BMC Remedy ITSM: Incident Management Process Flow


Uploaded by BMCdocs on 01.07.2012

Transcript:
This video teaches you the basic flow of the Incident Management process from the BMC Service
Management Process Model, and then shows how you can perform this process using BMC Incident
Management, part of the IT Service Management suite of applications. The video runs approximately
seven minutes.
The Service Management Process Model turns the theory and guidelines of the IT Infrastructure
Library into concrete processes that an IT organization can implement. The BMC Remedy
IT Service Management applications automate these processes, and link directly to SMPM
so that you can see the process that applies to the part of an application in which you’re
currently working.
The Incident Management process begins when an incident request is registered. This could
happen when a user contacts the Service Desk and an analyst registers their request, when
a user submits a request form, or when a specialist registers an incident that was triggered by
another process such as Event or Service Level Management.
If the analyst cannot resolve the incident request, they automatically or manually assign
it to a specialist group. The group coordinator determines whether a change is required to
resolve the incident request. A change is required if resolution will negatively affect
a service during service hours, change the functionality of a service, or update the
CMDB. If a change is required the group coordinator reassigns the incident request to the appropriate
change coordinator, kicking off the Change Management process. When the change request
is closed, the incident request can be closed. If a change is not required, the group coordinator
assigns the incident request to the appropriate specialist in the group based on skills, availability,
and access rights. If the specialist is able to resolve the incident, they change its status
and notify the original requester. If the specialist determines that the resolved incident
has a root cause that will generate similar incidents, they give the incident ID to the
appropriate problem coordinator, kicking off the Problem Management process. At this time,
if the specialist believes that their resolution for this incident would be useful in resolving
future incidents, they can propose the resolution for general use.
While trying to resolve the incident, the specialist might determine that a change is
required for one of the reasons previously stated, in which case they must escalate the
incident request. The specialist notifies the owner of the affected service and helps
that person understand the situation. The service owner must then decide whether the
most efficient way to resolve the incident is to restore the service at its continuity
site. If so, they escalate the incident to the on-duty manager, kicking off the Continuity
Management process. If not, the service owner asks the specialist to perform the needed
fix as an emergency change, kicking off the Change Management process.
Escalation to the service owner can also be triggered by the breach or near breach of
a service level agreement, a process known as Incident Request Tracking. If the group
coordinator is notified that a service outage is approaching or has exceeded its resolution
threshold, they must escalate the incident request to the service owner or take other
appropriate action. When other processes triggered by the incident
have completed or when the specialist verifies with the customer that the incident has been
resolved, the specialist can then close the incident request. At this time, if the specialist
has proposed the resolution for general use, the group coordinator reviews the resolution
and decides whether to approve it.
Now we’ll look at how the Incident Management process works in BMC Remedy ITSM applications.
The process begins when a Service Desk analyst registers an incident request. They do this
from the Incident Console by clicking New Incident, entering information about the request,
and clicking Save. Next the incident request is assigned to a
specialist group. Incident Management does this automatically when the analyst applies
an incident template to the request record or when they save the record for the first
time. Auto-assignment can designate not just an assigned group but also an assignee. If
auto-assignment is not configured to fully assign a particular incident request record,
a support staff member can manually assign it to a group and individual in the Assigned
Group and Assignee fields. If a change is required to resolve the incident,
a group coordinator or specialist first reassigns the incident request record to a change coordinator
using the same assignment fields. The change coordinator can then create an infrastructure
change request by expanding the Create Other Requests menu and clicking Create Change.
The new change request record is populated with information from the incident.
When a specialist resolves an incident, they must change its status and notify the original
requester. They do this by clicking Resolve and entering information in the resulting
dialog, then saving the record. This changes the Status to “Resolved” and automatically
notifies the requester. When a specialist resolves an incident, they
can create a problem request for the underlying cause of the incident. They can also propose
their resolution for general use. Creating a problem request record works the same as
creating a change request record, and is done by clicking Create Problem. The new record
is populated with information from the incident. To propose a resolution for general use, the
specialist creates a relationship to a new Solution Database request record, and then
edits and saves the record. If the incident request must be escalated
to the service owner or the on-duty manager, the specialist reassigns the request record
by using the Assigned Group and Assignee fields as previously shown. If the service owner
determines that an emergency change request is a better choice than recovering the service
at its continuity site, they create that change request record by clicking Create Change as
previously shown. If a service outage has breached or is about
to breach a service level agreement and the integration between BMC Service Level Management
and BMC Incident Management has been configured, Service Level Management automatically notifies
the appropriate person. This person can then escalate the incident request to the service
owner or take other appropriate action. Such notifications for a service target are configured
in Service Level Management. A milestone represents how close the target is to being breached,
and actions represent each notification that will occur for the milestone.
After resolving an incident request and verifying the resolution, the specialist can close the
request by changing the status of the record and saving. If the customer doesn’t verify
within a specified period of time that the incident was resolved, Incident Management
automatically closes the request. After an incident request has been resolved,
if the specialist has proposed its resolution for general use, the group coordinator decides
whether to approve the Solution Database request record by changing its status to Active. This
action concludes the Incident Management process. If you need to refresh your understanding
of the process while working with BMC Incident Management, you can launch the Service Management
Process Model right from the Incident Console. Click the Process Overview icon to display
the high-level flowchart of the Incident Management process used in this video. You can click
elements of the diagram to display more detail and you can view a text description at any
level.
We hope this video has helped you understand the best-practice process for Incident Management
from the BMC Service Management Process Model and the implementation of that process in
BMC Incident Management and BMC Service Level Management. Thank you for watching.