ITIL Practical Guide - Service Transition
•Télécharger en tant que PPT, PDF•
32 j'aime•37,619 vues
To view this complimentary webcast in full, visit: http://forms.axiossystems.com/LP=266 Integrating services with the business environment can be a daunting task. This video explains how you set success criteria and provide real, measurable business value. You will also learn the fundamentals of transition and release policy.
![V3 Service Transition : Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à ITIL Practical Guide - Service Transition
Similaire à ITIL Practical Guide - Service Transition (20)
Plus de Axios Systems
Plus de Axios Systems (20)
Dernier
Dernier (20)
ITIL Practical Guide - Service Transition
- 1. V3 Service Transition Finbarr Callan Lecturer, Best Practice
- 6. Service Transition : Scope © Crown Copyright 2007. Reproduced with permission from OGC
- 12. Shock Rejection Experiment Commitment Time The Denial Curve & Cultural Change
- 15. The purpose of Knowledge Management is to ensure that the right information is delivered to the appropriate place or competent person at the right time to enable informed decisions . Knowledge Management
- 16. DIKW Model © Crown Copyright 2007. Reproduced with permission from OGC
- 17. Managing Knowledge © Crown Copyright 2007. Reproduced with permission from OGC
- 20. Service Asset and Configuration Management
- 21. Managing Knowledge © Crown Copyright 2007. Reproduced with permission from OGC
- 25. Asset and Configuration Management
- 26. Asset and Configuration Management
- 27. Asset and Configuration Management
- 31. Change Management : Normal Change Process © Crown Copyright 2007. Reproduced with permission from OGC
- 38. Release and Deployment Management
- 41. Release and Deployment Management © Crown Copyright 2007. Reproduced with permission from OGC
- 42. CMS and Deployment © Crown Copyright 2007. Reproduced with permission from OGC
- 44. Release and Deployment Management
- 45. The V Model © Crown Copyright 2007. Reproduced with permission from OGC
Notes de l'éditeur
- The Service Portfolio acts as “the spine” of the service lifecycle. It is the single integrated source of information on the status of each service together with other service details and the interfaces and dependencies between services. The information within the Service Portfolio is used by the activities within each stage of the service lifecycle. SERVICE STRATEGY – Looks at the Capabilities and Constraints This slide demonstrates the SPINE of all this is the SERVICE PORTFOLIO
- Intentionally blank page to be completed by Training Provider with additional information if desired
- ST: Objectives Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans. Plan and manage the resources to establish successfully a new or changed service into production within the predicted cost, quality and time estimates Ensure there is minimal unpredicted impact on the production services, operations and support organisation Increase the customer, user and service management staff satisfaction with the Service Transition practices including deployment of the new or changed service, communications, release documentation, training and knowledge transfer Increase proper use of the services and underlying applications and technology solutions
- Intentionally blank page to be completed by Training Provider with additional information if desired
- And it therefore adds value to the business by improving the: Competitive edge – Ability to adapt quickly to new requirements and market developments Management of mergers, de-mergers, acquisitions, transfer of services Success rate of changes and releases for the business Predictions of service levels and warranties for new / changed services Confidence in the degree of compliance with business and governance requirements during change Variation of actual against estimated and approved resource plans and budgets Productivity of business and customer staff because of better planning and use of new and changed services Timely cancellation or changes to maintenance contracts for hardware and software when components are disposed or de-commissioned Understanding of the level of risk during and after change, e.g. service outage, disruption and re-work
- P25-31/ST
- P36 - ST
- Transition Strategy – see word doc. P38/39 in book.
- P.35+/ST book. Para 4.1 +
- The ability of an organisation (or individuals within it) to respond properly and effectively depends upon information being available in the right place, format and at the right time to enable it to be used for making relevant decisions. In the past much information was locked away within individuals. By recording more data and providing engines for searching, manipulating and presenting that data, the individual’s personal knowledge can be enhanced. The next slide illustrates a common model used for expressing the progression from Data to Wisdom
- The Data–Information–Knowledge–Wisdom structure Knowledge management is typically displayed within the Data–Information–Knowledge–Wisdom (DIKW) structure. The use of these terms is set out below. Data is a set of discrete facts about events. Most organisations capture significant amounts of data in highly structured databases such as service management and configuration management tools/systems and databases. The key knowledge management activities around data are the ability to: Capture accurate data Analyse, synthesize, and then transform the data into information Identify relevant data and concentrate resources on its capture. Information comes from providing context to data. Information is typically stored in semi-structured content such as documents, e-mail, and multimedia. The key knowledge management activity around information is managing the content in a way that makes it easy to capture, query, find, reuse and learn from experiences so that mistakes are not repeated and work is not duplicated. Knowledge is composed of the tacit experiences, ideas, insights, values and judgements of individuals. People gain knowledge both from their own and from their peers’ expertise, as well as from the analysis of information (and data). Through the synthesis of these elements, new knowledge is created. Knowledge is dynamic and context based. Knowledge puts information into an ‘ease of use’ form, which can facilitate decision making. In Service Transition this knowledge is not solely based on the transition in progress, but is gathered from experience of previous transitions, awareness of recent and anticipated changes and other areas that experienced staff will have been unconsciously collecting for some time. Wisdom gives the ultimate discernment of the material and having the application and contextual awareness to provide a strong common sense judgement. Data – quantitative collection of details e.g. number of Incidents Information – derives additional facts by processing data e.g. number of priority 1 Incidents occurring after year end processing Knowledge – uses information but includes an extra dimension from experience Wisdom – making correct decisions and judgements
- Diag. 4.39; p. 151 ST – spot the difference! This slide illustrates (in a simplified manner) how we can hold, manipulate and present information in a Knowledge Management system. The value of an SKMS depends to a large degree on the quantity and quality of data held in the various repositories that together represent the data and information sources. They will include structured and unstructured data. The Configuration Management System (CMS) will hold details of all the components of the IT Infrastructure and the relationships between them. In many cases it is the relationship information that will assist us most, since it will enable many of the other service management processes. Key components of the CMS are the Configuration Management Database (CMDB) of which there may be more than one physical instance that is linked with others to provide a Federated CMDB. The CMDB holds information about the logical components. The Definitive Media Libraries (DML) hold physical copies of items such as software, licences, etc. As the name implies, these are the master copies. Organisations may choose to link any other data/information to the CMS if it is decided that it will provide value. In such cases, the data is not normally replicated but linked to the CMS. Let us now look in more detail at the CMS and CMDB and the process of Service Asset and Configuration Management.
- Knowledge Base (Suggestions at point of logging)
- Knowledge Search
- Header slide
- Diag 4.8 ST. P68 This slide illustrates (in a simplified manner) how we can hold, manipulate and present information in a Knowledge Management system. The value of an SKMS depends to a large degree on the quantity and quality of data held in the various repositories that together represent the data and information sources. They will include structured and unstructured data. The Configuration Management System (CMS) will hold details of all the components of the IT Infrastructure and the relationships between them. In many cases it is the relationship information that will assist us most, since it will enable many of the other service management processes. Key components of the CMS are the Configuration Management Database (CMDB) of which there may be more than one physical instance that is linked with others to provide a Federated CMDB. The CMDB holds information about the logical components. The Definitive Media Libraries (DML) hold physical copies of items such as software, licences, etc. As the name implies, these are the master copies. Organisations may choose to link any other data/information to the CMS if it is decided that it will provide value. In such cases, the data is not normally replicated but linked to the CMS. Let us now look in more detail at the CMS and CMDB and the process of Service Asset and Configuration Management.
- The slide describes the objectives of Service Asset and Configuration Management The purpose of SAandCM is to: Protect the integrity of service assets and configuration items (CI) Place IT assets and designated CIs under configuration management Ensure the integrity of assets and configurations by maintaining a complete Configuration Management System (CMS) Support processes through accurate information The goal of SAandCM is to provide a logical model of the IT infrastructure correlating IT services and IT components (physical, logical, etc) needed to deliver these services.
- Intentionally blank page to be completed by Training Provider with additional information if desired
- Included in the Lifecycle CIs are: Service management plans, release and change plans, test plans, Organisation CIs include strategy and internal policies Internal CIs include tangible and intangible assets such as software for individual projects External CIs include external customer agreements, releases for suppliers or sub-contractors.
- Server Asset details
- Sage Payroll Service To show what other assets could be effected if sage is down (if there are any other open incidents against the assets, etc.)
- Detail all / specific assets within service catalog Item Selection – Service Catalog – Technical Services
- Header slide
- Some changes will lie outside the scope of Change Management. These may be wider organisational and/or business changes, that would give rise to RFCs that relate to services. At the opposite end of the scale, operational changes, such as printer repairs, may be deemed outside the scope.
- Normal changes include requests such as: change to service portfolios Change to a service or service definition Project change proposal User access request Operational activity Standard changes are those where the approach is pre-authorised by change management since it has an accepted and established procedure that can be followed to satisfy a specific change requirement. They will usually be associated with Change Models. Key aspects of standard changes are: Defined trigger Tasks are well-known, proven and documented Advance authority is effectively given Budgetary approval is either preauthorised or within the requestor’s control Usually low risk – but certainly well-understood
- Within the system, a record must be kept of all the changes proposed, the decisions made in relation to them and the current status of the change. Some of the information in a change record will be created when an RFC is raised; the remainder will be added as the change progresses through its life. In many ways, therefore, the RFC can be considered as a subset of the Change record. Change record Request for Change (RFC) Business case Related CMS information RFC Content Unique number Trigger Description Id of items to be changed Reasons Effect of not doing CIs and baselines affected Proposer details Date/time raised Category Timescales, resources, etc Priority Risk assessment Back-out plan Impact assessment Knock-on effect Decision body Decision Authorised Date
- Intentionally blank page to be completed by Training Provider with additional information if desired
- Intentionally blank page to be completed by Training Provider with additional information if desired
- Change impacts so many different people and groups across the enterprise that is difficult to ensure common levels of understanding about the importance of change management and the correct procedures to be followed. Change is inevitable; in many cases essential. But the organisation needs to define its appetite for risk. Is it always necessary to be first to market? – which might call for less rigorous testing and speedy decision making – or is it more important to ensure that nothing upsets the live services. All humans like stability, but change management needs to be seen as responsive and being an enabler of the right changes. The process must allow change not stifle it – but under control There will be resistance Measure the right things and use the results to seek improvement
- Process Design Manager – Software Release Process
- Same process – Change Calendar
- Change Conflict Detection
- Header slide
- Intentionally blank page to be completed by Training Provider with additional information if desired
- P.84/SD book Para 4.4
- Intentionally blank page to be completed by Training Provider with additional information if desired
- DML – same as V2. scope/content need to be defined during SACM planning.
- Intentionally blank page to be completed by Training Provider with additional information if desired
- Software Release affecting three servers (upgrading SQL Server 2003)
- Criteria – pass/fail. P.91/P.123 ST book. Using a model such as the V-Model (Figures 4.12, 4.21, 4.30) builds in service validation and testing early in the service lifecycle. It provides a framework to organize the levels of configuration items to be managed through the lifecycle and the associated validation and testing activities both within and across stages. The level of test is derived from the way a system is designed and built up. This is known as a V-model, which maps the types of test to each stage of development. The V-model provides one example of how the Service Transition levels of testing can be matched to corresponding stages of service requirements and design. The left-hand side represents the specification of the service requirements down to the detailed Service Design. The right-hand side focuses on the validation activities that are performed against the specifications defined on the left-hand side. At each stage on the left-hand side, there is direct involvement by the equivalent party on the right-hand side. It shows that service validation and acceptance test planning should start with the definition of the service requirements. For example, customers who sign off the agreed service requirements will also sign off the service Acceptance Criteria and test plan.
- ST book – p.115+
- Test and Evaluation (Typical Back-out Process)
- The Service Portfolio acts as “the spine” of the service lifecycle. It is the single integrated source of information on the status of each service together with other service details and the interfaces and dependencies between services. The information within the Service Portfolio is used by the activities within each stage of the service lifecycle. SERVICE STRATEGY – Looks at the Capabilities and Constraints This slide demonstrates the SPINE of all this is the SERVICE PORTFOLIO