Organizing for Service Transition Tutorial

5.1 Organizing for Service Transition

Learning Unit 5 – is about Organizing for Service Transition. In this unit we will discuss about Organizational development; Roles and responsibilities; and Relationship with other lifecycle phases. Learning Unit 6 – is about Technology considerations. Here we will look at the technology requirements of service transition. Learning Unit 7 – is about implementing and improving Service transition. In this unit we will cover details about implementing service transition in a virtual and cloud environment. Learning Unit 8 – is about Challenges, Critical Success Factors and risks relating to Service Transition. Learning Unit 9 – is about Summary and directed studies. This is the last unit of the module which consists of Summary, exam preparation and directed studies details. A mock examination will be conducted as a part of the delivery of this course. Let us now understand about the quiz questions given by Simplilearn in this tutorial.

5.2 Organizing Service Transition

Here we will discuss about some of the Organization definitions. Let’s begin with: Function, it is a logical concept referring to people and automated measures executing a defined activity. Next is a Group, it is a non-formal organization structure, grouping together the people to perform similar activities. Similarly a Team, which is a Formal organization structure containing people together who work to achieve a common objective. This is followed by Department is also a Formal organizational structure existing to perform specific activities, with a hierarchical structure. Division is a number of departments grouped together, normally self-contained. Laslty the Role, it is a set of linked behaviors or action performed by a person, team or a group. In the next slide let us look at the topics covered under organizing service transition.

5.3 Organizing Service Transition

On broader note we will learn about the Processes in Service Transition, covering the managerial and supervisory aspects in detail. Therefore, Let us now look at the topics that will be covered in this module. • The Introduction topic is the overview of organizing service transition. • Organizational development will focus on the delivery aspects of Transition. • Role of technical and application management function in service transition. • Organizational context for transitioning a service between agreed schedules. • Then we will go through Service transition roles and responsibilities. • Lastly the relationship of service transition to other lifecycle stages. Let us begin with the introduction on factors influencing the organization structure.

5.4 Introduction

A characteristic of a process is that all related activities need not necessarily be limited to one specific organizational unit. SACM, for example, can be conducted in departments such as Service Operation, application management, network management, systems development and non-IT departments like procurement. Since processes and their activities run through a whole organization, the activities should be mapped to the existing IT departments or sections and coordinated by process managers. Once detailed procedures and work instructions have been developed, an organization will then map its staff to the activities of the process. Clear definitions of accountability and responsibility are critical success factors for any process implementation. Without this, roles and responsibilities within the new or changed process can be confusing, and individuals might revert to how the activities were handled before the new or changed procedures were put in place. Various Influencing factors of ST Orginization Structure are: • The size and location of the Organization • Complexity of Technology used and Vendors involved • Skill sets available for Service Transition • Organization Culture • Organization's Finances • Management Commitment to Service Transition Processes • Communication Mechanisms, Process Integration and Tools available in the Organization As we are now aware of the factors that influence the ST organization structure, in the next slide let us get the glimpse of the structure.

5.5 Organizational Development(1 of 3)

In this slide we will discuss organizational development. First let’s define what an organization is? Organization is a company, legal entity or other institution. It has people, resources and budgets. When senior managers adopt a service management orientation, they are adopting a vision for the organization. There is no best way to organize and best practices defined in ITIL that need to be tailored to suite individual organizations and situations. Any changes made will need to take into account resource constraints, size, nature and needs of business and customers. The starting point for organizational design is strategy. The organizational design like scale, scope and structure depends on strategic objectives. Over time, an organization will likely outgrow its design. There is underlying problem of structural fit, certain organizational design fit while others do not. The design challenge is to identify and select among the often distinct choices. Thus the problem becomes much more solvable when there is an understanding of the factors that influence fit and the trade-offs involved, such as control and coordination. In the coming slide we will discuss different stages of organizational development.

5.6 Organizational Development(2 of3)

This slide explains the concept of Organizational development in Service Transition. There are various Stages of Organizational Development: 1. Services through Network 2. Services through Direction 3. Services through Delegation 4. Services through Coordination 5. Services through Collaboration It is also important while deciding on a Structure you need to look for – Where the organization is in the sequence – The range of appropriate options and – the challenges brought out by each solution. In continuation to Organizational development, let us look at the steps in the process of organizational change.

5.7 Organizational Development(3 of 3)

This slide explains the last sub-concept of Organizational development in Service Transition. Organizational Change involves 3 Step Change Process: 1st action is to unfreeze the Organization from the current state 2nd action is to make the desired change to the new state 3rd action is to Freeze the Organization in the new desired state

5.8 The Service Transition Organization

The figure shows an example of service transition in a small organization. In the small organization there is a service transition manager who is the process owner, process manager and process practitioner for transition planning and support. The change, configuration and release also called as CCR manager is the process owner and the process manager for change management, service asset and configuration management, release and deployment management and knowledge management. The CCR manager has a small team of practitioners who carry out specific activities for these processes. The evaluation and test manager is the process owner and process manager for change evaluation and for service validation and test. This manager also has a small team of practitioners. Let us now proceed to look at the role of technical and application management in the next slide.

5.9 Role of Technical and Application Management(1 of 2)

In our last slide we discussed about Organizational development .This slide explains the Role of technical and application Management in Service Transition. As a recap we are discussing these functions which we have already discussed earlier. Functions refer to a team or group of people and the tools or other resources they use to carry out one or more processes or activities – for example, the service desk Application management refers to the function responsible for managing applications throughout their lifecycle. Technical Management refers to the function responsible for providing technical skills in support of IT services and management of the IT infrastructure. Technical management defines the roles of support groups, as well as the tools, processes and procedures required.

5.10 Role of Technical and Application Management(2 of 2)

In continuation to our last slide of the Role of technical and application Management in Service Transition, this slide explains the other functions. Application management functions in Service transition provides tesing and deployment resources. It also provides input for improvement and maintaine CMS, relationship and attribute inputs. Application Management is responsible for training, look into documentation resources as well as manage vendor coordination. Now let discuss the role of Technical management in service transition. As discussed under Application management, the technical management functions are same. In addition to the mentioned functions it also performs infrastructure monitoring and decides on thresholds for changes. Let us now move on to our next slide to look at the interfaces of this process.

5.11 Organization Context: Interfaces

In our last slide we discussed about Role of technical and application Management .This slide explains the Organization Context i.e. interfaces in Service Transition. Other organizational units and third parties need to have clearly defined interface and handover points with Service Transition to ensure the delivery of the defined deliverables within the agreed schedule. Programmes, projects, Service Design and suppliers are responsible for the delivery of service assets and components in accordance with the requirements of the Service Design, SLAs and contracts in addition to initiating any changes that affect a service release or deployment. Service Transition will acquire changes, service assets and components from these parties. An example of Service Transition organization is illustrated in this Figure in addition to other teams within the IT service organization. As shown here, there are interfaces to projects and Business operations that need to be clearly defined. It is essential that throughout the Service Management lifecycle there is clear interaction and understanding of responsibility by all that neither element can work in isolation. It is critical that projects have a clear understanding of Service Design, transition and operations requirements and objective of delivery, and vice versa. Often projects and programmes will work in isolation from Service Transition and operations, believing that they have no part to play in the ongoing service delivery. Similarly, transition and operations can ignore ongoing project activity; working on the basis that they will only be concerned about it once it is ‘their turn’ to deal with it. This is a very short-sighted approach and one that should be removed. Cooperation, understanding and mutual respect are critical to ensuring that new, changed and ongoing delivery of services to the customer are optimized. Let us now move on to the next slide and discuss about the organization structure under organization context.

5.12 Organization Structure - Larger Organization

One key element of this recognition is the allocation of the role of Service Transition manager. An example of a function or organizational structure for Service Transition is shown in this Figure. This is an example of service transition in larger organization. In this larger organization there is a central HQ organization which includes all process owners, as well as a change management team, release managers for each category of business application and a validation and test team. Each geographical area has its own process managers and practitioners for change management, SACM and deployment and a knowledge manager. Let us check out the different roles in Service transition in the next slide.

5.13 Service Transition Roles

Here we shall be covering only the generic roles. The process relevant roles have been discussed earlier in learning unit three. We shall start with the role of Service Owner. The service owner is accountable for the delivery of a specific IT service. The service owner holds the responsibility, towards the client, for the initiation, transition and maintenance of a service. The other responsibilities include : Ensuring that the ongoing service delivery and support meet agreed customer requirements; Working with business relationship management to understand and translate customer requirements; Ensuring consistent and appropriate communication with customers for service-related enquiries and issues; Assisting in defining service models and assessing the impact of new or changed services; Liaising with the appropriate process owners throughout the service lifecycle; Soliciting required data, statistics and reports for analysis and to facilitate effective service monitoring and performance; Representing the service across the organization; Serving as the point of escalation for major incidents relating to the service; Representing the service in change advisory board meetings; Participating in internal and external service review meetings; Ensuring that the service entry in the service catalogue is accurate and is maintained; Participating in negotiating Service Level Agreements and Operational Level Agreements relating to the service; and Identifying improvement opportunities for inclusion in the continual service improvement register.

5.14 Service Transition Roles

We shall now look at the generic process owner role. The process owner is accountable for ensuring that a process is fit for purpose. He ensures that all process activities are carried out and is responsible for: • Sponsoring, designing and change managing the process and its metrics; • Defining the process strategy; • Assisting with process design; • Ensuring that appropriate process documentation is available and current; • Defining appropriate policies and standards to be employed throughout the process; • Periodically auditing the process to ensure compliance to policy and standards; • Communicating process information or changes as appropriate to ensure awareness; • Providing process resources to support activities required throughout the service lifecycle; • Ensuring that process technicians have the required knowledge and required technical and business understanding to deliver the process; • Reviewing opportunities for process enhancements and for improving process efficiency and effectiveness; • Addressing issues with the running of the process; and • Identifying improvement opportunities for inclusion in the Continual Service Improvement register. In the next slide let us understand service transition relationship with other lifecycle stages.

5.15 Service Transition Relationship with other Lifecycle Stages

In our last slide we discussed about Service Transition Roles. This slide explains the upstream relationships for Service Transition. Service Transition is presented as a discrete lifecycle step, but this should not be taken to imply that it can stand alone. Service Transition exists to deliver the concepts documented within Service Design through to Service Operations for day-to-day management, and so without design and operations it has no purpose. Logical staff mobility happens when: Service Transition takes its shape and input from the strategy set by the organization and from the new or changed services it is charged with bringing into live operation, i.e.(pronounced as that is) by the output of the Service Design stage. Its very nature is therefore dependent on its relationship with ‘upstream areas’. In most organizations, many staff will deliver tasks appropriate to more than one lifecycle stage. Indeed, the skills and experience accumulated by Service Transition and Service Operations staff will typically be valuable in the stages upstream of their nominal focus. Specifically, Service Transition will depend on appropriate experience from operations skilled staff to deliver much of the knowledge required to make key decisions, based on predicting likely successful practice based on previous behavior of systems in similar situations. When Service Design establishes the best transition approach, and when, within Service Transition, the continued viability of that approach is assessed, Service Transition and Service Operation are best placed to play the role of subject matter expert, and provide input to the assessment and evaluation of the design’s initial and ongoing viability. Service Operation people will be involved in (design and) operations tasks directly via population of the Service Knowledge Management System with precedents and experiences detected during Service Operation stages – e.g through incident-problem-error cycles. This will drive informed and correct decision making processes and facilitate more effective Service Transition. In order to retain and make effective use of experience, staff may well find themselves allocated (fully or partially) from operations tasks to support a design exercise and then follow that service through Service Transition. They may then, via early life support activities, move into support of the new or changed services they have been involved in designing and implementing into the live environment. Expert advice on transition (as with design and operations) will also provide expert input to the development and maintenance of Service Strategy. Process Communications play a vital role in t he upstream relationships of Service transition. Many of the capabilities of a service that require testing and acceptance with transition are established, approaches and measures are set within the design. As described above, this exercise is likely to have involved Service Transition staff, either through direct involvement (perhaps even formal secondment) or through consultation and expert advice. In the next slide we will discuss about the downstream processes and procedures that influence the Service transition relationship with other lifecycle stages.

5.16 Service Transition Relationship with other Lifecycle Stages

In our last slide we discussed about upstream relationships for Service Transition. This slide explains the downstream relationships for Service Transition. Many elements initiated or perfected during Service Transition will be established and become key elements within Service Operation. During transition testing incidents will be detected that reveal errors within the new or changed service. The nature and identified resolution of these errors will provide direct input to the Service Operations procedures for supporting the new or changed service in live use. Service Transition input is likely to affect most areas of the operations stage. Testing will share processes with operations, possibly with some variations in procedure, e.g. to accommodate the differing requirements and risk environments of analyzing and rectifying errors in testing and live environments. Where testing detects errors in a new or changed service that are not significant enough to prevent the release of the service, these errors are released into the live known error database, and notification is passed to Continual Service Improvement, via the SKMS, which CSI will make extensive use of.

5.17 Learning Unit 5 Summary

With this we have come to the end of learning unit 5, let us summarize. So far we discussed about: • Organizing for Service Transition is concerned with identifying, documenting and publicizing and implementing the roles, responsibilities and competencies required for Service Transition stage. • A number of factors like size, location, complexity of technology, culture, financial resources, management commitment and communication mechanisms influence the organization structure for Service Transition. • Organizational development normally evolves through a number of stages before reaching the stage of delivering ‘services through collaboration’. • The generic roles relating to service management are Service Owners, Process Owners, Process Managers and Practitioners. • Service Transition has close interactions and interfaces with both upstream and downstream lifecycle stages. Complete the quiz question and then proceed to learning unit 6 on Technology considerations.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*