Главная Обратная связь


Designing supporting systems, especially the Service Portfolio

The most effective way of managing all aspects of services through their lifecycle is by using appropriate management systems and tools to support and automate efficient processes. The Service Portfolio is the most critical management system used to support all processes and describes a provider’s services in terms of business value. It articulates business needs and the provider’s response to those needs. By definition, business value terms correspond to market terms, providing a means for comparing service competitiveness across alternative providers. By acting as the basis of a decision framework, a Service Portfolio either clarifies or helps to clarify the following strategic questions:

  • Why should a customer buy these services?
  • Why should they buy these services from you?
  • What are the pricing or chargeback models?
  • What are my strengths and weaknesses, priorities and risk?
  • How should my resources and capabilities be allocated?

See Figure 3.6. Ideally the Service Portfolio should form part of a comprehensive Service Knowledge Management System (SKMS) and registered as a document in the Configuration Management (CMS). Further information is provided on both the CMS and the SKMS within the Service Transition publication.

Figure 3.6 is a depiction of the relationship of the Service Portfolio with the SKMS.

Figure 3.6 The Service Portfolio – a central repository

Once a strategic decision to charter a service is made, this is the stage in the Service Lifecycle when Service Design begins architecting the service, which will eventually become part of the Service Catalogue. The Service Portfolio should contain information relating to every service and its current status within the organization. The options of status within the Service Portfolio should include:

  • Requirements: a set of outline requirements have been received from the business or IT for a new or changed service
  • Defined: the set of requirements for the new service are being assessed, defined and documented and the SLR is being produced
  • Analysed: the set of requirements for the new service are being analysed and prioritized
  • Approved: the set of requirements for the new service have been finalized and authorized
  • Chartered: the new service requirements are being communicated and resources and budgets allocated
  • Designed: the new service and its constituent components are being designed – and procured, if required
  • Developed: the service and its constituent components are being developed or harvested, if applicable
  • Built: the service and its constituent components are being built
  • Test: the service and its constituent components are being tested
  • Released: the service and its constituent components are being released
  • Operational: the service and its constituent components are operational within the live environment
  • Retired: the service and its constituent components have been retired.

The Service Portfolio would therefore contain details of all services and their status with respect to the current stage within the Service Lifecycle, as illustrated in Figure 3.7.

Figure 3.7 The Service Portfolio and its contents

Customers and users would only be allowed access to those services within the Service Portfolio that were of a status between ‘chartered’ and ‘operational’, as illustrated by the box in Figure 3.7, i.e. those services contained within the Service Catalogue. Service Strategy and Service Design personnel would need access to all records within the Service Portfolio, as well as other important areas such as Change Management. Other members of the service provider organization would have access to a permitted subset of the records within the Service Portfolio. Although the Service Portfolio is designed by Service Design, it is owned and managed by Service Strategy within the Service Portfolio Management process. Full details on Service Portfolio Management are discussed in the Service Strategy publication.

The Service Pipeline is a subset of the overall Service Portfolio and contains details of all of the business requirements that have not yet become services released to the live environment. It is used as a basis for the definition, analysis, prioritization and approval, by the ISG and Service Strategy, of all requests for new or changed services, to ensure that new and changed services are aligned to business requirements. It will principally be used as input to the activities of the Service Strategy and Service Design stages of the Service Lifecycle. It also provides valuable input to the activities of the Service Transition stage of the lifecycle in determining the services to be released. The Service Catalogue Management process must ensure that all of the details within the Service Portfolio are accurate and up-to-date as the requirement and its new or changed service is migrated into the live environment. This will involve close liaison with all Service Transition activities.

Various elements of the same service can have different statuses at the same time. Otherwise the Service Portfolio would be unable to support ‘incremental and iterative’ development. Each organization should carefully design its Service Portfolio, the content and the access allowed to the content. The content should include:

  • Service name
  • Service description
  • Service status
  • Service classification and criticality
  • Applications used
  • Data and/or data schema used
  • Business processes supported
  • Business owners
  • Business users
  • IT owners
  • Service warranty level, SLA and SLR references
  • Supporting services
  • Supporting resources
  • Dependent services
  • Supporting OLAs, contracts and agreements
  • Service costs
  • Service charges (if applicable)
  • Service revenue (if applicable)
  • Service metrics.

The Service Portfolio is the main source of information on the requirements and services and needs to be very carefully designed to meet all the needs of all its users. The design of the Service Portfolio needs to be considered in the same way as the design of any other IT service to ensure that it meets all of these needs. This approach should also be used for all of the other Service Management information systems, including the:

sdamzavas.net - 2020 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...