Programme Manager and UK

Business Flows Lead

Delivering Project Green

Using Oracle Business Flows
30th January 2006

Objectives
Explain why we use a Business Flows approach
Explain what it will mean to adopt a Business Flows
Approach
Explain some of the jargon
Ensure there is a common understanding between
Alfred McAlpine and Oracle teams about the
approach
Provide a forum for asking questions about the
approach

Agenda

Context and Key Concepts

Oracles Business Flows Approach
Conference Room Pilots
Lessons Learned

Context & Key Concepts

Why Business Flows?

Quicker implementations
Reduced customization
Re-use of good practice
Reduced risk
Improved quality of solutions
Improved communications

What is a Business Flow ?

Business Flows are end-to-end, integrated business processes
that define a primary cycle of activity within an enterprise.
Oracle Business Flows are Business Flows optimized for Oracle
Applications. They represent a leading practice approach to
employing standard functionality contained in Oracles EBusiness Suite.
Oracle Business Flows help customers relate to how Oracle EBS
solve their business problems.
Oracle Business Flows help
customers see themselves & their
business processes in Oracle software.

Flows and sub-flows

Each business flows comprises a number of sub-flows
For example, Procure to Pay comprises:

Requisition to Receipt
Sourcing Requirements to Agreement
Supplier Return to Replacement
Supplier Return to Debit
Click to Requisition

Oracle brings collateral at sub-flow level

What is a Flow Solution?

A business flow solution comprises:
Process diagram defining the overall process flow
Mapping of the flow to Oracle modules
Definition of the major feature / functions included
and/or excluded
Re-useable assets to help accelerate delivery

What makes a project flow based?

Pre-defined flow solution
Focus on business processes provided by the flows and not application
modules
Approach is solution driven not requirements driven
Customers willingness to adapt working practices to fit Business Flows
Use of Conference Room Pilot techniques on a customer specific
system
Early hands on access to applications for familiarisation and testing
Use of ABF Method, core document templates and re-useable assets

Oracles Business Flows

Approach

The Process
Build the system

Resolve the gaps

Conference Room Pilots
Confirm the design and the gaps
Build the Prototype system

CRP Preparation Define the criteria by which the

completeness of the system will be judged - Scenarios

Business Flows Method

Definition
Project
Planning

Build Required
Assets

Conduct Business
Architecture
Workshops

Elaboration

Build

Prepare CRP 2
Environment

Create and test

Custom
Extensions

Prepare for CRP 2

Workshop(s)

Prepare CRP 3
Environment

Conduct CRP 2
Workshop(s)

Design
Extensions

Prepare for CRP 3

Workshop(s)

Production

Prepare
Production
Environment

Convert and
Verify Data

Conduct CRP 3
Workshop(s)

Prepare
Custom
Test Scripts

Perform Systems
Integration
Test

Conduct CRP 1
Workshop(s)

Solution
Review &
Sign-Of

Perform User
Acceptance
Test

Conduct
Phase End
Review

Conduct
Phase End
Review

Conduct
Phase End
Review

Prepare for CRP 1

Workshop(s)

Transition

Verify
Production
Readiness

Begin
Production

Maintain
System

Propose
Future
Direction

Definition Phase
Definition

Elaboration

Build

Transition

Production

Objectives:
Plan the project
Familiarize customer with Flows
Map Flows to the Business
Identify potential changes
Key Activities:
Build/update Delivery Assets
Prepare CRP 1 Environments
Conduct Business Architecture
Workshops
Customer Education on CRP
Process
Conduct CRP 1
Outputs:
CRP 1 Results
Preliminary Conceptual Architecture
Key Configurations (COA, TCA,
Multi-Org)

Elaboration Phase
Definition

Elaboration

Build

Transition

Production

Objectives:
Validate COA, TCA, Mult-Org Setups
Refine mapping of Flows
Identify remaining changes
Design Custom Extensions
Determine/freeze scope of solution
Key Activities:
Prepare CRP 2 Environment
Design custom extensions
Conduct CRP 2
Solution Review and Sign-off
Outputs:
Refined Configuration
Approved designs for customizations
Conversion Data Mapping
Updated Test Scripts
High-Level Solution Document (Final)

Build Phase
Definition

Elaboration

Build

Transition

Production

Objectives:
Develop, test, and accept custom
software
Propose a transition strategy
Execute performance test
Conduct a system test
Finalize the solution
Key Activities:
Create & test custom extensions
Prepare CRP 3 Environment
Conduct CRP 3
Conduct User Acceptance Test
Outputs:
System Tested Applications
User Acceptance Test Results
Performance Test Report
Transition and Contingency Plan

Transition Phase
Definition

Elaboration

Build

Transition

Production

Objectives:
Prepare Production Environment
Convert and verify legacy data
Train user personnel
Transition to Production
Key Activities:
Plan Transition
Go-Live Checklist
Final System Check
Users & Support Ready
Convert & Load Data
Fallback Plan
Outputs:
Converted and verified data
Skilled Users
Production Support Infrastructure
Production system ready
GO-LIVE

Production Phase
Definition

Elaboration

Build

Transition

Production

Objectives:
Maintain the Production System
Measure System Performance
Promote user acceptance
Propose and plan future direction
Key Activities:
Assess effectiveness of system
Reinforce adoption of system
Recommend Business direction
Recommend technical direction
Outputs:
Effectiveness Assessment
Business Direction
Recommendations
Technical Direction
Recommendations

Whats Different With Flows?

Traditional Approach

Business Flows

Requirements driven

Solution Driven

Solution defined during project based Flow solution defined before start of
on requirements
project
Traditional Waterfall approach

Iterative approach based on CRPs

Defines customisations where std

functionality does not meet reqs

Seeks to avoid customisation and

prioritises all changes

Focus on individual modules

Focus on cross module process

flows

Ask and Do

Show and Tell

Conference Room Pilots

Conference Room Pilots (CRP)

A Conference Room Pilot refers to the technique and
activities surrounding the planning and execution of
one or more formal test scripts aimed at validating the
application system against the clients business needs.
The origin of the term comes from the practice of
placing workstations in a conference room and
arranging them in a particular order (usually by logical
process or Business Flow) for testing. Test scripts
were then passed down the line from one tester to the
next according to the natural flow of the
business process.

The Process
Build the system

Resolve the gaps

Conference Room Pilots
Confirm the design and the gaps
Compare standard system to customers business as
Build the Prototype
usual system
Confirm the standard system configuration
CRP Preparation
Definethe
the gaps
criteria by which the
Determine
completeness of the system will be judged - Scenarios
Determine the change required

CRP Definitions
Phase

CRP

Objectives

Definition

CRP 1

Familiarize the customer with the Business Flows

being implemented and map Business Flows to the
customers business and identify potential changes.

Elaboration

CRP 2.0

Validate customer Chart of A ccounts, Multi-Org

Structure, TCA structure and other personalized
setups identified during CRP 1. Refine mapping of
Business Flows to the customers business and
identify any remaining changes necessary. The
conclusion of CRP 2.0 should result in a frozen
solution design.

Build

CRP 3.0

Business System Test of tailored solution including

custom extensions and sample converted legacy
data. Refinement of solution is still an option at this
point, but the scope of changes should be small by
this time. Significant changes at this point may
indicate the need for an additional CRP 3 iteration.

CRP in detail
Work through
each
scenario

Desired
Result YES

Sign off

Desired
Result NO

Gap Listing

Outside CRP

Change the
business

Analysis of
the gaps

Change
Oracle

Steering
Board

Overview of a Workshop Day

Review Process Model / Flows to
be executed
Identify known Issues,Gaps and
current open issues list
Flow Execution
Issues & Gaps Log Update
Flow Sign-off

Objectives for CRP Execution

Validate Processes
Validate Gap solutions
Confirm Workarounds

Validate Package Configuration

Build Understanding & Ownership

Success
Criteria

CRP Execution - What it is not

System Performance or
User Acceptance Testing
A solution design exercise
Exhaustive exploration of
Functionality
An opportunity to revisit
project scope
Compromised by issue
identification
A training session

Success
Criteria

Outputs from CRP Execution

Flows Validated
Summary of Issues/Gaps

Processes
People
Technology

Revised Scripts
Updated Processes

Updates to Change
Management Process

---- -------

---- ----- --

Revised Application set up

CRP Execution Exit Criteria

Is flow execution complete?
Are all issues resolved?
Are any unresolved issues
categorised for further action?
Have all gaps been recorded &
described in sufficient detail?

CRP in detail
Work through
each
scenario

Desired
Result YES

Sign off

Desired
Result NO

Gap Listing

Outside CRP

Change the
business

Analysis of
the gaps

Change
Oracle

Steering
Board

Issue Classification Guidelines

Business Process Change
Work Around
Change to application configuration
Implementation Issues

Issue Guidelines
All issues and decisions must be recorded even
if resolved during Execution
Issues should be cross-referenced between the
log and the flow in order to facilitate proper
closure
All open issues must be prioritised
Any gaps must be highlighted and recorded for
specification development

What Oracle brings to the table

Ability to facilitate effective CRP workshops
Knowledge of the business flows and the Oracle applications
that underpin them
Prototype system set up
Pre-defined delivery assets:

Process diagrams
Scripts for demonstrating system and comparing system to customers
requirements
Set up documents

What Alfred McAlpine brings to

the table
Expertise and experience of current process
An open mind willing to look at opportunities for
improvement and streamlining their current process
A clear definition of what is critical to their business, and
what is just a nice to have
The expertise and knowledge to prioritise
Ability to make decisions about future business processes

Lessons Learned

Flow-Based Implementation
Challenges
For Customer

Business (and data) owners have to be involved and committed

Timely decisions must be made
Strong sponsorship and Client Team leadership
Commitment to Flows approach
Prioritisation of gaps

For Project Management

Change Management Issues Emphasized

Project Communication
Managing the integration of different flows
Training for project team
Use of instances in CRPs

Flow-Based Implementation
Challenges
For Consultants

From functions and features to benefits in business:

Communication in business terms
Solution awareness (broader knowledge than just one
module)
Workshop facilitation and ability to lead CRPs

For For all parties

Scope Control
Time and Schedule Management

Whats Different With Flows?

Time pressure at start of project

Need to get instance up and running quickly

Need to mobilise customer team quickly
Need business scenarios quickly

May need pre-project mobilisation phase

Customer mobilisation
Handover from sales
Gather accelerator assets

CRPs need to be planned in detail and scheduled

Need to plan for gaps
Iterative approach - how many iterations?
Different WBS

What to watch for

Customer does not really want to adopt approach
Impact of unexpected gaps
Different flows do not integrate out of the box
May be difficult to schedule CRPs (people, facilities)
Which instance is being used for CRP1 vision, preconfigured Gold, set up by project?
Expected accelerator assets may not be available /
suitable
CRP environment may not be available