ServiceNow Reviews

Because I do IT planning and program management, the project portfolio management part is most helpful and useful, but I can also see the integration to other parts of the IT operation as well. I think that's most useful because we are looking from an end-to-end perspective within the IT organization, though we may have different functional teams, but we are working as one team, so it's important that the various operations or processes are tied and integrated into one platform, in one end-to-end process.

I can see a very good product strategy. We see enhancements or enhanced features in each of the releases. I see the roadmap is good and the technology underneath is also good.

During the Knowledge16 conference, I found out more about the IT financial management part, which is important to me because we're trying to do more finance on our IT operations so that we can measure performance. We can also share info with our business shareholders and stakeholders as well. I see those features as really useful when we transform our IT organization into a service organization.

In our region we don't have many choices of implementation partners. At the same time, I don't see that they are as proficient as they are in other regions.

Today we aren't seeing major issues but one of our concern is that it's expensive.

Not at this company, but beforehand I had used Remedy. It is a very traditional IT Service Management tool, basically a help desk, but I think there's a lot more in ServiceNow.

The underlying technology and also the application or customization facility, or the technology behind ServiceNow actually is quite robust and quite agile, which we can make use of to do a release and deliver it quickly.

We're using Deloitte as our implementation partner. They are doing a fantastic job, but they're just one particular resource, one or two that can help us, but in our region, we don't have many choices on partners that are proficient in ServiceNow as well as in IT operations.

We are trying to do it in a phased approach, we want to have the initial system for us, and then we'll use it and improve-enhance it later on. I don't see that we'll have major issues, because our goal is not to have it all in one step, but rather we are evolving our solution.

I do not have particular details, but what I heard from my boss is that it's not a cheap solution, especially when you want to roll out to more people or more colleagues in an organization. That is really a significant factor we're considering because in terms of the cost it's not cheap, so we hesitate. We can see a lot of scalability and expansion possibility in rolling out beyond the IT organization.

Over the two years that we've had ServiceNow up and running, we've had a couple of service interruptions. Other than that, no. Some kind of network problem they were having, they had to fall back into a different data center, and that took about 15 minutes, I wish it was a little bit seamless, but we've had a couple of glitches.

The ability to add more users to the system itself, what we have done is we've linked it to our active directory, and that's where we're importing the user information from, and that's been working great for us.

Our company is basically a group of companies, it's not just one company, so our IT infrastructure and department and the way we operate is very fragmented. One of our goals is to combine them into one enterprise.

We are actually using about 26 different ITSM tools and we are in the process of eliminating them all. Over the past two years we have been able to get rid of five of them, and we're continually working towards off-lining the rest as well. The biggest one that we currently use is Maximal, I believe IBM uses that, that's who we deal with, and it's still there.

I wasn't with that company when they were implementing it, so I'm not exactly sure. As I was joining them, they were deploying their first module which was the incident module. Others have been very easy since I've been there, they did knowledge, they did change, and they developed a custom application, which after a little while ServiceNow provided free of charge, so that was kind of always, but we're still using the custom one. As far as deploying and developing goes within ServiceNow it's very easy, not painful at all. The only pain point for us is because we're a group of different companies, our collection of requirements is a little bit lengthy, it requires a little bit more work than other companies. The incident module itself alone is very complex because we have several service desks at several locations and fairly complicated.

I would advise you to stay out of the box as much as possible. I know it is very difficult to do that, but if you stay out of the box and go with minimum customization it would be the best, because when you upgrade to the next version, our next release or example, we will encounter issues if you have customized it, and you'll have to fix that. Also as far as testing goes, try to automate it. Because that's right now a challenge for us, a regression test.

We primarily use it for change management and incidents. We get the greatest value from our change management. We recently moved to ServiceNow from HP Service Manager about two years ago and it's been leaps and bounds just better than what we had before. We're able to do our approvals, automated approvals through email, through other means, and it's just made everything so much more smooth.

We found because we're working on an internal cloud solution right now, we found that being able to integrate with other solutions it's been so great because we're able to use the APIs and web service calls to integrate with SCCM, Microsoft's orchestration tool and we're just been able to find that it's so versatile in working with other products and it's made everything so much easy.

The only complaint that I would have is just the interface itself is not always user friendly. We get some complaints from users that they don't know exactly what all the features, all the fields mean, and what they're used for. I guess I want it to be  a little more user friendly.

I wasn't really involved in the installation of it. I'm more on the admin side so I can't really speak to that.

We do our maintenance updates about once a month but we haven't really had any downtime at all since we've put it in place. We recently went through an upgrade about a month ago, a couple of months ago, and there was no issue, there were no issues at all.

We haven't really had to do that yet because it's fairly new in our environment we haven't really had to scale it yet. We're basically using the same infrastructure that we put in initially.

Upgrades are fairly easy. Like I said, we don't have any real issue when it comes to updates and maintenance and things like that. I would say we haven't really had any major downtime incidents since we've had it in place.

I think getting your support team involved early on so that they understand how the process is going to change from whatever they're currently using is a big key. We had some growing pains initially going from one system to the other, but getting the support team involved early on in the process would be very beneficial to anyone that's moving forward with ServiceNow.

ServiceNow enables us to transform IT as it's a business driver. In my mind, we can shift the way IT works to make it more business aligned, business focused, and business oriented. Having a tool that kind of helps IT think differently about how we deliver services is important to me.

We're rolling out service level management this year and part of that is because we had this foundation of our CMDB. Our business services are in there. Being able to report on things based on how our business service is impacted, it's going to be the first time technology's been able to do that at this company. That's exciting.

Speed of delivery is really at the forefront. Being able to do things faster removes those IT obstacles out of the way for our business users and lets them do what they need to do quicker. We're enabling our business to be more nimble without bogging them down with technology.

I feel like there should be perhaps more unit testing before patches are rolled out because every patch has broken our entire catalog. That's kind of the most time consuming areas to test because of volume. There's so many catalog items. Each one has to get looked at, the workflows, each step has to be done. Every patch has broken our entire catalog, and I'd love for that to go away.

From a user perspective, we noticed a slowdown when we moved from Eureka to Geneva, so I've got a lot business customers that are saying, "Man, your tool got slower." I don't have any stats behind it. It's running all the time.

We add users constantly. We onboard people and they are automatically added. We have a portal that's internal for our users that don't need to do changer class but they do need to request things in the catalog so those people are able to log in and request stuff.

I think the only thing where there was anything negative was now you have two tools in the interim so people still used Remedy for some of the ITIL processes and now they have ServiceNow for change. Then as we increased our capabilities in ServiceNow, more and more people were happier.

Just really for me, it's all about the business case. What's a success story to tell? What are you able to do now that you couldn't do before? Some of the things that I would showcase are the wild set that we used to be in as far as requests goes and now we have the catalog and we're growing that everyday. Also, having a business portal is a huge selling point. Anything where you can spin up a portal as easily as you can with ServiceNow and make IT approachable for a business user is important. Every time they patch, they break the entire catalog. They need to fix that.

For me, it's basically the ITSM rules of ServiceNow. You can help the companies and all that stuff with their assets as well and all their service catalogues. It's a pretty complete platform that you can basically create whatever you want.

For us, we can have all the information organized, all PIR processes. We can have, as I said before, all of our equipment, assets, and employee control all in one small place.

Some of the things which I've seen that they're improving now, it was the UI. It was a pretty basic UI which needed improvement. Now with Angular and stuff like that, making it more responsive, that is very helpful, but they need to work on the UI more.

They don't seem to have that major impact. It's not a huge difference. Maybe from Fuji to Geneva it might have changed a bit, but we didn't see it to Helsinki.

The performance also depends on if you have too many changes, depends on the script and the developer that has worked on that instance. In the out of the box service, no, I haven't had any performance issues.

For the most part it's easy. It depends on what the user wants, but most of it is all easy. They have the business rules, client script, everything is basically ready for you to develop.

The cloud is the future, so you want to have everything in the cloud, everything organized, everything in one place. Basically, that's it. The cloud is the future.

I find the product to be valuable because even before they started really pushing it as a platform as a service, that is the biggest reason as to why I leaned towards its purchase two years ago; it's platform as a service. We didn't really purchase it as a SAS product. It's valuable to us because we do a lot of custom development on the platform.

We could have chosen many different platforms but for lack of a better word, it was the easiest to be able to move to, taking all of our existing processes and data from different sources. It was born in the cloud so we didn't have to worry about all of the nuances of being able to ensure that it would work as a cloud application. That was a big piece and it already had a service, although rudimentary, a service portal available with it. I think in the previous versions it's referred to as an ESS portal. With Fuji on forward I think they refer to it as a service portal.

If you look at the number of support calls that we put into ServiceNow, it's absolutely minimal because we filter. We don't have our users calling into ServiceNow directly and we trained our users, etc. I don't really see the value, monetarily, from what we're spending from a support perspective. Because if we call into ServiceNow it's because we're experiencing something at a much higher level, not something that is an easy fix. It's usually we've recognized performance issues or something like that. Their up time has been satisfactory for the most part.

For the most part, the product is very stable. We host customers ourselves and we know how difficult it is. As a host provider you're not completely 100% in control of everything, you're dependent on other vendors to be up.

We've had three major upgrades since we implemented and there have been no issues. A lot of that has to do with the fact that we followed a very regimented custom development best practice so that we wouldn't interfere with any of their upgrade processes.

It does not necessarily scale from a licensed user perspective, we don't grow as much because our license users are really just our core set of resources within our company that's internal. From an external customer perspective, our customers are international/worldwide, so we have folks from Africa, Singapore, London accessing the system. We went from an initial 8,000 users to double that amount from an external customer.

We also continue to use our own application that we develop which supplements ServiceNow.

We had a lot pushing us to go very fast so we implemented ServiceNow in less than a 90-day period once we actually started progressing to actual implementation. Some portions of just deciding upon the product and all of that took much longer, but once we procured the product and actually set on our way to implement, in less than 90 days we were live.

Advice to peers: It would depend on the problems they're trying to solve. It really would depend on the problems they're trying to solve. As an ITSM solution, I would highly recommend it, first choice. For something else, it would depend.

For me I believe it would have to be the real time reporting capabilities that it has, as well as the knowledge management features as far as reporting. We're just getting kicked off with trying to push knowledge management out into the organization. It's important to get a read on how it's being accepted as well as what's being used and how we can improve upon it in real-time.

I believe because it has so many different pieces to it and they're all interconnected, they're all interrelated. As you know, in IT everything relies on everything else. That fact alone that the CMDBs in the middle and everything feeds into it and comes out of it. That alone is an essential piece to the strategy.

Look at the cost savings that's there for it, the capability. So many companies nowadays want to make sure that they're on an ITIL compliant platform and ServiceNow is definitely that platform. I'd have to say that's one of the big business drivers. If you merge with another company, you've got an immediate capability to include them and bring them on board.

I think within knowledge management the editor could be greatly improved. To me it's very archaic looking. One of the issues is when you go to pull a document in there - we're talking about knowledge, we're talking about how to do something in many cases. It doesn't do numbered lists very well. As soon as you put a picture in it starts your numbering over. I don't know if there's something wrong with our implementation or it's just out of the box. We have it set up out of the box. That's one of the downsides. In general I hear a lot of people say that the interface from a back end. From the folks that have the IT role, it's not a pretty picture.

Myself here with this organization I've used it for about two years, and with other organizations on and off for about two years plus. Currently, we're on Geneva.

We've had a little bit of slowness at times. We're looking into the heart of that and I think that maybe some of that is maybe our implementation. The way we've gone about setting up database calls and things like that. It's hard to say. I can't really speak to that because I'm not working so much with that group. Occasionally, depending on the implementation I've seen it always run smooth and fast.

Other times we have to deal with the internet is right in the middle because it's cloud based. You never know if that's the reason for the lateness. Overall it's a great product.

Well from what I understand I can't speak to that really well. It seems quite scalable. I know other companies that are much larger than ours that have had an excellent implementation. I was in a talk where the gentleman was from a large company that had a huge investment in it, and they were using it across four hundred and fifty thousand employees or something huge.

In my past lives they have used Remedy as well as HP Service Desk at the time. At a previous company, I helped to implement HP Service Desk.

I don't know how it has been here, but in other places it's been a very straightforward and simple implementation. What it really requires is all the pre-work. If you're going to implement it you want to have an understanding of what you're stakes are. For example, in incident management. What the teams are going to do. What the processes are going to be worked out within the tool. That's an important aspect. A lot of people may think that you implement a tool and you have it. It's not that simple. You have to do a lot of work before you implement to make sure you have your processes in place.

One of the things important, if you're going to put new processes in it, have them written down and have them well understood and well documented before you implement it in the tool. Once you implement in a tool, that's when you can really start to improve on it. If you just go forward and put it in a tool and you don't have any documented process then you're back to square one. You don't know what you're improving and you're making changes and it's not a pretty picture.

We have a young lady who's very adept and she's moving forward with that. Making great things happen.

Make sure you have your processes well defined before you go to implement a tool because that's where you're going to get your real payoff. It's going to really help you improve things if you have all that well documented, well understood before you have it implemented. I think that's the biggest thing.

I think that they could do a lot better on thr interface. Especially for the back end because we can build all kinds of- there's all kinds of companies out there that create all these things. At some point you would think that they want to improve these certain aspects of it that- like knowledge management.

It acts as a one-stop shop for customers to be able to go in and create instant problem tickets if the incident is severity one or two. But basically, it's a one-stop shop because beforehand we were using multiple ticketing systems, mainly by email. So now instead of having that we just have them go in, log a ticket, and then its assigned to whatever group and whatever the group it's assigned to goes ahead and takes care of it.

We were doing our user on-boarding via email, and it involved a lot of emails going back and forth. Now, it's just a ticket. Our security team gets provisioning tasks. You can log an instance, use a service catalog, we have provisioning. It's just as important for them to go to one place. On a macro level it helps us do things more efficiently.

I can't wait until we get to Helsinki and such. There are some cool things that I have seen. Portal. The drag and drops which we currently don't have with Fuji.

We've been using it for three years, and we're currently on Fuji patch 3. I'm in the process of fixing our patching problems because there were some issues. Once I get it done, I will go ahead and bump us up to Fuji, patch 12 or so. Then we have a project where we are going to simplify our system, and we have a lot of customization so we are going to kind of try to go back out of the box.

They wanted a ticket to where the customer would see a general global ticket and not have to go through and see if it was an incident or a general request or whatever. And this one particular ticket and the way they have it set up is fairly complicated. They didn't use global tables that should have been used, they customized it and now we are having issues. So we are going to try to get it back to where it is a more simple thing and this should make it more stable.

The system admin. We have another guy that's our business analyst. But we have around 20,000 people in the company. Its global, so everyone is using it well we hope everyone is using it. We've added the catalog, we've made it global within the last year. So we have North America, Australia, Northern Europe and Central Europe. And we're hoping our European people are using it as well as Australia. But there used to be a lot of emails and stuff bouncing back and forth rather than using catalog.

We were using ChangeGear which was kind of limiting. We're a global company now. I don't know, I wasn't in on the why we changed but I know that we were using ChangeGear now before Service Now and it just wasn't suited to our needs.

I think that the way they set up global ticket there was a lot of development, so fairly complex. If they had not done all the customizations, it would have been a lot better, a lot easier and more straightforward.

I would recommend it. I would recommend not doing a lot of client scripts. Not doing a lot of customization. Stick with the out of the box, it's easier to upgrade, easier to implement. The people who are behind the scenes like I am need to go and find things in the Wiki. It's much easier to find, to fix that type of thing.

I've really enjoyed working with it, and I guess it's just the way we have things set up. It's a little frustrating not being able to find things, all the stuff I have to go through to get things fixed.