Article 4 IT Physician Heal Thyself Building Bridges and Breaking Boundaries

Transcription

1 Article 4 Physician Heal Thyself Building Bridges and Breaking Boundaries End to End Service Management A Case Study The Unified Process Framework (UPF) Governance By John Gibert Southcourt This is the fourth in a series of six articles that are due to appear in SERVICEtalk, Computing and its sister papers through Europe. They support the theme of this year s UK itsmf conference on building bridges and breaking boundaries. They are also part of the ba programme to improve the alignment of and. Support Enable Figure 1 Summary of the Previous Articles Previous articles have introduced the idea of a Unifying Process Framework that aligns the domains and frameworks across and into the business. The articles considered some key Management Domains: 1. Service Management 2. Project Management 3. Applications Management 4. Infrastructure Management 5. Strategy & Architecture.. Each of these domains have their own frameworks IL, MOP, PRINCE2, ASL, BSD/SSADM, RUP, DSDM, ISPL, IS-7799, COB and Catalyst POLDAT, that were developed separately and in parallel by different groups with different outlooks. They were not designed to align with one another and so they don t! The Unified Process Framework (UPF) The articles introduced the Unified Process Framework (UPF) which has been developed to be a Framework of Frameworks, into which all the best practices within the individual frameworks can be assembled so that processes are truly end to end. The UPF is a process unifying framework that aligns not only the domains within, but also aligns with the business. The Purpose of this Article The purpose if this, the fourth article, is to provide a worked example of how an service is developed and operated as part of a business development programme. The example takes an Service: from concept as an Service, in the Strategy and Architecture domain; through development, as part of a Development Programme domain; into day to day operation and support in Service Delivery domain. The article shows how the UPF model works across the and Governance domains. The case study shows how the Governance Framework and the Framework of UPF align and the business through the life cycle of business and Services End to End. The Case Study The case study is based upon the practices of a utility company that had a business development directorate who were responsible for driving strategic change. Wee will call them Ajax. The case study deals with the provision of internet billing and payment services to millions of customers. This was part of a programme of business service development that was significantly enabled by, but which also involved significant business process development and organisational change, as well as heavy marketing and selling. The UPF is made up of four dimensions and the last article explained the two dimensions of the core UPF processes that interact with one another. - The Governance Framework and Domains that operates in the Vertical Dimension, the development of which was influenced by the control framework of COB. - The Framework and Domains that operates in the Horizontal Dimension, the development of which was based upon Michael Porter s. Figure 1 provides an overall picture of the UPF. C:\data\ba\documentation\gibert\Computing & Service Talk 4.doc Shared with itsmf, ba and Computing The case study shows how Service Management was at the heart of the process of developing as well as delivering a business solution, with service management influencing strategy, architectures and projects to deliver service focused solutions. The case study shows how a new set of services were developed and delivered as part of a business programme to improve the way the business provided services to its customers. The new services involved the delivery of bills and the processing of payments over the internet. This capability was delivered through the IBAP project (Internet Billing and Payments) which was part of an 18 month programme to rationalise the customer interface as part of a revamp of the Customer Relationship Management, all under a Programme badged CRM2.

2 Ajax s Original CRM Programme Customer Relationship Management had been implemented by Ajax in the late 1990s through the original CRM programme. CRM brought together call centre, billing centre and sales centre interfaces with customers. The original CRM programme was delivered before UPF existed. Whilst the CRM programme had produced a solution, there were many shortcomings in the way CRM worked for the company and the overall development and operational costs - the total ownership costs were 70% higher than they thought necessary. These shortcomings included: Marketing problems because of the slower than expected delivery of the solution process problems because the solution was not inline with the required business processes Lack of reliability and flexibility because the solution and infrastructure were not highly serviceable High cost of business staffing because of staff intensive processes and systems usability problems High ownership costs because of poor serviceability and costly infrastructure To address these shortcomings, Ajax made a significant investment in a follow-up programme CRM2, to sort out the issues and reduce the total business operational costs and to be at the forefront of market trends. The Creation of Ajax s UPF Between the original CRM programme and its follow up CRM2, Ajax executive had instigated a review of the governance structure covering the way the business organised business development, the way that the executive steered the business, along with the way business processes were designed and the way that delivered Service driven solutions. They had decided to appoint a Chief Process Officer CBPO to operate alongside the CIO, in a board advisory position. The board looked to the CBPO to provide a top down structure to business process. One of the first tasks of the CBPO s appointment was to lead the top down definition of business governance through the formalisation of the Unified Process Framework and to establish business wide commitment to its use it. Ajax had been using the Balanced Score Card to develop, steer and communicated their business strategy. They had adapted the Balanced Score Card to give full recognition to the core dimensions of UPF. Governance was one of the four dimensions. vision, for best practice to govern the direction development and delivery of the enterprise Ajax s UPF Driven - Balanced Score Card Governance vision, to satisfy the needs of our customers by the provision of excellent products and services vision, of short and long term growth in profits and assets for the benefits of shareholders Customer Outcomes Vision & Strategy Finance vision, how to develop and use our capabilities to best effect Capabilities Figure 2 The other three Balanced Score Card dimensions reflected the value chains of Customer Outcomes, Capabilities (which included suppliers and partners and the Finance value chain. Ajax s approach to UPF also incorporated both 6 Sigma and EFQM which were used in a more bottom up manner for tactical quality improvement initiatives to improve people, process and technology. The Ajax Executive Governance Framework UPF provided the Governance Framework for implementing the Balance Score Card for top down direction and for incorporating 6 sigma and EFQM for bottom up improvement. The following diagram summarises how the Governance Framework worked. Ajax s UPF Executive Governance Framework 4 Strategy Management 3 5 Plan Management Governance Framework Development Plan Management Portfolio & Project Management Release & Readiness Management Operational Plan Management Operational Delivery Management Operational Support Management The appointment of a CBPO was the key to the turnaround of business and management practices at Ajax. No longer was business process buried in bottom up quality initiatives. With UPF, process was highly visible. It was driven by the executive: Top Down from the boardroom. Explaining the diagram above, UPF provided: C:\data\ba\documentation\gibert\Computing & Service Talk 4.doc Shared with itsmf, ba and Computing 1 2 Figure 3 1. Executive Governance with clear processes supporting management accountabilities covering Direction, linking Strategy through Architecture to Planning and Control.

3 2. Management Governance with clear linkage from Direction Planning to: Development Planning for the development activities resources and costs and Delivery Planning for the resulting operational activities, resources and costs. 3. Direction providing the architectural framework for Development to align the components of the business, namely its current and planned: Markets, Customers, Products, Services, Processes, People/ Organisation, Technologies and Suppliers. This provided the overall design authority/ blueprint for Portfolio, Programme and Project Management for them to deliver the revised architectures in a synchronised multi disciplinary manner across the value chains. 4. Clear definition of the business s with the value chain layers identified with clear life cycles and management accountabilities defined for the life span of the affected business value chain components. 5. A managed interface between Development and Delivery using Readiness & Release processes to manage entry and exit quality gates across the project stages for each of the value chains and their components within the multi-disciplinary projects. The diagram below shows the domains, as they applied to the to the CRM2 programme and the IBAP project, along with how they were linked together by Architecture Governance. CRM2 was likely to reduce significantly the workload of its call centres, billing centres and sales centres, provide customers with speed and flexibility and save significant costs. This had been part of their Balanced Score Card Vision plan for a number of years. was the enabler but the executive had the vision. As with all Strategic Programmes, the Development function lead market and related research into all aspects of the business and what was going on in the industry. Included in the research were trends in the use and take up of, and at this point in time, the adoption of web services. The Development function were also proactive in investigating potential scenarios and solutions. This strategic research involved experts from each of the business and value chains. Development used Architecture Governance to join together the analysts performing the analysis of the value chains, so providing an integrated architecture model that drove the CRM2 change programme. The diagram below illustrates the business and components of the model with their relationships. The Architecture Governance model was maintained on a database supporting current and future scenario baselines. Architecture Governance Linking and Components Ajax s UPF linked by Architecture Governance Customer Types Products/ Services Processes Organisation Units Outcome Market & Customer Management Product & Service Management Markets Services Functions Information Locations Internal Process Management Information Management Organisation Management Infrastructure Management Service Management Infrastructure Management Products Organisational Units Applications Infrastructure Products Job Roles Figure 5 External Finance Supplier Management Finance Management Figure 4 Development used the architecture model to identify existing solutions where they existed regarding all the value chains. The CRM2 programme was very different from the original CRM programme because it used a unified management framework. Strategy & Architecture Governance The executive of Ajax recognised that they needed to provide web based services to their large consumer base. The customers needed to be able to do everything via the web. It did not want to develop if it could buy. It did not want to invent if it could acquire and improve. Consequentially it considered buying in everything and anything that made sense including guidance on the services offered to customers, the internal processes operated, the services needed, the application systems, the appropriate infrastructure, all along with the selection of strategic partners for the provision of guidance, products and services. C:\data\ba\documentation\gibert\Computing & Service Talk 4.doc Shared with itsmf, ba and Computing

4 For IBAP, the value chains were a critical part of the business value chains. Development Governance The purpose of the IBAP project was to deliver business and services that involved the parallel development and involvement of all the dependent value chains. This was a truly multi-disciplinary approach, or as it was called a multi-value chain approach which was managed by Portfolio, Programme and Project Governance, as illustrated in the following diagram. Ajax s UPF linked by Portfolio and Project Governance Outcome Internal External Finance Market & Customer Management Product & Service Management Process Management Portfolio & Project Management Information Management Organisation Management Infrastructure Management Service Management Infrastructure Management Supplier Management Finance Management Figure 6 The IBAP project took the CRM2 programme s Architecture and involved all the allocated value chain business and experts to plan the project. They acquired a Web Billing and Payment process solution from web process consultancy. This provided the process model for web billing and payment. It also provided the organisational model and an indication of staff roles and staffing levels. 4. Information, Applications and Systems Integration Requirements - The The web process consultancy were able to advise on the sources of application solutions. The systems analysts were able to follow up and verify them. They used the current information and application architectures to identify the changes needed to be made to existing applications for the required system integration. 5. Infrastructure Requirements Once the application solution had been selected it was a matter or ensuring that the Application and the infrastructure could be developed to meet the business service requirements for availability, performance, security, operability, supportability, continuity and recoverability. 6. Organisation and Infrastructure Requirements In the same way that needed to meet service delivery requirements so did the business organisation and infrastructure, and so the availability, performance, security, supportability, continuity aspects of the business organisation, its locations and the office infrastructure was determined. Alignment using the Calendar The strategy work had already identified potential solutions to different parts of the value chain. These were investigated in further detail and confirmed or revised in the first stage of the project. This first stage involved: 1. The Service Requirements had been identified by investigating other companies approach to web billing and payment. The business service requirements identified the services needed to be provided by Ajax and created Ajax s Billing and Payment Service Catalogue. 2. The Service Requirements were identified in parallel from the same investigation process identifying the Services that were needed to be provided and created an Billing and Service Catalogue which defined what functionality and service was needed from. This was very different from the pure functional approach which provides a Functional Catalogue because it focused on the Resulting Services 3. The Process and Organisational Requirements - Ajax had a Chief Process Officer who reported alongside the CIO to the board. He directed a specialist Process Management team who were responsible for the development of top down and end to end processes. It was their responsibility to determine the business processes that were needed to support the highly automated business service. The working of the first stage is illustrated in the following diagram which lays out the Governance Framework, from business and strategy to business and service delivery aligning the Domains. It illustrates how the Governance framework is executed over time laid on top of the business s fiscal calendar. Calendar Alignment of UPF Governance and For the IBAP Project within the CRM2 Programme The Governance Strategy Management Plan Management Portfolio Management CRM2 Programme Management IBAP Project Management IBAP Project Stage Mngment. Readiness & Release Mngment. The Market Management Process Management People Management Service Management Infrastructure Management C:\data\ba\documentation\gibert\Computing & Service Talk 4.doc Shared with itsmf, ba and Computing IBAP Stage Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Readiness and Release Governance Sep Oct Nov Dec Figure 7 The diagram illustrates how the various stages of the project are progressed and controlled by the Readiness and Release Governance process.

5 Change inevitably leads to problems and to potential loss of service to customers. A stable business without change experiences few problems. The whole of the development process creates change, - a large amount of change to services and to the people, process and technology capabilities that deliver those services. Ajax knew that requirements that are not understood at the beginning of projects are difficult and expensive to add later. As a consequence an important aspect of Governance to Ajax within the Develop governance framework, was Readiness and Release Management. Readiness and Release Management is exercised during project development at project stage boundaries in the form of quality gates to ensure that projects are: Going to Release a complete and manageable solution, one that met all the value chain requirements listed previously. Going to make Ready all parts of and Delivery, ensuring the necessary resources, skills, tools and processes to deliver and support the new services are going to be in place. Formal testing took place at each of the project stage boundaries to ensure that the solution was likely to be complete and that the organisation was being prepared to be ready to operate and support the solution Policies and Guidelines Each of the value chains provided policies, guidelines and standards in line with the current business and strategy. These complimented the requirements. This enabled projects to know what was expected of them. Projects could then be effective in delivering what the value chains needed, for the value chains to operate and support in the final area of the Governance Framework Delivery. For Ajax, the policies, guidelines and standards were under quarterly review under Strategy Governance to ensure they supported the current Overall Strategy and reflected their current Strategy. Ajax s UPF Polices Steer Projects and enable Readiness & Release Outcome External Finance Market & Customer Management Product & Service Management Process Management Portfolio & Project Management Readiness & Release Management Information Management Organisation Management Infrastructure Management Service Management Infrastructure Management Supplier Management Finance Management Operational Delivery Management The diagram above illustrates the linkages of policies: 1. From Strategy in delivering policies to Development Projects. 2. From Readiness and Release to control the delivery from Projects into Delivery. The outcome for the IBAP project from a Customer Service viewpoint, was that the business services provided what the customers were looking for. Marketing and Sales were successful and the business reached its target customer volumes. The business processes ran smoothly, people were well organised and accepted the change in working practices. The technology worked well for the staff as well as for Ajax s customers who used many of the services directly. The business ran at the planned low cost of operation and delivery management were happy to operate with the revised manner. Delivery Governance The outcome for the IBAP project from an Service viewpoint, was that the services delivered what the business needed a smooth transition from Development into Delivery. The Services provided effective application functionality, excellent performance, the required availability and continuity provisions, effective security, high level of operational automation and system management automation, easy support and maintenance of mostly standard infrastructure, all resulting in low cost of operation and ownership and happy management and relaxed staff. With the implementation of the programme there were the operational budgets and resources to operate the revised business for a projected three year period based upon a demand and capacity plan. The UPF framework made sure that the effect of business development plans were reflected in the business operational plans budgets and resources. All outstanding development issues and less desirable features of the solution were documented and made visible to the service delivery functions so the help desk were able to comment on Known Issues and Known Features with advice documented in the projects as to how to use or workaround them. They did not have to treat them as incidents and waste time investigating what was already known in the development world. All business components developed or changed by the projects were delivered into the business wide CMDB so that business information on its products, customer services, business processes, business functions and business locations were as visible as the components of services, applications, infrastructure, data flows and databases. Figure 8 1. Strategic Policies 2. Assurance of Policy Adherence C:\data\ba\documentation\gibert\Computing & Service Talk 4.doc Shared with itsmf, ba and Computing

6 More importantly was the outcome for the IBAP project from an overall business viewpoint. There was a smooth transition into delivery of the new business services and capabilities with effective marketing that ensured significant adoption of the new web enables services by customers. processes and organisation were optimised to reduce costs of the call, billing and sales centres which were able to scale down. The CRM2 programme had an effective first project with IBAP. UPF had provided the Governance Framework needed for Direction and Development to ensure smooth Delivery. The Way Forward The fifth article will examine the Support and Enabling Domains. These will reveal how the common processes that underlie what people do in the Domains are shared across the Domains and provide a common support approach to running the enterprise. The sixth article will show how can move forward from being individual domain/ framework driven and how can improve, in a very pragmatic manner the interfaces between its existing frameworks like IL and PRINCE2, to integrate them practically into one aligned Unified Process Framework. For more information on the itsmf and its UK November 2003 conference, contact service@itsmf.com For more information on ba and their alignment programme and planned seminars on this subject, in Q across the UK contact support@bitacenter.com or look up their web site For more information on UPF, UPF Master Classes and the UPF Handbook, contact the author of this article J.Gibert@btopenworld.com Copyright Statement Please note these articles are the copyright of Southcourt Ltd. Companies are licensed to copy and use them as long as they acknowledge Southcourt as the copyright holders and reproduce this license to copy and use in any documentation they produce. C:\data\ba\documentation\gibert\Computing & Service Talk 4.doc Shared with itsmf, ba and Computing