Tiering Examples

1. User in building 3, floor 2, Accounting department reports an issue with accessing SAP. Root cause is a misconfigured switch port.

• Tier 1: User calls the Help Desk. A support agent opens a support ticket and does some basic troubleshooting – reboots, logs out and in. After 10 minutes, the agent tells the user they need to escalate and ends the call. The agent assigns to a SAP support group. After a few hours, an SAP engineer sees the ticket and begins to ask around if there are any known issues currently. He also confirms he can access SAP and notes no issues in the logging. He IMs local support in building 3 and asks if they can do a remote session. After some troubleshooting, they realize all computers on floor 2 are having trouble accessing some network resources. The ticket is reassigned to Networking. The next morning, the Networking team picks up the ticket and reads through all the notes. They check with the team verbally and via IM to see if any changes went in recently. After a few hours, they realize there was a switch card installed to fix a hardware issue 2 days ago. They begin to troubleshoot and by early afternoon, find the misconfiguration and fix it. They assign the ticket back to the Help Desk and the level one support team checks with the end user that service has been restored before closing the ticket.
• Tier 5: User submits an incident through the Self Service portal with a high impact, after confirming several members of his team are having the same issue. The incident is marked medium priority and tied to the SAP service and auto-routed to SAP support. SAP support picks up the incident and checks the SAP system for issues, seeing none. They view the CMDB map to check for upstream issues, and see that there are other incidents and a change tied to the network switch in building 3, floor 2. They change the affected CI to the switch and the ticket is auto-reassigned to the networking team, and change the priority to high. The networking team’s SLA-based queue dashboard moves the incident to the top, and the incident is assigned to a level 2 engineer automatically. The engineer, viewing the same CMDB map, makes the incident a child of another incident opened against the same switch. The team sees the change, and finds and fixes the configuration error based on the implementation notes for the Change. The parent is closed and the resolution flows to all children. Service is restored within 2 hours. Management reviews the change and sees a gap in the review process that allowed the issue to occur, and the change templates are changed to prevent the issue in the future.

2. A manager in Sales needs to onboard a new sales rep working remotely

• Tier 1: The manager emails the Help Desk with the details about the new rep. A support agent opens a support ticket and fills out what was provided in the email, but has to contact the manager to get additional information. After several back-and-forths, the agent begins to email other teams with the ticket information so that they can fulfill the portions they are responsible for, e.g. Procurement to get the hardware and Application Support to set up accounts. The agent has to manage the disparate fulfillment processes through phone, email and IM. Because of different lead times, it takes 8 days until the agent has everything she needs. Meanwhile the rep starts on day 10. The agent sets up the laptop, logs in as the new rep, sets up the applications, and ensures access. She then works with shipping to get the “office setup” sent to the new rep. The new rep receives everything after 13 days.
• Tier 5: The manager submits an Onboarding request through the Self Service portal, filling out all required information, including choosing available hardware stored in the system by department. The system also contains a master list of applications by department. The system’s fulfillment workflow for Onboarding sees the new rep is part of Sales, orders the Sales laptop automatically from Procurement, and auto-provisions all enterprise-wide and sales specific applications. Procurement uses Asset and Inventory management, and has hardware in-stock for such requests. The hardware is delivered to the Service Desk, and an Agent, who owns the master request, sets up the laptop for the rep and confirms the application access that has already been provisioned. The entire process takes 2 days. The Agent works with shipping to ensure the “office setup” is delivered the day the rep starts their position with the company. The system, based on the request, keeps a record of all hardware and application access received, and uses that data for managing shutoffs and reclamations when the sales rep transfers to another department or leaves the company. Management uses the requester’s and fulfiller’s departments and cost centers to report on how much service is being provided, and to whom, to manage budgets and do chargebacks.

Tier 1 vs. Tier 5

Tier 1

Characterized by:

• Lack of self-service
• Centralized help desk
• Unrelated tickets
• Tribal knowledge
• “Catch as catch can” prioritization and resolution

Tier 5

Characterized by:

• Multiple service channels
• Distributed, specialized support groups
• Prioritized and correlated ticket queues
• Synchronization between core data, knowledge and CMDB to align, diagnose and resolve and fulfill
• Automation, orchestration and integrations to fulfill and synch systems

What I hope is an obvious conclusion from all this is that ServiceNow is able to achieve all these tiers. Many systems that were designed as ticketing systems first can reach the first, second or perhaps third tier, but struggle to achieve the goals of tiers four and five. Because ServiceNow was designed as a platform first, and ticketing, specifically ITSM ticketing was layered on top, it is flexible enough to achieve any desired level. When Service Management is viewed holistically – from a platform perspective and not just a series of unrelated operations applications – it has the ability to help your company become a strategic leader in your industry. (Wow this sounds terribly like marketing – sorry about that!) So why drive a Cadillac? This is why!

Happy transforming!

I had a client recently refer to ServiceNow as a “Cadillac Escalade”, and that they “just needed a Kia”. This is certainly a long way from when I started at ServiceNow in 2010 and the company and the platform was still just emerging from its “gutsy startup” phase. We’ve now reached the point where ServiceNow has become a “gold standard” in cloud platforms and Service Management, and customers are having to decide if they can afford such a high-end solution.

Anyone who has spent time in business realizes that many decisions are made strictly on financial conclusions, or at the least, what is the minimum required solution for the minimum price. While this exercise is black and white, it’s often overly simplistic and short-sighted.

I’d like to use the remainder of this article to talk about the decisions made about using ServiceNow as your Service Management platform: What do you get out of it, what do you want to get out of it, and are you thinking about both in the right way?

Deciding what Service Management is to your business

For much of IT’s history in business environments, upper management’s view of it (and often the whole company’s) is mainly or purely operational: While it automates a previously manual process, it is there simply to “keep the lights on”, and isn’t core to the company strategy. As a subset of IT, Service Management serves the same function: Ensure people can do their work, and speed up the process of getting people what they need where possible.

Only recently have I started to see a shift in philosophy where companies and company decision-makers start to view IT and Service Management strategically: How can this business function actually be leveraged to make us more competitive, increase our margins, allow our people to focus on strategy and not day-to-day repetition. Let’s explore what this means. The following image shows the upward pyramid of Service Management from operational to strategic:

Here’s each tier in greater detail:
Tier 1
Organizations have a central mechanism for taking in issues and requests, assigning them, and working them through to completion. Issues and requests are lumped together; customers and fulfillers view everything as a “ticket” to get reported and completed. Processes are manual: the customer calls or emails, queue managers or general fulfillers assign out the work. No SLAs are defined or tracked – work is done “catch as catch can”. Knowledge and solutions are tribal. No CMDB exists or is leveraged for ticket alignment. No attempt to recognize patterns or recurrences. Reporting is basic and often compiled and manipulated “just in time”.

Tier 2
The central mechanism begins to delineate between types of requests, and defining SLAs around each. For example, an issue preventing a person or persons from doing their job is prioritized over a request for a new software installation. Customers have other interfaces to submit and view their issues and requests – portal, mobile apps, etc. Fulfiller queues become better defined and therefore easier to assign. Management starts to standardize reporting and it becomes more real-time in nature. Knowledge begins to be documented. A CMDB is started for aligning issues and requests with physical and logical infrastructure. Fulfillers begin to recognize and report patterns.

Tier 3
Based on information in submissions, some routing is automated, bypassing the initial queue. SLAs begin to be used to measure performance and enforce accountability. The customer experience becomes both broader and more intuitive – more information and paths to get service exist, but the interfaces are easy to navigate and the correct information is presented at the correct place and time. The CMDB becomes core to understanding and analyzing the service environment – where are issues arising and how is it tied to the broader environment? Reporting starts to move up and down the enterprise hierarchy and is not just limited to single service areas or tiers. Knowledge management processes become defined to ensure knowledge is relevant and up-to-date.

Tier 4
The service desk becomes de-centralized as the CMDB and other mechanisms define and route tickets to the correct initial fulfillment groups (bypassing the generic “service desk” or “help desk”). Correct and available knowledge begins to deflect ticket creation as customers are able to self-serve. Other tickets, particularly requests, are auto-fulfilled (require no human interaction) with orchestration. CMDB relationships are defined allowing fulfillers to see impact across services and the enterprise infrastructure.

Tier 5
All ticket types are defined based on the information presented and the service required – the “right tool to get the job done”. SLAs are defined by type and measured, viewed and accountability exists for meeting them. Almost every submission is routed to a minimum level 2 support group based on the information provided. Fulfillment flows are defined and automation/orchestration is used wherever possible, and fulfillment flows are not implemented without exploring and understanding what automation is possible. CMDB and core data drive the routing, the fulfillment flows and the reporting. Fulfillers leverage the CMDB relationships to understand issues and change impacts across the enterprise. Reporting can be done from the fulfillment teams and ticket type level all the way up to the enterprise, based on available core data. All opportunities for self service and ticket deflection mechanisms are implemented and exposed to the customer. Knowledge is cultivated, managed, standardized and available to the correct audiences. The service management system becomes a system of record for all services delivered and aligns with systems of truth for devices, licensing and access.

Where do you want to be in this tiering?

As stated earlier, it’s much easier to do a cost-benefit analysis of Tier 1. But the real ROI comes from leveling up towards Tier 5. ServiceNow’s flexibility allows you to reach any of these tiers, so a goal of Tier 5 is very attainable. When your employees are no longer focused on day-to-day operational concerns, but rather focus their energies on business improvement, strategic initiatives and outside the box thinking, your business becomes a leader.

In Part 2, we’ll examine the key differences between Tier 1 and Tier 5.

The generally accepted ITIL definition of a Service Request is “request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery”. (This differentiates from Incident, in that it doesn’t involve a restoration of Service.) The key part of this is “agreed as a normal part of service delivery”. Companies often struggle with what a “normal part of service delivery” means. ServiceNow further complicates this with how they built the Service Request application. If you’ve worked with the Service Catalog, Catalog Items, and the Service Request records they create, then you are probably aware of some of these challenges.

I drew this picture on whiteboards for customers for a few years and then gave it to ServiceNow training in 2013 and said “This needs to be in your curriculum. People need to understand this picture.”

The initial challenges are two-fold:

1. The Service Catalog and Catalog Items were designed to give an “Amazon” like experience. Customers select items, add them to a cart, and order them. In order to do this properly, the items need to be well-defined. You don’t go to Amazon and say, “I need socks”, press “Order” and Amazon says, “we’ll figure out the rest on the backend”. No, the expectation is you are selecting a well-defined product – size, style, color, etc. Amazon knows what they offer, which leads us to part 2 – they also know how to deliver it.
2. The Service Request is a 3-tiered record structure, with an Item-specific workflow running against the middle tier (Requested Item). The workflow generates and assigns Tasks (the third tier) based on a known delivery flow. In other words, because Amazon has defined what they are offering, they also know exactly how to deliver it.

In this way, the Service Request structure does not lend itself well to open-ended requests or ad-hoc delivery flows (aka “We’ll figure it out as we go”). The idea is that IT (or any part of the business) is delivering a known entity – they are able to define what that entity is, what it needs to ask the requester about the entity request, and what process and people need to be involved to fulfill the request for the entity successfully.

When part or all of this can’t be met, the reality is that the Service Request application (starting with a Catalog Item) may not be the correct place to build the requirement. In general, I ask the following questions of the requirement to determine if it can and should fit into a Service Request:

1. Does the use case have special security requirements? (Securing individual records gets complicated with the 3-tier record structure, and doesn’t scale well. Not to mention the notification and audit concerns.)
2. Does the use case have a known approval and delivery process? (Open-ended and ad-hoc approvals and tasks make for complicated workflows.)
3. Does the use case need the user to interact with the data after submitting the request, beyond comments? Do users need the ability to save something as a “draft” before submitting?
4. Does the use case have special schema requirements for a single entity? (e.g. Dept X needs to have 5 “special” fields on RITM to satisfy some specific need)
5. Does the use case need special notifications?
6. Does the use case require editing of variable answers after the submission of the request?
7. Does the use case have reporting requirements against what would be a variable? (ServiceNow still doesn’t do variable reporting well. Even though it is supported, it wasn’t designed with this in mind.)
8. Does the use case need an integration after the request has been submitted? (I’m shuddering at the thought of having to integrate variable data with another system.)

In general, I treat variables almost as “read-only” and un-reportable, in that a user should be able to populate them, submit them, the fulfiller looks at them to fulfill the request, and never needs to do anything else with them. Adding logic to variables is kludgy, and you don’t get a real audit history when they get edited. So when someone comes up with some complex use case that needs all this weird logic and interaction with variables, it starts to look like a Picasso painting. (As usual, this is as much art as science.)

So what to do? There isn’t a hard and fast answer to this. In some cases, when a customer is new to the platform, I have less of an issue creating a single “generic” request item that fills the need for requesters of “I don’t see what I need, can I just tell you what I need?” What this usually requires is two-fold:

1. An open-ended description that allows the requester to describe what they need. The assumption is that this almost always requires a follow-up by a service desk agent and some back-and-forth before being able to assign out work and fulfill the request.
2. A fulfillment workflow that allows for ad-hoc approvals and/or fulfillment tasks.

Keep in mind this type of request usually cannot be aligned with any delivery metrics, or if it is, will potentially skew these metrics.

In other cases, I’ve built an entirely new application to support these kinds of requests, using the Out of Box “Ticket” (ticket) table. This was for large organizations who have a well-defined catalog of items, but also fulfill a lot of requests that don’t align with a pre-built item. These are organizations whose use cases answer “yes” to many of the questions above. Once built, the records themselves can be assigned, worked and reported on like any other task-based record in ServiceNow, and queues can be managed with the ideas of “My Work” and “My Groups Work”.

So why not use Incident? An argument can be made for this, particularly if the volume is small. This is the reason for Category “Question” and Priority 5. However, keep in mind that the definition of Incident is something is broken and the goal is to restore service as quickly as possible. Often the use cases we are describing have nothing to do with restoration of service.

Regardless of the approach, the best practice is to continue to mine the requests entered for these use cases to determine if they can be converted to a well-defined Catalog Item and Fulfillment Workflow.