A truly great service management system uses organizational data to automate onboarding, and request history to automate transfers and offboarding.
“Standardization does not mean that we all wear the same color and weave of cloth, eat standard sandwiches, or live in standard rooms with standard furnishings. Homes of infinite variety of design are built with a few types of bricks, and with lumber of standard sizes, and with water and heating pipes and fittings of standard dimensions.”
– W. Edwards Deming
“If you don’t know history, then you don’t know anything. You are a leaf that doesn’t know it is part of a tree.”
– Michael Crichton
Introduction
If you’ve spent any time configuring, administering or managing a ServiceNow implementation, odds are good that you’ve managed Catalog Items for the Service Catalog, specifically those that become Service Requests upon submission. And if you’ve been involved with designing the overall Service Catalog taxonomy and user experience, you’ve probably thought about Service Offerings, CMDB Services, classification and categorization. A thoughtful Service Catalog design gives end-users the information they need, access to submitting the right kinds of requests, and insight into the business functions the organization has codified. Additionally, if you’ve done your homework and thought about Service Request fulfillment, you’ve set up Catalog Items that have defined (known) approval and fulfillment processes.
These are all good things. A well designed Service Catalog is key to a good user experience and an overall quality implementation. And building Items that become Service Requests that fit the model ServiceNow has created means a better user and agent experience and a more easily maintained system. But in this article I want to talk about taking it to the next level – thinking about feeding the Request process with organizational data, and using Request history to more easily manage organizational change. In short, extending the information used by the Request process, and the information gleaned from the Request process, to accelerate your ServiceNow ROI.
Note: This article is focused on design thoughts, not the technical specifics of an implementation of this design. The expectation is the reader will be able to use the design ideas to formulate their own specific technical implementation.
Organizational Standardization for Onboarding
I’ve written previously about the importance of building and maintaining your core data for the success of your ServiceNow implementation. If you’ve got your organizational data locked in, you can start leveraging it across a number of use cases. The easiest and most obvious are reporting – knowing what was done by, and for which, department, business unit, location etc. And perhaps you’ve already started using it in certain Catalog Items. For example, Option X for an Item is only available for particular Departments, or User Criteria is set up to only allow IT to see and request a particular Item. These are all good uses for the data. But what about leveraging the expandability to ServiceNow to a larger use case? What about standardizing and automating your onboarding process by leveraging your core data, your CMDB and your Request processes?
When I worked at Workday, one of their tenets was that when a new employee started, on their first day, as they left orientation, they would pick up their laptop and it would be configured and ready to go exactly for what they needed to do their job. No waiting on hardware, or software installs, or access to enterprise applications. As we moved this process into ServiceNow, we designed it so that all of these things – hardware, software and application access – were standardized by the organizational unit and captured from a data perspective in ServiceNow. This involved connecting out of the box tables with new tables, mostly with a lot of reference fields. The high-level model looked something like this:
Our “baseline profile” table captured by department and role what a user should receive as a baseline: what hardware, software and application access. Using the out of box CMDB tables and Catalog Items, we linked all these various records across tables via references. Then our New Hire order guide queried and leveraged this data to present both mandatory and optional items for each new hire, tailored by their department and role. Further automation could auto-provision access and software, but we didn’t get this far with the implementation before I moved on. Of course part of this process was receiving new hire user data from Workday prior to their start date, but this wasn’t a requirement – a user record could be created directly in ServiceNow and merged with Workday data once received as part of a normal integration cycle.
Note: I realize with the new CSDM models that CMDB tables connect directly to Catalog Items; if you have used these data models the need to have references to Catalog Item in your baseline profile may not be needed.
Using this model has these advantages:
- Standardization of “install packages” by organizational unit (no “willy-nilly” ordering).
- Managing mandatory items by organization, for example, perhaps an employee in Sales will always get Salesforce access and not need to find and order it.
- Managing the orderable items in data tables rather than across multiple Order Guides (or in a hyper-complex single Order Guide).
It probably goes without saying that this organizational data can be used for other ordering logic, such as hiding and showing options on individual items.
Transfers and Offboarding
Using organizational data to standardize your onboarding is a great start. But real power comes from extending the data collected from the request process to other downstream processes, and hopefully automations too. The best example of this is Enterprise Application access. Using our Salesforce example, let’s say a new employee in Sales is given the Sales Manager role (level of access) in Salesforce as part of their onboarding process, via a Requested Item fulfillment. Under the current model, once the request is fulfilled, the process is done and the data is largely irrelevant, save for some reporting. But here’s the thing: it’s not irrelevant! We have valuable information about this employee having access to Salesforce, what level of account they have, when it was granted, and hopefully when it expires. This is information that can be used for future changes to that employee’s status, whether a promotion, a transfer, or an offboarding.
Let’s reconsider our onboarding process. Generally, out of this process a user receives the following:
For hardware and software, there can be some tracking if part of the request process includes assigning these things to the requester via the CMDB records or the Software Allocation processes. These things can also be discovered in most cases. But for Enterprise Application access, other than the requested item record, we don’t have any record of, or tracking, or application access. (This is not discoverable to my knowledge.)
The solution for this is to create table(s) to track this information in a centralized, orderly way outside of the Service Request data. I’ve drawn the picture below.
In this way, ServiceNow can become a system of record for this data. (The applications themselves are the system of truth.) Beyond the obvious reporting benefits of having this data centralized, it can also be used to feed a transfer or an offboarding process. Let’s say a termination occurs and ServiceNow is tasked with removing access and collecting hardware. While the latter can be determined from the CMDB, in the current ServiceNow world, we don’t have the data to drive the access removals. But in this design, the termination request process can query the User Access table and determine exactly what needs to be removed. (And in an ideal world, automation is used to do it!)
For a transfer, we combine elements of diagram 1 and diagram 2: The Baseline Profile data is used to determine what the user should get in their new position, and the User Access and CMDB data determine what they already have. A well designed solution will understand the overlaps, so that only the pieces that need to be removed are removed, and only those that are net new will be added.
Conclusion
Many ServiceNow applications are well-built to serve a single purpose. The applications often leverage core organizational and CMDB data to inform that process, but the process itself is standalone and results of that process are not leveraged for anything besides reporting and metrics.
Extending the use of the resultant data for future processes can give you new abilities to make them more intelligent and more automatable, lowering levels of effort and increasing ROI. And isn’t that what it’s all about? Continue to think about the things that drive automation, the data that is already being collected, and the interconnectedness of the entire platform’s data and processes and you will see real gains in productivity and ROI.
Go forth and design with intelligence and knowledge.
