ServiceNow CMDB Reviews

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.

I am with a consulting company that implements the tool. I am working to implement ServiceNow in different areas such as SACM and software asset management. CMDB is the underlying database, and I populate it with the data from the clients based on their input and needs.

It has helped in tracking hardware and software and reducing overall costs.

When running large queries within the system, it does have a tendency to bog down the system. This is something that should be improved. I would also like to see the HAM Pro module beefed up a little bit and integrated better into the SAM Pro module, which seems to be pretty much on the roadmap.

Its pricing is pretty complicated and always fluctuating. Its pricing should be improved.

I've been using this tool for about seven years.

It is stable.

We do customizations for clients all the time.

For the most part, I would probably give them a nine out of ten. They are quite responsive.

Its initial process was very complex because there were a lot of customizations. The deployment took about six months.

In terms of the implementation strategy, we followed the standard waterfall methodology. Basically, we stood it up, did all our work and development, and pushed it to production.

It is always fluctuating. It seems to change every six months. Every time they come out with a new iteration, it changes. It is pretty complicated, and they should improve it.

I would absolutely recommend this solution to others. I would advise making sure that they know what they want. The biggest problem that we run into is the client not having a direction in which they want to go, or they don't have a use case to start with.

I would rate ServiceNow CMDB a nine out of ten.

The solution has a single database, architecture, and data model. 

The tool is not user-friendly. It has a lot of features and you can get lost in it. 

I have been using the solution for six years. 

The solution is stable. 

There are about 250 users for the solution in our company. 

The product is pricey. 

I would rate the product a nine out of ten. The solution is easy to use. 

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. 

The support of the whole infrastructure is one of the main features that makes ServiceNow CMDB suitable for every type of company. It integrates with all other modules like change, business management, HR, and customer service management.

Whenever there is an issue on statuses, you can quickly resolve it.

The initial setup can be very bad if the roadmap is not set up properly. You need a specialist to help you set up the roadmap.

I've been using it for almost 8 years.

Most of the customers have the cloud solution.

It's a very stable solution.

It's very scalable. You can start from a very small size and grow. You can configure, customize, etc.

ServiceNow moves very fast to fix any problems. I would rate their technical support at ten out of ten.

Positive

CMDB is like a journey that requires a specialist's help to build your roadmap. If you get the right resource to build your roadmap, then it's very easy to launch, depending on the process of the company. If it's not properly set up, then it can be very bad.

ServiceNow CMDB is an excellent solution, and I would rate it at ten on a scale from one to ten.