Your SlideShare is downloading. ×
0
V3 Service Transition Finbarr Callan Lecturer, Best Practice
V3 Service Transition : Agenda <ul><li>Key Elements of Transition </li></ul><ul><li>Processes –  </li></ul><ul><ul><li>Ser...
Service Lifecycle Components
<ul><li>Purpose and Goals </li></ul><ul><li>Provide  guidance on the development and improvement of capabilities  for tran...
Service Transition Scope Management and co-ordination of the processes, systems and functions to package, build, test and ...
Service Transition : Scope © Crown Copyright 2007.  Reproduced with permission from OGC
<ul><li>It enables the service provider to: </li></ul><ul><li>Handle  high volumes  of change and releases across its cust...
Business Value   <ul><li>Adaptability </li></ul><ul><li>Mergers & Acquisitions </li></ul><ul><li>Successful Change </li></...
<ul><li>Define Transition Policy </li></ul><ul><li>All changes  made through Change/Service Transition </li></ul><ul><li>C...
Fundamental Principles <ul><li>Define Release Policy </li></ul><ul><li>Roles and Responsibilities </li></ul><ul><li>Naming...
Common Operations <ul><li>Communications </li></ul><ul><ul><li>Strategy and planning </li></ul></ul><ul><ul><li>Methods </...
Shock Rejection Experiment Commitment Time The Denial Curve & Cultural Change
Service Transition : Processes <ul><li>Transition Strategy, Planning and Support  </li></ul><ul><li>Knowledge Management <...
Transition Planning <ul><li>Scope </li></ul><ul><li>Value to the business </li></ul><ul><li>Basic concepts </li></ul><ul><...
The purpose of Knowledge Management is to ensure that the  right information  is delivered to the  appropriate place  or  ...
DIKW Model © Crown Copyright 2007.  Reproduced with permission from OGC
Managing Knowledge © Crown Copyright 2007.  Reproduced with permission from OGC
Knowledge Management
Knowledge Management
Service Asset and Configuration Management
Managing Knowledge © Crown Copyright 2007.  Reproduced with permission from OGC
Service Asset & Configuration Management <ul><li>Objectives  </li></ul><ul><li>To  define and control  the components of s...
<ul><li>Key Concepts </li></ul><ul><li>Configuration items (CIs) </li></ul><ul><li>Categories </li></ul><ul><li>Levels </l...
Service Asset & Configuration Management A Configuration Item (CI) is an asset, service component or other item which is, ...
Asset and Configuration Management
Asset and Configuration Management
Asset and Configuration Management
Change Management
Change Management <ul><li>Objective and Scope </li></ul><ul><li>To ensure that changes are: </li></ul><ul><li>Recorded, ev...
<ul><li>Change types : </li></ul><ul><li>Normal  – requires full assessment and authorization </li></ul><ul><li>Standard  ...
Change Management : Normal Change Process © Crown Copyright 2007.  Reproduced with permission from OGC
Change Management <ul><li>Standard Change Elements  </li></ul><ul><li>Defined trigger </li></ul><ul><li>Tasks are well-kno...
Change Management : Assessing Impact <ul><li>The 7 “Rs” </li></ul><ul><li>Who  RAISED  the change? </li></ul><ul><li>What ...
Change Management : Challenges <ul><li>The spread of those affected  </li></ul><ul><li>Balancing risk  and  need </li></ul...
Change Management
Change Management
Change Management
Release and Deployment Management
Release and Deployment : Objectives <ul><li>Clear and comprehensive plans  enabling change projects to align their activit...
Release and Deployment  Management <ul><li>Scope </li></ul><ul><li>Value to the business </li></ul><ul><li>Basic concepts ...
Release and Deployment Management © Crown Copyright 2007.  Reproduced with permission from OGC
CMS and Deployment © Crown Copyright 2007.  Reproduced with permission from OGC
<ul><li>Release Options </li></ul><ul><li>Big-bang  – to all users at once </li></ul><ul><li>Phased  – partial then schedu...
Release and Deployment Management
The V Model   © Crown Copyright 2007.  Reproduced with permission from OGC
<ul><li>Validation and Testing </li></ul><ul><li>Scope </li></ul><ul><li>Value to the business </li></ul><ul><li>Basic con...
Evaluation and Testing
Roles and Responsibilities <ul><li>Service Owner </li></ul><ul><li>Service Transition Manager </li></ul><ul><li>Service As...
Service Lifecycle Components
Any Questions <ul><li>[email_address] </li></ul><ul><li>www.axiossystems.com </li></ul><ul><li>Further Resources </li></ul...
Upcoming SlideShare
Loading in...5
×

ITIL Practical Guide - Service Transition

16,601

Published on

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.

Published in: Business, Education
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
16,601
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
769
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide
  • 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
  • Transcript of "ITIL Practical Guide - Service Transition"

    1. 1. V3 Service Transition Finbarr Callan Lecturer, Best Practice
    2. 2. V3 Service Transition : Agenda <ul><li>Key Elements of Transition </li></ul><ul><li>Processes – </li></ul><ul><ul><li>Service Asset & Configuration Management </li></ul></ul><ul><ul><li>Change Management </li></ul></ul><ul><ul><li>Release and Deployment Management </li></ul></ul><ul><ul><li>Knowledge Management </li></ul></ul><ul><ul><li>Evaluation & Testing </li></ul></ul><ul><li>Questions </li></ul>
    3. 3. Service Lifecycle Components
    4. 4. <ul><li>Purpose and Goals </li></ul><ul><li>Provide guidance on the development and improvement of capabilities for transitioning new and changed services into operations </li></ul><ul><li>Set customer expectations </li></ul><ul><li>Enable integration </li></ul><ul><li>Reduce performance variation </li></ul><ul><li>Reduce known errors and minimize risk </li></ul><ul><li>Ensure proper use of services </li></ul>Service Transition
    5. 5. Service Transition Scope Management and co-ordination of the processes, systems and functions to package, build, test and deploy a release into production, and establish the service specified in the customer and stakeholder requirements Objectives <ul><li>Provide clear and comprehensive plans </li></ul><ul><li>Plan and manage the resources </li></ul><ul><li>Increase satisfaction </li></ul><ul><li>Increase use of services </li></ul>
    6. 6. Service Transition : Scope © Crown Copyright 2007. Reproduced with permission from OGC
    7. 7. <ul><li>It enables the service provider to: </li></ul><ul><li>Handle high volumes of change and releases across its customer base </li></ul><ul><li>Align the new or changed service with the customer’s business requirements and business operations </li></ul><ul><li>Ensure that customers and users can use the new or changed service in a way that maximizes value to the business operations </li></ul>Value to the Business
    8. 8. Business Value <ul><li>Adaptability </li></ul><ul><li>Mergers & Acquisitions </li></ul><ul><li>Successful Change </li></ul><ul><li>Service Predictability </li></ul><ul><li>Compliance </li></ul><ul><li>Productivity </li></ul><ul><li>Contract Management </li></ul><ul><li>Risk Management </li></ul>
    9. 9. <ul><li>Define Transition Policy </li></ul><ul><li>All changes made through Change/Service Transition </li></ul><ul><li>Common process framework </li></ul><ul><li>Align with organization process/re-use </li></ul><ul><li>Align with business requirements </li></ul><ul><li>Relationship and expectation management </li></ul><ul><li>Effective knowledge transfer </li></ul><ul><li>Planning and design </li></ul><ul><li>Manage resources </li></ul><ul><li>Handle corrections </li></ul><ul><li>Meet quality needs </li></ul>Fundamental Principles
    10. 10. Fundamental Principles <ul><li>Define Release Policy </li></ul><ul><li>Roles and Responsibilities </li></ul><ul><li>Naming/numbering/identification for release types </li></ul><ul><li>Frequency of release </li></ul><ul><li>Grouping changes into releases </li></ul><ul><li>Automation </li></ul><ul><li>Baselining </li></ul><ul><li>Acceptance criteria </li></ul><ul><li>ELS – end/handover to operations </li></ul>
    11. 11. Common Operations <ul><li>Communications </li></ul><ul><ul><li>Strategy and planning </li></ul></ul><ul><ul><li>Methods </li></ul></ul><ul><li>Organizational Change </li></ul><ul><ul><li>DRAC ( D enial/ R ejection/ A cceptance/ C ommitment) curve – how do you overcome it? </li></ul></ul><ul><ul><li>Necessity/Vision/Plan/Resources/Competence </li></ul></ul><ul><ul><li>Culture </li></ul></ul><ul><ul><li>Stakeholder Management </li></ul></ul>
    12. 12. Shock Rejection Experiment Commitment Time The Denial Curve & Cultural Change
    13. 13. Service Transition : Processes <ul><li>Transition Strategy, Planning and Support </li></ul><ul><li>Knowledge Management </li></ul><ul><li>Change Management </li></ul><ul><li>Service Asset and Configuration Management </li></ul><ul><li>Release and Deployment Management </li></ul><ul><li>Service Testing and Verification </li></ul><ul><li>Evaluation </li></ul>
    14. 14. Transition Planning <ul><li>Scope </li></ul><ul><li>Value to the business </li></ul><ul><li>Basic concepts </li></ul><ul><li>Activities/techniques </li></ul><ul><li>Challenges </li></ul>
    15. 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. 16. DIKW Model © Crown Copyright 2007. Reproduced with permission from OGC
    17. 17. Managing Knowledge © Crown Copyright 2007. Reproduced with permission from OGC
    18. 18. Knowledge Management
    19. 19. Knowledge Management
    20. 20. Service Asset and Configuration Management
    21. 21. Managing Knowledge © Crown Copyright 2007. Reproduced with permission from OGC
    22. 22. Service Asset & Configuration Management <ul><li>Objectives </li></ul><ul><li>To define and control the components of services and infrastructure, and maintain accurate configuration records allowing: </li></ul><ul><li>Compliance with corporate governance </li></ul><ul><li>Control of asset base </li></ul><ul><li>Cost optimization </li></ul><ul><li>Effective change and release management </li></ul><ul><li>Faster incident and problem resolution </li></ul>
    23. 23. <ul><li>Key Concepts </li></ul><ul><li>Configuration items (CIs) </li></ul><ul><li>Categories </li></ul><ul><li>Levels </li></ul><ul><li>Naming </li></ul><ul><li>Labels </li></ul><ul><li>Attributes </li></ul><ul><li>Configuration Management System (CMS) </li></ul><ul><li>Baselines </li></ul>Service Asset & Configuration Management
    24. 24. Service Asset & Configuration Management A Configuration Item (CI) is an asset, service component or other item which is, or will be, under the control of configuration management. <ul><li>Configuration Items </li></ul><ul><li>CI Categories: </li></ul><ul><li>Service lifecycle CIs, e.g. plans, business case, SDP </li></ul><ul><li>Service CIs - Capability assets, e.g. people, knowledge resource assets, e.g. systems, data models and packages </li></ul><ul><li>Organization CIs </li></ul><ul><li>Internal CIs </li></ul><ul><li>External CIs </li></ul>
    25. 25. Asset and Configuration Management
    26. 26. Asset and Configuration Management
    27. 27. Asset and Configuration Management
    28. 28. Change Management
    29. 29. Change Management <ul><li>Objective and Scope </li></ul><ul><li>To ensure that changes are: </li></ul><ul><li>Recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner </li></ul><ul><li>Changes to base-lined service assets and configuration items across the service lifecycle </li></ul>
    30. 30. <ul><li>Change types : </li></ul><ul><li>Normal – requires full assessment and authorization </li></ul><ul><li>Standard – pre-authorized by change management </li></ul><ul><li>Emergency – rapid response to a business affecting situation </li></ul>Service Change Definition The addition, modification or removal of any authorized, planned or supported service or service component and its associated documentation Change Management : Concepts
    31. 31. Change Management : Normal Change Process © Crown Copyright 2007. Reproduced with permission from OGC
    32. 32. Change Management <ul><li>Standard Change Elements </li></ul><ul><li>Defined trigger </li></ul><ul><li>Tasks are well-known, documented and proven </li></ul><ul><li>Authority is effectively given in advance </li></ul><ul><li>Budgetary approval pre-ordained or within control of requestor </li></ul><ul><li>Risk – usually low; always well understood </li></ul>
    33. 33. Change Management : Assessing Impact <ul><li>The 7 “Rs” </li></ul><ul><li>Who RAISED the change? </li></ul><ul><li>What is the REASON for it? </li></ul><ul><li>What is RETURN required? </li></ul><ul><li>What are the RISKS involved? </li></ul><ul><li>What RESOURCES are required to deliver it? </li></ul><ul><li>Who is RESPONSIBLE for build, test and implementation? </li></ul><ul><li>What is the RELATIONSHIP with other changes? </li></ul>
    34. 34. Change Management : Challenges <ul><li>The spread of those affected </li></ul><ul><li>Balancing risk and need </li></ul><ul><li>Stability vs responsiveness </li></ul><ul><li>Balancing control and bureaucracy </li></ul><ul><li>Culture </li></ul><ul><li>Using the right measurements </li></ul>
    35. 35. Change Management
    36. 36. Change Management
    37. 37. Change Management
    38. 38. Release and Deployment Management
    39. 39. Release and Deployment : Objectives <ul><li>Clear and comprehensive plans enabling change projects to align their activities </li></ul><ul><li>Release packages can be built, installed, tested and deployed efficiently </li></ul><ul><li>New or changed services meet the utility, warranty and service levels </li></ul><ul><li>Ensure knowledge transfer enabling full utilization by the consumer </li></ul><ul><li>Ensure knowledge and skills transfer to support staff enabling full delivery and support of the service </li></ul><ul><li>Minimize unpredicted impact </li></ul><ul><li>Satisfied customers and users </li></ul>
    40. 40. Release and Deployment Management <ul><li>Scope </li></ul><ul><li>Value to the business </li></ul><ul><li>Basic concepts </li></ul><ul><ul><li>Release Unit : a portion of a service or infrastructure that is normally released together </li></ul></ul><ul><ul><li>Release Package: a single release unit or a structured set of release units </li></ul></ul><ul><li>Activities/techniques </li></ul><ul><li>Challenges </li></ul>
    41. 41. Release and Deployment Management © Crown Copyright 2007. Reproduced with permission from OGC
    42. 42. CMS and Deployment © Crown Copyright 2007. Reproduced with permission from OGC
    43. 43. <ul><li>Release Options </li></ul><ul><li>Big-bang – to all users at once </li></ul><ul><li>Phased – partial then scheduled roll-out </li></ul><ul><ul><li>- Incremental changes to all users </li></ul></ul><ul><ul><li>- Unit by unit </li></ul></ul><ul><ul><li>- Element by element </li></ul></ul><ul><ul><li>- Combinations of these </li></ul></ul><ul><li>Push versus pull </li></ul><ul><li>Automation versus manual </li></ul>Release and Deployment Management
    44. 44. Release and Deployment Management
    45. 45. The V Model © Crown Copyright 2007. Reproduced with permission from OGC
    46. 46. <ul><li>Validation and Testing </li></ul><ul><li>Scope </li></ul><ul><li>Value to the business </li></ul><ul><li>Basic concepts </li></ul><ul><li>Activities/techniques </li></ul><ul><li>Challenges </li></ul><ul><li>Evaluation </li></ul><ul><li>Scope </li></ul><ul><li>Value to the business </li></ul><ul><li>Basic concepts </li></ul><ul><li>Activities/techniques </li></ul><ul><li>Challenges </li></ul>Validation and Testing / Evaluation
    47. 47. Evaluation and Testing
    48. 48. Roles and Responsibilities <ul><li>Service Owner </li></ul><ul><li>Service Transition Manager </li></ul><ul><li>Service Asset Manager </li></ul><ul><li>Configuration Manager/Analyst </li></ul><ul><li>Change Authority </li></ul><ul><li>Change Manager </li></ul><ul><li>CAB/ECAB </li></ul>
    49. 49. Service Lifecycle Components
    50. 50. Any Questions <ul><li>[email_address] </li></ul><ul><li>www.axiossystems.com </li></ul><ul><li>Further Resources </li></ul><ul><li>V3 Service Strategy and Service Design Webinars – now available onDemand. </li></ul><ul><li>V2 versus V3 White Paper and Webinar - on Axios website. </li></ul><ul><li>ITIL V3 Quick Reference Guide – pocket guide & poster </li></ul><ul><li>ITSM: IT Transforms Itself into a Service . Aberdeen Group Research. Available to download, along with a complementary onDemand Webinar on the Axios website. </li></ul><ul><li>ITIL V3: The Future is Here White Paper, authored by Sharon Taylor, Chief Architect of ITIL V3. A Webinar by Sharon Taylor is also available onDemand. Both are available for download from the Axios website. </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×