Policies, principles and basic concepts
Over the years, organizations’ IT infrastructures have grown and developed, and there may not be a clear picture of all the services currently being provided and the customers of each service. In order to establish an accurate picture, it is recommended that an IT Service Portfolio containing a Service Catalogue is produced and maintained to provide a central, accurate set of information on all services and to develop a service-focused culture.
The Service Portfolio should contain all the future requirements for services and the Service Catalogue should contain details of all services currently being provided or those being prepared for transition to the live environment, a summary of their characteristics, and details of the customers and maintainers of each. A degree of ‘detective work’ may be needed to compile this list and agree it with the customers (sifting through old documentation, searching program libraries, talking with IT staff and customers, looking at procurement records and talking with suppliers and contractors etc.). If a CMS or any sort of asset database exists, these may provide valuable sources of information, although they should be verified before inclusion within either the Service Portfolio or Service Catalogue. The Service Portfolio is produced as part of Service Strategy and should include participation by those involved in Service Design, Transition, Operation and Improvement. Once a service is ‘chartered’ (being developed for use by customers, Service Design produces the specifications for the service and it is at this point that the service should be added to the Service Catalogue.
Each organization should develop and maintain a policy with regard to both the Portfolio and the Catalogue, relating to the services recorded within them, what details are recorded and what statuses are recorded for each of the services. The policy should also contain details of responsibilities for each section of the overall Service Portfolio and the scope of each of the constituent sections.
The Service Catalogue Management process produces and maintains the Service Catalogue, ensuring that a central, accurate and consistent source of data is provided, recording the status of all operational services or services being transitioned to the live environment, together with appropriate details of each service.
What is a service? This question is not as easy to answer as it may first appear, and many organizations have failed to come up with a clear definition in an IT context. IT staff often confuse a ‘service’ as perceived by the customer with an IT system. In many cases one ‘service’ can be made up of other ‘services’ (and so on), which are themselves made up of one or more IT systems within an overall infrastructure including hardware, software, networks, together with environments, data and applications. A good starting point is often to ask customers which IT services they use and how those services map onto and support their business processes. Customers often have a greater clarity of what they believe a service to be. Each organization needs to develop a policy of what is a service and how it is defined and agreed within their own organization.
To avoid confusion, it may be a good idea to define a hierarchy of services within the Service Catalogue, by qualifying exactly what type of service is recorded, e.g. business service (that which is seen by the customer). Alternatively, supporting services, such as infrastructure services, network services, application services (all invisible to the customer, but essential to the delivery of IT services) will also need to be recorded. This often gives rise to a hierarchy of services incorporating customer services and other related services, including supporting services, shared services and commodity services, each with defined and agreed service levels.
When initially completed, the Service Catalogue may consist of a matrix, table or spreadsheet. Many organizations integrate and maintain their Service Portfolio and Service Catalogue as part of their CMS. By defining each service as a Configuration Item (CI) and, where appropriate, relating these to form a service hierarchy, the organization is able to relate events such as incidents and RFCs to the services affected, thus providing the basis for service monitoring and reporting using an integrated tool (e.g. ‘list or give the number of incidents affecting this particular service’). It is therefore essential that changes within the Service Portfolio and Service Catalogue are subject to the Change Management process.
The Service Catalogue can also be used for other Service Management purposes (e.g. for performing a Business Impact Analysis (BIA) as part of IT Service Continuity Planning, or as a starting place for re-distributing workloads, as part of Capacity Management). The cost and effort of producing and maintaining the catalogue, with its relationships to the underpinning technology components, is therefore easily justifiable. If done in conjunction with prioritization of the BIA, then it is possible to ensure that the most important services are covered first. An example of a simple Service Catalogue that can be used as a starting point is given in Appendix G.
The Service Catalogue has two aspects:
The relationship between these two aspects is illustrated in Figure 4.3.
Figure 4.3 The Business Service Catalogue and the Technical Service Catalogue
Some organizations only maintain either a Business Service Catalogue or a Technical Service Catalogue. The preferred situation adopted by the more mature organizations maintains both aspects within a single Service Catalogue, which is part of a totally integrated Service Management activity and Service Portfolio. More information on the design and contents of a Service Catalogue is contained in Appendix G. The Business Service Catalogue facilitates the development of a much more proactive or even pre-emptive SLM process, allowing it to develop more into the field of Business Service Management. The Technical Service Catalogue is extremely beneficial when constructing the relationship between services, SLAs, OLAs and other underpinning agreements and components, as it will identify the technology required to support a service and the support group(s) that support the components. The combination of a Business Service Catalogue and a Technical Service Catalogue is invaluable for quickly assessing the impact of incidents and changes on the business. An example of relationships between the Business and Technical portions of a Service Catalogue is shown in Figure 4.4.
Figure 4.4 Example Service Catalogue