Introduction
I created this material to aid in the study and implementation of ITIL Service Delivery and Service Support. The content are my interpretation and may be flawed. Thus, no warranty is offered or implied as to the suitable of this material for use. If you find errors or discrepancies, please send an email and I will do my best to correct the situation. Please understand, however, that this is a voluntary work in progress.

Also, please remember that this is a supplement, not a replacement for the ITIL Service Delivery and Service Support guides. While this material may aid your study and implementation, I strongly emphasize the importance of reading the actual OGC materials.

Robert Perrine, PMP, ITIL-SM, MBB, CISA
robert@RobertPerrine.biz
Fall 2004 - 2007
Irvine, California, United States of America

Copyright
Fall 2004 - 2007, Irvine, California, USA, copyright by Robert E. Perrine, PMP, ITIL-SM, MBB, CISA.
Offered as is, with no warranty regarding the accuracy or suitability of this material. Copyright reserved. Please, however free to copy and share these documents with the following restrictions.

• You may not charge for use or distribution of this material.
• Your usage of this material is conditioned upon your compliance with the PMI Code of Ethics.
• All distributions must be made with the intent to further the collected wisdom of humanity.
• You may not remove my name or my copyright notices from these documents.

Key Process Diagrams
There are specific interconnections between the ITIL processes that are key to the understanding of ITIL. As time permits, these flows will be identified and documented.

The Service Level Agreement Process

The Incident Escalation Process

The Problem Management Process

The Configuration Life Cycle

The Change Authorization Model

In the future I plan to work on diagrams for the remaining processes, including:

• IT Financial
• Capacity
• IT Service Continuity
• Availability
• Service Desk
• Release
• Service Management

Analysis
The purpose for the Analysis sections is to expose the processes within the disciplines. The ITIL Service Delivery and Service Support guides provide a mixed set of process flows, descriptions and allusions. The goal for this part of this study material is to provide a consistent description for each of the process flows.

Service Level Management
Agree, Monitor, Report and Instigate

Service Level Requirements (SLRs) and customer and support perceptions of service levels currently delivered				Planning				Evaluate monitoring tools and upgrade if required also send customer a satisfaction survey or interview customer and support
List of services from configuration data or interviews with Service Desk and customers				Service Catalog (SC) updates				Update the Service Catalog as required
Service Level Agreement (SLA) template, draft SLA, Service Level Requirements (SLR), monitoring capabilities and SC				Draft				Manage expectations, update the draft SLA and update the SLR until they align
Draft SLA and SLR				Negotiate				All parties must have clear and consistent expectations on the finalized SLA and SLR
Preliminary agreement on SLA and SLR along with monitoring capabilities (manual & automated)				Preliminary monitoring				Verify the thresholds are Specific, Measurable, Achievable, Relevant and Timed correctly
Current Operational Level Agreements (OLAs) and Underpinning Contracts (UCs)				Review OLAs and UCs				Updated OLAs and UCs with monitoring for each threshold
Preliminary SLA, SLR and monitoring results along with updated OLAs and UCs				Agree				Agreed SLA signed by both the customer and support
Signed SLA				Publish				Awareness campaign to ensure all parties are aware of the details
SLA, SC and implemented monitoring				Monitor				Action plan to address exceptions
Monitoring results				Report				Distribute results to confirm compliance and highlight exception
Published reports compared to the SLAs				Service Review Meetings				Identification of weak areas can trigger a Service Improvement Program (SIP), corrective actions or additional training
Established schedule and scope defined in the Service Quality Plan				Review SLM procedures				Review and maintain the Service Level Management policies and procedures Note exceptions with recommendations
Existing SLAs, OLAs and UCs with a defined review schedule				Review SLAs, OLAs and UCs				Review and maintain the SLAs, OLAs and UCs. Note exceptions with recommendations
Results from review of the procedures, SLAs, OLAs and UCs				Instigate corrective actions				Requests for Change to agreed documents

Managing the Service Level Management Process

Identify the benefits delivered through Service Level Management				Awareness Campaign				Publicize the benefits from Service Level Management
When initiating Service Level Management or launching a new service				Planning Service Level Management				Build a Mission Statement and Service Quality Plan to define roles and responsibilities, escalations and notifications
Establish a schedule for periodic contact with customers				Proactive customer communication				Venting and identification of their satisfaction. Note: Satisfaction = Expectations - Perception
Detection of weaknesses that justify corrective actions				Service Improvement Program (SIP)				A focused project to address the weaknesses

Service Desk
Call Distribution Process

Event details, configuration details and relevant Service Level Agreements (SLAs)				Determine which process is appropriate				Gather details about this event
When the event is a predefined service				Actioned Infrastructure Incidents				Restart services, execute scripts, etc as defined in the workflow (MAP) assigned to this event
When the event is an Incident				Implement Incident Management				Branch to the Incident Management process
When the event is a Request for Change (RFC)				Facilitate Change Management				Create or update an RFC or implement change as authorized by the Change Management process
When the event is a request for status				Interface for the Service Management processes				Gather status and communicate the status to the caller
Service Request Process
When the event is a Service Request (SR)				Record				Create a Service Request (SR) Record with the contact info, detailed description and configuration details
SR, relevant processes and workload assessments				Classify				Assign the Category, Impact, Urgency and Priority, then assign to appropriate resource
Periodic reminders to update the customer, or action by the customer requesting status				Communicate				Get updates and give status
Formal sign off by the customer that the results are satisfactory				Closure				Update the SR with status and then close the SR

Proactive Service Desk Tasks

Customer history				Customer Assessment				Create a Service Request to document customer training needs and escalate for action
Information distribution request				Customer Advisory				Disseminate advisories such as the Forward Schedule of Changes, Release Schedule, etc.
Periodic reminders to update the customer, or action by the customer requesting status				Customer Contact				Status updates, informal customer satisfaction surveys and marketing opportunities
Periodic surveys as described in the SLA				Customer Surveys				Customer Satisfaction rating and exceptions that require action
When the Impact is significant or an SLA timer indicates that the SLA might be breached				Hierarchical Escalation				Status and optional recommendations
When there is an error in the Configuration Management Database (CMDB)				Improved accuracy in the CMDB				Make the updates, where authorized, otherwise notify Configuration Management that there is an apparent error in the CMDB
Begin with a baseline User Handbook and then observe how the services are actually used				Maintain the User Handbook				Either update the User Handbook or document the revisions and forward them to the Handbook administrator
When opportunities arise and the customer is receptive or take opportunities to publish updates in newsletters and emails				Marketing				Market (sell) the benefits of the Service Desk, of this company and explain additional service offerings that could benefit this customer
Recurring Incidents				Problem identification				Match on existing Problem Record (PR) or create a new one

Managing the Service Desk Function

Classification and closure codes and criteria				Classification Process Review				Revised processes and revised lists of classification and closure codes
Reporting schedule and reporting requirements defined in SLAs, OLAs and UCs				Incident Reporting and Review				Reports with insight and recommendations
Established schedule and scope defined in the Service Desk policies and documentation				On-going training				Staff trained with people skills, knowledge of processes, procedures, tools and user applications & services
Established schedule and scope defined in the Service Desk policies and documentation				Periodic audits				Review and maintain the Service Desk policies, procedures and tools. Note exceptions with recommendations
Pre-release products in a clean staging environment with assistance from Release Management and Development				Pre-release Testing				Evaluation and recommendations regarding maintainability and usability
Pre-release products in a clean staging environment with assistance from Release Management and Development				Pre-release Training				Knowledge of functionality, known errors, problems and diagnostic tools
Establish a regular schedule to review active and exceptional Incidents against the relevant SLAs				Status Reviews				Clear communication and expectations with follow up on noted exceptions
Established schedule and scope defined in the Service Desk policies and documentation				Workload analysis				Reports with insight and recommendations

Incident Management
Incident Response Process

Event details, configuration details and relevant Service Level Agreements (SLAs)				Detect				Correlate event with configuration and verify service entitlement
When the event is actually a Service Request (SR)				Optional Functional Escalation to the Service Request Process				Create a new Service Request and then refer to the Service Desk function for the Service Request process
When the event is actually a Request for Change (RFC)				Optional Functional Escalation to Change Management				Link to an existing RFC or create a new RFC and then refer to the Change Management process flows
Event details and configuration details and SLAs				Record				Create an Incident Record (IR) to record the contact info, symptoms, initial diagnostics and configuration details
IR, prior Problem Records (PR), Known Errors (KE) and Requests for Change (RFC), configuration details and relevant SLAs				Classify				Update the IR with Category, Impact, Urgency, Priority and links to matched IRs, PRs, KEs or RFCs then assign to a resource and update the IR
IR and script (MAP) for initial support				Initial support				Update the IR with additional details and if restoration is done jump to Recovery
Transfer IR within IM or create new record to track external resources				Investigation				Update the IR with additional details and if restoration is done jump to Recovery
IR with appropriate linkages and history				Diagnosis				Document the work-around or solution with an action plan then transfer back to IM
Work-around or solution				Restore normal operations				Update the IR with restoration details
Means for recovering “lost data”				Recovery				Successful recovery of appropriate “lost data”
Formal sign off by the customer that the results are satisfactory				Closure				Update the IR with status and close the IR

Incident Ownership Tasks

When the Impact is significant or an SLA timer indicates that the SLA might be breached				Hierarchical Escalation				Status and recommendations
When there is an error in the Configuration Management Database (CMDB)				Improved accuracy in the CMDB				Make updates where authorized, otherwise notify Configuration Management that there is an apparent error in the CMDB
Impact, SLA and established policies				Incident Communication				Proactively inform users about an Incident that is impacting their service
Periodic reminders to update the customer, or action by the customer requesting status				Incident Monitoring				Get updates and give status on the Incident, Problem, Known Error or Request for Change
Periodic reminders linked to the SLA or to Incident Management policies				Incident Tracking				Get updates from the resources (internal or external) working on the Incident, Problem, Known Error or Request for Change
When the Incident cannot be matched to an existing Problem Record or Known Error or when the Incident has a Major Impact				Invoke the Problem Management process				Link this IR to an existing Problem Record (PR) or create a new PR and then refer to the Problem Management process flows

Management Tasks for Incident Management

Reporting schedule and reporting requirements defined in SLAs, OLAs and UCs				Management information and reports				Reports with insight and recommendations
Established schedule and scope defined in the Incident Management Process documentation				Periodic audits				Review and maintain the Incident Management Process documents and relevant policies and procedures Note exceptions with recommendations

Classification Process Expanded from Annex 5D

Incident Record (IR)				Support staff allocation				Assign to a resource and update the IR
Configuration details and relevant SLAs				Basic fact finding				Update the IR with Category, Impact, Urgency, Priority
Prior Problem Records (PR), Known Errors (KE) and Requests for Change (RFC)				Inquiries on historical data				Update the IR with links to matched IRs, PRs, KEs or RFCs
IR and script (MAP) for initial support				Diagnostic data search				Update the IR with additional details
IR with appropriate linkages and history				Resolution attempt				If restoration is done jump to Recovery
When the Impact is significant or an SLA timer indicates that the SLA might be breached				Hierarchical Escalation				Status and recommendations, then allocate additional resources
When the Problem is not resolved in a timely manner				Functional Escalation to Problem Management				Link this IR to an existing Problem Record (PR) or create a new PR and then refer to the Problem Management process flows

Problem Management

Incident details, configuration details and SLA				Problem identification and recording				Create a new Problem Record, document possible workarounds or solutions and initiate the Problem Control sequence
Problem Control Process
Problem Record with details and a resource work-load evaluation				Problem classification				Set the Category, Impact, Urgency and Priority, assign resources and update the Problem Record
Possible tentative work-around or solution and history of recent changes				Problem investigation				Document the approved work-around or proposed solution
Techniques including Kepner & Tregoe, Ishikawa, Brainstorming and Flowcharting				Problem diagnosis and / or Error Identification				Document the Root Cause Create a Known Error and either initiate the Error Control sequence or branch to training or procedural updates
Error Control Process
Known Error, Problem and Incident details, configuration details and SLA				Error assessment				Create a Request for Change Set the Category, Impact, Urgency and Priority then update the Known Error Record
Execution through the Change and Release Management processes or by managing the vendor				Error resolution Error Closure Error Review				Structural Change with resolution to the satisfaction of the user Update (close) the Known Error, Problem and Incident Records
Proactive Problem Management
Fragile components, recurring problems, training needs, documentation gaps, vendor updates and user meetings				Problem trend analysis				Opportunities for cost justifiable improvements. Create a new Problem Record and initiate the Problem Control sequence
Volume of incidents, Impact, duration, costs to resolve, costs to the business				Proactive problem prevention				Opportunities for cost justifiable improvements. Create a new Problem Record and initiate the Problem Control sequence.

Management Tasks for Problem Management

Problem with a major impact and the Problem resolution steps				Major Problem Review				What was done right What was done wrong What could be done better Actions to prevent recurrence
Reporting schedule and reporting requirements defined in SLAs, OLAs and UCs				Management information and reports				Reports with insight and recommendations regarding Problem Records, Known Errors and Requests for Change
Established schedule and scope defined in the Problem Management Process documentation				Review and maintain the Knowledge Base				Updated Knowledge Base with Problem Records, Known Errors, workarounds and solutions Also delivery training on the tools
Established schedule and scope defined in the Problem Management Process documentation				Periodic audits				Review and maintain the Problem Management Process documents and relevant policies and procedures. Note exceptions with recommendations

Kepner and Tregoe Analysis Process

Incidents, Impact, configuration details and SLAs				Define the problem				Problem statement with “occurrence” and “results”, but avoid jumping to a conclusion
Problem statement with history including a history of recent changes				Describe the problem				Identity -- what is the problem Location -- where does it occur Time -- when does it occur Size -- what is affected
Problem details, diagnostic data where possible along with expertise and further investigation				Establish possible causes				Prioritized list of possible causes
Prioritized list of possible causes along with testing criteria and methodologies				Test the most probable cause				Test results and analysis data narrowing the list of probable causes
Identified probably cause and a resolution technique				Verify the true cause				User confirmation that the problem is resolved

Configuration Management
Core Configuration Management Process

At the start of the project and when starting on new aspects of the environment				Planning				Define and publish the scope, policies and procedures with special attention on the ”level” to be tracked
Inventory with all available records on ownership, licensing and usage				Identification and Registration				Create and update the Configuration Items (Cis) and document the relationships between them
Enforce policy that no physical change is made without going through Change Management				Control				Assurance the inventory is licensed, authorized, secured and accurately recorded in the Configuration Management Database (CMDB)
Status updates during the life cycle of a CI				Status Accounting				Maintained history with status on each CI to ensure traceability
Physical check of assets matched against the CMDB baseline				Verification and Audit				Detect errors and identify appropriate corrective actions
Periodically as defined in the Configuration Management policy or when an exception is detected				Reporting				Report on the inventory with emphasis on exceptions and recommended corrective actions

Supporting the Change Management Process

Proposed Request for Change (RFC)				Record				RFC entered into CMDB and linked to relevant details
RFC linked to appropriate configuration details				Assess impact				Risk assessment passed to Change Management
RFC with risk, impact and resource assessments				Tracking				RFC updates as requested by Change Management and the other parties to this RFC
Build documentation linked to the RFC				Librarian				Load the build documentation into the Configuration Management Database (CMDB)
Documentation on hardware, software, processes and training				Librarian				Check documentation into the Definitive Software Library (DSL)
RFC, FSC, RS and user acceptance testing sign off				Notification				Notification to all that will be impacted by this change
Release Unit with proper licensing and documentation				Librarian				Release Unit into DSL/DHS and distributed as required
Notification from the Change Manager that the Change was attempted				Closure				Configuration details updated and RFC closed with status. If the Change was backed-out, then create a new RFC and start over

Management Tasks for Configuration Management

Periodically as defined in the Configuration Management policy or on request				Baseline				Record the configuration at a point in time to support the Change, Release Verification and Audit processes
All personnel should report discrepancies				Correction				Verify, audit, correct and recommend appropriate corrective action
Incidents, Problems, Known Errors, Request for Change, etc				Data Administration				Ensure all relevant artifacts (physical and logical) can be entered, tracked and related
Automation tools to discover details about the environment for Identification or Verification				Discovery				Review the results and update the CMDB reporting on exceptions and plans for correction actions
Software, licensing, documentation and all supporting materials				Librarian				Update the CMDB and physically archive the master copies in the software/documentation libraries
Accurate inventory of licensing on-hand compared to licensing in use				License management				Report on exceptions and take responsibility for corrective actions
Established schedule and scope defined in the Configuration Management Process documentation				Management information and reports				Report on exceptions with recommendations for action
Established schedule and scope defined in the Configuration Management Process documentation				Periodic reviews				Review and maintain the Configuration Management Process documents and relevant policies and procedures. Note exceptions with recommendations
Software releases and hardware spares				Recording				Support Release Management by tracking the inventory in the DSL and Definitive Hardware Store (DHS)
Requests from the business and other ITIL disciplines				Service				Support the business and the ITIL disciplines through updates, reports and investigations
Evaluate alternatives when starting and manage the tool once it is in use				Tool administration				Cost effective tool, properly configured and administered including tuning and backups
When starting and periodically thereafter				Training				All staff trained on policies especially license management

Change Management
Normal Change Authorization Process

Proposed Request for Change (RFC)				Filter				Accept or reject the proposed RFC
RFC				Registration				RFC passed to Configuration Management for registration and assessment
RFC linked to appropriate configuration details				Assess risk				Risk assessment with Impact from Configuration and resources from Release Management
RFC with risk, impact and resource assessments				Categorization				RFC updated with Category, Impact, Urgency and Priority and assigned to Change Authorization Model
RFC with assessment and business justification				Approval through appropriate Change Authorization Model				RFC added to Forward Schedule of Changes (FSC) and Projected Service Availability (PSA)
RFC with justification				Change Authorization Model for Emergency Changes				(Refer to the Urgent Change Authorization Model described below)
RFC with justification				Change Authorization Model for Minor Changes				Change Manager can authorize or reject
RFC with documentation to define a Standard Process taken to the Change Advisory Board (CAB)				Change Authorization Model for “Standard” Changes				Well documented Standard Process released for implementation as needed
Establish schedule, publish agenda and provide RFC details and Change history				Change Authorization Model for Major Changes				Change Advisory Board (CAB) meets to authorize or reject
RFC with justification				Change Authorization Model for Massive Changes				Change Manager takes RFC to Executive Committee to authorize or reject
RFC with FSC and user acceptance testing sign off				Authorization				Configuration Management distributes Notification to relevant parties
At the appropriate time, the Change Implementer distributes the “release” and prepares for the implementation				Implementation				Release Unit installed and ready for User testing
Release Unit installed and ready for User testing				Evaluation				User sign off or agreement to back-out
Either change is in effect or it is cleanly backed-out				User acceptance				Stable production environment along with list of change induced incidents
Stable production environment along with list of change induced incidents				Closure				Configuration Management then closes the RFC
Periodically as defined in the Change Management policies				Post Implementation Review				Review all changes in the recent period and initiate appropriate corrective actions

Urgent Change Authorization Process

Identification of urgent need				Change Advisory Board / Emergency Committee				Authorize or reject based on Impact, Priority and Risk
Authorization of the preliminary RFC with detailed scope				Build and Test				Change Manager is responsible for supervision of build, test, implementation and optional back out
At the appropriate time, the Change Implementer distributes the “release” and prepares for the implementation				Implementation				Patch installed and ready for User testing
Release Unit installed and ready for User testing				Evaluation				User sign off or agreement to back-out
Either change is in effect or it is cleanly backed-out				User acceptance				Stable production environment along with list of change induced incidents
Stable production environment along with list of change induced incidents				Closure				Change Manager works with Configuration Management to document and close the RFC
Periodically as defined in the Change Management policies				Post ImplementationReview				Review all changes in the recent period and initiate appropriate corrective actions

Urgent Change Authorization Process

Periodically				Awareness Campaign				Emphasize benefits of the process and strive for complete compliance
Established schedule and scope defined in the Change Management Process documentation				Management information and reports				Report on exceptions with recommendations for action
Annually, or more frequently if needed				Periodic audits				Review all documentation, minutes, and logs and validate processes are followed
Established schedule and scope defined in the Change Management Process documentation				Periodic reviews				Review and maintain the Change Management Process documents and relevant policies and procedures. Note exceptions with recommendations
When beginning				Planning				Create Mission Statement, start awareness campaign, define change windows (slots), pick tool, document the process and train participants

Release Management
Standard Release Process

Request for Change (RFC) linked to appropriate configuration details				Assess resources				Resource assessment
RFC with assessment and business justification				Planning				Forward Schedule of Changes (FSC), Projected Service Availability (PSA) and Release Schedule (RS)
Procurement planning				Make or buy evaluation				Issue purchase orders or do in-house design
Authorized RFC with RS				Build				Monitor build progress and verify conformance with requirements
Release Unit into clean test area				Fit-for-Purpose Testing				Coordinate user acceptance testing
Documented back-out plan				Test the back-out plan				Sign off on the suitability of the backout plan
Release Unit into clean test area				Integrity				Ensure release is licensed, secure, traceable and as per authorization
User documentation				Training				Coordinate user and support training
Fit-for-purpose test results				Release Acceptance				User acceptance testing sign off
RFC, FSC, RS and user acceptance testing sign off				Verify notification is distributed by the Configuration Manager through the Service Desk				Notification to all who will be impacted by this change
Release Unit with proper licensing and documentation				Distribution				Release Unit into DSL/DHS and distributed as required
At the appropriate time				Implement				Release Unit installed and ready for User evaluation
Release Unit installed and ready for User evaluation				Audit integrity as installed				User sign off or agreement to back-out
Either change is in effect or it is cleanly backed-out				Activate release or execute the back-out process				Stable production environment along with list of change induced incidents
Stable production environment along with list of change induced incidents				Ensure configuration details are properly updated				Configuration details updated and RFC closed

Management Tasks for Release Management

Periodically				Awareness Campaign				Emphasize benefits of the process and strive for complete compliance
Established schedule and scope defined in the Release Management Process documentation				Management information and reports				Report on exceptions with recommendations for action
Established schedule and scope defined in the Release Management Process documentation				Periodic reviews				Review and maintain the Release Management Process documents and relevant policies and procedures Note exceptions with recommendation
When beginning				Planning				Create Mission Statement, start awareness campaign, document the process and train participants

Service Management
The ITIL Process Improvement Model

Incentive to change				Where do we want to be?				Vision Statement and documentation describing the business objectives to be achieved in suffi cient detail to be effective
Interviews and review of current documentation				Where are we now?				Assessment of the “as-is” organizational model, processes and policies
“Gap analysis” comparing the “as-is” with the “to-be”				How do we get where we want to be?				Documented and agreed action plan describing the “to-be” proposal
Defi ned metrics and methods for measuring and assessing those metrics				How do we know when we have arrived?				Reporting focused on exceptions with action plans for correcting weaknesses

The Demming Cycle

Incentive to change				Plan				Vision Statement and documentation describing the business objectives to be achieved in suffi cient detail to be effective
Documented and agreed action plan describing the “to-be” proposal				Do				Changes implemented
“Gap analysis” comparing the “asis” with the “to-be”				Check				Reporting focused on exceptions with action plans for correcting weaknesses
Documented and agreed action plan describing the required corrective actions				Act				Take action to bring the current state closer to the planned state

In the future I plan to work on diagrams for the remaining processes, including:

• IT Financial
• Capacity
• IT Service Continuity
• Availability

Revision History

Date	Version	Author	Description
1 Oct 2004~	0.1	Robert Perrine	Initial work on the Dependencies.
26 Oct 2004	0.2	Robert Perrine	Released version of the Dependencies.
26 Oct 2004	0.3	Robert Perrine	Initial version of the Synopsis pages.
30 Oct 2004	0.4	Robert Perrine	Released version of the Synopsis pages.
07 Nov 2004	0.5	Robert Perrine	Initial version of the Memory pages.
21 Nov 2004	0.6	Robert Perrine	Released version of the Memory pages.
27 Nov 2004	0.7	Robert Perrine	Consolidated Memory and Synopsis into this ITIL Analysis guide.
29 Nov 2004	0.8	Robert Perrine	Consolidated Dependencies into this ITIL Analysis guide.
30 Nov 2004	0.9	Robert Perrine	Initial work on Analysis sections
2 Dec 2004	1.0	Robert Perrine	Initial work on Key Flow Diagrams
5 Dec 2004	1.1	Robert Perrine	Initial work on Collaborative sections
6 Dec 2004	1.2	Robert Perrine	Continued work on Key Flows, Analysis and Collaborative
12 May 2005	1.3	Robert Perrine	Minor tweaks before publishing via my web site.
26 Nov 2005	1.4	Robert Perrine	Removed content now duplicated in the Quick Reference
11 Nov 2007	1.5	Robert Perrine	Moved some content to ITIL Dependencies and reformatted the remainder.