AIM for Business Flows

Overview

1-1 Copyright © 2006, Oracle. All rights reserved.

 Traditional AIM
Traditional AIM Phases

Traditional AIM Processes

 Business Process Architecture
 Business Requirements Definition

Operations Analysis
 Business Requirements Mapping

Production
Production
 Application & Tech Architecture

Definition

Transition
Design
Module Design & Build

Build

 Data Conversion
 Documentation
 Business System Testing
 Performance Testing
 Adoption & Learning
 Production Migration

•Modeling and Reinventing Processes

•Features and Functions Gapping Customisations Testing
•Passive Involvement

1-2 Copyright © 2006, Oracle. All rights reserved.

 AIM for Business Flows (ABF)

AIM for Business Flows Processes AIM for Business Flows Phases

 Business Process Mapping

 Application & Tech Architecture

Elaboration

Production
 Module Design & Build

Transition
Definition

Build
 Data Conversion
 Documentation
 Business System Testing
 Performance Testing
 Adoption & Learning
 Production Migration
•Business Process Focus
•Tools to Manage Business
•Show & Tell vs Ask & Do
•Testing
•Baseline Solution at your finger tips
•Validation of solution
•Active Participation

1-3 Copyright © 2006, Oracle. All rights reserved.

 Traditional AIM vs ABF
Traditional AIM AIM For Business Flows (ABF)

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 Seeks to avoid customisation and

functionality does not meet reqs prioritises all changes
Focus on individual modules Focus on cross module process flows

Ask and Do Show and Tell

1-4 Copyright © 2006, Oracle. All rights reserved.
 What is AIM for Business Flows?

• Latest iteration of Oracle Consulting’s proven

Application Implementation Method (AIM)
• Incorporates changes that:
– Promote a business process focus
– Supports use of pre-defined Business Flows and
“delivery assets”, if available
– Employs iterative Conference Room Pilots (CRPs)
• Does not restrict tailoring of Flows or system
configuration to satisfy client requirements

1-5 Copyright © 2006, Oracle. All rights reserved.

 What makes an implementation Flow
Based?
• Use of predefined flows as starting point
• Use of iterative Conference Room Pilots (CRP)
with a live system
• Use of pre-existing delivery assets, if available
• Customer´s willingness to adopt basic elements
of E-Business Suite best practices as described
in flows
• Flows are reasonably “good fit”

1-6 Copyright © 2006, Oracle. All rights reserved.

 Benefits of Using AIM for Business Flows
for the Customer
• Accelerated implementation timeframes
• Improved communications
• Improved quality of resulting business system

• Reduced number of custom extensions, reduced

risk
• Improved ROI

1-7 Copyright © 2006, Oracle. All rights reserved.

 Approach Objectives

• Rapidly deploy an environment using pre-defined

Business Flows, and pre-tested configurations
• Start with standard business flows as “Future
Process Model”
• Incorporate user involvement throughout the
lifecycle using iterative conference room pilots
(CRPs)
• Employ CRP’s to map business flows to customer
business processes and identify gaps
• Focus on getting the customer rapidly onto Oracle

1-8 Copyright © 2006, Oracle. All rights reserved.

 What is a CRP in ABF ?
• CRP is a series of workshops where Flow Teams of an
implementation project go through the flows iteratively during the
project phases using Oracle Applications (e.g. EBS)

• The flows of a solution will be grouped into logical “flow batches”

that can and will be defined, tested and developed parallel by
independent Flow Teams during the project.

• A Flow Team will consist of at least :

• 1 Implementation Consultant as a facilitator (preferably 2 functional
consultants per flow team, one of which could be a solution architect)
• Customer’s Process Owner
• One or more Customer’s key users.

1-9 Copyright © 2006, Oracle. All rights reserved.

 What is a CRP in ABF ?

• Workshops are used as the primary working model

between Customer and Consultants.

– Implementation Consultants are responsible for

providing Oracle Applications knowledge, updating
project flow documentation, planning and
facilitating the workshops.

– Customer is responsible for providing Customer’s

processes and requirements knowledge and
making necessary timely decisions.

1-10 Copyright © 2006, Oracle. All rights reserved.

 CRP Definitions (for EBS)
Phase CRP Objectives

Definition CRP 1.0 Familiarize the customer with the Business Flows
being implementedand 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 scope.

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 changest this
a point may
indicate the need for an additional CRP 3 iteration.

1-11 Copyright © 2006, Oracle. All rights reserved.

 Summary of ABF
General Flow Solution Documents

General Document Name CRP1 CRP2 CRP3

High Level Solution Document v1 v2 -

Financial & Operation Structure v1 - -

Future Business Model v1 v2 -

Business Requirements Mapping Gaps v1 v2 -

Test Scripts (test results) v0 v1 v2

Set up Documents v0 v1 v2

Apps Extension Functional Design v0 v1

= Sign off
1-12 Copyright © 2006, Oracle. All rights reserved.
 Approach Overview – Top Level Flow
Definition Elaboration Build Transition Production

Create and test

Project Prepare CRP 2 Prepare
Custom
Planning Environment Production
Extensions
Environment

Prepare for CRP 2 Prepare CRP 3

Workshop(s) Environment
Build Required
Assets Conduct CRP 2
Workshop(s) Convert and
Prepare for CRP 3 Verify Data
Workshop(s)

Conduct Business Design Conduct CRP 3

Architecture Extensions Workshop(s)
Workshops Verify
Production
Readiness
Prepare Perform Systems
Custom Integration
Prepare for CRP 1 Test Scripts Test
Workshop(s)

Conduct CRP 1 Solution Perform User

Workshop(s) Review & Acceptance Begin Maintain
Sign-Off Test Production System

Conduct Conduct Conduct Propose

Phase End Phase End Phase End Future
Review Review Review Direction

1-13 Copyright © 2006, Oracle. All rights reserved.

 Definition Phase

Build Transition
Objectives:
Definition Elaboration Production
• Plan the project
Tasks & Activities • Familiarize customer with Flows
 Business Architecture • Map Flows to the Business
Workshops • Identify potential changes

 CRP 1
Key Activities:
• Build/update Delivery Assets
Deliverables • Prepare CRP 1 Environments
 Business Flows mapped to • Conduct Business Architecture
Workshops
Customer’s business • Customer Education on CRP Process
 High Level Solution • Conduct CRP 1
Document
Outputs:
• CRP 1 Results
• Preliminary Conceptual Architecture
• Key Configurations (COA, TCA, Multi-Org)

1-14 Copyright © 2006, Oracle. All rights reserved.

 Elaboration Phase
Objectives:
• Validate COA, TCA, Multi-Org Setups
Definition Elaboration Build Transition Production
• Refine mapping of Flows
• Identify remaining changes
Tasks & Activities
• Design Custom Extensions
 Gap Handling
• Determine/freeze scope of solution
 CRP 2s
 Update documents
 Designs for conversions, Key Activities:
extensions, interfaces • Prepare CRP 2 Environment
• Design custom extensions
• Conduct CRP 2
Deliverables • Solution Review and Sign-off
 Accepted Solution with
updated documents Outputs:
 Designs for conversions, • Refined Configuration
extensions, interfaces • Approved designs for customizations
approved • Conversion Data Mapping
• Updated Test Scripts
• High-Level Solution Document

1-15 Copyright © 2006, Oracle. All rights reserved.

 Build Phase
Objectives:
• Develop, test, and accept custom
Definition Elaboration Build Transition Production software
• Propose a transition strategy
Tasks & Activities • Execute performance test
 Finalize conversions, • Conduct a system test
interfaces, extensions • Finalize the solution
 CRP 3 = System and
Integration Testing
 User Acceptance
Key Activities:
Testing
• Create & test custom extensions
Deliverables • Prepare CRP 3 Environment
 Tested Solution • Conduct CRP 3
 Final designs for
• Conduct User Acceptance Test
extensions, interfaces
 Transition Plan Outputs:
• System Tested Applications
• User Acceptance Test Results
• Performance Test Report
• Transition and Contingency Plan

1-16 Copyright © 2006, Oracle. All rights reserved.

 Transition Phase
Objectives:
• Prepare Production Environment
Definition Elaboration Build Transition Production • 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

1-17 Copyright © 2006, Oracle. All rights reserved.

 Production Phase
Objectives:
• Maintain the Production System
Definition Elaboration Build Transition Production • 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

1-18 Copyright © 2006, Oracle. All rights reserved.

 Gaps and Gap Handling
• Resolution of identified “changes” may include:
– change in application configuration
– manual workaround
– custom extension, or
– adopt the standard Business Flow, as defined

• Approved changes should be incorporated in

following deliverables/work products:
– Future Process Model (i.e. Business Flows)
– Business Procedures documentation
– Application Setup documents
– System Test Scripts

1-19 Copyright © 2006, Oracle. All rights reserved.

 Oracle Business

Design to Release

1-20 Copyright © 2006, Oracle. All rights reserved.