ServiceNow CMDB Reviews

ServiceNow CMDB is not being used that much in the company. It's being used by customers, and mostly 90% are enterprise customers. The tool is used by many for IT assets, for example, PCs, printers, and applications. It's not just used for trouble ticketing. ServiceNow CMDB is used to manage the entire IT asset.

As I work based on the IT governance framework, what I like best about ServiceNow CMDB is ITSM, so incident/service request management. I also like that it can be useful for project portfolio management.

An area for improvement in ServiceNow is the reporting because there are reporting features that would be better when done within the platform, rather than having to buy the performance analytics model. There is a greater difference between the dashboarding that you can do from the platform versus what's on the performance analytics model. Some of the features currently available within performance analytics would be good to have within the platform because sometimes, customers will say that the tool is okay, but it's not enough, so you'll need to go with the performance analytics model, and that's costly.

The problem is that paying extra for performance analytics costs too much for what it can give back. Customers don't need the entire functionality delivered by performance analytics, but the default functionalities within the platform are not enough. There is always a trade-off. Customers are not getting value for money paid for the performance analytics model because they don't use the whole set of functionalities, and that is the problem.

For the time being, there isn't an additional feature I'd like to see in the next release of the tool.

I've been using ServiceNow CMDB for six years now.

ServiceNow CMDB is a very stable solution.

Technical support for ServiceNow was perfect. They provided a very high level of support.

The market sees ServiceNow as the Ferrari in terms of pricing. It's at the very top, and its cost is very, very high. If a customer is considering an alternative platform due to pricing, so I looked at Jira. It's clear that ServiceNow provides much more, but sometimes, you need a trade-off between customer requirements and what's on the platform.

If customers were to switch from ServiceNow to Jira, it would be because of pricing. Feature-wise, the two are almost equivalent. Everything you find in Jira, you can find in ServiceNow, but not everything you find in ServiceNow is in Jira, especially in terms of flexibility. One of the key points of ServiceNow is that when you want to downscale and you belong in a smaller organization, it becomes too costly. Pricing may change more in ServiceNow and ManageEngine, for example, but not that much in Jira. Downscaling in ServiceNow for a smaller organization is too costly, so they need to create a shrink-wrapped package specifically for smaller organizations, rather than delivering too much and costing too much.

On a scale of one to five, with one being the worst pricing, and five being competitively priced, in particular, not cheap, but competitively priced, I'm scoring ServiceNow a two because it's very expensive in the marketplace. If they can make some changes to their pricing packages, it would be much better.

I use ServiceNow CMDB, but understand that I work in a delivery company, a service company. The company drafted a partnership with ServiceNow six years ago and is still a partner, particularly a premier partner.

I'm giving ServiceNow CMDB the best score, ten out of ten.

We are just capturing all the services in CMDB, however, we can use that as a part of the change, incident, or problem management. We are just keeping configuration items like hardware and cloud resources like AWS and other infrastructure as on-prem cloud infrastructure. 

The way the CSDM model we have implemented works is great. They provide good structure and offer excellent services right out of the box, without the need to configure it. 

Our committed CMDB is now growing. Earlier we had only the probes and sensors.

The product is growing a lot and adding in lots of great features. 

The initial setup is pretty straightforward. 

The reliability is excellent. 

The scalability has been excellent in the past.

Technical support has been quite helpful. 

The different tables are available in ServiceNow CMDB are quite good. We don't need to create many custom tables.

ServiceNow is providing the frame only. Whatever you want, you can put it into the frame.

There is some customization we need from the customer side. 

In some cases, we are having issues. 

I can say one experience I had on the VMware side when we are using the change management we had to select from the VMware CI in the change management configuration items. A while back, we were having some issues with modifications and we tried to reach out to support and ServiceNow. They have some limitations on helping us. Apart from that, everything was allowed in terms of us modifying based on the requirements from the customers.

I've been working with the solution for the last five years.

The solution is very stable and completely reliable. there are no bugs or glitches. It doesn't crash or freeze.

We've scaled in the past. I can remember when I was working with a British Telecom - one of the largest in the UK - and, at that point in time, we had to implement a lot of scripts. We added based on the requirements from the customer. It's the scalability is there and we can modify many things based on our needs.

In terms of users, for CMDB we have six resources including one delivery manager, one architect, two developers, and one admin.

We are always continuing to expand the solution.

The solution's technical support is excellent. We can create a ticket and, in a matter of hours, especially if it is a high priority, we will get some sort of response within hours. We're quite satisfied with the level of support. They are extremely responsive. 

We have one customized database on BMC Remedy. I went for only one year with the BMC Remedy Configuration Management Database, then I just switched to ServiceNow.

The initial setup was straightforward. It was not overly complex. A company shouldn't have any issues with the process.

The solution does require maintenance. This is due to the fact that, on daily basis, CMDB is populating with some automated processes like Discovery and Service Mapping. Sometimes some issues come up and some matters are thrown due to some dependency on credentials or access for admission. On that basis, as a part of the team, we need to take care on weekly basis by looking at the list of retractors or the history.

We as solution consultants and architects are already maintaining it. We go through all the processes and we build some reports and the reports are taken care of by the admins on a weekly basis. The headache of the reports or the issues is completely on the admin side. If some issues come up, then the admin takes care of them.

I've never studied the ROI as I'm not at that level of knowledge with the company to get those kinds of details. 

We pay for licensing on a yearly basis. We find the pricing to be reasonable. If you need certain customizations, you may need to pay extra for that.

I did not evaluate other options. 

I'm just a customer.

I'm using the 2.0 version now. It's my understanding that they have a 3.0 version out as well. 

I'd recommend the resolution to other organizations. I already have in the past. 

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

When I was a student, I worked on a prototype for an app, and my main tasks were directly in CMDB. I had done a synchronization implementation to retrieve inventories from Excel files and put them into CMDB with automation.

I also used it in my previous company. This company is a supplier of ServiceNow for several clients in Canada and the USA, and we did a lot of customization and configuration for the clients. We worked with all ServiceNow platforms and not only with CMDB. If you want ServiceNow within your company, you've got to find a supplier or go with ServiceNow directly. 

It was on-premises, but ServiceNow is cloud-based. It is software as a platform. 

It helped us to synchronize some of the files containing the inventory of assets. 

The most valuable feature of ServiceNow is the user interface because you can customize or configure it directly from the user interface by using the mouse. It is easy to use even for non-IT people.

You can also directly plug your ServiceNow instance within your Microsoft Active Directory and then retrieve all your users and groups. So, you can use the users and groups to put automation inside the application. When you have new hires, you can automate the group security and group attribution.

It is very good in terms of performance. Its performance is almost 100%. Once, it took less than two minutes to back up and run an instance. It has very good reliability.

They can improve the mobile application and the TGO tool, which is a built-in tool for development and implementation. As a developer, it is very frustrating to configure or customize the mobile app. In my opinion, this part of the application needs full rework and re-engineering.

I have been using this solution for three years.

It is stable with very good reliability. Its performance is almost 100%. ServiceNow has very high standards.

It is very scalable. You will be able to scale it irrespective of the size of the infrastructures. It should work with really big IT infrastructure. You can adapt it for every kind of infrastructure. You can work with Windows infrastructure as well as with Linux infrastructure. You can do pretty much what you want with it. However, you can't do any implementations that are not ITIL compliant.

In terms of users, you might have an IT project manager, user services people, supervisors, and contract managers. ServiceNow provides Service Catalog to add every user of your company. You will add them into CMDB as assets. The real users are only the IT people of the company who have a license to use the backend.

Its usage is growing, and it is being used more and more. When I worked with it for the first time, I was not aware that you can also manage contracts with it. For me, it was just an ITSM solution with CMDB workflow, etc. In the last year, I have seen clients saying that they would like to add the Contracts module to manage their contracts within the platform. It is being used more widely now because you can do contract management and service catalog. You can also do IT support within the platform. It can be used as a ticketing tool.

I have interacted with the technical support of ServiceNow only twice. It is very easy to contact them. You log into the client portal, and you can send them the query or request. In my previous job, I was kind of providing support for our customers, and the company I was working for was kind of an interface between ServiceNow and clients.

It has a big community, which is a very cool thing about the ServiceNow platform. There is a lot of community and developer information. You can open a ticket directly with ServiceNow to ask them for new features or new releases, and they do respond.

It is really easy to deploy and add features. There are two ways of adding features inside the platform. You can go via their own built-in tools for developments or via the repository store. Basically, when you first start making changes inside an instance, there will be a tool to capture the modifications. When you are done with the modification, you close the repository and deploy it to the next instance. For instance, you would have one development instance, one pre-production instance, and one live or production instance. After you make a change in the development instance, you close the development repository and upload it to the pre-production instance. After that, you can do quality assurance, and if all is good, you can just deploy it to the production instance. It is really easy to work with.

Once you have your license, you can deploy it in five minutes, but it also depends on whether you are moving from an existing system to ServiceNow. In such a case, you will have to move your assets from your old system to the new system. I don't really have the experience of doing this, but, from my point of view, for a company with 20K employees, it will take eight months to one year to plan it and achieve it. There is a lot of work that you need to do before deploying it.

For its deployment, you would need an ITIL expert because ServiceNow is built around ITIL. You would also need a ServiceNow administrator, and you might require a project manager depending on the size of the enterprise.

In terms of maintenance, you don't have to do anything because all updates are mandatory, and they are deployed by ServiceNow. When you purchase the ServiceNow license, you agree to them updating it. You can choose the date on which you want to update. They don't force you to update it at a fixed date unless there is a security failure or a big issue. They send an email to your ServiceNow administrator or a message on the portal. You can then choose a date. They take care of the update, and you don't have to do anything. However, if you're located in Quebec or Canada and you are dealing with both French and English UI, you may have to do some maintenance after each update. Every time I saw an update, I had to deal with a problem related to translation in French, but it happened only in Quebec. I did not see this in France, and I don't know why.

I'm not 100% certain. My boss, who was kind of a ServiceNow director, used to think that we were making a profit with the solution, but I don't think it was a direct financial profit. It was more in terms of becoming more efficient. For instance, the whole user service department worked better with this platform.

It is really expensive. I don't know actually how much it costs, but in 2016, when a client decided to move from an old solution to ServiceNow and had to choose a supplier for ServiceNow, I had heard that it could cost $10 per hour, which is really expensive. 

I am not aware of any additional fees to the standard licensing fees. There is no standard ServiceNow solution. When a company wants to acquire ServiceNow, they already know which module they will choose. In a basic package, you would have Service Catalog, Incident Management, and Change Management. These modules are usually required in an IT company.

I would advise others to go for it. I would also recommend having at least one ServiceNow administrator in the company who is certified. Its certification is not very difficult to get. If you have an IT degree, you can go for it very easily.

I would rate ServiceNow CMDB an eight out of ten in spite of the fact that it was a bit frustrating to work with as a developer.

I'm looking at ServiceNow from the standpoint of things like technical services, business services, mapping, deployments, rolling up inventory to those mapped deployments, and doing application services, which takes your inventory and spreads it across all your instantiations.

We are more oriented toward cost control and multiple instantiations of the same product across multiple locations; basically, multiple data setting environments to thousands of deployments.

We'll deploy to our customers and host their equipment. Our customers subscribe to our equipment and we sell our software, but rarely do we sell our software. Basically, our customers pay us monthly to host their software and keep it updated. Our huge customers, companies like Bank of America and Wells Fargo kind of huge, get us to host their equipment. Otherwise, for smaller clients, run on our ASP configuration.

ServiceNow CMDB is just something that you could track everything on. For example, I can service a company with 50,000 employees with hundreds of thousands of servers.

ServiceNow was a platform that they wanted to sell as a development platform, but it didn't have a lot of traction there. So, they basically built a ticketing system because Remedy was a sad environment at the time and they built the next great Aon. ServiceNow is basically a go-to when it comes to Remedy and ticket management. The idea is that CMDB is to track all your assets, how you handle them, how you back them up, how you secure them, and which agents you have on them. To be able to do all that, keep it in the CMDB.

There are areas that could be improved, but that's a longer discussion. It all depends on what you are looking to do with it and then it becomes an issue of how do you configure the CMDB accordingly.  If I were to make one set of suggestions it would be how we defined deployments which would link back to instantiations.  Deployments would need to handle varying degrees of customization and granularity that integrate with Application Services and Business Applications.

I started dealing with ServiceNow back in the days of version D, which was seven years ago. I'm now on version P.

It is stable as hell, but it is always about what are you trying to do with your CMDB to make your company a quicker, faster, and more viable entity in your work or industry.

The initial setup can run anywhere from complex – meaning that you're doing contract management and looking for contract renewals and SLA achievement across contract structures – to just making sure your server has backup.

We do a lot of stuff around Mapping. We do Discovery. We do Identification/Reconciliation rules. We do the Transforms and stuff like that. Then, we validate the CMDB Health dashboard and stuff like that. That's predominantly the main work that we do around the CMDB and the data ingestion kind of stuff.

I work for a client and we find CMDB pretty useful as it's being leveraged across the board for all other service management practices. When I say service management practices, I refer to the incident, problem, change management, et cetera. The content in CMDB is pretty useful for us as that's the basis on which many, many decisions can be made. We go right down to the extent of leveraging the application portfolio. We leverage stuff like this to go back to creating files and figuring out which business service is impacted as a result of which CI. That is at its most basic level. We leverage the Discovery to ensure maximum availability and CIs are discovered, preventing manual ingestion. Our Identification/Reconciliation rules help us in affecting and understanding duplicates, and correctly remediating them, and making sure that we are on the right track. The out-of-the-box rules set by ServiceNow are great. The better we blend into it, the better it is for us.

Service Mapping is very useful. We found the APM, which is also part of the configuration, to be helpful. The APM has been pretty phenomenal. 

Portfolio management is very useful for us. The Discovery aspect is great. 

The performance analytics and the health dashboard are amazing to work with. 

The CI Class Manager and its stuff around it; the IRE rules, the Integration/Reconciliation, the classes which are in there in the CI Class Manager are all pretty useful as well.

The data presidencies are pretty useful to me. The Reconciliation Engine appends to it. 

The CMDB Health results, which have been configured by ServiceNow are used out-of-the-box are great. It's pretty useful to us.

We also use a lot of service associations, which help us to do the top-down mapping and understanding of end-to-end aspects if you want to have a chronological view. 

Most importantly, I think I can see the CMDB of ServiceNow aligns very closely and very well with the CSDM model. 

There are costly changes here and there. For example, it becomes difficult for us to identify the volume of patents. What we do is we fundamentally de-market and compare against the best and to another product that we were using before, which had some features that we didn't. For example, we use BMC Discovery. BMC Discovery has heaps of patents written using the TPL. BMC Discovery is a primitive tool and it's been in the market for a while. You would expect a lot more packages to be there. In ServiceNow, we are not there yet. It's less mature. 

There should be a few more classes here and there. For example, there are people who keep talking about Apple devices. They need to be taken into account, and they are not. Sometimes, we have certain rules and regulations of CIs and how we can pick up only those CIs which are operational to a change and describe non-operational ones. When you work with load balancers, when they're off, they obviously go into a non-operational mode.

We, from a process side, need to understand certain areas where we need to blend in. I would think that, for example, Network Gear would be a separate class under the config item parent. However, now, it's come under the hardware. That makes sense. 

I see the table called serial number that should be a lot more efficient and maybe that's the way we have configured it. That's where we are doing a shabby job - our duplication rules were on the serial number and the serial number table. The serial number table itself is a volatile table that keeps fluctuating from time to time. Things like that have to be eventually delivered. They keep coming, they keep coming. 

I don't think there are any pain points. It's just that we love to understand from a process perspective where we need to rectify ourselves. The tool is made a little differently and we need to figure it out. Our process cannot be stubborn and say the tool has to blend with the process. As an organization, we are very strong in our process. We expect the tool to cater to us whenever we tweak things and mess them up. However, when you tweak something, you need to be able to go in and clean it up and not think it will sort itself out. You need to put a patch. However, if you put a patch on a patch on a patch you've entirely screwed up the tool.

The tool has given you the provision to do the customization, however, you need to be strategic about what you do. You need to be careful in terms of writing. When you say SCCM is a secondary source of truth, for example, you need to be sure what activities you want from there. If you have multiple tools that are going to ingest data into the CMDB, you need to be careful of what rules we write to ensure that they fall in place. 

We've been using the solution until recently. We used the solution in the last 18 or so months.

The solution is very stable. ServiceNow is the way forward for many of us. I would just work on BMC Remedy as well, however, I've not been impressed as much as I'm impressed with ServiceNow. ServiceNow is definitely a lot more advanced. It's a lot more flexible and it's quite easy to use unlike BMC's product, which is pretty sophisticated. The Discovery is a little more complicated. If you want to understand how mapping is, it's all confusing in some places. They even recommend the SAAM and the CAM mapping. Whereas in ServiceNow, it's pretty straightforward. The complexities are not there. 

The scalability is phenomenal. It's expandable, for sure. It's quite easy to do so as well. I've seen its integration with a lot of tools. We integrated it with analytical tools like Qlik Sense for various reasons. They are also integrated with tools like SCCM. We integrate pretty smartly and pretty extensively. It's scalable due to the fact that we can take and look at other modules which are the add-ons from ServiceNow itself, such as performance analytics, asset management, and whatnot. 

We have all kinds of users, from the bottom to the top, from the business owner to the business managers. We have business users. We have the technology users. Then, we have the IT users themselves. Across the organization, we definitely can say we have around 25,000 users. At any point in time, concurrent usage could be up to 10,000, for sure. 

ServiceNow is our single source of truth. That's the single service management tool that we're using right across the board. It is definitely being used extensively. We have plans in terms of extending the usage. The expansion may not be until we plan to acquire a new organization or something. Otherwise, now, it's pretty good.

It took us about six months to set everything up, however, that's the organization. They're looking at a truckload of CIs in the CMDB. They're looking at about seven to eight million CIs, and therefore it was not going to be that straightforward and easy. It took us about three to six months due to the sheer volume. On top of that, we had our own organizational change that kept happening parallelly. People kept moving. People kept coming in. However, with something like this, it's all expected. It's part of the exercise.

There was complexity involved in the implementation, however, I can't blame it on the tool. Our thinking wasn't right. We didn't have the architects with the right frame of mind to put things together. The tool was in place. It's that we needed to know how to use it that held us back a bit. We needed to go and ask ourselves: "How do we use Discovery? How do we leverage on Mapping? How do we do things parallelly? What about other data? What about archive data? What are you going to keep? What are you going to flush out?" All those things, we needed to put in place. 

We had about 15 to 20 people on the implementation process for six months. We have to do some structural changes in the organization as well. At the same time, we weren't blending it into HR. We were blending into an HR framework, so we were restructuring the organization in a one-sided way. That's possibly one of the reasons why it took a little bit more time to get the whole thing fixed.

During implementation we did the configuration. Parallelly, we started the incident, problem, and change management. It was a full-fledged implementation across the entire organization and it was done together. It wasn't like incident first and then change second, and problem third or something. We did all of them together.

The solution does require maintenance from time to time. I'm not involved personally in that. I use only one part of that whole thing. There are people who do the maintenance for the entire solution. There's actually a team that's full-fledged and on maintenance. 

I really do not know much about the pricing and licensing package. I'm not on top of that. It's no a part of the solution I directly deal with.

We are partners with ServiceNow.

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

I'd advise other companies that, when you start using the tool, first, of course, you should have an architectural understanding of your organization. You need to have an understanding of what is it that you want to achieve, and an understanding of the end-to-end setup from the business to the end infrastructure layer. You want to know what you want and what you don't want, and have that well-built, and have an architectural view, and understand where your data comes in and how it comes in. CMDB can't help with that part. 

Don't go and expect the CMDB to do all the magic for you. You need architectural brains to blend in with the tool and that's how this whole thing works. CMDB blends very nicely if you have the architectural brain and if you have a logical understanding of what you want. Don't expect the tool to do it for you by throwing in junk and saying, "Yeah, do it for me."

If you have this, you have a good process in the works already. You will be able to blend in with asset management. Config and asset work hand in glove as a second function. When you know how these two blend with each other, you know what the architectural view is, and if you have the right people and the right sense, the tool will help. If your base is weak, I don't think the other process will work at all. 

If you really want to go down to the topmost to the bottom-most level, there are a lot of people on the business side who swill say, "I don't understand my application landscape. I don't understand this. I don't know why do we have so many products. Why do we have this? Why do we have that?" People don't understand. However, if you have a CMDB in place that actually manifests what the entire application landscape is, it's on top to bottom very comfortably. If you don't have CMDB, you'll regret it. I have seen many times it just cost the organization real money not having it in place. There has been financial loss, revenue loss, et cetera. 

I've realized that if you have a good full-fledged CMDB, being involved in understanding what causes problems is not very difficult. You don't have to go searching. You can look at the devices. You can go pinpoint. We can narrow the search. What it means is we can enable faster resolutions. Obviously, you can have better and higher availability.

That's the impact of a good quality CMDB. Traceability is good. You're able to pinpoint to the bottom-most of the problem. You know where to go. With CMDB you no longer say "I don't understand my IT landscape. I don't understand why we have so many applications. I don't know what we're doing." In a split second, you can actually go and say, "You know what? There's a network problem, and I know that the glitches. Please go look at it." You can go right down to that level very quickly.

That's the advantage of having good quality CMDB. Good quality CMDB equals good quality data, which equals the ability to diagnose and sort out issues. 

We use CMDB as a core solution for storing objects. You can still use your server information, your network information, all the characteristics of an infrastructure object, and use CMDB. We use it to provide reporting, change in management, and so forth.

The centralization in general is great. You get one version of the truth when you have a CMDB because it's all centralized.

You need to perform additional planning because their recommendation is not to add columns to the core tables. Their recommendation is always to add related lists, which is the best route to go. From an improvement standpoint, I like it because it can even maintain your upgrade pattern, but in some cases that may not be applicable. From a processing standpoint, a development standpoint, their processes of building the related lists is okay. It can be done right now; you just have to kind of think forward and you should make sure that people do it that way.

Every interface goes through updates and modifications. So right now, ServiceNow overall, in regards to having multiple screens open at the same time, you can do it, but if you try to go back, it loses its reference point as it uses a browser-based model as opposed to a tab-based model — it's window-based in other words.

I have been using this solution for roughly three years.

Where we are right now, it's pretty stable. I mean, every system has its issues, but for the most part, we've had good success with it.

It works fine. Integrations have been pretty straightforward. There is a high level of functionality when integrating with third-party systems.

The tech support has been fine — I've only had to reach out to them a couple of times. We kind of have a round table and communicate with one another when we run into a real bug, but it's on rare occasions that we have to contact them. 

It's somewhat straightforward — If you've gone through it enough times. It just depends on your infrastructure and how you have it setup. 

In regards to deploying it, there's always planning involved — sizing up your systems is always a key factor. If you know your organization, you should have some reference of how much space you're going to need. Then, if you have your growth plan laid out, you should know, "Hey, I need this much space." 

It's a good tool when it comes to RTSM, I think it has a lot of great functionality — planning. The biggest thing is communicating with the user base. It may sound a little cliche, but you're going to hear people complaining, "It's not like what we're used to." Well, we wouldn't be switching if the old situation worked. You need to get everybody on board and say, "Hey, you complain about this, this tool has that." You need to get them involved early. The sooner, the better, as far as testing, and training. Whoever signs the check is fine, but they're not the ones who are actually going to use the system. You should buy into the user community right away or near the beginning.

On a scale from one to ten, I would give this solution a rating of eight.

We use this solution to visualize the performance of all of our operation via a table that shows all of our critical surfaces.

We like that this solution allows us to easily track the relationship between our CI and the IT asset module, for troubleshooting purposes, or to check the impact of an incident site.

We would like the solution to be made more easily scalable in future updates.

We would also like to see more flexible pricing models made available that are tailored to usage.

We have been working with this solution for nearly four years.

We have found this to be a stable solution during our time using it.

This solution is scalable, but not easily.

The initial setup of the solution is straightforward as long as all of the requirements have been decided up and detailed beforehand.

We would rate this solution an eight out of ten.

We are using it as the foundation of the ServiceNow platform. It allows you to mature other processes such as ITSM, ISAM, and security operations. It is a SaaS solution.

It has allowed us to reduce the number of outages and the duration of outages.

It is a dependable source of data. If I want to understand what technologies are used to deliver certain business outcomes, this is what I would use. I can know that this particular server is being used to deliver this business application or business service.

There are some gaps in the technologies that can be solved. Operational technology isn't quite 100% there yet, but I hear it is on the roadmap.

I would also like it to be cheaper.

I have been using this solution for five years.

From a technical perspective, we've had no issues. A lot of it comes down to just making sure that the processes are being followed properly, which is a process people's problem rather than a tool problem.

Being a SaaS-based product, it scales with demand. We've had no issues on that front.

It covers a lot because we do employee self-service. We probably have over 300 users. They can be anything across IT because anybody who is interacting with the service desk is going to go through this solution, so everybody in the company has access to it.

In terms of increasing its overall usage, we identify any chances to bring it on board. We use it, and we have also got customers for our CRM to leverage it. We've basically got a philosophy of looking to identify whether they can be on the ServiceNow platform before moving in a different direction.

We contacted them occasionally when we come across some form of bug or something. They've been quite responsive to the issues that we've had and helped us in moving forward.

I'm not certain about this organization because it was here when I came on board. At previous ones, they had HP or BMC that were replaced by ServiceNow.

Essentially, it was about collecting the right data to store in the database. So, it involved understanding what it is that we cared about, identifying our use cases, and driving the automation to be able to collect that data and store it in the right place. I worked with the security teams to get the access that we needed at various endpoints to be able to allow the tool to function. To get it fully up and running and operational took about ten weeks.

We used professional services to get it off the grounds, and then from there, roles were defined for the responsibility to be applied. It was a part of their job to ensure that it is performing as it should.

It requires participation from the network team and the security team to allow the tool to function. After that, somebody is required to adopt the role of a configuration manager or process owner. 

In terms of the number of people, five or six people were involved, but some of them were only for a handful of hours or for escalations. The security administrator and the network administrator were required quite a bit upfront, and then from there, they weren't involved as much.

It has provided the ROI. The consistency of processes has given dividends. Previously, you couldn't scale by just relying on emails and conversations to understand what tasks were being done. It gives us the transparency of everything that is being worked on. We have the whole audit trail as well as all tasks that are being accomplished.

I would like it to be cheaper. If you've got a large environment, it can get quite expensive quite quickly. You still get a return on investment, but everybody has a tight budget.

In terms of licensing, everything is pretty much known upfront. Being SaaS-based, there are no real additional gotchas that we came across.

I would advise others to try to remain as out of the box as possible. It is built for the solution that you're going after. I see a lot of people who try to make it look like their previous tool, and they were leaving that previous tool for a key reason.

I would rate ServiceNow CMDB a nine out of ten. There is always a little bit of room for improvements, but so far, it is much greater than what we had previously.