Incident and Service Request separation

Service Requests can be handled within the Service Desk module, supported by the Service Catalog module. Service Requests are tracked as Service Desk Interactions and can be fulfilled using Incident Management, Change Management, Request Management, or another fulfillment engine specified by in the Service Catalog configuration. Service Requests that do not originate from the Service Catalog and instead come directly to the Service Desk can be routed to the appropriate fulfillment mechanism by the Service Desk Analyst or they can be completed and closed at the Service Desk.

Incident integration: Configuration Management system

Service Manager is fully integrated with the Micro Focus UCMDB CMS solution. This is a federated solution that integrates with the Micro Focus-provided discovery tools as well as those provided by other vendors.

Incident integration: Change Management

Out-of-box, the Service Manager Incident Management module is fully integrated with the Change Management module. Users can open Change request records from Incident records. Service Manager can pass relevant information from the Incident record to the Change request record. The two records are linked automatically.

Authorized users can access the Change Management module, create Changes associated with an Incident record, search for Change requests, view the Calendar, link an Incident record to an open Change request, and so on.

Incident integration: Incident matching with RFCs

Service Manager allows linkage between Incidents and Changes, and provides tools for users to establish the linkage. Users can link an existing Change or a newly created Change to an Incident. Service Manager can use business rules to manage the relationships. For example, Service Manager can use business rules to set all the related Incidents to “Resolved” when the related Change is resolved. Related users can then check if these Incidents can be closed.

Incident integration: Knowledge Management

The Service Manager Knowledge Management module allows end users and service-desk personnel to get speedy and accurate answers to their questions directly from any Service Manager application screen. End users can access the Knowledge Management module through the self-service interface to search for potential problem resolutions before contacting the service desk.

Knowledge can come from any Service Manager data source—Incidents, Known Errors and so on—or any external data source. Knowledge can also include Hot News.

However, the Knowledge Management module is more than just the technical components needed to store answers. Because knowledge articles are created via the Knowledge-Centered Support (KCS) process, users can be confident in the accuracy and “just-in-time” solution quality of the answers. The KCS process is an industry best practice for knowledge management for which Service Manager has received external certification.

Service Manager Knowledge Management is a fully integrated support-oriented knowledge management solution that supports KCS standards and guidelines. The Knowledge Management module provides a natural language search engine and rich-text authoring tools that enable users to search, update, and author knowledge articles. Knowledge Management integrates with Interaction, Incident, and Problem management modules so that users can search and use knowledge from existing incidents or problems while attempting to resolve a new incident or problem. Users can also use this integration with Interactions, Incidents, and Problems to create new knowledge. The rich-text editor allows users to include various types of images and documents as attachments that can be linked to other documents or included as part of an existing document.

As part of Micro Focus’s Closed Loop Incident Process (CLIP) solution, the integration between Service Manager Knowledge Management module and Micro Focus Operations Orchestration (OO) allows automatic execution of run-books related to change management tasks in the context of Service Manager Knowledge Documents. This allows for better and higher levels of automation.

For example, a Service Desk user diagnoses an Incident (or an end user who does self-help diagnosis) and searches for a Knowledge Management document with matching symptoms to the issue. When the user finds such a document, the user can execute a script from a link on the Knowledge Management page itself. The Knowledge Management link triggers a web service action that tells the OO server to run a specific pre-defined script on a specific server. The OO server then sends appropriate commands to the specified server to execute the runbook commands. When the target server receives the runbook commands, the server executes operating system commands or database commands as pre-defined to accomplish the specified action. This action could be a workaround or a fix, applied to the environment selected by the Service Desk (or end) user.

Incident integration: Problem Management

Service Manager provides separate modules for creating and managing Incident and Problem records, including Known Error records. However, because these modules are fully integrated and share data seamlessly, Incident, Problem, and Known Error records can be linked. Once linked, the relationships between the records are maintained. Users can create Problem records from Incident records (and vice versa), and Service Manager automatically copies all relevant information from the Incident record to the Problem record to minimize retyping. These records are automatically linked. Users can also manually link records.

Known Error records are created as part of the Problem Management process. The Service Manager Problem Management workflow contains two sub-processes:

• Problem Control. This process analyzes the problem, finds the root cause, and allows users to gather all data needed to initiate a new problem review. Problem Control includes two phases:

  • Identification and Classification. This phase includes creating the Problem record. Classification identifies relationships, urgency, assesses the impact on the customer’s business service, determines priority, and assigns the problem to a specialist or support group.
  • Investigation and Diagnosis. This phase examines the symptoms of the problem to identify the root cause.
• Error Control. This process manages correcting the root cause identified by Problem Control. The objective of Error Control is to effect permanent changes to Configuration Items (CIs) with known errors. Phase 1 of Error Control is Error assessment. Phase 2 of Error Control is closing the known error record.

While Service Manager will not automatically close all Incident records linked to a Problem or Known Error record, Service Manager facilitates closing linked records by listing all linked Incident records that need to be closed. Service Manager can be tailored to automatically close these records.

However, we do not believe that this supports best practices. Service Manager Problem Management is designed to address infrastructure errors, not immediate issues. Therefore, the technician should manage the closure of the Incident separately to help ensure the customer has received the necessary support.

Incident integration: Incident matching with Problem

Incident matching and association is a foundational function in Service Manager. When a user creates an Incident record, Service Manager prompts the user with a list of similar Incident and Problem records. Service Manager can automatically check for potentially similar records based on similar known errors, root causes, incident records, incident record duplicates on a device, or incident record duplicates on parents.

The user can then determine if the new Incident record is identical or similar to an existing Incident record (and can then link the records), or can be resolved based on the workaround information in an existing Problem record.

Incident integration: Request Fulfillment

Out-of-box, the Service Manager Incident Management module is fully integrated with the Request Fulfillment module. Users can open Request records from Incident records, and Service Manager can pass relevant information from the Incident record to the Request record. The two records will be linked automatically.

Service Manager also includes a web-based, self-service interface that allows end users to create service requests through an easy-to-complete form. Once the form is complete, Service Manager routes the request through the Service Desk module to the appropriate Service Desk technician, who can then escalate the request to an Incident record. Users can track, update, or close their requests through this interface.

Incident integration: Service Level Management

Service Level Agreements (SLA), Operational Level Agreements (OLA), and Underpinning Contracts (UC) are created in the Service Manager Service Level Management module. Each SLA has multiple Service Level Targets (SLT), which can define required response or resolution timeframes associated with Incident records, or required uptime for CIs or services. When an Incident record is created, Service Manager applies the applicable SLA (based on the business unit for which the Incident is created, the CI that is the subject of the record, or other parameters) and populates response and resolution time SLT, as well as availability SLTs, in the Incident record.

This information can be used to prioritize record resolution, and Service Manager displays upcoming SLT deadlines, escalations, and alerts in the Incident record.

 

Related topics

What is a Service Desk interaction?

Register an incident