I developed this for a project that I am currently involved in. The project aim is to develop a documentation framework for the provision of IT as a Service. I devised the framework using the Microsoft Operations Framework as ‘glue’ between other frameworks like ITIL. I thought I’d share it as it might be useful to others who are in a similar situation. The end result is a relatively compact set of documents for each service offered by IT.
2. Presentation Structure
• Introduction
• Framework for Service?
– Triangular Relationships
• Testing Ideas
– Operational Process Flow
– Service Mapping
– Operation and Service Guide
– Operations Plan
– Knowledge Base
• Documentation Framework
• Credits
3. Introduction
• Learn more about me http://uk.linkedin.com/in/sdenton35/
• Experienced realignment before
– Opportunity to apply lessons learned
• Manage depth and impact of change
– Aiming for ITIL based services
– Same people, new roles
• Opportunity for real improvement
– Change habits
• Applied some ‘zero-based thinking’
4. Framework for Service – The Service Triangle
Governance
Service
Monitoring
and Control
Operational
Delivery
Support
6. Framework for Service?
ISO
20000
ISO
22301
ISO
27001
ISO
31000
ISO
38500 ISO
9001
ISO
50001
1a
•ISO20000
•IT Service Management
1b
•ISO 22301
•Business Continuity Management
1c
•ISO 27001
•Information Security Management
1d
•ISO 31000
•Risk Management
1e
•ISO 38500
•Corporate Social Responsibility (CSR) and Governance
1f
•ISO 9001
•Quality Management
1g
•ISO 50001
•Energy Management System
[1] Industry
Standards
7. Framework for Service?
1 to 4
Framework
5
Processes,
Guidance &
Tools
6
Automation
7
The
Business
• Our Operational Framework
5
• Scenario Specific
• Solution Acceleration
6
• Efficiency and Accuracy
• Monitoring and Control
7
• Input and Requirements
• Feedback
8. Framework for Service?
• Connecting Framework
– Needs to be compatible with
other standards ITIL, COBIT,
ISO
– Content needs to be
technology agnostic
– Need something developed to
work with what we have
• Researched Options
– Why not utilise the Microsoft
Operations Framework 4.0?
3
Connecting
Framework
9. Framework for Service?
• Microsoft Operations Framework 4.0
– Readily available (free!) guidance for full service lifecycle
– Manageable and immediately applicable
– Leverages existing resources
– Designed to be digestible
– Question based for customisation and checklists
– Usable in parts
– Scalar
– Compatible with other standards ITIL, COBIT, ISO
10. Framework for Service?
• Main focus of ITIL is
on the ‘what’,
whereas Microsoft
Operations
Framework
concentrates on the
practical side of the
‘what’ and the ‘how’
Click image below to open file
11. Framework for Service?
MOF
It is practical guidance
for everyday IT
practices and activities,
helping users establish
and implement reliable,
cost-effective IT
services.
ITIL
A framework of best
practice techniques to
facilitate the delivery of
high-quality information
technology services.
ITIL outlines an
exhaustive set of
management
procedures to support
organizations in
achieving both value
and quality in IT
operations.
ITSM
An approach that
combines proven
methods such as
process management
and known industry
best practices, in the
area of IT Service
Management, to
enable any
organization to deliver
quality IT services that
satisfy customer
business needs and
achieve performance
targets specified within
service level
agreements.
12. Framework for Service?
• Phases describe goals,
activities and accountability for
each part of service lifecycle
• Service Management
Functions (SMF) provide
details of major activities in
each phase
• Underpinned by integrated
Management Reviews
14. Framework for Service?
• Where to start?
– Read published quick start guides e.g. Getting Started with MOF,
MOF Overview and Phase Overview documents (Plan, Deliver,
Operate, and Manage)
• Tested on with a small area of concern
– Picked a relatively complex service
– Tried a couple of activities to understand organisational fit
– Used published available job aids and templates
15. Documentation Framework
• Through testing ideas on a service a documentation
framework evolved
• The framework is divided into three key process streams:
– Governing – Those processes that control / regulate / direct the
Core and Enabling processes
– Core – Those processes that directly lead to satisfying the mission
statement
– Enabling – Those processes that facilitate / support / guide / enable
the Core and Governing processes
17. Service Delivery
Governing Governance
Service Monitoring
and Control
A sustainable well
managed business
Core Customers
Operational
Delivery
Performance,
Customer and
Employee
Satisfaction
Enabling Support
Customer and
Employee
Satisfaction
Process Stream Goal
19. Service Guide
• The objective of this document
is to:
– identify and describe the
Service
– identify the operational
requirements imposed by
Service and Operational
Agreements (SLA and OLA’s)
– define Service Monitoring and
Control requirements
Contents
1. The Services
2. Customer Centric Description
3. Who are the Users?
4. Service Support/Availability
5. Notifications
6. Team Organisation
7. Available Contact Methods
8. Underpinning Contracts
9. Unhappy Customer Escalation
10. Escalation: Teams We Escalate To
11. Service Level Objectives and Measures
12. Metric Definition
13. Costs Associated with the Service
20. Service Schedule
• The purpose of this document is to list
the operational work required to
operate the service successfully
• The document is intended to:
– Ensure that the work required to successfully
operate service has been identified and
described
– Reduce time spent by staff on reactive work
– Minimise service disruptions and downtime
through preventive work.
– Execute recurring and on-demand operation
tasks effectively and efficiently
– Act as a switchboard linking with Work
Instructions
Contents
1. Operational Requirements
2. Task Definition (from Glossary)
3. Table of Operational Tasks
21. Release and Deployment
• The purpose of this document is to
detail the requirements, design and
features of a modified service
• The document contents are limited to
elements that would not be captured in
revisions to other service documents
including Work Instructions which
would be made as part of the Release
and Deployment process
Contents
1. Justification and Goals
2. Usage Scenarios
3. Unsupported Scenarios
4. Assumptions and Dependencies
5. Business and User Requirements
6. Operational Requirements
7. System Requirements
8. Integration Requirements
9. Security Strategy
10. Conceptual Design
11. Timeline
12. Risk
13. Cost
22. Reliability
• The purpose of this document is to
describe for the service the functions
of :
– Availability
– Disaster Recovery
– Capacity
– Data integrity
– Monitoring
• The document would reference the
relevant Work Instructions
Contents
1. Availability Plan
2. Capacity Plan
3. Data Security Plan
4. Disaster Recovery Plan
5. Monitoring Plan
23. Architecture
• The purpose of this is to describe for
the service the architecture layers of :
– Mapping
– Software
– Infrastructure
– Information
• When combined with the architectures
of other services an overall
architecture would be created and
stored under the Service Portfolio
• Layers are only described if required
• Envisaged to comprise diagrams
rather than documents
Contents
1. Map
– Graphical display of a service that illustrates the various
components upon which successful delivery of that service relies.
Details dependencies between teams.
2. Software
– Documentation of a service’s software architecture. Focus on
bespoke (company specific alterations / customisations) not
reproducing vendor material.
3. Infrastructure
– Describes the structure and behaviour of the technology
infrastructure required by the service. It covers the client and
server nodes of the hardware configuration, the infrastructure
applications that run on them, the infrastructure services needed
by applications, the protocols and networks that connect
applications and nodes. It addresses issues such as performance
and resilience, storage and backup.
4. Information
– Describes the structural design of shared environments, methods
of organizing and labelling websites, intranets, and online
communities, and ways of bringing the principles of design and
architecture to the digital landscape.
24. Work Instructions
• The Operational Work Instructions will
include identification of:
– Relevant knowledge base material
– Responsibilities (i.e. which team)
– Permissions required
– Installation / Setup / Removal Requirements
• Work Instructions will be:
– Clear, concise and easily deliverable
– Tested
• Work Instructions will be linked to
process maps where multiple steps
are required e.g. Performing disaster
recovery
Contents
1. Unique Reference
2. Revision and Test History
3. Responsible Team
4. Permissions Required
5. Step-by-Step Description
6. Links to Knowledge Base material
25. “The second law of thermodynamics applies perfectly to human
beings.
It states that, left to itself, the entropy (or disorder) of an isolated
system will increase over time. In other words, unless something
acts on it, a system tends toward disorder. The human form of the
second law is that, left to ourselves, we humans will complicate
everything around us.
Why else would we attempt to have our IT systems handle every
known exception?”
Final Thought
26. Credits
• This presentation includes material taken from the
Microsoft Operations Framework
• The Microsoft Operations Framework 4.0 is provided with
permission from Microsoft Corporation and it’s use is
licensed under the Creative Commons Attribution
License. To view a copy of this license, visit
http://creativecommons.org/licenses/by/3.0/us/
Notas del editor
The Microsoft Operations Framework 4.0 is provided with permission from Microsoft Corporation and it’s use is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/us/.