6.4

Service Development and Design

The purpose of Service Development is to introduce new services and service development initiatives for the business. Service Development takes input from business projects, concept development, key users and service integration and carries out the development efforts either as projects, service releases or individual changes. It is essential both react to development needs coming from the business, and also continuously develop new digital business opportunities for the business. Service Owners and Service Managers have a crucial role in proactive development within services.

Service Design consists of involving key stakeholders (e.g. existing or future users of services, business and service delivery representatives) into designing the services. The purpose of Service Design is to build a holistic comprehension about various key stakeholder perspectives, and then incorporate that information into the design and development of the services. Service Design is used to improve the end-user satisfaction of the services, and also it can help to manage and deliver the services in the most efficient way.  

Service Design consists of identifying problems and needs, setting the business objectives, profiling user groups as well as developing, evaluating, testing and improving the solution ideas. In addition, some special Service Design practices help to measure and continuously improve the implemented solution. Service design is used to either create entirely new services or improve the existing ones.

Figure 6.4.1 depicts Service Architecture which has a major role in enabling purposeful Service Development, Service Design and Lifecycle Management. Service Architecture consists of four elements:

  • Service Offering
  • Service Roadmap
  • Service Delivery Model
  • Service Structure

SM_Service_Architecture

Figure 6.4.1 Service Architecture.

Service Architecture together with professional sourcing of services and business-value driven Service Roadmap help to achieve optimal services. It is essential to include also the key service providers in the development of the Service Architecture. Service Architecture should always be kept as clear and simple a possible.

Service Architecture is managed by Service Owners. Each Service Owner is responsible for a Service Domain or a specific service. Organizations have typically five to ten Service Domains such as:

  • Sales and Marketing Solutions
  • Production and Supply Chain Solutions
  • R&D and Engineering Solutions
  • Business Support Solutions
  • End User Services, i.e. Workstation and Collaboration Services
  • Infrastructure Services, i.e. Capacity and Connectivity Services

 

The first element of the Service Architecture, the Service Offering (also known as the Service Catalogue), is a definition of services provided by IT. The Service Offering is the tangible and understandable part of IT services forming the basis for developing, organizing, delivering and improving the overall IT management. In addition, it creates a link between business and IT by explaining which services are available and what components each of these services embraces. The Service Catalogue helps to demonstrate the service focus of IT and the value for the business. A complete Service Catalogue consists of an overview of IT services, Service Brochures and an Order and Service Request Catalogue published and managed via a Service Management Platform.

The Service Roadmap is a plan for developing a service or Service Domain with information on scope, schedule, costs and business benefits of each of the initiatives. Each development initiative is carried out as a project, service release or change.

The Service Delivery Model is defined in cooperation with Sourcing. The possible Delivery Models for continuous services include near or offshoring and cloud services. The Service Delivery Model should decide if and which services are sourced as well as who are the preferred Service Providers. It should also define whether services are purchased as end-to-end services, separate service components, or by building the so-called service towers (stack of services) that utilize the most suitable supplier for each service area. In most cases, the size and the operational model of the company will define the best delivery model.

The Service Structure includes definitions of the logical structure of the service, service relations and responsibilities. The Service Structure defines the highest-level elements for the Configuration Management Database (CMDB).

 

Change and Release Management

 

The Change Management is a governance process that employs standard methods and procedures in order to make assessment between the need for change versus the impact of change. This way, it will be easier to prevent all unintended consequences to service quality.

The Release Management is an execution process that is used for building and deploying the changes although some changes can still be carried out individually (e.g. pre-approved standard changes or emergency changes). Scheduling the changes in the Release Calendar makes the whole Change Management process more proactive and predictable.

Classification and execution of changes within the Service Lifecycle starts from the Development Backlog, which contains the development needs, small enhancements and Change Requests (CR) (see Figure 6.4.2). The changes need to be first categorized and prioritized, followed by planning, building and validating the execution. Finally, after the deployment, the new functionality will be reviewed and closed and handed over to the Service Operations.

Changes can be classified as normal, standard or emergency. Normal changes are infrequent changes to a service or infrastructure requiring a risk assessment by the Change Advisory Board (CAB). These type of changes can be implemented e.g. four times a year. Normal changes are divided further into three sub categories:

  • Minor: the change is relatively trivial and presents minimal risk of causing service problems. The Change Manager can approve the change without forwarding the Change Request to the CAB. Minor change can also be a candidate for a standard change.
  • Medium: The change requires significant effort and could have a substantial impact on the services. This type of change requires approval from the CAB.
  • Major: The Change could impact mission critical operations of the organization. It needs approval from IT Management in addition to the CAB.

 

Standard change is a routine task pre-authorized by the Change Management function that uses approved and established procedure to provide a specific change requirement. A standard change comprises pre-defined trigger, documented tasks and budgetary approval. The risk of implementing a standard change is low and well understood. Standard changes can be executed via the Service Request within an incident or via the Problem Management process. A good example of a standard change is e.g. setting up a workstation for a new employee. Standard changes can be deployed on-demand, daily, weekly or monthly basis either individually or via a Release.

Emergency change must be introduced as soon as possible, usually in order to correct an error within the environment. There is a substantial risk involved and therefore, it must be approved by the Emergency Change Advisory Board (ECAB). It also requires a separate escalation procedure in order to reduce or eliminate the impact on the environment. Emergency changes can be deployed individually or via a Release On-Demand process.

EA_Change_cassification_v3

Figure 6.4.2 Change Classification and Execution

 

Contact us IT for Business as PDF

 

Looking for answers to your questions about IT Standard? Get in touch.