Compared to others, I like the ease of Service Desk. It's easy to maneuver around in. It's very user friendly. Things make sense where some other products we looked at, they were very confusing.
We found that there's plenty of things that this tool does that we frankly aren't utilizing. Other tools looked neat, but when we got to really looking at it we just have it. We're not using it to it's potential to be honest with you. We do have the CMDB, but we're not utilizing a lot of the integrations to the potential like the IT workflow. A lot of the automated processes we're just not using and I'm sitting here looking at this stuff going, "We are barley using this tool."
We could be doing a better job, but unfortunately out hands are tied because it takes our system administrators time and effort to implement these things for us. Whether we want them or not, it's whether their team has time.
Room for Improvement
The thing that gets me is they sell it as a customizable tool, but the more customizations you add to it, the less stable it becomes. So over the last few upgrades, we've tried to come out of box as much as possible, and that has worked for us. Sometimes, people want and want and want and change and change and change and we find you really can live without all those customizations and it works just as well, I mean, works better. We're getting ready to upgrade to 14.1 and we were talking about that. Really, the last few years, we haven't really had to use the word outage very often.
I've suggested a couple of improvements. It might not mean anything to you specifically, but I have joined one of their communities and suggested that, when it comes to groups, they need to have a separation of groups so that you can have a separate group for work flow tasks in the change side than you do on the other side. The problem is, we have business people and different approvals on the change side that need to approve change orders, but they don't need to be involved on the ticket. But what happens on the incident problem request side, when people are playing hot potato trying to get the ticket out of their queue, they're looking for a group and they're picking it whether it's a my work flow group or not. We've tried to creatively name them so people won't use them, but there needs to be a separation. You ought to be able to select what modules you want that to be available in.
One other thing I can think of. I've noticed with this latest upgrade they're starting to change their terminology. They're calling incidents issues in the service catalog and I'm really curious to go talk to someone about that. We have what we call an issue module for our business side and that is for our external customers. When we plan to bring about the service catalog, they're going to be really confused when it says open an issue. Why did they do that? Why did they change that terminology and I've heard them use it in here. You know, "When you go to open your issue." I'm like, that's an incident. That's not an issue. That's two different worlds.
We've had no issues with deployment.
Customer Service and Technical Support
That would be the tier above me, so I haven't had to deal with them.
Other Solutions Considered
ServiceNow we also looked at. I would have been okay either way. In all honesty, it was more of a cloud solution and we wouldn't have needed our system administrators for as much as the upgrade work. That was kind of one of our driving things that did lean us towards that. The other tools were way too expensive compared to what we had. When we did the comparison, again, the new tools looked tiny and new, but we weren't utilizing what we have. We have some of the same features. We just haven't used them.
You don't have to go for the newest item out there. There's reliability, stability in maybe some of the older tools as well.