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 Oracle’s 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 Oracle’s E-Business 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 Customer´s 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

Oracle’s Business Flows Approach

Build the Prototype system

The Process

CRP Preparation – Define the criteria by which the completeness of the system will be judged - Scenarios

Conference Room Pilots – Confirm the design and the gaps

Resolve the gaps

Build the system

Business Flows Method

Definition Build ProductionTransitionElaboration

Project Planning

DesignExtensions

PrepareCustom

Test Scripts

Create and test Custom

Extensions

PrepareProduction

Environment

Convert and Verify Data

BeginProduction

MaintainSystem

ProposeFuture

Direction

Perform SystemsIntegration

Test

VerifyProductionReadiness

Prepare for CRP 1Workshop(s)

Conduct CRP 1Workshop(s)

Prepare for CRP 2Workshop(s)

Conduct CRP 2Workshop(s)

Perform User Acceptance

Test

Build RequiredAssets

ConductPhase End

Review

ConductPhase End

Review

Conduct BusinessArchitectureWorkshops

ConductPhase End

Review

SolutionReview &Sign-Off

Prepare for CRP 3Workshop(s)

Conduct CRP 3Workshop(s)

Prepare CRP 2Environment

Prepare CRP 3Environment

Definition PhaseDefinition Phase 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)

Definition TransitionTransition ProductionProductionElaborationElaboration BuildBuild

Elaboration PhaseElaboration PhaseDefinition TransitionTransition ProductionProductionElaboration BuildBuild

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 ConfigurationApproved designs for customizationsConversion Data Mapping Updated Test Scripts High-Level Solution Document (Final)

Build PhaseBuild PhaseDefinition TransitionTransition ProductionProductionElaboration Build

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 PhaseTransition PhaseDefinition Transition ProductionProductionElaboration Build

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 PhaseProduction PhaseDefinition Transition ProductionElaboration Build

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

What’s Different With Flows? Traditional Approach Business Flows

Requirements driven Solution Driven

Solution defined during project based on requirements

Flow solution defined before start of 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 client’s 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.

Build the Prototype system

The Process

CRP Preparation – Define the criteria by which the completeness of the system will be judged - Scenarios

Conference Room Pilots – Confirm the design and the gaps

Resolve the gaps

Build the system

Compare standard system to customer’s business as usual

Confirm the standard system configuration

Determine the gaps

Determine the change required

CRP DefinitionsPhase CRP Objectives

Definition CRP 1 Familiarize the customer with the Business Flows being implemented and map Business Flows to the customer’s business and identify potential changes.

Elaboration CRP 2.0 Validate customer Chart of Accounts, Multi-Org Structure, TCA structure and other “personalized” setups identified during CRP 1. Refine mapping of Business Flows to the customer’s 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

Analysis of the gaps

Change the business

Change Oracle

Steering Board

Outside CRP

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

SuccessCriteria

Validate Processes

Validate Gap solutions

Validate Package Configuration

Build Understanding & Ownership

Confirm Workarounds

CRP Execution - What it is not

SuccessCriteria

• 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

Outputs from CRP Execution

---- ------ -- ---- --

---- --

Flows Validated Summary of Issues/Gaps

Revised Application set up

Updates to Change Management Process

ProcessesPeopleTechnology

Revised Scripts Updated Processes

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

Analysis of the gaps

Change the business

Change Oracle

Steering Board

Outside CRP

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

customer’s 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

What’s 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, pre-

configured Gold, set up by project? Expected accelerator assets may not be available /

suitable CRP environment may not be available