AIM for Business Flows

Oracle Consulting’s Business Flow-

Based Methodology for Implementing the
Oracle E-Business Suite
An Oracle White Paper
August 2004
 AIM for Business Flows

Executive Overview.......................................................................................... 3
Introduction ....................................................................................................... 3
A Business Process Focus ........................................................................... 4
Oracle Business Flows as the Starting Point............................................. 4
Early introduction of hands-on familiarization and testing.................... 5
Iterative testing cycles .................................................................................. 5
Top Level Flow............................................................................................. 6
Key Features .................................................................................................. 7
Scalability ................................................................................................... 7
Structured Framework............................................................................. 7
Project Phases for Control...................................................................... 8
Project Processes for Continuity............................................................ 9
Deployment Strategy .................................................................................. 11
Enhancement Plans .................................................................................... 11

White Paper Title Page 2

 AIM for Business Flows

EXECUTIVE OVERVIEW
AIM for Business Flows is the latest iteration of Oracle Consulting’s proven
Application Implementation Method (AIM). It incorporates changes that support
the use of Oracle Business Flows, associated software environments, and pre-
seeded implementation assets, to accelerate the implementation timeline and keep
the focus of an implementation on business processes and benefits, rather than
software features and functions.
Some hallmarks of the AIM for Business Flows approach include:
• A Business Process Focus
• Use of pre-defined Oracle Business Flows as the starting point Future
Process Model
• Rapid establishment of a software environment, based on Oracle Business
Flows, for use in mapping the customer’s business to Oracle Business
Flows
• Early introduction of iterative hands-on user testing cycles
The AIM for Business Flows approach is applicable to any “assemble to order”
engagement involving the implementation of Oracle’s E-Business Suite, for which
pre-defined business flows exist.
Like earlier versions of AIM, AIM for Business Flows is intended to be a complete,
comprehensive delivery method, which addresses all potential aspects of an
implementation. As with previous versions of AIM, not all tasks need to be
performed on every project. Task selection guidelines incorporated in the method
assist Project Managers and practitioners in determining which tasks are
appropriate for a given project, based on the specific circumstances of the
engagement.

INTRODUCTION
With every investment in technology undergoing greater scrutiny in today’s
environment, it’s more important than ever that customers realize a faster return on
their investment in new Oracle software systems and technology. The combination
of accelerated implementation timeframes, and reduced overall cost, attainable with
a flow-based implementation approach increases the probability that improved ROI

White Paper Title Page 3


Definition: Business Flow – A sequence
of related business processes designed to
achieve a critical objective, incorporating
leading business practices. A flow can
also be a series of flows.
can be attained. Additionally, the iterative nature of the approach leads the
customer and project team to progressively converge on the final configuration of
the business system, improving the fit of the new system to the customer’s needs,
and contributing to better adoption of the new system by the organization.
Key characteristics of the AIM for Business Flows approach, that support these
objectives include:
• A business process focus
• A predefined Future Process Model (i.e. Business Flows) as a starting
point
• Early introduction of hands-on familiarization and testing
• Iterative testing cycles
A Business Process Focus
Oracle Business Flows are central to the AIM for Business Flows implementation
approach. A business flow is a sequence of related business processes designed to
achieve a critical business objective. Business flows often cross organizational and
application boundaries, reflecting how business is actually conducted within an
enterprise. “Order to Cash” is an example of a business flow, that addresses the
revenue cycle of a business.
Because Business Flows are expressed in neutral business language familiar to
business people, they improve Oracle’s ability to communicate with customers
about how they can manage their business using Oracle Applications. This focus
on business processes, rather than on product features and functions, contributes
to better communications between customer and implementers, resulting in
improved understanding of business requirements and software options/
capabilities, etc.
Oracle Business Flows as the Starting Point
Oracle Business Flows reflect standard business practices for an industry,
optimized for Oracle Applications. They represent a leading practice approach to
employing standard functionality contained in Oracle’s E-Business Suite to satisfy
common business requirements. AIM for Business Flows employs Oracle Business
Flows as the starting point for an implementation.
By positioning Oracle Business Flows as the proposed future process model, and
employing iterative, hands-on testing cycles to refine the model, it’s possible to
expedite the establishment of an application instance suitable for testing early in the
project, thereby achieving significant savings in time and effort.
Additionally, by effectively demonstrating how the customer can operate the
business using Business Flows employing standard functionality, the approach also
increases the likelihood that the Application software will be implemented without
unnecessary customizations or extensions, resulting in additional savings.
White Paper Title Page 4

Definition: Business Process - A planned
series of work activities with defined inputs
and results.
AIM for Business Flows also recognizes, and leverages, pre-seeded delivery
materials, which are based upon the Business Flows, to streamline the
implementation. These “accelerator” assets, such as pre-defined Business Flow
diagrams, Application setup documents, and pre-seeded test scripts provide a
baseline set of deliverables that are usable, with little or no modification, to support
the initial round of testing. The assets are updated, as changes are identified, to
support subsequent testing cycles.
Early introduction of hands-on familiarization and testing
With a predefined Future Process Model (i.e. Business Flows) serving as the
starting point for a flow-based approach, the proposed, initial configuration of the
new system is already defined. An environment reflecting that proposed
configuration can quickly be established, and the customer can begin working with
the system very early in the implementation.
The early introduction of hands-on familiarization, testing, and experimentation by
the customer is key to accelerated progress. Providing the customer with the
opportunity to work with the new system early on helps to build confidence in the
proposed configuration, and begin the validation/refinement process sooner.
Iterative testing cycles
Like the traditional AIM approach, AIM for Business Flows relies on business
system testing to verify that the proposed business system meets customer
requirements. However, business system testing begins much earlier in an AIM for
Business Flows engagement, and two or more cycles of testing/validation are
planned.
In a flow-based implementation, iterative business system testing/validation cycles,
or Conference Room Pilots, serve the same function as process modeling and
business requirements mapping sessions do in a traditional AIM engagement.
Through hands on use and testing of the system, they define and validate the future
business process model, and verify that the customer’s business requirements are
being met.
In an AIM for Business Flows engagement, refinements are made to the baseline
configuration at the conclusion of the first, and potentially the second, test
iteration. The changes identified during the first Conference Room Pilot (i.e. CRP
1) are applied to a newly established system environment before commencement of
the second test cycle. This updated environment then becomes the baseline for the
second Conference Room Pilot, or CRP 2.
By incrementally refining the proposed business system to better match customer
requirements, and iteratively vetting those changes in subsequent testing cycles, the
customer and implementation team are able to progressively converge on a
business system that suites the needs of the customer well.
White Paper Title Page 5
 Top Level Flow
Figure 1 below depicts some of the key activities that comprise the AIM for
Business Flows methodology. While many other activities will be performed
concurrently, the Top Level Flow captures the essential characteristics that define
the approach.

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

Figure 1 - AIM for Business Flows Top Level Flow

Most obvious among these characteristics are the iterative Conference Room Pilots,
represented here as CRP 1, CRP 2 and CRP 3. CRP 1 is primarily intended to
familiarize the customer with the Oracle Business Flows being implemented, and to
conduct an initial mapping of the customer’s business to those Business Flows.
CRP’s 2 and 3 concentrate on refining the mapping, incorporating approved
changes, and testing/retesting the revised environment to confirm it’s ability to
support the customer’s requirements.
Because CRP 1 is conducted in an Application environment based on the standard
Oracle Business Flows, the pre-seeded implementation assets employed (i.e. Test
Scripts, etc.) are useable without modification. Changes identified during CRP 1
are reviewed with the customer and, if approved, incorporated in the
implementation assets in preparation for the next CRP cycle. Likewise, refinements
identified in CRP 2 are also reviewed with the customer and, if approved,
incorporated in the delivery materials in preparation for CRP 3.

White Paper Title Page 6

Several business architecture workshops are planned during the Definition Phase,
which are designed to assist the customer in defining suitable Chart of Accounts,
Multi-Org, and Trading Community Architecture structures, which have
implications across the entire E-Business Suite. Application extensions, if required
to fill gaps in functionality, are identified during the first and second CRP cycles,
designed and built during Elaboration and Build phases, and tested during CRP 3.
Should more than one iteration of CRP 2 and/or CRP 3 be necessary due to the
complexity of the engagement, or other criteria, the method provides the flexibility
to plan those additional iterations, as indicated in the diagram.

Key Features
AIM for Business Flows was developed with the following key features:
• Scalability
• Structured Framework

Scalability

AIM for Business Flows was designed with scalability in mind. From the largest,
multi-national, multi-site, multi-entity projects, through to the smallest, limited size,
constrained scope projects—AIM for Business Flows provides the scalability
required by each unique project. AIM for Business Flows identifies
implementation tasks and task steps as either core or optional. A foundation of
core tasks defines the minimum set of steps necessary to implement Oracle
Applications. Task selection guidelines aid in determining which optional tasks to
include in the project plan. This greatly reduces the complexity for the project
management team in planning the work effort required for the implementation.

Structured Framework

AIM for Business Flows uses project phasing to include quality and control
checkpoints and allow coordination of project activities throughout the
implementation. During a project phase, the project team will execute tasks in
several processes. Figure 2 illustrates the relationship between phases and
processes.

White Paper Title Page 7

 Definition Elaboration Build Transition Production

Business Process Mapping (BF)

Application & Technical Arch. (TA)

Module Design and Build (MD)

Data Conversion (CV)

Documentation (DO)

Business System Testing (TE)

Performance Testing (PT)

Adoption and Learning (AP)

Production Migration (PM)

Figure 2 – AIM for Business Flows Phases and Processes

Below is a description of AIM for Business Flows Phases and Processes.

Definition: AIM Phase - A chronological Project Phases for Control

grouping of tasks in an approach.
Implementations are delivered by phase in
order to reduce project risk. Each phase
allows a checkpoint against project goals,
and measurement against quality criteria
to be made.
Definition
The goal of the Definition phase is to plan the project, and rapidly establish a pre-
configured and tested environment for familiarizing the customer with the Business
Flows being implemented. During Definition, workshops are conducted to educate
the customer about critical decisions to be made regarding application architecture
components, such as the Chart of Accounts Structure, Multi-Org Structure, and
Trading Community Architecture. These workshops are also intended to assist the
customer in defining those entities.
One Conference Room Pilot (CRP) is programmed for the Definition Phase – CRP
1. The focus of CRP 1 is to familiarize the customer with the Business Flows being
implemented and map the Business Flows to the customer’s business, while
identifying any potential changes that are required to “personalize” the system to
better fit the customer’s needs.

Elaboration

The goal of the Elaboration phase is to refine the solution through a second
iterative testing (CRP) cycle. This second Conference Pilot provides the first
opportunity to validate the customer’s tailored Chart of Accounts structure, Multi-
Org structure, and Trading Community Architecture. It also provides an initial
look at some of the other changes resulting from process or configuration
modifications identified during CRP 1.

White Paper Title Page 8

 Elaboration also encompasses the design of custom extensions, refinement of the
technical architecture design, and a number of Data Conversion and Performance
Testing preparatory activities.

Build

The goal of the Build phase is to confirm that the overall solution meets the
customer’s business needs. During the Build phase, the CRP 3.0 environment is
prepared incorporating custom extensions for the first time, and also incorporating
sample converted legacy data. Application configuration changes resulting from
CRP 2.0 are also validated during this test cycle. Only minor changes should be
identified, if any, during this test evolution.

Transition

During Transition, the project team deploys the new system into the organization.
All the elements of the implementation must come together to transition
successfully to actual production. The project team trains the users while the
technical team configures the Production Environment and converts data.
Transition is a demanding experience for the project team, and in particular, for the
users who have to maintain exposure to two systems until a new production system
is declared.

Production

The Production phase starts immediately with the production cutover. Production
marks the last phase of the implementation and the beginning of the system
support cycle. Included in this final phase is a series of refinement and
measurement activities. The Information Systems (IS) personnel work quickly to
fine-tune the system and begin regular maintenance. They provide ongoing
support to the organization for the remaining life of the system.
If multiple deployments exist, Production occurs at different times for the various
geographical sites and/or business units.

Definition: AIM Process - A discipline or Project Processes for Continuity

sub-project that defines a set of tasks
All AIM for Business Flows tasks are organized into processes that group related
related by subject matter, required skills,
deliverables together. Project team members are assigned to these groupings
and common dependencies. A process
usually spans several phases in an according to their specialization and background.
approach.
Business Process Mapping

Business Process Mapping addresses the activities surrounding the customer’s

initial familiarization with Oracle Business Flows, and the initial mapping of the
customer’s business to the Flows. It also encompasses the definition of customer
data needed to “personalize” the system for the customer, including the Chart of
Accounts, Multi-Org, and TCA structures. Iterative revision activities related to

White Paper Title Page 9

Business Flows, procedures, and application setups, which are completed after each
Conference Room Pilot (CRP) cycle, are also part of Business Process Mapping.

Application and Technical Architecture

During the Application and Technical Architecture process, the project team
designs an information system architecture around the organization’s business
vision. Included are Oracle, third party, and custom applications; computing
hardware; and networks and data communications infrastructure.

Module Design and Build

The Module Design and Build process produces custom application extensions to
fill gaps in functionality identified during Conference Room Pilots 1 and 2. Custom
systems include program modules (forms, reports, alerts, database triggers, and so
on) that must be designed, built, and tested before they can be incorporated into
the new system. Module Design and Build addresses the design and development
of the custom modules; the Business System Testing process supports testing of
custom modules.

Data Conversion

The Conversion process defines the tasks and deliverables required to convert
legacy data to the Oracle Application tables. The first step of this process is to
explicitly define the data business objects identified for conversion along with the
legacy source systems. System testing, training, and acceptance testing require
converted data before production cutover.

Documentation

The Documentation process begins with documentation standards materials

created early in the project to build quality operation support reference materials.
Documentation requirements and implementation complexity are closely
correlated, and the amount and level of detail in the documentation varies by
project.

Business System Testing

The Business System Testing process is a formal, integrated approach to testing the
quality of all application system elements. It focuses on preparing for testing early
in the project lifecycle, linking testing requirements back to business requirements,
and securing project testing resources.
The Business System Testing process takes on additional significance in an AIM for
Business Flows implementation because of its early introduction in the project and
the iterative nature of the testing, or Conference Room Pilot cycles, in the
approach. Business System Testing tasks make up the majority of CRP 2 and CRP
3 activities, where the configuration of the future business system is refined,
finalized and validated.

White Paper Title Page 10

Performance Testing

The Performance Testing process helps the project team define, build, and execute
a performance test on specific system configurations. This process provides a
powerful and direct means of assessing the performance quality of the system. This
assessment enables the customer to determine whether performance is acceptable,
and to propose changes and perform tuning to correct any initial performance
shortfall.

Adoption and Learning

The Adoption and Learning process accelerates the implementation team’s ability
to work together through team building and organization-specific application
learning. This process also helps determine human support requirements so that
the organization structure and job roles align to meet new performance
expectations resulting from the technology change. Learning needs of all personnel
impacted by the implementation are considered, and appropriate training materials
and learning events are developed and conducted.

Production Migration

The objective of the Production Migration process is to migrate the organization,

systems, and people to the new enterprise system. Following production cutover,
additional objectives include monitoring and refining the production system and
planning. The Production Migration process encompasses transition to production
readiness, production cutover, and post-production support.

Deployment Strategy
AIM for Business Flows method materials (i.e. guidelines/documentation,
workplans, accelerator assets, and deliverable templates, etc.) are being deployed to
delivery consultants via a desktop installable method pack, and Oracle Consulting’s
iProjects toolset. Oracle iProjects is a hosted, Internet platform for project
execution and knowledge management. iProjects allows project teams (Oracle
consultants, customers and partners) to collaborate "virtually" to deliver e-business
solutions better and faster, at a lower cost.
By leveraging iProjects’ ability to create tailored project workspaces, pre-seeded
with method materials appropriate to the engagement, project teams are able to
access the most current and up-to-date materials available from the customer
location, or anywhere else.

Enhancement Plans
Periodic enhancements to this methodology are planned as additional experience is
gained, and lessons learned, through practical experience. Feedback from field
practitioners, and others, is desired and can be submitted via email to AIM-
ADMIN_US@oracle.com

White Paper Title Page 11

AIM for Business Flows
August 2004
Author: Global Methods and Tools

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com

Copyright © 2004, Oracle. All rights reserved.

This document is provided for information purposes only
and the contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to
any other warranties or conditions, whether expressed orally
or implied in law, including implied warranties and conditions of
merchantability or fitness for a particular purpose. We specifically
disclaim any liability with respect to this document and no
contractual obligations are formed either directly or indirectly
by this document. This document may not be reproduced or
transmitted in any form or by any means, electronic or mechanical,
for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.