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.
