Last week in “Intake Management – A (non)-ITIL Process to ‘Center’ Your ITSM Initiative” Bill Cunningham talked about Intake Management and how implementing such functionality allows for a more efficient means of processing incidents, service requests and more. This week we’ll dive in to the auxiliary components of Intake and how each piece works together to support this process.
Like most technical solutions in ServiceNow, the data behind the scenes plays a pivotal element to the successful implementation of Intake. Service Catalyst created a custom application to help manage these data components. The process of Service Data Management captures the Services, Applications, and Symptoms that make up intake routing.
The Dish on Services
While there are many terms for a Service (business service, technical service, etc.) anything that delivers value to customers by facilitating desirable outcomes is considered a service. A consumer avoids the ownership risk and costs of a service by leaving it in the hands of the provider. Services are often times made up of a combination of resources, processes, and capabilities. A service owner works alongside appropriate personnel to manage and deliver it to consumers. Additionally a service may have a primary and secondary support group that assists in providing ancillary functions.
With an App Please!
Applications are the technical components that comprise a service. Applications are individually “owned” or managed and may also indicate specific support groups. Understanding this hierarchal relationship between services and applications is the base of Service Data Management.
Symptoms are indications of an issue or need. Some key types include incidents (something is broken), requests (something is needed), inquiries (clarification on something), and password resets. Ideally, the list of symptoms should be modest and generic. Creating symptoms overly specific to a singular application, generates additional, and often times unnecessary, efforts in data management. Instead, it is recommend that a single symptom can be used across a variety of services and applications.
The Full Plate
The combination of Services/Applications to Symptoms is what determines the routing piece of the intake process. Maintaining this data is important to the successful implementation of Intake, as it ensures the correct record is generated based on the backend pre-determined logic.
Who’s at the Table?
Service and Application owners are paramount to the integrity of Service Management data. These individuals are responsible for ensuring the information about their Services and Applications are accurate and up to date. They indicate operational status, who the primary and secondary support groups are, and what symptoms can potentially be associated to a service/application. Specified primary and secondary support groups ensure that the intake process routes appropriately if it’s apparent the help desk should not be managing this particular reporting.
Data management is always an undertaking. However, if you eat all your dinner you’ll be sure to get dessert: an operational and functional Intake process with a cherry on top!
Service Catalyst’s Ben Ramseyer will dish out Business Relationship Management, so be sure to visit us again soon!
Want to hear more? Listen to our podcast on this topic.