The solution is cloud-based. When we have a new release coming up, we have a few weeks of preparation. We don't have a straightforward test campaign.

Deployment took four weeks. 

I rate the product's deployment a six out of ten. Its deployment depends on factors such as the customer's existing backend setup and the organization of their data. For a fresh implementation, it can be fast and straightforward. However, if data migration and the creation of custom workflows and integrations are involved, it can take longer.

During the initial setup, I faced significant challenges with our partner developers as they struggled to grasp our requirements and insisted on their preferred approach rather than following our needs. Despite encountering difficulties during the development phase, we ultimately achieved our desired outcome. However, I believe that collaborating with different partners may have yielded better results.

The product's initial setup phase is a bit technical in nature.

The solution is deployed on the cloud.

The solution can be deployed in six to twelve months.

I am an expert and know how to gather requirements and complete implementations. The initial setup is not complex but someone who is new to this technology, may need assistance from an expert. The time it takes to deploy the solution depends on an organization's requirements. If they want to only implement event management, the timeline would be shorter.

We required an internal architect for implementation and one project manager to maintain the solution. We needed four ServiceNow senior developers and a ServiceNow QA for testing. For a bigger organization, you would need six people. This depends on the number of completion items. If you are using between 100 to 200 completion items, it is easier and you may need fewer people for installation. If you have more than 40K completion items, you would need six to 10 people. 

I would rate my experience with the initial setup a six out of ten, with ten being easy. Not super easy, but not super difficult either.

Overall, deployment took us a few days. It's still ongoing as we integrate with internal systems, but the core setup was quick.

It directly connects to our main database for authorization and asset storage. It's also part of our ERP system and connects to various management systems. We have a lot of systems that connect to ServiceNow.

I wasn't part of the deployment, but I believe it was straightforward because ServiceNow is a cloud-based application. The initial planning took about three months, but the deployment only took one or two weeks. 

It was pretty straightforward. It took about three months. We had to migrate our former projects from Planview PPM. It wasn't hard. We just had to make sure that everything was in there.

The initial setup is not complex.

There is a large pool of trained workforce available for ServiceNow. Considering their market share, which exceeds 60%, there are ample skilled resources in the market. ServiceNow technology has been established. I haven't encountered challenges with ServiceNow projects in terms of implementation or configuration wherever I've worked. However, the deployment can vary depending on the company and partner, and how they've structured their practice teams and training resources.

If it's a Greenfield project, then a new deployment is necessary. For enterprise customers, integration becomes the key focus. ServiceNow offers a substantial integration portfolio to address these needs.

It is overly complex mainly because it has a lot of content. There are some out-of-the-box configurations, and there is also a lot of content that is not configurable out of the box. Of course, most organizations aren't mature enough to use the additional content and additional tabs. Typically, the implementers are smart enough to deal with that, but I've worked with customers that weren't smart enough to go ahead and say, "Hey, we need a subject matter expert to come in and install this module." Sometimes, they brought somebody in to do just the bare bone install, and then they wanted to configure it themselves. 

You need a subject matter expert. ServiceNow doesn't always do it, and very often, it is third parties who implement it, but they don't do a great job of educating their customer on what they should and shouldn't do as their initial install. They just say here is the tool to some extent. You should ideally go for subject matter experts that are either recommended by ServiceNow or are directly from ServiceNow. Of course, it gets more expensive as you go up that chain.

ServiceNow could do a better job of prepping their coordinators and supporting this process. It is tough because most of the customers first need training on project management in general before you start teaching them how to use the tool. There is no lack of support. It is just not well-organized and prioritized support. There is a knowledge article for everything from ServiceNow, and all the information is there, but it is not organized in a way, especially for a new user, to say that don't worry about this. We'll get to this later. Here are the things you should worry about, and here are the things that you really should do as best practice. That's the key.

I have been advising and working with implementation teams over the last three years. Every single time, after they implemented and started using it, they started to discover things that they wish they'd known beforehand. That's why it would be good to have an organized set of best practices from ServiceNow saying, "Hey, you're implementing. This is new. You don't have a mature organization that has a bunch of requirements. So, here are the minimum out-of-the-box things that you should enable. We're also going to hide all that stuff that you don't need, and we're going to get these fundamentals working." Guided and organized best practices for organizations that are new to project management would be a huge win for ServiceNow.

It is a cloud product, so it requires just configuration from us. Typically, implementation takes two to three months, which includes all the beforehand and after closeout. You have some meetings, make some agreements, install the product, and get it up and running. Installation would take just two to three weeks, and the implementation would take two to three months because you've got to do training and everything else to truly get it in there. Most organizations also end up having to come back and do remediation that takes an additional three to six months. We're not talking about the setup where everybody is working on it. We're talking about a setup where you've got a small team that is typically working on the issues, coming up with solutions, and then implementing them later. There is usually a three-month to six-month clean-up afterward. It's not uncommon for me to see close to a full year from the first conversation to when they feel like they've got stable, usable, and good reporting coming out of the solution.

The solution’s initial setup is very straightforward.

It is a cloud solution. The initial setup is difficult. It requires someone with knowledge of the ServiceNow platform. One can take assistance from a DevOps engineer for configuration.

It takes a few weeks to complete. We have deployed it in different regions. We need to synchronize the changes across all the regions as well.

The initial setup is straightforward in ServiceNow. It's not complex, you can say it's out-of-the-box.

ServiceNow is the least complex of all of the platforms available.

When I worked at the bank they went from zero to running it within three months. At that time when dealing with Remedy or other legacy systems, that was unheard of to go from nothing to running in three months.

With one of our customers, we had it up and running in one month.

We have seven members to maintain ServiceNow. They are developers, senior developers, and the head of service management.

The initial setup is relatively straightforward.

The company was using another product before. They implemented this, I would say, within six months. It's been in place for two years now and it's matured.

I was not there for the deployment.

We have one SRM, senior relationship manager, that basically maintains the digital workspace. He's in charge of updating the versions or deploying new features. There's one person that does that.

Setting up ServiceNow is pretty standard because we want it to manage incidents and use it for other marketing, construction, and procurement areas. But, still, everything would be based on the different services we provide for their operations area. If you move forward with the cloud, I think the number of internal staff needed would be minor. It probably takes around two people to deploy and manage. In this case, we use some external consultants for all the development and maintenance.

The setup is tough. It takes a lot of knowledge and a lot of experience. So, you have to basically work with the product on an almost exclusive basis to become very knowledgeable. However, it is very powerful, especially once you have people who can write JavaScript and who can improve and make the product do a lot more than it does coming out of the box.

We have operations staff that handles the ongoing maintenance. It's not anything where we're having to pull down servers or anything. It's just managing access and maintaining the integrity of the CMDB. Everything else is just types of ITIL efforts such as handling tickets, processing requests. That's it. I find it very useful.

I was not involved in the setup of this solution. It was already in place when I started with the company.

The installation or deployment is easy because this is a Software as a Service (SaaS) solution and it is managed by ServiceNow.

They analyze the use of the tools they provide us with and they do the new deployments in a slot time when we do not use the tool or have minimal use. They inform us typically more than a week in advance and they send several friendly reminders when the cloud service has to do a change, a new deployment, or an upgrade. They are very flexible to keep the downtime of the service at a minimum and at a time that the tools are not being used.

The solution's initial setup process is easy. The time taken depends on the volume of code.

It was complex because we support network customers. They have dedicated fiber connections all around the world. It was a complex project, and we suffered afterward in terms of missing features and so on, but that wasn't because of ServiceNow. It was rather an internal issue of not allocating enough resources.

The implementation took six to nine months because we needed to prepare the cutoff. We did a pilot phase with dedicated customers, and we tested it first. After that, we rolled it out, and then based on agile, we fixed any production issues. We prioritized them, highlighted them, and we fixed them, which took another nine months. 

We had at least 20 people, but not all of them were for deployment. We have many global customers with network solutions. They are scattered around the globe with different priorities and focuses. It wasn't an easy task to gather all the information about the features that we and the customers require. We were also using two ticketing systems. So, we had to organize and then migrate.

It was deployed around the globe because there were some users in the U.K., Ireland, Germany, Hungary, India, and Egypt. So, it was deployed at several locations.

The initial setup is pretty clear. If we try to compare the implementation of some traditional modules, like incident management, request fulfillment, it's an industry standard. It's very good. ServiceNow, from a functionality and partner support perspective, has lots of materials. However, when it comes to some newer modules, some ITBM applications, et cetera, sometimes when they just release the first version of the module, and it might be a bit different from a functionality perspective. There's a lack of documentation and support. That's quite typical. I feel like Hewlett-Packard pays a bit more attention to that.

I didn't handle the initial setup.

That's a different group that does altogether. It's a packaging portion. We basically tell them if there are certain things or floor processes that we need to create. We'll create it on a front end, we'll create the diagram, the workflow, and everything else. We give it to the backend office and they'll basically make the changes as they go. They'll give us a test case scenario before it goes live, and any modification or any changes that are required. We reply back to them with the information and they basically make the changes according to what we want. From a packaging or modification perspective, it's not something that my team or I do. 

I'm not sure how many users are currently maintaining the product.

The initial setup is straightforward.

I entered into already established estates, so was not exposed to the efforts in setting up the ServiceNow instance sets.

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.

The initial setup is simple. It takes only eight hours for each resource because of integration and conversation flow.

I cannot speak to the initial setup. When I started using the solution, it was already in place. I'm not an implementer of it. I'm an advanced user. Therefore, I can't speak to how simple or difficult the implementation process is.

I didn't handle the initial implementation and I wasn't part of the team that did. I can't speak to how easy or difficult it was to implement or what the deployment process looked like. I'm not sure how long it took.

The solution is on the cloud and therefore doesn't require any maintenance.

The initial setup was fairly straightforward. I would rate it nine out of ten.

The initial setup was straightforward.

The initial setup is very easy. Based on my experience with BMC and EasyVista, ServiceNow is the easiest solution to implement.

We did have an on-premises solution until about a year and a half to two years ago, and now we're using the SaaS version. That changes features and then tools, and perhaps other things as well.

I think in some ways we probably bit off more than we should have chewed, but we needed the product to replace Altiris. We had to fill that gap because of everything it did. From a stability standpoint, it was probably on the verge of collapse. We had to put a product in place to take it's place.

We used a tiered approach. We did like five or six release cycles to get to where we are. We started with CMDB and change management at the same time and I think that that really worked well. When we were working in Remedy, our CMDB only kind of had Oracle database names and host names. Windows or Linux host names and that's it. It was pretty flat and people were used to it and it wasn't a whole lot of information to ask people to put in their change request. When we came over, we were able to stand up change and people were satisfied with just having the host names, which was fairly simple. Then we were able to do kind of a crawl, walk, run, run with scissors sort of thing. I think that it went well.

It was easy and straightforward. It's a web-based app essentially, so you get loaded onto a server, and we have twenty-four node cluster in one node. We're on primus and have 65,000 process users going to it. It's relatively easy, as far as getting it up and going and just turning the monitors on and letting people enter.

The initial setup is easy. The deployment was done within a month. 

Yes, the process is straightforward, but using an experienced services firm is best - especially if implementing the product for the first time.

The setup was straightforward, easily understandable with the training we did. There might have been some kinks but everything was worked out in due time. It was fine.

I didn't set it up, but it is pretty simple.

The initial setup was very easy.

Initially, deployment took us eight months. Once we had some experience with it, we could deploy it in four months.

As a developer and partner, most of the time the setup is customized. Right now, I'm working on a module called "Ask your HR." There are different sets of modules available and inside each module there are different sets of reports and functionalities, such as drag-and-drop, etc. It's full of customization. Whatever you're building, it has to be done from scratch. It's not like the functionality is available out-of-the-box.

We do follow certain documentation and steps. Whenever we do a migration or implementation, we check for the available system capacity. We have a team that allows us to do testing on it and see what kinds of things can be done, or how we can migrate directly to ServiceNow.

We usually don't go with a full-fledged migration, we do it in phases, Wave 1, Wave 2, and Wave 3. Each wave has certain things in it. We will plan it accordingly and, once the wave is successful, we'll do regression testing of certain scenarios and check whether it is up to the mark or not.

It depends how deep you want to go. You can use it for pretty much for anything. I wasn't involved in the implementation of it, but from a management perspective, it's pretty sweet.

The setup starts out easy but it can get complex quickly.

It is important to be prepared for yearly system updates. Normally your subscription will come with access to those new updates but you need to be ready to quickly update to the latest versions.

I wasn't part of that implementation team. I came in to really get the program together because we had our enterprise architect team implement it. However, I think the guys had fun implementing it because they were looking forward to actually getting it in place, start using it, and start deploying it. 

Upgrades through the years have been pretty tough. We didn't get the sandbox right away, so it made hard on our users where we have to do all the testing and make sure we understand the differences between out of the cloud versus what we did with custom development. That took just a little bit longer in analysis and testing implementation.

It was incredibly easy. We had the vanilla version and then we used a professional services vendor to kind of help us weed through what was there, to help us understand it, do some initial workflow set up, so it was very simple.

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.

I wasn't involved in the initial setup because it was already in place when I joined the organization.

I've heard that some of its features are difficult to implement. I've never done it myself, but from what I've heard from other teams, it takes a long time to create a full flow. It's not quite that easy.

My team did not implement ServiceNow, we do not maintain it and we do not service it. We just use the product.

I don't know what they had on the setup and the implementation part in terms of setting up servers and configuring servers and things like that. I don't know what that entails. We just know when we got it, we got a product. So what difficulties they might've had setting in up with, I don't know. I can't speak to that.

The initial setup was straightforward. They have out of the box solutions readily available, so if you're just going by the out of the box configuration, it might take a few months. Maybe a 12 week period is good enough to get it up and running.

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. 

It was very easy to set up. It was very easy to make sure things were activated.

Once you get the base up, it's easy to start to build out.

There are templates that are available, and you also have the ability to create your own.

It's very quick to implement.

The initial setup can be a little on the technical side so we are lucky we have the tech staff. Without that, we'd need to take a service provider or third party vendor to help with deployment which generally takes one to two weeks. It's important to have technical people involved in the implementation, otherwise it's quite difficult.

The solution was easy to implement as it wasn't styled out. It wasn't too complex.

Normally there is staff training near the beginning. This is not the case anymore. You can use it right away, however, it is difficult in the beginning, coming at it from a new user's perspective. That's the main thing to keep in mind. Organizations should be aware of this at the outset and plan for it.

For me, it was easy. I would say that for some individuals who are not very exposed to ITIL concepts, it can be very hard because they've never been exposed to the whole language, that whole concept, and framework of your problem, incident, and change. Most people, if they've never used ServiceNow before, continue to call incidents, tickets or calls or cases. For some of them to get used to the language, I think that that's where the implementation can get a little hard for individuals and they can get a little frustrated because not everyone is on the same language.

When a customer starts with ServiceNow, they go with it out-of-the-box, that's very easy. Just a couple of configurations here and there without any customizations. That's very easy in terms of implementation, and even customizations, it's pretty easy. It's smooth, and that's why we as product developers like the product, because it's too flexible. It's very flexible.

From what I've heard, and all I can go off of is hearsay, it was pretty easy comparatively. I don't know what they were using before for any ticket tracking system, but that's initially what they jumped into was ticket tracking. We needed something to be able to support our IT infrastructure and our service desk. They also wanted to be able to track changes, and do that. It was just like, "Okay, we'll start with this, and start growing more and more." It turned into quite a bit more. We have definitely stepped up using a lot more of the offerings that ServiceNow has, mostly because we have to, to some degree, to be able to make things a lot more efficient. It's worked for us from what I can tell.

You want to sit there and plan. You probably don't want to turn everything on right from the get go either, because then you're just going to overload yourself. The same goes with any type of a larger offering that has hooks into other aspects of your infrastructure. If you turn everything on, you're just going to get overwhelmed, and not actually have proper resources to be able to handle those. It's always start turning things on, start figuring out what the workflow is, and go from there.

The initial setup is complex because it's not meeting our needs. We're having to build a scoped app to address the inability to save contract line items and data.

The initial setup is really easy. Having a complex environment could add to the installation time but typically the solution can be up and fully operational in six to eight weeks' time.

The setup, on a technical basis, was not that difficult. But if I want to involve different businesses into using change management, it becomes a challenge to understand the process and implement it on a platform which is standard for everyone. So it's not really the technical aspect, it's more the procedural aspect.

It took us about eight months to roll out ITSM. But after that, we have had other instances where we use a custom solution, out-of-scope applications for our customer service area, and we were able to implement it within three months.

From an initial setup perspective, it is very simple. That is why ServiceNow is the market trend, compared to Remedy or compared to HPE tools. It has already captured close to 60 or 70 percent of the market. The initial setup is really very user-friendly and very easy to set up in customer environments. Just drag and drop. You really don't need any technical skillset to deploy ServiceNow at customer sites.

Deployment time depends on what a customer is trying to implement, for example, the number of modules. If a customer is going with the basic ITSM module, it does not take more than two to three months to implement that complete ITSM suite.

In terms of implementation strategy, first we try to go with the out-of-the-box features and try to follow ServiceNow guided setups, which are available on the ServiceNow Wiki. A lot of information is there. We can blindly follow that for the initial setup and for the configuration.

The staff required for deployment and maintenance depend on the customer's requirements. If the requirements are really complex and they want a custom solution, then the timelines and the staff increase, based on that. There's no standard staffing, as such, in terms of implementation. It completely depends on the complexity of the requirements and, obviously, the size of the requirements.

The workflow capability for easy setup is powerful. Combine this with automation and you have a great tool which is built on ITSM principles.

We have customized so much, so I think that might have contributed to the learning curve for me, just figuring out where the organization had put things and what terminology they use and where to look for certain things.

The entire installation process is easy and very straightforward, which consists primarily of the installation of the tool and its configuration. We are talking about SaaS, software as a service installation, meaning one which is ready for use. As such, there is no real installation work involved. 

The installation period lasts from two to several weeks. A medium enterprise would have a two week installation period and a large one would have a month. 

I didn't really get involved in the initial installation. It's my understanding that there really isn't one. In my experience, there's just a simple link that you click on and you're all set.

For the most part, it was straightforward. We were doing a bit of a transition, transformation, and concept. We were transitioning from one capability to another, and we had all those at the right touchpoints from an integration perspective. Overall, it was relatively stable and smooth.

The setup was pretty straightforward. They rolled this thing out and nobody has been swapped over from the road system is pretty seamless.

The complexity of the initial setup can vary based on the size and complexity of the organization implementing it. Including proof of concept, may take around three months or more for large companies and enterprises working in the IT department. The duration can depend on the specific modules being implemented. Setting up a data center and different management processes for seamless operations is crucial. It takes another hour or a week to complete.

We have a dedicated team to maintain the product. The team's strength depends on the specific budget and the number of requests and incidents. At the moment, we have two administrators working on deployment and maintenance.

ServiceNow is very easy to set up.

Setup is not my forte, but because we are on-prem you can imagine that the setup is very special because we are not on a standard database nor is it a typical setup such as with ServiceNow in the cloud.

This was already in place when I arrived, but they are installing the CMDB and we need the help of a partner.

It seems to be very complex.

We have one person who is dedicated to the maintenance of this solution. He is a Service Desk Supervisor.

The initial setup was straightforward.

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.

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.

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.

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

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.

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.

Very Complex, 13 companies, 9 Towers, 17,000 devices

Overall, the setup is fairly simple. You have to have a point of reference to compare it to. If I think about other cloud-based tools that I've worked with, by comparison, I would say it is most definitely simple.

Myself, being a consultant and implementing ServiceNow multiple times over in different organizations, an average implementation, which would result in a minimum viable product - standing up ServiceNow to achieve some form of business value - would be 12 weeks.

I typically see a 12-week implementation of ServiceNow achieved with approximately six individuals for the deployment. Ongoing maintenance of ServiceNow will typically involve the equivalent of four FTEs.

It was quite complex, because I'm working with service providers. They have a customer site, and a company site, so there's domain separation, where you actually separate all the data. I had to put a lot of effort on the CMDB, but now they have a great solution. The correct SLAs, they just wake the technicians at night when the customer's really paying for it. It's really pre-one incident.

It's already set up, you just have to work it out according to your needs. Just like in any other project, you need to understand your process, you need to understand how you need to improve your process. Don't automate the problem. Just like any other process, the recommendation is you either work with ServiceNow or you're work with a technology partner. I'm a technology partner and we help others with those types of things. It's really straightforward.

When we started out, we did it in phases. Our very first phase was the change management application in a very condensed version of the incident management application. Phase two rolled out in late 2014. At that point, we went to a full incident management application. We revamped our change management application, rolled out problem service catalog, discovery, our CMDB. We have quite a few, some 38, applications that are currently turned on. They were pretty basic and we've been over the years developing and expanding those.

The initial setup was not that complex. The main challenge in setting up the solution lies in the implementation process. There are many difficulties in adapting the workflow and approvals to align with ServiceNow's functionalities. Customer preferences and the need for customization may result in complicating the process further. Having a thorough understanding of the system is crucial for efficiently configuring the platform to meet customer requirements. I would rate it seven out of ten.

The initial setup is quite straightforward. Ours is a pretty large implementation, so it took approximately two weeks. This was due to the complexity.

From my standpoint it's easy. As long as you attend an event where they teach you how to do it, you'll pick it up right away, because before I attended one, I had no clue how ServiceNow worked. I went to one for three days and now I at least have, about 25% knowledge of how ServiceNow works. I guess if you attend an event, you'll pick it up right away.

It's pretty straightforward, and every now and then we have to go in and make some changes, but really it's not that big of a deal and it kind of helps us keep modernizing our stuff too, so not so bad.

Our initial setup was not the best. We had some issues with it with the company that implemented it for us. We're with a different company now and it has been just fantastic. They've taken us through the whole thing, they've helped us out and they've worked with us step by step.

The initial implementation did take a while. It was fairly complex. We engaged ServiceNow to help us with that. Our ServiceNow also engaged a business partner to help us with roll out initially. Going through that process did take a while, but we had the workshops and training in place to help make that easier.

The initial setup for ServiceNow was straightforward.

I am using it in a managed IT environment. As far as I know, it was satisfactory, but our department manager would know more.

I found the initial setup to be straightforward, and it should be relatively easy for anyone to navigate it with a little help.

I was not involved in the initial setup.

It's going to be pretty complex, but it's because we've got data coming from a lot of different sources. From what I've seen on the imports, ServiceNow isn't going to be reason it's going to be complex. They're going to make it a lot easier.

Out-of-the-box stuff is very easy to deploy but when you have specific demands then maybe of course it is more complex. For us it was quite easy because we had a developer instance already so we developed most of our products in that instance. We couldn't get stuff like the domain separation completely functionally the way we wanted it. We could develop already, so when we purchased our instance I think it took us 2 - 3 weeks to get everything up and running.

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 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 was not part of my current company's implementation, but with a previous one and their parent company, I was part of their implementations and it was pretty seamless, other than political issues.

I wasn't here when it came online.

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

I was actually not there when the setup was done so I can't answer that.

The setup was time-consuming and required a lot of internal resources. 

The technical aspects of it were fairly straightforward. We knew we wanted to change, and so never let a good crisis go unused, and so we knew we were changing products, and we wanted to change philosophies too, so we didn't spend a lot of time making ServiceNow look like Remedy, and that helped out, but what it also meant is that we hit a lot of resistance from people that had to move towards that new product, that it didn't look like the old stuff, and so from a technical standpoint, I had a top-notch architect, and he came in and he knew exactly what he was doing, and he knew how he wanted to do it, and so when we went to the customers, that was really the issue is, they wanted more of a vote, they wanted it to look like their view of how it looked, so technically? No, very easy. Politically, sort of new process, sort of point of view, it was a little bit harder, but the technical aspect's very easy to handle.

I didn't set it up for our organization, or I think my team didn't set it up, but for our instance for our group, it was seamless. The migration of data has been seamless for us as well. At least, that was our experience in our department. There's multiple departments, it's my organization. The data, the which one was the biggest one, transitioning from the old HPSM to the ServiceNow has been consistent and very good.

Actually, it's very complex. Usually, you're doing it with a partner. Most institutions have partnered with someone to help them with an implementation. How well it goes is usually on the implementation engineer or their team's shoulders. I have gone through an implementation that was just horrific and we made it work. I've seen implementations that go fantastic. You just turn a key and there it goes. I would say it really depends on the quality of your implementation engineer.

I wasn't there in our initial setup but our upgrades have been relatively painless.

It's not simple. One of the things I wish we had done is come to Knowledge before doing the implementation. You learn a lot. There's a lot of growing pains. You make mistakes of, "Oh, let’s just have this field," or, "Let's just do this to the table." You find out later it's like, "Maybe we should have done that." About a year into using it you really start feeling comfortable with it. A lot of the stuff they're doing now out of the box is usable, just right there without any customization. The biggest thing would be, "Yes, come here, go through all the training. Don't start tweaking stuff, learn it and then go implement it."

Most of our customers that we go to already have ServiceNow deployed. They have a team that manages it so I don't know how difficult or easy it is for them but they did give us an environment to work on and I think that's where we come in as an integrator with our product on it. If your question is specific to ServiceNow I really wouldn't know whether it's a problem for them to manage it or upgrade it.

When an instance is spun up, it’s ready to use. In that case, setup is very simple, but no organization wants to keep the out-of-box-setup though. Why would you buy something so highly customizable and not customize it?

If you keep your customizations light, setup is not difficult for someone with a modicum of experience. If an organization goes all out and wants heavy customization, then setup can become extremely complex.

It was pretty intense, but luckily our implementation package included getting two of us trained and ITIL Foundation certified which really got us on the same page.

Whether the initial setup is difficult or complex depends on the implementation. We have done multiple implementations, however, it depends on the product's implementation on the consumer end. It can vary from straightforward to complex.

The deployment also is product-specific, customer-specific, et cetera. It depends, for example, on the number of customers, the particular, specific scope, and which product is required, and how many users and devices that they have. All these things come into play and change how long it would take to set everything up.

The size of the team a company might need for deployment and maintenance is product and scope-specific, however, it can vary from one or two people to even maybe five to ten people, depending on which products are in scope, and what is the scope of maintenance requirements.

If the project is for the ITSM, it'll be 18 or 19 managers playing a role, and the rest being the configuration managers with other things. However, it depends on the project.

Due to some of the complexities within our organization, the initial deployment was complex. The tool itself is straightforward.

I prefer the installation and configuration of ServiceNow to that of the competition. 

The initial setup was easy. You can deploy all models together or model by model. You have different ways to work. You need to understand your customer's situations. The data is the most important part.

If you have a problem obtaining the data, the application will not function properly because you will not have all the functionalities at the right level.

The time it takes to deploy depends on the resources and the time you allocate to it, but if you put all the people, it can be done in seven months. 

I was not a part of the initial setup. By the time I arrived, it had already been set up by someone else.

We have five to eight people with various tasks to maintain this solution.

Very easy and simple to implement; a third of the time of other solutions.

There's a lot there, it's like Excel. You can go in any which direction and you got two different ways to do it or multiple ways of doing things. It was a steep learning curve for us. We went through a number of vendors until we were able to fish on our own. Now we can go to specific people and then get those targeted information. It's been really good for us to have the user groups, local user groups, the snugs, and pick the brains of other companies who are having the same challenges or working on the same projects we are. Then we can collaborate a little bit and make sure that we're doing what makes sense. It's not just us in our own little sandbox.

Upgrades can be kind of painful. ServiceNow is a great product because you can do almost anything with it. On the flip side of that, it's kind of horrible because you can do almost anything with it. The more you customize stuff, the more effort there is in upgrading to see what isn't getting upgraded because you've customized it and then to work out what you have to do.

It depends. From my perspective, it's easy, I am a system architect, and I think from a customer perspective it's easy as well. I can see a new custom application created in a simpler way, for building applications, etc. but I'm usually only using the basic functionality, which I started to work with at the beginning because it's easier and I know that I can control it. From the user perspective, I can see that they are adding new forms to configure everything.

I'm not sure. I wasn't here when they implemented ServiceNow or during the upgrade to Fuji. However, I heard it's pretty easy. The person that did it told me a little bit about it, that she sat down and then just called and was on the phone with ServiceNow. They were going over all the steps and it was maybe a couple of hours and then they did some testing afterwards to make sure that everything was running fine and that's about it.

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.

It can be both straightforward or complex. Probably one of the easiest ones that I've done was Greenfield. They didn't have ServiceNow at the time. They only wanted a project management solution. That's it. That was very, very small, very straightforward. Then I did one for a company in Australia called TXA. They do a lot of the television transmission equipment and it was end to end automating ticket creation based on an event log. A very, very bespoke and complicated event log.

It was very particular as there are a lot of concepts very particular to their business. It was very, very interesting but it was incredibly complex. They wanted as much of hands off and let the system sort it out as possible. Most implementations are fairly similar.

I think because we were so new and not knowing what the tool could do we really didn't have anybody that knew much about the product. We brought in a third party, and they had some quick starts that we used to get us up and rolling.

For the first portion of it, I know we had a lot of internal change management so it took a little bit longer but they rolled it out all at once. I think it took about six months but I wasn't here for that. We rolled out Project and Demand and we did it in two months.

It was easy to set up.

Very straightforward. It's almost point-click-done. You have to think a little bit, but that's mostly planning.

The complexity was not complex for ServiceNow, it was just wrapping our heads around it. We have over 120 different platforms and variations of those and we have probably 300 core sites, so to be able to pull together everything we wanted for our ticking system and to relate that with knowledge management was just a challenge for us to pull our process together.

Honestly, if we wouldn't have gone as far outside the box as we did, it would have been really easy. Change was actually the easiest thing that we've done, and doing the configuration management stuff, the auto-discovery, I would say that we had a great approach. We decided to go discovery by class of device, Unix servers, Cisco switches things like that, and we had a 13 to 14 week process to go - it was like September, October we began, and in December we had our CMDB pretty much good to go with our 6500 servers, workstations, and Cisco devices and it was actually functional in December in about four months. Which according to ServiceNow, is a rare thing. Not a lot of people get it that complete within four months.

I wasn't in the group when they did the implementation around a year ago and they did have a third party vendor helping out. They did push back the live date probably six, or seven times, I know there was a lot of trouble with implementing it and they didn't turn everything on initially, it was just the vanilla version to begin with. I don't know what the issues were they ran into, I just know it took some time. It was complex.

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.

A bit of both. It involved more customizations/work than we initially assumed.

It was straightforward because we had a clear idea of what processes we were implementing and how they would be (Workflow). The complex part of it is basically map your processes; implementing the tool is the easy part.

It is quite straightforward, but you need an expert. It is a specialized tool.

The setup of ServiceNow is very straightforward. You just have to raise a service request with them and they get it all setup with any plugins that you request for it. So far, I have not experienced any issues.

I wasn't at the company when the initial setup took place, so I can't really speak on that. As far as upgrades go, it's pretty straightforward. Doesn't take too long and generally goes smoothly.

We will eventually upgrade to Helsinki. I guess we can do it now if we wanted, but we just switched everybody from Fuji to Geneva and getting everybody used to that. The UI hasn't changed a whole lot, but one of the sessions coming up [at Knowledge 16] is the Helsinki features. I'm going to take a look and decide from there whether we should push it quicker or not.

I wasn't involved in the implementation so I can't really say but I don't think it was that difficult. I've not heard any complaints about it, or about the upgrades either.

If you aren't very familiar with ServiceNow, I would recommend bringing in a vendor for deployment. They will help you understand the tool and make sure you aren’t boxing yourself in with the way things are built out. The OOB processes ServiceNow offers are all based on ITIL standards so theoretically there aren't a lot of customizations you should need to make up front.

ServiceNow comes with a lot of functionality included as baseline implementation. For example, all main ITIL processes are implemented, as well the fact that it is a cloud solution gives you the whole functional system at the beginning.

It was very straightforward.

It was very straightforward and to the point, since it's very intuitive and easy to deploy.

We just did the Fuji to Geneva, and there were a lot of issues. I think it was because we've done a lot of customizations on forms, adding things, and what-not that broke when we moved to Geneva. The other guys who have been there for longer have said it was pretty difficult in comparison to the other upgrades.

Ours was very complex. We had several issues because we were not in ITIL shop, and because we were not only changing our tool but really changing the culture of the way we had done things in the past, there was a lot of push back. Having them come in and having ServiceNow's help was good since they did a great job. It wasn't easy, it was kind of a struggle. We did have some issues where we kind of hoped that the vendor that we had brought in to help us with the implementation would tell us what industry standards or best practices were. We didn't see it, we were missing some of those pieces. That made it kind of hard. We also had an executive turnover in the middle of it, so that doesn't help.That hindered our implementation. 

My suggestion to people would be to come and learn about the tool and learn about everything it can do before you make any decisions and before you start your implementation, because if I had to do my implementation over again I would change what I was trying to do. Like we implemented three pieces, or one piece, that really wasn't very helpful and I would have rather have tried something different.

The initial setup was quite straightforward. We deployed internally with some assistance from ServiceNow who carry out the maintenance. 

The initial setup was straightforward, but we did some core customizations. Therefore, we did need more time to finish setting it up.

It's straightforward.

It's pretty straightforward. We worked with a partner, Logic Callus to help us get setup. We had a hard date because we were coming off of an existing cloud system, so we had to really push hard to make it in that time frame, but we were up and running incident change, problem, and service catalog in two months. Basically what we had allotted for. It was pretty seamless.

The initial setup was straightforward. The only complexity was in the business requirements given by those trying to customize it to do something outside of the native configuration.

The setup was complex due to country dependencies and integrations.

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.

I was a consultant previously, so the initial setup is pretty straightforward, plus you have an implementation partner there to help you take your business requirements and configure it in the system

The implementation process is straightforward if you stick to out-of-the-box settings. If you trust ServiceNow has configured their out-of-the-box settings, then stick with them and their processes and the setup is very straightforward.

The amount of time needed for deployment depends on which part of the solution you're deploying and for what scale of the customer. If you think of ServiceNow as 100 applications, if you're just deploying one small application out of 100 for a very small customer, it could take a few days. If you're deploying 50 applications around the world for an enterprise customer, it could take 1,000 days.

It's difficult to say how long it takes as it depends upon the complexity of the number of applications and the customer requirements.

Typically, you need one person to deploy it and one person to manage it.

You need a good technical consultant, a developer, and you need somebody that has project-management skills, and you need somebody with business-analysis skills: somebody who can interpret the business requirements and translate those into the configuration. 

A project might require lots of different roles, however, one person may be very skilled. He might have some development skills and project-management skills, and he is good at asking the right business questions. In the smallest deployments, one person could do all those things. However, in the biggest deployments, you will have a dedicated project manager, dedicated technical architect, dedicated developers, consultants, dedicated business analysts. There are lots of roles that need to be covered in a deployment, depending on the size of the deployment. One person or several people might be necessary to cover all those roles.

I thought that the initial setup was complex.

I didn't like the design that was given to us and we had very little say on how we could customize it.

The initial setup is easy.

It has a medium difficulty level. It is not straightforward, and you need experience. If you are a beginner, it can be a very big problem. If you are experienced, it should not be a problem. 

It takes a couple of weeks to get it fully going on the platform.

The initial setup is not overly complex. It's quite straightforward and very simple. We didn't have any issues.

Our deployment took about four to five weeks in total.

I'm not exactly sure how many people in our organization actually handled the deployment or cover any maintenance required.  

This is a SaaS product. The customization and development of custom apps bit time-consuming.

It was straightforward and quite easy to deploy.

Depends on the requirements, of course. It was easy. It was good to develop something. If you try to use out-of-the-box functionality and your customer likes it, then it's okay. We also have huge and complex customizations, but they are working.

The initial setup was complex. We had to add some consulting services behind the scenes to build up the ServiceNow environment. The deployment took four months.

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 time it takes for the implementation depends on the customer requirements. Sometimes it will take longer. The out of the box configuration is easy and simple.

The initial setup is more or less straightforward. The deployment took around 30 to 40 days.

The initial setup was of medium difficulty. Though it wasn't the most difficult setup, it could have been easier.

The initial setup is very easy to get started, but it gets very complex as you move along.

There is no installation involved, as it's in the cloud.

The initial setup was pretty straightforward for me.

I was not a part of the deployment process. By the time I started a year ago, the technical team had already deployed this product.

The process of loading everything into ServiceNow is very straightforward. It is not complex.