Critical Review of Open Group IT4IT Reference Architecture
8 likes1,905 views
The document critically reviews the Open Group's IT4IT reference architecture, assessing its suitability for IT operations through a value stream approach. IT4IT aims to provide an integrated framework for managing IT functions and emphasizes service lifecycles to enhance organizational competitiveness. The review includes comparisons with other operational frameworks such as the Supply Chain Operations Reference (SCOR) model, underscoring the need for precise definitions and understanding of value and supply chains.
Critical Review of Open Group IT4IT Reference Architecture
- 1. Critical Review of Open Group IT4IT Reference Architecture Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney https://www.amazon.com/dp/1797567616
- 2. Introduction • Review of the Open Group’s IT4IT Reference Architecture https://www.opengroup.org/it4it with respect to other operational frameworks to determine its suitability and applicability to the IT operating function • IT4IT is intended to be an umbrella framework independent of specific processes that takes a value stream based approach August 17, 2020 2
- 3. Topics • Value Chain And Supply Chain • Supply Chain Operations Reference (SCOR) • Activity Based Costing • Organisation Value Chain And IT Value Chain • Introduction To IT4IT Reference Architecture • Issues With IT4IT Framework August 17, 2020 3
- 4. IT4IT Reference Architecture • IT4IT is intended to be a reference architecture for the management of the IT function • It aims to take a value chain approach to create a model of the functions that IT performs and the services it provides to assist organisations in the identification of the activities that contribute to business competitiveness • It is intended to be an integrated framework for the management of IT that emphasises IT service lifecycles • It aims to identify what the IT function must do well • It looks to attain efficiencies using supply chain-like approach to IT services • IT4IT reference architecture specifies an IT Value Chain August 17, 2020 4
- 5. Value Chain And Supply Chain • In order to understand the IT4IT approach it is first important to understand the meaning of value chain and supply chain • The phrases value chain and supply chain are all too frequently used without precise definitions and understanding of what they exactly mean August 17, 2020 5
- 6. Tradition View Of Value Chain • Value chain view observes how an organisation creates a finished product or service from raw inputs through activities that add value by increasing its worth (the amount that can be charged) over the sum of the cost of the inputs • Product or service is then offered or made available to an external customer or service user who typically pays for them, directly or indirectly August 17, 2020 6 Raw Input Cost Cost of Value Adding Activities Value of Finished Product or Services Value Added
- 7. Different Value Profiles For Different Products And Services • The different types of products and services developed and offered by an organisation will have different value profiles August 17, 2020 7 Raw Input Cost Cost of Value Adding Activities Value of Finished Product or Services Value Added Raw Input Cost Cost of Value Adding Activities Value of Finished Product or Services Value Added Raw Input Cost Cost of Value Adding Activities Value of Finished Product or Services Value Added Raw Input Cost Cost of Value Adding Activities Value of Finished Product or Services Value Added
- 8. Traditional View of Primary And Secondary Value Adding Activities August 17, 2020 8 Legal, Regulatory, Environment, Health and Safety Services Procurement, Supplier and Partner Services Knowledge, Improvement and Change Services Research and Develop and Manage Products and Services Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service Facilities Services Financial Services Information Technology Services Human Resource Services Value Added Supporting and Enabling Secondary Activities Primary Value Creating Activities
- 9. Value Chain • The value chain is the series of primary activities and their associated business processes that act on the raw inputs and work towards creating and providing the finished product or service to the target customer • Value added is the cost at which the product or service is sold or provided less the input costs August 17, 2020 9 Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service
- 10. Value Chain And Business Processes • The value chain is implemented through business processes • The business process is a standard set of activities that is designed to achieve a specific task transforming inputs into outputs • The external value chain representation masks multiple internal business processes August 17, 2020 10 Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service
- 11. Traditional View of Primary And Secondary Value Adding Activities • Supporting and Enabling Secondary Activities are sets of common services used across the organisation and typically provided by shared business functions or by outsourced service providers managed by business functions • The primary value chain activities call on the services offered by the secondary activities • The classification of these secondary activities and their processes and relative importance will vary between organisations August 17, 2020 11
- 12. Value Chain And Supporting Activities And Processes August 17, 2020 12 Legal, Regulatory, Environment, Health and Safety Services Procurement, Supplier and Partner Services Knowledge, Improvement and Change Services Research and Develop and Manage Products and Services Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service Facilities Services Financial Services Information Technology Services Human Resource Services
- 13. Supporting and Enabling Secondary Activities • Human Resource Services – staffing, recruitment, personnel management, payroll, organisation management services • Information Technology Services – management of the provision of IT services • Financial Services – invoicing, collection, debt management, financial control services • Facilities Services – locations, building and facilities management services • Legal, Regulatory, Environment, Health and Safety Services – regulatory monitoring and compliance, environmental and safety services • Procurement, Supplier, and Partner Services – management of supplier and product and service selection and acquisition and relationship management services • Knowledge, Improvement and Change Services – manage organisation knowledge and manage service improvement and change initiatives • Research and Develop and Manage Products and Services – identification and development of new products and services August 17, 2020 13
- 14. Contribution To Cost Of Value Adding Activities • The costs of the core and extended activities involved in the end-to- end supply of the product and service affects the value added August 17, 2020 14 Raw Input Cost Cost of Value Adding Activities Value Achieved for Finished Product or Service Value Added Legal, Regulatory, Environment, Health and Safety Services Procurement, Supplier and Partner Services Knowledge, Improvement and Change Services Research and Develop and Manage Products and Services Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service Facilities Services Financial Services Information Technology Services Human Resource Services
- 15. Profile Of Activity Cost Contribution To Value Chain • Contribution and cost allocation for each primary and secondary activity to the product or service cost profile will be different for each primary and secondary activity • Cost profile of a product or service will also change over time August 17, 2020 15 Legal, Regulatory, Environment, Health and Safety Services Procurement, Supplier and Partner Services Knowledge, Improvement and Change Services Research and Develop and Manage Products and Services Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service Facilities Services Financial Services Information Technology Services Human Resource Services
- 16. Profiles Of Activity Cost Contribution To Products/Services Value Chains August 17, 2020 16 • The core and extended value chain cost profile for each product or service will be different Legal, Regulatory, Environment, Health and Safety Services Procurement, Supplier and Partner Services Knowledge, Improvement and Change Services Research and Develop and Manage Products and Services Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service Facilities Services Financial Services Information Technology Services Human Resource Services
- 17. Value Chain And Organisation Competitiveness • Sum of value generated across all products and services is a measure of the current competitiveness of the organisation • An effective activity cost model identifies the actual cost of primary and support services that contribute to the generation of value • Supply chain processes monitor the competitors and their impact on value chains August 17, 2020 17
- 18. Wider Supply Chain Context Of Value Chain August 17, 2020 18 Legal, Regulatory, Environment, Health and Safety Services Procurement, Supplier and Partner Services Knowledge, Improvement and Change Services Research and Develop and Manage Products and Services Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service Facilities Services Financial Services Information Technology Services Human Resource Services Sourcing Planning Enabling Delivery ReturnsWork in Progress Demand Competition Production Support
- 19. Wider Supply Chain Context Of Value Chain • The value chain is the specific set of activities that directly and indirectly contribute to the creation and supply of the product or service • The value chain sits within a wider supply chain involving a range of activities and events that impact the value chain, both negatively and positively • There are various views of how to categorise the supply chain • The most widely used and most comprehensive one is Supply Chain Operations Reference (SCOR) - https://www.apics.org/apics-for- business/frameworks/scor − The SCOR model identifies six primary supply management processes: Plan, Source, Make, Deliver, Return and Enable − The SCOR model is aimed at manufacturing, transportation, delivery and logistics organisations − However, its principles and structures can be readily applied and adapted to service organisations − Any analysis of supply chain activities should at least make reference to SCOR August 17, 2020 19
- 20. SCOR Model Structure August 17, 2020 20 SCOR Performance Performance Attributes Reliability Responsiveness Agility Costs Asset Management Efficiency Metrics Reliability Metrics Responsiveness Metrics Agility Metrics Costs Metrics Asset Management Efficiency Metrics Level 1 Metrics Level 2 Metrics Level 3 Metrics Process/ Practice Maturity Stage 1: Initial; Stage 2: Managed; Stage 3: Defined; Stage 4: Quantitatively Managed; Stage 5: Optimising Processes Level 1 – Major Processes Level 2 – Process Categories Level 3 – Process Elements Level 4 – Improvement Tools and Activities Practices Standard Practices Best Practices Emerging Practices People Competency Level Expert Proficient Competent Beginner Novice
- 21. SCOR Metrics Level 1 And Level 2 Structure August 17, 2020 21 Metrics Reliability Perfect Order Fulfilment % of Orders Delivered In Full Delivery Performance to Customer Commit Date Documentation Accuracy Perfect Condition Responsiveness Order Fulfilment Cycle Time Source Cycle Time Make Cycle Time Deliver Cycle Time Delivery Retail Cycle Time Agility Upside Supply Chain Adaptability Upside Adaptability (Source) Upside Adaptability (Make) Upside Adaptability (Deliver) Upside Return Adaptability (Source) Upside Return Adaptability (Deliver) Downside Supply Chain Adaptability Downside Adaptability (Source) Downside Adaptability (Make) Downside Adaptability (Deliver) Overall Value- at-Risk (VaR) Supplier’s/ Customer’s/ Product’s Risk Rating Value at Risk (Plan) Value at Risk (Source) Value at Risk (Make) Value at Risk (Deliver) Value at Risk (Return) Time to Recovery Costs Total SC Management Cost Cost to Plan Cost to Source Cost to Make Cost to Deliver Cost to Return Mitigation Cost Cost of Goods Sold (COGS) Cost to Plan Supply Chain Cost to Plan Source Cost to Plan Make Cost to Plan Deliver Cost to Plan Return Asset Management Efficiency Cash to Cash Cycle Time Days Sales Outstanding Inventory Days of Supply Days Payable Outstanding Return on Supply Chain Fixed Assets Supply Chain Revenue Supply Chain Fixed Assets Return on Working Capital Accounts Payable (Payables Outstanding) Accounts Receivable (Sales Outstanding) Inventory
- 22. Sample SCOR Level 1/2/3 Metrics – Reliability August 17, 2020 22 ReliabilityPerfect Order Fulfilment % of Orders Delivered In Full Delivery Item Accuracy Percentage of orders in which all items ordered are the items actually provided, and no extra items are provided Delivery Quantity Accuracy Percentage of orders in which all quantities received by the customer match the order quantities (within mutually agreed tolerances) Delivery Performance to Customer Commit Date Customer Commit Date Achievement Time Customer Receiving Percentage of orders which is received on time as defined by the customer Delivery Location Accuracy Percentage of orders which is delivered to the correct location and customer entity Documentation Accuracy Compliance Documentation Accuracy Percentage of compliance documentation that are complete, correct and readily available when and how expected by customer, Government and other supply chain regulatory entities Other Required Documentation Accuracy Percentage of other required documentations (besides of compliance documentation, payment documentation and shipping documentation) are complete, correct, and readily available when and how expected by customer, Government and other supply chain regulatory entities Payment Documentation Accuracy Percentage of payment documentation that are complete, correct, and readily available when and how expected by customer, Government and other supply chain regulatory entities Shipping Documentation Accuracy Percentage of shipping documentations are complete, correct, and readily available when and how expected by customer, Government and other supply chain regulatory entities Perfect Condition % of Faultless Installations Number of Faultless Installations divided by Total Number of Units Installed % Orders/lines received damage free The number of orders / lines that are processed damage free divided by the total orders / lines processed in the measurement period Orders Delivered Damage Free Conformance Percentage of orders which is delivered without damage Orders Delivered Defect Free Conformance Percentage of orders which is delivered without defect Warranty and Returns Number of returns within the warranty period - warranty is a commitment, either expressed or implied that a certain fact regarding the subject matter of a contract is presently true or will be true
- 23. SCOR Process Structure And Hierarchy – 1/3 August 17, 2020 23 SCOR Plan Plan Supply Chain Identify, Prioritise and Aggregate Supply Chain Requirements Identify, Prioritise and Aggregate Supply Chain Resources Balance Supply Chain Resources with SC Requirements Establish and Communicate Supply Chain Plans Plan Source Identify, Prioritise and Aggregate Product Requirements Identify, Assess and Aggregate Product Resources Balance Product Resources with Product Requirements Establish Sourcing Plans Plan Source Identify, Prioritise and Aggregate Production Requirements Identify, Assess and Aggregate Production Resources Balance Production Resources with Production Requirements Establish Production Plans Plan Deliver Identify, Prioritise and Aggregate Delivery Requirements Identify, Assess and Aggregate Delivery Resources Balance Delivery Resources and Capabilities with Delivery Requirements Establish Delivery Plans Plan Return Assess and Aggregate Return Requirements Identify, Assess and Aggregate Return Resources Balance Return Resources with Return Requirements Establish and Communicate Return Plans Source Source Stocked Product Schedule Product Deliveries Receive Product Verify Product Transfer Product Authorise Supplier Payment Source Make-to- Order Product Schedule Product Deliveries Receive Product Verify Product Transfer Product Authorise Supplier Payment Source Engineer- to-Order Product Identify Sources of Supply Select Final Supplier and Negotiate Schedule Product Deliveries Receive Product Verify Product Transfer Product Authorise Supplier Payment Make Make-to-Stock Schedule Production Activities Issue Material Produce and Test Package Stage Product Release Product to Deliver Waste Disposal Make-to-Order `Schedule Production Activities Issue Sourced/In- Process Product Produce and Test Package Stage Finished Product Release Finished Product to Deliver Waste Disposal Engineer-to-Order Finalise Production Engineering Schedule Production Activities Issue Sourced/In- Process Product Produce and Test Package Stage Finished Product Release Product to Deliver Waste Disposal
- 24. SCOR Process Structure And Hierarchy – 2/3 August 17, 2020 24 SCOR Deliver Deliver Stocked Product Process Inquiry and Quote Receive, Enter, and Validate Order Reserve Inventory and Determine Delivery Date Consolidate Orders Build Loads Route Shipments Select Carriers and Rate Shipments Receive Product from Source or Make Pick Product Pack Product Load Vehicle and Generate Shipping Documents Ship Product Receive and Verify Product by Customer Install Product Invoice Deliver Make-to- Order Product Process Inquiry and Quote Receive, Configure, Enter and Validate Order Reserve Inventory and Determine Delivery Date Consolidate Orders Build Loads Route Shipments Select Carriers and Rate Shipments Receive Product from Source or Make Pick Product Pack Product Load Product and Generate Shipping Docs Ship Product Receive and Verify Product by Customer Install Product Invoice Deliver Engineer-to- Order Product Obtain and Respond to RFP/RFQ Negotiate and Receive Contract Enter Order, Commit Resources and Launch Program Schedule Installation Build Loads Route Shipments Select Carriers and Rate Shipments Receive Product from Source or Make Pick Product Pack Product Load Product and Generate Shipping Docs Ship Product Receive and Verify Product by Customer Install Product Invoice Deliver Retail Product Generate Stocking Schedule Receive Product at Store Pick Product from backroom Stock Shelf Fill ShoppingCart Checkout Deliver and/or install Return Source Return Defective Product Identify Defective Product Condition Disposition Defective Product Request Defective Product Return Authorisation Schedule Defective Product Shipment Return Defective Product Deliver Return Defective Product Authorise Defective Product Return Schedule Defective Return Receipt Receive Defective Product (includes verify) Transfer Defective Product Source Return MRO Product Identify MRO Product Condition Disposition MRO Product Request MRO Return Authorisation Schedule MRO Shipment Return MRO Product Deliver Return MRO Product Authorise MRO Product Return Schedule MRO Return Receipt Receive MRO Product Transfer MRO Product Source Return Excess Product Identify Excess Product Condition Disposition Excess Product Request Excess Product Return Authorisation Schedule Excess Product Shipment Return Excess Product Deliver Return Excess Product Authorise Excess Product Return Schedule Excess Return Receipt Receive Excess Product Transfer Excess Product
- 25. SCOR Process Structure And Hierarchy – 3/3 August 17, 2020 25 SCOR Enable Manage Supply Chain Business Rules Gather Business Rule Requirements Interpret Business Rule Requirement Document Business Rule Communicate Business Rule Release/Publish Business Rule Retire Business Rule Manage Supply Chain Performance Initiate Reporting Analyse Reports Find Root Causes Prioritise Root Causes Develop Corrective Actions Approve and Launch Manage Data and Information Receive Maintenance Request Determine/Scope Work Maintain Content/Code Maintain Access Publish Information Verify Information Manage Supply Chain Human Resources Identify Skills/Resource Requirement Identify Available Skills/Resources Match Skills/Resources Determine Hiring/ Redeployment Determine Training/ Education Approve, Prioritise and Launch Manage Supply Chain Assets Schedule Asset Management Activities Take Asset Off- line Inspect and Troubleshoot Install and Configure Clean, Maintain and Repair Decommission and Dispose Inspect Maintenance Reinstate Asset Manage Supply Chain Contracts Receive Contract /Agreement Updates Enter and Distribute Contract /Agreement Activate/ Archive Contract/ Agreement Review Contractual Performance Agreement Identify Performance Issues/ Opportunities Identify Resolutions/ Improvements Select, Prioritise and Distribute Resolutions Manage Supply Chain Network Select Scope and Organisation Gather Input and Data Develop Scenarios Model/Simulate Scenarios Project Impact Select and Approve Develop Change Program Launch Change Program Manage Regulatory Compliance Monitor Regulatory Entities Assess Regulatory Publications Identify Regulatory Deficiencies Define Remediation Verify/Obtain License Publish Remediation Manage Supply Chain Risk Establish Context Identify Risk Events Quantify Risks Evaluate Risks Risk Handling Strategy Manage Supply Chain Procurement Develop Strategy and Plan Pre-Procurement /Market Test and Market Engagement Develop Documentation, PPQ /Detailed Spec/ Combine with 1 Supplier Selection to Participate in ITT /RFQ /Negotiation Issue ITT /RFQ Bid /Tender Evaluation and Validation Contract Award and Implementation Manage Supply Chain Technology Define Supply Chain Technology Requirements Identify Technology Solution Alternatives Define/Update Supply Chain IT Roadmap Select Technology Solution Deploy Technology Solution Maintain and Improve Technology Solution Retire Technology Solution
- 26. Wider SCOR Context • The SCOR model is part of wider set of operations reference models that describe a view of the critical elements in a value chain − Product Life Cycle Operations Reference model (PLCOR) • Manages the activities for product innovation and product and portfolio management − Customer Chain Operations Reference model (CCOR) • Manages the customer interaction processes − Design Chain Operations Reference model (DCOR) • Manages the product and service development processes − Managing for Supply Chain Performance (M4SC) • Translates business strategies into supply chain execution plans and policies August 17, 2020 26 DCOR Design Chain Operations PLCOR Product Life Cycle Operations CCOR Customer Chain Operations SCOR Supply Chain Operations M4SC Managing for Supply Chain Performance Plan Source Make Deliver Return Enable Plan Ideate Develop Launch Revise Enable Plan Relate Sell Contract Assist Plan Research Design Integrate Amend Business Environment M a r k e t s S u p p l i e r s Customers
- 27. SCOR Performance Metrics August 17, 2020 27 Process MetricsEach Process Has Metrics Practices People Data MetricsMetrics Metrics Require Data
- 28. Key Supply Chain Processes Planning Develop, manage and maintain the organisation’s overall product or service supply chain processes to ensure that demand and supply are balanced and optimised Enabling Implement and operate and monitor the performance of the supply chain management processes such sourcing, logistics, finance, resourcing, information technology, sales and support Sourcing Manage and operate the selection of suppliers and the sourcing of raw product or service inputs as well as suppliers of secondary service Production Transform the raw material into the finished product or service to meet planned or actual demand Work in Progress Manage incomplete products and services as they are being worked or and transformed Delivery Deliver the completed products and services to customers including handling orders, distribution, transportation Returns Handle customer returns or rejections of delivered products and services Support Handle post-delivery support including maintenance, implementation of enhancements, upgrades Demand Monitor, understand and handle customer demand for products and services and circumstances that cause a change in demand and manage changes in those demands and associated changes to the other supply chain processes Competition Monitor, understand and handle competition in the supply of products and services from other sources and manage responses to competition August 17, 2020 28
- 29. Supply Chain Impact On Value Chain • Changes in the supply chain affect the value chain in many ways: − Sourcing, procurement and acquisition circumstances might change, affecting input costs − Product and service demand might change, affecting the ability to achieve the anticipated value − Competition might arise, affecting the cost that can be realised for the products or services − Support requirements might change, affecting value generated − The level of product returns or service cancellations might be different than planned for, impacting value achieved • Value chain analysis does not exist in isolation August 17, 2020 29
- 30. Activity Based Costing • How do you know the costs of the primary and secondary processes in the product or service value chain? • How do you allocate the overheads associated with the shared secondary activities and processes across all product and service value chains? • How do know the actual value being created? • Activity-based costing (ABC) is an approach to understanding costing that identifies activities in an organisation and assigns the cost of each activity to all products and services according to the actual consumption of those activities by each products or services • Use as a tool for understanding product and service and customer cost and profitability • ABC supports strategic decisions such as pricing, investments, outsourcing and identification and measurement of process improvement initiatives August 17, 2020 30
- 31. Activity Based Costing • Establishing a cross-functional view of your organisation and understanding what drives your costs is essential • Pulling apart indirect or hidden costs and attributing them correctly to products and services August 17, 2020 31 Activities Resources Products, Services and Customers Cost Drivers Performance Measures
- 32. Approaches To Determining Cost • Organisational Element Accounting August 17, 2020 32 Direct Costs Overhead Accounting System
- 33. Approaches To Determining Cost • Budgetary Cost Distribution /Commitment Accounting August 17, 2020 33 Commitments and Obligations Accounting System
- 34. Approaches To Determining Cost • Traditional Cost Accounting August 17, 2020 34 Direct Labour Direct Materials Activities Output Cost Overhead
- 35. Approaches To Determining Cost • Activity Based Costing August 17, 2020 35 Direct Labour and Overhead Direct Materials Activities Output Cost
- 36. Steps To Implementing Activity Based Costing August 17, 2020 36 General Ledger and Other Sources Departments Activities Cost Objects Calculate Profitability
- 37. Defining Activities • Most organisations use a cost centre structure • Recast the cost centre structure into activities • Usually a hierarchy of activities − Direct identification with product or service − Process support − Organisation and facility support − Customer/market support • Map from cost centre into activity hierarchy August 17, 2020 37
- 38. Traditional Cost Accounting View - Direct Costs August 17, 2020 38 ▪ Product A • 100 units • 1 hour direct labour at €20/hour • €20/unit direct cost • 100 total hours total effort to produce ▪ Product B • 950 units • 2 hours direct labour at €20/hour • €40/unit direct cost • 1,900 total hours of effort to produce • Total amount of effort for 100 units of Product A and 950 units of Product B is 2,000 hours • Assume the overheads total is €100,000
- 39. Traditional Cost Accounting View – Allocation Of Overheads • Traditional Cost Accounting Overhead Costs − = €100,000 /2,000 hours of effort across both sets of product creation activities − = €50 per hour • Product A − 1 hour to produce − = €50 x 1 hour − = €50 • Product B − 2 hours to produce − = €50 x 2 hours − = €100 August 17, 2020 39
- 40. Traditional Cost Accounting View - Total Cost • Product A • Direct Production Costs = €20 • + Overhead = €50 • Total Cost = €70 • Product B • Direct Production Costs = €40 • + Overhead = €100 • Total Cost = €140 August 17, 2020 40
- 41. Activity Based Costing – Calculation Of Overheads • Look at the activities the organisation performs for each product and their costs August 17, 2020 41 Activity Total Cost Cost Driver Setup €10,000 Number of setups Machining €40,000 Number of hours Receiving €10,000 Number of receipts Packaging €10,000 Number of deliveries Engineering €30,000 Number of hours Total €100,000
- 42. Activity Based Costing – Calculation Of Overheads • Allocate activities to products and understand the actual activity costs associated with each product August 17, 2020 42 Activity Product A Cost Product B Cost Cost Setup 1 €2,500 3 €7,500 €10,000 Machining 1 €2,000 3 €38,000 €40,000 Receiving 100 €2,500 1,900 €7,500 €10,000 Packaging 1 €2,500 3 €7,500 €10,000 Engineering 500 €15,000 500 €15,000 €30,000 Total €24,500 €75,500 €100,000 • Apportioning total overheads for each product according to their actual usage: − Product A - €24,500 /100 units = €245 − Product B - €75,500 /950 units = €79.47
- 43. Activity Based Costing Creates A Different View Of Product Costs • Product A • Direct Costs = €20 • + ABC Overhead = €245 • Total Cost = €265 • Product B • Direct Costs = €40 • + ABC Overhead = €79.47 • Total Cost = €119.47 August 17, 2020 43
- 44. Comparison Between Traditional Cost Accounting and ABC • Product A is much more expensive to produce than originally thought • If Product A is priced based on original view of costs, you will lose money • Product B is cheaper to produce and so its price could be reduced to stimulate greater demand or capture greater market share for competitors while still making a profit • Activity Based Costing provides a better understanding of consumption of resources across the product or service value chain August 17, 2020 44 Product A Product B TCA ABC TCA ABC Direct Costs £20 £20 £40 £40 Overhead Costs £50 £245 £100 £79.47 Total £70 £265 £140 £119.47
- 45. Organisation Value Chain And IT Value Chain • The IT value chain is a chain within a chain • The IT function supplies services to the business to support and enable its value chain • The same principles that apply to organisation value chains can be applied to the IT value chain August 17, 2020 45 Legal, Regulatory, Environment, Health and Safety Services Procurement, Supplier and Partner Services Knowledge, Improvement and Change Services Research and Develop and Manage Products and Services Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service Facilities Services Financial Services Human Resource Services Legal, Regulatory, Environment, Health and Safety Services Procurement, Supplier and Partner Services Knowledge, Improvement and Change Services Research and Develop and Manage Products and Services Acquire Raw Inputs Create Product or Service Market and Sell Product or Service Deliver or Supply Product or Service Service and Support Product or Service Facilities Services Financial Services Information Technology Services Human Resource Services IT Value Chain Organisation Value Chain
- 46. Organisation Value Chain And IT Value Chain • In the case of services provided by the IT function, these are rarely provided directly to paying external customers − Even where the solutions and services are used directly by external customers, the value generated accrues to the owning business function • The business value generated by the solutions and services provided by the IT function is indirect • The IT function has little direct control over the value the business generates from the solutions and services • The business uses the IT services as part of their value chain. August 17, 2020 46
- 47. Organisation Value Chain And IT Value Chain • The IT function is all too often a monopoly provider of IT services to the business functions or at least a gatekeeper to external solution and service providers, allowing or disallowing their introduction and use • This gives rise to shadow IT where the business bypasses what they view and experience as an unresponsive central IT function and goes directly to external service providers • Monopoly providers are in a privileged position and need to recognise this and be subject to appropriate governance and oversight to ensure that the lack of competition does not lead to accidental or deliberate abuse. August 17, 2020 47
- 48. Value Chain Value Chain, Secondary Services, Supply Chain And Cost Analysis August 17, 2020 48 Secondary Supporting Services and Processes Supply Chain Cost Analysis Value Chain Draws on Secondary Services Wider Supply Chain Impacts Operation of Value Chain Accurate Cost Analysis is Important to Understanding Actual Value Accurate Cost Analysis is Important to Understanding Actual Value Wider Organisation Operating Landscape Supply Chain Assists With Understanding External Value Pressures Supply Chain Processes Have Costs
- 49. Introduction To IT4IT Reference Architecture August 17, 2020 49
- 50. IT4IT Reference Architecture • IT4IT aims to be a standard and repeatable reference architecture that enables the creation of an information technology management environment • It is intended to provide a guide to the design of the IT service delivery function • It seeks to enable organisations adapt to changes in technologies, methodologies and processes without having to alter the IT management approach, structure and operations August 17, 2020 50
- 51. IT4IT IT Value Chain 17 August 2020 51 Governance, Risk and Compliance Strategy to Portfolio Requirement to Deployment Request to Fulfil Detect to Correct Resource and Project Intelligence and Reporting Sourcing and Vendor Finance and Assets Efficiency and Agility Supporting Activities Value Streams Plan Build Deliver Run
- 52. IT4IT IT Value Chain • Primary Value Streams • Strategy to Portfolio • Requirement to Deploy • Request to Fulfil • Detect to Correct • Supporting Activities • Governance Risk and Compliance • Sourcing and Vendor • Intelligence and Reporting • Finance and Assets • Resource and Project August 17, 2020 52
- 53. IT Pillars Of IT4IT Reference Architecture • Service Model • Information Model • Functional Model • Integration Model August 17, 2020 53
- 54. Service Model • Based on a provider/broker model to define the way IT provides services to the business • Emphasises services as the primary IT deliverable • Uses a service-centric lifecycle framework to provide a continuous assessment of the portfolio, sourcing and integrating components and servers offered to consumers • Service model is designed to store and manage service information – entities, data, attributes, relationships • Each of the four IT Value Streams uses elements of the Service Model to create an integrated view of IT August 17, 2020 54
- 55. IT4IT Service Model Backbone August 17, 2020 55 Service Providers Service Consumers Service Model Conceptual Logical Realised Continuous Assessment Continuous Integration Continuous Delivery Conceptual Service Logical Service Service Release Service Release Blueprint Service Catalog Entry Desired Service Actual Service
- 56. Four Primary Value Streams • Request to Fulfil (R2F) • Accepts the Service Release Blueprint and creates Service Catalog Entries describing its technical capabilities that are incorporated into Offers • Offers have Service Contracts that define their usage • Services are moved into production • Detect to Correct (D2C) • Creates an operational service management framework that monitors service operation and use and the IT Operations that incorporate services • Provides feedback on service usage to Strategy to Portfolio (S2P) for new services or changes to existing services August 17, 2020 56 • Strategy to Portfolio (S2P) • Accepts and processes requests for new services or changes to existing services from business functions or IT • Creates a Conceptual Service design that connects the business and IT elements of • Requirement to Deploy (R2D) • Accepts the Conceptual Service and creates a more detailed description of the Logical Service and its components • In turn this is used to create Service Release which is defined in Service Release Blueprint • The service is developed or procured and delivered
- 57. Primary Value Streams And Service Models August 17, 2020 57 Strategy to Portfolio Requirement to Deployment Request to Fulfil Detect to Correct Conceptual Service Model Realised Service Model Logical Service Model Drive IT Value Measure and Create Insight
- 58. Service Model Elements • Each of the four value streams are designed to contain the capabilities needed to manage the service lifecycle • Capabilities are achieved as a set of functional components and data objects • Functional components are individual stand-alone technology units that can perform a discrete function • Functional components have defined data objects as inputs and outputs • Data objects are intended to hold essential, relevant sets of (business) data that are used, processed, enriched, extended or changed by functional components • Data objects are also used to hold details on relationships between functional components August 17, 2020 58
- 59. IT Service Lifecycle • The four Value Stream elements are intended to describe the service lifecycle • The functional components in each Value Stream elements create and update data objects August 17, 2020 59 Strategy to Portfolio Requirement to Deployment Request to Fulfil Detect to Correct IT Value Chain Plan and drive the IT portfolio to achieve business innovation Provide what the business needs when it needs it Describe, catalogue, fulfil, monitor and manage service usage Anticipate and resolve operational and service issues
- 60. IT4IT Information Model • Information model consists of service lifecycle model data objects and their linkages • Each of the value streams creates, uses and updates data objects • Each data object describes a dimension of a service • Data objects are inputs to or outputs from a functional component or a phase of the service lifecycle • Each data object has its own lifecycle • The data object contains information structures that allows its relationships be recorded and maintained • IT4IT focuses on data rather than organisation processes or structures − The organisation information model is less subject to change that processes or structures August 17, 2020 60
- 61. Data Object Types • Key Data Objects – contain information on how services are created, provided and accessed − Uses in managing the service lifecycle • Service Model Backbone Data Objects – contain information on the functionality provided − Conceptual − Logical • Design • Release • Consumable − Realised • Desired • Actual • Auxiliary Data Objects – contain context and attribute information August 17, 2020 61
- 62. Functional Model • Functional components are stand-alone building blocks within value streams that create and use data objects − Generally one data object for each functional component • The Functional Model defines the functional components and their relationships • Functional components are linked to IT capabilities – a function or activity that creates an result August 17, 2020 62
- 63. Functional Model Types • Primary Functional Component – performs a core role in the actions of a value stream • Secondary Functional Component – not central to the operations of a value stream but there is a dependency − May be a primary functional component to another value stream or provide supporting functionality and capability • Some functional components can be primary to more than one value stream August 17, 2020 63
- 64. Functional Components Within IT4IT Value Streams August 17, 2020 64 Strategy to Portfolio (S2P) Enterprise Architecture Policy Proposal Portfolio Demand Service Portfolio IT Investment Portfolio – Auxiliary Requirement to Deploy (R2D) Project Requirement Service Design Source Control Build Build Package Release Composition Test Defect Request to Fulfil (R2F) Engagement Experience Portal – Secondary Offer Consumption Offer Management Catalog Composition Request Rationalisation Fulfilment Execution Usage Chargeback/Showback Knowledge and Collaboration Supporting Function Detect to Correct (D2C) Service Monitoring Event Incident Problem Change Control Configuration Management Diagnostics and Remediation Service Level
- 65. Integration Model • IT4IT integration model aims to simplify the creation of management subsystem using functional components • Integrations are typically accompanied by a System of Record data flow • Integration types: − System of Record Data Centric • Enables consistent management of data object lifecycle • Ensures data objects are consistently named and linked between functional components • Maintains the integrity of the Service Model − System of Engagement Experience-Centric • User interface integrations • Combine functional components to create a user-case or usage journey that facilitates interactions − System of Insight Intelligence, Analytics and KPI-Centric • Data-centric integrations • Provide end-to-end traceability, visibility, transparency and capture measurements related to services • Facilitates the exchange of structured and unstructured data that is created across the value chain August 17, 2020 65
- 66. IT Service • IT services perform work on behalf of a service consumer to generate a result, outcome or a change of state • Three service elements − Service Offer – the capability of the service that is made available to and consumed − Service Interaction – the invocation of the service by the service consumer communicated to the service provider and the input and output information − Service System – the set of technology components, processes and people that constitute the service, deliver on the Service Offer and perform the Service Interaction August 17, 2020 66
- 67. IT Service August 17, 2020 67 Service System Technology, Processes, People, Skills, Information Service Offer Published Capability, Contract Service Interaction Invocation, Performance, Transaction Is An Abstraction Of Defines The Provider Scope And Expectations IT Service Service Outcome Technology, Processes, People, Skills, Information Enables And Allows Results In Defines The Consumer Expectations
- 68. IT4IT Abstraction Levels And Class Structure • IT4IT Reference Architecture has five levels of abstraction and detail • Each lower level extends the higher level with more detail August 17, 2020 68 Level 1 – End-to-End Overview Level 2 – Value Stream Documentation Level 3 – Vendor-independent Architecture Level 4 – Vendor-Specific Refinement Architecture Level 5 – Solution Architecture Contains vendor- independent generalised views that can be used for strategy and planning and the creation IT management roadmaps Contains specific details that enable the development of implementation and the design of products
- 69. Level 1 – End-to-End Overview • Provides an overview of the IT4IT Reference Architecture • Introduces the five core concepts: − Value Streams − Functional Components − Service Lifecycle Data Objects − Service Model Backbone Data Objects − Relationships August 17, 2020 69
- 70. Level 1 Class Model • All data objects are viewed as service lifecycle data objects • The service lifecycle data objects that represent the Service Model are a type of lifecycle data object August 17, 2020 70 Value Stream Functional Component Lifecycle Data Object Service Backbone Data Object RelationshipHas One or More Has One or More
- 71. Value Streams • Value streams are groups of functional components and data objects where value is created − Strategy to Portfolio (S2P) − Requirement to Deploy (R2D) − Request to Fulfil (R2F) − Detect to Correct (D2C) • Supporting functions within the value chain model − Supplier Management − Asset Management − Human Resource Management − Legal − IT Financial Management August 17, 2020 71
- 72. Functional Components • Smallest technology unit or component that can stand on its own and be able to perform a useful function • Has data objects as defined inputs and outputs • Performs an operation on (one or more) data objects • Functional components are associated with a specific primary value streams and supporting functions • Secondary functional components that operate on data objects outside their primary value stream August 17, 2020 72
- 73. IT4IT Level 1 Reference Architecture August 17, 2020 73
- 74. Service Lifecycle Data Object • Service lifecycle data object represents data(in a variety of forms and formats that describe, represent or extend an aspect of a service being offered by IT • Data objects can be digital or physical and can contain structured, semi-structured, or unstructured data • Service Model Backbone data objects are a specific data object type that combine all the information needed to offer and manage a service • The IT4IT reference architecture seeks to define the data objects that are needed to ensure end-to-end operational or financial traceability of a service along the service lifecycle • The service lifecycle data objects represent the authoritative source data and/or master data needed to manage the business of IT August 17, 2020 74
- 75. Relationships • IT4IT Reference Architecture seek to defining both the data objects and their key relationships • The data objects and their relationships and dependencies form the System of Record Fabric for IT management • These relationships are viewed as System of Record Integrations • This System of Record Relationship Mapping is designed to ensure end-to-end service traceability and to ensure the Service Model integrity is be maintained across the lifecycle • Adhering to it removes any confusion and conflicts that may arise from process re-engineering exercises that may take place within the IT function August 17, 2020 75
- 76. IT4IT System Of Record Fabric • System of Record Fabric showing the Service Lifecycle Data Object and their relationships August 17, 2020 76
- 77. IT4IT Level 2 Reference Architecture • Level 2 expands on Level 1 with the following: − The relationships between data objects have multiplicity/cardinality (one-to-one, one to many, many-to-many) attributes added − Details on data flows between functional components are added − Data flows details on integrations are added − Relationships between capability disciplines and functional components are added August 17, 2020 77
- 78. IT4IT Level 2 Class Model • Multiplicity is the number of allowable instances of an element in terms of the relationships between data object instances • Only key relationships - those that contribute to the advancement of the service lifecycle – are defined • There are other relationships that may be needed to define specific policies, processes or capabilities but these are not prescriptive August 17, 2020 78
- 79. Level 2 Data Flows • A data flow represents the exchange of information between functional components • Data flow information is added in Level 2 diagrams to identify the need for data integration and data sharing • Data flow information can identify dependencies between functional components and illustrate how they work together to deliver value August 17, 2020 79
- 80. Level 2 System of Record (SoR) Integration • The System of Record (SoR) Integration is the authoritative source system for integrations between functional components • In order for the system of record relationships to be maintained over the service lifecycle these integrations and their key data objects must be well defined • A data flow creates a relationship or dependency between two data objects in the functional components that participate in the data flow • The relationship between the two data objects must be maintained • The lifecycles of the two data objects are interlinked so updates to one may have an impact on the other • The integrations ensure the integrity of the system of record fabric and the Service Model August 17, 2020 80
- 81. Level 2 System of Record (SoR) Integration – Sample Data Object State Model Dependency • Events can give rise to Incidents • The states of Event and Incident data objects are therefore both interrelated and interdependent August 17, 2020 81
- 82. Level 2 System of Engagement (SoE) Integration • Integrations exist between functional components to enable interactions with the associated data objects • Called system of engagement integrations • Integrations follow-on from use cases within value streams • Show how data object relationships give rise to or have an impact on system-to-system and human-to-system August 17, 2020 82
- 83. Level 2 System of Engagement (SoE) Integration - Sample August 17, 2020 83
- 84. Level 2 Capability Discipline • Capabilities enable organisation achieve results through a combination of people, process and technologies − Different organisation types and profiles will have different sets of capability requirements with different priorities • Organisations require many capabilities across solution design and delivery, programme and project management and service management • Capabilities are achieved as a set of functional components and data objects • Functional components are individual stand-alone technology units that can perform a discrete function • The IT4IT reference does not define key capabilities or define a means to assess what capabilities are important − It assumes that key capabilities can be derived from existing frameworks August 17, 2020 84
- 85. Level 2 Capability Discipline – Sample August 17, 2020 85
- 86. IT4IT Level 3 Reference Architecture – Vendor- independent Architecture • Level 3 of IT4IT contains a more formal specification of the reference architecture • Details on scenarios, essential attributes and essential services are added • Level 3 extends the Level 2 Class Model August 17, 2020 86
- 87. Level 3 Scenarios • Scenarios describe interactions between actors and functional components of a system • Scenarios represent larger sets of interactions • Scenarios are designed to provide explanations of the IT4IT Reference Architecture in a format that is easy to understand • Scenarios can be customised to meet the requirements of organisations that use IT4IT • Scenarios are specific implementations or use cases of IT4IT to deliver service-centred facilities August 17, 2020 87
- 88. Sample Scenarios Envisaged By IT4IT • Multi-Vendor Selection and Management • Demand and Capacity Management • Change and Configuration Management • Service Request Management, Self Service and Knowledge Management • Business Strategy and Solution Portfolio Management • Cloud Platform and Solution Selection and Management • Business Intelligence, Reporting and Data Visualisation • Asset Management • Financial and Cost Management • Risk Management August 17, 2020 88
- 89. Scenario Descriptions Descriptive Element Details Introduction Overview of the scenario and description of the goal to be achieved Requirements Requirements represent the necessary properties of the system components needed to achieve the objectives defined by the scenario goals Process Flow Defines the scenario process and its sequence of activities and steps Automation Specification using the Reference Architecture Details how the IT4IT Reference Architecture will support and enable the specific process contained in the scenario Essential Services Supporting the Scenario Service integrations between functional components and data objects involved in the scenario Data Objects and Essential Attributes Details on the data objects and their of the objects that that are essential in the operation of the scenario to maintain the integrity of the system of record fabric Any Proposed Changes or Extensions to the Reference Architecture Details on any proposed or required changes or enhancements to the IT4IT reference architecture to enable the operation of the scenario August 17, 2020 89
- 90. Level 3 Essential Attributes • Data exchanged between functional components is represented as data objects • Level 3 defines the necessary data object attributes − Most basic essential attributes are a unique identifier and the data object lifecycle status • Minimum set that is needed to maintain the integrity of the system of record fabric • Example shows the essential attributes that uniquely identify an Event and an Incident August 17, 2020 90
- 91. Level 3 Essential Services • Essential services provide facilities to enable integration between functional components or access a data object • IT4IT intends that essential services are implemented as a web service, micro service or API rather than individual point-to-point integrations • IT4IT currently does not contain a defined list of essential services August 17, 2020 91
- 92. Level 4 • Levels 4 and 5 of IT4IT are intended to be owned and controlled by suppliers of IT management products and services • Level 4 allows providers to design and detail their services, interfaces and exchange models that should be derived from Level 3 • Extensions can include − Data model and data objects − Scenarios − Processes − Integrations August 17, 2020 92
- 93. Level 5 • Level 5 allows for provider-specific representations for how elements of or all of the IT4IT Reference Architecture are implemented • Contains the specifications and/or functionality for IT management products and services • Includes variations and adaptations of IT4IT August 17, 2020 93
- 94. Strategy to Portfolio (S2P) Value Stream August 17, 2020 94 Objective is for IT to contribute to business strategy and planning enabling IT alignment with business plans Traditional IT Planning and Portfolio Planning • Focus is on evaluation, approval and delivery tracking of project proposals • Emphasises minimising costs for IT initiatives or assets • No overall IT portfolio view across IT Architecture, PMO and Service Portfolio functional areas • Inconsistent solution delivery and service management processes • Inconsistent and poor quality data • Poor tracking and connection across conceptual, logical and physical domains of service delivery IT needs accurate and current information on the IT portfolio • Understand the relationships • and dependencies • Enable the co-ordination of all the elements of IT in • Ensure IT function supports business objectives and goals IT4IT S2P Value Stream • Aims to provide overall view of IT portfolio activities through data integrations across all areas of the IT portfolio • Seeks to provide a blueprint for optimising service and investment • Looks to provides greater understanding of the relationships between the many IT functional areas such as IT Architecture, PMO, Application Management, Operations Management and Security Management • Intends to provide an end-to-end IT portfolio view makes visible the key data objects frequently ignored during IT portfolio planning activities • Defines a framework to define key data objects and their relationships Limitations Requires IT4IT Aims
- 95. Strategy to Portfolio (S2P) Value Stream Functional Components And Data Objects Overview August 17, 2020 95
- 96. Strategy to Portfolio (S2P) Business Value Proposition Provide a complete view of IT portfolio across the Enterprise Architecture, PMO and Service Management functions Allow IT portfolio decisions to be made based on business priorities Enable prioritised IT investments based on IT portfolio analysis factors such as impacts on architecture, service roadmap, business priorities Balance IT investments across strategic and operational areas Provide accurate view of business and IT demand Ensure IT portfolio data consistency Support service lifecycle tracking through conceptual, logical, and physical domains Communicate with business stakeholders through IT portfolio roadmaps August 17, 2020 96 • Provide a framework for connecting those functions that support IT Portfolio Management, ensuring data consistency and proper data hand-offs in order to optimise the organisation’s IT Portfolio Management
- 97. Strategy to Portfolio (S2P) Key Performance Indicators And Critical Success Factors August 17, 2020 97 Success Factor Performance Indicators Business and IT Alignment • Ratio of new and maintenance activities, effort and cost Accurate View of Overall Demands from Business • Demand requests, types and delivery per service as a percentage of overall IT budget that can be traced to formalised demand and service requests from business • Structured and operational Demand Management process with continuous improvement efforts to minimise the number of demand queues that staff must respond to Service Portfolio Rationalisation • A formal Service Portfolio functional component process exists under a Service Portfolio Management process owner • Classifications and agreed definitions for understanding functional and technical redundancy and business value of the IT service are implemented and operational • Processes for consistently evaluating and tagging portfolio entries are implemented and operational • Service portfolio is subject to ongoing rationalisationusing the taxonomies, implemented as continuous improvement • Service and IT Portfolio Management functions and processes are rationalised with clear scoping and relationship established Service Portfolio Financial Analysis • Financial reports are produced regularly to show the ongoing investment and spend in each service/application • Financial reports are compared with business outcomes and the financial objectives that have been achieved Service Portfolio Reporting and Analysis • A service portfolio exists and is used to decide which services to offer Service Investment Tracking • The investment in each service in the service portfolio is known and quantified • Investment in each service is reported, from the initial investment and the monthly, quarterly, and annual ongoing budget spend and cost of operation Improved Customer Satisfaction • Number/percentage of satisfied customers per service/application Stewardship of IT Investment • Capital expenditure and operational expenditure • Software license percentage actually in use • Planned versus actual service costs • Average cost of IT delivery (per service/application) per customer. Enterprise Security Alignment • Frequency of security assessments against latest standards and guidelines • Deficiencies against security standards and policies
- 98. Strategy to Portfolio (S2P) Functional Components August 17, 2020 98 Strategy to Portfolio (S2P) Enterprise Architecture Policy Proposal Portfolio Demand Service Portfolio IT Investment Portfolio – Auxiliary Requirement to Deploy (R2D) Project Requirement Service Design Source Control Build Build Package Release Composition Test Defect Request to Fulfil (R2F) Engagement Experience Portal – Secondary Offer Consumption Offer Management Catalog Composition Request Rationalisation Fulfilment Execution Usage Chargeback/Showback Knowledge and Collaboration Supporting Function Detect to Correct (D2C) Service Monitoring Event Incident Problem Change Control Configuration Management Diagnostics and Remediation Service Level
- 99. Enterprise Architecture Functional Component August 17, 2020 99 Purpose • Create and manage long-term IT investment frameworkand delivery plan that are criticalto business strategic objectives Functional Elements • Create and manage long-term IT investment frameworkand delivery plan • Identify strategic IT architecturalcomponents based on current business vision, strategy, goals, and requirements • Develop target state business, information, application,technology, and security blueprints based on strategies, principles, and policies Key Data Objects • Enterprise Architecture - contains references to the target state architecture landscape representing planned and deployed IT services Key Attributes • ID - Unique service identifier • Component - Architectural buildingblocks required to enable a service • Diagram - As-is business, data, application, and technology domain architecture description from the viewpoint of IT service owners Key Data Object Relationships • Enterprise Architectureto ConceptualService – used to track which service components and service diagrams are allocated to which service(s)
- 100. Policy Functional Component August 17, 2020 100 Purpose • Manage the creation, review, approval and audit of all IT policies Functional Elements • Align and map IT policies to Enterprise Architecture • Manage policies relating to IT governance • Manage IT security and regulatory policiesby incorporatingexternal and internal security and regulatory compliances • Enable review and approval of IT policies based on roles and responsibilities • Manage the distribution and acceptance of policies used on predefined templates and schedules for designated IT stakeholders • Provide visibilityinto IT Policyattributes such as types, status, non-compliance, audit history, and issues • Define pricing/costingpolicies and capture informationrelated to Service Contracts • Maintain policy revision history and review period or obsolescence rules • Log and track IT policy exceptions and track policies for exception identification, evaluation, and status report leading to corrective action Data Architecture Elements • Associate one or more policies to one or more Conceptual Services Key Data Objects • Policy - Central repository for storing and organising all types of IT policies based on various templates and classificationfactors Key Attributes • ID - Unique policy identifier • Description - Description/detailsof the policy • Applicable Geography - Which geographies the policy applies to Key Data Object Relationships • Policy to Conceptual Service - Multiple policies might be applicablefor a single • service or a single policy may be applicablefor multipleservices • Policy to Requirement - Requirements may be sourced from policies or may • reference policies in order to remain in compliancewith previously agreed policies
- 101. Proposal Functional Component August 17, 2020 101 Purpose • Manage the portfolio of IT proposals that are proposed, approved, active, deferred or rejected Functional Elements • Create a structured Scope Agreement that includes proposals from rationalisedPortfolioBacklog Items through a structured analysis approach • Send proposed IT investments to the IT Investment Portfolio functionalcomponent for scoping and investment decisions • Update Scope Agreement(s) to compare approved baseline and actual resulting • benefits derived from completing the IT Initiatives • Review, evaluate and take action on Scope Agreement change requests from the R2D Value Stream • Consider the R2D Value Stream project portfolio as the authoritativesource for the list of IT deliverablesor services that will be rendered during a delivery lifecycle • Create project portfolio views for specific business functions • Manage the project portfolio entries through the Project Management framework being used • Ensure that the project portfolioreports back to the investment portfolio in order to accurately track progress and outcomes for a given Scope Agreement • Implementsecurity controls necessary for protecting the various classificationsof data Key Data Objects • Scope Agreement - Proposals are created from rationalisedPortfolioBacklog Items • Scope Agreements reflect budget, cost/benefit projections, scope, status, • and other key attributes of proposed work • Views can be created for specific business functions • Used for building the IT investment plan of record for the organisation or a business function Key Attributes • ID - Unique identifier of the Scope Agreement • Description -Details of the Scope Agreement • Business Entity - Business or geographic unit • Proposed Budget - Requested • Approved Budget - Approved budget • Status - Status such as proposed, approved, rejected Key Data Object Relationships • Scope Agreement to Portfolio Backlog Item - One Scope Agreement can be associated to one or more demand data objects • Scope Agreement to IT Budget Item - Helps track budget allocated to which Scope Agreement. • Scope Agreement to IT Initiative - Helps track IT Initiative(s)to Scope Agreement
- 102. Portfolio Demand Functional Component August 17, 2020 102 Purpose • Log, maintain, and evaluate all demands (new service, enhancements, defects) coming into IT through a single mechanism • The single mechanism co-ordinates demands across all of project ideation, service request management, incident management, continuous improvementand other demand channels • Correlate incomingdemand to similarexisting demand or create new demand Functional Elements • Capture PortfolioBacklog Items from business • Capture PortfolioBacklog Items from Problem Management activities • Capture PortfolioBacklog Items from the Service Portfolio functionalcomponent Activities • Capture PortfolioBacklog Items for defect fix requests which exceed the operations budget or require urgent attention due to business impact on existing service • Support backlog item data object backlog ranking, trending, and analysis based on requested services, timeline, business unit origination, etc. • Categorise and group the demands and push demands to the Proposal functional component • Receive scoping and investment decisions from the Proposal functional component • Associate one or more Requirements(user stories, use-cases, business rules, etc.) to a • PortfolioBacklog Item Key Data Objects • Portfolio Backlog Item - Represent the repository of all incoming demands includingbut not limitedto new requests, enhancement requests and defect fix requests Key Attributes • ID - Unique identifier • Description - Description/detailsof the Portfolio Backlog Item (demand request) • Source - Where did the demand originatefrom (e.g., person/department) • Scope Agreement ID - Unique identifier of the related Scope Agreement • Estimated Budget - May store budget (as estimated during creation of the Scope Agreement) of the Portfolio Backlog Item • Expected Completion Date - Expected completion date (as estimated during creation of the Scope Agreement) of the PortfolioBacklog Item. • IT Service ID - The conceptual service ID. Is demand related to a live service (e.g., enhancement requests) • Fulfilment Status - Status information • Decision Maker - Informationon who took the decisions related to the demand Key Data Object Relationships • Portfolio Backlog Item to Conceptual Service - One Conceptual Service may be related to one or more PortfolioBacklog Items • Portfolio Backlog Item to Requirement - A PortfolioBacklog Item is mapped to one or more Requirements which will need to be delivered to successfully fulfilthe demand • Portfolio Backlog Item to Scope Agreement - One or more PortfolioBacklog Items may be included in a Scope Agreement
- 103. Service Portfolio Functional Component August 17, 2020 103 Purpose • Manage the portfolio of services in plan, transition, production and retirement • Be the authoritative source for the list of services that IT delivers, has deliveredin the past, or brokers to itself and • Business • Any IT service within the Service Portfoliofunctional component often corresponds to one or more entries in the Offer Catalog Functional Elements • Assess the effectiveness and efficiencyof current services delivered to business • Manage all inventory informationabout services or applications; includingbusiness benefits, risk, quality, fit to purpose, etc • Compare similarservices or applications to identify rationalisationopportunities • Evaluate the portfolio with regard to value/cost performanceand risk/criticalityto maximise portfolio value, align and prioritiseresource allocations, and balance supply and demand • Review proposed portfoliochanges; decide whether to keep, retire, or modernise services or applications • Create, review, and update service roadmaps • Determine and track the TCO of a service and associated return on investment • Determine and track operations spend • Create and maintain service blueprints and endpoints Key Data Objects • Conceptual Service - Represents the business perspective of the service and is the service interaction or the business capability of the service • Conceptual Service Blueprint - contains the various deliveryoptions for a given Conceptual Service Key Attributes • Conceptual Service • ID - Unique identifier of the Conceptual Service • Details - Details of the Conceptual Service • Owner - Owner of the Conceptual Service • Status - Status of the Conceptual Service; e.g., planned, retired, etc. • Business Unit/Portfolio - The business unit or portfolio to which the service belongs • Budgeted Spend - Approved budget for service development and maintenance • TCO: Total cost of ownership of a Conceptual Service (includes development, run, enhancement and overhead charges) • Recovery - Return on investment against the Conceptual Service • Conceptual Service Blueprint • ID - Unique identifier of the Conceptual Service Blueprint • Details - Details of the Conceptual Service Blueprint • Conceptual Service ID - Unique identifier of the Conceptual Service to which the Blueprint is associated Key Data Object Relationships • Conceptual Service • Conceptual Service to Logical Service - Traceabilityis maintainedbetween one Conceptual Service and one or more Logical Services • Enterprise Architectureto ConceptualService - Traceabilityis maintained between one or more Conceptual Services and the Enterprise Architecture drawings, diagrams and other documents that describe those services • Conceptual Service to Portfolio Backlog Item - One Conceptual Service may be related to one or more PortfolioBacklog Items. • Conceptual Service to IT Budget Item - Budget for one Conceptual Service may be spread across multiplebudget items and one budget item should hold budget for a single Conceptual Service • Conceptual Service to Policy - Multiple Policiesmight be applicablefor a single service or a single Policy may be applicablefor multipleservices • Conceptual Service Blueprint • Conceptual Service to Conceptual Service Blueprint - One Conceptual Service may have multiple Conceptual Service Blueprints • IT Cost Model to ConceptualService Blueprint - One IT cost model (rule engine) can be applicable for multipleConceptual Service Blueprints • Conceptual Service Blueprint to Logical Service Blueprint - One Conceptual Service Blueprint could have one or more Logical Service Blueprints
- 104. IT Investment Portfolio – Auxiliary Functional Component August 17, 2020 104 Purpose • Manage the portfolio of all authorised IT investments Functional Elements • Manage the entire IT investment lifecycle • Be the authoritative source for all IT investments requested over a given time period • Receive proposed IT investments for developmentfrom the Proposal functional component • Receive proposed IT investments for run and maintain and non-service investments from investment owners • Assess proposal feasibilityfor cost, value, etc. and obtain required approval from Finance • Communicate the status of the final scoping and investment decisions back to the respective stakeholders. Key Data Objects • IT Budget Item – Contains an authoritativelist of approved IT investments pertaining to a service Key Attributes • Financial Period - Financial period for which the IT Budget Item is recorded. • Investment ID - Unique identifier of the service or investment (e.g., overhead) for which the IT Budget Item is recorded • Investment Type - Nature of investment (e.g., run, development, overhead) • Approved Budget - Approved budget • Spend - Actual spend Key Data Object Relationships • IT Budget Item to Conceptual Service - One IT Budget Item shall hold budget for a single Conceptual Service and budget for one Conceptual Service may be spread across multiple IT Budget Items • IT Budget Item to Scope Agreement - Helps track how much IT budget is allocated to which Scope Agreement(s)
- 105. Requirement to Deploy (R2D) Value Stream Overview • Aims to ensure predictable, cost-effective, high quality results of service delivery to business consumers while seeking to achieve high levels of component re-use, flexibility, speed and collaboration across the IT function to support traditional and new approaches for service creation and service sourcing August 17, 2020 105
- 106. Requirement to Deploy (R2D) Value Stream Overview August 17, 2020 106 Make service delivery predictable and efficient across dispersed teams, multiple suppliers and different solution delivery approaches and technologies • Many different parties are involved in solutions sourcing • Each party works with their own processes, technologies and approaches • New technologies and approaches such as cloud sourcing, agile development, continuous delivery, data growth and demands have created the need for IT to be able to manage development and delivery of solutions in a hybrid or multi- sourced environment • The gap between business expectations of IT solutions and IT solution provision capability and capacity is getting wider • IT operations may not be able to accommodate new technologies and environments fast enough to meet the requirements of solution consumers • Development organisations create solutions in isolation that are made live without adequate • There are still too many incidents immediately after a solution or service is released into production Why • Be able to provide an overview of planned activities • Put management controls in place to lessen the impact of high staff turnover and capture the knowledge that would otherwise be lost and cause schedules to be negatively impacted • Speak a common language with all parties involved and provide a common methodology to achieve the high- quality results • Build a culture of collaboration between IT operations and IT development to ensure service release success • Establish control over the quality of a service regardless of the number of suppliers involved in development and/or delivery • Ensure that each service release is high quality, fit-for- purpose and meets customer expectations How IT Must Respond
- 107. Requirement to Deploy (R2D) Value Stream Functional Components And Data Objects Overview August 17, 2020 107
- 108. Requirement to Deploy (R2D) Goals • Understand the evolving relationship between planning and delivery. planning of complex solutions requires information only available through iterative attempts to fulfil requirements so both planning and building must occur simultaneously • IT operations and development must improve collaboration across business and technical domains and suppliers • Drive predictable outcomes without driving out innovation - innovation and process efficiency are two elements of competitive advantage that IT departments bring to the business that frequently co-exist badly - emphasis on on-time project delivery tends to suppress innovation - IT must continuously improve its ability to execute in such a way that on-time innovation is standard August 17, 2020 108
- 109. Requirement to Deploy (R2D) Business Value Proposition August 17, 2020 109 Optimise the pipeline of projects and smaller demand requests for faster service realisation Ensure predictable outcomes the solution or service delivered performs as requested, leading to higher rates of solution consumer acceptance and better alignment with actual business needs Establish controls to manage the quality, utility, security and cost of services, independent of delivery method, technology, source or provider Provide increase management information for traceability and benchmarking of internal and external solution and service developers and suppliers Ensure that all services are designed in accordance with standards and policies (Compliance, Enterprise Architecture, Risk Management, IT Financial Management) Provide improved inputs to IT Financial Management on actual solution and service delivery and operation cost Demonstrate the link between solution and services and business value by creating and maintaining the service blueprint Accelerate the sourcing and delivery of solutions and services • Provide a framework of functional components and data objects so IT functions can better control the quality, utility, schedule and cost of services regardless of the specifics of the technology and delivery model
- 110. Requirement to Deploy (R2D) Key Performance Indicators And Critical Success Factors – 1 August 17, 2020 110 Success Factor Performance Indicators Improved Quality • Number of defects not found • % of actual versus planned executed tests • % of critical defects found early in unit testing versus UAT Improved Project and Feature Execution • % of projects, solutions and services delivered on time • % of successful projects, solutions and services • Deviation of planned to actual effort • Number of identified issues • Number of opened risks • Amount of backlog/work-in-process Improved Management of IT Investment • % of actual versus planned project, solution and service cost • % of change in project, solution and service cost • % of budget at risk Increased Use of Automation • % of automated tests Solution Delivery Excellence • % of requirements tested and completed • % of requirements traced to tests • % of reviewed requirements • % of successful builds • % of changes resulting in Incidents • Ratio of detected to closed defects at release Improve Early Life Success of Releases • % of Incidents during warranty period • % of successful/unsuccessful deployments for the project • % of emergency changes • Pass rates on UAT/validated requirements
- 111. Requirement to Deploy (R2D) Key Performance Indicators And Critical Success Factors – 2 August 17, 2020 111 Success Factor Performance Indicators Operations and Development Collaboration • Trend on early life support/UAT success metrics • % rework Improve Financial Visibility • Planned cost versus actual cost Maintain a Linkage between Business Services and IT Initiatives • Aggregate (roll up) service development costs by business service High Quality Service Design Specifications at the Outset • % reduction in the rework required for new or changed service solutions in subsequent lifecycle stages Integration Test Success • Trend on the number of installation errors in all the packages in the integration environment • Number of applications or services that require exceptions outside of the existing infrastructure portfolio Design-Review to Ensure Application Design Complies with all Policies, including Security • Number of application designs that pass a security policy review Early Testing of Applications for Security Vulnerabilities • % of severity 1 security defects fixed before application is released
- 112. Requirement to Deploy (R2D) Functional Components August 17, 2020 112 Strategy to Portfolio (S2P) Enterprise Architecture Policy Proposal Portfolio Demand Service Portfolio IT Investment Portfolio – Auxiliary Requirement to Deploy (R2D) Project Requirement Service Design Source Control Build Build Package Release Composition Test Defect Request to Fulfil (R2F) Engagement Experience Portal – Secondary Offer Consumption Offer Management Catalog Composition Request Rationalisation Fulfilment Execution Usage Chargeback/Showback Knowledge and Collaboration Supporting Function Detect to Correct (D2C) Service Monitoring Event Incident Problem Change Control Configuration Management Diagnostics and Remediation Service Level
- 113. Project Functional Component August 17, 2020 113 Purpose • Manage the creation and provide ongoing delivery supervision of IT Initiatives that create new or enhance existing services based on the Scope Agreement, track and report on execution status, manage communication between internal and external stakeholder, manage deliveryfinances, manage scope and handle changes, supervise resource acquisition Functional Elements • Be the system of record (authoritative source) for all IT Initiatives • Manage interactions with other functionalcomponents • Manage the lifecycleof the IT Initiativeand govern, coordinate, influence, and direct IT Initiativeexecution • Manage the acquisition of resources • Manage the status of the IT Initiative and maintain traceability between IT Initiativesand associated applications and service(s)being developed • Coordinate resources, finances, tasks, and milestones for IT Initiatives, and provide ongoing execution oversight of IT Initiatives when creating new services or enhancements to existing services • Create IT Initiativesbased on the specifications outlined in the Scope Agreement, includingcost, time, scope, and quality • Aggregate, track, and report status, resources consumed against project plan, or project burn down, and communicate these to stakeholders • Ensure financialgoals and boundary conditions are adhered to and track spending • Manage change control Key Data Objects • IT Initiative - Contains informationon the scope of the work to be performedand created from and associated with the Scope Agreement. Data Architecture • Associate a Scope Agreement to one or more IT Initiatives • Associate an IT Initiative to a service • Associate an IT Initiative to one or more RFCs • Associate an IT Initiative with IT Budget Items Key Attributes • ID - Unique identifierof the effort/initiative • Name - Full name of the effort/initiative • Status - Status of the effort/initiative • Service Release - Identifier of one or more Service Releases • RFC ID - Identifierof one or more RFCs • Budget - Budget for the IT Initiative • Actual Spend - Actual spend on the IT Initiative • Start Date - IT Initiative start date • End Date - IT Initiativecompletiondate • Scope Agreement ID - Unique identifier of the related Scope Agreement Key Data Object Relationships • Scope Agreement to IT Initiative - Linkage between the proposal that authorised one or more IT Initiatives • IT Initiative to Service Release - An IT Initiative will manage the creation of one or more Service Releases required to deliver the IT Initiative • IT Initiative to Request for Change (RFC) - An Initiativewill be related to one or many RFC records in order to manage all changes resulting from a single work effort (initiative)
- 114. Requirement Functional Component August 17, 2020 114 Purpose • Collect, refine, track progress and manage requirements through the lifecycleof a service, maintain traceabilityof each requirement to the original source and derive deliverybacklogs which will feed queues for enhancing IT services Functional Elements • Be the system of record (authoritative source) for all requirements • Collect, refine, scope, and track progress of requirements • Manage the lifecycleof the requirement • Manage the state of a requirement • Manage requirementsthrough the lifecycleof a deliveryand maintain traceabilityof each requirement to its original source • Derive product or program backlogs which will serve as work queues • Trace requirementto one or more test cases Key Data Objects • Requirement – Contains details the needs or conditions to meet for a new or altered service Data Architecture • Allow recursive relationshipsbetween requirements • Allow hierarchicalrelationshipsbetween Requirements • Associate a requirement to a service • Associate one or more Requirementsto a Service Release • Associate one or more Requirementsto a PortfolioBacklog Item Key Attributes • ID - Unique identifier of a given Requirement • Type - Identifies the category of a Requirement (i.e., epic, theme, feature, user story, non-functional, functional, etc.) • Summary - Represents the short description/title/summaryof a given Requirement • Logical Service ID - Unique identifier of the related Logical Service • Requirement Source - A reference to the Requirementsource such as policy, backlog item, etc. • Owner -The person or team that is assigned to this Requirement • Service Release ID - Unique identifier of the related Service Release Key Data Object Relationships • Logical Service to Requirement - One or more Requirements will be used to define the required behaviour from the Logical Service • Service Release to Requirement - Describes a version of the service which fulfils one or more Requirements • Requirement to Test Case - A Requirementis traced to one or more Test Cases to ensure stated needs or conditions have been successfully delivered or met • Portfolio Backlog Item to Requirement - A PortfolioBacklog Item is mapped to one or more Requirements which will need to be delivered to successfully fulfilthe demand • Policy to Requirement - Requirements may be sourced from policies or may reference policies in order to remain in complianceto previously agreed policies for an organisation • Requirement to Source - Source will fulfil one or many Requirements, and for a given Requirement, there could be multiple Sources created/modified
- 115. Service Design Functional Component - 1 August 17, 2020 115 Purpose • Identify the new or existing services required to meet the needs of the Scope Agreement and the associated IT Initiative • Create a Logical Service that describes the service structure and behaviour taking into account the service system and the service offer and ensure that the architecture and Logical Service Blueprint are compliant with all standards and policies, includingsecurity standards and policies • Create the service design specification • Identify the service delivery model and potential service suppliers • Implementdata collection and measurementframework so IT can capture actual data about how IT services are performingrather than relying only on anecdotal input from the service consumers • Ensure that the service is architected to meet the applicableKPIs and SLAs Functional Elements • be the system of record (authoritative source) for all Logical Services • identify the new or existing services required to meet the needs of the Scope Agreement and IT Initiative • Leverage the Conceptual Service and Portfolio Backlog Items from the S2P Value Stream along with Requirementsto produce a Logical Service that describes the service structure and behaviour • Create various architecturalartefacts (data flow diagrams, technical schematics, etc.) that comply with the IT Initiativespecificationsand boundaries • Create service design specification document (Logical Service Blueprint) • identify the service delivery model (in-source, outsource, etc.) and service suppliers to meet the Requirements within the chosen deliverymodel • Enable interaction with IT operations to develop support plan/requirements for an IT Service • Ensure that the architecture and Logical Service Blueprint are compliant with all standards and policies, including security standards and policies • Ensure that the architecture and Logical Service Blueprint meet all Requirements, includingsecurity requirements, to ensure the confidentiality, integrity, and availabilityof the service • Put data collectionand measurement framework in place so that IT can capture actual data about how IT services are performing, rather than relying only on anecdotal input from service consumers • Ensure traceabilityis done through the Requirementfunctional component • Receive the development spend from the Project functionalcomponent and pass it to the Service Portfolio functional component Key Data Objects • Logical Service - bridge between the service interaction and service system containing the group of logical components needed to provide the expected outcome or service interaction • Logical Service Blueprint - design of the logical service that details the components and how those components relate to one another
- 116. Service Design Functional Component - 2 August 17, 2020 116 Key Attributes • Logical Service • ID - Unique identifier • Name - Meaningfulname • Description - Short description of the purpose • Conceptual Service ID - Unique identifier of the related Conceptual Service • Budgeted Spend - Approved budget for development of a service • Actual Spend - Actual spend for the development of a service • Logical Service Blueprint • ID - Unique identifier • Name - Meaningfulname of the • Description - Short description of the purpose of the Logical Service Blueprint • Version - Version • Logical Service ID - Unique identifier of the related Logical Service • ArchitectureDesign - An architecturalrepresentation (diagram)of the service system components Key Data Object Relationships • Conceptual Service to Logical Service - One or more Logical Services represents the logical components which are necessary to provide the expected outcome of the Conceptual Service • Logical Service to Requirement - One or more Requirements will be used to define the required behaviour from the Logical Service • Logical Service to Service Release - A Logical Service can lead to the creation of one or more Service Releases in order to deliver the required service outcomes • Logical Service to Logical Service Blueprint - A Logical Service structure and behaviour can be detailed by one or more Logical Service Blueprints
- 117. Source Control Functional Component August 17, 2020 117 Purpose • Develop source code or infrastructure based on the Logical Service Blueprint, Service Design Package, and IT Initiativepriorities • Ensure that the source code meets the design specifications, organisation policies, standards and non-functional requirements so that the service can be operated successfully and meets solution consumer expectations • Manage the development backlog of requirements and defects Functional Elements • Be the system of record (authoritative source) for all source • Manage the source lifecycle • develop source code or infrastructurebased on the Logical Service Blueprint, • Service Design Package, and IT Initiative priorities • Ensure that the source code meets the design specifications, organisational policies, standards, and non-functional requirementsso that the service can be operated successfully and meets solution consumer expectations • Manage the development backlog of requirements and defects • Create (automated) test scripts includingunit testing and scripts for static applicationsecurity testing that follow a formal software security assurance methodology • Run security tests on core code to identify existing security issues at the start of the development cycle so that assessment of scope/requirements set/schedule for existing services being changed can be negotiated early • Manage source code images and store them in a source data object repository Key Data Objects • Source - Created or purchased solution to meet the requirementsfor a particularService Release Data Architecture • Allow recursive relationshipsbetween source • Allow hierarchicalrelationshipsbetween source • Associate source to a service • Associate one or many requirements to one or many sources • Associate one or many builds to the related source Key Attributes • ID - Unique identifier • Version - Version of the Source • Requirement ID - Identifier of the related requirement(s) Key Data Object Relationships • Source to Requirement - Source will fulfil one or many requirements, and for a given requirement, there could be multiplesources created/modified • Source to Build - Source can be built multipletimes to create several Build versions
- 118. Build Functional Component August 17, 2020 118 Purpose • Receive the source data object from the Source Control functional component and manage the creation, implementation, automation, and security and storage of all builds Functional Elements • Receive the Source data object from the Source Control functional component and manage the creation, implementation, automation, and security and storage of all Builds • Create the Build from the Source data object for a particular service component • Automate the Build process to support the Build schedule and build frequency requirements in order to support daily Build and smoke test plans or continuous integration plans • Run dynamic applicationsecurity testing no later than when the final Build data object is received and before the RFCs are created for moving the new or changed service into production • Manage Builds and versioning in a DefinitiveMedia Library (DML) • Develop automated Build storage procedures and automated compilationtechniques and tools • Monitor and report on the results of each integrationBuild • Initiate or automate the delivery of Builds to the Build Package functional component for validationby the acceptance testing team as candidate release builds Key Data Objects • Build - Created from Source and versioned Data Architecture • Be the system of record (authoritative source) for all Builds • Manage the version of each individualBuild • Associate a Build to a service • Associate Source to one or many Builds if a Source Control functional component exists • Associate one or many Builds to one or many Test Cases which are executed as part of the Build creation if a Test functional component exists • Associate one or many Builds to a Build Package if a Build Package functional component exists Key Attributes • ID - Unique identifier • Version -Version of the build • Source ID - Identifier of the related source • Test Case ID - Identifier of the related test case(s) • Build Package ID - Identifier of the related build package after it has been created Key Data Object Relationships • Source to Build -Source can be built multipletimes to create several Build versions • Build to Test Case - One or many Builds can be related to one or many Test Cases used as part of the Build creation • Build Package to Build - A Build Package is comprised of one or many Builds.
- 119. Build Package Functional Component August 17, 2020 119 Purpose • Create a deployable package made up of one or many Builds • Manage the Build Packages and relationships to the Service Release Blueprints Functional Elements • Create a deployable package made up of one or many Builds. • Manage the Build Packages and relationships to the Service Release Blueprints • Be the system of record (authoritative source) for all Build Packages Key Data Objects • Build Package - A compilation of one or many Builds in a deployable package Data Architecture • Associate a Build Package to a service • Associate one or more Builds to a Build Package if a Build functional component exists • Associate one or more Service Release Blueprints to one or more Build Packages if a Release Composition functional component exists Key Attributes • ID - Unique identifier • Name - Meaningful name of the Build Package Key Data Object Relationships • Build Package to Build - Build Package is comprised of one or more Builds • Build Package to Service Release Blueprint - Multiple build packages, which represent the deployable content of the service components, can be deployed using the instructions contained in the Service Release Blueprints
- 120. Release Composition Functional Component - 1 August 17, 2020 120 Purpose • Manage the Release Package, Service Release, Service Release Blueprints and overall Service Release for developing and deliveringnew or changed services to the R2F Value Stream Fulfilment Execution functional component to facilitatea smooth transition to IT operations Functional Elements • be the system of record (authoritative source) for all Service Releases • be the system of record for all Service Release Blueprints • Manage the Release Package, Service Release, Service Release Blueprints, and overall Service Release for developing and deliveringnew or changed services to the R2F Value Stream Fulfilment Execution functional component to facilitatea smooth transition to IT operations • Create the Service Release, Service Release Blueprint, and Release Packages that will be utilised by the Test functional component and later the Fulfilment Execution functionalcomponent (R2F Value Stream) to create a specific deployment for a specific IT service instance • Begin the creation of monitors, batch processing, backup/restore, etc. for the service, to ensure supportabilityas part of IT operations enablement Key Data Objects • Service Release - Represents a planned release of a version of the service system • Service Release Blueprint - Provides the planned design/configurationof the components of the service system Data Architecture • Associate a Service Release to a service • Allow a recursive relationshipbetween Service Releases • Associate a Service Release to one or more Service Release Blueprint • Associate a Service Release Blueprint to a service • Associate a Service Release Blueprint to a Release Package • Associate one IT Initiative to one or more Service Releases which are defined to deliver this IT Initiative if a Project functional component exists • Associate one Logical Service to one or more Service Releases which are designed to deliver this Logical Service if a Service Design functional component exists • Associate one Service Release with one or more Requirementswhich are fulfiled in this release if a Requirement functional component exists • Associate one Service Release with one or more Test Cases if a Test functional component exists • Associate one or more Service Release Blueprints to one or more Build Packages if a Build Package functional component exists • Receive one or more Build Packages that should be included in the Service Release Blueprint if a Build Package functional component exists • Associate one or more Service Release Blueprints to one or more Service Contracts • Associate a Service Release Blueprint to one or more Desired Services
- 121. Release Composition Functional Component - 2 August 17, 2020 121 Key Attributes • Service Release • ID - Unique identifier • Name - Meaningfulname of the Service Release • Status - Lifecyclestatus of the Service Release • Version - Version of the Service Release • Logical Service ID - Unique identifier of the related Logical Service • IT Initiative ID - Unique identifier of the related IT Initiative • Service Release Blueprint • ID - Unique identifier • Name - Meaningfulname of the Service Release • Description - Description of the Service Release Blueprint • Service Release ID - Unique identifier of the related Service Release • Build Package ID - Unique identifier of the related Build Package • Defect ID - Identifier of the related Defect(s) • Deployment Model - A representation of the deployable service components and their various configurationoptions Key Data Object Relationships • Service Release • Logical Service to Service Release - A Logical Service can lead to the creation of one or more Service Releases in order to deliver the required service outcomes • IT Initiative to Service Release - An IT Initiative will manage the creation of one or more Service Releases defined to deliver the content of the IT Initiative • Service Release to Service Release Blueprint - A Service Release can be released to differentenvironments based on different Service Release Blueprints • Service Release to Requirement - The Service Release describes a version of the service which fulfilsone or more Requirements • Service Release to Test Case - A Service Release can be validated by one or many Test Cases • Service Release Blueprint • Service Release to Service Release Blueprint - A Service Release can be released to differentenvironments based on different Service Release Blueprints • Service Release Blueprint to Build Package - Multiple Build Packages, which represent the deployable content of the service components, can be deployed using the instructions contained in the Service Release Blueprints • Service Release Blueprint to Desired Service - One Service Release Blueprint can be translated to one or more Desired Service(s) • Service Release Blueprint to Fulfilment Request - One Service Release Blueprint is used for service instantiation by one or many Fulfilment Requests • Service Release Blueprint to Service Contract - One or more Service Release Blueprints contain the template of one or more Service Contracts • Service Catalog Entry to Service Release Blueprint - Each Service Catalog Entry is created based on definitionsof a Service Release Blueprint • Service Release Blueprint to Defect - One or more Service Release Blueprints can contain one or more Defects in the form of Problems/Known Errors
- 122. Test Functional Component August 17, 2020 122 Purpose • Plan and execute tests that are traced to requirements that ensure the IT service will support the agreed requirementsat the agreed service levels Functional Elements • Prepare test environments • Manage test data • Be the system of record (authoritative source) for all Test Cases • Ensure traceabilitybetween tests and Requirements • Manage the lifecycleof Test Cases • Plan and execute tests that ensure the IT service will support the solution consumers’ requirementsat the agreed service levels • Create Defect data objects that are consumed by the Defect functional component • Plan and design tests, including automated test scripts for both code images and monitors • Execute tests for functionality,usability, security, performance • Create Defects found during testing which are consumed by the Defect functional component • Provide test execution reports • Maximise test automation re-use Key Data Objects • Test Case - Used to validate that the Service Release is fit for purpose Data Architecture • Allow recursive relationshipsbetween Test Cases • Associate a Test Case to a service • Associate one or more Test Cases to one or more Builds that uses the Test Case • Associate a Requirement to one or more Test Cases that validates the Requirement • Associate a Test Case to one or more Defects that result from the test • Provide Defect informationto the Defect functional component Key Attributes • ID - Unique identifier • Name - Meaningful name for the Test Case • Description - Summary or short description of the Test Case • Status - Lifecyclestatus of the Test Case • Result -Last known Test Case execution outcome • Service Release ID - Unique identifier of the related Service Release • Requirement ID - Identifier of the related Requirement(s) Key Data Object Relationships • Requirement to Test Case - A Requirementis associated to one or more Test Cases that validates this Requirement • Service Release to Test Case - A Service Release is associated to one or more Test Cases which are executed as part of this Service Release • Test Case to Build - One or more Test Cases can be associated with one or more Builds that uses this Test Case as part of the Build creation • Test Case to Defect - One Test Case can be associated to one or more Defects that are reported as a result of this test
- 123. Defect Functional Component August 17, 2020 123 Purpose • Keep track of all Defects; includingtheir origin, status, importance, and relation to Requirements and Known Errors Functional Elements • Be the system of record (authoritative source) for all Defects • Manage the lifecycleof Defects • Analyse Defects and find resolution • Keep track of all Defects includingtheir origin, status, importance, and relation to Requirements and Known Errors • Report Defect status and provide Defect reports convert Defects not resolved by service development to Known Errors for Problem Management (D2C Value Stream) to document or develop work-around and report in knowledge management articles • Shall receive Defect informationfrom the Test functionalcomponent if a Test functional component exists • Receive Defect informationfrom a Known Error if a Problem functionalcomponent exists Key Data Objects • Defect - An issue with the Service Release Blueprint which should be remediated to fulfil the associated Requirements Data Architecture • Associate a Defect to a service • Associate Defects with Requirements • Associate one or more Service Release Blueprints to one or more Defects • Associate a Test Case to one or more Defects • Associate a Known Error to a Defect Key Attributes • ID - Unique identifier • Title - Short description of the main issue discovered • Description - Description of the Defect • Status - Status of the Defect • Test Case ID - Identifier of the related Test Case Key Data Object Relationships • Test Case to Defect - One Test Case can be associated to one or more Defects that results from the test • Defect to Service Release Blueprint - One or more Service Release Blueprints are associated to one or more Defects which are included in the Release Package as Problems/KnownErrors • Known Error to Defect - A Known Error may be the source for submitting a new Defect • Incident to Defect - A current practice that replaces the Known Error path when that one does not exist. An Incident may be the source for submitting a new Defect
- 124. Request to Fulfil (R2F) Value Stream Overview August 17, 2020 124 Framework for connecting the various consumers (business users, IT practitioners, or end customers) with goods and services that they need to drive productivity and innovation using a consumption-driven engagement model that goes beyond the traditional IT service request management • A service consumption experience that exposes technology resources and/or IT capabilities rather than valued services • Multiple catalogs required for consumers to navigate in order to find and request available services • Too many customer service requests requiring creation of fulfilment incidents, projects, and/or human intervention resulting in delays and an unfavourable experience overall • Lack of service subscription, usage, and chargeback traceability Limitations of Existing Approaches • It fosters service consumption and fulfilment, service costing knowledge sharing, self-service support, and collaboration between communities of interest to improve the overall engagement experience with IT Objective • Provide a blueprint for creating a streamlined consumption experience that consistently engages consumers and eliminates the need for them to avoid working with their IT organisation Why Do It • The ability to package deliverables as offers that consumers recognise and value, abstracting away confusing technology choices and complex fulfilment processes • This is accomplished by leveraging the Service Model to create Service Catalog Entries that can be instantiated and consumable offers that can be requested/ordered. • The ability to present and manage an consumption experience that exposes a variety of opportunities to acquire services, goods, knowledge, and/or support • This requires organisations to go beyond the traditional IT request catalog solutions Keys to Success
- 125. Request to Fulfil (R2F) Value Stream Functional Components And Data Objects Overview August 17, 2020 125
- 126. Request to Fulfil (R2F) Business Value Proposition August 17, 2020 126 Provide a blueprint for increasing business innovation velocity by facilitating a service consumption experience that allows consumers to easily find and subscribe to goods and services through a self-service engagement model Provide a functional framework that delineates between a single Offer Catalog and multiple Catalog Compositions to reduce complexity in the IT shopping experience Provide an architectural foundation for moving from traditional IT request management to service brokerage that increases both business and IT effectiveness Increase fulfilment efficiency and consistency through standard change deployment and automation Provide holistic visibility and traceability across service Subscription, Usage, and chargeback to improve IT Financial Management Enables increased cost optimisation; for example, by cancelling expired Subscriptions and reclaiming resources, Subscriptions, and/or licenses that are unused • Emphasise on time-to-value, repeatability, and consistency for consumers looking to request and obtain services from IT • Optimise both service consumption and fulfilment experiences by delineating between the creation of offers and catalog aggregation and Service Catalog Entry composition
- 127. Request to Fulfil (R2F) Key Performance Indicators And Critical Success Factors August 17, 2020 127 Success Factor Performance Indicators Ability to Meet Customer Expectations • New or modified Subscriptions per time period • % and number of Subscription requests complying or breaching SLA or OLA agreements • Number of Subscription requests accepted and rejected by the requestor for the first time right delivery/fulfilment • Variation in the average time to fulfil Subscription requests for the predictability of delivery • Number of Incidents related to request fulfilment • Arrival and departure rate of service requests Reduce Costs • Costs (burned resources) per service and per fulfilment step • Breakdown of self-source fulfilments versus one-off fulfilments • % and number of fulfilments requiring human intervention to be completed • Number of service request queues being managed External Service Provider Compliance • Number of purchase orders per time period • % and number of orders delivered and accepted complying with underpinning contract agreements • % and number of delivered orders breaching underpinning contract agreements • Number of Incidents related to the purchase order fulfilment • Number of purchase orders unfulfilled at the end of a given period • Number of orders delivered and accepted by the requestor per time period • Number of purchase orders rejected via no delivery or cancelled purchase orders Increase Speed/Agility/Flexibility (Operational Performance) • Completed service requests • Service request work-in-progress • Number of interactions with consumers per service during delivery • % of work-in-progress within SLA • % of completed work within SLA
- 128. Request to Fulfil (R2F) Functional Components August 17, 2020 128 Strategy to Portfolio (S2P) Enterprise Architecture Policy Proposal Portfolio Demand Service Portfolio IT Investment Portfolio – Auxiliary Requirement to Deploy (R2D) Project Requirement Service Design Source Control Build Build Package Release Composition Test Defect Request to Fulfil (R2F) Engagement Experience Portal – Secondary Offer Consumption Offer Management Catalog Composition Request Rationalisation Fulfilment Execution Usage Chargeback/Showback Knowledge and Collaboration Supporting Function Detect to Correct (D2C) Service Monitoring Event Incident Problem Change Control Configuration Management Diagnostics and Remediation Service Level
- 129. Engagement Experience Portal (Secondary Functional Component) August 17, 2020 129 Purpose • Facilitate service consumption by connecting any potential consumer with the right information, goods, services, or capability at the right time through a single experience, taking into account the service consumer profile • Drive the consumption through the Offer Catalog • Enable collaborationbetween communities of interest • Obtain support through a self-serviceinterface • Access knowledge that enables them to be better informed about services offered by IT Functional Elements • Be availableto all users that desire to consume IT services • Expose various IT functions and capabilitiesin a single place, unifying the experience in a form possibly similarto smartphone apps • Allow consumers to manage their User Profile Key Data Objects • User Profile - Personal data stored securely and associated with a specific service consumer consisting of different attributes managed by a user or consumed by other authoritativesources Key Attributes • ID - Unique Identifier • Name - Full name of the user • Role - Used to grant access to functionalityand information Key Data Object Relationships • User Profile to Offer Catalog - Present a personalised list of offers from the catalog depending on the consumer profile. • User Profile to Shopping Cart - The catalog items which are ordered need to link to the consumer that will receive the items. If an approval step is required, the User Profile helps to identify the authorised person by looking up informationfrom the organisational hierarchy • User Profile to Subscription- A Subscription is created and linked to the user for every service that has been ordered and fulfiledwhere a Subscription is required
- 130. Offer Consumption Functional Component August 17, 2020 130 Purpose • Present service offers to various service consumers. Facilitate consumption/managementof and payment for IT services rendered Functional Elements • Provide informationon the existing Subscription to enable the user to change/cancel existing Subscriptions • provide all necessary informationto guarantee the fulfilment • provide functionalityto order multipleoffers in one transaction • enable consumers to order services on behalf of other consumers • Provide visibilityto informationabout the user’s specific service consumption including pricing, usage, etc. • Expose information on the Service Level status for the services the user subscribed Key Data Objects • ShoppingCart - Contains the IT services that the user wants to order; the object only exists during the actual shopping session. Upon submission, a request is generated that is comprised of the content contained in the Shopping Cart Key Attributes • ID - Unique identifier • User ID - Unique identifier for the user (from User Profile) • ApproverID - Based on the user, the identifier of the approver (e.g., user ID of the manager) • Status - Controls the status of the approval steps/workflow if needed • ShoppingCart Line Item - Multiple items can be ordered in one go • ShoppingCart Offer ID - Identifier of the Offer • ShoppingCart Request ID - Based on the Offer the user might need to provide values/options for a successful fulfilment Key Data Object Relationships • ShoppingCart to User Profile - The contents of the Shopping Cart relate to a specific user, who is actually ordering the services. • ShoppingCart to Offer - The Shopping Cart only contains those items availableto the end-user from the existing Offers. • ShoppingCart to Request - Represents the relationship between the Shopping Cart and the Requests necessary to fulfil the services ordered in the shopping experience.
- 131. Offer Management Functional Component August 17, 2020 131 Purpose • Aggregate all Catalog Composition items and external supplier catalogs into consumable Offers that users can order through the Offer Consumption functional component Functional Elements • Contain all of the Offers availableto consumers and provide this information to the Offer Consumption functional component • Group services from multiple providers (internaland external) into a single Offer • Create the Service Contract template and provide informationto the Service Level functional component • Aggregate all Catalog Composition items and external supplier catalogs into consumable Offers that users can order through the Offer Consumption functional component • Build and publish the various offerings into Offer Catalogs for various populations to consume and determine prices, and valid options that consumers can select • Enable Offers to be grouped into an Offer Catalog to expose them as a collection of consumable items for a given group of consumers • Fulfil each Offer through numerous underlying Catalog Compositions as determined by the Offer Management functional component • Send the labour and asset cost estimates to the Proposal functional component • Receive estimation about labour and asset configurationfrom the Proposal functional component Key Data Objects • Offer - Defines how a Service Catalog Entry will be instantiated and under what terms and conditions – price, deployment, approval, workflow, service level (contract), etc. • Offer Catalog - A set or collection of Offers that are grouped together as something that can be consumed by certain consumers or consumer groups Key Attributes • Offer • ID - Unique identifier for every Offer in the catalog • Catalog ID - Identify in which catalog this Offer is available(from Offer Catalog) • Name - Descriptionof the Offer for consumers to identify/searchOffers • Start Date - Date/time on which the Offer may be consumed • Expiry Date - Date/time on which the Offer is no longer available • Status - Indicates if the Offer is ready for consumption (e.g., draft, published, retired, etc.) • Price - If applicable, the pricing information on the service, includingthe type of Subscription • Req Value - Mandatory options or variables linked to the service which need to be provided by the consumer to prevent issues during the fulfilment • Service ID - Identifier for the service (from Service Catalog Entry) • Offer Catalog • ID - Unique identifier for the Offer Catalog • Name - Offer Catalog name used for consumers • Roles - Authorisationrole required for access Key Data Object Relationships • Offer • Offer to Service Catalog Entry - Ensures all required informationis captured for the fulfilment(deployment/delivery)of the service • Offer to Shopping Cart - Each Offer may appear in multipleShopping Carts and each Shopping Cart may include multiple Offers • Offer Catalog • Offer Catalog to Offer - Represents the collection of Offers that comprise each Offer Catalog. • Offer Catalog to User Profile - Represents which users can access/consume each Offer Catalog.
- 132. Catalog Composition Functional Component August 17, 2020 132 Purpose • Create and publish the Service Catalog Entries, includingall of their dependencies, at the level at which these can be presented as Offers in the Offer Management functional component. Functional Elements • Manage inter-dependencieswithin the services • Create and publish the Service Catalog Entries, includingall of their dependencies, at the level at which these can be presented as Offers in the Offer Management functional component • Create Service Catalog Entries from the Service Release Blueprint in the Release Composition functional component (R2D Value Stream) • Accurately define services, as well as their dependencies and details, includingthe necessary informationfor the service to be instantiated • Create and update Service Catalog Entries to prepare them for consumption, includingconfigurableoptions (e.g., pricing, subscription terms, bundles, service level, support conditions, etc.). Key Data Objects • Service Catalog Entry - Authoritative source for the consolidated set of technical capabilities and specificoptions availablefrom a service system which can be delivered by the service provider. Serves as the bridge between the service system and the service offer Key Attributes • ID - Unique identifier for every service in the catalog • Name - Name of the service used for catalog and offer creators • Req Value - Provide a set of values/variables that are needed upon fulfilment Key Data Object Relationships • Service Catalog Entry to Service Release Blueprint - Ensure all catalog entries relate to the specificservice definitions used for fulfilment • Service Catalog Entry to Offer - Ensure all informationneeded is captured during the order phase
- 133. Request Rationalisation - 1 August 17, 2020 133 Purpose • Rationalise, break down, and route clean order requests (ready for fulfilment)to appropriate Fulfilment Execution engines or providers in order to deliver services to consumers Functional Elements • Provide informationto the consumer on the fulfilment status • Break down a single order/request into multipleFulfilment Requests • Track fulfilmentstatus and completion notificationsfrom fulfilmentchannel(s) as received • Update consumers on order status at the Subscription level, not at the level of the underlying Requests needed to fulfil the Subscription • Provide Subscription informationfor the creation of the associated Chargeback Contract • provide informationon Request delivery times for SLA measurements • Break down the composite request (described by the Shopping Cart and consumer-selectedvalues) into the individual Requests that need to be fulfiled • Send the bound Service Catalog Entry to the FulfilmentExecution functionalcomponent in order for it to create the Fulfilment Requests needed to satisfy the order • Provide Subscription informationto the Project functional component for associated FulfilmentRequests • Rationalise, break down, and route “clean order” requests (ready for fulfilment)to appropriate FulfilmentExecution engines or providers in order to deliver services to consumers • Ensure appropriate fulfilment-relatedSubscription informationis kept up-to-date, such as approval/rejections, modifications, cancellations, and so on • Enable the recordingof patterns of service consumption that can be used to shape demand for new and/or improved services • Break the request down into the IT services and provide these to the Fulfilment Execution functional component and create the Subscriptions for these services upon their successful fulfilment • Send the instances of the Service Contracts to the Service Level functional component if a Service Level functional component exists Key Data Objects • Request - Contains all Offers from the Shopping Cart which have been consumed and need to be fulfiled • Subscription - Managed by the Request Rationalisation functionalcomponent. This data object represents the rights to access a service that has been provided to a consumer
- 134. Request Rationalisation - 2 August 17, 2020 134 Key Attributes • Request • ID - Unique identifier for the Request • User ID - User identifier (from Shopping Cart) • Status - Controls the status of the fulfilment • Date - Date/time the Request was received • Latest Fulfil Date - Maximum date/time on which the Request needs to be fulfiled • Act Fulfil Date - Date/time on which the Request is fulfiled • Subscription ID - Link to the Subscription for this service (from Subscription) • Service ID - Based on the Offer, the service(s) are identified(from Offer) • Req Value - Based on the Offer, the user might need to provide values/options for a successful fulfilment(from Offer) • Subscription • ID - Unique identifier for the Subscription • Offer ID - Identifier of the service (from Offer) • User ID - Unique identifier of the user (from Engagement Experience Portal) • Desired Service ID - Unique identifier of the related Desired Service Key Data Object Relationships • Request • Request to ShoppingCart - Enables the traceability of Requests to the originatingorder (in the form of the Shopping Cart) which is used to report the current status of the order • Request to Subscription - Enables traceabilitybetween the Request and the resulting Subscription. This helps to better understand how the current Subscription state was realised • Request to Fulfilment Request - Used for tracking fulfilmentas well as to navigate between dependent FulfilmentRequests • Subscription • Subscription to User Profile - Enables the consumers to manage (view/modify)all of their Subscriptions. Also helps provide important informationrelated to the specific consumer Subscription • Subscription to Offer - Provides traceabilitybetween the Subscription and the Service Contract (via the Offer). • Subscription to ChargebackContract - Facilitates the various chargeback/showbackcalculations that are dependent on Subscription details such as its contract duration and service status • Subscription to Desired Service - Enables traceabilitybetween the consumer, their Subscription, and the realised service. There can be multiple Subscriptions linked to a single Desired Service
- 135. Fulfilment Execution August 17, 2020 135 Purpose • Orchestrate the deliveryof the various requests amongst (one or more) fulfilmentengines in order to deliver the IT service Functional Elements • Engage fulfilmentsystems that perform actions directly, or engage other systems in order to perform actions • Engage external providers in order to fulfilSubscriptions • Manage a registry of the available fulfillersto include what each fulfiller does (capabilities)and how to engage each fulfiller (where they are located and how to invoke them) • Update the IT asset inventory as they are ordered • Take the bound Service Catalog Entry and generate both the relevant FulfilmentRequests in order to realise/fulfil the originatingconsumer request • Maintain visibilityinto supplier capacity levels and raise alerts if capacity appears to be insufficientfor immediate demand • Select the appropriate fulfilmentmechanism • Coordinate if multiple fulfilmentmechanisms are needed and manage the dependencies required to fulfil the IT service Request • Create one or more Desired Services based on the Service Release Blueprint and associated Subscription for new service deployment Requests • Provide the Subscription status to the Request Rationalisationfunctional component • Create the Actual Services as a copy of the Desired Service within the Configuration Management functional component • Create a new service monitor or modify an existing one for the service provided in the Request as part of fulfilment • Create/route a Request to an external service provider to fulfil part or all of the service • Request IT assets necessary for fulfilment (such as licenses) • Trigger deployment engines to enable fulfilment of the service Key Data Objects • Fulfilment Request - Describes all fulfilmentaspects of an IT service, which includes items such as provisioning,deploying, modifying,actions (i.e., start, stop, etc.), decommissioning, and so on • Desired Service - The specificationof an instance of a service as required to meet the fulfilmentrequirements detailed in the consumer order (Request) and supported by a single Service Release Blueprint Key Attributes • Fulfilment Request • ID - Unique identifier • Request ID - Refers to the originatingRequest (from Request) • Desired Service ID - Links to the service to be instantiated (from Desired Service) • RFC ID - If applicable, an RFC will be created (from RFC) • Status - Status of the deployment/fulfilmentworkflow • Desired Service • ID - Unique identifier for the bound IT service to be delivered • Subscription ID - Traceabilityto the Subscription (user of the IT service) (from Subscription) • Service Release Blueprint ID - Getting necessary informationon the IT service (from Service Release Blueprint) Key Data Object Relationships • Fulfilment Request • Fulfilment Request to Request - Inform on Fulfilment Request status • Fulfilment Request to Service Release Blueprint - The Service Release Blueprint supplies the FulfilmentRequest with informationneeded to instantiate the service • Fulfilment Request to Desired Service - Acquire relevant information • Fulfilment Request to RFC - If applicable, the RFC created can be linked to the originatingRequest • Desired Service • Desired Service to Subscription- Create the traceabilityfrom service to Subscription • Desired Service to Service Release Blueprint - Acquire all necessary service information for fulfilment • Desired Service to Actual Service - Create traceabilityand enable verificationof correct deployment/fulfilment
- 136. Usage Functional Component August 17, 2020 136 Purpose • Track and manage actual usage of subscribed IT services and their associated costs Functional Elements • Track actual Usage of subscribed IT services by gathering IT service Usage metrics, activity, and history for both internal and external sourced IT services associated to an aspect of the Desired Service Key Data Objects • Usage Record - This contains the measured use of a particularservice or service component and can include data such as hours of usage, system usage (capacity, CPUs, etc.), or external supplier usage • Process and break down Usage informationfor each Subscription, its consumers (singular, group), provider, etc. • Collect service Usage metrics from the Service Monitoring functionalcomponent (D2C Value Stream) • Encrypt sensitive Usage information or set appropriate access controls • Generate service Usage history and activity reports • Provide Usage informationto the Chargeback/Showback functionalcomponent enabling usage-based chargeback or showback • Collect Usage informationfrom vendor invoices that represent resources used by the Service • Collect cost of assets partaking in delivery of the service Key Attributes • ID - Unique identifier • ChargebackContract ID - Relate the service Usage to the Chargeback Contract • Usage Date From - Date from which the service Usage is captured (linked to billing frequency in the Chargeback Contract) • Usage Date To - Date up to which the service Usage is captured (linked to billingfrequency in the Chargeback Contract) • Units - Transaction or consumption units • Unit Type - The type of units used. Key Data Object Relationships • Usage Record to ChargebackContract - Every Usage Record for a Subscription is associated with a Chargeback Contract. The Chargeback Contract defines the billing rule and frequency for a service Subscription
- 137. Chargeback/Showback Functional Component August 17, 2020 137 Purpose • Provide chargeback or showback for internal and external services based on Subscription, Service Contract, and/or Usage information Functional Elements • Calculate the chargeback/showbackof consuming/subscribingto a service to the subscriber • Take actual usage into consideration when calculatingthe charge of consuming a service • Consolidate the charges from all subscribed services once Usage is collected for the given billingperiod • Send the consolidated service charges to the Project functional component if a Project functional component exists • Send the subscribed service charges to the Service Portfoliofunctional component for an Actual Service if a Service Portfoliofunctional component exists • Send a Chargeback Record for approval and internal reconciliation request to the Finance function if a Finance function (external to IT) exists Key Data Objects • ChargebackContract - Details the contract for financialobligations between the service consumer and provider(s)as defined at the time of Subscription • ChargebackRecord - Represents the actual charge to the subscriber based on the Usage of subscribed services in a given time period. It computes the charge using the billingrule, with the input being the Usage Records collected for the period Key Attributes • ChargebackContract • ID - Unique identifier • Subscription ID - Link to the Subscription for which this Service Contract is instantiated (from Subscription) • Billing Rule - Pricingrule captured at the time of Subscription describes the method/formulafor translating the Usage into chargeback. This might be as simple as a product or as complex as an algorithm depending on the kind of service and granularityof chargeback/usage required to be captured • Billing Frequency - Billingfrequency to the subscriber (e.g., daily, weekly, monthly, quarterly) • Status - Status of the contract (active, inactive, etc.) • ChargebackRecord • ChargebackContract ID - Unique identifier • ChargebackDate From - Billing start date • ChargebackDate To - Billing end date • Subscription ID - Unique identifierof the related Subscription • Bill Amount - Amount billed for the given period • Bill Status - Status of the record (initiated, recorded, etc.) Key Data Object Relationships • ChargebackContract to Subscription - This relationship provides the traceability between the service rendered (represented by the Subscription) and the expected charges for those services (described in the Chargeback Contract) • ChargebackContract to ChargebackRecord - Multiplebilling records can be generated for a single Chargeback Contract as the Chargeback Record will be generated for each billingperiod
- 138. Knowledge And Collaboration - Supporting Function August 17, 2020 138 Purpose • Provide knowledge - structured IT/supplier produced articles, or unstructured Conversations from business/IT users, webinars, videos, training materials- in the form of content and Conversations that help to address the needs of IT service consumers Functional Elements • Enable SMEs to submit and/or approve Knowledge data objects (whether they are IT staff or service consumers) • Provide functionalityto enable the IT service consumers and IT staff to rank Knowledge data objects and Conversations, thus improvingfuture knowledge consumption • Provide functionalityto enable IT service consumers to participate in Conversations relating to the IT services they consume (collaboration) • Aggregate multiple(internal and external) Knowledge sources • Provide Knowledge in the form of content and Conversations that help to address the needs of IT service consumers • Include structured IT/supplier produced articles, or unstructured Conversations from business/IT users, webinars, videos, training materials, etc. which are searchable by the IT service consumers • Increase the contribution to Knowledge by providing all users with the ability to generate new content, either through informalConversations, or by more formal submissions of Knowledge • Improve accessibilityof Knowledge in the organisation • Reduce the number of requests for information/Knowledge that arrive at the IT service desk through self-service • Provide Knowledge for consumption by additional value streams in general and specificallyby the D2C Value Stream Key Data Objects • Knowledge - Structured and unstructured Knowledge from the Knowledge & Collaborationfunctional component. • Conversation - User Conversations from the Knowledge & Collaborationfunctional component. Key Attributes • Knowledge • ID - Unique identifier • Author ID - Unique identifierof the responsible author • Actual Service ID - If provided, linked to the Actual Service in ConfigurationManagement • Problem ID - If applicable,a link to a related Problem will be provided • Status - For example, draft, revise, published, review, archived • Publish Date - Date/time on which the item is availablefor publication • Expiry Date - Date/time on which the item is no longer visible • Title - Title of Knowledge data object • Body - Body text, video, or any other content that is published • Conversation • User ID - Unique identifier of the responsible author • Knowledge ID - Related Knowledge data object(s) • Body - Body text, video, or any other content Key Data Object Relationships • Knowledge • Knowledge to Problem - If a link to a Problem exists, the Knowledge data object will need changing when a Problem is (partly) resolved • Conversation • Knowledge to Conversation - Conversations can be linked to the Knowledge data object(s)
- 139. Detect to Correct (D2C) Value Stream Overview August 17, 2020 139 Framework for the business of IT operations and the services delivered by IT integrating Service Monitoring, Event, Incident, Problem, Change Control, Configuration Management, Service Remediation, and Service Level functions • Lack of timely identification of an issue before users of the service are impacted • Poor work prioritisation that does not understand business, IT operations, and technology impacts • Complexity of service delivery across multi-sourced environments exceeds the capabilities • Siloed organisational structure combined with process and technology misalignments • Slow troubleshooting from poor cross-domain teamwork due to poor data sharing, unreliable data, and inconsistent terminology • Slow remediation due to low levels of automation • Poor linkage of Incidents and Problems to the R2D Value Stream (providing Defect information about the service) • Poor linkage of Problems to the S2P Value Stream (providing demand loop back information about the service) • No end-to-end management of the service lifecycle across domains that leads to more disconnects between the IT department’s different groups, less focus on the business needs that are being served by the specific service and a lack of coherent view of the service status at all times Limitations of Existing Approaches • Incorporate a wide variety of sourcing methodologies across services, technologies, and processes and integrate the technical inter-relationships and inter-dependencies required to fix operational issues and improve the ability of IT to support business objectives by providing agility, increased uptime, and lower per- service cost Objective • Bring IT operations functions together to enhance IT services and efficiencies and reduce risk • Fix operational issues and improve the ability of IT to support business objectives by providing agility, increased uptime and lower per-service cost Why Do It
- 140. Detect to Correct (D2C) Value Stream Functional Components And Data Objects Overview August 17, 2020 140
- 141. Detect to Correct (D2C) Business Value Proposition August 17, 2020 141 Increase Efficiency and Reduce Cost •Focusing response based on causal factor, priority, and business impact •Increasing sharing of information and reduction of multipleentry of the same data •Creating a prescriptive data flow between Event, Incident, Problem, and Change Control •Centralised Event Management for faster analysis •Automation between and across business functions •Knowledge management and self-service linkage •Driving Service Monitoring configuration, operating/ServiceLevel targets, and predefined Knowledge linked to the R2F Value Stream •Improvingthe speed at which issues with a business service are identified, including proactive identification before service impact is severe Reduce Risk •Consistent data and configuration information shared between operational silos •Prescriptiveflow semantics and data objects •Defined business impact •Reducing the need for best-guess routing and clannish knowledge •Increased uptime by reduced MTTR •Creating a consistent way of managing SLM definitions, measurements, KPI calculations, and reporting back to the proper service owner or user (in the R2F Value Stream) •Implementingnetwork security to minimise intrusions that cause denial of service, viruses, and theft or corruption of data and minimiserisk exposure •Utilising SIEM to identify complex attack signatures that can disrupt operations and affect compliance •Performingthreat and vulnerability assessments •Providing an audit trail •Providing clear ownership Enable Continuous Service Improvement •Defined data objects to be shared with Problem Management •Using this accumulatedKnowledge as input into the S2P Value Stream •Improved management information and decision-making • Enables the IT organisation to increase efficiency, reduce cost, reduce risk, and drive continuous service improvement by defining the data objects and data flow required to integrate the operations of multiple domains
- 142. Detect to Correct (D2C) Key Performance Indicators And Critical Success Factors August 17, 2020 142 Success Factor Performance Indicators Ability to Meet Customer Expectations • New or modified Subscriptions per time period • % and number of Subscription requests complying or breaching SLA or OLA agreements • Number of Subscription requests accepted and rejected by the requestor for the first time right delivery/fulfilment • Variation in the average time to fulfil Subscription requests for the predictability of delivery • Number of Incidents related to request fulfilment • Arrival and departure rate of service requests Reduce Costs • Costs (burned resources) per service and per fulfilment step • Breakdown of self-source fulfilments versus one-off fulfilments • % and number of fulfilments requiring human intervention to be completed • Number of service request queues being managed External Service Provider Compliance • Number of purchase orders per time period • % and number of orders delivered and accepted complying with underpinning contract agreements • % and number of delivered orders breaching underpinning contract agreements • Number of Incidents related to the purchase order fulfilment • Number of purchase orders unfulfilled at the end of a given period • Number of orders delivered and accepted by the requestor per time period • Number of purchase orders rejected via no delivery or cancelled purchase orders Increase Speed/Agility/Flexibility (Operational Performance) • Completed service requests • Service request work-in-progress • Number of interactions with consumers per service during delivery • % of work-in-progress within SLA • % of completed work within SLA
- 143. Detect to Correct (D2C) Functional Components August 17, 2020 143 Strategy to Portfolio (S2P) Enterprise Architecture Policy Proposal Portfolio Demand Service Portfolio IT Investment Portfolio – Auxiliary Requirement to Deploy (R2D) Project Requirement Service Design Source Control Build Build Package Release Composition Test Defect Request to Fulfil (R2F) Engagement Experience Portal – Secondary Offer Consumption Offer Management Catalog Composition Request Rationalisation Fulfilment Execution Usage Chargeback/Showback Knowledge and Collaboration Supporting Function Detect to Correct (D2C) Service Monitoring Event Incident Problem Change Control Configuration Management Diagnostics and Remediation Service Level
- 144. Service Monitoring Functional Component August 17, 2020 144 Purpose • Creates, runs and manages monitors which measure all aspects/layers of a service such as infrastructure(system and network), application, and security Functional Elements • Be the system of record for all Service Monitors • Perform monitoring of all aspects of an IT service • Store all of the results of the measurements being done on the IT service • Calculate the results of compound Service Monitors from one or more simple measurements • Manage the lifecycleof the Service Monitor • Create, run, and manage monitors that measure all aspects/layers of a service Key Data Objects • Service Monitor - Performs the operational measurement aspects of a CI or an IT service in order to understand the current operational status of that CI or IT service Data Architecture • Create an association between the Service Monitor data object and the related Actual Service(s) • Initiate the creation of an Event or alert that is passed to the Event functional component if an Event functional component exists • Provide service monitoringstatus if an Offer Consumption functional component exists • Provide service Usage measurements if a Usage functional component exists • Provide business/IT measurements if a Service Level component exists • Receive Service Monitor definitions if a FulfilmentExecution functional component exists Key Attributes • ID - Unique identifier • Name - Name of the Service Monitor • Description - Description of the Service Monitor • Type- Type of the Service Monitor (system, application, network, security, etc. • Measurement Definitions - The definitions of the measurements that the Service Monitor is collecting about the monitored CI • Last Run Time - Date/time that the Service Monitor was last run • Last Run Status - Was the last run of the Service Monitor successful or not? • Actual Service ID - Identifier of related Actual Service(s) Key Data Object Relationships • Service Monitorto Event - Enables the traceability from the Events that are created to the Service Monitor they originated from • Service Monitorto Actual Service - The Actual Service is the CI being monitored
- 145. Event Functional Component August 17, 2020 145 Purpose • Manage Events through the Event lifecyclefor events that occur on any IT service Functional Elements • Be the system of record for all Events • Manage the state and lifecycleof the Events • Manage the correlationbetween Events • Categorise Event data • Forward Events categorised as Incidents to the Incident functional component • Initiate a change request (RFC) based on Event data to the Change Control functionalcomponent • May send Events for diagnostics and remediation processing Key Data Objects • Event - Represents an alert/notificationsignifying a change of state of a monitored CI Data Architecture • Create an association between the Event data object and the related Actual Service(s) Key Attributes • ID - Unique identifier of an Event • Name - Name of an Event • Category - Category of an Event category (info, warning, error, etc.); aids in determiningassignment and prioritisation • Type - Categorising the Event to causal or symptom type • Status - The current stage in the lifecycleof an Event • Status Time - Time stamp for the Status attribute • Severity - Severity of the Event • Threshold Definitions - The definitionsof the thresholds by which the Event severity is determined • Assigned To - Group or person that is assigned to handle the Event • Is Correlated - Is the Event correlated to other Events? • Actual Service ID - Related CI(s) Key Data Object Relationships • Event to Incident - Enables the connection between the Incidents and Events and supports the integration lifecyclebetween them • Event to RFC - Associated Event is availablefor RFC processing • Event to Actual Service - The Actual Service(s) associated with the Event(s) • Service Monitorto Event - Enables the traceability from the Events that are created to the Service Monitor from which they originated
- 146. Incident Functional Component August 17, 2020 146 Purpose • Facilitate normal service operations restoration as quickly as possible and minimisethe impact on business operations, thus optimising service quality and availability Functional Elements • Be the system of record for all Incidents • Manage the state escalation paths and general lifecycleof the Incident • Allow an Incident to be initiated from an Event • Create an Incident when an Interaction cannot be associated with an existing Incident because it requires additional clarification, diagnostics, or support actions • Create an association between the Incident data object and the related Actual Service(s). • Initiate the creation of a Defect when Incident diagnostics determines that an emergency fix is required from development for resolution • Trigger the execution of a Run Book (either automated or manual) to provide diagnostic informationor remediationsteps • Create a Problem record when the Incident is severe, requires further deep investigation, or is repeating if a Problem functional component exists • Trigger the creation of an RFC in order to implement a fix to the Incident fault if a Change Control functional component exists • Provide business measurements of Incident data Key Data Objects • Incident - Hosts and manages Incident data • Interaction - Hosts the record of an end-user’s contact with the service desk Key Attributes • Incident • ID - Unique identifier for the Incident record • Category - The category aids in determiningassignment and prioritisation • Sub Category - The second level of categorisation, followingCategory • Status - The current stage in the lifecycleof an Incident • Status Time - Time stamp for the Status attribute • Severity - Severity of the Incident • Priority - Priority of fixing the Incident • Title - Title of the Incident • Description - Description of the Incident • Assigned To - Group or person that is assigned to fix the Incident • Actual Service ID - Related CI(s) • Interaction • ID - Unique identifier for the Interactionrecord Key Data Object Relationships • Incident to Problem, Known Error - Connection between the Incidents that are converted to Problemsto permanentlyaddress severe/repeating Incidents • Incident to RFC - Connecting RFCs to the Incidents they originated from • Incident to Defect - Current practice - connecting Defects that are created when Incident diagnostics determines there is need for an emergency fix from development • Incident to Actual Service - Actual Service to which the Incident is associated and usually the main subject of • Event to Incident - Enables the connection between the Incidents and Events and supporting the integration lifecyclebetween them
- 147. Problem Functional Component August 17, 2020 147 Purpose • Managing the lifecycleof all Problemsand resolve severe/repeating Incidents, prevent Incidents from happening, and minimise the impact of Incidents that cannot be prevented Functional Elements • Be the system of record for all Problem records • Manage the state and lifecycleof the Problem • Create Known Error data object instances from unsolved Problems • Push Problem data to trigger the execution of a Run Book data object to provide diagnostics informationor remediationsteps • Create an RFC associated to a Problem in order to implement a fix to the issue that is documented by the Problem • Use existing Knowledge data to solve a Problem • Create a new Knowledge data object based on Problem Management activities • Push Problem data requiring emergency/specificdevelopment to the Defect functional component • Push a PortfolioBacklog Item to the PortfolioDemand functional component for backlog processing Key Data Objects • Problem, Known Error - Defines the Problem or Known Error and manages the Problem and Known Error lifecycle Data Architecture • Associate Problem(s)to Actual Service (s) • Associate Incident data to the corresponding Problem record and continue the investigation around the Incident reported fault within the Problem lifecycle Key Attributes • ID - Unique identifier for every Problem record • Category - The Category aids in determining assignment and prioritisation • Sub Category - The second level of categorisation, followingthe Category attribute • Status - The current stage in the lifecycleof a Problem • Status Time - Time stamp for the Status attribute • Title - Title of the Problem • Description - Description of the Problem • Assigned To - Group or person that is assigned to fix the Problem • Actual Service ID - Related Actual Service(s) Key Data Object Relationships • Problem, Known Error to RFC - This connection enables the relation of an RFC record that is created when problem resolution requires a change • Problem, Known Error to Portfolio Backlog Item - Ensures a PortfolioBacklog Item is created for Problemsrequiring a future fundamental/big fix/enhancement to the IT service • Problem, Known Error to Defect - Enables the creation of Defects when emergency/specificfixes require development • Incident to Problem, Known Error - Connection between the Incidents that are converted to Problemsto permanentlyaddress severe/repeating Incidents • Problem, Known Error to Actual Service - Problem records are mapped to the affected Actual Service(s) • Problem, Known Error to Knowledge - Creating a relationshipbetween the Knowledge data object and the Problem it originated from
- 148. Change Control Functional Component August 17, 2020 148 Purpose • Manage the lifecycleof all the RFCs in the IT environment and ensure that changes are done in a standardised and auditable way so that the business risk is minimised Functional Elements • Be the authoritative system of record for all change request information • Manage the state and lifecycleof the change • Facilitate communicationwith stakeholders • Assess the risk of proposed changes and their implementation • Support the impact and risk assessments to minimise risk of production disruptions involved when rolling out changes • Enable management of organisationalchanges and training needed for making a new release a success • Enable notification of all affected change stakeholders and facilitate their collaboration on change execution • Support automation of changes so that human participationis reserved for the highest added value and most complex change work • Enable RFC management against a change calendar and avoid change collisions • Provide change data to the Event and/or Service Monitoring functionalcomponents to facilitate root-cause analysis process in the context of the impact changes may have Key Data Objects • RFC - Change data to manage the change lifecycleand includes details of the proposed change Data Architecture • Associate change(s) to Actual Service (s) • Associate changes with Incidents bi-directionally (changes in response to Incidents, and changes that actually cause Incidents; i.e., unsuccessful changes) • Associate changes with Events when a change triggers an Event or an Event occurs during a change period • Associate the Fulfilment Request with the RFC record as the overall framework that facilitatesthe IT service implementation/instantiation • Associate RFCs to the Problem in order to implementa fix to the issue that is documented by the Problem Key Attributes • RFC ID - Unique identifierfor the change record • Category - The category aids in determiningassignment and prioritisation • Sub Category - The second level of categorisation, followingCategory • Phase - The current step in the RFC workflow • Phase Time - Time stamp for the change phase • Approval Status - The current status of the RFC approval • Risk - The probabilitythat the change could cause harm or loss, or affect the ability to achieve objectives • Planned Start Time - Date/time that RFC implementationis planned to start • Planned End Time - Date/time that RFC implementationis planned to end • Title - Title of the Incident • Description - Description of the Incident • Assigned To - Group or person that is assigned to fix the Problem • Actual Service ID - Related Actual Service(s) Key Data Object Relationships • Fulfilment Request to RFC - An RFC initiated from the FulfilmentExecution functional component (R2F Value Stream) is created on service implementation/instantiation • RFC to Actual Service - Associates the RFC with affected Actual Service(s) • Problem, Known Error to RFC - Enables the relation of an RFC record that is created when problem resolution requires a change • Incident to RFC - Connecting RFCs to the Incidents they originated from. RFC to Event (n:1): Associated Event is availablefor RFC processing
- 149. Configuration Management Functional Component August 17, 2020 149 Purpose • Tracks the inventories of Actual Services and their associated relationshipsincluding identification,controlling, recording, reporting, auditing, and verificationof service items and their data such as versions, constituent components, their attributes, and relationships Functional Elements • Be the system of record for all Actual Services and their associated relationships • Manage the lifecycleof the Actual Service • Serve as the data store for the realisation of the service in the production environment • Calculate and provide the change impact based on the proposed change and the Actual Service relationships • Calculate and provide the business impact of the Incident to help in the prioritisation process • Calculate and provide the business impact of the Event to help in the prioritisationprocess Key Data Objects • Actual Service - The realised deployment of the service. Includes Configuration Items that represent the implementedservice components. Should be kept in sync with the Desired Service, but includes specific implementationcharacteristicsand Details Data Architecture • Allow hierarchicalrelationshipsbetween Actual Services • Associate a Run Book with the Actual Service against which the Run Book is associated • Associate an Actual Service with an RFC with which the change is associated • Associate the Actual Service with the Problem record against which the Problem is Associated • Associate the Actual Service with the Incident with which the Incident is associated • Calculate and provide the business impact of the Incident to help in the prioritisation Process • Associate the Actual Service with the Event with which the change is associated • Associate the Actual Service with the Service Monitor with which the change is associated Key Attributes • ID - Unique identifier of the Actual Service • Name - Name of the Actual Service • Type - Type of the Actual Service (e.g., infrastructureservice, customer-facingservice, enabling service, front office, etc.) • Create Time - Date/time the Actual Service was created • Last Modified Time - Date/time the entry was last modified in a significant way • Owner - Group or person that is assigned to own the Actual Service • Location - Location of the Actual Service. Can vary from high-level country to city or low-level, such as building or room Key Data Object Relationships • Desired Service to Actual Service - Create traceabilitybetween the Desired and Actual Service(s) • RFC to Actual Service - The Actual Service(s) associated with the change activity • Problem, Known Error to Actual Service - Problem records are mapped to the affected Actual Service(s) • Run Book to Actual Service - Run Book records are mapped to the associated Actual Service(s) • Incident to Actual Service - Actual Service(s) to which the Incident is associated • Actual Service to Event -The Actual Service(s) associated with the Event • Actual Service to Service Contract - Connecting between the Actual Services and the Service Contract in which they are measured. • Service Monitorto Actual Service - The Actual Service being monitored
- 150. Diagnostics And Remediation Functional Component August 17, 2020 150 Purpose • Using manual and automated Run Books, provide diagnostics informationand/or remediationsteps to shorten the mean-time-to-repair of a fault and streamline diagnosis and remediationfor service functions by applying knowledge solutions to service anomalies Functional Elements • Be the system of record for all Run Books • Manage the Run Book lifecycle • Allow an Event to trigger a Run Book mainly for diagnostics purposes • Allow an Incident to trigger a Run Book for diagnostics or remediationpurposes (remediationthat does not require RFCs) • Allow a Problem to trigger a Run Book for remediationpurposes (after an RFC has been opened) Key Data Objects • Run Book - A routine compilationof the procedures and operations which the administrator or operator of the system carries out Data Architecture • Allow hierarchicalrelationshipsbetween Run Books associate a Run Book with an Actual Service Key Attributes • ID - Unique identifier for the Run Book record • Description - Description of the Run Book • Category - The Category aids in determining assignment and prioritisation • Execution Time - Date/time the Run Book was created • Actual Service ID - Related Actual Service(s) Key Data Object Relationships • Actual Service to Run Book - Track Run Books and the Actual Service(s)with which they are associated
- 151. Service Level Functional Component August 17, 2020 151 Purpose • Enable the design and creation of Service Contracts (SLAs) and manage all Service Contract data objects throughout their lifecycleincludingthe governance of the Service Contract instances from the moment they are instantiated Functional Elements • Be the system of record for the Service Contract • Manage the Service Contract lifecycle(create, store, and maintain). • Manage the lifecycle(create, store, and maintain) of KPIs • Manage the relations between the Service Contract data object and the KPI data object throughout their lifecycle • Receive measurements such as Incident data as well as other informationthat may be covered by the Service Contract and used for calculatingthe KPI measurements • Create reports on the Service Contracts to show the quality of service per SLA • Receive business/IT measurements from Service Monitoring • Receive Incident business measurements • Send reporting data on the Service Level status Key Data Objects • Service Contract - Describes the service characteristicsand supports service measurementtracking, governance, and audit • Key Performance Indicator - The definitionof an objective that is measured, its requested thresholds, and the exact mathematicalmethod in which measurement data items are used in order to calculate the KPI measurements Data Architecture • Allow hierarchicalrelationshipsbetween Service Contracts Key Attributes • Service Contract • ID - Unique identifier • Name - Name of the Service Contract • Type - Type of the Service Contract (SLA, OLA, UC) • Provider - Provider of the service • Consumer- Consumer of the service • Start Date - Start date/time of the Service Contract • End Date - End date/time of the Service Contract • Support Calendar - Contracted support hours of the service • AdherenceCalculation Periodicity - Service measurement calculationperiod • Maintenance Window - Service maintenance timeframes/blackout periods • Actual Service ID - Related Actual Service(s) • Key Performance Indicator • ID - Unique identifier • Name - The name of the Key PerformanceIndicator • Description - A short description of the Key PerformanceIndicator • Threshold - The threshold of the Key PerformanceIndicator Key Data Object Relationships • Service Release Blueprint to Service Contract -The Service Release Blueprint serves as the place where the Service Contract templates are being stored after their development and before they are shipped to the Service Level functionalcomponent • Actual Service to Service Contract - Relationships to Actual Service(s) are maintainedand updated to ensure functional component and data object traceabilityin the value stream • Service Contract to KPI - KPIs will track the measurements associated with Service Contracts. Service Contracts will have multipleKPIs • Subscription to Service Contract - Once a Subscription is instantiated it also triggers the instantiation of a Service Contract instance from the Service Contract template
- 152. Issues With IT4IT Framework • Issues − IT4IT as a value chain approach to IT − Inconsistent level of detail − Narrow focus and set of functional components August 17, 2020 152
- 153. IT4IT As A Value Chain Approach To IT • IT4IT does not really describe a set of value chains in the real meaning of the term • It does not take into account the wider supply chain context of a value chain or use the de facto value chain standard Supply Chain Operations Reference (SCOR) • It does not identify or define a measurement approach or framework on how IT generates value to the business • The IT value chain is in reality a chain within a wider business value chain − IT supplies services to the wider business function that enables the business create value from the products and services it supplies • It does not deal with the problem that the IT function is all too often a monopoly provider of IT services to the business functions or at least a gatekeeper to external solution and service providers, allowing or disallowing their introduction and use • This gives rise to shadow IT where the business bypasses what they view and experience as an unresponsive central IT function and goes directly to external service providers August 17, 2020 153
- 154. Inconsistent Level Of Detail • The IT4IT reference architecture is very detailed and prescriptive in the definition of the functional components and their attributes, data objectives and relationships • Levels 4 and 5 are left undefined • Focus on software development rather than more general solution procurement/acquisition and configuration/customisation • Balance between run the business and change the business not really addressed with focus on new services rather than keeping existing services operational • Generally at least 70% of the IT budget is spend on run the business/business as usual/keep the lights on activities August 17, 2020 154
- 155. Narrow Focus And Set Of IT Functional Components • The set of IT-related functional components defined in the IT4IT reference architecture can be viewed as a set of capabilities the IT function must possess to operate effectively and deliver services to the business efficiently and cost- effectively • There are (too) many different views of the critical capabilities of the IT function such as: − IT4IT Reference Architecture contains 32 functional components − IT Capability Maturity Framework (IT-CMF) https://ivi.ie/critical-capabilities/ contains 37 critical capabilities − Skills Framework for the Information Age (SFIA) - http://www.sfia-online.org/ lists over 100 skills − European e-Competence Framework (ECF) http://www.ecompetences.eu/ contains 40 competencies − ITIL IT Service Management https://www.axelos.com/best-practice-solutions/itil − COBIT 2019 https://www.isaca.org/resources/cobit has 40 management and control processes • There are many well-proven well-established IT function capability frameworks without the need for yet another one • IT needs the existing frameworks more widely and successfully implemented rather than new frameworks August 17, 2020 155
- 156. Sample Competencies And Processes For IT4IT, IVI And ITIL August 17, 2020 156 IVI Accounting and Allocation Business Planning Business Process Management Capacity Forecasting and Planning Demand and Supply Management Enterprise Information Management Governance Green Information Technology Innovation Management Leadership Organization Change Management Organization Design and Planning Risk Management Service Analytics and Intelligence Sourcing and Supplier Management Strategic Planning Budget Management Budget Oversight and Performance Analysis Funding and Financing Benefits Assessment and Realization Project Portfolio Management Total Cost of Ownership Capability Assessment Management Data Analytics Enterprise Architecture Management Information Security Management Knowledge Management People Asset Management Personal Data Protection Programme Management Project Management Relationship Management Service Provisioning Solutions Delivery Technical Infrastructure Management User Experience Design User Training Management IT4IT Enterprise Architecture Management Policy Management Proposal Management Portfolio Demand Management Service Portfolio Management IT Investment Portfolio Management Project Management Requirement Management Service Design Management Source Control Management Build Management Build Package Management Release Composition Management Test Management Defect Management Engagement Management Offer Consumption Management Offer Management Catalog Composition Management Request Rationalisation Management Fulfilment Execution Management Usage Management Chargeback/Showback Management Knowledge and Collaboration Management Service Monitoring Management Event Management Incident Management Problem Management Change Control Management Configuration Management Diagnostics and Remediation Management Service Level Management ITIL Access Management Application Development and Customisation Availability Management Capacity Management Change Management Compliance Management Service Monitoring Event and Alert Management Financial Management Incident Management IT Architecture Management IT Facilities Management IT Operations Management IT Security Management IT Service Continuity Management Knowledge Management Problem Management Process Evaluation Project Management (Transition Planning and Support) Release and Deployment Management Request Fulfilment Risk Management Service Asset and Configuration Management Service Catalogue Management Service Evaluation Service Level Management Service Portfolio Management Service Validation and Testing Supplier Management
- 157. Sample Competencies And Processes For ECF And COBIT August 17, 2020 157 European e-Competence Framework IS and Business Strategy Alignment Service Level Management Business Plan Development Product / Service Planning Architecture Design Application Design Technology Trend Monitoring Sustainable Development Innovating Application Development Component Integration Testing Solution Deployment Documentation Production Systems Engineering User Support Change Support Service Delivery Problem Management Information Security Strategy Development ICT Quality Strategy Development Education and Training Provision Purchasing Sales Proposal Development Channel Management Sales Management Contract Management Personnel Development Information and Knowledge Management Needs Identification Digital Marketing Forecast Development Project and Portfolio Management Risk Management Relationship Management Process Improvement ICT Quality Management Business Change Management Information Security Management IS Governance COBIT EDM01 Ensure Governance Framework Setting and Maintenance EDM02 Ensure Benefits Delivery EDM03 Ensure Risk Optimisation EDM04 Ensure Resource Optimisation EDM05 Ensure Stakeholder Transparency Align, Plan and Organise APO01 Manage the IT Management Framework APO02 Manage Strategy APO03 Manage Enterprise Architecture APO04 Manage Innovation APO05 Manage Portfolio APO06 Manage Budget and Costs APO07 Manage Human Resources APO08 Manage Relationships APO09 Manage Service Agreements APO10 Manage Suppliers APO11 Manage Quality APO12 Manage Risk APO13 Manage Security APO14 Manage Data BAI01 Manage Programmes BAI02 Manage Requirements Definition BAI03 Manage Solutions Identification and Build BAI04 Manage Availability and Capacity BAI05 Manage Organisational Change Enablement BAI06 Manage Changes BAI07 Manage Change Acceptance and Transitioning BAI08 Manage Knowledge BAI09 Manage Assets BAI10 Manage Configuration BAI11 Manage Projects DSS01 Manage Operations DSS02 Manage Service Requests and Incidents DSS03 Manage Problems DSS04 Manage Continuity DSS05 Manage Security Services DSS06 Manage Business Process Controls MEA01 Manage, Monitor, Evaluate and Assess Performance and Conformance MEA02 Manage, Monitor, Evaluate and Assess the System of Internal Control MEA03 Manage, Monitor, Evaluate and Assess Compliance With External Requirements MEA04 Manage Assurance
- 158. IT Function Structure • Terms likes skills, capabilities and processes are used interchangeably in these frameworks • But they all have different meanings • The operating model of the IT function should bring all these together into and translate them into a coherent whole that links structure, roles, people, competencies, processes and methodologies • The IT function must ultimately be actual, concrete, tangible working entity rather than a collection of theoretical capabilities August 17, 2020 158
- 159. IT Function Structure, Operating Model and Capabilities August 17, 2020 159 The IT function operating model is combination of a structure with capabilities implemented and operated consistently by repeatable processes and filled by people with roles using tools, techniques and methodologies to perform the required workload in order to deliver on and measure commitments and generate value for the organisation IT Function Operating Model Roles and Staffing Structure Capabilities Tools, Methodologies, Techniques Commitment and Value Processes
- 160. Interconnected Aspects Of IT Function Operating Model The IT4IT reference architecture does not provide a context or attempt to locate the functional components within a wider operational structure August 17, 2020 160 Structure Capabilities Will Be Delivered and Operated Through Defined Processes Personnel Will Have Skills to Deliver Capabilities Personnel Will Operate Within Structure Processes Will Be Supported By Tools Personnel Will Use Tools and Methodologies Processes Roles and Staffing Commitment and Value Tools, Methodologies, Techniques Skills and Capabilities Personnel Will Operate Processes Commitment Will Use Processes to Deliver and Measure Value Personnel Will Deliver Value Capabilities Will Be Embedded in Structure Methodologies Will Support The Delivery of Value Skills and Capabilities Will Enable The Delivery of Value Right Set of Tools and Methodologies Will Support Capabilities Processes Will Underpin The Operating and Functioning Of the Structure
- 161. Not All IT Functions Need All Capabilities • IT Function work will be a balance between − Run The Business – Typically 70%+ • Business as usual activities (BAU) related to administering and operating production IT systems and providing service to users and managing the BAU function and its service delivery − Change the Business – Typically 30%- • Designing and Implementing major transformation, programmes and projects and delivering new services and systems and managing the associated technology and organisation changes • Balance will depend on the profile of the organisation − Capabilities required will depend on this profile • Change will span both activities − Small changes in Run The Business − Large changes in Change the Business August 17, 2020 161 Run The Business Business As Usual Keep The Lights On Implement Ongoing Changes and Enhancements IT Function Change The Business New Programmes, Projects Transformations, Major Initiatives Manage Change Market Changes Business Changes Technology Changes, Refreshes Regulatory Changes Small Change Large Change
- 162. IT4IT Functions Generalised Set of IT Function Capabilities Enterprise Architecture Management Enterprise Architecture Policy Management Organisation Design, Planning and Operation Proposal Management Sourcing and Supplier Management, Acquisition, Procurement Portfolio Demand Management Demand and Supply Management, Capacity Forecasting and Planning Offer Management Service Provisioning, Service Delivery and Service Monitoring and Management Service Portfolio Management Catalog Composition Management Usage Management Chargeback/Showback Management Service Monitoring Management Event Management Incident Management Problem Management Configuration Management Accounting, Funding, Financing, Budgeting, Planning and Asset Management Diagnostics and Remediation Management Programme Management, Portfolio Management, Project Management Service Level Management Business and Process Analysis and Design IT Investment Portfolio Management Solution Architecture, Design and Specification Project Management Solution Installation, Configuration, Customisation, Development, Delivery and Implementation Requirement Management Testing, Quality and Defect Management Service Design Management Relationship Management and Business Engagement Request RationalisationManagement Data, Information and Knowledge Asset Management and Analytics Source Control Management Change and Change Management, Solution and Service Introduction Build Management IT Leadership and Governance Build Package Management Strategic and Business Planning Release Composition Management Security, Continuity and Disaster Recovery Fulfilment Execution Management People and Facilities Asset Management and Training Development and Delivery Offer Consumption Management User Experience Design Test Management Organisation Design and Change Management Defect Management Operations Management, Manage Solution and Service Portfolio Engagement Experience Management Trend Analysis, Research, Development and Innovation Management Knowledge and Collaboration Management Infrastructure, Networks, Communications and Telephony Change Control Management Benefits Assessment and Realisation Mapping IT4IT To Generic IT Function Capabilities August 17, 2020 162
- 163. Mapping IT4IT To Generic IT Function Capabilities • IT4IT contains a concentration of service management capabilities while omitting a wide range of other key IT function capabilities, such as: − IT Leadership and Governance − Strategic and Business Planning − Security, Continuity and Disaster Recovery − People and Facilities Asset Management and Training Development and Delivery − User Experience Design − Organisation Design and Change Management − Operations Management, Manage Solution and Service Portfolio − Trend Analysis, Research, Development and Innovation Management − Infrastructure, Networks, Communications and Telephony − Benefits Assessment and Realisation • Large number of service management capabilities contained in IT4IT is an effective operationalisation of ITIL-like service management August 17, 2020 163
- 164. IT4IT Applicability • The IT4IT framework would be applicable in number of areas: − Framework for outsourcing service provider to deliver services to clients − IT operations element of overall IT function August 17, 2020 164