Workshop - Managementul proiectelor informatice

Bucureti, 27 octombrie 2004

ITERATIVE BUSINESS FLOW-BASED METHODOLOGIES FOR

IMPLEMENTING SOFTWARE PACKAGES. A CASE STUDY
Robert KOMARTIN1
Abstract: AIM for Business Flows, the latest iteration of Oracle Application Implementation
Method, incorporates changes supporting the use of Oracle Business Flows, asociated 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.
Keywords: Business Flow, Applications Implementation Method (AIM), AIM Phase, and AIM
Process
1 Introduction
With every investment in technology undergoing greater scrutiny in todays environment,
its more important than ever that customers realize a faster return on their investment in new
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
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 customers needs, and contributing to better adoption of the new system by
the organization.
The paper provides insights regarding the structure and the inner workings of the last
generation implementation methodologies by analyzing as a case study Oracles AIM for Business
Flows.
2 Definitions
The reader will notice some key terms reccurently appearing throughout the paper. We
believe brief definition of these terms can significantly ease the lecture of the document:
Business Process - A planned series of work activities with defined inputs and
results.
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.
AIM Phase - A chronological 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.
AIM Process - A discipline or sub-project that defines a set of tasks related by
subject matter, required skills, and common dependencies. A process usually spans
several phases in an approach.
1

Oracle Romnia SRL, Robert. Komartin@oracle.com

Workshop - Managementul proiectelor informatice

Bucureti, 27 octombrie 2004

3 Key Characteristics
As described in [2], the key characteristics of Oracle methodology for implementing
packaged software, methodology known as Applications Implementation Method (AIM) for
Business Flows, 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
3.1 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 Oracles 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.
3.2 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 Oracles 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, its 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.
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.

Workshop - Managementul proiectelor informatice

Bucureti, 27 octombrie 2004

3.3 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.
3.4 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 customers 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.
4 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.
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 customers business to those Business Flows. CRPs 2 and 3 concentrate on refining the
mapping, incorporating approved changes, and testing/retesting the revised environment to confirm
its ability to support the customers 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.

Workshop - Managementul proiectelor informatice

Bucureti, 27 octombrie 2004

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.

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.
5 Key Features
AIM for Business Flows was developed with the following key features:
Scalability
Structured Framework
5.1 Scalability
AIM for Business Flows was designed with scalability in mind. From the largest, multinational, multi-site, multi-entity projects, through to the smallest, limited size, constrained scope
projectsAIM 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 aids 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.

Workshop - Managementul proiectelor informatice

Bucureti, 27 octombrie 2004

5.2 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.

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

5.2.1 Project Phases for Control
Definition
The goal of the Definition phase is to plan the project, and rapidly establish a preconfigured 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 customers business, while identifying any potential changes that are
required to personalize the system to better fit the customers 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 customers
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. 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 customers
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

Workshop - Managementul proiectelor informatice

Bucureti, 27 octombrie 2004

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.
5.2.2 Project Processes for Continuity
All AIM for Business Flows tasks are organized into processes that group related
deliverables together. Project team members are assigned to these groupings according to their
specialization and background.
Business Process Mapping
Business Process Mapping addresses the activities surrounding the customers initial
familiarization with Oracle Business Flows, and the initial mapping of the customers 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
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 the
information system architecture around the organizations 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.

Workshop - Managementul proiectelor informatice

Bucureti, 27 octombrie 2004

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.
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 teams 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.
6. 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
Oracle Consultings iProjects toolset. Oracle iProjects is a hosted, Internet platform for project

Workshop - Managementul proiectelor informatice

Bucureti, 27 octombrie 2004

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.
7. Conclusions
AIM for Business Flows is the latest iteration of Oracles proven Application
Implementation Method (please refer to [1] for further details regarding prior releases of the
method). It incorporates changes that support the use of Oracle Business Flows, asociated 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 customers 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 Oracles 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.
References
Robert KOMARTIN, Metodologii de realizare a sistemelor informatice integrate. Taxonomii
metodologice, Informatica Economic vol. VI, nr. 3/2002, pag. 55 58
[2] ***, Applications Implementation Method (AIM) Advantage Handbook, Oracle Corporation,
2004
[1]