Creating an I.T. Service Definition
I
recently had a go at creating my first attempt at a full-detail Service
Definition (as opposed to a Service Catalog entry) to cover enterprise BPI work requests.
So far I have come up with the broad Service
Description headings and sub-headings and used a real-life BPI request
to provide examples of how those headers may be filled.
This is an incomplete work based upon resources
shown in the bibliography.
I have attempted to cover most key elements
identified for a Service Descriptor artifact even though some of those elements
may not require completion through bespoke work deliverables.
I would appreciate any critical feedback on
whether I am on the right track for designing a Service Definition and what
things I may have overlooked.
Service Description
Elements
There appear to be at-least ten Service Description Elements:
1. Service
Description
2. Business
Benefits
3. Risk
Identification
■ Business risk
■ I.T. risk
4. Service
Price
■ Model
■ Unit
cost
5. Service
Design
■ Functional
■ Resilience and DR
■ Monitoring
■ Alerting
■ Reporting
6. Service
Provision Resourcing
7. Service
Capacity
8. Service
Warranty
■ Parameters
■ Prioritisation
9. Service
Commitments
■ SLA
– CFS
■ OLA
– RFS & inter/intra-department
10. Authorisation
11. Usage
■ General
Operation
■ Required
Software
■ Web
Interface
■ Support
12. Change
and Upgrades
Partially-worked
Example
1. Service
description
Title
e.g. Bespoke
Integration, Reporting and Business Process Improvement for monthly
board-reporting of Divisional Management metrics
Summary
e.g. Integration automation to increase speed of monthly
regional report production through reduced manual processing and
remediation of inherent human error
Features
e.g. Created as transportable WinAutomation™ executable
(or Visual Basic macro), will permit its application to standardised regional
report spreadsheets for all enterprise regions
Functions
e.g. Reads all data from each regions’ individual
projects Report workbooks as they are delivered. Compiles regional
summary report.
Parent or Partners Service(s) (from defined Business Services)
e.g. XXX State Report Visual Basic macro
and monthly Project Report Visual basic macro
Availability Times & Maintenance Window(s) – a schedule
e.g. 24x7 local-system access for those to whom this
service is deployed
2. Business
benefits
Speed / delivery timeliness,
e.g. will reduce current 1-man-week per month labour
expenditure for reports production
Cost
savings,
e.g. labor savings in terms of regained productivity for
the regional and national managers
Staffing reduction/load-sharing,
e.g. automated data compilation of the monthly reports
can now be performed by staff other than the regional managers
Staff skilling/hiring,
e.g. Less highly skilled operators required for report
compilation
Hours of attendance,
Repeatability,
e.g. consistent output through reduced tedium in the
monthly compilation of the 26-plus project reports
Error reduction,
e.g. less likelihood of missed or mal-transposed data
from project to regional summary reports
Risk reduction,
e.g. single-person dependency reduced by making it
possible for other-than the regional managers to produce the monthly
summary reports
3. Risk
Identification
Business
Operational impact – consult with business to identify impact
Legal Impact– consult with business to identify impact
Information Systems
Operational Impact
e.g. Staff with the required (WinAutomation or Visual
Basic) automation skills must be retained
RFS Systems Impact
e.g. No internal I.S. services interface with this
service offering
4. Service
Price
Model - the way in which this service will be charged to the
customer on a one-time or recurring basis, and any additional charges which may
be apparent.
Initial, Refinement/Enhancement, Warranty and post-warranty should all be considered
e.g.
This service will be internally chargeable to
the requesting department at an agreed one-time value based on estimated/quoted labor
The total service estimate shall not
exceed 160 hours labor - 40 hours design, 120 hours develop and deliver.
The estimated value will derive from the
initial analysis and proposed design; to prototype, debug, refine,
document, and deploy this service.
Prototype refinement costs will be
chargeable as defined in the following per-deliverable Unit Cost
section
Warranty labor costs are covered in the
development labor estimate based on the initial analysis of this service’s
design
Post-warranty support will be covered under
each departments standard I.S. charge-back contribution
per deliverable Unit Cost – charges for first and subsequent
deployments of this service
e.g.
Initial analysis suggests approximately 40
hours will be required to design, develop and deliver this service.
A further labour charge of up to 16 hours
is estimated to refine the delivered prototype to meet User Acceptance.
For each additional state into which
this service is deployed and additional 8 hours labour charge will apply
5. Service
Design
Analysis – description pending
Design and Prototyping - description pending
Build - description pending
Testing - description pending
Debugging - description pending
Documentation - description pending
User Training - description pending
Deployment - description pending
Warranty - description pending
Support - description pending
6. Service
Provision Resourcing – estimated persons and duration's required
Analysis / Requirements definition –
I.S.
e.g. I person for 3~4 hrs
Design – I.S. or
external
e.g. 1 person 8 hrs
Prototyping – I.S. or external
e.g. 1 person 16 hrs
Build – I.S. or
external
e.g. 1 person 16 hrs
UAT – Business and Build
resources
e.g. 1 person 2~4 hrs
Debugging – Build
resource
e.g. 1 person 16 hrs
Documentation – Design and Build resources
e.g. 2 persons 16 hrs combined
Deployment – I.S.
e.g. 1 person 30 mins per deploy
Training – Design and/or Build and/or I.S.
resources
e.g. 1 person 4 hrs per deployment
Warranty – Build and/or I.S. resources
e.g. 2 persons 4 hrs combined
First contact Support – I.S. Service Desk
< 1% Service Desk resource overhead
7. Service
Capacity
Baseline - description pending
Growth Projection - description pending
8. Service
Warranty
Parameters
Period
e.g. 30 days elapsed starting from User Acceptance
Coverage
Bug fixes – all non-functional or erroneous-actions performed by the service
will be addressed as “bugs”
Design refinement – as defined in per deliverable Unit Cost section
Resourcing / Prioritisation
Bug Fixing
Design refinement – matching requirements
Enhancement requests – extended requirements
9. Service
Commitments:
☼ Service Level
Agreement (SLA) – CFS – between I.S. and Customer
■ What will occur?
► First
Response (TTR)
► System
Recovery (TTF or RTO)
► Full
Data Access Recovery (RPO)
■ By when?
► Response
Time Objectives (TTR)
Service viability assessment – Time of assessment delivery from time
of business request
[max 10 business days elapsed]
Service Design – time to deliver a design from delivery of “viable”
assessment
[max 40 expended hours]
Service Delivery – time to deliver a working prototype for UAT, from
time of design completion
[T.B.D based on
design complexity but guideline max 120 expended hours else “too big” to offer
as a service, needs to become a Project]
Warranty bug-fix – time to first contact upon warranty bug
notification
[tbd]
Warranty design refinement - time to first contact upon receipt of
refinement request
[tbd]
Post-warranty support - time to first contact upon incident
notification
[Standard Service Desk TTR SLA unless otherwise negotiated]
►
Recovery Time Objectives (TTF)
System Functionality restored [tbd]
All data
accessible
[tbd]
■ To what degree?
►
Recovery Point Objective (RPO) – anticipated worst-case data loss - example pending
Whom is responsible for delivery? - example pending
Escalation thresholds [tbd]
Escalation Methods & Procedures - description
pending - example pending
Breach penalties
[tbd]
☼ Supporting
Operational Level Agreements (OLA’s) – RFS – Internal to I.S. or between
I.S. and any third-party Service Providers
Supporting systems dependencies? - example pending
Supporting system SLA’s
[tbd]
Whom is responsible for OLA deliveries? - example pending
OLA escalation thresholds
[tbd]
OLA escalation methods & procedures - description
pending - example pending
☼ Dependent
Operational Level Agreements - OLA’s or Inter/Intra-departmental
business agreements
Dependent systems or services? - example pending
Whom is responsible for ensuring service delivery to third-parties - example pending
OLA escalation thresholds
[tbd]
OLA escalation methods & procedures - description
pending - example pending
10. Authorisation
- who is authorising time and expenditure for this service - example pending
11. Usage
- Text or links describing how to access or use functions of the service.
Self-service resource links. Configuration information. - example pending
Software - Links to standard software used to access the service. -
example pending
Web interface details - URLs etc - example pending
Getting Help - Standard Service Desk links and any additional contacts
for clients to receive service support. Links to relevant FAQs and self-service
information. - example pending
12. Change
and Upgrades - description pending - example pending
Glossary
|
|
|
CFS
|
Customer Facing Service
|
defines the characteristics and
behaviour of a particular service as seen by the customer
|
OLA
|
Operational Level Agreement
|
an agreement between an IT
service provider and another part of the same organization
|
RFS
|
Resource Facing Service
|
supports CFSs but are not seen
or purchased directly by the customer.
(e.g., “DHCP” [RFS] is required
for “Email” [CFS])
|
RPO
|
Recovery Point Objective
|
RPO (Recovery Point Objective)
refers to the amount of data at risk. It's determined by the amount of time
between data protection events and reflects the amount of data that
potentially could be lost during a disaster recovery. The metric is an
indication of the amount of data at risk of being lost.
|
RTO
|
Recovery Time Objective
|
RTO (Recovery Time Objective)
is related to downtime. The metric refers to the amount of time it takes to
recover from a data loss event and how long it takes to return to service.
RTO refers then to the amount of time the system's data is unavailable or inaccessible
preventing normal service.
|
SLA
|
Service Level Agreement
|
A formal, negotiated document
that defines (or attempts to define) in quantitative (and perhaps
qualitative) terms the service being offered between an IT service provider
and a customer.
|
TTF
|
Time To Fix
NOTE: Sometimes referred to as:
Time To Resolve or Time To
Recover
|
|
TTR
|
Time To Respond
NOTE: can be confused with:
Time To Resolve or Time To
Recover
|
the point at which someone
takes ownership of the issue
|
URL
|
Universal Resource Locator
|
one type of
Uniform Resource Identifier (URI); the generic term for all types of names
and addresses that refer to objects on the World Wide Web.
|
WSLA
|
Web Service Level Agreement
(Language)
|
The Web Service Level Agreement
(WSLA)
framework is targeted at
defining and monitoring SLAs for Web Services
|
Bibliography
Business-focused
IT and Service Excellence – David Miller
Application or System Testing
When conducted properly, should follow a logical progression of test phases, where each subsequent phase builds upon the proofing provided by the former phase(s)
Order of Test Phases
Unit >>
Smoke / Sanity testing >>
Integ >>
Func >>
System - Functional and Non-Functional >>
Perf >>
Regression >>
UAT >>
Pilot/Field >>
PVT
Purpose of Test Phases