ServiceNow Reviews

We primarily use the solution for tickets and we use it for order processing.

We use the product for incident management, asset management, and service management. Those are the three big use cases. It's mostly asset management.

We use a ton of the features.

The best feature for me, personally, is Discovery. That one is super useful for us. Discovery is super advantageous. That has brought us a long way forward. That is a big deal for us. It's gotten us away from the manual of walking the floor to trying to find the assets.

The other one that is really big for us is Automatic Workflows. That is a big deal and certainly helps with the streamlining of the process and the interconnectivity with incident management.

The solution is very stable.

The company went out of their way to help us and even helped us save about six months of deployment time.

If you stick to the out-of-the-box solution, it's an easy setup.

You can scale the solution quite well.

Technical support is very helpful and very responsive.

The licensing needs to be divided into tiers in order to attract lower-level users.

Right now, the licensing is kind of an all or nothing and so what happens is, is that either somebody has full access or they don't have any access due to the way the licensing works. There is this kind of view for ITIL purposes access that we kind of need, and we don't have access to it. If you think of RACI, it's informed access. You would need a full license to be able to do it. And we just don't. It really caused us a level of visibility loss. 

Basically, what the licensing offers now is just for doers. There's no viewer role. It really needs a viewer role or an approver role level of licensing without a doer role license having to be issued.

If you move away from the out-of-the-box configurations, the initial implementation can get complex and take a while.

I've been using the solution for about two years at this point.

I love the stability. We were lucky enough to be physically located very close to Service Now. When we were hitting problems with our internal organization to roadblocks, we literally drove up to Service Now headquarters and sat down with them for an eight-hour session to revamp our whole internal process. I was pretty sure that if we would have continued down our own process, we would have taken another six months. However, with Service Now's assistance, we fixed it in one day just by having access directly to Service Now. That was an amazing process. They enabled us to jump forward six months and made things super stable.

We're a huge company. Scalability is definitely possible. We're scaling to over 100,000 users. We have asset management users, incident managements, software deployment, hardware deployments, break fixes, asset monitoring, et cetera, all on this solution. 

We do plan to increase usage in the future.

If a company needs to scale, it can do so, no problem.

Technical support has been great. They are extremely helpful and responsive. We're quite satisfied with the level of service we receive as an organization.

We did previously use different solutions. Everything was fragmented. We were able to combine multiple systems. We tied multiple systems to combine them into one ServiceNow offering. We wanted to consolidate 50 or more systems into a single system and Service Now is one of the two options we looked at that was able to do that.

The deployment process is basically about requiring, gathering, and then developing or customizing the product itself for the workflows and then deploying it out into the field. It's really pretty simple, as long as you stick to a lot of the out-of-box functionality. 

When you start to get away from the out-of-box functionality, you can really link in the deployment process. Anything that you go out past that out-of-box functionality, you can really hurt yourself. Basically, it has the capability of getting very complicated. However, if you stick to out-of-the-box, it's simple. We personally found that out the hard way.

For us, the deployment process took two years. 

We recruited some outside help to assist us in the implementation. We found that having experts on hand was extremely beneficial.

I'd recommend outside help. There are definitely some nuances within the deployment that having some experts within Service Now is very helpful - especially when you're first time to have some outside thinking. 

Our organization has noticed an ROI. They're happy with it.

The licensing needs to offer a variety of levels to meet what an organization actually needs. Right now, it's all or nothing, and that can get costly.

We also evaluated SAP against ServiceNow. We ended up choosing ServiceNow in the end, however, I can't recall what the deciding factor or factors were.

I'm a customer and end-user. 

We are using the FAAS version of the solution currently.

I would advised those companies considering the solution to take advantage of what the programs do rather rather than try to lift and shift.

I'd rate the solution at a nine out of ten overall.

We use it for ITIL/ITOM catalog of services. ServiceNow is the CMDB for our organization, and we use the Discovery, Incident Management, Change and Project Management tools within ServiceNow to keep a centralized view of our enterprise. We have recently begun implementing the Governance and Risk (GRC) features as well.

Discovery has reduced, on average, the time to build/deploy devices within our environment by one hour. This may not seem like much but it adds up over time. It also reaps additional time savings with its ability to capture changes through subsequent discoveries over the life of the device. Discovery is the first piece in the CMDB chain for our organization, making sure that the device appears in the CMDB before it is needed (for, say, a change request).

ServiceNow Discovery is very valuable. It does, however, come at a steep cost of time and effort to implement it correctly. Do not be fooled into thinking it will "just work." Discovery, within any platform, requires meticulous planning and management to have it work for you. No discover solution is ever the "silver bullet" either, so plan to have more than one discovery engine implemented to cover your enterprise.

Where it could be improved is Discovery. This may sound odd since I just praised the value of ServiceNow Discovery, but improvements to its automatic detection, the breadth of devices, and the depth of devices covered, as well as keeping up with new technologies, are all essential.

Microsoft has caused some issues recently with its decision to move away from SNMP and WMI in favor of PowerShell management. ServiceNow will need to make changes to move away from these deprecated services and to discover these devices. Discovery engines universally rely upon SNMP to detect, at least at an initial level, what type of device they are talking to. Without SNMP, some other platform will need to advertise the device and its capabilities. Most applications offer API (ideally REST-based) connectivity and ServiceNow should expand upon its use of these connections.

The SaaS platform has been very reliable. ServiceNow has been one of the few SaaS solutions that we have chosen that has not had major issues. The agility to provide test/dev instances, and the seamless access provided by their support team, have been essential in allowing us to work with the solution.

As designed, the solution is incredibly scalable. It is possible for a customer to create logic, processes, or other rules that will hinder or limit this scalability, but that is not the fault of the platform. Having a knowledgeable staff and/or partner will reap huge dividends in the scale of the implementation.

Technical support is very good. Like in any support organization, there can be technicians who do not meet your requirements, but the vast majority of the ServiceNow support engineers have been helpful. As a side note, support is delivered via predominately Indian personnel. This is common in the IT industry, but we have seen it almost exclusively with ServiceNow support.

We used the CMDB that is offered within the product that we make/sell ourselves (Plex Online). It was not designed to meet the needs of a software company and we took the opportunity to move to something that was a better fit.

The initial setup was incredibly complex. I would pity any customer who decided to self-implement ServiceNow, unless they have experienced, dedicated staff for the length of the implementation. I was largely dedicated to the implementation of the CMDB, Event, Incident, and Discovery pieces of our implementation, with the help of an outside consulting firm, and it still took up a massive amount of my time to implement.

Many parts of the ServiceNow solution do work out-of-the-box. Being flexible also means being complex. Rarely can you just apply a change to all areas or systems. Screens (or forms) are unique to just about every part of the system, so if you want a uniform look and feel you will need to touch a lot of places.

Even if you do not think you will need an on-staff ServiceNow developer, you will want one. Many of the changes to the system are too involved for a standard admin to make (confidently) and there will be no shortage of ongoing work to keep this person (or persons) employed full-time.

We deployed in stages, bringing certain modules online as we were satisfied with the functionality. We are truly still implementing. The core of the system necessary for day-to-day operations was deployed in about one year. But changes and features are still being implemented. We continue to add and subtract from the system as we use it and as ServiceNow offers new or enhanced functionality. We also continue to develop integrations with other business systems.

In terms of our implementation strategy, we took on the system in phases. CMDB was first. This was perceived as necessary for all other functions for our organization since we are using it for ITIL/ITOM. The CMDB was manually populated and maintained at first, while Discovery was implemented. Project came next, along with Time Tracking. After that was Incident, Problem, and Change.

We kept to an Agile deployment methodology focusing on the small pieces needed to keep moving the larger whole along. Customization was kept to a minimum (where possible).

We did use a third-party service provider but it did not go well. I still could not imagine attempting to do it without them, but two years later, we are still replacing much of the work they did. There is a cautionary tale here of not going with the lowest bid.

The biggest failure on the part of our partner was with Discovery. They did not have the depth of knowledge necessary to get this delivered on time or, in fact, working in general. The level of effort needed to implement Discovery, in the end, dwarfed the rest of the platform. The partner absorbed the cost since they failed to understand exactly what it would take to deliver.

We have not done an actual ROI evaluation at this point. We determined that it was necessary from a business standpoint to change to a scalable SaaS solution and ROI was not necessary as part of the project scope. I believe that through Discovery and Automation we could likely create an ROI case. In other aspects, systems like Change and Incident may have introduced some toil to our process, but this may eventually become less of an issue as we continue to refine our process.

Isn't pricing always too much? We really do chafe at the ITIL licensing. ITOM is also pretty expensive.

We evaluated Service Cloud and ScienceLogic. ServiceNow really seemed to have the most complete offering.

If you plan on using Discovery, double whatever hours/manpower/money you had planned that it would cost. Do not let sales convince you that any part of the system "just works." You will ultimately end up modifying absolutely everything. Definitely look at using a reputable partner for implementation, unless you have a dedicated knowledgeable staff of ServiceNow users who have done it before (and not who just went through training).

We have 60 users for ITIL. We have provided limited access to our development and external management users.

For maintenance, we have two full-time employees. One is a dedicated ServiceNow developer tasked with customization and managing version upgrades. The other maintains the CMDB and Discovery process. I could see adding one more of each.

Deployment was an entire team effort, with different teams championing different modules of the application. At any given time, there were ten to 15 internal employees working on implementation with the assistance of five partner resources.

ServiceNow manages and maintains our ITOM/ITIL daily operations. It is a core piece of our environment that will only continue to grow. We have thought about removing the ITOM piece as we have not been able to implement or leverage it as we had initially planned, but we are still working on understanding what other tools we would need to replace the features and functionality. The primary limit we have on increasing usage across our company is the cost to license ITIL users.

We are an integrator. We help our clients to implement ServiceNow for their companies.

The most valuable features generally depend on our client's needs, but most often it's some type of basic setup like incident management, request fulfillment, SLAs, problem management, change of management, and knowledge management.

In other cases, it can be something like an ITBM suite. Currently, we are implementing project management and Scaled Agile Framework for one of our customers.

It actually has quite a wide list of modules and processes.

There are Virtual Task Boards in the tool in the latest releases. There are many of them in the Scaled Agile Framework. There is some room there for improvement. It's really quite promising but, at the same time, it could be improved and I believe it will be improved soon.

The solution is quite stable. It's actually a big platform with a lot of plugins and a lot of things being introduced in each version. Sometimes there is not enough information about releases. For example, right now we have an issue understanding what the roadmap is for the Scaled Agile Framework.

It's very scalable. It's good, really good. I have experience working with other IT solutions like HPE/Micro Focus, and ServiceNow, in this regard, is all in the cloud. There are no issues thinking about the physical infrastructure. So it's very good.

Sometimes it limits you. For example, in CIS, they had a lot of issues working with a SaaS, but generally it is good.

I haven't had a chance to check technical support myself, but my colleagues say it could be faster. But in comparison to my previous experience with HPE/Micro Focus, ServiceNow is the same. It's good but it could be better.

When I was first assigned to this position and added to the team, and entered the ServiceNow world, this product and its use for clients were already ongoing. It was not new to the other members of the team. I was the newbie here. I checked out some training materials and I had some previous experience in the ITSM world. I just onboarded and started playing this role. It was pretty simple for me personally.

For the company, I can't comment on the initial setup because ServiceNow was here before me.

For the particular client we're working on, I joined the project last summer and it finished this summer. Before that, it had been ongoing for a year or year-and-a-half. But it was a big implementation, ten or 12 modules implemented.

In terms of the implementation strategy, there is most often a need in the client's company and they ask us to do a preliminary assessment and some onsite discovery. After the discovery, we build a prototype and finish the requirements-gathering. Then comes the implementation part which is mostly done through an Agile approach. After that there is testing on our side and user-acceptance testing on the client's side. Finally, it is released.

Speaking in light of my previous experience with HPE, at that time, around 2012 or so, if ServiceNow was a bit cheaper it would have had a good chance of our company choosing it at that time.

Now, ServiceNow is a leader and its pricing is quite good, quite competitive. If it were cheaper it would probably be better in this market niche.

Sometimes some plugins are not priced reasonably but, generally, the platform itself, its modules, are priced reasonably.

Long ago, when our company itself was choosing a platform, a solution for the company to support, there was a big analysis effort and investigation of what was on the market. Back then we chose HPE. But that was really long ago and it's not relevant to my activities and my experience currently.

My advice would be not to try to implement it by yourself. You could spend a lot of time without any considerable outcome.

We have ten clients right now and some of them have 1,000 users, all together. They have 20 to 50 engineers.

Deployment and maintenance on the client's size and their requirements: how quickly they want the implementation done, and on how many people create tickets, etc. The basic team is five to seven people who implement Service Now. For support of the solution, it's a maximum of three to five people.

I would rate ServiceNow at about nine out of ten. One of the things to be improved is their transparency in working with partners. Being a partner of ServiceNow, sometimes it's not clear how we should check for new updates; for example, this Scaled Agile Framework, etc. Working with HPE was more transparent for me. I had good communication points to address questions, not on the support level but on a higher level, to get answers to questions quite quickly and informatively.

We are a large integrator with more than 20,000 IT engineers. We work with many vendors including HPE, Micro Focus, Oracle, and some dozen other vendors.

We use it as a service desk solution, for ticketing.

First of all, we had several tasks that were performed manually by the service desk and infrastructure teams, but now we have been able to automate those processes and reduce the manual intervention. For example, when an employee from one of those teams goes on vacation, we can block the account and, when he comes back, we can unblock access and reset the password, and everything is done automatically.

The most valuable feature is the flexibility of development for customization.

For example, we are starting now to expand the tool for HR and some other departments. They need applications or processes to improve their tasks. For instance, right now we are discussing, with the Internal Risk team, creation of an application inside ServiceNow so they can open a ticket and follow all the steps according to their process. One of the nice things about ServiceNow is that, if you have your process, you can design the ticket and the form according to your process. That is very useful and can be done quickly.

There's one that I would like to see improved to reduce the cost of our ServiceNow, related to the resetting and unblocking of passwords for users who forget their passwords. We had a conversation about this with ServiceNow. We don't have a huge amount of password reset requests, but the minimum package of resets that ServiceNow offers is much more than we need. In conversations with other companies that have a similar profile to ours, they complained about the same thing: "Why should I have to buy a minimum number of password resets, when that amount is much more than I need?" They should have some kind of scaling of the reset package, like zero to 100, 101 to 300, etc. That would be a little bit more useful for us. That package is very expensive. It's more expensive than if I were to have someone in-house who was dedicated to doing those tasks.

It's a very stable product, it has a very good SLA and RTO. So far, so good, and I expect it will continue like that.

I haven't had any issues with scalability so far, but we're a medium-small company with about 300 users. The most active users are the service desk, infra, and development teams. Overall, we have 50 or 60 heavy users.

Here in Brazil, we have local support from a company called Fast Lane. They are the enterprise that did the development and implementation of the solution in our company. We don't have any issues with them. They are very fast and very helpful. They help us with the design of our processes and the tools.

We had a simple tool with which you would just open a ticket, without SLA, no features. But we had internal issues and realized we should improve our processes. That's why we went to ServiceNow.

The initial setup wasn't so easy, but it wasn't a ServiceNow issue, it was an internal issue. Because it was new for the organization, setting up a cloud solution, we needed to open some ports in the firewall.

One detail we didn't explore so much during the negotiations with ServiceNow was related to Edge Encryption. That is a feature that encrypts all the information that is saved in ServiceNow. It was requested by information security here in our company. We bought it, but the setup for that tool was new here, in Brazil, from what I understood from the vendor. It's a little complicated to have all of the information and all the details set up for it. It took a little bit longer than we expected, but it was a management situation. There was no impact to the business.

We know that ServiceNow is not cheap, it's more expensive than other solutions. But we are trying to increase our ability to handle tickets so that the cost per ticket is less. ServiceNow is a little bit expensive for us, here in Brazil, due to taxes, etc.

We talked with HPE and IBM, but both are on-prem solutions, whereas ServiceNow is a cloud solution. That fact was very important for us, that it is not an on-prem solution, as it reduces our internal cost of support. 

Also, the development time for each process is much shorter than with an on-prem solution. For example, with on-prem, I would have internal processes like change management, open a ticket, fill out all the information, and get the request approved. After that, it would need to be implemented. That would take a long time.

It is very good having this tool. Getting it going went much faster than I expected. We did the setup and had it in production in six months.

The biggest problem for me was our internal process and not Service Now. For example, convincing people to go to a cloud solution, and getting engagement with the solution from information security, were challenges. If you don't have engagement from information security, the project is going to take longer than you expect. The big change for the company, with this solution, is that you're not going to host your data internally, on-prem. You are going to put all your data in a cloud solution. When we spoke about the solution here, within our company, some people said, "Wow! Are you crazy? You are going to put customer information in a cloud that you don't know?" So there are a lot of questions. ServiceNow has all the answers, but if you don't have engagement from information security, it will take you longer.

We have a lot of things we can improve internally, regarding information security, but because we are just starting out, we need our process to mature. I believe ServiceNow can help that a lot. All the features can support us in the future if we expand the tool. We have new models to improve on the automation of our processes in our data center.

My only concern is that when we started to talk with ServiceNow, we received very good attention from them but, after we signed the contract, I didn't know who, in ServiceNow, was taking care of my account. The person sent me an email but he had never been here to ask, "What do you need? How is it going? How is your project?" We didn't get any attention from ServiceNow. We had very good negotiations in the beginning, they were very attentive. But after we signed the contract, they changed my account manager and, today, I really don't know who that guy is.

I would very much like to have him here to discuss the roadmap of the solution or to see what else I can buy. I would like to negotiate some issues that we have, like password resets. I would talk with ServiceNow but, if they are not going to be close to me, I'm not going to spend time running after them to talk with them. I talk with the suppliers and they are helping me, instead of ServiceNow.

I rate ServiceNow at eight out of ten. Why eight and not ten? The relationship with ServiceNow is important for me. I would like to have more engagement from them, to have them here, at my company, so we can talk more strategically. But compared to the other vendors, it gets an eight because it's a cloud solution and I don't have any issues with technical parts or its performance. The tool is very reliable.

PPS components such as Planning Console, Resource Workbench and the Visual Task Board are excellent add-ons to the OOTB lists and forms and provide a great way to add value to the Organization without having to opt for a point solution for each of these processes.

ServiceNow reduces drastically the time to value and it is possible to completely get rid of flat files such as spreadsheets and powerpoints in less than a month for any Organizational process.

ServiceNow offers Angular components that greatly enhance User Experience. Pages such as the Resource Workbench to allocate resource, Planning Console for Waterfall planning and Demand Workbench to prioritize demands all contribute to adding value to a ServiceNow implementation project. On the flip side, until very recently the overall UX experience was very poor as everything is either based on a form or a list. Hopefully with the release of Service Portal and as it evolves in future releases, web developers will have more and more flexibility to improve on the OOTB UI capabilities.

Deployment through Update Sets can be challenging at first but after some practice they become easy as a breeze.

Stability is assured by the Vendor. No issues found so far.

Easily scalable as the Vendor assumes availability at all times.

Very good. Quick response and very customer friendly.

Technical support hours can be negotiated with contract and with so many community resources most of the times it's not even needed to recur to the Vendor.

Setup requires someone who understands the default data model in order to quickly identify synergies between requirements and OOTB capabilities.

Licensing model is not easy to understand and is constantly evolving. For example, just recently ServiceNow changed the PPS licensing model (now Service Strategy) to distinguish between users who only perform assigned tasks (workers) and planners.

As a platform approach I would say I really like this vision of saying ServiceNow is an application platform now as a service where we can build any application we want to so we have some applications on the baseline like in sales management, like change management, now customer services, like security operation. If we need to build other applications we can do it, the same way if we want to modify an application, we can do it as long as we follow the base practices.

It's something really nice to do with ServiceNow because all legacy products when you were trying to do something a little bit on the side, it didn't work anymore and was very out of grade. Here, with our customers it's actually nice to upgrade ServiceNow.

It's like when you work on science, you say, when I answer one question, I have 10 other questions rising up. I see the same thing with ServiceNow. When something is added on ServiceNow on the platform, then you have 10 more things to do because you have to improve again and again and again. Here what could we do? They probably have a lot of things to do with IOT. We can always improve a lot of things about how we work between citizen developers and professional developers.

I am a professional developer so I know about Javascript, about coding, about scripting, technical stuff, but need as well to have people who don't anything about it would just and test it by their business side of the things. I want to engage them more and more to do things, to start doing things and when they are stuck with something, they just say, "Okay, David, please come to us, please help us with this thing. Please finish up the polish part," and then we arrive. Those are the things I would like to improve to engage more and more and more the citizen developers.

I started using it in December 2011.

I think we've got one customer who had an outage once, or maybe twice. One was a mistake we did on an integration and not the fault of ServiceNow. Second one is that the personnel forgot to change some certificates, so the instance was working perfectly, but the customer said, "I have an outage here and why?" We looked at it and we say, "Did you do your work here?" "Oh shit! I have to do it now." Yeah, extremely nice. I never had any issue with ServiceNow.

We go through the smallest customers, probably have something like 30 people and the biggest ones probably have thousands of people using ServiceNow everyday.

It's working very nicely, with scalability. Again, scalability with number of people, but also different teams working on ServiceNow, different processes, different countries. You can work with people all over the world together because ServiceNow won't stop working at 9:00 in the evening for European time.

Extremely good. The latest incident I have registered on high support was last week and maybe it was extremely complex, extremely technical, but after maybe one hour or two hours they came back with an answer saying, "Yeah, David, please read the documentation because it explains there that what you're trying to do is not actually possible." They provides all the answers and explanation why it's not really good to do it.

It's different for each company because if you are already quite mature with your processes, if you have good communication on your team, if you are obvious approach of collaborating between people, it's extremely easy. It can take just weeks to do it. On the other side, if you had legacy processes, you customized the previous tools and if you don't have this collaboration approach with the different teams and if everyone says, "I know what I need. I need this and only this feature and I can't listen to you if you tell me otherwise."

In that case, it might take more time, not because of ServiceNow but because we need a chance to culture the company. We need to have a culture shift on the company to be able to go to the right direction on ServiceNow. Communication, marketing, intel or involvement, engagement with people. That's extremely important to do.

If you need more time to do, for example, user acceptance testing, if you say, "Well I'm not secure as a customer to go live now." "Okay, let's take one more week, two more weeks to test. We probably won't do anything, any new developments, just a sync," but at least you will be sure that your users know ServiceNow, they are ready for go live and will be smooth. That's the most important. You go live when it's smooth, and not when it will be hectic.

I have customers who use HP Service Manager, BMC Remedy or CA. Personally, I tried in 2011, I have tried to work on BMC Remedy for maybe two months. I didn't learn that much. When I had the opportunity to go on ServiceNow, I said, "Yes, let's try." It was very nice and I have also spent maybe two days on HP Service Manager and that was the two most boring days of my life.

Yeah, the only thing we have to say with customers who already have some product today, especially in ITSM, is don't implement what you have from BMC or HP in ServiceNow. When you do ServiceNow, you do the ServiceNow way, not the BMC or not the HP way. That's extremely important because that's where you can end up with something extremely complex, not only for the platform. The platform can manage it, the platform don't care. Technically it's possible. For the people, for the users, for the end users for the fulfillers, you want to do something simple.

For example, for one customer, a small customer like one Android people IT guys, small customer. They had on instant management they had three Android categories. When you do some ServiceNow implementations, the first implementation step, you have to review your processes and review the requirements. Be sure you have the right things in place and not the things you don't need. Yeah. I think if I have say three words about a good ServiceNow implementation, it's all about upgradabiity, because you have to upgrade every six months or every year so you need to think about the upgradability of your platform. You have to think about the performance and you have to think about the value.

If you request anything and if you are a customer and you ask me anything to me, I will tell you what is the justification. If you don't have any justification, I will tell you, "Well, I'm sorry. I can't do it." I'll go to the CS person, and the they will say, I want this feature and I will say, "Okay. You are the customer, I do whatever you need, but above that, you need a justification." That's extremely important.

Immediate insight into reporting. For us it's about trying to wrap our heads around the volume of tickets that are coming in the door. How quickly we're getting our turn time done? Those were things that were missing from our incident management platform. We could basically do a data dump once a week, dump that into an Excel spreadsheet, then do some computation on the side, and get those numbers out.

With ServiceNow, we're able to generate those reports daily. We can get that feedback almost immediately. We just started turning on performance analytics as well. That's one of the reasons I'm here [at Knowledge16], is to take the courses to learn more about performance analytics. We're really looking forward to that, to get it in more real time, and provide dashboards.

It was all on Fuji. Some of the things I'm going to say might already be in Geneva and Helsinki. We use a zipper product for our project management portfolio, demand management and resource planning. From what I have heard, and what I've seen thus far, resource management needs to be a little tighter. We're running performance models around capacity planning. We need to know: How many resources are in play? How many hours are they actually working? What's the requirement for all those resources on those different pieces? How does that lay against what we're allocating?

I can't have resources available for 45 hours a week, and then deploy them against 60 hours, and they only turn in 37 hours. The resource planner we have today actually calls out those discrepancies. I'm hoping that with performance analytics this will too. I haven't seen a lot of that in play yet because I think it's still fairly new for them. I think if you're going to run your IT shop like a business, you really need that kind of insight.

The other thing we do is we report out against three different modalities in our IT shop. 1. You got to run the shop. 2. You've got to maintain the business to keep the doors open. 3. You got to grow the business. There's some fancy math that you have to do against what people are doing, and how they're deploying their time to roll that back into one of those three categories. With the current system we have, there's a way of doing data masking and manipulating it so that way you can form these common buckets. I don't know that this will do that, I hope it will.

With ServiceNow, you have to do a lot of manipulation ahead of time to get to what that end state is. That said, coming to the conference and playing with Geneva, and playing with Helsinki, I've got a slightly different opinion. I'm pushing my guys to move from Fuji directly to Helsinki. Just because it does allow me to set those records up the way I want to quickly, as opposed to playing with the report to get that structure right. The only way I can describe it is, if you really enjoy building formulas, and data drops, and pivot tables, and having all that, and then analyzing the data, Fuji is great. Excel is also great for that, but it's not what I want to do. I want to actually analyze the data.

I've been using it about six months.

It's one of the few systems we have in our house that hasn't gone down. It's very stable. As a matter of fact, we don't even put it on our availability list because it's up.

We're currently on the Fuji release. There's some other things that we want to do like Demand Management and PMO they're coming out with in Geneva and Helsinki. It's one of the reasons we're here at the conference is to see if it will be scalable to those processes as well. From what I've seen thus far, it's pretty scalable.

To be honest, we have mostly in-house support. Anytime I've had a call or a question, it's been answered usually within a few days. Most of what we're looking for is just how do we get the right data. Our guys are able to go back to the system analysts, and get that information out, and then tell me which field to put in the report. It's a fairly quick turnaround.

We were using a competitor product at the time. It was from our corporate office. We brought a real sharp guy in from NetApp. He had used the ServiceNow platform for about half a decade. He's been to just about every conference. He was bragging about the fact that he was at the Knowledge 2011. He's a pretty sharp guy. He brought it to our attention, and then helped implement it. We tease him and say that maybe he's brought a lot of his bad habits from the other companies into this one too. Along with some of our bad habits from CA, which is us poking fun at the customization. He really does know the product inside and out, and we're lucky to have him.

To be honest, I wasn't involved a whole lot with the initial setup. At that point, I was in the PMO. I was watching it get executed as a project. It was a fairly quick project. I think we implemented six or seven of the modules that are out there reporting incident management etc. We were up and running in about two to three months.

Now that said, there's always the PMO side of the house where I got to look at it and go, "Did we get all the requirements?" I think we did it more agile. We're still finding things that we'd like to do different. Things we'd like to change now that it's up and running. Getting it up and out of the box is really quick. We did some customization which was really quick too.

Go ahead and get it. You'll have a cleaner insight into your organization, and how it's really working. You're going to do a little fighting with your groups if they're not already doing careful time tracking. ServiceNow is based at the task level. They assume that they are going to give you a task. That task has some time collateral associated with it. That tells you how long you're spending on certain things.

You have better insight into those tasks, better insight into how that time is being deployed. If your organization isn't already doing that, you're going to have a little bit of a culture shift. If that's where you want to go, if you want to transfer your business from "Trust us, we'll just get it done," to "I can actually demonstrate how we're doing it." ServiceNow is the right product for you.

I would say Fuji is about a 7, and what I was playing with the other day in the labs is probably about an 8 or a 9. It's a great product. I like where they're road mapping it. They have a very clear plan, and where they're going next. That's pretty exciting. We'll keep the product in-house for a couple of years.

We primarily use the solution for IT Operational Management.

Everything about the schema, including the design of ServiceNow, is great. 

It's scalable. That's what attracts me most. 

You can configure it to fit your client's requirements. You can extend your functionalities, and then the workflow.

The stability is very good.

It's moving at a very fast pace. It is difficult for developers or engineers to keep up with it. That's the only issue. 

For the customer it's expensive. 

I've been using the solution for seven years or so. It's been a while. 

The stability is great. There are no bugs or glitches. It doesn't crash or freeze. 

The solution is scalable. It's easy to expand if you need to. You can use it no matter the size of your organization - from small to large. 

We haven't had any issues with technical support. We are satisfied with the level of service on offer. 

The initial setup is excellent. There are no issues dealing with the implementation.

It's very expensive, and if care is not taken, competitions can quickly come and take over the space by offering better pricing.

We use both cloud and on-premises deployments. 

I'd rate the solution at a ten out of ten. They're doing what you need to do. They provide a roadmap, which is good.