Overall Satisfaction with ServiceNow
ServiceNow is a Platform as a Service product. It is typically used across the spectrum of IT in my customers' architecture. In virtually every deployment it has began as either an improved or even first time service desk tool and once the value has been demonstrated other enterprise stakeholders are quick to adopt its use - change management and problem management followed by product and services catalogs, asset management, etc.
I can honestly say that I have never been let down by the platform to meet a business goal - even those that might not be possible with other tools. The platform is extremely versatile and easily configurable to meet, thus far, any need.
I can honestly say that I have never been let down by the platform to meet a business goal - even those that might not be possible with other tools. The platform is extremely versatile and easily configurable to meet, thus far, any need.
- Incident Management is the obvious first choice. It arrives out of the box (OOB) fully able to meet the needs of an ITIL compliant/guided Service Desk. The relatively low amount of configuration (usually data and/or special use needs) required to get up and running in an enterprise means that you can immediately be productive with the product and begin identifying mission critical concerns that impede your business success. The #1 benefit, in my estimation, is that the product prevents issues from falling through the cracks. Clients will no longer fail to get resolution because their incidents get lost, passed over or simply forgotten.
- Change Management, always a challenge, benefits from the task based nature of ServiceNow. When combined with the Configuration Management Database and the intrinsic Workflow Manager, ServiceNow provides an integrated set of tools to respond to IT change processes. When integration of Incident, problem and change are in place an enterprise has all it needs to identify concerns, investigate root cause, make critical changes or reparation expediently. The platform also provides for executive level (and deeper) reporting to identify trends of service improvement - or degradation.
- Keep in mind that the tool does not necessarilly require a troop of developers to configure. Most configurations and behaviors require either no or a only a few simple javascript code lines to accomplish. Very often the stakeholders themselves can perform the module changes they need.
- While the individual topic modules are excellent, they would be less effective were it not for the notification engine that permeates the entire platform. Keeping everyone on the same page is a snap. Customer facing communications are separate from internal facing communications. Messages are automated at configurable ticket state changes, at defined events in the system, on the fly in a task form... The methods are email - easily customized to be branded and even personalized by user or department, and SMS notifications.
- Complex reporting is an area that still needs improvement. It is not yet possible to obtain parameterized reporting. In truth, this is the only function of the platform that I would count down.
- This is not my area of focus. However, I am able to work, literally, anywhere in the world because my function, my 'job' is online. That is invaluable to me.
- Relative to the question, however, I can honestly say that most of my clients have benefited from the fact that implementing ServiceNow in their IT architecture has exposed the missing or broken elements of their IT Processes definitions. Invariably the consistent management of all incident or other request tickets has led to immediate service improvement upon deployment. While I am inadequate to put a dollar value on this fact I am certain that each reader with those skills can do so and that the value, alone, will figure favorably in a purchase decision.
Frankly, I regularly deploy ServiceNow to replace these products. The legacy products require complete code recompile to change feature behavior and the other web based platform is, at its core, a CRM despite the add-ons developed and marketed in recent years. When I developed on that platform I found it replete with internal errors, repetitive dialog requirements, missing or incorrect documentation. I abandoned its use eventually.
ServiceNow IT Service Management Feature Ratings
ServiceNow Implementation
- Professional services company
Please note that I AM the Professional Services implementer.
Yes - Typically deployment is broken into more than one phase. This can be due to the expected cost of implementation, duration to complete all tasks, readiness issues (funding, culture, pre-requisites, education), etc.
The phase 1 modules are usually Incident, Problem, Change, Service Catalog, Knowledge Management and Configuration Database (either 'Lite" or fully integrated). These core modules, once deployed into a production environment, will provide the greatest initial impact on the ITSM needs of an enterprise. The ROI is usually evident within the first year.
Afterward, other modules are typically developed/configured in-house. If the original deployment was a develop-with (a shared responsibility development plan where the professional services agents assist the client's developer staff to accomplish the goals as well as to teach and coach) this is likely the case. Custom applications and integration with thirrd party tools may still require assistance but usually SMEs within the organization are all that may be required.
The final phase is to make the product/platform attractive. The platform has its own internal CMS. With a little schooling a competent web designer can skin the customer facing pages to conform to the branding and quality requirements of the corporate web presence.
[Remember that this is done LAST!]
The phase 1 modules are usually Incident, Problem, Change, Service Catalog, Knowledge Management and Configuration Database (either 'Lite" or fully integrated). These core modules, once deployed into a production environment, will provide the greatest initial impact on the ITSM needs of an enterprise. The ROI is usually evident within the first year.
Afterward, other modules are typically developed/configured in-house. If the original deployment was a develop-with (a shared responsibility development plan where the professional services agents assist the client's developer staff to accomplish the goals as well as to teach and coach) this is likely the case. Custom applications and integration with thirrd party tools may still require assistance but usually SMEs within the organization are all that may be required.
The final phase is to make the product/platform attractive. The platform has its own internal CMS. With a little schooling a competent web designer can skin the customer facing pages to conform to the branding and quality requirements of the corporate web presence.
[Remember that this is done LAST!]
Change management was a big part of the implementation and was well-handled - Missing or broken processes are inevitably identified during the planning stage of this module's development. However, the platform is versatile and the install state is usable for 80% of the users as-is. I have found that when I am developing configurations that are ITIL compliant all goes well. When I start to get out into the weeds... not so much. If you find yourself having difficulty getting your configuration to work it is probably because it is a bad idea. Sometimes you need to examine the business requirement and consider different means of accomplishing the goal. There have been occasions where meeting the goal has been accomplished by reapplying the process in a slightly different method.
- Knowledge of process is always paramount to success. You absolutely must know why you are performing an activity and what your goal is. Without a clear definition the results will not be as desired.
- Do not lie to the system. Many times I have been asked to do something that is ultimately foolish. An example is to permit the facts of a change request to be changed after the fact when an error is identified. This is always a bad idea because the purpose is to identify faults and correct them. Changing the historical record to be only a solution eradicates the thinking and errors that led to the problem. Merely providing the answer fails to maintain the reasons why the problem came into being. The correct solution is to simply permit post activity comments. The additional observations and solution details will remain relevant and in context to the concern.
- Do not lie to the single source of record.