DRAFT VERSION

Commonwealth of Massachusetts
IT Consolidation Phase 2

ITIL Process Flows

August 25, 2009
 SERVICE DESK STRUCTURE
DRAFT VERSION
Service Desk: A Service Desk is a functional unit made up of a dedicated number of staff responsible for dealing with a variety of service events, often made via telephone calls, web interface, or automatically reported infrastructure events.

Key Information Implications and Key Decisions

Location Services HR Finance Other
Tier 1

Core Helpdesk Team

Tier 2

Agency A Agency B Agency C - N Regional Team

Tier 3

Vendor 1 - N
 INCIDENT MANAGEMENT
DRAFT VERSION
Incident: An unplanned interruption to an IT service or reduction in the quality of an IT service.
Incident Management: The process for dealing with all incidents;
 this can include failures, questions or queries reported by the users, by technical staff, or by event monitoring tools.

Incident From Email From

Incident From Incident From
User Phone Technical
Event Mgmt Web Interface
Customer

Call Staff

No

No No Functional No Yes
Incident Incident Service Incident Initial Diagnosis Investigation and Resolution and
Incident Logging Major Incident? Escalation Resolved? Incident Closure
Identification Categorization Request? Prioritization Diagnosis Recovery
Needed?
Tier 1

Yes Yes
Yes
Request Major
Incident Record / Fulfillment Knowledge Mgmt./ Incident Record /
Incident End
Service Desk Tool Known Error DB Service Desk Tool
Procedure

No
Yes
Functional Functional No
Investigation and Resolution and
Escalation Initial Diagnosis Escalation Resolved?
Diagnosis Recovery
Level 2 Needed?
Tier 2

Yes
Incident Record /
Service Desk Tool

No
Yes
Functional Hierarchic No Investigation and Resolution and
Escalation Initial Diagnosis Escalation Resolved?
Diagnosis Recovery
Level 3 Needed?
Tier 3

Yes
Management Incident Record /
Escalation Service Desk Tool

Multi-level Incident Investiga- Resolution

Incident Incident
Categoriza Prioritiza- tion and and
Record Closure
tion tion Diagnosis Recovery

Sample Incident Record Sample Development Sample Prioritization Sample Procedure Sample Resolution Sample Closure Procedure
Fields Process and Categories Coding System Procedure
- Unique reference number 1. Develop top-level categories Clear guidance should be provided for - Establishing exactly what has gone - Asking the user to undertake directed - Closure categorization. Check and
- Incident categorization (i
nc luding  an  ‘ot
her ’
) category. Set up all support staff to enable them to wrong or being sought by the user activities on their own desk top or confirm that the initial incident
remote equipment categorization was correct and update
Key Information

- Incident urgency the relevant logging tools to use these determine the correct urgency and - Understanding the chronological
- Incident impact categories for a trial period. impact levels, so the correct priority is order of events - The Service Desk implementing the as necessary.
- Incident prioritization 2. After a trial period, perform an assigned. Such guidance should be - Confirming the full impact of the resolution either centrally (say, - User satisfaction survey. Carry out
- Date/time recorded analysis of the incidents logged during produced during service level incident, including the number and rebooting a server) or remotely using a user satisfaction call-back or e-mail
- Name/ID of the person and/or group the trial period and identify gaps. negotiations. range of users affected softwar e t
o take  cont
rol of the 
us er’
s   survey for an agreed percentage of
recording the incident 3. Perform a breakdown analysis of - Identifying any events that could desktop to diagnose and implement a incidents.
- Method of notification (telephone, the incidents within each higher-level have triggered the incident (e.g. a resolution - Incident documentation. Chase any
automatic, e-mail, etc.) category to develop the lower-level Impact recent change, some user action?) - Specialist support groups being outstanding details and ensure that the
- Name/department/phone/location of categories. High Medium Low - Knowledge searches looking for asked to implement specific recovery Incident Record is fully documented.
Urgency

user 4. Review and repeat periodically High 1 2 3 previous occurrences by searching actions (e.g. Network Support - Ongoing or recurring problem?
- Call-back method (telephone, mail, Medium 2 3 4 previous Incident/Problem Records reconfiguring a router) Determine whether it is likely that the
etc.) Software Low 3 4 5 and/or Known Error Databases or - A third-party supplier or maintainer incident could recur and decide
- Incident status (active, waiting, etc.) manuf act urers’
/suppl i
ers’ 
Er r
or  Logs 
or  being asked to resolve the fault. whether any preventive action is
- Related Incidents Priority Description Target Knowledge Databases. necessary (if so, open a Problem
- Support group/person to which the Application Code Res. Time Record).
incident is assigned 1 Critical 1 hour - Formal closure. Formally close the
- Related problem/Known Error Admini- 2 High 8 hours Incident Record.
- Activities undertaken to resolve the stration 3 Medium 24 hours
incident 4 Low 48 hours
- Resolution date and time Time & 5 Planning Planned
- Closure category Attendance
- Closure date and time

Note: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research
 REQUEST FULFILLMENT
DRAFT VERSION
Request: A generic description for many varying types of IT demands that are small changes –low risk, frequently occurring, low cost, etc.
Request Fulfillment: The process for dealing with all requests using pre-defined approval and qualification processes. Note: many organizations use their incident management process to fulfill requests.

Proactive Asset and

Service Incident
Service Desk Problem Configuration
Catelogue Management
Management Management
Input

No
Yes
Yes Yes No
Identify and Log Request Standard Request Financial Functional
Request Planning Fulfill Request Completed? Request Closure End
Request Categorization Change? Prioritization Approval? Referral?
Tier 1

No No Yes
Change
Request Request
Manage-
Record/Service Record/Service
ment
Desk Tool Desk Tool

No
Yes
Functional No
Functional Request Fulfilled Completed?
Escalation 2 Request Planning
Referral?
Level
Tier 2

Yes
Request
Record/Service
Desk Tool

No
Yes
Functional
Escalation 2 Request Planning Request fulfilled Completed?
Level
Tier 3

Request
Record/Service
Desk Tool

Request
Record

Sample Request Record

Fields
- What service is being requested
- Who requested and authorized the
Key Information

service
- Which process will be used to fulfill
the request
- To whom it was assigned to and
what action was taken
- The date and time when the request
was logged as well as the date and
time of all actions taken
- Closure details.

Note: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research
 CHANGE MANAGEMENT
DRAFT VERSION
Change: The addition, modification, or removal of authorized, planned or supported service or service component and its associated documentation.
Change Management: The process for responding to changing business and IT requirements while minimizing risk and reducing incidents, disruption and re-work.
Change Requestor

Service
Service Project Operational Non-Standard
Portfolios
Change Change Change Request
Change
Change Initiator

Design and Plan Review Change

Create RFC Record the RFC Plan Updates Implement Change
Change Results

Change
Change Develop
Management
Management Remediation Plan
System
System

Yes
Change Manager

No Coordinate
Standard Assess & Evaluate Authorize the Review Change Close Change
Review the RFC Change
Change? the Change Change Proposal Results Record
Implementation

Change
Management End
System
Yes
Change Authority

Authorize the Change Review Completed

Change Approved? Changes

No

Evaluation Report

Change
Standard Asses & Review
RFC Authoriza-
Change Evaluate and Close
tion

Sample Request for Change (RFC) Fields Sample Standard Change Sample Considerations Sample Change Authorization Model Change Advisory Board Sample Closure Processes
Considerations Membership
- Unique reference number - Impact assessment and evaluation – A standard change is a change to a Seven Rs of change management: Escalation Change Potential Membership Considerations - The change has had the desired
- Trigger (e.g. business need, resources, capacity, cost, benefits service or infrastructure that is pre- - Who raised the change? Path Authority Impact - Composition based on the changes effect and met its objectives
Key Information

purchase order, etc.) - Governance impact (continuity authorized by Change Management - What is the reason for the change? being considered - Users, customers and other
- Description management) with an established procedure. - What is the return required from the Business
High cost/risk - Should include business and stakeholders are content with the
- Identity of items to be changed - Change decision body change? Level 1 Executive
change technical representation results, or have identified any
Board
- Reason for change (business case) - Decision and recommendations Elements of a standard change: - What are the risks involved in the - Should involve suppliers when that shortcomings
- Effect of not implementing the accompanying the decision - There is a defined trigger to initiate change? would be useful - There are no unexpected or
change (business, technical, financial) - Authorization signature the RFC - What resources are required to Multiple - Shoul d r efl
ec t 
both user s’
 and  undesirable side-effects to
- Configuration items and baseline - Authorization date and time deliver the change? IT Management functionality, service levels,
- The tasks are well known, Level 2 services or orgs c us tomer s’ 
v iews
Board
versions to be changes - Target baseline or release to documented and proven - Who is responsible for the build, test impacted - Is likely to include the problem warranties
- Primary contact information of person incorporate change into - Authority is effectively given in and implementation of the change? manager and service level manager - The resources used to implement the
proposing change - Scheduled implementation time advance - What is the relationship between this and customer relations staff. change were as planned
- Date and time of proposed change - Location/reference to release/ - Budgetary approval will typically be change and other changes? Change Single service - The release and deployment plan
- Change category (minor, major, etc.) implementation plan Level 3
preordained or within the control of the Advisory Board or org impacted worked correctly
- Predicted timeframe, resources, - Details of change implementer change requester Additional Considerations: - The change was implemented on
costs and quality of service - Change implementation details - The risk is usually low and always - Impact on business operation time and to cost
- Change priority - Actual implementation date and time well understood. - Effect on infrastructure services that - If needed, the remediation plan
- Risk assessment and risk - Review dates share the infrastructure Local Standard
Level 4 functioned correctly
Authorization change
management plan - Review results - Impact on customer service
- Back-out or remediation plan - Closure - Effect of no change
- Impact on resources
- Impact on future plans
- Impact on current schedule

Note: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research
 ASSET AND CONFIGURATION MANAGEMENT
DRAFT VERSION
Asset and Configuration Management: Full lifecycle management of IT and service assets, from the point of acquisition through to disposal

Approved Approved
Input

Approved Asset/Config. Request for Asset

Asset
New Asset Data Audit Report Disposal/
Change
Reallocation

Procure Asset Update Financial

Procurement

End
Record
Finance /

Finance/
Finance/
Procurement
Procurement
System
System

Yes
Asset/Config.

Asset No Define New Schedule & Plan Direct Corrective Plan and Assign
Manager

Standard? Config. Codes Audit Analyze Report

Action Report

Configuration
Management
System
Asset/Config.

Conduct Audit Report Findings Prepare Report

Analyst
IT Technicians

Create Asset Implement

Update Asset Retire Asset
Record Corrective Action

Configuration
Management
System

Configura-
Configura- Note:
tion Asset
tion Asset
Identifica- Record
Control Disposal
tion

Sample Configuration Asset Record Sample Asset Record Configuration Control Asset Disposal
Identification Procedures Considerations Attributes Considerations Considerations
- Define and document criteria for The items placed under Configuration - Unique identifier - License control, to ensure that the Security Disposal
selecting configuration items and the Management will typically include - CI type correct number of people are using - PII and HIPAA
Key Information

components that compose them service bundles, service packages, - Name/description licenses and that there is no - Sensitive information
- Select the configuration items and service components, release - Version (e.g. file, build, baseline, unlicensed use and no wastage - Legislative mandates
the components that compose them packages and products that are release) - Change Management - Legal requirements
based on documented criteria delivered to the customer, designated - Location - Version control of service asset,
- Assign unique identifiers to internal work products, acquired - Supply date software and hardware versions, Environmental Disposal
configuration items services, products, tools, systems and - License details, e.g. expiry date images/builds and releases - Precious metal recovery
- Specify the relevant attributes of other items that are used in creating - Owner/custodian - Access control, e.g. to facilities, - Hazardous substance disposal
each configuration item and describing the configurations - Status storage areas and CMS - Legal requirements
- Specify when each configuration item required to design, transition and - Supplier/source - Build control, including the use of - External repurposing
is placed under Configuration operate the service. - Related document masters build specification from the CMS to
Management - Related software masters perform a build
- Identify the owner responsible for Choosing the right Configuration Item - Historical data, e.g. audit trail - Promotion, migration of electronic
each configuration item. (CI) level is a matter of achieving a - Relationship type data and information
balance between information - Applicable SLA. - Taking a configuration baseline of
A baseline configuration should be availability, the right level of control, assets or CIs before performing a
developed. An example of a baseline and the resources and effort needed to release (into system, acceptance test
is an approved description of a service support it. CI information is valuable and production) in a manner that can
that includes internally consistent only if it facilitates the management of be used for subsequent checking
versions of requirements, requirement change, the control of incidents and against actual deployment
traceability matrices, design, specific problems, or the control of assets that - Deployment control including
service components and user can be independently moved, copied distribution
documentation. or changed. - Installation

Note: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research
 PROBLEM MANAGEMENT
DRAFT VERSION
Problem: The unknown cause of one or more incidents.
Problem Management: The process of preventing problems and resulting incidents from happening, to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented.

Proactive
Event Incident Supplier or
Service Desk Problem
Management Management Contractor
Management
Input
Problem Analyst

Problem Problem Functional No Known Problem or

Problem Logging Initial Diagnosis Problem Major
Problem Detection Escalation Known Error Problem Closure End
Categorization Prioritization Resolution Problem?
Needed? Record

Yes
Major Problem Problem Major
Incident Record/ Service Record/ Service Problem
Procedure Desk Tool Desk Tool Review

Yes No
Investigation and Create Known Change Problem
Workaround?
Diagnosis Error Record Needed? Resolution
Tier 2

No Yes
Change
Configuration Problem
Known Error Manage-
Management Record/ Service
Database ment
System Desk Tool

Investigation and No
Change Problem
Diagnosis Needed? Resolution
Tier 3

Yes
Change
Configuration Problem
Manage-
Management Record/ Service
ment
System Desk Tool

Problem Investiga-
Problem Problem tion and Problem
Prioritiza-
Detection Record Diagnosis Resolution
tion

Sample Detection Sample Problem Record Sample Prioritization Sample Approaches Sample Problem
Procedures Fields Coding System Resolution
- Suspicion or detection of an unknown Cross-reference the related incident Priority and severity should be - Chronological Analysis: Briefly document all events in chronological order –to provide a timeline of - Develop fault elimination action plan
cause of one or more incidents by the logs to capture details such as: included in the Problem Prioritization events to help identify which events may have been triggered by others or to discount any claims that - Track progress of problem resolution
Key Information

Service Desk process. Problems are prioritized are not supported by the sequence of events. against plan
- Analysis of an incident by a technical - User details using the same methodology as - Kepner and Tregoe: Charles Kepner and Benjamin Tregoe developed a useful way of problem - Document progress against plan
support group which reveals that an - Service details incidents. Severity can be determined analysis which can be used formally to investigate deeply rooted problems. They defined the following - Close problem once plan is complete
underlying problem exists, or is likely - Equipment details using the following criteria: stages:
to exist. - Date/time initially logged - Can the system be recovered, or ● defining the problem
- A notification from a supplier or - Priority and categorization details does it need to be replaced? ● describing the problem in terms of identity, location, time and size
contractor that a problem exists. - Incident description - How much will it cost? ● establishing possible causes
- Analysis the trend of incidents as - Details of all diagnostic or attempted - How many people, with what skills, ● testing the most probable cause
part of proactive Problem recovery actions taken. will be needed to fix the problem? ● verifying the true cause.
Management. - How long will it take to fix the - Ishikawa Diagrams: A method of documenting causes and effects. The main goal is represented by
problem? the trunk of the diagram, and primary factors are represented as branches. Secondary factors are then
- How extensive is the problem? added as stems, and so on. Creating the diagram stimulates discussion and often leads to increased
understanding of a complex problem.
- Pareto Analysis: This is a technique for separating important potential causes from more trivial
Impact issues. The following steps should be taken:
High Medium Low 1 Form a table listing the causes and their frequency as a percentage.
Urgency

High 1 2 3 2 Arrange the rows in the decreasing order of importance of the causes
Medium 2 3 4 3 Add a cumulative percentage column to the table.
Low 3 4 5 4 Create a bar chart with the causes, in order of their percentage of total. Superimpose a line
chart of the cumulative percentages.
6 Draw line at 80% on the y-axis parallel to the x-axis. All data elements below where the line
intersects with the curve are important causes

Note: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research
 Incident
Request
Fulfillment
Change
Manage-
ment
 Release
Management