One of the of things I like best about HPE Service Manager is while it's a solution that does work out of the box with some configuration, its real strength is its ability to change for your organization's infrastructure.
What I do with the tool, our Process Managers come to our group and say, "We're trying to do this. We're trying to enable this process. We're trying to manage this application. We're trying to do this new thing. How can your tool help?" HP Service Manager's primarily for incident problem change configuration management. When they have a new thing they need to do, my team builds Service Manager to do that new thing.
While the tool works, what makes it work better is I can make it do whatever they need. It's a completely customizable solution to fit with the specific needs of our organization. It does it really easily and really dependably. I never have to worry if the whole thing is going to break. The tool won't break because of the changes that I make to it. My specific thing might not work, that never happens. But the tool itself is not at risk or in jeopardy when we're making these changes to it. They built it with that idea of configuration in mind. I think that's really its real strength and that's where it helps me.
Improvements to My Organization:
When we're doing a refresh of workstations, as everybody needs a new PC every two years, the team that's managing that refresh process, just says, "We want a way to open this refresh ticket. We want it auto-populated with all these specific pieces of information. We want to automatically have a reminder go out X number of days before the refresh. We want an email that can contain these pieces of information and allow the user to click yes or no to these options. Can you make that happen?" And I can. The tool doesn't do that natively but all of those things that they needed it to do it was really easy to set up for them to do all of those things. Making the PC refresh process work a lot simpler without having to come up with, "Okay, how do we build a solution for that." We just build it into something we're already using.
Room for Improvement:
My big concern is that HPE made a decision in its last dot release to change the way that these improvements and enhancements are done by the end user. They went to what they call code-less, really it just means you code less. It's not really a code-less mode, you're just coding less. Their sales pitch is, they can take the control of these improvements and enhancements out of the hands of people like me and into the hands of the person who's saying, "Can you make it do whatever?"
The gap in that or the thing that makes me nervous about that is the guy who is saying, "Here is my thing." Doesn't have the picture of here's everybody else's thing and how yours is going to impact theirs. Some of the things they ask me to build are really dumb and I shouldn't build. That conversation with the development team that says, "This thing that you're trying to do doesn't really fit. Does it really make sense to do this thing?" And having that sanity check. If my end-user can build that themselves, then you don't get that level of sanity check.
As they move to what they want, I think they're trying to make it easier for the companies that are smaller companies that don't have guys like me, that don't have an expert to do the building and make it simpler for them, but in doing so they do make it a little bit more scary for the guy who is managing it for the larger organization. I want to be able to make this stable. I know that what I'm putting in isn't going to break anybody else's things. I won't step on your toes because so and so has asked me and so and so has asked me, so I'm familiar with what everybody wants.
My concern is not something I want them to do different, but as they're going in a direction that might sell well to the guy who doesn't have a guy like me on their team it actually is scary to the guy like me who says, "But how can you ensure that people are going to do it right if you're putting it into the hands of Joe user who isn't aware of that bigger picture."
Other than that, I guess the only other thing I would say is it really is an amazing tool. They have built in integrations with out of box tools and standing up integrations to brand new tools is really simple. We've custom built 64 different integrations, usually within the period of weeks. Somebody says, "I need a new way to do this." We're like, "All right, we'll stand that up." Most of the development time is their product talking to mine, because I know how to make my product work. They're still figuring out how to talk to my product. But standing up new integration points is really simple, working with other tool sets is really simple. They do a lot of things really well. I think it is awesome, and I'm surprised that more people don't think so.
Service Manager itself is stable. Every time there's a major release from the vendor we put it through its tests. But we do quarterly releases every 6-8 weeks we're implementing minor improvements and enhancements to make the processes work better and usually it's just functional testing. We never have to worry about what it's going to do to the underlying system. The user says, "Make it do X." We come up with a solution. We say, "Is this what you we're thinking of?" They say, "Yeah." We put that into production and we very rarely get any sort of negative follow-up. We've had 26-27 months without an unexpected outage.
It is built for small organizations all the way up through large organizations. We have 6,000 active users; 6,000 operators within the tool. It's a software for tracking something broken. You call into the help desk and say, "My X broke." Service Manager takes over from there, the person who's taking your information is pulling your information from Service Manager and they're putting that in the ticket and that ticket is in Service Manager, and your thing that broke is a record in Service Manager and they know all about that thing. We have, I don't know, close to 100,000-200,000 tickets a month.
Our volume is incredibly high. We have a lot of throughput of the number of tickets. Some of those are from users who've called in and said, "My X is broken." We have integration with automation and monitoring who can automatically create tickets within the tooling system. It works for a small, but we're not small we've been big the whole time.
For most of the Tech Support I'm the guy to ask. When we do ask questions we have to ask questions of HPE, and they're familiar enough with us now, but the first level support guy whose job it is is to ask the first level support questions, I get to bypass them. They send me to the third level support guys and I get to ask the interesting questions.
When dealing with HP’s technical support, the first level support teams are responsible for weeding out the simple questions. They aren’t necessarily experts in a particular tool-set like HPSM, but they are the ones with access to documentation and the ability to search through it. So the job of first level support is to ask the basic level questions – what version of HPSM are you using, what messages are in the logs, what error messages are you experiencing – etc., and then search through HP’s documentation library to find answers for those questions. For simple questions, that level of knowledge is great. But we don’t ask simple questions anymore. We’ve been working with the toolset long enough that our questions are beyond the ability of first level support.
Fortunately our support contract allows us to move quickly past that first level of support. When we get to the next levels of support, we move past the team that asks the basic questions and reads through documentation, and we get routed to the people who are (or were) developers, consultants, tool experts who have knowledge more than just what’s been documented, but who have the knowledge that comes from experience. So when we have a question that is not a simple question, we get experts who know how to assist us in figuring out the answers.
They had an old software suite called Vantive that was going out of support and starting to get too expensive. They needed to move to a more modern platform.
That's actually how I got involved. The people who deployed it did a bad job. They built it and then the consultants left. The team that was onsite was doing the best they could but there were some foundational flaws with how the deployment was done that they didn't know about. They were looking for an expert, someone who knew the tool, who could come in and sort of help them fix some of those issues and they hired me over the phone because I fixed one over the phone.
They're like, "It's always slow when we do this thing." I said, "Well, have you checked here. There's an out of the box function that's really a sales pitch function, that as soon as you have a 1,000 records it starts to slow down." Like, "No, yes we do have that enabled. Let's turn that off." As soon as they did that on the phone, they were like, "Can you come work for us." No, I wasn't part of the initial deployment but have been there every year but the first. I solved the problem over the phone. He hadn't met me in real life, in that two hour phone conversation he said, "We want to hire you. Do you want to move out from Minnesota to New Jersey and take the job?"
Other Solutions Considered:
They had looked at a couple of other ones: BMC's Remedy, HPE Service Manager and then a third one. Remedy actually came in first in their reviews, they liked Remedy better but the license and support was more expensive.
Service Manager's big competitor is ServiceNow. It's a hosted solution in competition with HPE Service Anywhere. HPE has a hosted solution. People think ServiceNow is the be all end all. The reason they think that is simply because the user interface is really pretty. They think because the user interface is really pretty, the underlying stuff is working as well.
A couple years ago we looked at moving away from Service Manager into ServiceNow. The more we dug into ServiceNow the less we liked ServiceNow. While the UI is pretty, all the things that they swear are better, when we were testing it out and actually walked through some actual real life scenarios, didn't gain us anything. It was slower than what we were doing in HP Service Manager. They were like it's upgrade proof and you don't have to worry about any of your code breaking. We had code breaking. They are like, the upgrades are simple and experiences no outage. We experienced outage every time they did an upgrade. The hosted solution where someone else is taking care of it for you didn't really work.
We kept it in-house and we kept Service Manager because we wanted to be able to have that control. We wanted to know what the impact was going to be. We wanted to have our hands on because then if anything went wrong it's on-us. Because of that we have made sure everything's gone smoothly because it's on-us. As people are looking at their solutions as your looking at Service Manager compared to ServiceNow look at what you can configure and customize in HPSM compared to what you can do in ServiceNow. Look at the true cost of ServiceNow compared to their sales pitch of that costs. Look at what you can actually do with the tool set verses what they'll sell you with the tool set. Remember that the prettiness of the UI, it can look like a beautiful car but if it doesn't get you down the street it's not really a good car. It will look good in the driveway but it's lousy to drive.
Their fallback was this, and it wasn't like, "Oh, we didn't want HPSM." They analyzed three and this was number two. BMC and HPE Service Manager tend to flip back and forth between who's the best depending on what year. It wasn't like, "Oh, I guess we'll have to have Service Manager." It was, "Okay, that was more expensive then we want to pay. We're happy to go with HPSM."
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Aug 24 2016