Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Enterprise Business Architecture in Practice --
Leveraging EBA for Success on Large-Scale CRM/ERP
Implementations




  St...
Disclaimer
     • This presentation stems from an internal project conducted
       within Sun Microsystems prior to Sun's...
Objectives:
     • Demonstrate how Enterprise Business
       Architecture (EBA) can be leveraged to
       increase likel...
Sun Microsystem's “IBIS” Project
   • Believed to be one of the larger CRP/ERM
     implementations ever attempted.
   • M...
Beware!
• Large scale CRM/ERP implementations are HIGH RISK
  undertakings due to:
      > Disruptive Effects on Your Enti...
Key Pitfalls
    • Inability to manage the organizational change necessary
      for success
          > Unclear understan...
Leveraging EBA
      • An Enterprise Business Architecture (EBA) provides
        a customer-centric and holistic view of ...
The Change is LARGER
          Than You Think!
                 ● Metrics targeted for improvement
 The change      ● Appl...
Managing Organizational Change
    Managing organizational change requires knowing
     where you are, where you want to b...
The reality at most organizations




                 Transition             Transition
                              Kee...
Knowing Where You Are
   • Why Model “As-Is” state?
        > Helps identify opportunities for improvement
        > Helps...
1
What's an Enterprise Business Architecture ?
• A single common Enterprise-Wide framework that focuses on how
  value is ...
Building The Enterprise Business
     Architecture
     • The EBA is rigorously derived via an integrated
       set of mo...
EBA Enterprise Entity View is “Outside In”
                                                                           “Ext...
Value Stream Group View
                                                   Customer



                               C   ...
Value Stream Architecture View
                                                          Customer


                      ...
Example Data Lexicon
      Product                Install Base                  Service             Contract Level
       ...
Sub-Value Stream Architecture View
                                     Customer
                                         ...
Value Stream & Process Hierarchy
                                                   Value Stream Elements may be organized...
Upper Levels of a Value Stream Hierarchy
                                                                                 ...
Function Hierarchy vs. Value Stream Architecture

    “Function Hierarchies”               Value Stream Architecture
     ...
Knowing Where You Want to Go



                  #1 Reason CRM Initiatives Fail:
                  #1 Reason CRM Initiati...
Clearly Define Success
     • Don't just list the possible benefits, be specific about which
       benefits you are commi...
Example: Value Streams and Metrics
                $                         $                             $


           ...
Leveraging EBA
      • An Enterprise Business Architecture (EBA) Provides
        a customer-centric and holistic view of ...
Organizing Your Program For Agility
   • To be effective, the team members, work activities, and
     information associat...
What's Your Organizing Principle?
Some Candidate        Pro's                        Con's
Organizing Principles
by Applic...
Value Stream Hierarchy is Backbone
     • The upper (architectural) levels of the Value Stream Hierarchy
       are quite ...
Leverage Your Investment
     • Large Scale CRM/ERP projects require you to make a
       significant investment in unders...
Our initial approach to managing this info
      • Via hundreds (literally) of disconnected documents...
        > Impacts...
Transform How You Manage Info
        From                                   To
        • Document-Centric                ...
Organizing Information with Info Map
                                                                   <- tested by [0..n...
Leveraging EBA
      • An Enterprise Business Architecture (EBA) Provides
        a customer-centric and holistic view of ...
Use Outside-In Approach
 • Application-Centric, Organization Centric, or Process Centric
   approaches are Inside-Out.
   ...
Define Primary Scope of Your Program in
  Clear
Terms of Value Stream Elements
                                           ...
Leverage Model Relationships
• The interconnection of Value Stream Elements via the Business
  Artifacts they create and r...
Leveraging EBA to Avoid Waste
     IBIS scope covered ~285 distinct business processes... we needed to
      IBIS scope co...
Summary
 • An Enterprise Business Architecture (EBA) provides a customer-
   centric and holistic view of your enterprise ...
To Explore Further...
       • Let's connect: http://www.linkedin.com/in/stevemelville
       • Understand Enterprise Busi...
Enterprise Business Architecture In Practice --
Leveraging EBA for Success on Large-Scale
CRM/ERP Implementations
Upcoming SlideShare
Loading in …5
×

Enterprise Business Architecture in Practice -- Leveraging EBA for Success on Large-Scale CRM/ERP Implementations

3,121 views

Published on

Pragmatic recommendations for leveraging Enterprise Business Architecture (EBA) to avoid common pitfalls of ERP/CRM projects. While there is ample literature on the theory and concepts of Enterprise Business Architecture, this talk distills recommendations gleaned from actually having tried to apply EBA on Sun Microsystems &quot;IBIS&quot; project. This multi-year, multi-deployment program impacted more than 250 business processes spanning virtually all of Sun\'s core value streams: Concept-to-Offering, Campaign-to-Sales Order, Order-to-Cash, Supply Chain Plan-to-Stock, Issue-to-Resolution, and Financial Accounting-to-Reporting. It targeted more than 50% of Sun\'s entire application portfolio for replacement. The presentation describes how EBA can be leveraged to avoid the cost overruns, schedule slips, and missed business expectations that are often encountered on ERP/CRM implementation efforts.

Published in: Technology, Business
  • Dating direct: ❤❤❤ http://bit.ly/2F90ZZC ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area is here: ♥♥♥ http://bit.ly/2F90ZZC ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Enterprise Business Architecture in Practice -- Leveraging EBA for Success on Large-Scale CRM/ERP Implementations

  1. 1. Enterprise Business Architecture in Practice -- Leveraging EBA for Success on Large-Scale CRM/ERP Implementations Steve Melville May 6, 2010 Denver, Colorado
  2. 2. Disclaimer • This presentation stems from an internal project conducted within Sun Microsystems prior to Sun's acquisition by Oracle. • It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. • The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. May 6, 2010 Slide 2
  3. 3. Objectives: • Demonstrate how Enterprise Business Architecture (EBA) can be leveraged to increase likelihood of success on very large scale CRM/ERP implementations • Focus is on pragmatic recommendations distilled from our experiences on Sun Microsystems' “IBIS” project. May 6, 2010 Slide 3
  4. 4. Sun Microsystem's “IBIS” Project • Believed to be one of the larger CRP/ERM implementations ever attempted. • Multi-year, multi-deployment effort aimed at streamlining Suns' business and consolidating its application portfolio. > Number Business Processes Impacted = 285, spanning virtually all of Sun's core value streams: Concept-to-Offering, Campaign-to-Sales Order, Order-to-Cash, Supply Chain Plan-to-Stock, Issue- to-Resolution, and Financial Accounting-to-Reporting. > Number of Sun Applications Targeted for EOL = 513 (>50% of Sun's entire portfolio) > Number of Oracle eBusiness Suite (EBS) modules targeted for deployment = 74 (76% of 11i EBS) > Number of RICE Objects > 950, 417 Reports, 213 Interfaces, 88 Conversions, 232 Extensions > Number of program team members (peak) = 1,074 > Number of Internal Users > 30,000 > Number of Partner Companies Impacted > 3,000 (including Selling Partners, Suppliers, External Manufacturers, Logistics Providers, Banks, Export Control, Repairs Partners) > Deployment Architecture: single global instance comprised of Oracle eBusiness Suite (11.5.10): > Mid-Tier: 50 Sun Fire T2000 servers (total: 1.6 TB memory) > Data Tier: 4 Sun Fire E25K servers + 1 StorEdge 9990 + 1 STK 6540 Storage Array > Production OLTP Database Size (>6TB as of 8/1/2009) and growing! May 6, 2010 Slide 4
  5. 5. Beware! • Large scale CRM/ERP implementations are HIGH RISK undertakings due to: > Disruptive Effects on Your Entire Business Ecosystem > High Cost of Implementation > High Likelihood of Schedule and Budget Overruns • According to Panorama Consulting's 3-year study of more than 1,300 ERP implementations published in 2008*: > 93% of ERP projects take longer than expected > 65% cost more than expected > 79% deliver less than half of the expected business benefits *Full report available at: http:www.panorama-consulting.com/2008ERPReport.html May 6, 2010 Slide 5
  6. 6. Key Pitfalls • Inability to manage the organizational change necessary for success > Unclear understanding of where you are, where you want to be, and why you want to be there (unclear definition of success) • Ineffective program organization > Teams -- overlaps and gaps between program teams > WBS -- failure to understand dependencies in work breakdown structure > Program information – the information gathered and created by the program is not organized for traceability or easy retrieval • Late surprises > Key business requirements that don't surface until late in the game force re-work and schedule delays May 6, 2010 Slide 6
  7. 7. Leveraging EBA • An Enterprise Business Architecture (EBA) provides a customer-centric and holistic view of the enterprise and a business view of your CRM/ERP project • This talk will focus on ways to leverage EBA to ➢ Manage Organizational Change ➢ Organize Your Program for Agility ➢ Avoid Late Surprises May 6, 2010 Slide 7
  8. 8. The Change is LARGER Than You Think! ● Metrics targeted for improvement The change ● Applications targeted to replace or introduce you intended ● Business Processes targeted for re-engineering ● Metrics which must not be degraded ● Applications upstream from applications being replaced, that must be modified to create different outputs ● Applications downstream from applications being replaced that must deal with different inputs ● New / changed application interfaces (no “dangling wires”!) Side-effects ● Business Processes that must be modified to of the create different artifacts implementation ● Business Processes that must be modified to itself handle different artifacts as inputs An organization's ability to manage change is one An organization's ability to manage change is one of the main gating factors for success of the main gating factors for success
  9. 9. Managing Organizational Change Managing organizational change requires knowing where you are, where you want to be, and why Transition Transition Keep From To Organization's Organization's Desired Current Capabilities Capabilities Where we Where we are today want to be Looks pretty simple, right? May 6, 2010 Slide 9
  10. 10. The reality at most organizations Transition Transition Keep From To Organization's Current Organization's Capabilities Where we Desired Where we are today? want to be? Capabilities You can't clearly define success if you are fuzzy about where You can't clearly define success if you are fuzzy about where you are and where you want to be you are and where you want to be May 6, 2010 Slide 10
  11. 11. Knowing Where You Are • Why Model “As-Is” state? > Helps identify opportunities for improvement > Helps to identify real problems rather than pet theories > Helps bring to light “hidden” requirements > Helps identify change targets – i.e., roles that will be impacted by process changes > Provides a baseline against which changes can be defined – knowing the “the deltas” greatly aids business readiness activities • Some risks of modeling current state > Delays “getting on with the solution” > Costs time (delaying value realization) and money > Can get bogged down in “analysis paralysis” > Modeling current state forces thinking down the same ruts -- may stifle innovation > Is throw-away – why create a blueprint of a building just before you knock it down? Recommendation: Initially, model current state Recommendation: Initially, model current state at Business Architecture level, rather than Business Process level at Business Architecture level, rather than Business Process level (but leverage Business Process level models if they exist) (but leverage Business Process level models if they exist) May 6, 2010 Slide 11
  12. 12. 1 What's an Enterprise Business Architecture ? • A single common Enterprise-Wide framework that focuses on how value is generated for customers by your company and it's partners. • An Enterprise Business Architecture (EBA) is composed of an integrated set of models, expressed through a set of views that define your Value Stream Elements and the business artifacts required and produced through those value streams. • These models and views also depict the relationships that Value Stream Elements and Business Artifacts have with each other and: > with External Business Entities (e.g., customers, suppliers) > with your internal organization structures (i.e., your org chart) > with your business strategies and goals and the change programs intended to drive improvements > with other elements of your Enterprise Architecture (e.g., Application Architecture, Information Architecture, etc.) 1 Refer to Enterprise Business Architecture: The Formal Link between Strategy and Results, Ralph Whittle and Conrad B. Myrick for more information about EBA. May 6, 2010 Slide 12
  13. 13. Building The Enterprise Business Architecture • The EBA is rigorously derived via an integrated set of models, expressed via a set of views. • What follows are excerpts from a few of these views to illustrate some key points. > Enterprise Entity View – the “outside in” view > Value Stream Group View – ties “outside in” views to the end-to-end flows of how value is delivered > Value Stream Architecture View – begins to show how work flows within your enterprise > Sub-Value Stream Architecture View – the connection to Business Processes May 6, 2010 Slide 13
  14. 14. EBA Enterprise Entity View is “Outside In” “External Entity” “External Entity” e.g., Customer, e.g., Customer, Business Artifacts Business Artifacts Supplier, Selling Exchanged Customer Supplier, Selling Exchanged Partner Partner Between Entities Between Entities C R R C R <<tangible>> <<tangible>> <<tangible>> <<via phone>> <<via phone>> <<electronic>> <<electronic>> Product <<via web>> <<via web>> Inbound Sales Order Shipment Service Service Request Purchase Order Confirmation Request Resolution C R C R C “C” designates “C” designates outputs “created” outputs “created” “R” designates “R” designates inputs “received” inputs “received” Sun Microsystems, The “Enterprise Entity” The “Enterprise Entity” Inc (i.e., Your Enterprise) (i.e., Your Enterprise) viewed at this level as aa viewed at this level as “black box” “black box” Focus is on your interactions with your customers... Focus is on your interactions with your customers... not your internal processes not your internal processes May 6, 2010 Slide 14
  15. 15. Value Stream Group View Customer C R R C R <<tangible>> <<tangible>> <<tangible>> <<via phone>> <<via phone>> <<electronic>> <<electronic>> Product <<via web>> <<via web>> Inbound Sales Order Shipment Service Service Request Purchase Order Confirmation Request Resolution C R C R C Value Value Stream “Balancing & “Balancing & Stream $ $ Leveling” This view “peaks inside” the This view “peaks inside” the VS-22 VS-31 Leveling” ensures all VS-22 VS-31 ensures all Enterprise Entity, mapping Enterprise Entity, mapping Inbound PO Inbound PO Issue Issue Business Business To To Artifacts from Value Stream Value Stream inputs and outputs toResolution To Shipment Shipment Value To inputs and outputs to Value Resolution Artifacts from Enterprise View Enterprise View Group we're Group we're peaking Streams Streams $ $ are tied to some are tied to some peaking VS VS inside inside VG-2 Customer Centric Group Sun Microsystems, Inc Value Stream Elements are characterized by the Value Stream Elements are characterized by the transformations they drive (inputs to outputs) transformations they drive (inputs to outputs) May 6, 2010 Slide 15
  16. 16. Value Stream Architecture View Customer C R C R <<via phone>> <<via phone>> <<via web>> Service <<via web>> Service Request Service Request Service Request Resolution Request Resolution R C R C Business $ Artifacts SVS-310 Intermediate $ created by Service Artifact SVS-312 Sub-Value other Value Request Accepted Stream Streams To SR Now we will “peak<<electronic>> the Issue-to- C inside” R Accepted To Resolution Resolution ValueAccepted Service reveal how $ SR Stream to Request $ work flows within your enterprise R R R C Value Stream we're <<electronic>> <<electronic>> <<electronic>> “Peeking Install Service Service Inside” Base Contract Knowledge VS-31 Issue to Resolution VS-31 Issue to Resolution “Peeking inside” the VS begins to reveal how work flows “Peeking inside” the VS begins to reveal how work flows within your enterprise in support of your external flows Slide 16 within your enterprise in support of your external flows May 6, 2010
  17. 17. Example Data Lexicon Product Install Base Service Contract Level Asset Contract Line [0..1] of Service Related Related Business Business entitled [0..1] ▲ Data Objects Data Objects Serviced asset [1] ▲ LOS for [0..n] ▼ SR's [0..n] ▼ contract [1] ▲ SR's [0..n] ▼ Customer service address [1] ► Address ◄ address for [0..*] Service Business Request Customer Business Primary contact [1] ► Contact Data Data ◄ contact for [0..*] Object Object S:Created SR Number [0..1] S: Accepted Business Business [0..1] S: Closed - Resolved Data Data Request Date S: Canceled States States Problem [0..1] Business Business Description Business Data Rules Data Data Severity [0..1] Business Term Definition Meaning Attributes Attributes Expected [0..1] Accepted Service A Service Request for which Reflects a state of the Service Response Time Request Problem Description, Request in which all necessary Serviced Asset, Entitled information has been gathered Actual [0..1] Level of Service, Service to begin resolution of that Response Time Address, and Primary service request. DATA LEXICON – Contact have been SERVICE Expected [0..1] determined. Resolution Time REQUEST Service Request Resolution A Service Request in a Closed - Resolved state. Reflects a state of the Service Request in which the Last Modified On: 15-Mar-2010 Actual [0..1] customer's issue has been Last Modified By: Steve Melville Precise specification of the informational content of Resolution Time resolved to the customer's Precise specification of the informational content of satisfaction. Business Artifacts is defined in Data Lexicon Models. Business Artifacts is defined in Data Lexicon Models. May 6, 2010 Slide 17
  18. 18. Sub-Value Stream Architecture View Customer This Business Process transforms “Service Requests” received via the phone into C “Accepted Service Requests” C <<via phone>> <<electronic>> Service Business Service Request Request Process R R P-2740 Accept SR Via Phone $ C P-1202 <<electronic>> Accepted “Peaking inside” Accept SR a Sub-Value Stream Service C Accepted Request R SR To Via Web connects us to the Business Process R R Resolution $ Sub-Value R R Level Stream <<electronic>> <<electronic>> We're Install Service “Peeking Base Contract Inside” SVS-310 Service Request To Accepted SR The “leaf” of the Value Stream Hierarchy defines the scope (inputs and The “leaf” of the Value Stream Hierarchy defines the scope (inputs and outputs) of your Business Processes (from which BPMN models can start) outputs) of your Business Processes (from which BPMN models can start) May 6, 2010 Slide 18
  19. 19. Value Stream & Process Hierarchy Value Stream Elements may be organized into a Value Stream Elements may be organized into a Value Stream Hierarchy Value Stream Hierarchy Sun Microsystems, Inc. (SMI) Entity SMI Country/ Analogous "Google Maps" Level of Detail Contintent Value Stream Architecture Elements $ $ $ Group Country Aggregates VG VG$ VG VG$ ... VG VG$ 4.9" $ $ Value Streams VS VS Region $ $ Sub-Value $ $ $ $ State SVS SVS SVS SVS Streams $ $ $ $ Business BP BP City Process BP BP Process Neighborhood BP-80 Level 1 BP-80 Level 1 Process Models (+) (+) (+) (+) Role Role Steps 1.2 1.3 1.2 1.3 2.34" Role Role (+) (+) 1.7 1.7 BP-80 Level 2..n BP-80 Level 2..n BP-80 Level 2..n BP-80 Level 2..n Blocks / Process Houses Role Role Role Role 1.2.1 1.2.3 1.2.1 1.2.3 1.2.1 1.2.3 1.2.1 1.2.3 Sub-Steps Role Role Role Role 1.2.2 1.2.2 1.2.2 1.2.2 May 6, 2010 Slide 19
  20. 20. Upper Levels of a Value Stream Hierarchy Sun Microsystems, Inc $ $ $ $ VG-1 VG-2 VG-1 VG-2 VG-2 VG-2 VG-2 VG-2 VG-3 VG-2 VG-3 VG-2 VG-4 VG-2 VG-4 VG-2 Strategic Customer Strategic Customer Customer Customer Customer Customer Business Customer Business Customer People Customer People Customer Centric Visioning Centric Centric Centric Centric Centric Enabling Centric Centric Caring Centric Visioning Centric Enabling Caring $ $ $ $ $ $ $ $ $ $ $ VS-10 VS-11 VS-12 VS-32 VS-50 VS-51 VS-55 Insight Concept Initiative Resolution Strategy Plan Accounting to to to to to to to Strategy Retirement Results Knowledge Plan Stock Reporting $ $ $ $ $ $ $ $ $ VS-21 $ VS-22 $ VS-23 $ $ $ VS-20 VS-31 VS-80 VS-81 Campaign Sales Order Order Relationship Issue Recruit Hire to to Fulfillment to to to to Sales Fulfilled to Partnership Resolution Hire Separate $ Order $ Lines $ Cash $ $ $ $ May 6, 2010 Slide 20
  21. 21. Function Hierarchy vs. Value Stream Architecture “Function Hierarchies” Value Stream Architecture > Can be used to classify > Can be used to classify processes into buckets. processes into buckets. > Functional Hierarchies are > Value Stream Hierarchies* are imposed rigorously derived > Don't explicitly demonstrate: > Value Stream Architecture > How value is delivered to Models explicitly show: the customer > How value is delivered to the > How work flows through customer your organization > How work flows through your > Dependencies between organization processes > Dependencies between processes *using EBA balancing and leveling techniques May 6, 2010 Slide 21
  22. 22. Knowing Where You Want to Go #1 Reason CRM Initiatives Fail: #1 Reason CRM Initiatives Fail: Companies Can't Effectively Define Success11 Companies Can't Effectively Define Success Top 3 Reasons CRM Initiatives (Still) Fail – And How to Avoid Them, Pivotal CRM, 1 http://www.bitpipe.com/detail/RES/1244603771_296.html?asrc=HR_HRL May 6, 2010 Slide 22
  23. 23. Clearly Define Success • Don't just list the possible benefits, be specific about which benefits you are committed to achieving • Baseline current state > Define clear, specific, measurable metrics for each Value Stream. > Value Stream Architecture models aid in the transformation of Value Stream metrics to process KPI's > The rigorous decomposition of Value Streams into Sub-Value Streams and of Sub-Value Streams to Business Processes allows identification of finer-grained measures and performance indicators with clear traceability to the higher level metrics > Use current measures against those metrics as your baseline. • Define success in terms of specific, measurable changes in these key metrics. May 6, 2010 Slide 23
  24. 24. Example: Value Streams and Metrics $ $ $ VS-11 VS-11 VS-21 VS-21 VS-31 VS-31 Concept Concept Campaign Campaign Issue Issue to to To To To To Retirement Retirement Sales Order Sales Order Resolution Resolution $ $ $ Time-to-Market Quote Conversion Rate Issues Per Product Quote-to-PO Duration (Sales Cycle) Delivery Cost per Service Request Margin % of SR's with Response Time Key Metrics Within SLA Booking Time % of SR's with Resolution Time Within SLA Booking Transactional Cost ● ●Metrics organized by Value Stream Metrics organized by Value Stream ● Establish Baseline and Target Values for Key Metrics the project is intended to ● Establish Baseline and Target Values for Key Metrics the project is intended to impact as a more precise definition of “success” impact as a more precise definition of “success” > Example: Improve “% of SR's with Response Time Within SLA” by 20% > Example: Improve “% of SR's with Response Time Within SLA” by 20% without increase in “Delivery Cost Per Service Request.” without increase in “Delivery Cost Per Service Request.” ● Traceability between Value Streams, Sub-Value Streams, and Business Processes ● Traceability between Value Streams, Sub-Value Streams, and Business Processes allows these high-level targets to be decomposed into lower level KPI's allows these high-level targets to be decomposed into lower level KPI's May 6, 2010 Slide 24
  25. 25. Leveraging EBA • An Enterprise Business Architecture (EBA) Provides a customer-centric and holistic view of the enterprise and a business view of your CRM/ERP project • This talk will focus on three ways to leverage EBA ✔ Manage Organizational Change ☞Organize Your Program for Agility ➢ Avoid Late Surprises May 6, 2010 Slide 25
  26. 26. Organizing Your Program For Agility • To be effective, the team members, work activities, and information associated with large scale CRM/ERP projects must be organized effectively • Ineffective program organization results in: > Overlaps and gaps between program teams = churn, rework > Work Breakdown Structure (WBS) fails to reflect dependencies = unrealistic schedules, delays, rework > Information gathered and created by the program is not organized for traceability or easy retrieval = inefficiency, rework > “Unstable” organizing principle -- teams, WBS, and information groupings get out of sync every time business changes = lack of agility, higher cost, strands investment • Can we organize program information effectively to avoid these consequences? May 6, 2010 Slide 26
  27. 27. What's Your Organizing Principle? Some Candidate Pro's Con's Organizing Principles by Application + more natural for developers -- doesn't match business flows, (Module) Groups -- high likelihood of gaps -- unstable (apps come and go!) by Business + more natural for "sponsors" -- doesn't match business flows, Organizational Unit -- high likelihood of gaps, -- unstable (reorg's happen!) by Business Function + often close to "sponsors" -- doesn't match business flows view -- high likelihood of gaps + more stable than org structure by Value Stream + matches business flows, -- cross-functional may not be as Element + matches effective “units of natural for sponsors, especially implementation” in functionally siloed + gaps much less likely organizations + stable May 6, 2010 Slide 27
  28. 28. Value Stream Hierarchy is Backbone • The upper (architectural) levels of the Value Stream Hierarchy are quite stable – changing only as a result of specific, large- scale process re-engineering efforts (whereas re-orgs only require pushing around lines on the org chart!) • The Value Stream Hierarchy provides the backbone to which other elements can be attached. • Value Stream Elements: > are realized by Business Processes > are expected to meet Program objectives, Metrics and Measures > are supported by Logical Software Components (i.e., applications and services) > address Business Requirements > have contributions from and are stewarded by Organizational Units > are tested by Test Plans and Test Scripts > and provide organization for Project Plan Work-Breakdown Structures (WBS) and Program Teams May 6, 2010 Slide 28
  29. 29. Leverage Your Investment • Large Scale CRM/ERP projects require you to make a significant investment in understanding your organization and your solution > Business Process Models and Requirements > Design Specs > Technical Specs > Functional, Technical, and Deployment Architectures > Project Plans, Work Breakdown Structures > Program Rosters, Teams > Test Plans, Scripts, Results > Success Criteria • Is this work “throw-away” or can we leverage this investment throughout and beyond the life-cycle of the project? May 6, 2010 Slide 29
  30. 30. Our initial approach to managing this info • Via hundreds (literally) of disconnected documents... > Impacts: > little traceability between levels > expensive to build high-level views (so we rarely do!) > little or no navigation across relationships > tie to goals/requirements is ad hoc and hard to visualize or analyze > very difficult to analyze from multiple viewpoints. > rippling changes (e.g., to goals) through multiple documents is prohibitively expensive and time-consuming • ... and a handful of disconnected repositories and tools > Impacts: > little traceability between levels > little or no navigation across relationships > redundant data entry (= higher cost + time) May 6, 2010 Slide 30
  31. 31. Transform How You Manage Info From To • Document-Centric • Model-Centric Information is “hostaged” in While the need for documents documents – making re-use and won't go away...focus on managing analysis of this information difficult models rather then publishing documents. • Leverage Enterprise Architecture Tool(s) to maintain models in a common repository capable of generating multiple viewpoints. Use web publishing to enable broad distribution. • On IBIS we defined an Info Map to define the structure and semantics for program information • An EBA Meta-Model White Paper is being worked on jointly by Steve Melville and Ralph Whittle, expected to be published in May, 2010. May 6, 2010 Slide 31
  32. 32. Organizing Information with Info Map <- tested by [0..n] tests {1..n] -> <- supports [1..n] Business publish Business supported by{1..n] -> <- applies to [0..1] Requirement Master Goals should address{1..n] -> (and Fit/Gap) Reqmt & Gaps List (MRGL) addressed by -> Master ( Reqm Name) <- addresses <-has goals <- gap resolved by [0..1] goal for -> Process Scope E2E List resolves {1..n] -> publish Process Flows link Application Business <- implemented by [1..n] System Process Element implements [1..n]-> Gap (non 11i) (e.g., Value Stream <-plays role in [1..n] Resolution Workflow, Process) actors [1..n]-> (GR Name) Oracle 11i <- test case for <- input for <- output from Process test case -> input -> Module output -> link Role link Configuration Gap Spec Resolution BR.100 Process BR.030 Business MD-120 Definition Artifact BP.080 implemented by [1..n] -> MD-70 (Data or Physical) <- implements [1..n] RICE MD-51 Elements link test case -> Report MD-120 Test <- test case for Test MD-70 Scenario or MD-50 Script link Scripts & Interface link Scenarios (TE-40) MD-120 Data CV-60 publish Conversion link CV-40 Master LEGEND RICE Scope Source of Truth: List Extension Info Map EA Tool link MD-120 link MD-70 Last Revised: 08-Sep-2009 RICE By: Steve Melville MD-50 Tracker Version 2.0 Source of Truth: Collab Library May 6, 2010 Slide 32
  33. 33. Leveraging EBA • An Enterprise Business Architecture (EBA) Provides a customer-centric and holistic view of the enterprise and a business view of your CRM/ERP project • This talk will focus on three ways to leverage EBA ✔ Manage Organizational Change ✔ Organize Your Program for Agility ☞Avoid Late Surprises May 6, 2010 Slide 33
  34. 34. Use Outside-In Approach • Application-Centric, Organization Centric, or Process Centric approaches are Inside-Out. > They make it easy to plunge into detailed designs... > But they make it difficult to see the things you should be working on, but aren't! > Gaps don't surface until late in test cycles – when they are expensive to correct and cause schedule delays • As noted earlier, EBA is Outside-In > Value Streams provide an End-to-End view of how value is delivered. > End-to-End views reduce risk of gaps – and also are helpful in constructing end-to-end test cases May 6, 2010 Slide 34
  35. 35. Define Primary Scope of Your Program in Clear Terms of Value Stream Elements Sun = In Scope Microsystems, Inc = Out of Scope $ $ $ $ VG-1 VG-2 VG-1 VG-2 VG-2 VG-2 VG-2 VG-2 VG-3 VG-2 VG-3 VG-2 VG-4 VG-2 VG-4 VG-2 Strategic Customer Strategic Customer Customer Customer Customer Customer Business Customer Business Customer People Customer People Customer Centric Visioning Centric Centric Centric Centric Centric Enabling Centric Centric Caring Centric Visioning Centric Enabling Caring $ $ $ $ $ $ $ $ $ $ $ VS-10 VS-11 VS-12 VS-32 VS-50 VS-51 VS-55 Insight Concept Initiative Resolution Strategy Plan Accounting to to to to to to to Strategy Retirement Results Knowledge Plan Stock Reporting $ $ $ $ $ $ $ $ $ VS-21 $ VS-22 $ VS-23 $ $ $ VS-20 VS-31 VS-80 VS-81 Campaign Sales Order Order Relationship Issue Recruit Hire to to Fulfillment to to to to Sales Fulfilled to Partnership Resolution Hire Separate $ Order $ Lines $ Cash $ $ $ $ Of course, this can and should be extended to Sub-Value Of course, this can and should be extended to Sub-Value Stream and Business Process levels Stream and Business Process levels May 6, 2010 Slide 35
  36. 36. Leverage Model Relationships • The interconnection of Value Stream Elements via the Business Artifacts they create and require forms a dependency graph. • Use this dependency graph to derive secondary scope. -- i.e., the additional Value Stream Elements and Business Processes on which the primary scope depends – or which have dependencies on the primary scope. • Leverage additional model relationships to define primary and secondary scope: > The Logical Software Components (applications or services) being replaced, added, or impacted. > The enterprise data (lexicon elements) required or created > The organizations affected by the Change Program. > The scope of Program Teams responsible for executing the Change Program May 6, 2010 Slide 36
  37. 37. Leveraging EBA to Avoid Waste IBIS scope covered ~285 distinct business processes... we needed to IBIS scope covered ~285 distinct business processes... we needed to understand how they all fit together. understand how they all fit together. Without Business Architecture With Business Architecture • Overlaps = wasted effort, contention, • No overlaps = enables teams to work re-work in parallel with less integration risk • Gaps = schedule risk, rework • No gaps = avoids late surprises/ re- work • Unclear dependencies = schedule/budget risk -- more meetings • Clear dependencies = teams know with more people required to resolve when/where to integrate, enables dependencies, rework if dependencies construction of E2E scenarios not discovered soon enough May 6, 2010 Slide 37
  38. 38. Summary • An Enterprise Business Architecture (EBA) provides a customer- centric and holistic view of your enterprise and a business view of your CRM/ERP project > Helps you understand and manage organizational change > Provides a framework for clear definition of metrics, measures and expectations for success > Provides a framework for organizing the vast amount of information generated by a large CRM/ERP implementation in a way that enables you to leverage it both during and after your initial implementation. > Provides the backbone for traceability between: > Goals and Objectives > Process Definitions > Requirements > End-to-End Test Scenarios > Application Systems / Components > Development Artifacts (Reports, Interfaces, Conversions, Extensions) > Helps avoid surprises that cause rework and schedule delays May 6, 2010 Slide 38
  39. 39. To Explore Further... • Let's connect: http://www.linkedin.com/in/stevemelville • Understand Enterprise Business Architecture > Enterprise Business Architecture: The Formal Link between Strategy and Results, Ralph Whittle and Conrad B. Myrick, Auerbach Publications, CRC Press, 2005 > IASA Enterprise Business Architecture Training Class, taught by Ralph Whittle. > Watch for EBA Meta-Model White Paper by Steve Melville and Ralph Whittle to be published later this month (May, 2010) • Other areas where Enterprise Business Architecture can be leveraged: > Business Architecture: Scenarios & Use Cases: http://bawg.omg.org/Bus_Arch_Scenario_White_Paper.pdf • Understand why, what and how of “Outside In” approaches > Customer Expectation Management: Success Without Exception, Terry Schurter & Steve Towers, Meghan-Kiffer Press, 2006 > Reorganize for Resilience: Putting Customers at the Center of Your Business, Ranjay Gulati, Harvard Business Press, 2010 > The “BP Group” on LinkedIn: http://www.linkedin.com/groups?gid=1062077&trk=myg_ugrp_ovr • Analysis of ERP/CRM projects: > http:www.panorama-consulting.com/2008ERPReport.html > Top 3 Reasons CRM Initiatives (Still) Fail – And How to Avoid Them, Pivotal CRM, http://www.bitpipe.com/detail/RES/1244603771_296.html?asrc=HR_HRL May 6, 2010 Slide 39
  40. 40. Enterprise Business Architecture In Practice -- Leveraging EBA for Success on Large-Scale CRM/ERP Implementations

×