Tuesday 13 October 2015

Creating an I.T. Service Definition (as opposed to a Service Catalogue entry)


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 Resourcingestimated 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 assessmentTime of assessment delivery from time of business request                
[max 10 business days elapsed]
                                                Service Designtime to deliver a design from delivery of “viable” assessment                                   
[max 40 expended hours]
                                                Service Deliverytime 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-fixtime 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




No comments: