I’ve been involved in selection and implementation of numerous ITSM tooling projects over the years. Typically, I manage the implementation and configuration on behalf of the customer, acting as their trusted advisor, and managing the day-to-day work of the Systems Integration partner.
More recently, I’ve become involved more and more with the selection and implementation of ServiceNow, and have become familiar with the questions asked by the Systems Integration partners when seeking the customer’s requirements, so that these can be converted into configuration requirements.
I’ve assembled a list of the common data sets and items that customers are asked for.
Much as I love working with the Systems Integrators, they commonly expect these things to be in place and will often take what they are given without question.
Some of these items are “big-ticket” issues that will need considerable effort to resolve. My point is that these should be addressed before the tool is about to be configured, not during the configuration process. If the latter approach is adopted, it’s likely that the quality of the implementation will suffer from poor data or the implementation timelines will be extended.
- Ticket categories – how will the tickets be categorised, in terms of the impacted item, e.g.hardware, software, etc
- Ticket priorities
- Self-service, service request types, workflows and approvals required for each request type
- CMDB (CI types) – What data do you want to store in your CMDB, Applications, versions, relationships between CIs, perhaps hardware too (Servers, etc)
- Incident and Problem workflows (when does an incident “become” a problem, and what data needs to be carried over from one record to another”
- Incident and Problem record statuses (open, in progress, awaiting, closed, etc)
- Master Data (Users, locations, and associated SLAs)
- Reporting (internal and external facing reports), e.g. “live” dashboards, regular reports, automated distribution via email, etc
- SLAs, for service restoration and ticket resolution, both customer and supplier facing
- Knowledge articles, and permission groups for read/write access to each type of knowledge article (e.g. customer facing, internal 1st line, internal 2nd line, etc)
- Workflows for other processes, such as change management
- Approvals for all request and change types, together with an indication of whether there are multiple approvals for each type and the supporting workflow for these