Cloud Operating Model Design

8,373 views

Published on

Service Offering

Published in: Business, Technology

Cloud Operating Model Design

  1. 1. Operating Model Design<br />Service Offering Description<br />
  2. 2. 5/19/2011<br />© Copyright 2010-2011 Sunnyside Associates, LLC. All Rights Reserved.<br />2<br />
  3. 3. Operating Model Elements<br />Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools. <br />Governance – how we make and sustain important decisions about IT. <br />Sourcing – how we select and manage the sourcing of our IT products and services. <br />Services – our portfolio of IT products and services. <br />Measurement – how we measure and monitor our performance. <br />Organization – how we structure and organize our IT capabilities? <br />5/19/2011<br />3<br />© Copyright 2010-2011 Sunnyside Associates, LLC. All Rights Reserved.<br />
  4. 4. Agenda<br />Major Assumptions<br />Operating Model Scope<br />Value Proposition<br />Design Approach<br />Level 0 Process Model with Level 1 ITIL V3 Mapping<br />The Model as a Business Planning Tool<br />Candidate Operational Flows<br />Next Steps<br />5/19/2011<br />© Copyright 2010-2011 Sunnyside Associates, LLC. All Rights Reserved.<br />4<br />
  5. 5. Major Assumptions<br />The scope of managed services addressed by the model should be flexible enough to support technical services, e.g., network, storage, compute and application infrastructure or middleware, needed to deliver service offerings to the SBUs as well as the business services needed to run IT, e.g., infrastructure management systems, service management systems<br />Best practice approaches should be leveraged wherever possible to deliver a Type 2 or 3 Service Provider Model (ITIL V3), e.g. managed and shared services<br />In the Target Operational Model headcounts and skill levels will be aligned to ‘market standards’ to allow for operational metrics and KPIs to be benchmarked against industry best practices, e.g. ratio of devices / admin, incident metrics, etc. <br />The best practice numbers will serve as a goal against which the target environment will be measured as it matures<br />Operational maturity and skill levels will be evaluated after a Due Diligence phase and organizational gap remediation steps taken to ensure that the saves promised by initiative (s) be realized.<br />The model must support E2E processes for all service management flows as they span Service Desk (e.g., incident, Support and Operations, e.g., config,. change, facilities mgmt., etc)<br />
  6. 6. Agenda<br />Major Assumptions<br />Operating Model Scope<br />Value Proposition<br />Design Approach<br />Level 0 Process Model with Level 1 ITIL V3 Mapping<br />The Model as a Business Planning Tool<br />Candidate Operational Flows<br />Next Steps<br />
  7. 7. Process Model<br /><ul><li>End-to-end operating processes
  8. 8. Process triggers and interfaces
  9. 9. E.g., ITIL , eTOM, ISO 2000
  10. 10. Performance KPIs </li></ul>Operating Model<br />Goals are:<br /><ul><li>Operational Efficiency
  11. 11. Customer Experience
  12. 12. Revenue & Margin</li></ul>People & Organization<br /><ul><li>Roles & Responsibilities (RACI)
  13. 13. Process owners
  14. 14. Escalations & interactions, etc.
  15. 15. Performance KPIs and Metrics</li></ul>Technology<br />(IT Infrastructure, Tools & Automation)<br /><ul><li>Process automation
  16. 16. Data models and repositories (e.g., CMDB)
  17. 17. COTS, standards & simplification</li></ul>Operating Model Scope<br />
  18. 18. Agenda<br />Major Assumptions<br />Operating Model Scope<br />Value Proposition<br />Design Approach<br />Level 0 Process Model with Level 1 ITIL V3 Mapping<br />The Model as a Business Planning Tool<br />Candidate Operational Flows<br />Next Steps<br />
  19. 19. Assumed Operating Model Savings Targets - Operations<br />
  20. 20. Assumed Operating Model Savings Targets - Support<br />
  21. 21. Assumed Operating Model Savings Targets - SBUs<br />
  22. 22. Agenda<br />Major Assumptions<br />Operating Model Scope<br />Value Proposition<br />Design Approach<br />Level 0 Process Model with Level 1 ITIL V3 Mapping<br />The Model as a Business Planning Tool<br />Candidate Operational Flows<br />Next Steps<br />
  23. 23. Design Approach: Blending Industry Best Practices<br />Isn’t ITIL Enough?<br /><ul><li>ITIL V3 covers 100%+ of Day 1 capabilities
  24. 24. From a pure end-state design perspective, ITIL is Internally focused – experience shows that once transparency is achieved for the business, comparative valuation occurs – eTOM offer management and campaign processes could address an important gap in the end state
  25. 25. ITIL does not link solutions and training to a design process (it is part of release)
  26. 26. The use of eTOM simply ensures that the end state design provides full coverage in the event the client needs to access additional capabilities as it matures</li></ul>End-to-end operating processes<br />Integrate with client requirements<br />
  27. 27. Agenda<br />Major Assumptions<br />Operating Model Scope<br />Value Proposition<br />Design Approach<br />Level 0 Process Model with Level 1 ITIL V3 Mapping<br />The Model as a Business Planning Tool<br />Candidate Operational Flows<br />Next Steps<br />
  28. 28. Strategy & Service <br />Operations and Support<br />High Level-Process Model<br />Service Lifecycle Management<br />Business Strategy, Architecture & Planning<br />Service Management and Operations<br />Service Fulfillment<br />Service Assurance<br />Customer Service<br />Service Development & Management<br />Service Configuration & Activation<br />Resource Development & Management<br />Service Quality Management<br />Supplier Development & Management<br /><ul><li>The Operating Model shows seven vertical process groupings that are the end-to-end processes that are required to support customers and to manage operations
  29. 29. The operating model also includes views of functionality as they span horizontally across the clients’s internal organization
  30. 30. The horizontal functional process groupings distinguish functional operations processes and other types of business functional processes, e.g., Service Development versus Service Activation & Configuration, etc.</li></li></ul><li>Operating Model E2E Processes<br />Built on industry best practice business and IT process models<br />Addresses all of end-to-end processes needed to deliver Managed Services to customers - Includes <br />Strategy and Service: “Enabling” processes of Business Strategy, Architecture & Planning, including<br />Service Lifecycle Management and Service Development & Management<br />Operations and Support: “Lights on,” or core operations processes of Customer Service, Service Management and Operations, including <br />Operations Support, Billing/Chargeback, Service Desk, Service Development and Management<br />Service Configuration & Activation, Service Quality Management, Facilities and Operations<br />
  31. 31. ITIL V3 Mapping<br />Service Desk<br />Incident/Fault Management<br />Problem Management<br />Event Management<br />Access Management<br />Request Fulfillment<br />Strategy & Service <br />Operations and Support<br />Service Lifecycle Management<br />Business Strategy, Architecture & Planning<br />Service Management and Operations<br />Service Fulfillment<br />Service Assurance<br />Facilities Management<br />Knowledge Management<br />Release & Deployment Mgmt.<br />Configuration Management<br />Solution Management<br />Service Validation & Testing<br />Service-Level Management<br />Chargeback Management<br />Change Management<br />Availability Management<br />Service Continuity Management<br />Operations Management<br />Continuous Service Improvement<br />Security Management<br />Service Portfolio Management<br />Risk Management<br />Supplier Management<br />Capacity Management<br />Service Catalog Management<br />Compliance Management<br />Architecture Management<br />Demand Management<br />Financial Management<br />
  32. 32. Operating Model<br />REFERENCE MODEL<br />PROCESS<br />PEOPLE<br />TECHNOLOGY<br />
  33. 33. Strategy & Service covers the processes involved in forming and deciding Service Strategy and gaining commitment from the business for this<br />Service Lifecycle Management covers the services themselves – note that the model distinguishes Service, used by the client to represent the “technical” part of the product, and Resource (physical and non-physical components used to support Service)<br />The vertical functional groupings in are mapped from ITIL V3, Service Strategy and Design<br />Business Strategy, Architecture & Planning Processes<br />
  34. 34. Level 0 Operations & Support Processes<br />Operations & Support (O&S) provide the core of lights-on Operations and first- and second-line support<br />The vertical processes in O&S represent a view of flow-through of activity, and map to ITIL V3 processes where there is functionally-related activity, e.g., Service Transition, Operation and CSI<br />
  35. 35. Resource Model<br />
  36. 36. Resource Model at a Glance<br />Process Grouping<br />ITIL V3 Processes<br />Key Baseline Metrics<br />Industry Benchmark Metrics<br />ITIL Roles<br />Headcount Forecast<br />Demand<br />Forecast<br />
  37. 37. Agenda<br />Major Assumptions<br />Operating Model Scope<br />Value Proposition<br />Design Approach<br />Level 0 Process Model with Level 1 ITIL V3 Mapping<br />The Model as a Business Planning Tool<br />Candidate Operational Flows<br />Next Steps<br />
  38. 38. The Target Model as a Business Planning Tool<br /><ul><li>Roles (ITIL V3)
  39. 39. Processes (ITIL V3)
  40. 40. Skills (SFIA)
  41. 41. KPIs / Metrics (Role Based / Processes Based)
  42. 42. Baseline and improvement
  43. 43. Allows us to dial up and down to see ROI</li></li></ul><li>Anticipated Trends Forecast (sample)<br />Infrastructure Capacity, Efficiency, Scale and Ability Cope with Change<br />BAU Headcounts<br />BAU + Incremental <br />Initiative Headcounts<br />Aurora Planning Timeline<br />
  44. 44. Key Planning Metrics<br />Low Hanging Fruit?<br />Key Operations Metrics<br />Mean Time to Repair (time required to diagnose and resolve problems)<br />Incident to Change Ratio<br />% of Incidents Reported by End Users<br />% of Outages Traced to Mis-configurations<br />% of Changes Completed within change Windows<br />% of Changes Automated versus Manual<br />Device to Admin Ratio<br />Service roll-out cycle time (MTTD - mean time to deploy)<br />Changes per Admin<br />$ Unit per Device Managed<br />Time and cost to Audit and Remediate (Audit cycle time)<br />Time and cost to Grant and Revoke Administrative Access<br />Downtime traced to compliance violations<br />% of configuration audits passed<br />$ Operation per Device Managed<br /><ul><li>Key Support Metrics
  45. 45. Ratio of L1 to L2 to L3 support staff
  46. 46. First call resolution rate
  47. 47. Percentage of escalations to L2 and L3 support
  48. 48. Time to plan a change
  49. 49. Time to approve a change
  50. 50. Backlog of changes
  51. 51. # of change collisions
  52. 52. % of changes rolled back
  53. 53. # of calls resolved via self-service requests (call avoidance)
  54. 54. MTBF for business availability
  55. 55. Ratio of planned to unplanned changes
  56. 56. Average cost per incident
  57. 57. Average cost per type of service request
  58. 58. % of incidents closed by L1 support
  59. 59. # of Incidents
  60. 60. Ratio of L1 to L2 to L3 incidents</li></li></ul><li>Candidate Operational Flows<br />Start the dialog<br />Guide POV / POC activities<br />Tied to KPIs / Metrics can help determine direct value opportunity<br />
  61. 61. Agenda<br />Major Assumptions<br />Operating Model Scope<br />Value Proposition<br />Design Approach<br />Level 0 Process Model with Level 1 ITIL V3 Mapping<br />The Model as a Business Planning Tool<br />Candidate Operational Flows<br />Next Steps<br />
  62. 62. 1. New Service Request/Service Provisioning<br />
  63. 63. 2. New Service Request Development Environment<br />
  64. 64. 3. New Service Request Development Application<br />
  65. 65. 4. Application Promotion <br />
  66. 66. 5. Closed Loop Compliance <br />
  67. 67. 6. Proactive Incident Management<br />
  68. 68. Agenda<br />Major Assumptions<br />Operating Model Scope<br />Value Proposition<br />Design Approach<br />Level 0 Process Model with Level 1 ITIL V3 Mapping<br />The Model as a Business Planning Tool<br />Candidate Operational Flows<br />Next Steps<br />
  69. 69. Call to action<br />Gather data to complete Resource Model spreadsheet<br />Cross-org. process “innovation workshop”<br />Gain consensus and buy-in on high priority operational process improvement targets, KPIs, phasing, etc.<br />Organization skills assessment, remediation recommendations<br />Interface mapping across upstream and downstream systems (dependency mapping between SM, CRM, MIS, etc.)<br />Implement operational flows in POV using defined alternatives<br />Gain understanding of E2E optimization choices, e.g., replacement vs. migration<br />
  70. 70. Operating Model Focus Group Plan Milestones <br />
  71. 71. High Level Roadmap <br />Q4<br />Q2<br />Q1<br />Q3<br />Q4<br />Q2<br />Q1<br />Day One<br />Day One Operations Transition Readiness<br />Dedicated Resources Assigned (see Resource Model)<br />Stakeholder Process <br />Transition Team and Infrastructure in place<br />Governance Process<br />Business-line Application Team Engagement<br />Complete Resource Model<br />Phase 1<br />Strategic Target OM Design<br />Identify Process Owners<br />Develop Approach<br />Gain consensus on priority<br />Develop and roadmap<br />Sync with program priorities<br />Phase 2<br />Skills Assessment & Remediation Plan<br />Identify Functions / Skills Roles<br />Develop Approach<br />Gain consensus on approach<br />Execute assessment, identify gaps, develop remediation plan<br />Align plan to roadmap <br />
  72. 72. Day 1 – Operations Transition Readiness<br />Q4<br />Q2<br />Q1<br />Q3<br />Q4<br />Q2<br />Q1<br />Day 1<br />Day One Operational Transition Readiness<br />Qualified, Dedicated Resources Assigned (see Resource Required)<br />Stakeholder Process <br />Transition Team and Infrastructure in place<br />Governance Process<br />SBU Application Team Engagement<br />Complete Resource Model - deliver to WG5<br />Deliverables<br /><ul><li>Operations transition team in place, transition processes documented and ready to support Day One operations and activities
  73. 73. Stakeholder process
  74. 74. Resource Model Delivered
  75. 75. Governance Process
  76. 76. Major dependencies – Dedicated resources and infrastructure (see Day One Resource requirements), Stakeholder engagement, commitment by management to Governance Process</li></ul>Dependencies<br /><ul><li>Existence of quality metric data
  77. 77. Availability of Transition Team resources </li></li></ul><li>Phase 1 – Strategic Target Operating Model Design <br />Q4<br />Q2<br />Q1<br />Q3<br />Q4<br />Q2<br />Q1<br />Phase 2<br />Strategic Target OM Design<br />Identify Process Owners<br />Develop Approach<br />Gain consensus on priority<br />Develop and roadmap<br />Sync with Aurora priorities<br />Deliverables<br /><ul><li>Process Owners identified and committed – engagement with WG4
  78. 78. Process Models / Roadmap delivered
  79. 79. Prioritization Model / Approach / KPIs delivered
  80. 80. Major dependencies – Dedicated resources and infrastructure (see Day One Resource requirements), Process Owner participation (from Technical Operations), dedicated process design resources (see Day One Resource requirements)</li></ul>Dependencies<br /><ul><li>Availability of dedicated resources (Budget)
  81. 81. Availability and commitment of Process Owners</li></li></ul><li>Phase 2 – Skills Assessment and Remediation Plan<br />Q4 2009<br />Q2 2010<br />Q1 2010<br />Q3 2009<br />Q4 2010<br />Q2 2011<br />Q1 2011<br />Phase 2<br />Skills Assessment & Remediation Plan <br />Identify Functions / Skills Roles<br />Develop Approach<br />Gain consensus on approach<br />Execute assessment, identify gaps, develop remediation plan<br />Align plan to roadmap <br />Deliverables<br /><ul><li>Skills Assessment Framework
  82. 82. Function / skills / role profiles
  83. 83. Gap / remediation plan (e.g., Training / HR Plan)
  84. 84. Major dependencies – Dedicated resources and infrastructure (see Day One Resource requirements), Process Owner participation, dedicated HR / training resources</li></ul>Dependencies (items still to be resolved – if any, and who might be the person / group to ask)<br /><ul><li>Assessment framework (Budget)
  85. 85. Availability of Process Owners
  86. 86. Dedicated HR / Training planners (Budget)
  87. 87. Training Resources (Budget)</li>

×