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

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

Steve Melville May 6, 2010
Denver, Colorado

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

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

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

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

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

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

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

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

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

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)

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.

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

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

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)

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

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.

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)

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


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 $ $ $ $


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

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


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.


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

Leveraging EBA
• An Enterprise Business Architecture (EBA) Provides
project
• This talk will focus on three ways to leverage EBA
✔ Manage Organizational Change

☞Organize Your Program for Agility
➢ Avoid Late Surprises


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?


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

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

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?


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)

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.


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


Leveraging EBA
• An Enterprise Business Architecture (EBA) Provides
project
• This talk will focus on three ways to leverage EBA
✔ Manage Organizational Change
✔ Organize Your Program for Agility

☞Avoid Late Surprises


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


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

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


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


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

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

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

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

More Related Content

What's hot (20)

Similar to Enterprise Business Architecture in Practice -- Leveraging EBA for Success on Large-Scale CRM/ERP Implementations (20)

Recently uploaded (20)

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