Cloud Operating Model Design
Download as PPTX, PDF14 likes10,502 views
The document outlines an operating model design for managed IT services. It includes discussions of key elements like processes, governance, sourcing, services, and measurement. The agenda covers assumptions, operating model scope, value proposition, design approach, a high-level process model mapped to ITIL processes, how the model can be used for business planning, candidate operational flows, and next steps. The goal is to design an efficient operating model that improves customer experience, revenue, and organizational maturity through best practices like ITIL.
Cloud Operating Model Design
- 1. Operating Model DesignService Offering Description
- 2. 5/19/2011© Copyright 2010-2011 Sunnyside Associates, LLC. All Rights Reserved.2
- 3. Operating Model ElementsProcesses – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools. Governance – how we make and sustain important decisions about IT. Sourcing – how we select and manage the sourcing of our IT products and services. Services – our portfolio of IT products and services. Measurement – how we measure and monitor our performance. Organization – how we structure and organize our IT capabilities? 5/19/20113© Copyright 2010-2011 Sunnyside Associates, LLC. All Rights Reserved.
- 4. AgendaMajor AssumptionsOperating Model ScopeValue PropositionDesign ApproachLevel 0 Process Model with Level 1 ITIL V3 MappingThe Model as a Business Planning ToolCandidate Operational FlowsNext Steps5/19/2011© Copyright 2010-2011 Sunnyside Associates, LLC. All Rights Reserved.4
- 5. Major AssumptionsThe 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 systemsBest practice approaches should be leveraged wherever possible to deliver a Type 2 or 3 Service Provider Model (ITIL V3), e.g. managed and shared servicesIn 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. The best practice numbers will serve as a goal against which the target environment will be measured as it maturesOperational 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.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)
- 6. AgendaMajor AssumptionsOperating Model ScopeValue PropositionDesign ApproachLevel 0 Process Model with Level 1 ITIL V3 MappingThe Model as a Business Planning ToolCandidate Operational FlowsNext Steps
- 7. Process ModelEnd-to-end operating processes
- 8. Process triggers and interfaces
- 9. E.g., ITIL , eTOM, ISO 2000
- 10. Performance KPIs Operating ModelGoals are:Operational Efficiency
- 12. Revenue & MarginPeople & OrganizationRoles & Responsibilities (RACI)
- 13. Process owners
- 14. Escalations & interactions, etc.
- 15. Performance KPIs and MetricsTechnology(IT Infrastructure, Tools & Automation)Process automation
- 16. Data models and repositories (e.g., CMDB)
- 17. COTS, standards & simplificationOperating Model Scope
- 18. AgendaMajor AssumptionsOperating Model ScopeValue PropositionDesign ApproachLevel 0 Process Model with Level 1 ITIL V3 MappingThe Model as a Business Planning ToolCandidate Operational FlowsNext Steps
- 19. Assumed Operating Model Savings Targets - Operations
- 20. Assumed Operating Model Savings Targets - Support
- 21. Assumed Operating Model Savings Targets - SBUs
- 22. AgendaMajor AssumptionsOperating Model ScopeValue PropositionDesign ApproachLevel 0 Process Model with Level 1 ITIL V3 MappingThe Model as a Business Planning ToolCandidate Operational FlowsNext Steps
- 23. Design Approach: Blending Industry Best PracticesIsn’t ITIL Enough?ITIL V3 covers 100%+ of Day 1 capabilities
- 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. ITIL does not link solutions and training to a design process (it is part of release)
- 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 maturesEnd-to-end operating processesIntegrate with client requirements
- 27. AgendaMajor AssumptionsOperating Model ScopeValue PropositionDesign ApproachLevel 0 Process Model with Level 1 ITIL V3 MappingThe Model as a Business Planning ToolCandidate Operational FlowsNext Steps
- 28. Strategy & Service Operations and SupportHigh Level-Process ModelService Lifecycle ManagementBusiness Strategy, Architecture & PlanningService Management and OperationsService FulfillmentService AssuranceCustomer ServiceService Development & ManagementService Configuration & ActivationResource Development & ManagementService Quality ManagementSupplier Development & ManagementThe 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. The operating model also includes views of functionality as they span horizontally across the clients’s internal organization
- 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.Operating Model E2E ProcessesBuilt on industry best practice business and IT process modelsAddresses all of end-to-end processes needed to deliver Managed Services to customers - Includes Strategy and Service: “Enabling” processes of Business Strategy, Architecture & Planning, includingService Lifecycle Management and Service Development & ManagementOperations and Support: “Lights on,” or core operations processes of Customer Service, Service Management and Operations, including Operations Support, Billing/Chargeback, Service Desk, Service Development and ManagementService Configuration & Activation, Service Quality Management, Facilities and Operations
- 31. ITIL V3 MappingService DeskIncident/Fault ManagementProblem ManagementEvent ManagementAccess ManagementRequest FulfillmentStrategy & Service Operations and SupportService Lifecycle ManagementBusiness Strategy, Architecture & PlanningService Management and OperationsService FulfillmentService AssuranceFacilities ManagementKnowledge ManagementRelease & Deployment Mgmt.Configuration ManagementSolution ManagementService Validation & TestingService-Level ManagementChargeback ManagementChange ManagementAvailability ManagementService Continuity ManagementOperations ManagementContinuous Service ImprovementSecurity ManagementService Portfolio ManagementRisk ManagementSupplier ManagementCapacity ManagementService Catalog ManagementCompliance ManagementArchitecture ManagementDemand ManagementFinancial Management
- 33. Strategy & Service covers the processes involved in forming and deciding Service Strategy and gaining commitment from the business for thisService 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)The vertical functional groupings in are mapped from ITIL V3, Service Strategy and DesignBusiness Strategy, Architecture & Planning Processes
- 34. Level 0 Operations & Support ProcessesOperations & Support (O&S) provide the core of lights-on Operations and first- and second-line supportThe 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
- 35. Resource Model
- 36. Resource Model at a GlanceProcess GroupingITIL V3 ProcessesKey Baseline MetricsIndustry Benchmark MetricsITIL RolesHeadcount ForecastDemandForecast
- 37. AgendaMajor AssumptionsOperating Model ScopeValue PropositionDesign ApproachLevel 0 Process Model with Level 1 ITIL V3 MappingThe Model as a Business Planning ToolCandidate Operational FlowsNext Steps
- 38. The Target Model as a Business Planning ToolRoles (ITIL V3)
- 40. Skills (SFIA)
- 41. KPIs / Metrics (Role Based / Processes Based)
- 43. Allows us to dial up and down to see ROIAnticipated Trends Forecast (sample)Infrastructure Capacity, Efficiency, Scale and Ability Cope with ChangeBAU HeadcountsBAU + Incremental Initiative HeadcountsAurora Planning Timeline
- 44. Key Planning MetricsLow Hanging Fruit?Key Operations MetricsMean Time to Repair (time required to diagnose and resolve problems)Incident to Change Ratio% of Incidents Reported by End Users% of Outages Traced to Mis-configurations% of Changes Completed within change Windows% of Changes Automated versus ManualDevice to Admin RatioService roll-out cycle time (MTTD - mean time to deploy)Changes per Admin$ Unit per Device ManagedTime and cost to Audit and Remediate (Audit cycle time)Time and cost to Grant and Revoke Administrative AccessDowntime traced to compliance violations% of configuration audits passed$ Operation per Device ManagedKey Support Metrics
- 45. Ratio of L1 to L2 to L3 support staff
- 46. First call resolution rate
- 47. Percentage of escalations to L2 and L3 support
- 48. Time to plan a change
- 49. Time to approve a change
- 51. # of change collisions
- 52. % of changes rolled back
- 53. # of calls resolved via self-service requests (call avoidance)
- 54. MTBF for business availability
- 55. Ratio of planned to unplanned changes
- 56. Average cost per incident
- 57. Average cost per type of service request
- 58. % of incidents closed by L1 support
- 59. # of Incidents
- 60. Ratio of L1 to L2 to L3 incidentsCandidate Operational FlowsStart the dialogGuide POV / POC activitiesTied to KPIs / Metrics can help determine direct value opportunity
- 61. AgendaMajor AssumptionsOperating Model ScopeValue PropositionDesign ApproachLevel 0 Process Model with Level 1 ITIL V3 MappingThe Model as a Business Planning ToolCandidate Operational FlowsNext Steps
- 62. 1. New Service Request/Service Provisioning
- 63. 2. New Service Request Development Environment
- 64. 3. New Service Request Development Application
- 66. 5. Closed Loop Compliance
- 67. 6. Proactive Incident Management
- 68. AgendaMajor AssumptionsOperating Model ScopeValue PropositionDesign ApproachLevel 0 Process Model with Level 1 ITIL V3 MappingThe Model as a Business Planning ToolCandidate Operational FlowsNext Steps
- 69. Call to actionGather data to complete Resource Model spreadsheetCross-org. process “innovation workshop”Gain consensus and buy-in on high priority operational process improvement targets, KPIs, phasing, etc.Organization skills assessment, remediation recommendationsInterface mapping across upstream and downstream systems (dependency mapping between SM, CRM, MIS, etc.)Implement operational flows in POV using defined alternativesGain understanding of E2E optimization choices, e.g., replacement vs. migration
- 70. Operating Model Focus Group Plan Milestones
- 71. High Level Roadmap Q4Q2Q1Q3Q4Q2Q1Day OneDay One Operations Transition ReadinessDedicated Resources Assigned (see Resource Model)Stakeholder Process Transition Team and Infrastructure in placeGovernance ProcessBusiness-line Application Team EngagementComplete Resource ModelPhase 1Strategic Target OM DesignIdentify Process OwnersDevelop ApproachGain consensus on priorityDevelop and roadmapSync with program prioritiesPhase 2Skills Assessment & Remediation PlanIdentify Functions / Skills RolesDevelop ApproachGain consensus on approachExecute assessment, identify gaps, develop remediation planAlign plan to roadmap
- 72. Day 1 – Operations Transition ReadinessQ4Q2Q1Q3Q4Q2Q1Day 1Day One Operational Transition ReadinessQualified, Dedicated Resources Assigned (see Resource Required)Stakeholder Process Transition Team and Infrastructure in placeGovernance ProcessSBU Application Team EngagementComplete Resource Model - deliver to WG5DeliverablesOperations transition team in place, transition processes documented and ready to support Day One operations and activities
- 76. Major dependencies – Dedicated resources and infrastructure (see Day One Resource requirements), Stakeholder engagement, commitment by management to Governance ProcessDependenciesExistence of quality metric data
- 77. Availability of Transition Team resources Phase 1 – Strategic Target Operating Model Design Q4Q2Q1Q3Q4Q2Q1Phase 2Strategic Target OM DesignIdentify Process OwnersDevelop ApproachGain consensus on priorityDevelop and roadmapSync with Aurora prioritiesDeliverablesProcess Owners identified and committed – engagement with WG4
- 78. Process Models / Roadmap delivered
- 79. Prioritization Model / Approach / KPIs delivered
- 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)DependenciesAvailability of dedicated resources (Budget)
- 81. Availability and commitment of Process OwnersPhase 2 – Skills Assessment and Remediation PlanQ4 2009Q2 2010Q1 2010Q3 2009Q4 2010Q2 2011Q1 2011Phase 2Skills Assessment & Remediation Plan Identify Functions / Skills RolesDevelop ApproachGain consensus on approachExecute assessment, identify gaps, develop remediation planAlign plan to roadmap DeliverablesSkills Assessment Framework
- 82. Function / skills / role profiles
- 83. Gap / remediation plan (e.g., Training / HR Plan)
- 84. Major dependencies – Dedicated resources and infrastructure (see Day One Resource requirements), Process Owner participation, dedicated HR / training resourcesDependencies (items still to be resolved – if any, and who might be the person / group to ask)Assessment framework (Budget)
- 85. Availability of Process Owners
- 86. Dedicated HR / Training planners (Budget)