Purpose: To provide a single source of consistent \ninformation on all of the agreed services, and ensure \nit\"s widely available to those who are approved to \naccess it.

\n

\n

\n

Goal: To ensure that a Service Catalog is produced and \nmaintained, containing accurate info on all operational \nservices and those preparing to be run operationally.

\n

\n

\n

Objective: to manage the information contained within \nthe Service Catalog and to ensure that it is accurate \nand reflects the current details, status, interfaces and \ndependancies of all services that are being run, or are \nin preparation to run in the live environment.

\n

\n

\n

4.1.2 Scope

\n

To provide and maintain acurate info on all services in \ntransition to production.

\n

Activities should include:

\n

Service definition
Production and maintenance of the accurate SC
Interfaces, dependancies and consistency \nbetween the Srv. Catalogue and S. Portfolio
Interfaces and dependancies between services \nand supporting services from SC and CMS
Interfaces and dependancies between all \nservices, and supporting components and CIs \nfrom SC and CMS

\n

\n

\n

4.1.3 Value to the Business

\n

SC is a single source of consistent information on all of \nthe provided IT services. All areas of business can view \nan accurate, consistent picture of IT services, their \ndetails and status. It contains a Customer View of \nservices, how they should be used, business proces \nthey enable and QOS that the Customer can expect \ndor each of them.

\n

\n

\n

4.1.4 Policies, principles and basic concepts

\n

Service Portfolio should include all the future \nrequirements for services.

\n

Service Catalogue should include all pending and \ncurrent services, with the summary of their \ncharacteristics, and details of the customers and \nmaintainers of each.

\n

Policies should be developed for Service Portfolio and \nfor Service Catalog: recorded details, statuses, and \nresponsibilities.

\n

Service Catalog Aspects:

\n

Business Service Catalog – A customer view: \nIT services delivered to the customer, including \nrelations to business units and business \nprocesses it supports.
Technical Service Catalog – IT Services \nrelated to customer – related with \ninfrastructure: supporting and shared services \nand CIs that support the provision of service. \nThis view should not be presented to a \ncustomer.

\n

\n

\n

4.1.5 Activities, methods and techniques

\n

Agreeing and documenting a service definition \nwith all relevant parties.
Interfacing with Service Portfolio Management \nto agree the contents of SP and SC.
Production and maintainance of SC in \nconjunction with SP.
Interface with business and ITSCM on the \nrelations of business units and processes with \nIT Services, therefore with contents of the \nBusiness Service Catalogue
Interface with support, suppliers and Config \nManagement on relations contained in Technical \nService Catalogue.
Interface with Business Relationship \nManagement and SLM to ensure that info \n(which info?) is aligned with the business and b. \nprocesses

\n

\n

\n

4.1.6 Trigers, inputs, outputs and interfaces

\n

Inputs:

\n

Busines and IT strategy, plans, financial plans, \ncurrent and future requirements from Service \nPortfolio
Business Impact Analysis (impact, priority and \nrisk related to each service or changes to svc. \nrequirements)
Business requirements: info on agreed, new or \nchanged business reqs from Service Portfolio
Service Portfolio
CMS
Feedback from all other processes

\n

\n

\n

Triggers are changes in business reqs & services, \nconsequently RFCs and ChM process. In the end, new \nservices will be introduced, existing will be changed or \nretired.

\n

\n

\n

Outputs:

\n

Definition of the service documentation & \nagreement
Updated data on services and service \nrequirements in Service Portfolio
Updated data on live services in Service Catalog.

\n

\n

\n

4.1.7 Information management

\n

Main information is in Service Catalogue.

\n

Main input for the Catalogue is from Service Portfolio \nand the business (BRM or SLM)

\n

SC information has to be maintained through Change \nManagement process.

\n

\n

\n

4.1.7 KPIs

\n

Two most important:

\n

Percentage of live services recorded and \nmanaged in Service Catalog
Number of variances between the SC info and \nlive services

\n

Others:

\n

Percentage increase in completenes of Business SC \nagainst operational services (business users\" \nawareness of the provided services)

\n

IT Staff awareness of the technology which \nsupports the services:\n
- Percentage increase in completenes of \nTechnical SC against supporting IT \ncomponents
- Percentage of tickets without the \nappropriate service info (SD awareness)
\n

\n

\n

\n

4.1.9 Challenges, CSFs and Risks

\n

Major challenge is to maintain the accurate SC as a \npart of SP and CMS and SKMS.

\n

This is a cultural issue, so it has to be propagated \nthat SC and SP are essential points of info and that \neveryone has to use, audit and maintain them.

\n

\n

\n

CSFs:

\n

Accurate SC

\n

Business users awareness of the provided \nservices
IT staff awarenes of the technology \nsupporting the services

\n

\n

\n

Risks:

\n

Data inaccuracy in SC and not being under \nChange control
Poor acceptance of the SC
Inaccurate input data from SP, business or IT
Inadequate Tools and Resources
Poor access to accurate Change M. info and \nprocesses
Poor connection to CMS and SKMS
Avoidance of SP and SC usage
Standard level of detail can be too low or \ntoo high. Should be the same as in CMS and \nSKMS

\n

\n

\n

$\"graphic\"$

\n

My Repository 2