Innovative Business Process Design

April 2011 Editorial . . . . . . . . . . . . . . . . . . . . . . 2 The Parallel Universe Syndrome Practice Guide . . . . . . . . . . . . . . . . .3 Beware the New Silos! There are six primary disciplines involved in business improvement – Business Architecture, Enterprise Architecture, Business Process Management, Business Capability Management, Service Oriented Application Modernization and IT Service Management. In many enterprises the level of coordination between the disciplines is inadequate resulting in silos which deliver suboptimal results for the enterprise. In this report we explore the issues and propose a governance based approach to balancing responsibilities, accountabilities and managing conflicts and maturity. By David Sprott Practice Guide . . . . . . . . . . . . . . . .18 Innovative Business Process Design In previous reports we have advised on approaches for modeling for business improvement and the adaptable enterprise. In this report we return to this topic and show by example how enterprises are innovating in their process design to deliver significant improvements in customer experience. They do this by going beyond basic process modeling with capability models for organizational intelligence. We show by example how this model provides an integrating framework for implementing a broad range of organizational and technological initiatives. By Richard Veryard Independent Guidance for Service Architecture and Engineering Editorial –The Parallel Universe Syndrome Disciplines are inward looking, they have their own language, industry standards, specialists, champions, culture and sponsors. What’s needed is a cross discipline governance system that allows these parallel universes to continue in splendid isolation but with minimum necessary dependencies between disciplines defined and governed. I have become increasingly concerned that in the typical enterprise the major business improvement disciplines operate to some extent as silos. EA is often disconnected from Business Architecture. BPM is frequently not well connected with EA and Application Modernization. Governance is commonly applied at discipline level rather than being coordinated across discipline. The term Parallel Universe comes to mind in which a hypothetical self-contained separate reality coexists with one's own. Although strictly we should refer to this as a Multiverse, let’s not get too technical. Think about it for a moment; disciplines are inward looking, they have their own language, industry standards, specialists, champions, culture and sponsors. In fact they have a significant critical mass of their own. Furthermore we can observe standards bodies for the various disciplines expanding their scope to encroach on the natural space of other disciplines, instead of establishing agreed boundaries and coordination mechanisms. Figure 1 – Example BPM Framework (Source BP Trends) In the BPM world there appears to be a profusion of frameworks, all of which cover similar ground, but no real convergence. I particularly liked the framework recently published by BP Trends shown below as Figure 1. This illustrates the point perfectly – this is centered on the BPM discipline, with a nod towards Business Architecture, and various IT and HR stuff along the way. CBDI Journal © Everware-CBDI Inc. April 2011 Page 2 Other disciplines have equivalent frameworks, and they are similarly discipline centric. No surprise here. They all use different perspectives to manage dimensions of a common business objective. The issue is that all these frameworks need to work in a coordinated, networked manner. But in addition to the culture, language and other areas of difference mentioned above, they operate on different life cycles and timescales in a concurrent but often conflicting manner frequently with very fragmentary coordination. I don’t believe we need yet another framework to address this question. There are a huge number of possible dependencies and interfaces, and given the heterogeneous nature of the overall business improvement environment, it seems preferable to encourage outcomes not techniques. What I propose is that because governance is typically exerted for each discipline, what’s required is a set of governance review criteria for each discipline that raises the key questions that allows the organization to monitor and govern across discipline. In this month’s Journal I have introduced such a cross discipline governance system. I have suggested a simple approach which extends the widely used COBIT governance framework. There’s no attempt to say “how” the disciplines should work together; simply to focus attention on the outcome for the collaboration to ensure that appropriate coordination is considered. In this way the parallel universes can continue in relative isolation but with minimum necessary dependencies. David Sprott, Everware-CBDI, April 2011 Everware-CBDI – Specialists in Service Oriented Application Modernization As specialists in service oriented application modernization, we offer a range of consulting services and knowledge-based products to help organizations successfully transition to a business driven, service-oriented information technology portfolio. Checkout the Everware-CBDI web site at: www.everware-cbdi.com CBDI Journal © Everware-CBDI Inc. April 2011 Page 3 Beware the New Silos! A governance approach to coordinating the disciplines involved in business improvement There are six primary disciplines involved in business improvement – Business Architecture, Enterprise Architecture, Business Process Management, Business Capability Management, Service Oriented Application Modernization and IT Service Management. In many enterprises the level of coordination between the disciplines is inadequate resulting in silos which deliver suboptimal results for the enterprise. In this report we explore the issues and propose a governance based approach to ensuring managed outcomes for the wider enterprise. By David Sprott Introduction Many enterprises are now embracing the BPM discipline. After many years in the doldrums, the BPM market is clearly maturing rapidly. But does “market maturity” necessarily equate to capability maturity? Recently I was speaking with a business process analyst who briefed me on how his company, a medium sized financial services organization, is using a leading BPMS together with a collaboration based tool. He described how they are doing amazing work in the business process layer, but appear to be oblivious to everything else. They have no information architecture, no services or service architecture, no applications and no interest from business or IT management in anything other than delivering business processes. Everything is managed in the one platform and organized in business process silos. He commented, “this is a major train wreck waiting to happen!” Perhaps this is an extreme case, but it serves to highlight a very common problem in the BPM space. But don’t imagine that BPM is unique. After many years of strategic commitment to SOA without effective governance, it is clear that SOA is now mainstream for many enterprises, a mandatory architecture pattern and technology for all projects and programs. But interpretations of SOA vary widely and it’s extremely common to see services implemented as next generation enterprise application integration, with minimal business based service architecture. Similarly many enterprises struggle to find the right role for Enterprise Architecture. The continuing debate about “what is the purpose of EA?” demonstrates that there is profound lack of understanding or agreement throughout industry. One well known bank set up an EA responsibility, but after a few months it was clear that business pressure for solution delivery programs simply overwhelmed the EA effort which in the end was reduced to a bit part player on the governance board. Is this atypical? I think not. The core issue is that EA as practiced and as articulated in standards is too technology focused and too procedural. And whilst enlightened EA practitioners have promoted the idea of Business Architecture or Business Design as a parallel discipline to EA, in most enterprises the reality is that business architecture and design gets done in business delivery programs. The issue is that each of these primary disciplines is required, but they need to be coordinated to some degree. Most enterprises have business transformation and CBDI Journal © Everware-CBDI Inc. April 2011 Page 4 modernization tasks in process and these require the involvement of all the disciplines if the outcome is going to be materially improved over the status quo. There’s no sense that we require an umbrella “framework”. I suspect we have sufficient frameworks already. Rather in this report we explore a governance based approach to coordination in which the responsibilities for policy creation and compliance plus inter discipline dependencies form a minimum necessary structure for ensuring the right questions are asked, and there is clear understanding on a case by case basis of the risk and lost opportunity which may result from isolationist strategies. Landscape View ARCHITECTURE Enterprise Architecture (EA) Business Architecture Business Capability Management (BCM) Business Process Management (BPM) BUSINESS MODERNIZATION Application Modernization (AM) IT Service Management (ITSM) IT MODERNIZATION Figure 1: Disciplines in the Landscape If you have just one, isolated business process to improve or a single legacy application to modernize, you don’t need to read further. But, if like most enterprises you have a hugely complex landscape of business processes, services and applications you almost certainly require some coordination across the various disciplines involved. Almost all business improvement and solution delivery is modernization of some existing artifacts. Green field developments in business or IT are extremely rare. Yet the modernization topic doesn’t seem to be a core area of interest even though in most enterprises the existing processes and systems are the only reliable source of knowledge about what the business does. We advise that a modernization context saves time and money because:  It enables a reliable baseline against which improvements can be justified and planned CBDI Journal © Everware-CBDI Inc. April 2011 5   It facilitates incremental, progressive delivery of smaller components that reduce risk and shorten time to market for critical business capabilities It reduces the reinvention of core business knowledge that is central to the way the business operates and thereby reduces risk So, perhaps controversially, we recognize three primary tracks of distinct activity as shown in Figure 1.    Architecture – planning, architecting IT and business, coordinating portfolios and transition Business Improvement – improving business processes, creating common business capabilities IT Modernization – rationalizing the existing application estate as a set of IT services which offer appropriate SLAs for operation and change Tracks Discipline Short Description Architecture Business Architecture (BA) A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands (OMG) Enterprise Architecture (EA) A formal description of a system, or a detailed plan of the system at component level to guide its implementation. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. For a collection of organizations that have common goals. (Open Group) Business Capability Management BCM) A systematic approach to managing stable, shareable business capabilities that enable common behaviors across many business processes. (CBDI) Business Process Management (BPM) A systematic approach to managing an organization's business processes and workflow that enables separation of business process and application behaviors and increases business agility. (CBDI) Application Modernization (AM) A business driven, architecture led, agile process approach to modernizing one or more applications or a portfolio to deliver service oriented solutions and components that can be evolved on a continuous basis in response to changing business needs. (CBDI) IT Service Management (ISTM) The implementation and management of Quality IT Services that meet the needs of the Business. IT Service Management is performed by IT Service Providers through an appropriate mix of people, Process and Information Technology. (ITIL V3) Business Improvement IT Modernization Table 1 – Defining Disciplines CBDI Journal © Everware-CBDI Inc. April 2011 6 Some comments on this landscape perspective:   This should not be viewed as a hierarchical, top down arrangement of disciplines. The reality for most enterprises is that increasingly BPM projects drive business modernization. The other disciplines try to respond. Readers will quickly spot that SOA is missing. Of course SOA is not a discipline in its own right. SOA is an architecture style and pattern and View. So it will be an integral perspective of the Business Architecture, and the Enterprise Architecture. Similarly SOA will guide the efforts of BCM and BPM. And SOA will be the underlying structure for AM and ITSM. Figure 2 below illustrates. BA Planned  EA  BCM  BPM  AM  ITSM  Specified     Being Provisioned             Provisioned Certified  Published  Operational Retired   Archived         Figure 2 – Disciplines in the Service Life Cycle We recommend that Business Architecture and Enterprise Architecture should be separate disciplines. Whilst it is perfectly reasonable for the EA structure to include business process models the EA (at least) as defined in the TOGAF standard is insufficiently rich to articulate the business context to inform the other disciplines. BCM is one of the most important aspects of modernization planning that facilitates cross cutting capabilities which can provide standardization of business process behaviors across multiple value chains and business processes. Arguably BCM will kick in at higher levels of BPM maturity, but our recommendation is that BPM efforts will deliver far more value to enterprises if they embrace coordination and collaboration as early as possible in their capability maturity model. The term AM is widely used but frequently refers to conventional legacy reengineering; often a technology centric activity. At CBDI we use Service Oriented Application Modernization (SOAM) to better describe business driven AM. The overwhelming majority of BPM projects require service enablement CBDI Journal © Everware-CBDI Inc. April 2011 7  of legacy and other back end applications which frequently generate demand for minimalist, façade based application modernization for specific BPM projects. But the façade approach is almost certainly not a long term solution. The objective of the AM discipline should be to facilitate service enablement of applications that separates business process behaviors from applications in an architected manner that enables the application portfolio to support common, consistent service support to all BPM projects and to be able to continuously evolve to support the inevitable demand for change from the business process layer. If you are still persisting with conventional legacy reengineering it’s time to look at AM. Information Technology Service Management and ITIL are de facto practices across the industry. The ITSM discipline is well placed to effect modernization of the provided IT service. Today the industry solution is typically Cloud deployment, and it would be easy to say that all we need is a Cloud deployment modernization discipline. But as most larger enterprises are discovering the reality of future deployment architectures will be multi dimensional. A Governance Based approach In most organizations the relationships between the various disciplines in general, let alone individual project instances, are commonly tenuous. The IBM Red Book exploring just the relationships between EA and BPM1 refers to tribes! That summarizes the problem rather well. The Red Book pursues the relatively simple relationship between EA and BPM in a conventional manner defining all the various deliverables that link modeling systems. I am however more than a little skeptical that it will solve the primary issues between the two disciplines because it is narrowly focused and mechanistic. Figure 3 – Interrelationships Between COBIT Components (Source IT Governance Institute) CBDI Journal © Everware-CBDI Inc. April 2011 8 In my report on the COBIT Framework2 last year I outlined how the highly generic COBIT framework could be used to govern SOA based solution architecture and delivery, and provided extensions to the meta model and classification system. One aspect of COBIT that I found very useful was the relationships between Business Goals and Control Objectives shown in Figure 3 below. To coordinate the various disciplines involved in business architecture and modernization I recommend a governance approach in which the key Control Objectives for each discipline that support integrity of inter discipline relationships are the basis for ensuring integrity of the overall coordination. The Control Objective is a governance review criteria. In project practice this will be supported by detailed deliverables, but we don’t need to itemize these in order to show all the dependencies between the disciplines. This provides us with a meaningful and communicable view of cross discipline interrelationships. To manage the governance process the incremental Control Objectives can be added to existing Control Objectives and managed through existing governance practice. The governance reviews need to be executed on a discipline by discipline basis triggered by discipline / phase activity. Using and extending the COBIT framework for our purposes will, in many enterprises, be seen as very supportive of existing governance practices and reduce friction in the areas of adopting new governance criteria. Control Objectives In this section I set out Control Objectives for each of the Disciplines discussed above. For each discipline I outline business goals that should drive inter discipline relationships. I then map key Control Objectives that govern inter discipline relationships and show examples, plus coordination requirements. I don’t pretend this is exhaustive, but hopefully it’s a good template and starting point. The interrelationship aspect is crucial to governance across the disciplines. The intent is that the Control Objectives form key governance criteria for each discipline that, together with the identified coordination with other discipline(s) provides a coherent approach that should optimize the enterprise view in the most efficient manner. Discipline: Business Architecture Control Objectives that can be utilized regardless of how the disciplines are organized, with BA as part of EA or standalone. Business goals relevant to BA cross discipline control might address:    Adequacy of business strategy Business standardization – goals that rely on consistent business process and information such as customer satisfaction, cross channel behaviors, competitive business intelligence and so forth. And conversely . . . Business diversity – goals that rely upon freedom of action in innovation areas, loosely coupled parts of the business that are perhaps candidates for divestiture as well as cash cows where business improvement is low priority. CBDI Journal © Everware-CBDI Inc. April 2011 9  Business morphology – goals that influence the structure and shape of business. Strongly linked to business loose coupling, these goals may relate to business components that may be more easily outsourced, or capabilities that deliver cross division, LoB and geography to achieve goals such as regulatory compliance or centralization to achieve reduction in headcount or costs. Control Objective Type Examples Coordination required Business strategy is articulated sufficient to guide primary delivery projects and programs Context business components will be outsourced Architectural response by EA Core business components will be enterprise standard Project goals, scope and strategy response by BPM and AM projects ITSM response on scope of IT services Standardized business model components modeled and defined Consistent behaviors for certain business types Policy governing implementation approach defined in EA and complied with by BPM, AM and ITSM Standalone business capabilities identified Candidate for outsourcing and or offshoring Policy governing implementation approach defined in EA and complied with by BCM and BPM implemented in AM and ITSM Candidate for replication for scalability or risk reduction Compliance requirements defined for (industry standard) semantics Support for partner ecosystem and or channel strategy EA defines information and or transformation architecture Business process standardization Compliance with defined aspects of Information Architecture by BPM, BCM, AM Key KPIs defined for major processes (value chains) Number of complaints Architecture and design response from BCM, BPM Average <claim, trade, . .> handling cost % add-on business Service architecture and design response from AM including schema support SLA response from ITSM Table 2 – Example BA Control Objectives Discipline: Enterprise Architecture In most enterprises EA is responsible for determining the enterprise context for solution and BPM delivery projects and managing the portfolio view. This means setting policies for architecture work, establishing reference architecture and identifying those elements of all architecture views that are enterprise standards such as capability and core business services, technology and deployment components and so forth. CBDI Journal © Everware-CBDI Inc. April 2011 10 Whilst EA will typically establish requirements for architecture governance, in a cross discipline environment it is also important that the other disciplines accept the enterprise policies and architecture as relevant to discipline delivery. A governance forum is an appropriate mechanism to improve coordination between EA and the other disciplines. The business goals relevant to cross discipline EA Control Objectives may include:   Prioritized focus on principles that support key business strategies  Alignment of IT services with strategic business context    Loose coupled business Establishing architecture that enables continuous evolution of business capability with appropriate response time to defined classes of change by domain Business sourcing strategy Conformance with specific business governance requirements, such as business security and threat containment, regulatory requirements, knowledge and intellectual property management, management of third party relationships etc. Control Objective Type Examples Coordination required Architecture principles reflect business strategy needs Services and components will map to key business concepts that support consistent behaviors for mission critical, core business processes across all channels, LoB and geographies. Alignment between BA and EA Compliance by all disciplines Common enterprise data and information architecture supporting above. Evolutionary architecture in support of innovating business processes. Reference model and architecture establishes consistency of approach and reusability of standard components relative to a) strategic business context b) type of sourcing Component types by layer for logical, implementation, technology and deployment architecture mapped to strategic grid Reference business process architecture mapped to strategic grid Development of EA overlays to support specific business and sourcing contexts as requested by BA/BPM/AM Compliance by BPM, BCM, AM and ITSM Contract formats for services, components and IT services. CBDI Journal © Everware-CBDI Inc. April 2011 11 Control Objective Type Examples Coordination required Key planning and architecture policies approved Architecture layer patterns Compliance by BPM, BCM, AM and ITSM Commoditization patterns Sourcing Type by layer and component Architecture governance process defined Architecture and delivery phase end deliverable templates Compliance by BPM, BCM, AM and ITSM Common enterprise service architecture contracts mirror business contracts Orders Capability Service is a business service and a technical interface Alignment with BA, BCM and BPM Common enterprise component architecture meets objectives for loose coupled Business Types Alignment with BA, BCM and BPM Information and Semantic Architecture Common application platform architecture for various layers Conformance by AM and ITSM Compliance by BPM and BCM Implementation and compliance by AM and ITSM Service exception architecture Common Technology Architecture Common Security Architecture Enterprise portfolio and transition plan supports business priorities for continuous business evolution Service Portfolio Plan Aligned with BA priorities Transition Engineering Plan In conjunction with ITSM Change SLAs Continuous feedback of portfolio asset status from BPM, BCM, AM, ITSM Table 3 – Example EA Control Objectives Discipline: Business Process Management As discussed, whilst BPM projects are generally the primary drivers for business improvement, they need to be coordinated with all other disciplines. The business goals relevant to cross discipline BPM Control Objectives may include:     End to end business processes or cross ecosystem business processes Support for radical changes in business model(s) and new KPIs Process improvement including increased productivity and quality of service, lower operating costs and faster cycle times Improve ongoing flexibility of business processes CBDI Journal © Everware-CBDI Inc. April 2011 12 Control Objective Type Examples Coordination required Business process explicitly supports business strategy Business process supports new business model with new KPIs Alignment with BA Business process is part of a coherent process portfolio Business processes not confined to existing organization structure Between BPM projects to establish interaction and interfacing BPM projects collaborate in delivering consistent end to end business process support With BA for cross functional perspective With EA to ensure use of common reference architecture and components Business process reuses standard elements – business process components and business capabilities as appropriate Common Ordering Process capability used across many lines of business and geographies With EA to signal demand for common components and to feedback asset reuse Business process is designed to continuously evolve to meet demands of changing business Managed dependencies limit horizon of change With BA to drive out future perspectives Componentized business process design With EA to develop agile architecture, generic components, customizing platforms etc Strict enforcement of BPM architecture layering Generic designs where appropriate With ITSM to reuse standard IT services With EA to minimize dependencies With AM to commission generalized, constantly evolving services and to minimize change cycle time With ITSM to establish contracts for IT Service change cycle time Business process reuses standard enterprise services Common customer service enforces common behaviors across all customer contacts throughout all business processes With BA to understand strategy for consistent business process behaviors With EA to signal demand for standard service or feedback asset reuse With EA to develop platform strategies for embedding consistent behaviors into processes and concurrently enabling localization With AM to enable reuse and potentially to evolve standard service and or introduce localization CBDI Journal © Everware-CBDI Inc. April 2011 13 Control Objective Type Examples Coordination required Business process uses common reference process architecture and template. Enterprise standard BPMS practices, technology, templates, components With BA to understand requirements for enterprise consistency or innovation With EA to adopt standard reference process architecture With ITSM for standard SLAs implicit in standard reference architecture Table 4 – Example BPM Control Objectives Discipline: Business Capability Management Business capabilities are generally intended to implement standard behaviors across an enterprise, although it is perfectly possible that certain capabilities may be limited to specific domains, divisions or product groups. There is a natural tension between BCM and BPM insofar as business capabilities will usually encapsulate business process components as well as application functionality. This will require coordination right from the outset in development of the BA such that the embedded processes are clearly demarcated from other free standing business processes. The business goals relevant to cross discipline BCM Control Objectives may include:      Segregating context behaviors for use of a standard COTS package Segregating context behaviors for use of a BPO Segregating core or context behaviors with standalone deployment for outsourcing and or cloud deployment Standard capability behavior is mandatory Standard capability behavior is mandatory but localization by extension is encouraged to meet situation specific behavior needs. Control Objective Type Examples Coordination required Business capabilities are designed to be extended for local behaviors whilst maintaining the integrity of standard enterprise behaviors. Customer support capability facilitates extension for varying product group requirements Compliance with common capability behaviors defined in the BA Business Capabilities are enterprise standards Customer, Risk, Regulatory Compliance, Customer Support, Authentication . . . Embedded business process components defined in the BA to ensure separation from free standing business processes Coordination with EA policy on capability extension platform stack Architecture defined in EA AM provides standard interface contract Standard ITSM SLA CBDI Journal © Everware-CBDI Inc. April 2011 14 Control Objective Type Examples Coordination required Business Capabilities are genuinely standalone Manufacturing capability encapsulates all layers of stack including business process, application and technology. Deployment architecture is to Cloud with explicit agreements that facilitate rehosting Coordination with AM and ITSM to ensure minimum necessary dependencies Capability behavior is encapsulated. Communications with offered capability services are entirely through the capability service interface. All physical attributes and behaviors are hidden from consumer. ITSM to cover technology and manual activities and resources Capabilities are single business functions (or components) that may be assembled into composite applications or business processes. Shipment capability may be composed into Orders to Cash. Defined in EA Coordination with BPM for business process design. Coordination with AM for composite delivery Coordination with ITSM for composite SLA Table 5 – Example BCM Control Objectives Discipline: Application Modernization The key feature of AM is the transformation of the application portfolio to a set of components and services that will facilitate continuous evolution. Smaller units of deployment that map well onto the service architecture and by inference business components. The business goals relevant to cross discipline AM Control Objectives may include:    Reduce unit cost of delivery Ensure service can meets business needs for response to change by continuous evolution Retention of business knowledge Control Objective Type Examples Coordination required Solutions deliver services for specific solution(s) but within enterprise framework Retail channel specific Customer service is designed to be evolved over several iterations to support multiple channel behaviors. Coordination with EA and BA for vision of endpoint goal for generic, differentiated service. Where relevant ensure stability of business model by With BA to understand where Leverage and protect existing CBDI Journal © Everware-CBDI Inc. April 2011 Coordination with ITSM for version availability 15 Control Objective Type Examples Coordination required business knowledge reusing existing knowledge business model is changing Deliver comprehensive knowledge together with solution and services With EA to align with new information architecture With BA to align with business process rules With ITSM to include knowledge as a key deliverable Modular, portable, cloud ready services and components Solutions, services and components designed to minimize dependencies, reduce deployment horizon where appropriate With EA to align with enterprise technology and deployment architecture With ITSM to establish operational and change SLAs Enable minimum effort to rehost Integrated into service and component portfolio Twin track approach to AM separates out service from solution delivery. Service delivery is usually evolving the Service Portfolio Plan (SPP) With EA to align with SPP, implementation architecture and feedback asset status Deliverables include services, components and solution(s) plus designs and processes for continuous evolution Designed for low horizon of change to enable narrow focus units of deployment. Aligned with BA business components and heat maps for areas of volatility Work Breakdown Structure common to Deliver and Evolve Phases Aligned with Change SLA in ITSM Business capabilities implemented as standalone components and encapsulated services Private stack Coordinated with ITSM for separate deployment and virtualization With ITSM to provide SLAs Table 6 – Example AM Control Objectives Discipline: IT Service Management Service architecture is by definition a contract based environment. A key business goal is generally to establish high levels of separation between component, services and layers of the stack. The AM discipline delivers the technical interfaces; the ITSM manages the usage and life cycle contracts for composite IT services that ensure the goals of separation are achieved at realistic cost. The business goals relevant to cross discipline ITSM Control Objectives may include:   Dynamic reporting of business performance data Faster response to business change CBDI Journal © Everware-CBDI Inc. April 2011 16  Reduced lock-in to suppliers at all levels of the stack Control Objective Type Examples Coordination required SLA reports support KPI requirements Average time and cost to handle claim Alignment between SLA reports and BA, BPM, BCM KPI reporting requirements Delivered IT Services have functional change SLA for relevant granularity components Services classified for functional change (upgrade) response time Change SLAs agreed with consuming BPM, BCM projects Delivered IT Services have non functional change SLA Services classified for non functional change response time. E.g Change SLAs agreed with consuming BPM, BCM projects SLA reports support KPI requirements - scalability - change of host Average time and cost to handle claim Alignment between SLA reports and BA, BPM KPI reporting requirements Table 7 – Example ITSM Control Objectives Summary and Conclusions Each of the primary disciplines involved in business improvement have a high internal critical mass which may encourage isolationism. Interrelationships may be competently established on a one to one basis. But if this is done in a tactical manner, the communications will be narrowly focused on deliverable and data exchange, and may ignore the bigger picture. The governance approach outlined in this report, particularly in conjunction with some form of cross discipline governance body, can provide assurance that due diligence has been carried out in delivering optimum outcomes for the wider enterprise. Further this is a lightweight process, with low overheads placed on the disciplines, that can shine spotlights on areas where more attention needs to be given to particular issues. From my observation of numerous corporations and government departments, a cross discipline governance system is badly needed, and in many situations could be rapidly demonstrated as bringing considerable benefit. 1 Reference IBM Red Book – Combining BPM and EA http://www.redbooks.ibm.com/abstracts/sg247947.html?Open 2 Using the COBIT Framework for SOA Governance, CBDI Journal, May 2010 CBDI Journal © Everware-CBDI Inc. April 2011 17 Best Practice Report: Innovative Business Process Design Going beyond basic process modeling for enhanced customer experience In previous reports we have advised on approaches for modeling for business improvement and the adaptable enterprise. In this report we return to this topic and show by example how enterprises are innovating in their process design to deliver significant improvements in customer experience. They do this by going beyond basic process modeling with capability models for organizational intelligence. We show by example how this model provides an integrating framework for implementing a broad range of organizational and technological initiatives. By Richard Veryard We explore examples of how complexity can be managed and show how to give the organization more power to operate effectively in a complex demand environment. Introduction As transaction-oriented IT becomes increasingly commoditized and virtualized, any competitive advantage from IT must come from its support for business innovation and organizational intelligence. In this article, we shall explore how business improvement in today’s world demands innovative business process design. Strategic Advantage and Differentiation There are two important differentiation questions for any organization with critical relationship with external stakeholders (such as customers): how do They differentiate Us, and how do We differentiate Them. Firstly how do They differentiate Us. In other words what differences in our products and services or organization are (a) going to be noticed by external stakeholders such as customers and (b) going to affect the behaviour and attitudes of these stakeholders. Sophisticated marketing organizations pay a lot of attention to this kind of thing. Does it make a difference if we put this in a blue envelope? Does it make a difference if we have a female voice here? Sometimes you have to experiment with differences that don't matter, in order to have a refined view of what differences do matter. So intelligence involves an important feedback loop through Decisions and Learning. Secondly, how do We differentiate Them. What are the strong signals in the environment that we must respond to, and what are the weak signals we might respond to? An organization that responded to every weak signal would be impossibly unstable, so most organizations have operational processes that respond to strong signals, and CBDI Journal © Everware-CBDI Inc. April 2011 Page 18 some form of business intelligence that scans the environment for weak signals and identifies a subset of these signals demanding some kind of response. Differentiation and Context The CBDI Forum identified Differentiated Services as a key pattern of advanced SOA as long ago as 2002. We have looked at a number of dimensions of differentiation, including identity, presence and context, and discussed how businesses in such sectors as retail have created value for themselves and their customers by progressive differentiation. An enterprise may differentiate its customers (and their behavior and intentions) according to a number of factors, with greater or lesser granularity.    Zero variation. No differentiation between customers. One size fits all. Fixed segmentation. The enterprise identifies a number of (fixed) market segments, and assigns each customer to the appropriate segment. Dynamic deconstruction. Differentiation based on the detailed actions and inferred intentions and context of customers. Each degree of differentiation increases the range and scope of supported behaviors, and therefore affects the overall complexity of the process1. Under the right conditions, increased differentiation may produce better outcomes for the enterprise and its customers. Under the wrong conditions, differentiation merely adds complication, increases cost and risk, and may produce worse outcomes. From a business process design point of view, we are searching for different contexts. Understanding the range of contexts is critical for business agility – because each new context introduces some degree of variation (differentiation) that adds value to the process for that context2. Business Intelligence and Differentiation With business intelligence, we have the opportunity to select the most relevant forms of differentiation, based on statistical analysis of characteristic features. In many situations, what the business really wants is to use the past to predict the future. We only want to differentiate customers based on their past buying patterns if this provides a good predictor of their future buying patterns. When I lived in Central London, I sometimes used to visit a hairdresser on the King’s Road in Chelsea, The King’s Road is full of hairdressers, and the staff would stand in the street handing out leaflets to likely customers. When I was walking towards my hairdresser, I would walk past several of these touts, but I wouldn’t be recognized as a potential customer because I didn’t have a smart haircut. After my hair was cut, I would be given loads of leaflets because I then fitted their preconception of what a customer looked like – but of course I didn’t then need a second haircut. This is the kind of stupidity trap that many backward looking sales operations fall into – trying to sell lawnmowers to people that already have lawnmowers. Business intelligence helps us find alternative differentiators. What are the characteristic features of someone who needs a haircut, or might buy a lawnmower? We can then differentiate the services based not on a fixed set of differentiators, but on a current (and periodically updated) set of differentiators, and we constantly review the CBDI Journal © Everware-CBDI Inc. April 2011 Page 19 predictive power of these differentiators. (This means that the underlying business type model now needs to be constructed at the meta level, with DIFFERENTIATOR and CHARACTERISTIC FEATURE as business types.) Retail Example – Amazon In our articles about business modelling, we have described the progressive differentiation that can be observed in certain industries. For example, over the past decade or so, retailers have progressively increased their ability to differentiate customers according to buying history and other contextual information. The introduction of the loyalty card represented a radical strategic shift for the large retail chains. Stores now had a formal basis for recognizing a customer as the same again. They can identify customers, and collect and analyze data about the behavior of specific customers. And they can use this analysis to differentiate the response to different customers. For example, different customers may receive different special offers. Obviously if the retailer can identify the customer as she enters the store, then this differentiation can be done as the customer browses, rather than only when the customer comes to pay. This is relatively easy to implement with online shopping (for example through the use of cookies); and there are various mechanisms (smartphone, face-recognition software, RFID) that might achieve the same result in a physical store if the obvious privacy concerns can be allayed. For example, if there are RFID chips on the goods and RFID scanners on the shelves and in the shopping trolley, then the customer can be presented with information based on the stuff that is already in the shopping basket. This capability is very easy to implement for online shopping, and this stimulates retailers to build an equivalent capability for physical shopping. The service we get from supermarkets is fairly simple, so perhaps there isn't much scope for variation. But each customer may get a different set of special offers, and this can be generated dynamically, according to the contents of the shopping basket or the path through the store. A customer with a known taste for raw eggs, or a history of returning stale products, may get a warning that a selected product is close to expiry. Amazon is of course well-known for its pioneering work in providing targeted information and deals based on a customer’s browsing and buying history, and creating new forms of associative information which may be reflected back to the customer. But even Amazon could possibly go further in differentiating all aspects of the supply chain, in order to maximize value for the customer and for itself. For example, we recently heard a complaint from an Amazon customer about the delivery process that required the customer to pick-up the parcel after failure to deliver, for an item that was actually small enough to slip through the letter-box. In this particular instance, in other words, Amazon seems to have failed to have built sufficient differentiation into its delivery process. (Perhaps we have higher expectations of companies like Amazon: the appalling lack of differentiation we experience from most other service companies is quite scandalous.3) Library Example CBDI Journal © Everware-CBDI Inc. April 2011 Page 20 Some business people think of differentiation purely in terms of targeted advertising. But it is also important to think of ways that an organization can serve its customers better (not just target them better) through an awareness of their context. This is intrinsic differentiation - in other words, differentiation that is relevant to the service in hand. Let us consider libraries. A few years ago, my son did a school project on a mathematician of his choice. He chose Florence Nightingale (the inventor of the pie chart). If he had gone into a library for help, would he have been offered a scholarly history of the Crimean War or an academic thesis about mortality statistics and their graphical representation? Maybe that depends whether he talks to a human librarian or uses the computer. Can a computerized system offer anything approaching the sensitivity and common sense that we still expect from a human librarian? At one extreme, there are standardized search systems, which will give you exactly the same answer whether you are a schoolchild or a BBC researcher or an LSE postgraduate. At the other extreme, there may be inflexible classification systems, which assume that a child is only interested in reading books that are designated suitable for that age group. One of the most important aspects of context is how the service fits into what the consumer (the customer, the library reader) is trying to do. Do I have an essay or article or thesis to write, and when is it due? Am I reading Nietzsche because I am learning German, or because I am learning existentialism (or both)? Am I reading Bede because I am studying history or historians (or both)? Does it make sense to read Locke without also reading Hume? What stage of my learning have I reached? Do I need an edition with glossary, with scholarly notes, with English translation facing? What is my preferred style of learning, my preferred style of researching a topic? Surely questions like these are relevant to improving the service offered by a library to a particular reader? Ultimately, context-awareness takes us down a path of embracing user diversity. Not just user semantics, but user pragmatics. How much of the reader's context can the library possibly deal with, and what other service providers might the library collaborate with? There are some seriously complex models here. Context-awareness introduces some significant challenges to many organizations introducing modes of complexity that they have never dealt with before - but with the potential reward of offering massive improvements to the experienced quality of service. Coordination and Intelligence Effective differentiation is a function of the intelligence embedded within the customer management capability. The greater the “quantity” of intelligence, the greater the capacity to differentiate effectively. See Box below.    Success Factors of Effective Differentiation Focus on the most relevant differentiators. Sufficient range of responses to differentiators. Coordination between variety of perceived differentiation and variety of response. CBDI Journal © Everware-CBDI Inc. April 2011 Page 21    Feedback loops to improve relevance and accuracy of differentiation. Feedback loops to refine responses. Progressive elimination of unnecessary or irrelevant complication, along with exploration of new opportunities. Retail Example – Supermarkets Many organizations are increasingly facing multi-sided markets, and the need to create indirect value as well as direct value. They must differentiate and innovate in a number of different process areas simultaneously. The critical capability here is the coordination between these process areas. Let’s explore this using a retail example. Let’s start by dividing a retail operation into a number of discrete capability areas, each focusing on a discrete domain of interest. Each capability area can then be managed semi-autonomously. Figure 1 – Example Capability Areas in Retail Operations (We may compare alternative ways of decomposing the retail operation according to the independence of each chunk, and how much coordination is required. Any given decomposition leaves some cross-cutting concerns. Many architects skip this step, and base their models uncritically on the most obvious decomposition, without exploring alternatives.) Within each capability area, we have a potential trade-off between the economics of scale and the economics of scope. For example, simple economics of scale within product management suggest stocking large quantities of a very small number of products from a small number of suppliers to obtain maximum discounts and minimum transport costs. However, this conflicts with the need within product management to offer a broad range of products (economics of scope). There are also trade-offs between capability areas. For example, a simplistic approach to the economics of scale within product management will conflict with a simplistic CBDI Journal © Everware-CBDI Inc. April 2011 Page 22 approach to the economics of scale within store management. In practice, it is impossible to optimize all these economic factors simultaneously. So we need a coordination mechanism that allows for a reasonable accommodation between these semi-autonomous areas, illustrated in Figure 2, as well as a sense of the economic and organizational cost of this coordination. For example, suppose a supply-side manager negotiates a deal with a key supplier, which specifies a favourable display position for that supplier’s products. This deal may then inhibit our ability to vary the display arrangements, even if this variation could improve the customer experience and increase total spending. Most importantly, if we fail to experiment regularly with alternative display arrangements, we won’t have enough data to calculate the true value of a given display arrangement, and therefore to estimate whether a given supply-side deal carries an unacceptable opportunity cost (in terms of lost sales for other products). Figure 2 – Coordinating Semi Autonomous Capability Areas    Design Questions What are the events and information flows that help to join up the retail operation as a whole? Where is the strategic knowledge of the enterprise located, and how is it continuously developed and effectively used? What are the mechanisms to support innovation and organizational learning? There are many different pathways for joining-up the business. Think for example how a supermarket manages a single product – a jar of organic baby food. This product has many different associations, each of which has some coordination and integration implications as shown in the Table below. Coordination with other jars (pasta sauce) Often supplied by the same manufacturers. Similar patterns of shelf life and shelf management. Similar handling requirements. CBDI Journal © Everware-CBDI Inc. April 2011 Page 23 Coordination with other baby goods Bought by the same customers. Coordination with other organic produce Bought by the same customer demographic. Table 1 – Example Product Associations Requiring Coordination How are these different associations managed? The traditional approach is to regard one of these associations as primary, and to construct processes and hierarchical organization structures around the primary association – for example, product line management. Some organizations complicate this approach by attempting various forms of matrix management, but this is typically an unsatisfactory compromise that still fails to deal with all the associations and pathways properly. Furthermore, when these associations are hard-coded into the organization structure, even tactical change in product management necessitates major organizational change – and there are some organizations that undergo this kind of reorganization alarmingly frequently. An adaptable enterprise needs to have a more dynamic way of managing a broad range of these associations and pathways. Each of these pathways may be associated with a different capability area, and mobilizes a different kind of intelligence. Systems, Services and Technology There are several technologies that help to support the intelligent real-time enterprise, including business intelligence, complex event processing, business process management, knowledge management and enterprise social networking (“Enterprise 2.0”). Within the enterprise, these technologies are typically at different stages of adoption and maturity, and there are interesting developments within each area. The key question for us here is how these technologies and tools can be combined to solve more interesting and complex business problems. In our work on service-oriented business intelligence, we have talked about closed-loop business intelligence – management feedback loops that operate at real-time or nearreal-time. We are already seeing an interesting convergence between business intelligence and complex event processing. Figure 3 – Closed Loop Business Intelligence Model CBDI Journal © Everware-CBDI Inc. April 2011 Page 24 Much of the experience with Complex Event Processing (CEP) tools has been in tracking real-time operations. For example, telecommunications companies such as Vodafone can use complex event processing to monitor and control service disruptions. This is a critical business concern for these companies, as service disruptions have a strong influence on customer satisfaction and churn. CEP is also used for autodetecting various kinds of process anomalies, from manufacturing defects to fraud. When coordinating between different business processes, each process may operate on a completely different tempo. With customer complaints, for example, replying to the customer is either instant or within hours/days (and a product recall for safety reasons would probably operate on a similar tempo), whereas the feedback loop into product design probably takes weeks or months - in other words, a much slower tempo. Business Process Management itself has several nested feedback loops, each operating at a different tempo.    A modeling and discovery tempo, in which the essential and variable elements of the process are worked out. Oftentimes, full discovery of a complex process involves a degree of trial and error. An optimization and fine-tuning tempo, using business intelligence and analytics and simulation tools to refine decisions and actions, and improve business outcomes. An execution tempo, which applies (and possibly customizes) the process to specific cases. The events detected by CEP can then be passed into the BPM arena, where they are used to trigger various workflows and manual processes. This is one of the ways in which CEP and BPM can be integrated. Social software and Enterprise 2.0 can also operate at different tempi - from a rapid and goal-directed navigation of the social network within the organization to a free-ranging and unplanned exploration of business opportunities and threats. Social networking platforms (such as TIBCO's new product tibbr®4) can be organized around topics, allowing and encouraging people to develop and share clusters of ideas and knowledge and experience. The organization of Enterprise 2.0 around topics appears to provide one possible way of linking with CEP and BPM. A particularly difficult or puzzling event (for example, a recurrent manufacturing problem) can become a topic for open discussion (involving many different kinds of knowledge), leading to a coordinated response. The discussion is then distilled into a resource for solving similar problems in future. A critical success factor for organizational intelligence is "contextually relevant information", and this provides a common theme across all of these technologies. It helps to think about the different tempi here. In the short term, what counts as "contextually relevant" is predetermined, enabling critical business processes and automatic controls to be operated efficiently and effectively. In the longer term, we expect a range of feedback loops capable of extending and refining what counts as "contextually relevant".  On the one hand, weak signals can be detected and incorporated into routine business processes. Wide-ranging discussion via Enterprise 2.0 can help identify such weak signals. CBDI Journal © Everware-CBDI Inc. April 2011 Page 25  On the other hand, statistical analysis of decisions can determine how much of the available information is actually being used. Where a particular item of information appears to have no influence on business decisions, its contextual relevance might need to be reassessed. CBDI Journal © Everware-CBDI Inc. April 2011 Page 26 Social Media (Systems of Engagement) Recent work in the Content Management domain distinguishes between Systems of Record (focused on transactions) and Systems of Engagement (focused on interactions). In a recent white paper Systems of Engagement and The Future of Enterprise IT : A Sea Change in Enterprise IT (AIIM 2011), Geoffrey Moore identifies this as a major shift of emphasis in IT. According to Moore, this shift is necessary because most organizations are dependent upon suppliers or distributors or partners to deliver their fundamental value proposition to their customers. (Of course, these challenges aren't just for commercial organizations. Public sector organizations are under just as much pressure to deliver value, even if this pressure is transmitted politically rather than commercially.) They also raise key architectural issues, especially in managing the join between formal systems and informal systems. For example, enterprise social media can be organized around business topics. The particularly difficult or puzzling example event mentioned above (the recurrent manufacturing problem) is a good example of this. The discussion around the topic leading to the coordinated response may be distilled into a resource for solving similar problems in future. A business topic can be modeled as a social object5efficient and effective integration between transaction systems (Systems of Record) and intelligence systems (including Systems of Engagement) requires a simple and flexible model of such social objects, and a clear understanding of the identification and granularity of these objects. Conclusion and Key Actions In this article, we have explored how complexity is (can be) managed in a real business. The agenda here is not to eliminate complexity but to respect and leverage it – giving the organization more power to operate effectively in a complex demanding environment. For improving organizational intelligence, there are several key actions for architects, as shown in Table 2 below. Aspect Purpose Artefact Granularity Enabling the organization to identify more precisely and respond more flexibly and appropriately to a finer level of detail and differentiation. Business Concept Model Sense and Respond Defining the set of events that the business processes can respond to. Event Model Feedback Loops Building a closed improvement and learning loop into each business process. Business Process Model Coordination Establishing coordination and intelligence capabilities between multiple strategic processes. Business Capability Model Platform Establishing a joined-up platform (including business intelligence, business process management, knowledge management and social networking) to enable managers across the organization to collaborate and innovate effectively. Technology Architecture Business Type Model Business Process Model Table 2 – Key Actions for Architects CBDI Journal © Everware-CBDI Inc. April 2011 Page 27 References Some of the ideas presented in this article have been mentioned in previous articles.         Business Flexibility (CBDI Journal, June 2002) Web Services to improve Business Intelligence (CBDI Journal, June 2003) Service-Based Business – Insurance 2 (CBDI Journal, December 2004) Service-Oriented Business Intelligence (CBDI Journal, October 2005) Business Modeling for SOA (CBDI Journal, January 2006) Towards the Agile Business Process (CBDI Journal, July 2007) Web 2.0 and Enterprise Architecture (CBDI Journal, November 2007) Event-Driven Service Architecture (CBDI Journal, February 2008) 1 Process complexity informally measures the difficulty of describing and executing a process. See for example Howard, Rolland and Qusaibaty, Process Complexity, INFOS 2004. http://www.cs.rmit.edu.au/~jah/cats09/papers/cats2009_submission_41.pdf 2 The ability of a system to respond appropriately and flexibly to the variety in the demand environment is known as requisite variety. The greater the complexity and turbulence of the environment, the greater the value of this variety. The challenge for the enterprise is to manage this variety efficiently, and to focus on those variables that have the greatest potential contribution to business value. 3 See my review of the Support Economy, CBDI Journal July 2004. Also available at http://rvsoapbox.blogspot.com/2005/01/support-economy.htm 4 Tibbr® http://www.tibbr.com/ 5 The concept of social object was introduced by Jyri Engeström, and has been developed by JP Rangaswami and others. CBDI Journal © Everware-CBDI Inc. April 2011 Page 28 About CBDI CBDI Forum is the Everware-CBDI research capability and portal providing independent guidance on best practice in service oriented architecture and application modernization. Working with F5000 enterprises and governments the CBDI Research Team is progressively developing structured methodology and reference architecture for all aspects of SOA. CBDI Products The CBDI Journal is freely available to registered members. Published quarterly, it provides in-depth treatment of key practice issues for all roles and disciplines involved in planning, architecting, managing and delivering business solutions. Visit www.cbdiforum.com to register. Platinum subscription – A CBDI Forum subscription provides an enterprise or individual with access to the CBDI-SAE Knowledgebase for SOA delivering ongoing practice research, guidance materials, eLearning, tools, templates and other resources. Everware-CBDI Services At Everware-CBDI we enable large enterprises and governments to become more agile by modernizing their business systems. We have repeatable processes, resources, tools and knowledge-based products that enable enterprises to transform their current applications in an efficient, low risk manner, into an optimized service-based solutions portfolio that supports continuous, rapid and low cost evolution. Our consulting services range from providing practices and independent governance to architecture development, solution delivery and service engineering. Contact To find out more, and to discuss your requirements visit www.everware-cbdi.com or call USA and Americas: 703-246-0000 or 888-383-7927 (USA) Europe, Middle East, Africa, Asia, and Australasia: Telephone: +353 (0)28 38073 (Ireland) www.everware-cbdi.com IMPORTANT NOTICE: The information available in CBDI publications and services, irrespective of delivery channel or media is given in good faith and is believed to be reliable. Everware-CBDI Inc. expressly excludes any representation or warranty (express or implied) about the suitability of materials for any particular purpose and excludes to the fullest extent possible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All trademarks and copyrights are recognized and acknowledged. The CBDI Journal may be distributed internally within customer enterprises that have current corporate subscriptions. Otherwise CBDI Journals may not be copied or distributed without written permission from Everware-CBDI. CBDI Journal © Everware-CBDI Inc. April 2011