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.

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.

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.

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.

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.

My company is a reseller, we're not the end-user. We don't have ServiceNow ourselves. We develop and we're a service provider, so we only provide ServiceNow solutions.

All areas of the solution have room for improvement. I mean, it's a never-ending thing, everything's being improved all the time. Because I'm an SME, the most important thing is the technical help that I can get, so better, more useful technical support would be good.

I also think the solution would be better if it was more intuitive.

I've only been using the solution for about six months, but the company that I work for has probably been using it for five to ten years.

The stability is about the same as other platforms. It's not better or worse than other products. It's not perfect, but it's pretty good.

The scalability of the solution is good.

It's a complex task, but the ServiceNow version is probably not any more difficult than any other platform.

You pay for the service and whatever extra features you want. If you want minimal service and don't want the extra features, you don't pay for them.

My advice for people looking into the solution would be to have a big bank account.

I rate this solution an eight out of ten. 

For one of our current customers, they have prepared the CMDB by manually importing the JIRA data from their existing infrastructure —the data module, services, servers, application servers, database, database container, and database data—and they've asked us to handle the application business. 

The customer has two repositories. The first is for modeling the application architecture. The second is for delivery management as well as integrating the data between the release control platform and our platform for business applications. And from this one, we support only the relationships between the CIs and we have produced a mapping to update the relationship between all the CIs.

In the past, when working for a banking client, we adopted two different types of deployments based on our customer's needs. The first one was improvised and the second one was in the cloud. We had to do mapping between discovery and the CMDB service BMC because they did not previously have CMDB or ServiceNow. We closed the assets activity between BMC and ServiceNow platform. 

We have thousands of users engaged in a wide range of activities around the solution, such as the infrastructure and request management team. We're working with many plugins and a lot of features.

I like ServiceNow CMDB's discovery tools. If you have discovery tools and the discovery tools are built around a philosophy of mapping, then we can implement a top-down architectural mapping of the elements in the upper structure and create your CI. We can directly map for the dependencies among your infrastructure, hardware, and software. If you do not have discovery tools, we can still populate the CMDB but for the administrator, it's very hard.

There's room for improvement in terms of integration. When we integrate a customer's foundational data, we get the core of their business from the integration. Because the process is not done through scripting, getting elected in the administrative solution can have value.  But with ServiceNow, there is sometimes an added risk for the workflow in the activity.

About five years. We started with the Eureka release in 2016. After that, we upgraded to Fiji and our most recent upgrade is Geneva. I'm not a specialist in ServiceNow. I am an IT service management consultant. I advise on all activities concerning the best practice of ETL process. I am involved in the CMS configuration. I coordinate activity between asset management and discovery within the CMDB, but the scripting on the platform is not my task. In the bank, I have offshore teams for development from my side.

ServiceNow is a stable solution. 

We have a philosophy for IT service management. When we create your infrastructure, we don't change the core. We can build an overlay on your process but we don't change the core of the process. When we update the solution, we generally update the core.  

Support is good. We have an in-house specialist, and if they have a workaround, we will use that.  But sometimes we'll still need to escalate to ServiceNow support. Generally, if we have a solution, we apply the solution, and we don't need to create a support ticket.

Before ServiceNow, I used BMC. From my point of view, BMC is the best. BMC is a solution rooted in best practices. At the moment, there are a lot of ServiceNow developers, but they have no understanding of the impact of the services. They're looking to develop a new plugin before understanding the best practices of how to use it in the short version. The solution is mature, and they have a lot of modules. Maturity comes into play when customers need to develop something. But sometimes when we develop some root system, there can be a drift on your platform. When there is a drift on your platform, the impact on the application is great sometimes. We can lose some functionality after the update. 

We use a common model— a generic collection. If you respect the common model, implementing CMDB is seamless. But if we don't respect the common model, it can complicate the relationship between CIs. However, using the common model, you can achieve a seamless mapping of the infrastructure with your CMDB.  Generally, it takes a couple of months to populate a CMDB depending on the scope. For example, we might start with the servers, and after that, we can look at the software, then the databases, and the middleware applications for application servers, networking, and storage.

It takes a long time to deploy depending on the volume of the infrastructure. It takes a lot longer if you have thousands of servers. Some elements of our procedure apply more for small businesses and others for big ones. In the bank, we have a big discovery process. We have thousands of elements in our city and hundreds of data centers. Implementation at the bank took more than a month just to activate all data in one building.

I have no idea about the pricing of the solution. Two or three years ago, they changed the model. Now you can access ServiceNow CMDB with a nominal license. Before we can gave all users an IQ profile to access the CMDB core. I think they have changed it a few times since.

If you are implementing ServiceNow or any CMDB solution, you have to start by properly sizing up the scope. We start at the level of the server and application, then look at the network. And after looking at the network, we turn to storage infrastructure. By working step by step, we can read your infrastructure to develop the topology of the infrastructure in your CMDB. We cannot start from scratch. It's not likely that we can build a CMDB in just a few days.

All in all, I would rate ServiceNow CMBD eight out of 10.

CMDB is used for capturing all the IT hardware assets and configuration items. That includes computers, servers, virtual machines, phone devices, switches, et cetera. It's for the network and the front and back end.

There is a data mixer that's called Management and Commission and Discovery. What it does is it helps us auto-populate the information directly by pinging that particular CI and capturing that information. That's a very good feature. It makes it so that we don't have to go for manual updates every time.

There is a lot of documentation online regarding CMDB.

The solution is stable. 

The solution can scale to a certain extent. 

Right now, it's a one-sided integration, which means that whatever information is available in SLCN, for example, the mixer will capture the information. Therefore, there are scenarios where some of the CIs get retired. It does not really update their status. For example, We have 10 servers. Two were retired, so they were not updating anything. For the rest of the eight, they updated information. However, for the two which were retired, there needs to be a modern option for modifying the state as well in mid-server. 

The need to work on how the Virtual Machine Centers are being discovered, and how the Cloud's CI is being discovered and flagged.

The initial setup is a bit complex. 

The scalability capability could be improved. 

The pricing could be more competitive. 

The stability is good. there are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

The solution is scalable, however, there is some room for improvement regarding the vCenter and the Virtual Machine Center, for which we are actually struggling right now.

In our organization, CMDB is used by everyone.

The initial implementation is a bit complex compared to other modules as it's really technical in the back end. The steps are clearly defined on how to do it and there's a use case library available. That said, it's a bit of a tedious process.

You do have to pay for a license, however, I cannot speak to the exact details. It's not part of my responsibilities. My understanding, however, is that pricing could always be better. 

I would advise that before a company starts implementing CMDB, they should look at the CSBM. They should understand CSBM as it is common, however, they need to understand the requirements, and how the structure should be set up before implementing anything. The reason being, there are scenarios where people put all the data into the system, and that causes a blockage, which means that you don't have to actually document every CI. A company should see what should be the scope of the CMDB, and only then start implementing it. Otherwise, it will be a lot of information available that serves no use. 

I'd rate the solution at an eight out of ten.