Вы находитесь на странице: 1из 20

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
 Application & Tech Architecture

Production
Production
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
 Module Design & Build

Production
Definition

Transition
 Data Conversion

Build
 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 implemented andmap 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 changes at this 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

Elaboration Build Transition


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

Key Activities:
• Build/update Delivery Assets
Deliverables • Prepare CRP 1 Environments
• Conduct Business Architecture
 Business Flows mapped to Workshops
Customer’s business • Customer Education on CRP Process
 High Level Solution Document • Conduct CRP 1

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
Definition Elaboration Build Transition Production
Setups
Tasks & Activities
• Refine mapping of Flows
• Identify remaining changes
 Gap Handling
• Design Custom Extensions
 CRP 2s
• Determine/freeze scope of solution
 Update documents
 Designs for conversions, extensions,
interfaces
Key Activities:
• Prepare CRP 2 Environment
• Design custom extensions
Deliverables • Conduct CRP 2
• Solution Review and Sign-off
 Accepted Solution with updated
documents
Outputs:
 Designs for conversions, • Refined Configuration
extensions, interfaces approved • Approved designs for
customizations
• 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 Testing Key Activities:
• Create & test custom extensions
• Prepare CRP 3 Environment
Deliverables
• Conduct CRP 3
 Tested Solution • Conduct User Acceptance Test
 Final designs for extensions,
interfaces
Outputs:
 Transition Plan • 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 Flow: Forecast to Plan
Forecast & Demand Management
PF1967 PF2011 PF2021 PF2028
Collect Generate Achieve Manage
Design to Release Consensus
Forecast Sales Production
Data Forecast Forecast Forecast
• Collect Sales and • Generate statistical • Review forecasts on a • Apply demand and
Shipments Data for forecast based on regular basis and consume forecast.
statistical forecasts. sales history. revise as needed.
Material Resource Planning, Order Management

Production Planning
PF1963 PF1966 PF2038 PF2039
Collect Generate Run Analyze
Demand Item Safety Production Plan, KPIs
Variability Data Stock Levels Plan and Exceptions

• Collect demand data • Calculate for all • Launch Production • Analyze Plan, KPI’s,
including forecast locations where items Plan exception messages
confidence levels have maintained and counts prior to
from relevant sources. safety stock levels. releasing orders.

Material Resource Planning


Production Planning and Control
PF3002 PF3003 PF3004 PF3005 PF2040 PF3001
Adjust Simulate Collaborate Implement Release Plan
Plan with Revised on Revised Revised Schedule Non–MRP
Constraints Constraints Constraints Material

• Make adjustments to • Run plan in simulation • Collaborate with internal • Implement the revised • Release the • Plan non–MRP planned
the plan based on mode with revised and external parties to constraints based on production schedule materials using Kanban
plan review and new constraints to model agree on revised collaboration results. to work areas and planning, MinMax
information potential solutions. constraints. procurement. Planning, etc..
Material Resource Planning, Inventory

Example Enterprise Roles

Planner

Demand Planner

Only Plan to Schedule


Requisition to Receipt – Direct
Demand Manager

Inventory Planning Manager

Copyright © 2005, Oracle. All Rights Reserved


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

Вам также может понравиться