Aim - Oracle Application Implementation

ORACLE METHODSM
APPLICATION
IMPLEMENTATION
METHOD HANDBOOK
Release 2.0.0
July, 1997
Enabling the Information Age™

Application Implementation Method (AIM) Method Handbook, Release 2.0.0
Part No. A53968-01
Copyright © July, 1997, Oracle Corporation
All rights reserved. Printed in the U.S.A.
Authors: Jennifer Bennett, Anne Blaylock, Jim Lange, Craig Martell, William Matson,
Josyf Mychaleckyj, Janet Price, Bob Reary
Editors: Linda Cherney, Mary Sanders
The programs are not intended for use in any nuclear, aviation, mass transit, medical, or
other inherently dangerous applications. It shall be licensee’s responsibility to take all
appropriate fail-safe, back up, redundancy and other measures to ensure the safe use of
such applications if the Programs are used for such purposes, and Oracle disclaims
liability for any damages caused by such use of the Programs.
This software/documentation contains proprietary information of Oracle Corporation; it is
provided under a license agreement containing restrictions on use and disclosure and is
also protected by copyright law. Reverse engineering of the software is prohibited.
If this software/documentation is delivered to a U.S. Government Agency of the
Department of Defense, then it is delivered with Restricted Rights and the following legend
is applicable:
Restricted Rights Legend Programs delivered subject to the DOD FAR Supplement
are ‘commercial computer software’ and use, duplication and disclosure of the
Programs shall be subject to the licensing restrictions set forth in the applicable Oracle
license agreement. Otherwise, Programs delivered subject to the Federal Acquisition
Regulations are ‘restricted computer software’ and use, duplication and disclosure of
the Programs shall be subject to the restrictions in FAR 52.227-14, Rights in Data --
General, including Alternate III (June 1987). Oracle Corporation, 500 Oracle Parkway,
Redwood City, CA 94065.
The information contained in this document is subject to change without notice. If you find
any problems in the documentation, please report them to us in writing. Oracle
Corporation does not warrant that this document is error free.
ORACLE, Designer/2000, Developer/2000, SQL*Plus, SQL*Loader, SQL*Net,
CASE*Method, ORACLE Parallel Server, PL/SQL, Pro*C, SQL*Module are registered
trademarks of Oracle Corporation, Redwood City, California.
AIM Advantage, CDM Advantage, PJM Advantage, Oracle Cooperative Applications,
Oracle Financials, Oracle Alert, Oracle Manufacturing, Oracle Inventory, Oracle Bills of
Material, Oracle Engineering, Oracle Capacity, Oracle Commissions, Oracle Master
Scheduling, Oracle MRP, Oracle Work in Process, Oracle General Ledger, Oracle Assets,
Oracle Order Entry, Oracle Cost Management, Oracle Payables, Oracle Receivables, Oracle
Personnel, Oracle Payroll, Oracle Purchasing, Oracle Quality, Oracle Sales and Marketing,
Oracle Service, and Application Object Library are trademarks of Oracle Corporation,
Redwood City, California.
Oracle Method is a service mark of Oracle Corporation, Redwood City, California.
Microsoft and MS-DOS are registered trademarks and Windows, Word for Windows,
Powerpoint, Excel, and Microsoft Project are trademarks of Microsoft Corporation. Visio is
a trademark of Visio Corporation. Project Workbench and Project Bridge Modeler are
registered trademarks of Applied Business Technology. All other company or product
names mentioned are used for identification purposes only and may be trademarks of their
respective owners.
Preface
T he Application Implementation Method Handbook provides an overview

of the various approaches, phases, processes, and tasks of the
Application Implementation Method (AIM). AIM is Oracle’s full life-
cycle approach for implementing applications.
This handbook contains the information needed by project managers,

sponsors, and team members to understand the scope of an application
implementation effort and to plan and execute AIM projects.
This handbook, and the Application Implementation Method itself, are

part of Oracle MethodSM —Oracle’s integrated approach to solution
delivery.
Oracle Method Preface i

Audience
The Application Implementation Method Handbook is a high-level

description of how AIM can be used to facilitate implementation
projects. Project managers will use this handbook for project planning
and scheduling. Team members can use this book to gain a broad
understanding of AIM. It also provides a context for the detailed
information in the Process and Task Reference manual.
How the Manual is Organized
This handbook consists of an overview of AIM, chapters on each AIM

phase, and several appendices.
Introduction: This chapter presents an overview of AIM and how to

determine a project approach. It provides guidance in estimating
resources and discusses how AIM incorporates Oracle’s Project
Management Method (PJM).
Phase Chapters: Each phase chapter consists of a phase overview and a

section on the approach to completing that phase. The chapters provide
the following information:
Phase Overview:
• Objectives — describes the objectives of the phase

• Critical Success Factors — lists the success factors of the phase
• Overview Table — lists the process, prerequisites, and key
deliverables
• Prerequisites — lists task prerequisites and their sources
• Processes — lists and defines the processes used in the phase
• Key Deliverables — lists and defines the deliverables for the
phase
ii Preface AIM Method Handbook

Approach:
• Tasks and Deliverables – lists the tasks executed and the

deliverables produced
• Task Dependencies – illustrates the dependencies between tasks
• Managing Risks – provides assistance in reducing the risks
associated with this phase
• Tips and Techniques – discusses helpful tips and techniques
• Estimating – illustrates the relative effort of tasks within the
phase by role
• Scheduling – discusses the approach to scheduling this phase
• Staffing – provides suggestions for staffing this phase
Appendix A: Appendix A provides a work breakdown structure for

the Classic approach.
Appendix B: Appendix B provides a description of the roles used in

AIM.
Appendix C: Appendix C lists the roles used in AIM, the tasks

performed by each role, and the percentage of task time assigned to the
role.
Appendix D: Appendix D provides the AIM data model, including

entities and their relationships, as well as definitions and entity
examples.
Glossary: The Glossary contains definitions of terms, abbreviations,

and acronyms used in AIM.
How to Use this Manual
The Application Implementation Method Handbook contains general

information about using AIM for application implementation projects.
Use this handbook in conjunction with the Application Implementation
Process and Task Reference, which provides detailed information on
processes and tasks. Together, the handbook and reference provide a
complete guide for planning and executing application
implementations.
Oracle Method Preface iii

Conventions Used in this Manual
Several notational conventions are used to make this handbook easy to

read.
Capitalization
Names of tasks, deliverables, processes, and phases are given initial
capitals. For example, Gather Business Volumes task, Business Volume
Requirements deliverable, Business Requirements Definition process,
and Design phase.
Abbreviations and Acronyms

Occasionally, it is necessary to use abbreviations and acronyms when
adequate space is not available. The Glossary lists definitions of all
acronyms and abbreviations.
Suggestions
Helpful suggestions appear throughout the handbook to help you get
the most out of the method. They are highlighted with an illuminated
light bulb. Here is an example of a suggestion:
Suggestion: Verify your backup and recovery plan with your

hardware and software vendors.
Attention
Important information or considerations that save time or simplify tasks
are marked with an attention graphic. Here is an example:
Attention: Since project team training occurs simultaneously

with this task, some recommendations (or decisions) from
training may be implemented in the mapping environment.
In this case, these training inputs become predecessors to this
task.
For More Information

Throughout the handbook we alert you to additional information you
may want to review. This may be a task section, appendix, or reference
manual. Here is an example of a reference graphic:
iv Preface AIM Method Handbook

Reference: Hickman, Linda and Longman, Cliff Case*Method
Business Interviewing. Addison-Wesley. 1994
ISBN 0-2-1-59372-6
Related Publications
Books in the AIM suite include:
• A Quick Tour of AIM

• AIM Method Handbook (this book)
• AIM Process and Task Reference - Volume 1
• AIM Process and Task Reference - Volume 2
Each of these books and their relationships to each other is discussed in

A Quick Tour of AIM.
You may also refer to the following Project Management Method (PJM)
suite of reference books:
• PJM Method Handbook

• PJM Process and Task Reference
• PJM Deliverable Reference
Oracle Method Preface v

Your Comments are Welcome
Oracle Corporation values and appreciates your comments as an Oracle

AIM practitioner and reader of the handbook. As we write, revise, and
evaluate our documentation, your comments are the most valuable
input we receive. If you would like to contact us regarding this
reference or any other AIM or Oracle Method manuals, please use the
following address:
Oracle Method - Application Implementation Group

Oracle Corporation
500 Oracle Parkway
Mailstop 30P16
Redwood Shores, CA 94065
For email inquiries use the following Internet address:
aiminfo@us.oracle.com
Please provide the following information:
• AIM user name

• company name
• company address
• telephone number
Please use these channels to send comments only. Contact your local
Oracle Consulting Services office for technical questions about using the
software tools.
vi Preface AIM Method Handbook

CONTENTS
CHAPTER 1 Introduction to AIM .................................................................................1-1
What is AIM? .............................................................................................1-2
Processes in AIM .......................................................................................1-3
AIM Project Phases.................................................................................. 1-10
Determining a Project Approach............................................................ 1-15

Critical Success Factors .................................................................... 1-15
Selecting an AIM Implementation Approach................................. 1-18
Multiple Deployment Phase Considerations .................................. 1-21
Level of Process/Requirements Analysis ....................................... 1-22
Acceleration Techniques .................................................................. 1-23
Estimating AIM Projects ......................................................................... 1-28
Managing an AIM Project ....................................................................... 1-31

Tailoring the Method........................................................................ 1-33
Working on Multi-site/Multi-phase Projects ................................. 1-34
Using AIM with a User Method ...................................................... 1-35
CHAPTER 2 Definition ..................................................................................................2-1
Overview ....................................................................................................2-2
Objectives ............................................................................................2-2
Critical Success Factors ......................................................................2-2
Overview Table...................................................................................2-3
Prerequisites ........................................................................................2-4
Processes..............................................................................................2-6
Oracle Method Contents vii

Key Deliverables ................................................................................. 2-7
Approach.................................................................................................. 2-10
Tasks and Deliverables..................................................................... 2-10
Task Dependencies ........................................................................... 2-12
Managing Risks................................................................................. 2-14
Tips and Techniques......................................................................... 2-16
Estimating.......................................................................................... 2-22
Scheduling ......................................................................................... 2-24
Staffing............................................................................................... 2-27
CHAPTER 3 Operations Analysis................................................................................. 3-1
Overview.................................................................................................... 3-2
Objectives ............................................................................................ 3-2
Critical Success Factors ...................................................................... 3-2
Overview Table................................................................................... 3-3
Prerequisites........................................................................................ 3-5
Processes.............................................................................................. 3-6
Approach.................................................................................................. 3-13
Managing Risks................................................................................. 3-20
Estimating.......................................................................................... 3-28
Scheduling ......................................................................................... 3-30
Staffing............................................................................................... 3-34
CHAPTER 4 Solution Design ........................................................................................ 4-1
Overview.................................................................................................... 4-2
Objectives ............................................................................................ 4-2
Overview Table................................................................................... 4-3
Prerequisites........................................................................................ 4-6
Processes.............................................................................................. 4-8
Approach.................................................................................................. 4-13
Managing Risks................................................................................. 4-20
viii Contents AIM Method Handbook

Estimating.......................................................................................... 4-28
Scheduling ......................................................................................... 4-30
Staffing............................................................................................... 4-34
CHAPTER 5 Build ...........................................................................................................5-1
Overview ....................................................................................................5-2
Objectives ............................................................................................5-2
Overview Table...................................................................................5-3
Prerequisites ........................................................................................5-5
Processes..............................................................................................5-8
Key Deliverables .................................................................................5-9
Approach.................................................................................................. 5-13
Managing Risks................................................................................. 5-18
Estimating.......................................................................................... 5-24
Scheduling ......................................................................................... 5-26
Staffing............................................................................................... 5-28
CHAPTER 6 Transition...................................................................................................6-1
Overview ....................................................................................................6-2
Objectives ............................................................................................6-2
Overview Table...................................................................................6-3
Prerequisites ........................................................................................6-5
Processes..............................................................................................6-6
Key Deliverables .................................................................................6-7
Approach....................................................................................................6-9
Tasks and Deliverables.......................................................................6-9
Managing Risks................................................................................. 6-12
Estimating.......................................................................................... 6-16
Scheduling ......................................................................................... 6-18
Staffing............................................................................................... 6-20
Oracle Method Contents ix

CHAPTER 7 Production ................................................................................................. 7-1
Overview.................................................................................................... 7-2
Objectives ............................................................................................ 7-2
Overview Table................................................................................... 7-3
Prerequisites........................................................................................ 7-4
Processes.............................................................................................. 7-5
Approach.................................................................................................... 7-7
Tasks and Deliverables....................................................................... 7-7
Task Dependencies ............................................................................. 7-8
Managing Risks................................................................................... 7-9
Tips and Techniques........................................................................... 7-9
Estimating.......................................................................................... 7-12
Scheduling ......................................................................................... 7-14
Staffing............................................................................................... 7-16
APPENDIX A AIM Work Breakdown Structure .......................................................... A-1
AIM Classic Approach Work Breakdown Structure ............................. A-2
APPENDIX B AIM Roles................................................................................................. B-1
Role Descriptions.......................................................................................B-2
APPENDIX C Role Usages .............................................................................................. C-1
Role Usages ............................................................................................... C-2
APPENDIX D AIM 2 Data Model...................................................................................D-1
Purpose and Objective of the Data Model.............................................. D-2
AIM Data Object Definitions ................................................................... D-4

Relationship to AIM Processes, Tasks, and Deliverables ............... D-4
Relationship to the AIM Glossary .................................................... D-4
Data Object Definitions ..................................................................... D-4
GLOSSARY
x Contents AIM Method Handbook

CHAPTER
1 Introduction to AIM
T his chapter discusses the content and structure of Oracle’s

Application Implementation Method (AIM).
Business Requirements Definition
Business Requirements Mapping
Application and Technical Architecture
Module Design and Build
Data Conversion
Documentation
Business System Testing
Performance Testing
Training
Production Migration
Figure 1-1 Application Implementation Process Overview Diagram
Oracle Method Introduction to AIM 1 - 1

What is AIM?
Oracle’s Application Implementation Method (AIM) is a proven
approach for implementing packaged applications. It is comprised of
well-defined processes that can be managed in several ways to guide
you through an application implementation project. AIM provides the
tools needed to effectively and efficiently plan, conduct, and control
project steps to successfully implement business solutions.
AIM defines business needs at the beginning of the project and

maintains their visibility throughout the implementation. It defines
internal, external, and time-sensitive business events and maps each
event to the responding business and system processes. Using this
method, the business community gains an accurate understanding of
the business requirements to be met by the final system.
AIM was developed primarily for moderate- and large-sized projects,

but is also applicable to smaller projects. Although it is designed to be
used in Oracle Applications projects, with minor changes in technique,
AIM can be applied to other technologies and appropriate products as
well.
AIM meets the demand for faster business solutions. While traditional
implementations make it difficult to realize business benefits quickly,
AIM defines the fastest route to implementation, thereby reducing the
implementation life cycle.
1 - 2 Introduction to AIM AIM Method Handbook

Processes in AIM
AIM tasks are organized into processes. Each process represents a
related set of objectives, resource skill requirements, inputs, and
deliverable outputs. A task can belong to only one process. Project
team members are usually assigned to a process according to their
specialization and background.
Figure 1-2 illustrates the AIM processes and the process overlap that
occurs during a project. The extent to which overlap is permitted is a
function of task prerequisites and the availability of project resources.
Data Conversion
Documentation
Performance Testing
Training
Figure 1-2 Processes in AIM
This section provides a brief overview of the AIM processes:
• Business Requirements Definition

• Business Requirements Mapping
• Application and Technical Architecture
• Module Design and Build
• Data Conversion
• Documentation
• Business System Testing
• Performance Testing

• Training
• Production Migration

Business Requirements Definition defines the business needs that must
be met by the implementation project. You document business
processes by identifying business events and describing the steps that
respond to these events. You then organize processes into scenarios
that reflect the business requirements. The project team conducts a
Current Business Baseline to ensure requirements are considered, then
constructs future business process and function models to portray
future business requirements.
As part of Business Requirements Definition, the company’s financial

and operating structure is identified, business transactions volumes are
documented, and storage requirements are determined. Audit and
control considerations for financial and system administration further
define security and operating requirements.

Business Requirements Mapping compares the business requirements to
standard application software functionality and identifies gaps that
must be addressed to fully meet business needs. Mapping teams are
assigned groups of future business processes, usually related by
business function. Business Requirements Scenarios are then mapped to
application functionality.
As gaps between requirements and functionality emerge, they are

resolved by documenting workarounds, alternative solutions,
application extensions, or by changing the underlying business process.
After business processes have been mapped to the application and gaps
resolved, the project team documents how the business will operate
using the new system.

During the Application and Technical Architecture you design an
information systems architecture that reflects your business vision.
Using the business and information systems requirements, this process
facilitates development of a plan for deploying and configuring:
• Oracle, third-party, and custom applications

• supporting application databases
• critical enterprise interfaces and data distribution mechanisms
between applications, servers, and data centers
• computing hardware including servers and client desktop
machines
• networks and the data communications infrastructure
A coherent and well-designed information systems architecture is a

critical success factor for any implementation project. The information
systems architecture design should be:
• derived from balanced input of business and technical

requirements
• consistent with the corporate business vision and provide the
information technology framework to achieve it
• realistic about the capabilities and limitations of the technology
on which it is based
The first bullet above is especially important because the architecture

part of an implementation project is often considered to be purely
technical in nature, with the resulting risk that the business
requirements are treated as subservient to the technology. A well-
managed architecture project uses the business requirements and
functional mapping as drivers for:
• optimal configuration of the applications being implemented

• hardware and network infrastructure providing the applications
processing
• tools and procedures needed to manage the complete system
To arrive at an architecture for the newly implemented systems, the

architecture team may need to consider the following types of complex
issues:
• the best deployment strategy for the applications across one or

more data centers, business organizations, and business functions
• the high-level configuration of the applications to support
financial, administration, manufacturing, and distribution
business units
• interface points between the applications and/or remote sites,
including specifications, dataflows, and mechanisms

• the deployment and capacity planning for the hardware and
network infrastructure that will support the applications
processing
• management tools and procedures that will enable the system to
continue to operate as intended
Relative to other processes, the architecture process occurs early in an

implementation project. While the formal process is active only during
Definition, Operations Analysis, and Solution Design, architecture
deliverables are required and used throughout the entire
implementation project. This is because the architecture process defines
the framework for the technical aspects of the future system and also for
the project that is defining and creating the new system.
Both application and technical architecture designs become more

detailed and concrete as they progress from Definition through
Operations Analysis to Solution Design. It is important to consider both
aspects of architecture throughout the process so that a top-to-bottom
view of the future system architecture is created early. Any issues that
affect the technical architecture can then be assessed in the context of
the application architecture design, and vice versa.

Module Design and Build produces custom software solutions to gaps
in functionality identified during Business Requirements Mapping.
Custom software solutions include program modules (forms, reports,
zooms, alerts, database triggers) that must be designed, built, and tested
before they can be incorporated into the system. Module Design and
Build addresses the design and development of the custom modules;
Business System Testing supports testing of custom modules.
Working together, technical analysts and business analysts define the

specific custom extensions needed to support the requirements and then
estimate the work effort required to design and build the extensions.
Module designers write functional and technical specifications for each
module that together comprise the detailed design. Programmers code
new modules or modify existing modules based on the detailed design
documents.
Data Conversion
Data Conversion defines the tasks and deliverables required to convert
legacy data to the Oracle Applications tables. The first step of this
process explicitly defines the business objects that are required for
conversion and the legacy source systems that store these objects. The

converted data may be needed for system testing, training, and
acceptance testing, as well as for production.
An overall strategy determines how the conversion requirements will be

met. Both automated and manual methods should be considered as
possible solutions. The conversion process includes designing, building,
and testing the required conversion programs as well as the actual
conversion of the legacy data.
Documentation
Documentation begins with materials created early in the project. Using
detailed documents from the project, the writing staff develops user and
technical material that is tailored to the implementation.
A complete documentation set includes a System Management Guide,

User Guide, User Reference Manual, Technical Reference Manual and
online help text. Producing prototypes for each document encourages
early consensus on documentation design, format, and content.

Early in the project life cycle, Business System Testing focuses on linking
test requirements back to business requirements and securing project
resources needed for testing. It supports utilizing common test
information including data profiles to promote testing coordination and
to minimize duplication of test preparation and execution effort.
Business System Testing provides a formal integrated approach to

testing. The primary deliverable is a high-quality application system,
including packaged applications components and custom extensions.
Performance Testing
Performance Testing enables you to define, build, and execute a
performance test. It does not assume a particular scope for the
performance test. You can use the same process to define a complex
test on an entire system, or a simpler test on a component or subset of
the system. You may also initiate the process more than once on a
project with differing scope and objectives to test the performance of
different aspects of your system. The specific goals of each process and
the relative timing within a project may be different, but the method
you use can be the same.
As a primary benefit, this process provides a powerful and direct means

of assessing the performance quality of your system. Use the results to

make decisions on whether the performance is acceptable for the
business and to help propose tactical or strategic changes to address the
performance quality shortfall. If the performance characteristics you
measure prove to be unacceptable, you can implement tuning to
improve the performance quality or, alternatively, propose a change in
the system architecture to provide the improvement you desire.
Performance Testing is closely related to Application and Technical
Architecture; they are interdependent.
The performance testing team defines the scope of testing and relates it
to point-in-time snapshots of the transactions expected in the real
production system. Technical analysts create or set up transaction
programs to simulate system processing within the scope of the test and
populate a volume test database against which to execute the
transactions. Once the system and database administrators have
created the test environment, the test is executed by the project team
and the final results are documented.
Training
Training prepares both users and administrators to take on the task of
running the new application system. It includes development of
materials and methods, as well as administration. Instructors and
courseware developers orient their material toward roles and jobs, and
not toward application modules.
AIM distinguishes between education and training. Education provides

an understanding of the fundamentals of how the business operates in a
certain type of environment; training refers to the Oracle products and
skills courses.
Production Migration moves the company, system, and people to the
new enterprise system. Following production cutover, it monitors and
refines the production system and plans for the future. The Production
Migration process encompasses transition to production readiness,
production cutover, and post-production support.
During Production Migration, the project team deploys the finished

solution into the organization. This transition depends on Business
Requirements Mapping, Module Design and Build, Data Conversion,
Business System Testing, Training, and Documentation for fully tested
business solutions, custom extensions, conversion programs,
documentation, and training materials. Transition is complete when
data has been converted and verified and users have started using the

new system. When the system is stabilized, regular maintenance and
system refinement begins. In addition, management begins preliminary
planning of the company’s future business and technical direction as it
relates to the new systems.

AIM Project Phases
Conduct an AIM project in phases that provide quality and control
checkpoints to coordinate project activities that have a common goal.
During a project phase, your project team will be executing tasks from
several processes. Figure 1-3 illustrates the relationship between phases
and processes.
Definition Operations Solution Build Transition Production

Analysis Design
Data Conversion
Documentation
Performance Testing
Training
Figure 1-3 AIM Context Diagram
Following is a description of each AIM phase:
Definition
During Definition you plan the project, review the organization’s
business objectives, and evaluate the feasibility of meeting those
objectives under time, resource, and budget constraints. The emphasis
is on building an achievable workplan and introducing it with
guidelines on how the organization will work to achieve common
objectives. Establishing scope early in the implementation gives the
team a common reference point and an effective way to communicate.
Strategies, objectives, and approaches are determined for each AIM
process, providing the basis for the project plan.
To achieve an early understanding of current business operations and

future processes, the team also performs baselining and process
modeling during this phase.

The goal is to identify business and system requirements, propose the
future business model, and determine the current application and
information technology architecture. The information gathered
provides input to downstream activities in subsequent phases. The
team reviews financial, operational, technical, and administrative
processes to verify that everyone understands and agrees on the
detailed business requirements. All business requirements are
associated with planned future business processes. Sharing an accurate
understanding of these requirements is a critical success factor to the
project.
Operations Analysis
During Operations Analysis, the project team develops Business
Requirements Scenarios based on deliverables from Definition that are
used to assess the level of fit between the business requirements and
standard application functionality. Gaps are identified and
corresponding solutions developed. The analysis results in a proposal
for conducting business operations under the envisioned application
technical architecture. Solutions for gaps evolve into detailed designs
during Solution Design.
A model for the application architecture is created and the technical

architecture is designed. The technical architecture includes high-level
hardware, software, and communications components to support the
future business system. The Application and Technical Architecture
documents are used to develop detailed designs during Solution
Design.
To develop models of future business operations you must verify your

initial assumptions regarding solutions for gaps. Solutions may require
only minor modifications to forms, reports, and programs. The team
should explore workarounds to application gaps before considering
custom modifications or new development. If solutions require custom
development, the team prepares high-level solution documents. These
documents include general descriptions of the required features and a
work estimate for each customization. The customization approach and
estimates are approved before detailed design begins during Solution
Design.
The Performance Testing team creates models for testing the

performance characteristics of the new system. These models usually
focus on critical system processing associated with key business
functions and transactions.

Finally, a transition strategy is developed for migrating the company
from the current to the future way of doing business.
Solution Design
The purpose of Solution Design is to develop the detailed designs for
the optimal solutions to meet the future business requirements. During
this phase, project team members create detailed narratives of process
solutions developed during Operations Analysis.
Supporting business requirements may require building application

extensions to standard features; several alternative solutions may have
been defined during Operations Analysis. The project team carefully
scrutinizes these solutions and chooses the most cost effective
alternatives.
To design effective business solutions, you should make sure that

planned user roles and job procedures are efficient. When designing
solutions, consider organizational changes, process improvement, and
reengineering initiatives to the extent that these are within project scope.
These initiatives often affect how application features should be utilized.
While solution designs are being finalized, the application and technical
architecture begins to take form. The technical staff designs a technical
architecture that can support the standard application configuration and
custom solutions and considers the future system architecture needs of
the company. The technical staff also designs performance testing
programs and the environment for executing the performance tests.
As solutions to business requirements are created you will begin to

develop operating documentation. As the system is refined the
documentation is revised.
Business process design is iterative. Tasks that span both Operations

Analysis and Solution Design may be performed as a unit by a design
team.
Build
The coding and testing of all customizations and other custom software
including enhancements, data conversions, and interfaces are done
during Build. Policy and procedure changes relating to business
process modifications are developed. Business system testing is
performed to validate that the developed solutions meet business
requirements.

If customizations, extensions, or conversions are not required, Build is
still important because it includes the business system test, which is
commonly conducted as a formal conference room pilot. The business
system test validates the solutions and is performed in an environment
that closely resembles production.
During Build the performance testing team creates performance testing

components and executes the performance tests. Developers produce
unit-tested program modules. Integration, performance, and business
system tests are performed and a working, tested business system
solution is delivered at the end of the phase.
Transition
During Transition, the project team deploys the finished solution into
the organization. All the elements of the implementation must come
together to transition successfully to actual production. The project
team trains the end users while the technical team configures the
production environment and converts data. Transition ends with the
cutover to production, when end users start performing their job duties
using the new system.
Transition is a demanding experience for the project team and, in

particular, for the end users who have to maintain two systems until
production is declared. Managing changes and buffering your
organizations from negative impacts must be a top priority.
Preparation and planning in advance facilitates the transition process.
If a phased deployment approach is being employed, Transition may

consist of multiple deployments where subsets of the applications may
be deployed to various geographical sites and/or business units at
different times.
Production
Production begins immediately with the production cutover. It marks
the last phase of the implementation, and the beginning of the system
support cycle. Included in this final phase is a series of refinements and
performance measurement steps. The Information Systems (IS)
personnel work quickly to stabilize the system and begin regular
maintenance. They will provide the ongoing support to the
organization for the remaining life of the system. During Production,
you compare actual results to project objectives. System refinement
begins in a controlled manner to minimize impact to end users. Finally,
you start preliminary planning of the future business and technical
direction of the company.

If multiple deployment exists, Production will occur at different times
for the various geographical sites and/or business units.

Determining a Project Approach
When deciding on the project approach for your implementation
consider the following dimensions:
• Scope—project objectives, business functions, sites, and

applications addressed
• Cost/Time/Quality—the balance among cost, implementation
speed, and quality in meeting requirements
• Risk—the potential of an adverse condition occurring that will
impact the project or the organization
• Track Record—the approaches that have or have not worked in
the past for this organization
• Resources—the resource constraints that affect the practicality of
certain project approaches
Critical Success Factors
Critical success factors may affect the selection of a project approach.

The following table shows typical critical success factors and the impact
they can have on the success of the implementation.
Internal/
External to
Critical Success Factor Percent Impact Project
Sufficient infrastructure 10 External
Clear understanding of business 15 External

needs
Upper management support 20 External
Strong program/project 20 Internal

management
Team strength 15 Internal

Internal/
External to
Critical Success Factor Percent Impact Project
Organizational readiness 10 External
Sufficient technical architecture 10 External
Table 1-1 Impact of Critical Success Factors
Sufficient Infrastructure
It is possible to attempt an application implementation where the
demands on the information systems infrastructure are too great.
Determine how far you can realistically stretch the infrastructure over a
specific period of time.
Clear Understanding of Business Needs

Before starting a project, do not assume that the organization has a clear
understanding of its needs. Even if there is a clear understanding of the
perceived business problems to be addressed there may be additional
undocumented issues.
Upper Management Support

Upper Management Responsibilities
Upper management has several key responsibilities that are connected
to project success. They include:
• clearly defining project scope

• resolving major issues in a timely manner
• allocating resources
• instilling a positive attitude throughout the organization
• establishing project priority
• managing the organizational changes associated with the project
• making sure that project management has critical information
about major planned or potential events that could impact the
project

Time/Budget/Quality Considerations
The project budget and schedule must be based on realistic estimates
with appropriate contingencies. If real time and budget constraints
exist, Project Management must work closely with upper management
to ensure an appropriate balance is reached. Frequently, time and
budget constraints are imposed before the project scope has been
determined and a detailed project plan has been developed.
Strong Project Management

A strong project manager identifies problems, determines solutions, and
drives the solution process. An inexperienced or ineffective manager
may be unable to identify problem areas that could escalate and
negatively impact the project. If high risk project approaches (such as
Fast Track implementations) are selected, strong project management is
essential to complete the project successfully
The organization’s willingness or ability to delegate responsibility and

control to the project manager should also impact your selection
approach. If complete responsibility and control is held by the project
manager, communication with upper management can occur through
exception reporting and issues management. Frequently, incomplete
delegation of authority results in responsibility without control. In
these cases, the project manager may not be able to perform effectively
because he does not have the right level of decision making authority.
Fast Track approaches are unusually dependent on full
project/program management authority since decisions must be made
quickly.
Team Strength
Capitalizing on individual and team strengths while compensating for
weaknesses are critical factors affecting the project’s success. Potential
team factors include:
• a strong team with a weak project manager may succeed, but the
risk is high; a weak team with strong project management can
become a strong, effective project team
• a group of strong individuals does not guarantee a strong team;
teamwork is essential

Organizational Readiness
Application implementations cause change and change management
can mean the difference between project success or failure. Project
managers should be tuned to organizational factors impacted by the
project, for example:
• Do various levels in the organization view the project as a

desirable solution to current problems?
• Is the Information Systems department able to absorb new
technology and support the project?
• What is the level of computer literacy? How many people will be
using an automated system for the first time?
• How stable is the organization? Change may be difficult for the
user community if it is also being driven by other initiatives.
• Are all levels of management ready? Authorizing a system
implementation is different than managing the associated
organizational changes.
• Did the user community participate in the system selection?
Greater involvement can mean less resistance to subsequent
changes.
• If the applications will be deployed at various sites, are business
functions performed differently at each location?
• What is the organization’s strategy regarding centralized versus
decentralized planning and control?
• What is the history of system implementation and has it created a
positive mindset regarding future projects?
Selecting an AIM Implementation Approach
AIM defines two implementation approaches:
AIM Classic
AIM processes are conducted with resources and timeframes optimized
for low risk and quality.

AIM Fast Track
AIM processes are conducted with resources and timeframes optimized
to achieve the earliest possible go-live date. However, by accelerating
implementation you assume a greater risk that some requirements may
be missed or you will not achieve the quality of a classic
implementation.
Before you decide to use Fast Track, analyze the associated risks and
weigh the cost and benefits of an early implementation against potential
problems after production.
Ensure that you do not eliminate tasks and deliverables that will have a
serious downstream impact on the project. Every task in AIM is related
to another. If you remove a task, its deliverable will not be available for
related subsequent tasks. Verify that the information contained in the
deliverable will not be required for your project.
Table 1-2 summarizes some of the criteria you should consider in

selecting a Classic or Fast Track implementation categorized by AIM
process.
AIM Processes Classic Implementation Fast Track Implementation
Business Requirements Business requirements not well Business processes documented and
Definition understood. requirements clearly defined and
well understood.
Business process changes are No significant changes to business

anticipated. process that could impact the project.
Business Requirements Moderate to substantial changes Minimal application customizations.

Mapping to the application software may Gaps between requirements and the
be performed. standard application software will be
resolved by changing business
policies and procedures.
Application and Major shifts in computing Little change in technology; solid IS

Technical Architecture paradigm, tools, and skill set.
architecture.

AIM Processes Classic Implementation Fast Track Implementation
Organization has little Sound expertise regarding planned

knowledge or experience in new architecture.
architecture.
Module Design and Significant application software Few or no customizations.

Build changes.
Data Conversion Large conversion volumes and Straightforward data conversion.

moderate to complex
conversion processes and tools.
Documentation Significant custom Few or no changes to standard

documentation required. documentation.
Business System Substantial business system Small scope to the business system
Testing testing required for testing - few customizations, custom
customization, data conversion, interfaces, and data conversions.
interfaces.
Many complex business Few complex business processes.

processes.
Substantial business process Few business process changes.

changes.
Performance Testing Some performance testing Sufficient hardware and network

required. capacity clearly exists. No
performance test required.
Training Requires custom developed Standard training materials and

materials and classes. classes.
Production Migration Complex migration to Simple cutover to production.

production.
Table 1-2 Classic Versus Fast Track Implementation

Multiple Deployment Phase Considerations
Determine if the transition into production needs to occur for all

organizations at the same time. If a phased implementation is planned,
decide what applications will be implemented in each phase. This
combination of choices presents four scenarios:
• Deploy all applications for all organizations at the same time.

• Deploy all applications for different organizations at different
times.
• Deploy subsets of the applications for all organizations at the
same time.
• Deploy subsets of the applications for different organizations at
different times.
Consider the following factors when deciding on a single-phase or

multiple-phase deployment:
• Is the organization facing changes from other sectors? Allow

time for an organization to absorb major changes before
introducing new factors.
• Is the organizational culture amenable to integrating the new
system into its operations? The risk will be less if the
organization is accustomed to using a common system with
related policies and procedures. If business units have been
operating independently the organization must adapt to a
cultural change as well as the new system.
• Can the project team adequately execute the project so that there
is minimal risk in implementing all applications for all
organizations at one time?
• What is the company’s experience with previous system
implementations?
• What is the project team’s experience with previous system
implementations?
• Is the application a production, controlled, or beta release of the
software?
To minimize risk, use the pilot implementation approach. Go live with

a carefully selected subset of users who are well trained and able to deal
with initial problems.

Develop an interface between the applications and the existing system
so that transactions are posted to both systems. This allows the
remainder of the organization to use the current system in parallel with
the pilot implementation. For example, journal entries could post to the
new General Ledger and to the existing General Ledger. This allows
consolidated reporting from the current system until all regions are cut
over.
Along with risk reduction, phased deployment adds complexity and

cost to the project:
• The project duration is lengthened requiring the project team to

remain intact for a longer period of time.
• The phase overlaps can create peak resource loading problems.
You may be starting a new deployment at the end of a previous
one. Production migration needs, startup demands, and support
requirements are occurring in parallel.
• Peaks in computer resource utilization may occur during phase
overlaps due to multiple application database instances being
needed for training, data conversion, and production for the
deployment just ending, and start up tasks for the next
deployment.
Level of Process/Requirements Analysis
The scope of process analysis and requirements definition activity can

vary greatly. For example, the objective may be to minimize
customizations by matching the business processes to the applications.
Or the objective may be to change the applications to match the business
processes because of an overall strategy of minimizing changes to
business procedures.
If the organization intends to replace many business practices, there

may be little need for the team to assess or understand how business is
currently done. On the other hand, if the strategy is to integrate the
applications into current processes, it is critical that the team
understand how the business is currently operating.
At a minimum, each current business process must be identified to

ensure everything is addressed by the project. Substantial time and
expense can be saved by minimizing current process analysis but there
is a tradeoff between cost, time, and risk.

Acceleration Techniques
In certain situations you may be able to condense the project duration

by using acceleration techniques. This is how you can tailor the AIM
Workplan and use a Fast Track implementation approach.
Project Management (PJM) imposes phase start and completion

checkpoints that are valuable for project management and control but
may disrupt natural process/task overlap opportunities and project
flow.
In large, complex implementations, the formal phase signoffs are

needed for scope and risk management. The Classic implementation
approach is the best way to control a project and mitigate risk.
In smaller, less complex projects or for Fast Track implementations,

there may be opportunities to expedite project activities with an
acceptable degree of risk by collapsing tasks within a phase.
Collectively, they will deliver results close to a Fast Track approach.
Examples of acceleration opportunities categorized by AIM processes

follow:
Definition
Definition should always be a standalone phase. Have a milestone and
phase-end checkpoint after Definition and use it to reassess the future
project approach.
Operations Analysis and Solution Design

Collapse Operations Analysis and Solution Design into a single phase.
Start creating design deliverables as the mapping progresses. This is a
popular approach, but incurs greater risk because the Operations
Analysis checkpoint is removed. The full vision of the future system
does not emerge until Solution Design is nearing completion. This
technique increases the risk of major design issues associated with non-
integrated analysis and costly rework, as well as scope creep.
Solution Design and Build

Frequently Build begins while Solution Design is in process. This
technique offers economies in projects with numerous customizations,
but there is a risk of non-integrated designs and scope creep.

Operations Analysis, Solution Design and Build
Collapse the first three phases into a single super-phase. This is only
suitable for small scale projects that are easy to control and that use
alternative risk mitigation steps.
Other considerations:
• If there is uncertainty regarding any aspect of the project, use the

classic approach to assure good checkpoint and risk management.
• By using multiple parallel business process definition/mapping,
teams can speed up Definition and Operations Analysis. Mitigate
risk for this technique by assigning a specific process/solution
team to ensure cross-process integration. Use a project data
repository such as Designer/2000 for custom developed
solutions. The repository automatically cross-validates designs
and enforces integrated solutions.
• If there are minimal large, complex customizations, begin work
on them early because of the timeframes required for designing,
building, and testing major customizations. It may be possible to
selectively overlap specific customizations. To further mitigate
risk, define a formal subproject specifically for a given
customization.
Process Teams for Requirements Definition and Mapping

Process teams formed within a business function to define requirements
should continue into requirements mapping.
Business requirements scenarios created during Definition will be

mapped to the applications during Operations Analysis. The process
teams create scenarios that represent how the process driven business
requirements can be satisfied using the standard application features.
The goal is to arrive at a solution that satisfies the business needs of the
users, resolves current system problems, and optimizes process
efficiency. These solutions can be a combination of several components:
application supported process steps, manual processes or process steps,
application setups, system features, reports, and background processes.
These prototype solutions are interactively developed by project team

members, key users, and application consultants. The application
consultants enable features, set system parameters, and guide process
mapping to illustrate how the new system supports proposed scenarios.
This process continues until a solution is arrived at or an application-
process gap is identified.

This prototyping method expedites the requirements mapping process
by capitalizing on the early knowledge transfer in both directions, from
process teams to application consultant, and from application
consultant to process teams. Internal resources can save time by relying
more heavily on the consultant’s participation and interpretation of
requirements. Less reliance is placed on users’ grasp of new system
functionality and experimentation to arrive at optimal solutions.
Therefore, the project team and users can concentrate on business
process design and leave the mechanics of application set up to the
consultants.
A repetitive implementation process task cycle for business processes are

performed multiple times for different subject areas. For example,
Current Business Baseline, Future Process Model, Business
Requirements Scenarios, and Business Requirements Mapping Form
will occur for each business process. An example is shown in the
following diagram:
Current
Business
Baseline
(Payment
Current Processes)
Business
Baseline Define Future
(Receiving Process and
Current Processes) Function Model
Business (Payment
Baseline Define Future Processes)
(Procurement Process and
Processes) Function Model Define Business
g
e linin (Receiving Requirements
Bas Define Future Processes) Scenarios
Process and (Payment
Function Model Define Business Processes)
(Procurement Requirements
Processes) Scenarios Map Business
(Receiving Requirements
Define Business Processes)
ng (Payment
eli Requirements
Mod Scenarios Processes)
Map Business
(Procurement Requirements
Processes) (Receiving Test Business
ss
u sine Processes) Solutions
gB Map Business (Payment
inin
Def a r io s Requirements Processes)
c e n (Procurement Test Business
S
Processes) Solutions
(Receiving
Processes)
m ents Test Business
uire
Req ing Solutions
p
Map (Procurement
Processes)
ting
Tes e s s
in
B u s tions
S lu
o
Figure 1-4 Repetitive Implementation Process Task Cycle Example

Acceleration Techniques for Module Design and Build
Multiple Tasks for Program Modules
The default Project Workplan for AIM includes a single task for Create
Custom Modules. In reality, this task must be repeated for all the
customizations, conversions, and interfaces required by the project.
When preparing a detailed project plan, add tasks for each individual
program module that must be built and tested. This gives you the
flexibility to assign several programmers to the construction tasks and
perform resource leveling to derive the detailed schedule. There may
also be opportunities for parallel development that can be identified
using this technique.
Prioritization for Customizations

Some customizations identified during Solution Design may not be
critical for initial production cutover. By delaying these Build activities
you can move to Business System Testing and Production Migration
more quickly. Development of these less important programs can
continue in parallel with other activities, but are introduced after
production.
Schedule Optimization
Work closely with the designers so that you can define the inter-module
dependencies in the project plan. You may also wish to assign priorities
so that the auto-leveling feature of your project planning tool can
generate an appropriate schedule. We recommend that you use
resource-driven scheduling for program construction tasks so that
multiple resources can be most efficiently utilized. Fixed-duration
scheduling can be used for Business System Testing since additional
resources may be brought in during this process.
Parallel Design and Development

Since the primary predecessor for program construction is the detailed
design document, the project plan may include Build activities in
parallel with Solution Design activities. If development is accelerated in
this way, some of the assumptions incorporated into earlier designs
could change when later designs are developed, which may require that
the earlier designs are revisited and the related programs updated or
rewritten. This approach could also shorten the lead-time of Module
Design and Build.

Project Tracking
Careful attention to progress reporting, signoffs, and scope control are
particularly important while managing Solution Design. Include
frequent checkpoints and milestones so that you always know the status
of the project.

Estimating AIM Projects
The preliminary application implementation project estimate is based
on:
• What is the business objective?

• What is the vision regarding the solution?
• How do Oracle Applications contribute to the vision?
• What is the scope of the project and how does it relate to the
overall vision?
• Who will participate in the project (employees, consultants,
vendors)?
• What are the constraints affecting the project (timing or budget
limitations, organization changes)?
• Which applications will be implemented?
• What sites will be involved?
• Will a phased deployment approach be employed? If so, in what
sequence will the applications be implemented?
• When will work commence?
• What experience does the organization have regarding the
technology that will be used?
Before creating a detailed work plan, develop the project scope,

suggested approach, and preliminary budget. Use an iterative process
where different project scenarios are defined at a summary level and
then estimated.
Generally accepted industry practices include using experience and

results from similar projects to develop estimates for the different
scenarios.
The final budget should be developed using a detailed bottom up

estimating process based on the detailed work plan. This project plan
should include:
• Work Breakdown Structure (WBS)

• Resource Assignments

• Dependencies
• Deliverables
• Dependency Relationships
Appropriate contingencies should be included in the estimate. Use the

plan to baseline the project and then review and update it on a day-to-
day basis.
AIM includes project planning tools which provide a starting point for
developing the detailed work breakdown structure and contain all the
AIM tasks with associated dependencies, project roles, and deliverable
names.
Table 1-3 summarizes Oracle’s experience in medium size projects. It

presents a “Process as a Percentage of Project Effort” view that is the
result of using the detailed bottom up model. Each cell represents the
process’ percentage of project effort in that phase. The table sums down
for phase totals and across for process totals. For example, Solution
Design is the most work intensive phase of the project and requires 30
percent of the project work effort.
Operations
Production
Transition
Definition
Analysis
Solution
Design
Build
Total
Process (as % of Project Effort)
RD - Business Requirements Definition 4% 2% 6%
BR - Business Requirements Mapping 6% 1% 7%
TA - Application & Technical Architecture 1% 1% 2% 4%
MD - Module Design & Build 0% 0% 6% 5% 12%
CV - Data Conversion 0% 0% 6% 4% 2% 13%
DO - Documentation 1% 0% 4% 2% 7%
TE - Business System Testing 3% 9% 1% 13%
PT - Performance Testing 0% 0% 1% 5% 7%
TR - Training 1% 3% 2% 5% 11%
PM - Production Migration 0% 1% 1% 4% 6%
PJM - Project Management 3% 2% 4% 4% 1% 1% 15%
TOTAL 10% 15% 30% 29% 11% 5% 100%
Table 1-3 Process as a Percentage of Project View
Warning: Use caution in using these estimated percentages

“as is”; you must take into account the specifics of your
implementation.
The following table summarizes Oracle’s experience in medium-size

projects as a “Process Effort as a Percentage of Phase.” Each cell in the

table represents the percentage of phase effort incurred by a process in
each project phase. Phase columns must then total 100 percent, and
process rows sum to process totals.
Operations
Production
% of Total
Transition
Definition
Analysis
Solution
Design
Build
Process (% of Phase Effort)
RD - Business Requirements Definition 36% 17% 6%
BR - Business Requirements Mapping 41% 5% 7%
TA - Application & Technical Architecture 15% 4% 5% 4%
MD - Module Design & Build 1% 2% 21% 17% 12%
CV - Data Conver sion 3% 1% 20% 14% 17% 13%
DO - Documentation 7% 3% 14% 6% 7%
TE - Business System Testing 9% 32% 13% 13%
PT - Per formance Testing 2% 1% 4% 17% 7%
TR - Training 11% 18% 6% 47% 11%
PM - Production Migration 1% 2% 10% 78% 6%
PJM - Project Management 25% 13% 13% 13% 13% 22% 15%
TOTAL Phase 100% 100% 100% 100% 100% 100% 100%
Table 1-4 Process Effort as a Percentage of Phase View
The phase chapters in this manual provide additional estimating tables

that detail the percentage of task distributions by process for the project
roles in that phase.

Managing an AIM Project
Oracle’s Project Management Method (PJM) provides a framework in
which all types of projects can be planned, estimated, controlled, and
tracked in a consistent manner. This consistency is required in today’s
business environment where projects often implement packages,
develop custom solutions, and create a data warehouse in order to
satisfy a business need.
There are two dimensions to PJM. The first addresses What work needs
to be done to manage and support a project. The second is When those
management and support tasks should be performed in the project life-
cycle.
PJM tasks are organized into five processes that help project
management understand What tasks need to be performed for a
successful project. The PJM processes are as follows:
• Control and Reporting determines the scope and approach of the

project, manages change, and controls risks. It contains guides
for reporting progress status externally and for controlling the
Quality Plan.
• Work Management defines, monitors, and directs the work
performed on the project. It also maintains the financial view of
the project for Oracle management.
• Resource Management determines the right level of staffing and
skills for the project, and the working environment to support
them.
• Quality Management implements quality measures to ensure
that the project meets the organization’s purpose and
expectations throughout the project life-cycle.
• Configuration Management stores, organizes, tracks, and
controls all items produced from and delivered to the project. It
also provides a single location from which all project deliverables
are published.
The tasks within each PJM process are assigned to a PJM life-cycle
activity. Each activity is integrated into a project plan that shows when
the project management and support tasks should be performed. The
PJM life-cycle activities are as follows:

• Project Planning defines the project scope, quality, timeline, and
cost. It also determines the appropriate organization of resources
and assigns responsibilities for project tasks.
• Phase Planning tasks update project plans and procedures for
the phase.
• Phase Control tasks execute concurrently with the phase
execution. They perform project monitoring, directing, and
reporting functions.
• Phase Completion tasks conclude and secure sign-off of a phase.
• Project Completion results in the satisfactory conclusion of the
project and settlement of all outstanding issues prior to shutting
down the project.
Figure 1-5 illustrates the relationship between the process and life-cycle
activities in PJM:
Project Project
Phase Management
Planning Completion
Planning Control Completion
Control and Reporting
Work Management
Resource Management
Quality Management
Configuration Management
Figure 1-5 Project Management Life-cycle
Figure 1-6 shows PJM and its relationship with AIM. PJM life-cycle
activities are integrated into the project plan at the appropriate project
and phase levels. Project planning and completion activities are
performed once at the beginning and end of a project, while phase
planning, control, and completion are performed once for each phase of
the project. PJM dependencies do not appear on the critical path.

Initial Intermediate Final
Phase Phases Phase
Project Planning
Phase Planning
Phase Control Control Control Control
Execution Execution Execution
Phase Completion
Project Completion
Figure 1-6 Managing an AIM Project
For more information on PJM, refer to the Oracle Method Project

Management suite of reference books:
• PJM Method Handbook

• PJM Process and Task Reference
• PJM Deliverable Reference
Tailoring the Method
AIM is designed to be flexible. It has standard tasks and activities that

can be tailored to specific user needs. For example, you can combine
tasks from a business process re-engineering project with your
application implementation project.
Keeping it Simple
The standard workplan in AIM is designed to track progress and issues.
It can easily accommodate the integration of subprojects you address
within the following risk areas:
• Plan resources.
• Track budget to actuals.
• Adhere to project scope and terms.

• Follow an efficient and complete design, build, and transition
route.
• Provide for a quality control mechanisms for key deliverables.
• Communicate progress and future tasks.
• Manage the system environment.
The implementation process you design with your user influences the
tasks and dependencies in your workplan. If a hybrid method will be
used, ensure that the dependencies are preserved.
Adding and Removing Tasks

Some tasks are optional depending on the project. For example, if a
user does not require software modifications, the related design, build,
and test tasks are not necessary. However, a project may also need
tasks added. If a business process re-engineering effort is conducted
instead of doing a current process baseline, new tasks must be defined
and entered.
Customizing Templates and Deliverables

You can use the standard features in AIM to perform some
customizations to templates. For example, you can add a company logo
or make Microsoft Word style changes that suit your user’s preferences.
You can also make global variable changes to documents that will
rename key processes using company terminology.
Working on Multi-site/Multi-phase Projects
The AIM project plan includes all the necessary tasks to implement
Oracle Applications, although some tasks may be optional depending
on the project. Large or multi-site projects may require that repeated
tasks, such as administration and standards creation, be moved to a
central repository and shared between projects. When a task is elevated
to the enterprise level, the same task in AIM takes on a different form.
These AIM tasks are transformed into reviews of the enterprise
deliverables. However, the AIM tasks can also modify the enterprise
deliverable to incorporate the local requirements.

Using AIM with a User Method
Sometimes a project team member or user wishes to use their own

project method. When this occurs, do a detailed fit and gap analysis
between the methods. For any identified gaps, incorporate the
appropriate AIM tasks and dependencies into the user’s method. Make
sure that the associated deliverables will be produced and develop a
gap strategy for all remaining open issues.

CHAPTER
2 Definition
T his chapter describes the Definition phase of AIM. The goal of

Definition is to determine the business and information system’s
high-level requirements necessary to meet a set of defined business
objectives.

Analysis Design
Data Conversion
Documentation
Performance Testing
Training
Figure 2-1 Context of AIM Definition Phase
Oracle Method Definition 2 - 1

Overview
This section provides an overview of Definition.
Objectives
The objectives of Definition follow:
• Obtain a clear understanding of the business processes, functions,

and information required to meet the project’s defined business
objectives.
• Develop a high-level conceptual architecture.
• Determine the high-level architectural, technological, and
configuration requirements to support the functional and
information needs of the application.
• Defines the project scope clearly.
• Obtain management approval to proceed with Operations
Analysis.
• Optional: Examine the existing business processes and
information systems affected by the project’s defined business
objectives.
The critical success factors for Definition follow:
• clear definition of the business objectives to be addressed

• active participation by key management and knowledgeable user
and technical representatives from the areas of the business
affected by the project’s objectives
• access to information related to the existing business processes
and systems affected by the project
• detailed, thorough, and documented process modeling sessions
• effective project management of scope and issues
• sufficient time and resources
2 - 2 Definition AIM Method Handbook

Overview Table
This table illustrates the prerequisites, processes, and key deliverables

for Definition.
Process Prerequisites Key Deliverables
Business Requirements Business Process Reengineering Business Volume Requirements

Definition Studies
Existing Reference Material Current Business Baseline
Future Business Strategy Financial and Operations Structure
High-Level Existing System Data Future Business Function Model

Model
Original Justification for Business Future Process Model

Systems Investment
Sales and Presales Material Process and Mapping Summary
Application and Technical Architecture Designs and Technical Architecture Scope, Objectives and
Architecture Documents from Sales Cycle Approach
Existing System Architecture or Architecture Requirements

Technical Configuration
Documents
Existing System Management Architecture Strategy

Procedures Documents
Existing Systems Architecture Conceptual Architecture

Strategy or Policy Documents
Technical Architecture Baseline
Module Design and Build Customization Strategy

Data Conversion Legacy System Documentation Conversion Scope, Objectives and

Approach
Conversion Strategy
Documentation Business Documentation Standards Glossary Documentation

and Guidelines Requirements
Documentation Standards and

Procedures
Performance Testing Application User Manuals Performance Test Scope, Objectives

and Approach
Performance Testing Strategy
Training Training Material Standards and Education and Training Plan

Guidelines
Current Training Resources Trained Project Team
Table 2-1 Definition Phase Overview Table
Prerequisites
Prerequisites for Definition follow. You should use these prerequisites,

if they exist, prior to beginning the project. Otherwise, you may need to
create them during Definition.
Prerequisite Source
Application Manuals Client
Architecture Designs and Technical Client

Documents from Sales Cycle
Business Documentation Standards Client
Business Process Reengineering Client

Studies

Prerequisite Source
Existing Reference Material Client
Existing Systems Architecture Client

Strategy or Policy Documents
Existing System Architecture or Client

Technical Configuration Documents
Existing System Management Client

Procedures Documents
Future Business Strategy Client
High-level Existing System Data Client

Model
Legacy System Documentation and Client

Guidelines
Original Justification for Business Client

Systems Investment
Performance Testing Standards and Client

Guidelines
Sales and Presales Material Client
Table 2-2 Definition Phase Prerequisites

Processes
The processes used in this phase follow:

Complete baseline understanding of current events and business
processes. Develop process and function models of future business
operations. Gather volumes of business transactions and storage
requirements. Establish repository of key process and mapping
information, as well as decisions.

Identify the scope, objectives, and strategy you will use for the
architecture process. Collect the high-level business requirements and
policies affecting architecture. Create a conceptual integrated model
application and technical architecture.

Define a strategy for extending and customizing the applications and
developing custom interface software.
Data Conversion
Define the Conversion Scope, Objectives, and Approach, and prepare
the Conversion Strategy.
Documentation
Define a glossary of terms for the project. Specify the documentation
requirements and determine the documentation standards and
procedures.
Performance Testing
Identify the scope, objectives, and strategy you will use for the
performance testing process, including measurements to make, testing
methods, and testing tools.

Training
Plan education and training for the project team. Deliver skills and
applications education to prepare team members for process modeling
and requirements definition.
Key Deliverables
The key deliverables of this phase follow:
Deliverable Description
Architecture Requirements Documents the high-level

requirements for the architecture of
the new systems. The requirements
are classified by whether or not they
constitute policies for the new
business systems.
Architecture Scope, Documents the scope of the

Objectives, and Approach architecture process, the objectives of
the design, and the approach that
you will use. This is created if a
more precise definition of scope,
objectives, and approach is needed
for an architecture subproject.
Architecture Strategy Documents the strategy that you will

use for the architecture process. It
includes a discussion of the methods,
tools, and techniques that you will
employ to perform the work outlined
in the scope document.
Business Volume Inventory of key transaction and data

Requirements volumes by business functional area.

Conceptual Architecture Documents the conceptual

architecture for the new systems. It
is a high-level view of the new
application and technical architecture
and is intended as a working model
for the architecture work and for the
broader project team. It is also the
primary vehicle for communication
of the future information system’s
architecture to management.
Conversion Scope, The conversion requirements and

Objectives, and Approach related scope, objectives, and
approach.
Conversion Strategy The conversion strategy for

implementing the defined conversion
requirements.
Current Business Baseline An analysis of the current business

processes and functions.
Customization Strategy A strategy document that describes

how the project will respond to
customization requests.
Documentation The business needs that must be met

Requirements by project documentation.
Documentation Standards The standards and procedures to be

and Procedures applied to project documentation.
Education and Training Plan Contains the training schedule for

courses. Determines the resources
needed for preparing training and
holding the session. Also assesses
general education course needs.
Financial and Operating A depiction of the financial structure

Structure and the operating organizations of
the company.

Future Business Function Catalogs the elementary functions to

Model be supported within future business
processes.
Future Process Models Contains Process Flow Diagrams of

the events and business processes
that will be supported by the
applications and functions of the
business area.
Glossary Documents the definitions of key

terms used throughout the project.
Performance Testing Scope, Documents the scope of the

Objectives, and Approach performance testing process, the
objectives of the testing, and the
approach that you will use.
Performance Testing Documents the strategy that you will

Strategy use for the performance testing
process. It includes a discussion of
the methods, tools, and techniques
that you will employ to perform the
work outlined in the scope
document.
Process and Mapping A summary of key processes,

Summary business requirements, and mapping
decisions.
Technical Architecture Documents technical information

Baseline about the existing legacy systems,
including the applications, hardware,
networks, and interfaces.
Trained Project Team Project Team members qualified to

transfer knowledge to the
constituents they represent.
Table 2-3 Definition Phase Key Deliverables

Approach
This section describes the approach for Definition.
Tasks and Deliverables
This table lists the tasks executed and the deliverables produced during
Definition.
ID Task Deliverable

RD.010 Identify Financial and Operating Structure Financial and Operating Structure
RD.020 Conduct Current Business Baseline Current Business Baseline
RD.030 Develop Future Process Model Future Process Model
RD.040 Develop Future Business Function Model Future Business Function Model
RD.050 Establish Process and Mapping Summary Process and Mapping Summary
RD.060 Gather Business Volumes Business Volume Requirements
TA.010 Define Architecture Scope, Objectives, and Architecture Scope, Objectives, and
Approach Approach
TA.020 Prepare Architecture Strategy Architecture Strategy
TA.030 Establish Architectural Requirements Architecture Requirements
TA.040 Develop Conceptual Architecture Conceptual Architecture
TA.050 Conduct Technical Architecture Baseline Technical Architecture Baseline
MD.010 Prepare Customization Strategy Customization Strategy
Data Conversion
CV.010 Define Conversion Scope, Objectives, and Conversion Scope, Objectives, and
Approach Approach
CV.020 Prepare Conversion Strategy Conversion Strategy
Documentation
DO.010 Prepare Glossary Glossary
DO.020 Specify Documentation Requirements Documentation Requirements
DO.030 Determine Documentation Standards and Documentation Standards and
Procedures Procedures

ID Task Deliverable
Performance Testing
PT.010 Define Performance Testing Scope, Objectives, Performance Testing Scope,
and Approach Objectives, and Approach
PT.020 Prepare Performance Testing Strategy Performance Testing Strategy
Training
TR.010 Prepare Training Strategy Education and Training Plan
TR.030 Conduct General Education Classes Trained Project Team
TR.040 Conduct High-level Overview of Application Trained Project Team
Features
Table 2-4 Definition Phase Tasks and Deliverables

Task Dependencies
This diagram shows the dependencies between tasks in Definition.
Definition
RD.020 RD030
Conduct Current Develop Future
Business Baseline Process Model
RD.020 RD.030
BUSINESS
REQUIREMENTS
RD.010
DEFINITION Identify Financial
and Operating
Structure
RD.010
TA.010 TA.020 TA.030

Define
Prepare Establish
Architecture
APPLICATION AND Architecture Architecture
Scope, Objectives,
TECHNICAL Strategy Requirements
and Approach
TA.020 TA.030 TA.050
ARCHITECTURE TA.010
Conduct Technical
Architecture
Baseline
TA.050
M ODULE DESIGN
AND BUILD
D ATA
CONVERSION
DOCUMENTATION
TR.030
Conduct General
Education Classes
TR.010 TR.030 TR.040
T RAINING Conduct High-level
Prepare Training Overview of
Strategy Application
TR.010 Features
TR.040
PT.010 PT.020
P ERFORMANCE Performance Prepare
Testing Scope,
TESTING Performance
Objectives, and Testing Strategy
Approach
PT.020
PT.010
Figure 2-2 Definition Phase Task Dependencies

Definition
RD040 RD.080
Develop Future Gather Business
Business Function
Volumes
Model RD.060
RD.040
BUSINESS
R EQUIREMENTS
RD.050
Establish Process D EFINITION
and Mapping
Summary
RD.050
TA.040
Develop
Conceptual APPLICATION AND
Architecture T ECHNICAL
TA.040
ARCHITECTURE
MD.010
Prepare
Customization
M ODULE DESIGN
Strategy AND BUILD
MD.010
CV.010 CV.020
Define Conversion Prepare DATA
Scope, Objectives, Conversion
and Approach Strategy CONVERSION
CV.010 CV.020
DO.010 DO.030 DO.020

Determine
Documentation Specify
Prepare Glossary Documentation DOCUMENTATION
Standards and
DO.010 Procedures Requirements
DO.020
DO.030
TRAINING
P ERFORMANCE
TESTING
Figure 2-2 Definition Phase Task Dependencies (cont.)

Managing Risks
The areas of risk and mitigation for Definition include the following:
Risk Mitigation
Management, users, or Have clearly stated objectives from

project team not committed executive management and regular
to the magnitude of change. reporting to executive steering
committee.
The tendency to preserve old Select key area team leaders who
processes and not develop support the need for change, can
new ones. facilitate change in their areas, and
are knowledgeable about their areas
and processes.
Knowledgeable users not Assign a project sponsor role to a

involved in current and leader from the user community who
future process definition. can promote a high level of
commitment from key users and will
nurture support for project team
members as they work outside their
normal jobs and duties.
Project team not adequately Conduct process modeling sessions

trained in process modeling for team members; have them
techniques. demonstrate required skills with a
qualified instructor.
Missed or incomplete Have functional executive

processes and unidentified management review the integrated
events. process model and event catalog for
completeness.
Process model does not Have representatives from each

tightly couple all integrated process team review the process
processes. models from other teams.
Insufficient data gathered on Have both functional and

volumes and processing information processing management
windows. review and agree upon volume and
processing windows.

Risk Mitigation
Incomplete definition of Create a project organization that

scope for the architecture enables input and consideration of
work. business, functional, and technical
requirements in architecture.
Treatment of the architecture Consider business requirements and

as a purely technical pursuit functional mapping as well as
and inadequate consideration technical requirements as drivers for
of business requirements as the optimal configuration and
drivers for architecture deployment of the applications being
(bottom-up approach). implemented.
Lack of project team Screen project team candidates for

expertise in application prerequisite skills and experience.
deployment strategies or
advanced technical
architecture.
Lack of involvement or sign- Communicate conceptual

off by senior management of architectures to senior management
key architecture strategies, and organize a review, if appropriate.
plans, and issue resolutions.
Inadequate or non-existent Appoint a quality manager who has

quality assurance in the responsibilities for quality assurance
implementation project. and enforcing review and approval
procedures.
Imprecise definition of scope Ensure that the scope and objectives

and objectives for for performance testing are made
performance testing, leading clear by senior management, and that
to false conclusions . they understand what performance
testing can or cannot achieve or
predict.
Lack of a structured method Use a structured method for

for performance testing, performance testing to ensure that
leading to measurements that the test results can be interpreted in
are difficult to interpret the context of their meaning for the
relative to the target real production system.
production system.

Risk Mitigation
Lack of appreciation of the Have a member of the performance

dependency of performance testing team review the work and
testing on good quality deliverables relating to application
applications setup data and setup and conversion.
data conversion programs.
Lack of project resources to Plan ahead so that the required

provide a controlled, resources are available for this
segregated performance test activity.
environment.
Conversion requirements, Discuss conversion requirements

scope, and objectives not with the client early in the project
clearly defined. life-cycle. Encourage the client to
make decisions that impact the
conversion scope during Definition.
Conversion strategy not Make decisions about the conversion

clearly documented and strategy (such as using automated
understood. conversion tools during Definition)
and communicate this strategy to the
client.
Documentation standards Require documentation standards

and procedures poorly and procedures input and approval
defined or incomplete. from key client areas involved in
using the final documentation.
Training requirements not Create a detailed set of training

fully developed. requirements listing expected roles
that are within the project scope.
Table 2-5 Risk Management Table for Definition
Tips and Techniques
This section provides tips and techniques for managing Definition. In

addition, advice and comments on each process are included.

Business Requirements Definition begins in Definition with the task of
constructing the current business baseline in order to understand the
events to which existing business processes currently respond. This
examination of current requirements expands to create a vision of how
future processes and requirement scenarios will respond to those
events, as well as any additional ones anticipated by the company’s
future business strategy. Model the future processes with both process
models and function models to ensure sufficient breadth and depth of
process definition.
The operating and financial structure of the business entity affects

application and technical architecture definition as well as set up.
Gather and formalize business volumes and use them to determine
storage and performance requirements.

Architecture work performed during Definition complements the
business requirements definition and helps to provide the technical
framework for subsequent phases of the project. Substantive work on
architecture needs to occur relatively early in an implementation project
because it underpins the technical environment of all other project
activities. At the completion of this phase, the architecture team should
have defined the critical architecture requirements and policies and
should have as much information as needed about the existing technical
architecture. They should also have identified a preferred conceptual
architecture that incorporates the new systems being implemented.
The architecture team defines the scope of the project architecture work
in this process. Issues and scope vary from project to project, so it is
important to set detailed parameters for the work early in the project.
An important part of the scope is to establish to what extent the project
is defining the architecture and information systems strategy for the
evolving business. If the project is replacing a subset of the existing
systems, the architecture of the newly implemented systems will need
to be consistent with the existing systems architecture and the
information systems strategy for the business. If, however, the project is
replacing most or all of the major existing systems in the business, the
architecture of the newly implemented systems will assume an added
importance in helping to define the future information systems strategy.
The existing technical architecture of a business may or may not be

important for the implementation of a new system, depending on the
scope of the implementation. If the existing legacy systems are to be

completely or largely replaced and/or the project is a Fast Track
implementation, gathering information about the existing systems may
not be necessary. Conversely, an implementation that will reuse the
existing business technical infrastructure, or will integrate with
preserved existing systems, may require additional work to understand
the technical components of the existing systems.
The application architect works closely with the technical architect to

create a prototype architecture that satisfies the high-level business and
information systems requirements and policies. The prototype
Conceptual Architecture forms the basis of the architecture working
model for the project and covers both application and technical
architecture. After this stage the Conceptual Architecture is preliminary
and will be in a format that both non-technical project managers and
sponsors can understand. If there are multiple architectural options,
this deliverable should present the options and their tradeoffs, and the
review of the Conceptual Architecture will include a decision regarding
which option to use as a working architecture model. Even in projects
where the architecture is fairly clear cut (such as a single application
installation on a single database server) creating a conceptual view of
the architecture so that senior management understands the architecture
and technical direction of their business can still be useful.

A worthwhile goal of any implementation is to use the Applications as
they were designed; in other words, without customization. However,
most projects include custom development, even if it is limited to
interfaces and custom reports. Descriptive Flexfields, Alerts, and
Zooms are also customizations, even though you can implement them
without traditional coding.
The Customization Strategy outlines the customization philosophy, such

as minimizing customization as much as possible. It also describes the
development tools developers will use for each type of module.
An important part of the strategy is how much overlap is acceptable

between phases. For example, some of the functional teams may
complete their mapping earlier than others. Should designers begin
writing design documents for required custom extensions before other
teams have completed their mapping? After the team approves some
design documents, should programmers begin building custom
modules before other designs are completed? Allowing some overlap
can speed up the implementation; however, it increases the risk of
rework, since solutions arrived at later may affect earlier decisions.

Data Conversion
Definition provides the client with two deliverables that define
Conversion Scope, Objectives, and Approach and Conversion Strategy.
Detail the client’s conversion requirements (both programmatic and
manual conversion requirements) when defining Conversion Scope,
Objectives, and Approach. These requirements then form the
foundation for documenting the Conversion Strategy. This strategy
should provide a complete solution for meeting the client’s conversion
requirements. If an automated tool provides the best conversion
solution for your client, then discuss this in the Conversion Strategy
document.
The two conversion tasks in this phase are prerequisite tasks for
preparing the project workplan and estimate. Prepare the initial project
workplan and estimate after the Conversion Scope, Objectives, and
Approach task is complete. Revise the project workplan and estimate
after the Conversion Strategy deliverable is prepared.
Documentation
The documentation process addresses the needs of users, technical, and
operations staff. Designate a key resource from each area as part of the
committee that specifies documentation requirements, standards, and
procedures. The detailed documentation plan should identify all
sources of information required by the documentation team, as well as
roles and responsibilities for reviewing the deliverables.
The glossary documents the vocabulary of a project and should include

unfamiliar or confusing terms. The business community, IS
department, and project team should participate in the selection of
words for the glossary and reach agreement on the definitions. The
glossary often includes terms that describe the new system
functionality, or words whose meanings are changing from the old to
the new system.
Performance Testing
The Performance Testing Scope, Objectives, and Approach, and Strategy
tasks define the high-level scope for this process, the requirements for
testing, and the main tools and techniques that will be used. The
complexity of the test and any specialized resources needed to perform
the work are also documented.
Decide whether to use some form of automated testing tools in the

Performance Testing Strategy. Some automated load testing tools can

provide the means to simulate complex processing environments with
many simultaneous online transactions. However, these tools are
generally costly and require special expertise and training. If this
process will not employ an automated tool, then the team will have to
devise other methods for conducting the test.
The timing of when to initiate a performance test will depend on the

precise scope and goals of the project. If the test objective is to provide
metrics to support architectural decisions (for example, the capacity
needed for a database server, or the performance viability of a
centralized or distributed hardware configuration), the test should
probably be conducted early in the implementation project. If a test
objective is to validate business processes throughout the project, then it
may occur in the middle of a project. At the very end of a project,
performance testing may help to tune the system. The same test
programs can be reused throughout the project life-cycle.
Performance testing usually requires a controlled test environment that

may mean isolating the test from other project work, on separate test
machines. This may also be wise from the standpoint that a
performance test may put an undue load on servers and networks and
could severely impact other project processes in shared environments.
Plan the test environment and identify hardware that is available to the
test team in Definition. Ideally, the technical hardware and software
environment should be identical to the production environment, but
this may not be possible depending on project circumstances. If it is
not, you should try to minimize the differences and establish the impact
on the test results. If the test will require a volume test database, you
will also need to plan for significant disk capacity.
Training
The project team must prepare to take on the challenges of business
process redesign and systems implementation. The more they know
about proven methods for adapting the business to a new system, the
more they will perform an advocacy role. The team must gain an
understanding of the fundamentals of application implementation and
how the business must operate in the new environment. The team must
acquire a conceptual level of knowledge about application features and
functionality. Additionally, courses to improve their skills (such as
project management skills, manufacturing principles and practices, and
so on) must be delivered.

This page intentionally left blank.

Estimating
The following table indicates the typical percentage of effort required by

each task by role.
Application Administrator
Business Line Manager
Database Administrator
Client Project Manager
Configuration Manager
Applications Architect
Applications Expert
Database Designer
IS Operations Staff
Business Analyst
Phase Effort
IS Manager
Facilitator
Analyst
Definition
ID Task %
Business Requirements Definition 36.1%
A.RD.010 Identify Financial and Operating Structure 0.9% 100 0
A.RD.020 Conduct Current Business Baseline 9.0% 90 0 10
A.RD.030 Develop Future Process Model 18.1% 90 0 10
A.RD.040 Develop Future Business Function Model 5.4% 100
A.RD.050 Establish Process and Mapping Summary 0.5% 100 0
A.RD.060 Gather Business Volumes 2.2% 100 0
Application & Technical Architecture 15.0%
A.TA.010 Define Architecture Scope, Objectives, and Approach 0.9% 10 0
A.TA.020 Prepare Architecture Strategy 1.1% 10 0
A.TA.030 Establish Architecture Requirements 1.6% 45 10 0
A.TA.040 Develop Conceptual Architecture 8.6% 40 20 0 0
A.TA.050 Conduct Technical Architecture Baseline 2.7% 20 0 0
Module Design & Build 1.4%
A.MD.010 Prepare Customization Strategy 1.4%
Data Conversion 2.7%
A.CV.010 Define Conversion Scope, Objectives, and Approach 1.4% 0
A.CV.020 Prepare Conversion Strategy 1.4% 0
Documentation 7.3%
A.DO.010 Prepare Glossary 1.8% 95
A.DO.020 Specify Documentation Requirements 2.7% 85 0
A.DO.030 Determine Documentation Standards and Procedures 2.7% 0
Performance Testing 1.8%
A.PT.010 Define Performance Testing Scope, Objectives, and Approach 0.9% 0
A.PT.020 Prepare Performance Testing Strategy 0.9% 0
Training 10.8%
A.TR.010 Prepare Training Strategy 1.9% 0 0
A.TR.030 Conduct General Education Classes 4.0% 0
A.TR.040 Conduct High-level Overview of Application Features 4.9% 0
Project Management 24.9%
PJM Manage Phase 24.9%
CONT Contingency 0.0%
100.0%
Table 2-6 Definition Phase Estimating

0
IS Support Staff
Lead Tester
Module Designer
5
Network Adminstrator
Oracle Method
Production Database Administrator
Programmer
5
Project Database Administrator
5
Project Manager
60
15
30
10
30
30
0
0
0
0
0
Project Sponsor
Quality Auditor
5
Systems Administrator
System Architect
Table 2-6
Team Leader-Architecture
80
40
45
50
50
Team Leader - BR
0
Team Leader-Conversion
20
Team Leader-Customization
25
Team Leader-Documentation
30
10
Team Leader - Mapping
Team Leader-Performance Testing
70
55
Team Leader - Testing
5
5
Team Leader-Training
30
Technical Analyst
15
80
90
Technical Architect
10
10
Technical Expert
75
Definition Phase Estimating (cont.)

Technical Expert - Build
Technical Expert - Design
Technical Expert - Environment

5
Technical Expert-Existing Systems
Technical Writer
70
Tester
Trainer
95
95
10
0
0
0
0
0
0
0
User
Definition 2 - 23
Task Summary
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
Scheduling
The critical role during Definition is the analyst. By assigning more

analysts during this phase, you may be able to shorten the critical path.
Key decision makers in the user and upper management communities

are frequently on the critical path. Although their availability can
impact the project schedule and the quality of decisions, their schedules
can be difficult to predict. Upper management should encourage key
personnel to allocate sufficient time to the project.
Be realistic about the number of resources that can be applied to a task

effectively. In general, you should stop adding resources to a role when
average utilization starts to fall below 100 percent of the target. This is a
symptom that the incremental communication and administration
associated with adding resources is reducing productivity. Allow a
time contingency in the schedule to cover unforeseen events or delays.
Scheduling Suggestions
Scheduling suggestions for Definition follow:
Project Management
During Definition, spend sufficient time developing a sound project
plan with associated resource and cost forecasts. For moderate to large
projects it is not unusual to spend several person weeks developing a
good plan. The critical path is a sequence of critical tasks throughout
the project. If one of those tasks takes one day longer than planned, the
end date of the project will be one day later. Tasks not on the critical
path have slack; they can be completed later than planned without
affecting the end date for the project.
Warning: Avoid planning with too much detail. It is

tempting to define tasks at a very detailed level during
planning. However, later you may discover that tracking
progress at this level is so time consuming that you abandon
tracking altogether.

An organization may want to implement the applications as quickly as
possible with minimal customizations and, if necessary, change the way

they do business to match the application’s functionality. In other cases,
the approach is to minimize operational changes by appropriately
customizing the applications.
The need for thorough fact gathering and analysis regarding current
business processes depends on how much business change is expected.
At a minimum, you need to identify all business processes and
functions that will be affected by the implementation and develop a
sufficient understanding of those processes and functions to determine
how to change them to match how the applications work.

Carefully consider the timing of this work. Too often the need for
additional hardware, systems software, and data administration time is
identified after the project budget has been finalized.
This can be an opportunity to use external consulting resources in a

cost-effective way. Consultants can have a large impact in a short time.
In this way important knowledge can be transferred to local staff and
correct sizing estimates and architectural decisions can be made.
Consider the impact of a multi-phased deployment on the scheduling of

this process. For example, you may elect to go live with the new
applications at different times at different sites. In this case, your
technical architecture may need to grow over time to support the
phased deployments.

Module Design and Build scheduling depends on several factors that
can be determined during Definition, for example:
• When will you need the development environment?

• When will you begin to bring developers onto the team?
• What is your approach to establishing test data so your
developers can test their custom software?
• What kinds of technical design, coding, testing and
documentation standards do you need, and when must they be
ready?

• Will you deploy the applications in multiple phases? If so, over
what period of time will you need development resources? Will
you be doing all custom software development up front, or will
you do customization, interface, or conversion custom
development for each deployment phase?
Seek an optimally sized development group. Development activity

seems to be more sensitive to the size of the group than other activities.
Avoid too large of a group, which can introduce inefficiencies due to
incremental communication and administrative time requirements as
the number of people increases.
Data Conversion
The Data Conversion tasks from subsequent phases can be performed in
Definition if the existing systems data is well understood and no
significant issues arise. The benefit of an early execution of Data
Conversion is the support for module and module integration testing in
Module Design and Build.
Documentation
Determine what documentation will need to be produced. For example:
• Will you produce a user manual? If so, what will it contain?

• What kind of technical documentation will be produced?
• If multiple deployments will occur for different business units,
will user documentation be different for each deployment? Will
all business units use the applications in the same way?
The scope of the user and technical documentation to be produced and

the techniques used to create this material can have a major impact on
the project schedule.
Performance Testing
Early in the project, assess the risk of encountering performance
problems. If there is significant risk, incorporate Performance Testing in
the project plan. Consider the following questions:
• What will the system load be?

• What technical architecture will be provided?
• What are the system’s performance requirements (for example,
response time, report creation, and delivery time)?

Staffing
This diagram illustrates a typical project organization for Definition.
Definition Organization
Project Management
Project Management Administrative Assistant/

Support Team Project Librarian
Configuration Management Resource Management
Control & Reporting Quality Management
Resource Management Oracle Product/SupportLiaison
Oracle Account Manager Data Base Administration
Business Requirements Technical Architecture &

Definition & Mapping Performance Testing
Existing Systems
Examination
Functional Area
Team
(A)
Team Lead
Team Members
Functional Area
Team
(B)
Team Lead
Team Members
Business Process
Integration
Data Conversion Training &

Documentation
Figure 2-3 Staffing Chart for Definition

Staffing Suggestions
This section provides advice and comments on project organization for
Definition.
Project Management
One of the most important decisions for an application implementation
is the kind of project management team that will be established. A full-
time project manager should be provided for all but the smallest
application implementation projects.
If the complexity of a project goes beyond a certain point, frequently

driven by the need for multiple deployment phases, you may need to
treat the effort as multiple projects.

A key staffing requirement is recruiting analysts with good
interpersonal skills, a knowledge of the business and application
functionality, and sufficient data conversion expertise to conduct
preliminary conversion analysis. If applications will be deployed in
phases at multiple sites, your analysis activities will be more complex,
which may require more experienced staff. For example, a phased
deployment may mean that some sites will be using the new
applications, while others are still using the legacy systems. This can
necessitate the use of temporary bridge systems. Until all sites are
deployed, these systems pass transactions to the appropriate system
used for consolidating reporting.

This process must be staffed by an experienced technical architect. A
multi-phased deployment approach may complicate the technical
architecture by introducing time phased requirements. In this case, be
sure your technical architect has experience with this approach.

The key Definition activity for this process concerns design and
planning for establishing the development environment. Ensure that
someone skilled in development management is available for this task.
A phased deployment approach may significantly affect the timing of

staffing needs for Module Design and Build. For example, if you are
deploying to different sites at different times, you may need to develop

custom software associated with various deployments. This could
significantly affect the timing of your staffing needs.
Data Conversion
This process requires individuals skilled in analysis, programming,
testing, performance tuning, and transition. During this phase, you
need someone who can perform high-level analysis tasks to identify
data conversion needs.
Software tools that can significantly improve productivity are available

from various vendors. Using these tools may require lead time for
evaluation, acquisition, and installation. If you use such a tool, you may
need staff with related expertise.
If you deploy in multiple phases, you will need to perform data

conversions at different times. This affects the timing of your staffing
needs.
Documentation
Since this phase includes finalizing the documentation strategy, you
need staff that can advise you on various documentation approaches.
Determine if new documentation will be required or existing
documentation will be updated.
A multi-phased deployment approach may require documentation tasks

to be performed for each deployment. If various business units do
business in different ways, some user documentation may need to
change for each deployment. This would affect the timing of related
staffing requirements.
Performance Testing
Specialists are required to effectively perform this process. Decisions
regarding whether such staff will be needed are made in this phase.
If you deploy in multiple phases, you may need a phased Performance

Testing approach. Make sure that the maximum load your system will
experience after all deployments can be handled by the planned
configuration. This consideration could affect the timing of staffing
needs.

Training
Decisions about the training approach are made in this phase; therefore
you need staff that can advise you on approaches. For example, you
might decide to:
• develop custom training

• use standard Oracle training
• use Oracle instructors at your site
• use internal people as trainers with a separate class to “train the
trainers”
• train Information Systems analysts to support the new
applications
• conduct separate training for each deployment in a multi-phased
project
Decisions related to these issues will impact your staffing requirements.

CHAPTER
3 Operations Analysis
T his chapter describes the Operations Analysis phase of AIM. The

goal of Operations Analysis is to formulate the detailed
requirements for the computer application system and to propose a
solution.

Analysis Design
Application & Technical Architecture
Module Design & Build
Data Conversion
Documentation
Performance Testing
Training
Figure 3-1 Context of AIM Operations Analysis Phase
Oracle Method Operations Analysis 3 - 1

Overview
This section provides an overview of Operations Analysis.
Objectives
The objectives of Operations Analysis follow:
• Produce accurate information, function, and process models for

the business areas being addressed.
• Define the detailed function, data, and operational requirements
that the new application system must support.
• Map business requirements to application capabilities and
propose solutions to gaps.
• Define a technical architecture of hardware and software in
which the application system must perform.
• Propose a transition strategy for moving from the current system
to the new application system.
• Identify audit and control reporting and application integration
requirements.
• Train the project team.
• Develop performance testing models and scenarios.
The critical success factors of Operations Analysis follow:
• active participation by team management and knowledgeable

user and technical representatives from the area of the business
affected by the project
• thorough knowledge of the standard functionality of the
applications being implemented
• timely resolution of outstanding issues and questions
3 - 2 Operations Analysis AIM Method Handbook

• clear definition of the business objectives to be addressed by the
project
• access to information related to the existing business processes
and systems affected by the project
• effective management
Overview Table

for Operations Analysis.
Application and Architectural Requirements Application Security Architecture

Technical Architecture
Architectural Strategy Application Function Architecture
Business Volume Requirements Hardware and Network

Architecture
Conceptual Architecture
Logic Application and Database
Architecture
Future Applications Deployment
Performance Risk Assessment
Process and Mapping Summary
Physical Database Architecture
System Availability Strategy
System Capacity Plan
Technical Architecture Baseline
System Management Procedures
Module Design and Business Data Mapping Form Database Extension Design
Build
Customization Strategy Module Function Design
Solution Document Module Technical Design

Data Conversion Conversion Scope, Objectives Conversion Data Mapping

and Approach
Conversion Standards Conversion Program Design
Conversion Strategy Conversion Test Procedures
Current Business Baseline
Documentation Document Prototypes and

Templates
Document Requirements
Document Standards and

Processes
Documentation Environment
Business Systems Testing Mapping Scenario Testing Strategy
Integration Fit Analysis
Performance Testing Performance Test Transaction Performance Test Data Design

Models
Performance Test Scripts
Test Database Load Program

Design
Test Transaction Program Design
Training User Training Manuals
Production Migration Education and Training Plan Detailed Transaction and

Contingency Plan
Transition Strategy Production Support Infrastructure
Table 3-1 Operations Analysis Phase Overview Table

Prerequisites
Prerequisites for Operations Analysis follow. You should use these

prerequisites, if they exist, prior to beginning this phase. Otherwise,
you may need to create them during Operations Analysis.
Prerequisite Source
Architectural Requirements Application and Technical

Architecture
Architectural Scope, Objectives, and Application and Technical

Approach Architecture
Architectural Strategy Application and Technical

Architecture
Business Volume Requirements Business Requirements

Definition
Conceptual Architecture Application and Technical

Architecture
Conversion Scope, Objectives, and Data Conversion

Approach
Conversion Strategy Data Conversion
Current Business Baseline Business Requirements

Definition
Customization Strategy Module Design and Build
Documentation Standards and Documentation

Procedures
Documentation Requirements Documentation
Education and Training Plan Training
Financial and Operating Structure Business Requirements

Definition

Prerequisite Source
Future Business Function Model Business Requirements

Definition
Future Process Model Business Requirements

Definition
Glossary Documentation
Performance Testing Scope, Performance Testing

Objectives, and Approach
Performance Testing Strategy Performance Testing
Process and Mapping Summary Business Requirements

Definition
Technical Architectural Baseline Application and Technical

Architecture
Table 3-2 Operations Analysis Phase Prerequisites
Processes

Create detailed business requirements scenarios that depict sequenced
elementary business functions for mapping process steps to
applications. Determine business requirements for system availability.
Define audit and control requirements for financial and system
administration purposes. Define reporting requirements for all
functions.

Map business requirements to application functionality. Prove the
viability and feasibility of proposed business processes and their
integration. Map information flow and access needs by organization.

Develop strategies to meet the reporting needs and system availability
requirements of the business. Determine the details of deploying the
new application across data centers within the scope of the new
architecture. Refine the initial conceptual architecture and identify any
subsystems that need to be developed or integrated.
Data Conversion
Prepare the Conversion Standards to be used throughout the conversion
process.
Documentation
Create the documentation environment and produce the prototypes and
templates.
Performance Testing
Identify the test models that will be used to simulate the system or
system components that are within the scope of the test.
Training
Provide technical and functional application training to the project
team, including specific training segments for defining and using the
applications as well as maintaining the system.
Prepare a transition strategy for migrating the company, systems, and
people into the new enterprise system.

Key Deliverables
Acceptance Certificate Agreement by management that the

integrated business solutions satisfy
business objectives.
Architecture Subproject Proposals for architecture subprojects

Proposals to design and build, or integrate,
architecture subsystems.
Architecture Subsystems Describes the subsystems needed to

support the new architecture. The
subsystems may be designed and
built in-house, or may be purchased.
Examples include data warehouses,
OLAP systems, and enterprise data
transport mechanisms.
Audit and Control A statement of security, maintenance,

Requirements and monitoring of the production
system.
Business Availability A statement of the business needs in

Requirements terms of operating hours, system
uptime, and response and
turnaround time.
Business Data Mapping Verification that the underlying table

structures and attributes will support
business processes.

Business Requirements Detailed business requirements

Mapping Form written in business language and
associated with business processes,
analysis and comparison of the
current solution for a business
requirement to a proposed solution,
and details for the type and nature of
the solution in a descriptive format.
Business Requirements A set of formal statements of the

Scenarios detailed business requirements for
each business process, the source of
these requirements, how these
requirements will be satisfied (either
by the application, manual process
steps, workarounds or other
application solutions), and what
prototyping steps must be taken to
prove the designs.
Conceptual Architecture Revision of the original Conceptual

Architecture to reflect analysis done
during Operations Analysis.
Conversion Standards Documents naming conventions, file

structures, automated data
conversion toll usage standards, and
so on, used to ensure consistency and
quality.
Documentation Environment Contains the Documentation

Environment Proposal, procurement
information, and installation
documentation.
Documentation Prototypes Prototypes and templates developed

and Templates for documentation, for example: User
Reference Manual, User Guide,
Technical Reference Manual, and
System Management Guide.

Future Application Details the future deployment of

Deployment applications needed to support the
business and information systems
requirements and the broader
corporate vision.
Future Process Models Defines the future business model in

the form of integrated process flows
built upon the business processes
supported by the new application.
Information Access Model A model that depicts access to key

process and organization information
for reporting and/or security
purposes.
Information Flow Model A model that visually depicts

information flows in the business
between business functions, business
organizations, and applications.
Integration Fit Analysis Identifies the new integration points

which will require interfaces.
Mapping Scenario A plan for and record of business

solution testing, including business
processes involved in the test, the
business conditions that are needed
to test the application system,
definition of test script execution,
support tools required during
execution of the test, and a record of
test actions.
Master Report Tracking List A document that supports the

analysis and mapping of report
requirements to future business
processes and standard application
reports. It contains a consolidated
list of reporting requirements and the
final disposition of report
requirements.

Performance Test Scenarios The performance test scenarios that

will be simulated in performance
testing. These are point-in-time
snapshots of the total production
system processing environment that
will be modeled in the performance
test. There may be more than one
performance test scenario to model,
and each may have a different set of
transactions.
Performance Test The transaction models that will be

Transaction Models used to simulate each performance
test scenario. They will, in general,
contain a subset of the total
transactions and processing that
would occur in a real system and are
approximations to the real processing
environment in a live system. This
also discusses the transaction rates
and measurements to be used for
testing.
Project Team Training The environment to be used for

training the project team.
Training Preparation Lists the resources required for

Checklist project team training.
Trained Project Team Project personnel trained to perform

assigned project tasks.
Reporting Strategy Strategy for the reporting systems

needed to support the various
reporting requirements of the
business. Includes operational, ad
hoc, decision support, and analytical
reporting across applications,
databases, and sites.

Solution Document A document that summarizes the

business need that the application
features cannot meet, and proposes a
solution that can include a
combination of custom components,
manual workarounds, and other
existing application features.
System Availability Strategy Documents the strategy for handling

planned and unplanned outages. It is
the system implementation of the
more general business availability
requirements.
Transition Strategy Outlines the approach for migrating

the people, company, and system to
production status. Includes
transition and contingency plans and
transition support strategy.
Table 3-3 Operations Analysis Phase Key Deliverables

Approach
This section describes the approach for Operations Analysis.
Operations Analysis.
ID Task Deliverable

RD.070 Create Business Requirements Scenarios Business Requirements Scenarios
RD.080 Determine Audit and Control Requirements Audit and Control Requirements
RD.090 Identify Business Availability Requirements Business Availability Requirements
RD.100 Develop Reporting Requirements Master Report Tracking List
BR.010 Prepare Mapping Environment Configure Mapping Environment
BR.020 Map Business Requirements Business Requirements Mapping
Form
BR.030 Map Business Data Business Data Mapping Form
BR.040 Conduct Integration Fit Analysis Integration Fit Analysis
BR.050 Develop Information Flow Model Information Flow Model
BR.060 Develop Information Access Model Information Access Model
BR.070 Conduct Reporting Fit Analysis Master Report Tracking List
BR.080 Test Business Solutions Mapping Scenario
BR.090 Confirm Integrated Business Solutions Acceptance Certificate
TA.060 Develop System Availability Strategy System Availability Strategy
TA.070 Define Future Application Deployment Future Applications Deployment
TA.080 Develop Reporting Strategy Reporting Strategy
TA.090 Revise Conceptual Architecture Conceptual Architecture
TA.100 Define Architecture Subsystems Architecture Subsystems
TA.110 Propose Architecture Subprojects Architectural Subproject Proposals
MD.020 Define and Estimate Custom Extensions Solution Document

ID Task Deliverable
Data Conversion
CV.030 Prepare Conversion Standards Conversion Standards
Documentation
DO.040 Prepare Documentation Environment Documentation Environment
DO.050 Produce Documentation Prototypes and Documentation Prototypes and
Templates Templates
Performance Testing
PT.030 Identify Performance Test Scenarios Performance Test Scenarios
PT.040 Identify Performance Test Transaction Models Performance Test Transaction Models
Training
TR.020 Prepare Project Team Training Environment Project Team Training Environment
TR.050 Prepare Project Team Training Training Preparation Checklist
TR.060 Train Project Team Trained Project Team
PM.010 Prepare Transition Strategy Transition Strategy
Table 3-4 Operations Analysis Phase Tasks and Deliverables


Task Dependencies
This diagram shows the dependencies between tasks in Operations

Analysis.
Operations
Analysis
RD.100
Develop Reporting
Requirements
RD.100
BUSINESS RD.090 RD.060 RD.070

Identify Business Create Business Determine Audit
R EQUIREMENTS Availability Requirements and Control
D EFINITION Requirements Scenarios Requirements
RD.090 RD.070 RD.080
RM.040
Map Business
Data
BR.030
RM.010 RM.020
Prepare Mapping Map Business
Environment Requirements
BR.010 BR.020
BUSINESS
R EQUIREMENTS
M APPING RM.050
Conduct
Integration Fit
Analysis
BR.040
TA.070
Define Future
Application
APPLICATION AND Deployment
T ECHNICAL TA.070
ARCHITECTURE TA.060
Develop System
Availability
Strategy
TA.060
Figure 3-2 Operations Analysis Phase Task Dependencies

Operations
Analysis
BUSINESS
REQUIREMENTS
DEFINITION
RM.060
Test Business
Solutions
BR.080 BUSINESS
REQUIREMENTS
M APPING
RM.110 RM.070
Develop Confirm Integrated
Information Flow Business
Model Solutions
BR.050 BR.090
RM.120 RM.030
Develop
Conduct Reporting
Information
Fit Analysis
Access Model
BR.070
BR.060
TA.080
Develop Reporting
Strategy
TA.080
APPLICATION AND
TECHNICAL
TA.090 TA.100 TA.110 ARCHITECTURE
Define Propose
Revise Conceptual
Architecture Architecture Architecture Sub-
Subsystems projects
TA.090
TA.100 TA.110
B C
Figure 3-2 Operations Analysis Phase Task Dependencies (cont.)

Operations
A
Analysis
MODULE DESIGN
AND BUILD
CV.030
Prepare
DATA Conversion
Standards
CONVERSION CV.030
DOCUMENTATION
PERFORMANCE
TESTING
TR.050
Prepare Project
Team Training
TR.050
TRAINING TR.020 TR.060
Prepare Project
Team Training Train Project Team
Environment TR.060
TR.020
PRODUCTION
MIGRATION

B C
Operations
Analysis
MD.020
Define and
Estimate Custom MODULE DESIGN
Extensions
AND B UILD
MD.020
DATA
CONVERSION
DO.040 DO.050
Produce
Create
Documentation
Documentation
Prototypes and DOCUMENTATION
Environment
Templates
DO.040 DO.050
PT.030 PT.040
Identify
Identify
Performance Test
Performance Test PERFORMANCE
Transaction
Scenarios
PT.030
Models TESTING
PT.040
TRAINING
PM.010
PRODUCTION
Prepare Transition
Strategy MIGRATION
PM.010

Managing Risks
The areas of risk and mitigation for Operations Analysis include the
following:
Risk Mitigation
Team members inadequately Provide project team training

trained on the use of regarding methods and tools.
methods and tools.
Screen project team candidates to

ensure necessary skills and
experience will be available.
Insufficient business process Ensure training sessions sufficiently

research. explain that process research goes
down to the level of Elementary
Business Functions and validate that
the research reaches this level.
Erroneous statement of Obtain agreement from the user

required system availability. community about the level of system
outage that can be tolerated by the
business.
Inconsistency of team Assign process design and mapping

composition and expertise teams to groups of business
across process design, processes or areas and keep them
mapping, narrative writing, together across all analysis and
and approval activities. design tasks.
Inconsistency of team Conduct training sessions for team

methods and approaches members on methods and
across business areas or approaches. Have them demonstrate
process groups. required skills with a qualified
instructor.
Inadequate integration of Create an integration team that

processes across design and monitors process designs. As they
mapping teams. are in-process, look for inter-team
integration problems.

Risk Mitigation
Limited understanding by Screen project team candidates to

the project team of the ensure necessary skills and
applications tools to be experience are present.
implemented and generally
accepted industry practices.
Limited access to information Conduct frequent checkpoints that

about business areas, their include a management review to
processes, and information ensure that teams engaged in analysis
generation and use. activities are not being blocked from
gathering information.
Incomplete consideration of Employ team members with

the capabilities and appropriate experience or knowledge
limitations of the technology about the technology.
on which the architecture
will be based.
Lack of visibility of major Assemble architecture team

architecture issues occurring representation in channels or forums
in different areas or teams. to discuss major cross-functional or
business issues.
Insufficient communication Communicate the conceptual

to the wider project team of architecture model to the broader
the chosen conceptual project team so that everyone is
architecture model to all properly informed.
team members.
Not initiating development of Allow adequate investment of

complex, bi-directional resources and time in developing a
system interfaces early sound project plan and follow it to
enough in the project. ensure tasks are begun early enough
in the project life cycle.
Lack of technical expertise Recruit team members with

affecting decisions appropriate experience and
concerning appropriate knowledge.
technology solutions.

Risk Mitigation
Lack of expertise in Careful design of the test transaction

designing system transaction models with a clear vision of the
models that will provide objectives of the test and the extent to
useful results and provide which approximate models can
answers to the questions provide useful answers.
posed by the objectives of the
performance testing process.
Transaction models for Communicate the conceptual

performance testing built architecture model to the wider
without allowing for future project team so that everyone is
business growth, peak properly informed.
periods, or detailed
workflow patterns.
Poor or nonexistent business Survey and establish business

volume metrics and inability volume metrics in advance of
to relate the performance test conducting performance testing.
results in a meaningful way
to the production system.
Insufficient development of Start development of standards in

conversion standards. Operations Analysis using the
template for Prepare Conversion
Standards.
Poorly designed Include all key project areas in the

documentation prototypes design and approval of the
and templates. documentation prototypes and
templates.
Table 3-5 Risk Management Table for Operations Analysis

Tips and Techniques
This section provides tips and techniques for managing Operations

Analysis. In addition, advice and comments on each process are
included.

In Operations Analysis, format detailed business requirements into
scenarios containing elementary business functions. These include
sequenced process steps that need to be supported by a combination of
application functions, manual process steps, other interfaced or
integrated applications, workarounds, or custom modules.
Along with the business requirements identified in Definition, gather

and formalize the business availability requirements that dictate system
availability needs. This will be considered during the technical
architecture process.
The flow of information that results from business processes and

transactions is portrayed both within and across organizations. The
type of information access required for operating, reporting, and
consolidation for each organization is also identified (for example, some
organizations are creators of information while others are consumers of
information). These tasks will help to formalize the understanding and
control of information access and timing requirements.

During Operations Analysis, good team organization is the most
important factor affecting the quality of this process. Mapping teams
should address the same business areas and business processes as
process design teams. Ideally, the same teams will work on process
modeling and design, business requirements identification, and
mapping of requirements to application capabilities.
Key users should participate in mapping sessions. Perform mapping

close to the business process, in order to have access to agents and key
users and to allow users to witness process execution. As decisions are
made and agreements reached, document them in Business
Requirements Scenarios so that the final product reflects the proposed
business process design.

Follow the “Rule of 3-2-1.” This means that roughly three hours of
research are normally required for two hours of process design and one
hour of formal entry (capturing the BRS using a template or other tool).
Talk with real users and review real process outputs; avoid mapping
exclusively in a conference room.
Maintain a meticulous record of process prototyping. This will make

acceptance of business solutions easier. Obtain an informal agreement
before the formal signoff, if possible.

The information used to refine and extend the detail of the Conceptual
Architecture comes from Application and Technical Architecture itself,
and also from Business Requirements Definition and Business
Requirements Mapping. As the business mapping proceeds, the
mapping team will make decisions about how the new applications will
be configured to run the business, and it is important that the
architecture team has visibility to these decisions and any identified
mapping gaps. Gaps which correspond to major architecture
components having a pervasive impact on the overall system become
the responsibility of the architecture team. If the gaps require
standalone architecture components, they may also be identified as
architecture subsystems.
When the architecture team has refined the Conceptual Architecture,

they should also identify architecture components that are standalone
subsystems and have a wider impact on the information systems
architecture than a localized extension to a collection of modules or a
simple interface to a third party application. Examples of such
subsystems might include a data distribution system that links multiple
application installations and legacy applications; an operational data
repository that is synchronized to provide real-time information about
the state of business; a data warehouse; or an intranet web interface to
the new systems. Typically, these types of subsystems are only
important in larger scale projects, but the concept of a non-localized
component to an architecture, affecting multiple different applications,
interfaces, or databases is entirely general.
Because of the possible impact of these subsystems on the overall

systems architecture and on multiple individual technical groups
working on the project, separate the specification, design, and build of
these systems into separate subprojects linked to the core Application
and Technical Architecture process. The individuals or teams assigned
the task of managing the subsystems will produce individual proposals
for the work needed to integrate the subsystems into the overall

technical infrastructure. Even if the subprojects components are
purchased as pre-built packaged applications, significant integration
work may be necessary to integrate them.

One of the key deliverables of Operations Analysis is Solution
Documents which describes required custom extensions with work
estimates to design, build, and test all components. This is an important
decision-making document for upper management since it allows them
to evaluate the full cost of the implementation. If the time and cost to
implement the required extensions is greater than the perceived benefit,
management may ask the project team to reevaluate some of the gaps
and propose alternate solutions. You may decide to delay some of the
optional extensions until after production cutover.
The detailed work estimates in the Solution Documents are an

important input to the project manager for planning the detailed tasks
in Solution Design and Build. They also specify the need for the
technical resources you must secure for the project.
Data Conversion
In Operations Analysis, Conversion Standards should be prepared and
followed throughout Data Conversion
Documentation
The appropriate documentation environment includes the hardware,
software, and utilities that will accommodate the previously specified
documentation procedures and adequately support the technical needs
of the writing staff. Those assisting in the environment proposal should
have a thorough knowledge of the documentation procedures,
hardware, software, and utilities being considered.
Create a prototype for each document that contains a table of contents

and a sample chapter that can be easily reviewed for document design,
format, and suggested content. Prototypes present a clear visual
indicator of the final product and serve as the model for template
development.
Templates provide a baseline for the writing staff. They standardize the
style of each document and may eliminate formatting inconsistencies.
This allows the writer to concentrate on content and simplifies the
editing process that occurs later.

Performance Testing
In systems that support many tightly integrated business functions, the
processing environment may be complex and have a large number of
detailed transaction flows. In such cases approximations are inevitable
in the definition of a test model.
During this phase the performance test team constructs test models that
meet technical needs and will be financially feasible to implement. The
team will construct the models relative to predicted or actual
production system snapshots, and use input from the Business
Requirements Definition and Mapping teams to understand the way the
business will run on the new system. In this way, the team can interpret
the test results properly in the context of a real production situations.
Typically, the models selected will reflect situations of the highest
processing load on the system or on some critical component of the
system. The performance testing process depends on Business
Requirements Definition and Mapping to obtain information of
sufficient detail and quality so that the test team can construct accurate
models.
Training
During Operations Analysis, the project team is introduced to key
application features. Examples of key features are the use of multiple
sets of books and available to promise functions. This background
prepares the team for mapping tasks. Team members must have a
good understanding of system capabilities.
One of the key deliverables of Operations Analysis is the Transition
Strategy which outlines the approach for migrating the people,
company, and business systems to production. It includes estimated
transition resource requirements, high-level transition and
implementation contingency plans, and a transition support strategy.
The components of the Transition Strategy document are an important

input to the project manager for planning the detailed tasks in
Transition and for updating the Project Workplan. They also identify
the need for specific resources needed during the transition process.


Estimating
each task by role.
Applications Administrator
IS Operations Staff
Applications Expert
Database Designer
Business Analyst
Phase Effort
IS Manager
Facilitator
Analyst
Operations Analysis
ID Task
Business Requirements Definition 16.6%
B.RD.070 Create Business Requirements Scenarios 12.8% 30 50 10 5
B.RD.080 Determine Audit and Control Requirements 1.8% 100 0
B.RD.090 Identify Business Availability Requirements 0.6% 95 0
B.RD.100 Develop Reporting Requirements 1.5% 100 0
Business Requirements Mapping 40.9%
B.BR.010 Prepare Mapping Env ironment 1.7% 20 0
B.BR.020 Map Business Requirements 15.3% 5 25 35 0 5 5
B.BR.030 Map Business Data 3.0% 30 50 0
B.BR.040 Conduct Integration Fit Analysis 1.6%
B.BR.050 Develop Information Flow Model 1.4%
B.BR.060 Develop Information Access Model 1.4% 75 0
B.BR.070 Conduct Reporting Fit Analysis 2.1% 5 20 35 10 5
B.BR.080 Test Business Solutions 12.8% 30 60 0
B.BR.090 Confirm Integrated Business Solutions 1.5% 25 25 0
Application & Technical Architecture 3.6%
B.TA.060 Develop System Av ailability Strategy 0.6% 10 0 0
B.TA.070 Define Future Application Deployment 0.5% 85 15 0
B.TA.080 Develop Reporting Strategy 0.8% 50 20 0 0
B.TA.090 Revise Conceptual Architecture 0.5% 35 20 0 0
B.TA.100 Define Architecture Subsystems 0.6% 30 0
B.TA.110 Propose Architecture Subprojects 0.6% 0
Module Design & B uild 1.9%
B.MD.020 Define and Estimate Custom Extensions 1.9% 10 0
B.CV.030 Prepare Conv ersion Standards 0.9%
Documentation 2.8%
B.DO.040 Prepare Documentation Env ironment 1.2% 0
B.DO.050 Produce Documentation Prototypes and Templates 1.6%
B.PT .030 Identify Performance Test Scenarios 0.6% 35 0
B.PT .040 Identify Performance Test Transaction Models 0.7% 10 0
Training 17.8%
B.TR.020 Prepare Project T eam Training Env ironment 1.5% 20 0
B.TR.050 Prepare Project T eam Training 3.0% 45
B.TR.060 Train Project Team 13.3%
Production Migration 0.8%
B.PM.010 Prepare T ransition Strategy 0.8% 0
100.0%
Table 3-6 Operations Analysis Phase Estimating

0
0
IS Support Staff
Lead Tester
Module Designer
70
10
Oracle Method
30
Programmer
2
25
Project Manager
90
20
20
10
0
0
Project Sponsor
Quality Auditor
2
35
80
10
40
System Architect
Table 3-6
80
20
5
Team Leader-BR
Team Leader - Conversion
Team Leader - Customization
5
5
5
5
5
5
25
Team Leader-Mapping
10
65
65
6
5
10
5
5
Technical Analyst
25
25
20
25
95
95
20
20
10 0
Technical Architect
10
30
35
30
70
20 Technical Expert
Technical Expert - Existing Systems
Operations Analysis Phase Estimating (cont.)

Technical Writer
25
15
10 0
Tester
Trainer
90
25
10
0
0
0
0
0
0
0
0
0
0
User
Operations Analysis 3 - 29
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
Scheduling
The critical role during Operations Analysis is the analyst. By assigning

more analysts to this phase, you can shorten the critical path. Executing
tasks on the critical path in parallel also allows you to compress the
phase timeline.
Scheduling suggestions for Operations Analysis follow:
Project Management
In Operations Analysis the last portion of Business Requirements
Definition is completed and the majority of Business Requirements
Mapping tasks occur. Managing the overlap between these processes
can significantly affect your schedule.
Leverage analysis time with key users since user availability may be a
critical resource constraint. If you have skilled analysts and
knowledgeable users, several objectives associated with various
processes can be achieved in one work session. To ensure quality,
formal acceptance of the deliverables from these key tasks must occur.
Operations Analysis requires a considerable time commitment from

user management and staff. Time must be allocated from day-to-day
work to provide information about the business areas’ objectives,
requirements, and work practices, and to attend reviews. The project
manager should set expectations about the level of user participation
needed by explicitly scheduling these reviews and consultations in the
workplan.
Consider the impact of a multi-phase deployment. If applications will

be deployed in phases, there may be additional requirements, gaps, and
solutions needed at each site.

At the beginning of Operations Analysis, assess the completeness and
accuracy of your team’s work to date. Inaccuracies occurring early in
the project can have large scheduling impacts later on.

Schedule slippage for this process is often caused by:

• unrealistic test data in the mapping instance
• inadequate knowledge of Oracle Applications functionality
• inadequate time commitment by key users
• neglecting to adequately assess the impact of a multi-
phased/multi-site deployment approach
Usually at this point the Oracle demo database is being used to run
mapping scenarios. Depending on your business processes, the demo
data may not be sufficient to exercise the Oracle Applications according
to your scenarios. Consider augmenting the demo data.
If you are using a multi-phase deployment approach consider using

special Oracle features such as the open application program interfaces
(APIs) to support temporary bridges from your legacy systems that may
support some business units during initial deployment phases. By
passing transaction data to Oracle Applications you can use them for
consolidated reporting and query even though a portion of the
organization temporarily continues to use legacy systems.

Coordinate the detailed scheduling of this process with the Business
Requirements Definition development teams. Make sure function
frequencies and data retention rules are reviewed and agreed on from a
business perspective before finalizing the Capacity Plan.
Determine the impact of a multi-phased deployment approach on

technical architecture; they may cause schedule slippage later in the
project.
Both the new applications and legacy systems may need support until
all business units convert to the Oracle Applications. A phased
deployment approach may appear straightforward; however, there
could be major complexities in this area.

Carefully maximize overlap between the beginning of this process and
the end of Business Requirements Mapping. If there are obvious gaps
requiring custom software development, getting an early start could
shorten your schedule or, this could be done prematurely causing the
schedule to slip and overrunning the budget due to rework.

If different business units will be in production on legacy systems and
new applications, you may need to build temporary bridges between
them to support consolidated query and reporting. Consider using
Oracle’s application programming interfaces (APIs) to facilitate
bridging.
Data Conversion
Effective software products exist for data conversion that can
significantly enhance a team’s productivity. At this point the decision
regarding whether you will use such tools should have been made to
allow for acquisition, implementation, and training.
A multi-phase deployment approach may require iterations of some

data conversion tasks as the various subsets of business units go live on
the new system.
Documentation
Use an approach that leverages documentation developed earlier in the
project. A multi-phased deployment approach may have time
consuming impacts on documentation that should be addressed.
Performance Testing
A key advantage of a multi-phased approach is minimizing the risk of
major schedule slippage due to unexpected performance problems after
production. You can use actual production performance statistics to
assess capacity and add resources if necessary. A big bang approach
provides no leeway for incorrect capacity forecasts.
Training
Procrastination regarding training tasks (such as curriculum
development, training site scheduling, and instructor identification) is
common. This may result in schedule slippage later in the project or a
decision to accept lesser quality training than initially planned.
Accurately assess your training needs and determine the appropriate

approach. Curriculum development is expensive but may be the most
effective method of introducing a heavily customized system. Standard
Oracle education and custom developed training have considerations
that can end up on the critical path. When will standard Oracle classes
be taught? How soon can custom training be developed?

The most important consideration is whether a multiple deployment
approach will be used, since Production Migration must occur for each
deployment.

Staffing
This diagram illustrates a typical project organization for Operations

Analysis.
Operations Analysis Organization
Project Management

Business Requirements Technical Architecture &

Definition & Mapping Performance Testing
Existing Systems Team Lead

Examination
Functional Area
Team Team Members
(A)
Team Lead
Team Members
Functional Area
Team
(B)
Team Lead
Team Members
Business Process
Integration
Data Conversion Training &

Documentation
Team Lead Team Lead
Team Members Team Members
Transition Oracle Applications

Specialists
Figure 3-3 Staffing Chart for Operations Analysis

Operations Analysis.
Project Management
The most important staffing related factors in Operations Analysis are:
• having the right mix of skills due to the diversity of processes

occurring simultaneously
• fostering a sense of ownership of key decisions by appropriate
managers
• obtaining sufficient upper management, Information Systems,
and user commitment to ensure accurate and timely results
• ensuring staff follow a systematic plan with appropriate
guidelines, standards, and milestones
• dealing effectively with a mixed project team if you are using
people from various organizations (such as multiple consulting
firms, hardware/software vendors, or employees)
User and IS membership in the core project team is an effective tool in

fostering a sense of ownership in the new system. Consideration should
be given to full-time participation by key user and IS staff. Management
personnel who realize the importance of the application implementation
and the fact that its success is based on their involvement will
understand your request for full-time staff.

Substantial efficiencies can be gained by using some key people
throughout Business Requirements Definition and Business
Requirements Mapping.
The main difference, from a staffing point of view, between these two
processes is that a critical mass of knowledge must exist regarding how
the standard Oracle Applications function during Business
Requirements Mapping. This is where final decisions are made
regarding what aspect of the standard applications will suffice and
where customizations and/or workarounds are needed. Ideally,
thorough applications knowledge will exist throughout the entire
project.

Sufficient expertise must exist regarding standard application
functionality to accurately map requirements to the applications,
identify gaps, and define customizations and/or workarounds.
Maximize continuity between the Business Requirements Definition and
Business Requirements Mapping by retaining key personnel.

This process must be staffed by an experienced technical architect who
is knowledgeable in hardware, network, and operating system
considerations.

Module Design and Build work can begin when a custom solution is
complete. In some cases, team members may be assigned too late to
take advantage of the process overlap opportunities between mapping
and design. As a result, benefits to the project schedule are not
recognized.
Data Conversion
This process requires individuals skilled in analysis, programming,
testing, and transition. This process requires a diverse set of skills that
may be difficult to find.
Documentation
During Operations Analysis, the documentation environment must be
prepared to meet the needs of the people assigned to developing
documentation. Be certain to involve the writers in determining their
environment requirements.
Performance Testing
The fundamental approach to Performance Testing, and the design of
the mechanisms to be used, is defined during Operations Analysis. If
the work in this phase is accomplished well, it may be possible to use
less skilled staff to carry out the remainder of the performance testing
plan. Assure yourself that the technical architecture will support the
forecasted load by ensuring that sufficient expertise is applied to this
process.

Training
By the end of this phase all major decisions regarding training
development and delivery should be made.
During Operations Analysis, the Transition Strategy is prepared. This
document is critical for a successful move to production. Be sure that
the individuals selected to define the strategy have a sufficient
understanding of the transition requirements.

CHAPTER
4 Solution Design
T his chapter describes the Solution Design phase of AIM. The goal of
Solution Design is to use the requirements created during
Operations Analysis and finalize the system design and proposed
applications setups.

Analysis Design
Data Conversion
Documentation
Performance Testing
Training
Figure 4-1 Context of AIM Solution Design Phase
Oracle Method Solution Design 4 - 1

Overview
This section provides an overview of Solution Design.
Objectives
The objectives of Solution Design follow:
• Produce a design that meets functional requirements within

business, technical, and financial constraints.
• Document the design specifications in a way that facilitates and
supports future maintenance of the system.
• Define proposed application setups and test plans.
• Create job-level designs that will support proposed business
processes.
• Design the application, security, database, and network
architectures.
• Develop functional and technical designs for custom extensions,
interfaces, conversion programs, and database extensions.
• Develop unit, link, system, and system integration test scripts.
• Design performance test scripts, test transaction programs, and
test data.
• Develop User Training Manuals.
• Develop the detailed transition and contingency plans.
The critical success factors of Solution Design follow:
• clearly define the business objectives to be addressed by the

project
• ensure active participation by key management and
knowledgeable user and technical representatives from areas of
the business affected by the project
4 - 2 Solution Design AIM Method Handbook

• know the capabilities and features of the application and
available technology
• ensure that designs are traceable to business requirements
• manage designs so that they remain within scope
• allocate sufficient time resources
• utilize a well-managed change control system
• build a good framework for transition and contingency planning
Overview Table

for Solution Design.
Business Requirements Business Requirements Mapping Applications Setup Document

Mapping Form
Process Narrative
Business Requirements Scenario
Security Profiles
Financial and Operations Structure
Information Access Model

Application and Technical Architectural Requirements Application Security Architecture

Architecture
Architectural Strategy Application Function Architecture
Business Volume Requirements Hardware and Network

Architecture
Conceptual Architecture
Logic Application and Database
Future Applications Deployment Architecture
Process and Mapping Summary Performance Risk Assessment
System Availability Strategy Physical Database Architecture
Technical Architecture Baseline System Capacity Plan
System Management Procedures
Module Design and Build Business Data Mapping Form Build Standards
Customization Strategy Design Standards
Master Report Tracking List Database Extension Design
Solution Document Module Function Design
Module Technical Design
Data Conversion Conversion Scope, Objectives, and Conversion Environment

Approach
Conversion Data Mapping
Conversion Standards
Conversion Program Design
Conversion Strategy
Conversion Test Plan Procedures
Current Business Baseline
Manual Conversion Strategy

Documentation Document Prototypes and Initial User Reference Manual

Templates
Initial User Guide
Document Requirements
Initial Technical Reference Manual
Processes Initial System Management Guide
Documentation Environment
Business Systems Testing Mapping Scenario Testing Strategy
Integration Fit Analysis Unit Test Scripts
Link Test Scripts
System Test Scripts
Systems Integration Test Scripts
Performance Testing Performance Test Transaction Performance Test Data Design

Models
Performance Test Scripts
Performance Test Scenarios
Test Database Load Program
Design
Test Transaction Program Design
Training Trained Project Team User Training Manuals
Production Migration Conversion Strategy Detailed Transition and

Contingency Plan
Education and Training Plan
Production Support Infrastructure
Performance Test Strategy
Transition Strategy
Table 4-1 Solution Design Phase Overview Table

Prerequisites
Prerequisites for Solution Design follow. You should use these

prerequisites, if they exist, prior to beginning this phase. Otherwise,
you will need to create them during Solution Design.
Prerequisite Source
Architecture Requirements Application and Technical

Architecture

Architecture
Business Data Mapping Form Business Requirements

Mapping
Business Requirements Mapping Business Requirements

Form Definition
Business Requirements Scenario Business Requirements

Definition
Business Volume Requirements Business Requirements

Definition
Conceptual Architecture Application and Technical

Architecture
Conversion Scope, Objectives, and, Data Conversion

Approach
Conversion Standards Data Conversion
Conversion Strategy Data Conversion

Definition
Customization Strategy Module Design and Build
Documentation Prototypes and Documentation

Templates

Prerequisite Source

Procedures
Documentation Environment Documentation
Financial and Operating Structure Business Requirements

Definition
Future Application Deployment Business Requirement

Mapping
Information Access Model Business Requirement

Mapping
Integration Fit Analysis Business Requirement

Mapping
Mapping Scenario Business Requirements

Mapping
Master Report Tracking List Business Requirements

Mapping
Performance Test Scenarios Performance Testing
Performance Testing Transaction Performance Testing

Models
Process and Mapping Summary Business Requirements

Definition
Solution Document Module Design and Build
System Availability Strategy Application and Technical

Architecture

Prerequisite Source
Technical Architecture Baseline Application and Technical

Architecture
Transition Strategy Production Migration
Table 4-2 Solution Design Phase Prerequisites
Processes

Develop process narratives documentation that will serve as input into
the creation of training materials and user procedures. Finalize
application setups, security profiles, parameters, and user security
structures.

Create detailed designs for application and database deployment and
application configuration. Document the detailed hardware and
network configuration needed to support the applications deployment,
including system capacity planning. Design the system management
procedures needed to maintain the system.

Design customizations to address functionality gaps identified during
Business Requirements Mapping.
Data Conversion
Prepare the Conversion Environment, Conversion Data Mapping,
Manual Conversion Strategy, Conversion Program Design, and the
Conversion Test Plans.
Documentation
Create the Initial User Reference Manual, User Guide, Technical
Reference Manual, and System Management Guide.

Prepare a Testing Strategy that encompasses all tasks in the testing
process. Include an overview of the testing approach, the type of test
scripts to be developed, the testing to be performed, a schedule of
testing resources and responsibilities, the testing tools and
environments required, and a discussion of the problem management
process. Develop the detailed test scripts for each type of testing
including unit, link, business system, systems integration, and
regression testing. Test scripts can include test checklists, test
specifications or steps, test data profiles, and test sequences.
Performance Testing
Design the performance test database and identify how it will be
populated. Design any special database loading programs needed.
Design the test transaction programs needed to execute the test model.
Develop performance test scripts.
Training
Create materials for end-user training.
Develop the production support infrastructure, as well as contingency
and transition plans.
Key Deliverables
Application Functional The design of the functional

Architecture architecture for the applications for
each installation site.
Application Security The design of the security architecture

Architecture to support the (inter-) organization
security requirements.
Application Setup Document Setup data detailed documentation.

Conversion Data Mapping The mapping of the legacy system files

and data elements to the target
application tables and columns.
Conversion Program Design The program logic and rules data

conversion programs.
Conversion Test Plans The detailed conversion test plan for

both manual and automated data
conversions.
Database Extensions Design A design for new and changed

database objects, including their
relationships to standard application
database objects.
Hardware and Network The hardware, systems software, and

Architecture networks to support the applications
deployment and database architecture.
Initial User Reference Preliminary version of the User

Manual Reference Manual.
Initial User Guide Preliminary version of the User Guide.
Initial Technical Reference Preliminary version of the Technical

Manual Reference Manual.
Initial System Management Preliminary version of the System

Guide Management Guide.
Logical Application and The design of the application and

Database Architecture database architecture at the logical
level. Includes the relationship
between the functional architecture
and the logical data partitioning.
Encompasses database schemes and
logical database objects.
Manual Conversion Strategy The strategy for performing manual

data conversion in contrast to
automated conversions.

Module Functional Design Custom module designs expressed in

user terms.
Module Technical Design Specifications for the program

modules with sufficient technical detail
enabling the programs to be
successfully coded.
Performance Risk Study of the performance risks

Assessment inherent in the chosen architecture and
the techniques and steps that can be
taken to mitigate the risk.
Performance Test Data The detailed design for the

Design construction of the test database. This
specifies the business objects and
volumes needed in the test database
and how you will populate the test
database with the prerequisite data.
Performance Test Scripts The details of the individual steps that

you will execute for each transaction
test user profile.
Physical Database The detailed design for the physical

Architecture layout of databases in the architecture.
Includes the mapping of the logical
database architecture onto the physical
subsystems that support the database.
Process Narrative A textual description of a business

diagram at a job level.
Production Support Identifies the operational

Infrastructure infrastructure for managing and
maintaining the application
environment, database, and network
communications.
Security Profiles List of role-based security

specifications necessary to ensure good
controls and transaction access.

System Capacity Plan The system capacity plan for the

technical configuration. Includes the
planning of client and server machines,
and addresses CPU, memory, and disk
capacity.
System Management The detailed design for the systems

Procedures management procedures necessary to
support the architecture.
Test Database Load Program The designs for any programs needed
Designs to load data into the test database.
Test Transaction Program The detailed design for any transaction

Designs programs needed for the test. This
might include programs that execute
transactions against the database, or
automated programs that manage the
execution of multiple simultaneous
transaction flows.
Testing Strategy Establishes the approach and scope of

testing activities. Identifies the testing
tools and environment to be used, and
how defects will be managed.
Transition and Contingency Detailed plan for Transition including

Plan contingency plans if problems arise.
User Training Materials Workbooks, slides, lab exercises, and

product demonstrations for user
training.
Table 4-3 Solution Design Phase Key Deliverables

Approach
This section describes the approach for Solution Design.
Solution Design.
ID Task Deliverable

BR.100 Create Process Narratives Process Narrative
BR.110 Define Application Setups Application Setup Document
BR.120 Design Security Profiles Security Profiles
TA.120 Design Application Security Architecture Application Security Architecture
TA.130 Design Application Functional Architecture Application Functional Architecture
TA.140 Design Logical Application and Database Logical Application and Database
Architecture Architecture
TA.150 Design Physical Database Architecture Physical Database Architecture
TA.160 Design Hardware and Network Architecture Hardware and Network Architecture
TA.170 Develop System Capacity Plan System Capacity Plan
TA.180 Assess Performance Risks Performance Risk Assessment
TA.190 Design System Management Procedures System Management Procedures
MD.030 Define Design Standards Design Standards
MD.040 Define Build Standards Build Standards
MD.050 Design Database Extensions Database Extensions Design
MD.060 Produce Module Function Design Module Function Design
MD.070 Produce Module Technical Design Module Technical Design
MD.080 Review Detailed Designs Acceptance Certificate
Data Conversion
CV.040 Prepare Conversion Environment Conversion Environment
CV.050 Perform Conversion Data Mapping Conversion Data Mapping
CV.060 Design Manual Conversion Strategy Manual Conversion Strategy

ID Task Deliverable
CV.070 Design Conversion Programs Conversion Program Design

CV.080 Prepare Conversion Test Plans Conversion Test Plans
Documentation
DO.060 Produce Initial User Reference Manual Initial User Reference Manual
DO.070 Produce Initial User Guide Initial User Guide
DO.080 Produce Initial Technical Reference Manual Initial Technical Reference Manual
DO.090 Produce Initial System Management Guide Initial System Management Guide
Business Systems Testing
TE.010 Develop Testing Strategy Test Strategy
TE.020 Develop Unit Test Scripts Unit Test Scripts
TE.030 Develop Link Test Scripts Link Test Scripts
TE.040 Develop System Test Scripts System Test Scripts
TE.050 Develop Systems Integration Test Scripts Systems Integration Test Scripts
Performance Testing
PT.050 Create Performance Test Scripts Performance Test Scripts
PT.060 Design Performance Test Transaction Programs Test Transaction Program Designs
PT.080 Design Performance Test Data Performance Test Data Design
PT.090 Design Test Database Load Programs Test Database Load Programs Designs
Training
TR.070 Develop User Training Materials User Training Materials
PM.020 Design Production Support Infrastructure Production Support Infrastructure
PM.030 Develop Detailed Transition and Contingency Detailed Transition and Contingency
Plan Plan
Table 4-4 Solution Design Phase Tasks and Deliverables


Task Dependencies
This diagram shows the dependencies between tasks in Solution Design.
Solution RM.080
Design Create Process
Narratives
BR.100
RM.100 RM.090
BUSINESS Design Security Define Application
REQUIREMENTS Profiles Setups
MAPPING BR.120 BR.110
TA.160 TA.170
TA.120 Design Hardware
Design Application Develop System
and Network
Security Capacity Plan
Architecture
Architecture TA.170
TA.160
TA.120
APPLICATION AND
TECHNICAL
TA.130 TA.140 TA.150 TA.180
ARCHITECTURE Design Logical
Design Application Design Physical Assess
Functional Application and Database Performance
Database
Architecture Architecture Risks
Architecture
TA.130 TA.150 TA.180
TA.140
MD.020 MD.060
Produce Module
Define Design
Functional
Standards
Designs
MD.030
MD.060
MD.050
Define Build
Standards
M ODULE DESIGN MD.040
AND BUILD MD.050
Design Database
Extensions
MD.050
CV.04
0 Prepare
Conversion
Environment
CV.040
DATA
C ONVERSION
A B
Figure 4-2 Solution Design Phase Task Dependencies

Solution
Design
BUSINESS
R EQUIREMENTS
M APPING
TA.190
Design System
Management
Procedures
TA.190
APPLICATION AND
T ECHNICAL
ARCHITECTURE
MD.070 MD.080
Produce Module Review Detailed
Technical Designs Designs
MD.070 MD.080
M ODULE DESIGN
AND BUILD
CV.05 CV.07 CV.08

0 Perform 0 0 Prepare
Design Conversion
Conversion Data Conversion Test
Mapping Programs Plans
CV.070
CV.050 CV.080
DATA
CONVERSION
CV.06
0
Design Manual
Conversion
Strategy
CV.060
C D E F G H
Figure 4-2 Solution Design Phase Task Dependencies (cont.)

A B
Solution
Design
DOCUMENTATION
TE.010
Develop Test
Strategy
TE.010
BUSINESS SYSTEM
TESTING
PERFORMANCE
TESTING
TRAINING
PM.020
Design Production
PRODUCTION Support
M IGRATION Infrastructure
PM.020

C D E F G H
Solution
Design
DO.070
Produce Initial
User Guide
DO.070
DO.060
Produce Initial
User Reference
DO.060 DOCUMENTATION
DO.080 DO.090
Produce Initial
Produce Initial
System
Technical
Management
Reference
Guide
DO.080
DO.090
TE.020
Develop Unit Test
Scripts
TE.020
TE.030 TE.040
Develop Link Test Develop System
Scripts Test Scripts BUSINESS SYSTEM
TE.030 TE.040 TESTING
TE.090
Develop System
Integration Test
Scripts
TE.050
PT.050 PT.060 PT.080 PT.090

Create Design Design Design Test
Performance Test
Performance Test
Performance Test Database Load P ERFORMANCE
Scripts Transaction Data Programs TESTING
Programs
PT.050 PT.080 PT.090
PT.060
TR.070
Develop User
Training Materials TRAINING
TR.070
PM.030
Develop Detailed
Transition and PRODUCTION
Contingency Plan
PM.030
M IGRATION

Managing Risks
The areas of risk and mitigation for Solution Design include the
following:
Risk Mitigation
Disruptive testing due to Create a comprehensive testing

unplanned revisions, even strategy that details the coordination
though decisions have been and execution of every task in the
made regarding key testing process, that should be
application setups. developed and communicated prior
to commencement of any testing-
related activity.
Disruption to design Implement a configuration

activities due to frequent management subsystem for
changes in requirements controlling project deliverables.
design and assumptions, and
weak control over design
libraries.
Establish review and sign-off process

for each design.
Inaccurate or non-existent Encourage detailed capacity planning

capacity planning. including future volume projections,
peak periods, and changes of
headcount.
Assess capacity risks and the strategy

for dealing with uncertainties.
Ensure expertise is available to

support the need for capacity
planning.
Lack of good business Train project staff in techniques for

volume information gathering business volume
necessary for capacity information.
planning.

Risk Mitigation
Ensure effective management

support for the project, including
encouraging assignment of
knowledgeable staff to provide
information to the project team.
Lack of clear standards and Conduct reviews of database design

procedures for database before approving.
design.
Ensure that appropriate database

design standards are followed.
Poor design of automated Recruit experienced automated

tool test programs leading to testing tool technical staff or allow
re-coding to change time to adequately train staff on the
transaction models and rates tool.
during test execution.
Inaccurate or incomplete Link solution designs and setup data

application setup data. definitions to Definition and
Operations Analysis deliverables.
Inadequate design standards. Encourage the development and use

of design standards.
Conversion data mapping is Resolve the application setup

incomplete due to application unresolved issues that impact the
configuration issues not conversion data mapping and decide
being resolved and data on required data defaults.
defaults not selected.
Incorrect data conversion Provide project team training on

rules in conversion program establishing data conversion rules.
design document.
Define all conversion rules that

impact the conversion code in the
Conversion Design deliverable.

Risk Mitigation
Inaccurate or incomplete Ensure that test scripts, including test

linking between mapping specifications and data profiles, build
solutions and test plans. on the mapping scenarios that were
developed during Business
Requirements Definition.
Failure to develop a complete Create a comprehensive testing

and thorough testing strategy strategy that details the coordination
that covers not only test and execution of every task in the
execution, but also the testing process (develop and
coordination of test script communicate prior to
development resources, commencement of any testing-related
testing environments and activity).
tools, defect management
and the overall approach to
the testing process.
Inadequate reflection of Involve team members who were

business requirements in test responsible for analyzing business
scripts. processes and developing business
requirements in test script
development.
Underestimation of Develop a detailed plan mapping

Transition resource transition activities to existing project
requirements. resources; if needed, augment
existing resources by enlisting
additional client personnel and/or
additional consulting support.
Inadequate contingency plan. Emphasize the importance of having

contingency plans to support normal
business operations for key processes
(shipping, invoicing) in the event that
production cutover is unsuccessful.
Table 4-5 Risk Management Table for Solution Design

Tips and Techniques
This section provides tips and techniques for managing Solution Design.
In addition, advice and comments on each process are included.

Process Narratives are based on business process designs and define
how work is performed at the job level. They lay a foundation for user
procedures and user training, as well as business systems and
acceptance testing. Applications setups are defined and security
profiles are designed.

Solution Design is the phase where Application and Technical
Architecture is designed. The degree of detail needed for these designs
depends on the scope of the project and the project architecture process.
If the architecture is being designed for a localized application
implementation project with a single installation, the architect will
perform these tasks in detail. The system administrators can then
configure and set up the technical infrastructure for the new system
without requiring further work.
If, however, the architecture is at the enterprise level (spanning multiple

site implementations, installations, or databases) designing to the lowest
level of detail may not be possible. Under these circumstances the
architects will design to the degree of detail possible, with the
understanding that the enterprise-level architecture will only address
the enterprise-level issues. Individual architecture processes of more
limited scope will create the detailed designs for the individual
implementations.
The application architecture design developed in this phase involves the

following areas:
• Application Security Architecture

• Application Functional Architecture
• Logical Application and Database Architecture
• Physical Database Architecture
• Hardware and Network Architecture

The System Capacity Plan is developed and Systems Management
Procedures are designed. Performance risks are also assessed.
The application architect creates a detailed application deployment plan

specifying key application setup configurations, logical database
architecture and application installations, and determines the
application-level security to be implemented in the system. Key
application setup parameters may be specified by the business
requirements mapping team. The application architect will take this
information as input, validate the impact of the setup decisions on
application data partitioning and logical database architecture and make
recommendations to the mapping team if necessary.
The technical architect works with the application architect to design the
hardware and network infrastructure to support the application
architecture and ensure key business and information systems
requirements are met.

A major focus of Solution Design is the design of custom extensions as
well as interfaces between Oracle Applications, legacy systems, and
third-party applications.
The overall customization approach is defined in the customization

strategy prepared during Definition. Solution Documents produced
during the end of Operations Analysis are refined and detailed designs
created.
The first step is to define the Design and Build Standards that designers
and programmers must follow. Design and Build Standards are needed
for the types of modules that you plan to build to support the solutions
defined during Operations Analysis. For example, if no solutions
require the use of database triggers, related standards are not needed.
Once design standards are defined, designers can begin writing
functional design documents while the build standards are being
documented.
If there are many customizations, the Module Design and Build process
can consume a large portion of the schedule and budget. It is important
to schedule the appropriate technical resources and allocate time for
business analysts and users to participate in testing. The project plan
should include sufficient detail so that resources can be assigned to
individual modules.

Data Conversion
Prepare the environment that will be used for the data conversion
design, build, and testing tasks, then map the legacy data elements to
the Oracle Application tables and columns. If a standard interface is
provided with the Oracle Application, the legacy data should be
mapped to the standard interface tables and columns.
After the conversion data mapping is complete, the conversion

programs should be designed. If an automated conversion tool is being
used, you may need traditional code. Regardless of the tools being
used, conversion business rules must be defined.
During this phase, conversion test plans are developed. A manual

conversion plan needs to be constructed if manual data conversions will
be employed.
Documentation
Prototypes developed during Solution Design depict documentation
design, format and content. They are created for user review and
approval before formal documentation begins. Usually documentation
prototypes are required for:
• User Reference Manual

• User Guide
• Technical Reference Manual
• Systems Management Guide

The Testing Strategy describes the high-level direction and guidelines
for testing all components of the application system. This includes
outlining the overall approach to the testing process, coordinating the
development and execution of test scripts, scheduling adequate and
appropriate testing resources, configuring testing environments and
tools, and problem management. The Testing Strategy is a working
document that can be referenced throughout all tasks in the testing
process.
Based on the characteristics of the system to be built, specific testing

activities may vary in importance. Specific considerations include the
number of custom modules, availability and reliability of converted
data, system performance, number of system interfaces, the scope of

testing, testing standards, the types of testing, and the significance of
the system to the business.
The key focus is developing test scripts for unit, link, system, and
systems integration testing. In general, test scripts include test steps
and test data profiles. Unit tests usually include checklists, while
systems and systems integration tests include test sequences.
The testing process emphasizes re-using test script components

wherever possible to avoid duplication of effort. For example, when
developing the components of the system test scripts, it is important to
build on the mapping scenarios and data profiles that were previously
developed as well as the link test scripts that are related to the business
functionality that is being tested. Each level of testing builds on the
previous level, testing materials are re-used, and business processes are
tested in successively larger and larger pieces.
Performance Testing
After the team arrives at feasible models for performance testing, the
technical analysts will design the database and test programs needed to
create the test transactions. The technical analysts decompose the
transaction models into test scripts that specify the individual
transactions and events to be created during the test. If performance
testing is using an automated load testing tool, the technical analysts
will create programs to manage the specific transactions and test user
simulation. If not, there may be little or no design of special
performance test transaction programs and the majority of the work in
Solution Design will be focused on the test database design.
One of the critical success factors for this process is the inclusion of
testing against a volume test database. Performance Testing is
potentially the only area where testing of the system against a
significant volume of data occurs. Unfortunately, the bulk loading of
data to create a database that is “industrial-sized” can be time
consuming. There may be opportunities to leverage other work in the
project to alleviate this task (for example, by reusing the programs
created by the data conversion process). If the project has good quality
application data already set up, copy another database to provide the
setup data to bulk load transaction data.
Training
Training courseware is created during Solution Design using the User
Guide, User Reference Manual, and System Management Guide as the
basis for the content. The classes should be role-based and provide

users with a thorough introduction to their new responsibilities and
procedures.
Define production support infrastructure by identifying and
documenting the support requirements for application, database, and
network administration. Review the external software and hardware
providers’ support programs and existing internal support procedures.
Map the requirements to the support programs, and develop
procedures to meet any requirements in areas that are not already
covered. Create and document a method for identifying and
categorizing internal and external support problems. Finally, develop a
training plan to communicate the support procedures to both IS
personnel and users.
Develop a detailed transition and contingency plan that includes a

series of tasks or checklists to assist project management and users in
preparing for and executing the transition to production. The general
checklist tasks facilitate planning and estimating Transition. The
specific checklist tasks provide guidance in executing Transition.
The contingency plan outlines alternatives that may be implemented if

the cutover to production is unsuccessful. It discusses the
circumstances that require the execution of a contingency plan and lists
the implementation steps. It also identifies a migration step to re-
transition to the new system once problems are corrected.

Estimating
each task by role.
Applications Expert
Database Designer
IS Operations Staff
Business Analyst
Phase Effort
IS Manager
Facilitator
Analyst
S o lu tio n D e s ig n
ID T a sk
B u s in e s s R e q u ire m e n ts M a p p in g 4 .7 %
C .B R .1 0 0 C re a te P ro c e s s N a rra tiv e s 3 .1 % 95 0
C .B R .1 1 0 D e fin e A p p li c a tio n S e tu p s 1 .5 % 80
C .B R .1 2 0 D e sig n S e c u rity P ro file s 0 .1 % 80
A p p lic a tio n & T e c h n ic a l A r c h ite c tu r e 5 .2 %
C .T A .1 2 0 D e sig n A p p li c a tio n S e c u rity A rc h ite c tu re 0 .2 % 60 30
C .T A .1 3 0 D e sig n A p p li c a tio n F u n c tio n a l A rc h ite c tu re 0 .2 % 60 40
C .T A .1 4 0 D e sig n L o g ic a l A p p lic a tio n a n d D a ta b a se A rc h ite c tu re 0 .3 % 40 10 10
C .T A .1 5 0 D e sig n P h y sic a l D a ta b a se A rc h i te c tu re 1 .1 % 80 0
C .T A .1 6 0 D e sig n H a rd w a re a n d N e tw o rk A rc h ite c tu re 0 .8 % 10 0 0
C .T A .1 7 0 D e v e lo p S y ste m C a p a c ity P la n 1 .0 % 20 0 0
C .T A .1 8 0 A sse ss P e rf o rm a n c e R isk s 0 .5 % 25 0
C .T A .1 9 0 D e sig n S ys te m M a n a g e m e n t P ro c e d u re s 1 .1 % 10 20 0 0
M o d u le D e s ig n & B u ild 2 1 .2 %
C .M D .0 3 0 D e fin e D e s ig n S ta n d a rd s 0 .3 %
C .M D .0 4 0 D e fin e B u ild S ta n d a rd s 0 .3 %
C .M D .0 5 0 D e sig n D a ta b a se E x te n s io n s 0 .4 % 60
C .M D .0 6 0 P ro d u c e M o d u le F u n c tio n a l D e sig n 6 .1 % 20
C .M D .0 7 0 P ro d u c e M o d u le T e c h n ic a l D e sig n 1 2 .0 %
C .M D .0 8 0 R e v ie w D e ta ile d D e si g n s 2 .2 % 30 0
D a ta C o n v e rs io n 2 0 .2 %
C .C V .0 4 0 P re p a re C o n v e rsio n E n v iro n m e n t 0 .9 % 20
C .C V .0 5 0 P e rf o rm C o n v e rsi o n D a ta M a p p i n g (M a p C o n v e rsi o n D a ta ) 1 1 .3 %
C .C V .0 6 0 D e sig n M a n u a l C o n v e rsio n S tra te g y 0 .8 % 0
C .C V .0 7 0 D e sig n C o n v e rsio n P ro g ra m s 4 .8 %
C .C V .0 8 0 P re p a re C o n v e rsio n T e st P ro c e d u re s 2 .4 %
D o c u m e n ta tio n 1 4 .1 %
C .D O .0 6 0 P ro d u c e In itia l U s e r R e f e re n c e M a n u a l 6 .5 %
C .D O .0 7 0 P ro d u c e In itia l U s e r G u i d e 5 .2 % 20
C .D O .0 8 0 P ro d u c e In itia l T e c h n ic a l R e fe re n c e M a n u a l 1 .9 %
C .D O .0 9 0 P ro d u c e In itia l S y ste m M a n a g e m e n t G u id e 0 .5 %
B u s in e s s S y s te m T e s tin g 8 .9 %
C .T E .0 1 0 D e v e lo p T e st S ta te g y 0 .3 %
C .T E .0 2 0 D e v e lo p U n it T e st S c rip ts 1 .2 %
C .T E .0 3 0 D e v e lo p L i n k T e s t S c rip ts 3 .0 %
C .T E .0 4 0 D e v e lo p S y ste m T e s t S c rip ts 3 .5 % 60
C .T E .0 5 0 D e v e lo p S y ste m s In te g ra tio n T e s t S c rip ts 0 .9 % 20
P e r fo r m a n c e T e s tin g 3 .9 %
C .P T .0 5 0 C re a te P e rfo rm a n c e T e st S c rip ts 1 .3 % 30
C .P T .0 6 0 D e sig n P e rfo rm a n c e T e st T ra n sa c tio n P ro g ra m s 1 .9 %
C .P T .0 8 0 D e sig n P e rf o rm a n c e T e s t D a ta 0 .2 % 30
C .P T .0 9 0 D e sig n T e s t D a ta b a s e L o a d P ro g ra m s 0 .5 % 10
T r a in in g 6 .2 %
C .T R .0 7 0 D e v e lo p U s e r T ra in in g M a te ria l s 6 .2 % 45 0
P ro d u c tio n M ig ra tio n 2 .3 %
C .P M .0 2 0 D e sig n P ro d u c tio n S u p p o rt In f ra stru c tu re 0 .8 % 0 0
C .P M .0 3 0 D e v e lo p D e ta ile d T ra n sitio n & C o n ti n g e n c y P la n 1 .5 % 0 0 0 0
P ro je c t M a n a g e m e n t 1 3 .2 %
P JM M an ag e Ph ase 1 3 .2 %
CO NT C o n tin g e n c y 0 .0 %
1 0 0 .0 %
Table 4-6 Solution Design Phase Estimating

0
0
0
IS Support Staff
Lead Tester
20
10 0
Module Designer
60
60
10
80
20
20
10
10
90
30
90
80
40
20
10
10
Oracle Method
Programmer
20
80
30
10
30
Project Manager
75
0
Project Sponsor
Quality Auditor
20
40
40
20
35
10
10
System Architect
25
Team Leader - BR
Table 4-6
10
10
10
10
10
10
10
10
10
Team Leader - Documentation
5
Team Leader-Mapping
10
10
10
20
20
10
5
15
Technical Analyst
20
50
20
60
90
90
90
10
10
Technical Architect
10
50
50
45
20
30
Technical Expert
10 0
90

90
Technical Writer
25
80
80
70
90
Tester
60
30
Trainer
25
Solution Design Phase Estimating (cont.)

0
0
0
User
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
Solution Design 4 - 29
Scheduling
The critical roles during Solution Design are the business analyst,
module designer, and technical analyst . By assigning additional
qualified individuals to perform these roles, you can shorten the critical
path.
Scheduling suggestions for Solution Design follow:
Project Management
Project management review and sign-off meetings critical to Solution
Design should be reflected in the schedule.
Consistently applying the policies, procedures, standards, guidelines,

and tools provided to solution designers can have a positive impact on
the timeline. For example:
• Use an effective test database instance with sufficient test data to

explore different solution scenarios.
• Use design walkthroughs to identify integration problems that
could be time consuming if discovered during testing.
• Require unit test plans.
• Control design changes.
The information flow between the designers and other team members is
important; however, be sure to limit unnecessary interruptions.
Consider assigning designers to a physical location that is out of the
mainstream.
In addition to application customizations, solution designs for data

conversion, interfaces, technical architecture, performance testing, and
user training are produced during this phase. Emphasis on
customizations may detract from the importance of addressing these
other development areas. Thorough planning and tracking can prevent
schedule slippage due to last minute training material development or
an interface that was overlooked.
If a phased deployment approach will be used you may have both

legacy and new systems in production simultaneously. How will
consolidated reporting and queries be addressed? You may need

temporary bridge systems to pass transactions from one system to the
other so that both the new and legacy system can access all data.
Issue management can have a major impact on the Solution Design

schedule. Emphasize the importance of identifying, documenting,
investigating, and resolving issues in a timely manner.

The primary scheduling factors associated with Module Design and
Build are:
• the number of available and qualified team members

• the availability of an appropriate work environment
• the accuracy and completeness of the information developed in
previous phases
• the extent to which tasks can be conducted in parallel
Data Conversion
Allow for changes to the conversion modules caused by the discovery
of new requirements during the performance of Module Design and
Build tasks.
Documentation
The time needed to develop documentation is frequently
underestimated. Consider using professionals (for example, technical
writers) to improve productivity.
The primary factors influencing schedule are the scope of the document
to be produced and the productivity of the team.

Business System Testing requires carefully documented test scenarios
that include expected results. To adequately test a complex system you
need sufficient data to exercise application functionality. Inadequate
preparation can create the impression that the system has problems,
when in reality the testing process is at fault.
Performance Testing
Consult performance testing specialists to conduct practical
performance tests. There may be ways to ensure your system will be

able to handle the anticipated production load. For example, many
hardware vendors, in conjunction with Oracle, provide performance
testing services.
Performance testing may be complicated by multi-phase/multi-site

deployment approaches, resulting in a longer time requirement.
Training
Training approaches may impact the schedule, for example:
• Will standard Oracle training, custom training, or a combination

be used?
• Will internal or external instructors be used?
• Will internal instructors need specialized training on how to teach
the class?
• Will classes be conducted at multi-sites simultaneously? If so,
separate database instances may be needed for each site so
students can do the exercises.
• What is an acceptable class size? Multiple sessions of some
classes may be required to accommodate students.
Unless you use experienced curriculum developers, it is easy to

underestimate the resources and time required to develop custom
training materials.
In many cases, changes in user policies and procedures accompany an

applications implementation. Be sure that users are trained in system
functions, company policies, and job procedures.
Detailed plans are required for the production application setup, data
conversion, systems administration, and data administration tasks. It is
easy to underestimate the time required for this process.
For example, there are critical interdependencies for setup data and
data conversion steps among the Oracle Applications such as:
• Employees must be set up before you can enter project managers

into Project Accounting or Buyers into Purchasing.

• Fixed Asset Categories must be entered before assets can be
converted, and key fixed asset account numbers must be in the
Chart of Accounts before the categories can be entered.
Operating system and Applications logons and passwords must be

established. Project team responsibilities must also be determined and
communicated to all users prior to production.

Staffing
This diagram illustrates a typical project organization for Solution

Design.
Solution Design Phase Organization
Project Management

Business Function Custom Software Design

Specialists & Build
Business Function Team Leader

(A)
Functional Lead Team Members
Functional Analysts
Business Function
(B)
Functional Lead
Functional Analysts
Business Process
Integration
Technical Architecture & Data Conversion

Performance Testing
Team Lead Team Lead
Training & Transition

Documentation
Team Lead
Team Members
Oracle Applications
Specialists
Figure 4-3 Staffing Chart for Solution Design

Solution Design.
Project Management
During Solution Design the primary staffing factor is the transition to a
more technical team; the functional requirements should be complete.
Your primary focus is addressing gaps between the organization’s
needs and the standard applications. This requires knowledge of the
standard application’s functionality and technical architecture in order
to design effective solutions.
In multi-phase/multi-site projects there may be impacts on the design of

training classes, technical architecture, interface modules, application
extensions, and data conversion custom software modules.

Although staffing continuity maintains the project productivity level,
budget considerations may require that some team members be phased
out when their tasks are completed. Be sure that sufficient
documentation is transferred to the project before team members are
released from their responsibilities.
For multi-phase/multi-site deployments, try to select staff who have

experience with this approach. Experienced staff may identify key
requirements that otherwise might be missed.

Participation by skilled technical architects is critical. The Information
Systems department may be reluctant to use external technical
architects if they believe their group expertise is sufficient. Whether the
technical architect is an employee or consultant is less important than
the qualifications they bring to the process. Verifying that the technical
architecture will support the future system load is a critical component
of a successful project.

Experienced staff should develop the functional design specifications.
Technical specifications may be developed by less experienced staff and
reviewed by functional design developers.

A good development lead on a medium to large project can manage the
schedule and provide technical leadership. On a small project the
project manager might perform this role. The development lead is
responsible for the creation of custom extensions, an expensive
corporate asset. Using a structured, systematic development approach
that emphasizes quality control is essential.
If multiple deployment phases are used, additional customizations may

be requested or required for each deployment. Determine if additional
interface development and data conversion tasks will be needed by a
specific deployment.
Data Conversion
To design data conversion solutions, both technical and functional
expertise and a good understanding of application integration data
considerations are needed.

Business System Testing requires careful planning to thoroughly and
efficiently test the system.
If a phased deployment to different parts of your organization will

occur, determine the testing requirements that must be satisfied for each
user community. Their approval of the system is closely tied to the
Business System Testing results. Extensive or complicated testing may
require additional staff.
Performance Testing
Performance testing usually requires specialists. Hardware vendors
may provide performance testing services at their own sites. You may
be able to leverage their staff and facilities.
If you deploy in multiple phases, your system load will increase over
time. This potentially complicates performance testing but allows a cost
savings by phasing in additional computer and network capacity as
necessary.
Training
Training impacts the ongoing success of the implementation. Users
who understand the new system functionality will benefit from its
features. If you are choosing to create a custom course, select

courseware developers who understand your need for a detailed class
covering the features and functions for each user role.
For multi-phase deployments, you may need to repeat user training for
each deployment. Do not assume the same instructors will be available
for each deployment. If deployments will occur every few months,
training should be packaged so it can be repeated at each site.
The complexity and importance of Production Migration requires
experienced staff during the planning stage. For multiple deployments
many production migration tasks will be repeated for each deployment.
It may be impractical for the same people to perform these tasks for
each deployment.

CHAPTER
5 Build
T his chapter describes the Build phase of AIM. The goal of Build is to
develop the solution designed during Solution Design.

Analysis Design
Data Conversion
Documentation
Performance Testing
Training
Figure 5-1 Context of AIM Build Phase
Oracle Method Build 5 - 1

Overview
This section provides an overview of Build.
Objectives
The objectives of Build follow:
• Prepare the development environment.

• Develop, test, and accept custom software including:
– application customizations
– interface programs
– data conversion software
– custom application subsystems integrated with Oracle
Applications
– temporary bridge subsystems which transaction data
between legacy and new systems during multiple
deployments
• Create, test, and accept database extension and installation
routines.
• Develop and accept all documentation deliverables including:
– User Reference Manual
– User Guide
– Technical Reference Manual
– Systems Management Guide
– Online help text
• Develop performance test components, execute performance
tests, and prepare a report.
The critical success factors of Build follow:
5 - 2 Build AIM Method Handbook

• clear understanding of the business objectives being addressed by
the project
• effective participation by executive and user management
• accurate and complete design documentation
• a productive Build environment
• effective project management
• a productive team with appropriate skills
Overview Table

for Build.
Module Design and Build Application Setup Document Custom Database Objects
Approve Designs Develop Environment
Build Standards Installation Routines
Database Extension Design Module Source Code
Link Test Scripts
Module Functional Design
Module Technical Design
Physical Resource Plan
Unit Test Scripts

Data Conversion Conversion Data Mapping Business Object Tested Conversion

Programs
Conversion Environment
Conversion Programs
Conversion Program Design
Unit Tested Conversion Programs
Conversion Testing Plans
Validation Tested Conversion
Current Business Baseline Programs
Detailed Transition and

Contingency Plan
Documentation Design Standards Online Help Text
Document Prototypes and System Management Guide

Templates
Technical Reference Manual
Procedures User Guide
Documentation Requirements User Reference Manual
Initial System Management Guide
Initial Technical Reference Manual
Initial User Guide
Initial User Reference Manual

Business System Testing Business Requirements Scenario Integration Test Systems
Process Narrative Link Test Modules
Production Support Infrastructure Performance Test Results
System Test Scripts Prepared Users
Systems Integrated Test Scripts System Test Applications
Testing Strategy Testing Environments
Test Install Routines
Unit Test Modules
Performance Testing Perform Test Data Design Performance Tested Database
Perform Test Transactions Models Performance Tested Environment
Perform Testing Strategy Performance Tested Report
Test Database Load Program Tested Database Load Programs

Designs
Tested Transaction Programs
Test Transaction Program Designs
Table 5-1 Build Phase Overview Table
Prerequisites
Prerequisites for Build follow. You should use these prerequisites, if

they exist, prior to beginning this phase. Otherwise, you may need to
create them during Build.
Prerequisite Source
Application Function Architecture Application and Technical

Architecture

Prerequisite Source
Application Security Architecture Application and Technical

Architecture
Application Setup Document Business Requirements

Mapping
Approve Designs Module Design and Build
Build Standards Module Design and Build
Business Requirements Scenarios Business Requirements

Definition
Conversion Environment Data Conversion
Conversion Program Design Data Conversion
Conversion Testing Plans Data Conversion
Conversion Test Procedures Data Conversion
Conversion Data Mapping Data Conversion

Definition
Database Extension Designs Module Design and Build
Design Standards Module Design and Build
Detailed Transition and Contingency Production Migration

Plan
Documentation Prototypes and Documentation

Templates

Procedures

Prerequisite Source
Hardware and Network Architecture Application and Technical

Architecture
Initial System Management Guide Documentation
Initial Technical Reference Manual Documentation
Initial User Guide Documentation
Initial User Reference Manual Documentation
Link Test Scripts Business System Testing
Logical Application and Database Application and Technical

Module Function Designs Module Design and Build
Module Technical Designs Module Design and Build
Performance Risk Assessment Application and Technical

Architecture
Performance Test Data Designs Performance Testing
Performance Test Scripts Performance Testing
Performance Test Transaction Performance Testing

Models
Performance Test Strategy Performance Testing
Physical Database Architecture Application and Technical

Architecture
Physical Resource Plan Project Management
Process Narratives Business Requirements

Definition
Production Support Infrastructure Production Migration

Prerequisite Source
Security Profiles Business Requirements

Definition
System Capacity Plan Application and Technical

Architecture
System Testing Scripts Business System Testing
Systems Integrated Test Scripts Business System Testing
Test Database Load Program Design Performance Testing
Test Transaction Program Design Performance Testing
Test Strategy Business System Testing
Unit Test Scripts Business System Testing
Table 5-2 Build Phase Prerequisites
Processes
Model Design and Build

Develop custom application extensions, interface programs, and custom
application subsystems to be integrated with Oracle Applications.
Data Conversion
Develop and test the conversion programs and perform conversion
business object and validation testing.
Documentation
Complete final updates to the documentation and prepare for transfer
of ownership to the user community. Create and install the online help
text.

Prepare testing environment and perform testing tasks for the custom
extensions and total business solution. This includes the execution of
the test scripts, documentation and analysis of test results, and the
problem management process whereby identified errors are resolved
and re-tested.
Performance Testing
Develop the special database load and transaction programs, construct
the test database, create the test environment, and execute the
performance tests. Document the testing process and results in the final
performance test report.
Key Deliverables
Business Object Tested A record of information about the

Conversion Programs conversion programs that have been
tested.
Conversion Programs Conversion code needed for data

conversion.
Custom Database Objects New tables, indexes, views,

sequences, grants, and synonyms
required to support the custom
extensions. A component of this
deliverable is scripts to create the
new database objects in the
production environment.
Development Environment The environment to support custom

software development.

Installation Routines Operating system shell scripts, SQL*

Loader, or terminal keystroke files to
install and configure custom
extensions in the production
environment. This may also include
documented manual procedures for
online setup that cannot be easily
scripted.
Integration Tested System A set of systems whose interfaces

have been tested.
Link Tested Modules Tested modules that interact with

each other.
Module Source Code Forms, Reports, SQL, PL/SQL, C and

other code for the new modules. For
non-coded modules such as
Flexfields and Alerts, this represents
the online implementation of these
solutions.
Online Help Text Online user reference (full-screen text

with suggestions regarding system
usage and error messages).
Performance Test Database The database(s) to be used for

executing the performance tests. It
should have a significantly greater
volume of data than is usual for
business system test databases. In
general, it will include both
application setup data and
transaction data. Depending on the
circumstances and timing of the
project, the database may be sparsely
populated, but will have all the data
needed to allow the test transaction
programs to execute flawlessly.

Performance Test A fully configured performance test

Environment is executed. The environment
includes hardware, networks, test
database(s), automated test execution
tools, and monitoring tools. All steps
should have been taken to allow the
performance test team to connect to
the system and start the execution of
the performance tests.
Performance Test Report Report summarizing the performance

test including the test approach, the
test models, test hardware and
software configuration, test results,
and conclusions.
Performance Test Results Performance test measurements.
Prepared Users Users trained in specific standard

and custom applications
functionality.
Regression Tested Execution Modules that have been tested to

Modules ensure defects have been corrected.
System Management Guide Procedures for managing the

application (for example, backup,
recovery, audit, security).
System Tested Applications Applications that have been system

tested.
Technical Reference Manual A manual providing technical

information for use during
application maintenance.
Test Database Load Coded and tested data load

Programs programs that will be used to
populate the performance test
database.

Test Transaction Programs Coded and tested transaction

programs that will be used to execute
the performance test.
Tested Conversion Programs Data conversion programs that have

been tested.
Tested Installation Routines Validated installation routines for

custom modules.
Testing Environments The environment to be used for

testing custom software.
Unit Tested Modules Custom software modules that have

been tested.
User Guide Procedures needed to respond to all

supported business events using
standard and customized software.
User Reference Manual Manual to provide information to

users about system use during
production.
Valid Tested Conversion Data conversion programs that have

Programs been tested and accepted.
Table 5-3 Build Phase Key Deliverables

Approach
This section describes the approach for Build.
Build.
ID Task Deliverable

MD.090 Prepare Development Environment Development Environment
MD.100 Implement Database Extensions Custom Database Objects
MD.110 Create Custom Modules Module Source Code
MD.120 Create Installation Routines Installation Routines
Data Conversion
CV.090 Develop Conversion Programs Conversion Programs
CV.100 Perform Conversion Unit Test Unit Tested Conversion Programs
CV.110 Perform Conversion Business Object Test Business Object Tested Conversion
Programs
CV.120 Perform Conversion Validation Test Validation Tested Conversion
Programs
Documentation
DO.100 Complete User Reference Manual User Reference Manual
DO.110 Complete User Guide User Guide
DO.120 Complete Technical Reference Manual Technical Reference Manual
DO.130 Complete System Management Guide System Management Guide
DO.140 Provide Online Help Text On-line Help Text
TE.060 Prepare Testing Environments Testing Environments
TE.070 Perform Unit Test Unit Tested Modules
TE.080 Perform Link Tests Link Tested Modules
TE.090 Perform Installation Test Tested Installation Routines
TE.100 Prepare Key Users for Testing Prepared Users
TE.110 Perform System Testing System Tested Applications
TE.120 Perform Regression Testing Regression Tested Custom Modules

ID Task Deliverable
TE.130 Perform Systems Integration Testing Integration Tested System

Performance Testing
PT.070 Develop Performance Test Transaction Test Transaction Programs
Programs
PT.100 Develop Test Database Load Programs Test Database Load Program Designs
PT.110 Construct Performance Test Database Performance Test Database
PT.120 Prepare Performance Test Environment Performance Test Environment
PT.130 Execute Performance Test Performance Test Results
PT.140 Create Performance Test Report Performance Test Report
Table 5-4 Build Phase Tasks and Deliverables


Task Dependencies
This diagram shows the dependencies between tasks in Build.
Build
CV.090 CV.100 CV.110
Perform CV.120
Develop Perform Conversion Perform
Conversion Conversion Unit Business Object Conversion
DATA Programs Test Test Validation Test
CONVERSION CV.090 CV.100 CV.110 CV.120
MD.090 MD.100 MD.110

M ODULE DESIGN Prepare Implement
Create Custom
AND BUILD Development Database
Modules
Environment Extensions
MD.110
MD.090 MD.100
DO.100
Complete User
Reference
DO.100
DOCUMENTATION
DO.110
Complete User
Guide
DO.110
TE.060 TE.070
Prepare Testing
Perform Unit Test
Environments
TE.070
TE.060
BUSINESS SYSTEM
TESTING
TE.080
Perform Link Test

TE.080
PT.070
Develop
Performance Test
Transaction
Programs
PERFORMANCE PT.070
TESTING PT.110 PT.100
Develop
Construct
Performance Test
Database Load Performance Test
Database
Program
PT.100
PT.110
Figure 5-2 Build Phase Task Dependencies

Build
DATA
CONVERSION
MD.120
MODULE DESIGN
Create Installation
Routines AND BUILD
MD.120
DO.140 DO.120
Complete
Provide Online
Technical
Help Text
Reference
DO.140 DO.120 DOCUMENTATION
DO.130
Complete System
Management
Guide
DO.130
TE.100 TE.130
Prepare Key Users Perform
for Testing Installation Test
TE.100 TE.130
BUSINESS SYSTEM
TESTING
TE.110 TE.130 TE.120
Perform System Perform Systems Perform
Test Integration Test Regression Test
TE.110 TE.130 TE.120
PERFORMANCE
TESTING
PT.120 PT.130 PT.140
Prepare Create
Execute
Performance Test Performance Test
Performance Test
Environment Report
PT.130
PT.120 PT.140
Figure 5-2 Build Phase Task Dependencies (cont.)

Managing Risks
The areas of risk and mitigation for Build include the following:
Risk Mitigation
Inadequate testing of Begin test measurement executions

performance test transaction after performance test transaction
programs against the programs have been tested and
performance test database approved.
prior to starting test
measurement executions.
New hardware or disk Consider hardware or disk purchase

purchases do not arrive in lead times in scheduling the
time for the performance test performance testing.
environment preparation.
Underestimating time Realistically assess development time

needed to build and debug for a volume test database and/or
automated performance test automated testing tool transaction
tool programs as well as the programs and discuss development
test database. metrics with testing tool vendor.
Inadequately tested custom Perform rigorous unit and link tests

code that interferes with of custom modules.
effective system testing.
Ineffective conversion The conversion programmers verify

programs due to insufficient that the level of detail provided in the
conversion designs. Conversion Design is adequate.
Inadequate training of testers Train staff who will conduct

for conversion business conversion object tests on the
object and validation tests. functionality of the target
applications and testing procedures.
Insufficient test data. Ensure that sufficient time and

resources are provided for test data
development.

Risk Mitigation
Incomplete Business System Business Systems Test and Systems

and Systems Integration Integration Test scripts should be
Tests. executed and documented by
personnel who understand the
business processes and interfaces that
are being tested.
Inadequate testing Separate testing environments should

environment affecting control be configured to support each type of
over testing data and testing, if possible. At minimum, a
processes as well as the given testing environment can be
validity of test results. managed to support multiple types of
testing, but should not be used for
other non testing-related project
activities.
Fewer resources than needed Ensure that sufficient resources are

to execute system and planned for testing.
systems integration test
scripts and document test
results.
Inadequate defect The defect management process

management resulting in should be established in the Testing
defects that are identified but Strategy document, implemented
not resolved in a controlled, prior to custom development, and
reliable manner. describe the step-by-step process to
be followed in identifying, correcting,
and re-testing a defect.
Table 5-5 Risk Management Table for Build

Tips and Techniques
This section provides tips and techniques for managing Build. In


Module Design and Build and Business System Testing are two distinct
processes in AIM, but must be treated as a coordinated set of activities
to ensure success. In particular, Develop Custom Modules is tightly
integrated with Perform Unit Test and Perform Link Tests in Business
System Testing. Programmers and testers repeat these three tasks for
each custom module and related sets of custom modules until all
custom extensions are ready for the business system test.
The movement of custom modules and database extensions from the

development, unit, and link test environments to the business system
test environment must be carefully executed to ensure that all
components function properly. This can be a major issue when
customizations consist of a combination of different module types that
have different migration procedures. Some can be automated with
scripts while other steps must be completed by entering parameters
manually in Application Object Library forms. The Business System
Testing Strategy describes the number of testing environments and the
Build Standards define the migration procedures.
Data Conversion
During Build, the conversion programs are developed. If an automated
tool has been selected it may be used to build conversion templates that
map the legacy data to the Oracle Application tables and then load the
legacy data into the Oracle tables.
The conversion programs should be unit tested during this phase to

ensure that they function as intended. Once legacy data is loaded into
the Oracle Application, the integrity of the data should be tested within
each Oracle application. In addition, a conversion validation test should
be executed to test the performance of the legacy data within the entire
suite of installed Oracle Applications.
Documentation
Documentation should be continually updated as the applications and
extensions are being tested and revised. When the User Guide and User

Reference Manual are completed, the online help text can be developed
and installed. After the implementation is complete and the project
team disbanded, the documentation will be a major resource for every
area using the new system.

Creating the testing environments needed to support each type of
testing can be done in the beginning of the phase, or each environment
can be created as needed during the testing process. The Testing
Strategy lists the number and type of environments needed to support
the testing tasks, including unit, link, system, systems integration,
regression, and acceptance testing.
You may choose to perform multiple types of testing in a single testing

environment. However, it is not recommended that testing be
performed in an environment that is concurrently supporting other
project activities such as training or conversion testing. This practice
can cause corruption of test data or programs, inaccurate test results,
and frustration for testers and the other users of the shared
environment.
The emphasis during Build involves testing each custom module as it

moves through development (unit and link testing) and testing the
applications and their integration with external systems (system testing
and systems integration testing).
For each type of testing it is preferable that test scripts be executed more
than once for each testing target (module, linked modules, business
process, integrated system). In the case of unit and link testing,
developers generally test each other’s code in an iterative process until
the module or linked module is ready for system testing.
System testing and system integration testing should reflect actual

business flows and be executed in cycles. Each test specification is
tested multiple times with different data profiles, within the context of
different occurrences of each business transaction.
Performance Testing
System and Database Administrators construct the performance test
environment during Build. This includes:
• preparing the hardware and network connections

• migrating the fully populated test database

• migrating the special test transaction programs
• installing the applications
• installing performance monitoring tools
Administrators should perform as much environment testing as

possible before formally starting the test execution. The technical
analysts and administrators should also perform testing of the
transaction programs, the test scripts, and the test database in the test
environment.
The execution of a complex performance test rarely proceeds without

initial problems. Each iteration or test cycle may need to correct
problems in the environment found during a prior cycle or may test the
effects of a system re-tuning. There is a good deal of tuning and re-
tuning necessary during the execution of a large-scale, multiple
transaction performance test. To collect system measurements for a
particular set of test parameters or a test configuration may require
multiple cycles before the system and the test programs are tuned
properly to give realistic or useful results.
At the end of the formal performance test process, a performance test

report summarizes the work performed by the team during the process,
the results obtained, and conclusions and recommendations. The
creation of a formal report is optional and may not be necessary if the
performance test process is relatively limited in scale and is not making
strategic or critical project recommendations. The project manger
responsible for the performance test project will decide whether a
formal report is warranted.
At the end of the formal testing process, the programs and scripts may
be useful for performance regression testing in a continuing
performance quality management system. Before making changes to
the production technical configuration, or the applying of software
patches or upgrades, the business can use the performance test suite to
assess the performance impact of changes.


Estimating

each task by role.
Applications Expert
Database Designer
Business Analyst
Phase Effort
IS Manager
Facilitator
Analyst
Build
ID Task
Module Design & Build 17.0%
D.MD.090 Prepare Development Environment 0.9% 15
D.MD.100 Implement Database Extensions 0.6% 20
D.MD.110 Create Custom Modules 14.2%
D.MD.120 Create Installation Routines 1.2%
D.CV.090 Develop Conversion Programs 5.0%
D.CV.100 Perform Conversion Unit Test 2.0%
D.CV.110 Perform Conversion Business Object Test 6.0%
D.CV.120 Perform Conversion Validation Test 1.5% 30
Documentation 5.8%
D.DO.100 Complete User Reference Manual 2.0%
D.DO.110 Complete User Guide 1.6%
D.DO.120 Complete Technical Reference Manual 0.6%
D.DO.130 Complete System Management Guide 0.2%
D.DO.140 Provide Online Help Text 1.4%
Business System Testing 32.1%
D.TE.060 Prepare Testing Environments 1.1% 20
D.TE.070 Perform Unit Testing 6.1%
D.TE.080 Perform Link Testing 7.9%
D.TE.090 Perform Installation Test 0.7%
D.TE.100 Prepare Key Users for Testing 0.7% 0
D.TE.110 Perform System Testing 9.8% 0
D.TE.120 Perform Regression Testing 2.5%
D.TE.130 Perform Systems Integration Testing 3.3%
D.PT.070 Develop Performance Test Transaction Programs 3.4% 5
D.PT.100 Develop Test Database Load Programs 1.6% 5
D.PT.110 Construct Performance Test Database 4.7%
D.PT.120 Prepare Performance Test Environment 2.6% 20 10
D.PT.130 Execute Performance Test 4.0% 20
D.PT.140 Create Performance Test Report 1.1% 5 10 0
100.0%
Table 5-6 Build Phase Estimating

0
IS Operations Staff
0
0
0
IS Support Staff
Lead Tester
10
10
10
75
10
Module Designer
10
10
10
10
20
10
Oracle Method
10
10
10
Programmer
85
85
20
20
20
20
20
50
40
10
90
100
100
100
25
30
80
25
Project Manager
0
Project Sponsor
Quality Auditor
10
30
40
80
40
15
35
System Architect
Table 5-6
15
Team Leader - Architecture
Team Leader - BR
10
10
10
40
5
5
45
20
10
10
Team Leader-Testing
25
Team Leader - Training
Technical Analyst
20
20
15
70
Build Phase Estimating (cont.)

Technical Architect
Technical Expert
Technical Expert-Environment
15
Technical Writer
60
70
80
60
80
Tester
60
60
60
80
50
60
90
0 Trainer
0
User
Build 5 - 25
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
Scheduling
The critical roles during Build are that of the developer and the tester.
By assigning more programmers and testers, you may shorten the
critical path. Executing tasks on the critical path in parallel may
compress the timeline.
Scheduling suggestions for Build follow:
Project Management
During multi-phase/multi-site deployment you may need to maintain
team development capability throughout the deployment phases.
Team size can affect the Build schedule. Maximize parallel activities by
having as large a team as possible, but avoid going beyond the size
where incremental administration and communication needs can
decrease productivity.

Make every effort to ensure the development environment is ready on
time. To be productive a development team needs:
• computer resources and workstations

• test database instance with sufficient test data
• design, coding, and testing standards and procedures
• various tools (for example, automated tools to facilitate
producing design documents)
• administrative procedures for issue resolution, registering
modules, getting deliverables approved, and obtaining answers
to questions
Data Conversion
For multi-phase/multi-site deployments, data conversions may be
scheduled at different times according to site requirements.

For smaller projects with good user participation you may consider
combining System Testing and the Acceptance Test. Combining the two
tasks requires careful planning and extensive user participation but can
significantly reduce the timeline.
If you choose to combine the tests, the usual errors detected during
Systems Testing can be misinterpreted by users, resulting in a credibility
issue for project management.
Performance Testing
If Performance Testing needs to be repeated because previous test
results were inaccurate or insufficient computer resources have been
allocated, the schedule may change accordingly.

Staffing
This diagram illustrates a typical project organization for Build.
Build Organization
Project Management

Business Function Oracle Applications

Specialists Specialists
Custom Software Design Technical Architecture &

& Build Performance Testing
Team Lead Team Lead
Data Conversion Training
Team Lead Team Lead
Transition Documentation
Team Lead
Team Members
Testing
Team Lead
Team Members
Figure 5-3 Staffing Chart for Build

Build.
Project Management
The most important staffing factor in Build is having a strong
development lead. This individual needs knowledge of Oracle
Applications technical architecture and the custom development tools to
be used. They must motivate developers to meet deadlines and to
follow project policies and procedures.
The development environment can have an impact on the morale and

productivity of developers. Custom software developers are very
dependent on their environment to perform fundamental tasks.
Fewer team members with functional skills will be required during

Build so some may be released from the team. At the same time,
developers may be added to enhance the technical staff.

Focus on the following key elements to help ensure a productive
development team:
• strong development lead

• productive work environment
• committed developers willing to follow project policies and
procedures
• planned knowledge transfer method during project team
personnel changes for multi-phase/multi-site projects
• effective issue management
Data Conversion
Using commercially available software can significantly affect the
development time during this phase and reduce staffing requirements.
If your data conversions will be audited, you should begin to assemble

the appropriate documents and statistics. If a phased conversion
approach is being used, the conversion process could span several site
deployments. The conversion of a given business object may need to be
repeated multiple times. Multi-phased conversion deployment will
have a significant impact on staffing requirements.

Documentation
The documentation completed in this phase will impact the success of
the project after the system has gone into production. Staff this final
documentation effort with team members who have exceptional writing
skills and are detail oriented.

The system test relies heavily on the participation of the user
community. Sufficient users must be available for the test and be
adequately trained in the new system functionality. Their approval of
the system test results determine if the project continues to the next
phase.
Performance Testing
The last Performance Testing steps analyze test results and develop
conclusions. The performance testing team can be deployed elsewhere
at this time unless follow up performance testing projects will be
undertaken.

CHAPTER
6 Transition
T his chapter describes the Transition phase of AIM. The goal of

Transition is to install the new application system, prepare client
personnel, establish the system administration function, and then cut
over to the new system.

Analysis Design
Data Conversion
Documentation
Performance Testing
Training
Figure 6-1 Context of AIM Transition Phase
Oracle Method Transition 6 - 1

Overview
This section provides an overview of Transition.
Objectives
The objectives of Transition follow:
• Install data conversion software.

• Convert and verify legacy data.
• Prepare personnel to support the system.
• Verify that the system meets all acceptance criteria.
• Begin to use the production system.
• Support acceptance testing.
• Train user personnel.
• Set up the applications.
The critical success factors of Transition follow:
• clear understanding of the business objectives

• effective participation by business management
• sufficient technical and application architecture
• available and committed support staff to implement the new
solutions
• committed user involvement and ownership
• successful performance acceptance testing
• successful completion of production readiness plan
• effective training
6 - 2 Transition AIM Method Handbook

Overview Table

for Transition.
Data Conversion Conversion Program Design Converted and Verified Data
Detailed Transaction and Installed Conversion Software

Contingency Plan
Conversion Environment
Performance Testing Results
Validation Tested Conversion

Programs
Training Application Setup Document Trained Users
Education and Training Plan User Training Environment
User Training Materials

Production Migration Hardware and Network Configured Applications

Architecture
Documented Support Procedures
Installation Routines
Production Environment
Integrated Tested Systems
Production System
Logical Application and
Database Architecture Production-Ready System
Online Help Text
Physical Database Architecture
Prepared Users
Production Support
Infrastructure
Security Profiles
System Management
Procedures
Technical Reference Manual
User Reference Manual
Business System Testing Acceptance Test Results
Table 6-1 Transition Phase Overview Table

Prerequisites
Prerequisites for Transition follow. You should use these prerequisites,

if they exist, prior to beginning this phase. Otherwise, you may need to
create them during Transition.
Prerequisite Source
Acceptance Test Plan Client
Application Setup Document Business Requirements

Mapping
Conversion Environment Data Conversion
Validation Tested Conversion Data Conversion

Program Design
Detailed Transaction and Production Migration

Contingency Plan
Hardware and Network Architecture Application and Technical

Architecture
Installation Routines Application and Technical

Architecture
Logic Application and Database Application and Technical

Online Help Text Application and Technical

Architecture
Performance Testing Results Performance Testing
Physical Database Architecture Application and Technical

Architecture
Prepared Users Application and Technical

Architecture

Prerequisite Source
Production Support Infrastructure Production Migration
Security Profiles Business Requirements

Mapping
System Management Procedures Application and Technical

Architecture
Technical Reference Manual Documentation
User Reference Manual Documentation
User Training Materials Training
Validation Tested Conversion Data Conversion

Programs
Table 6-2 Transition Phase Prerequisites
Processes
Data Conversion
Install the data conversion software in the production environment,
convert the legacy data to the Oracle Applications, and verify data
accuracy.

During Transition, this process can include creating and supporting the
testing environment, providing test scripts and testing support staff,
training testers on the system prior to testing, coordinating the
acceptance testing, and managing the issue resolution process.
Training
Train users and support staff in preparation for going live on the new
system.

Prepare the production environment, including entering application
setups. Implement the support infrastructure, assess production
readiness, and execute production cutover.
Key Deliverables
Configured Applications Application ready for production

use.
Converted and Verified Data Converted data in the production

database that has been reviewed
and verified.
Documented Support Procedures for supporting the new

Procedures system in documentation form.
Installed Conversion Installed conversion software and

Software automated conversion tools used in
converting legacy data.
Production Environment Installed production environment

ready to receive final configured
applications.
Production Readiness Detailed production readiness

Checklist verification checklist.
Production Ready System New system ready to be installed in

the production environment.
Production System New system installed in the

production environment ready for
production use.
Trained Users Users who have attended user

training.

Configured Applications Application ready for production

use.
User Training Environment Environment to be used in training

users.
Table 6-3 Transition Phase Key Deliverables

Approach
This section describes the approach for Transition.
Transition.
ID Task Deliverable
Data Conversion
CV.130 Install Conversion Software Installed Conversion Software
CV.140 Convert and Verify Data Converted and Verified Data
TE.140 Support Acceptance Test Acceptance Test Results
Training
TR.080 Prepare User Training Environment User Training Environment
TR.090 Train Users Trained Users
PM.040 Prepare Production Environment Production Environment
PM.050 Setup Applications Configured Applications
PM.060 Implement Support Infrastructure Documented Support Procedure
PM.070 Verify Production Readiness Production-Ready System
PM.080 Commence Production Production System
Table 6-4 Transition Phase Tasks and Deliverables

Task Dependencies
This diagram shows the dependencies between tasks in Transition.
Transition
CV.130 CV.140
DATA Install Conversion Convert and Verify
CONVERSION Software Data
CV.130 CV.140
BUSINESS SYSTEM
TESTING
TR.080 TR.090
Prepare User
TRAINING Training Train Users
Environment TR.090
TR.080
PM.060
Implement
PRODUCTION Support
Infrastructure
MIGRATION PM.060
PM.040 PM.050
Prepare
Production Setup Applications
Environment PM.050
PM.040
Figure 6-2 Transition Phase Task Dependencies

Transition
DATA
CONVERSION
TE.140
Support BUSINESS SYSTEM
Acceptance Test TESTING
TE.140
TRAINING
PM.070 PM.080
Verify Production Commence
Readiness Production PRODUCTION
PM.070 PM.080 MIGRATION
Figure 6-2 Transition Phase Task Dependencies (cont.)

Managing Risks
The areas of risk and mitigation for Transition include the following:
Risk Mitigation
Malfunctioning or inefficient Design programs with performance

custom software. in mind and include custom
programs in Performance Testing.
Obtain formal and independent

quality signoff of all testing activities.
Inadequate production Verify in Build that the production

environment for conversion environment will be prepared in time
software. to install the conversion software.
Ensure that qualified and effective

staff review and approve
deliverables.
Users who are unprepared to use Establish a user certification or

the production system. readiness program that provides
incentives for system skill mastery,
and prevents system use by people
who have not demonstrated the
proper level of qualification.
Inadequate communication of Integrate support procedures into

support procedures to end users end-user training and system testing
prior to production cutover. processes.
Changes made to application Establish a procedure for migrating

setups in the testing environment changes to application setups into the
not documented in the production environment.
production setup documents or
implemented in the production
environment.
Table 6-5 Risk Management Table for Transition

Tips and Techniques
This section provides tips and techniques for managing Transition. In


If you have built custom extensions, you may need developers during
cutover to address any problems encountered with custom code.
Data Conversion
The conversion software should be installed in the production
environment. Assuming the prerequisite testing tasks are complete, the
legacy data should be converted to the Oracle Application production
environment and verified for accuracy and audit requirements.

The final testing task involves supporting trained end users in the
execution of the Acceptance Test. The system’s functionality will be
measured in general against business requirements, and specifically
against Acceptance Test Criteria.
If users have been involved throughout the implementation, there

should be no surprises during the final system acceptance test. Prior to
the test, users must be trained for appropriate system skills to enable
their successful participation in the testing effort. A procedure should
be implemented to address any issues or problems that are identified
during testing, and all resolutions must be communicated to the
acceptance test team.
Training
User training should be delivered prior to the new system going into
production; however, timing is critical. If training is delivered too soon,
users will not be able to retain their knowledge; if delivered too late,
some users may be unprepared for their new responsibilities. The best
approach is to conduct a program of user certification or readiness
testing.
To retain the students’ attention and avoid overwhelming them with

information, it is important to break training sessions into manageable
sections that focus on clear objectives. Providing hands-on interaction

with the application will encourage confidence in their ability to use the
system.
The Business System Testing and Training tasks during Transition
provide opportunities to test the support procedures that have been
developed and documented. Distribute support materials throughout
the company, and review them during user training and testing
preparation. Practice logging technical assistance requests (TARs)
during testing and training to familiarize users with the support
procedures and to highlight any areas lacking sufficient coverage.
Notify external vendor support groups of the production cutover

schedule. You may want to request additional support coverage during
this period.
The typical transition time period is one month for small to moderate
projects with one deployment phase and includes the execution of all
training, support infrastructure, data conversion, and the setup of the
production environment.
A meeting with the entire organization will allow management to

answer any concerns and review contingency plans. In addition, key
managers should be notified of the impending transition so they can be
prepared to deal with any issues, potential delays in service, or
organizational changes.


Estimating

each task by role.

IS Operations Staff
Business Analyst
Module Designer
IS Support Staff
Phase Effort
Programmer
IS Manager
Analyst
Transition
ID TASK %
Module Design and Build 30%
TR.080 Prepare User Training Environment 5.0% 20 0 10
TR.090 Train Users 25.0% 0 0 0
Data Conversion 30%
CV.130 Install Conversion Software 5.0% 0
CV.140 Convert and Verify Data 25.0% 0 15
Business Systems Testing 10%
TE.140 Support Acceptance Test 10.0% 0 0 25 10 25
Production Migration 30%
PM.040 Prepare Production Environment 5.0% 15 0 15
PM.050 Setup Applications 10.0% 20 70 5
PM.060 Implement Support Infrastructure 5.0% 0 0 0
PM.070 Verify Production Readiness 5.0% 0 0 0
PM.080 Commence Production 5.0% 20 20 20 20
Table 6-6 Transition Phase Estimating

5
4
25
25
5
0
Project Manager
20
20
Quality Auditor
45
Oracle Method
System Architect
5
5
35
10
30
15
5
5
25
15
5
0
5
Team Leader-Mapping
5
Table 6-6
5
Team Leader-Testing
30
5
11
15
Technical Analyst
50
50
Technical Architect
10
Trainer
85
15
0
0
0
0
User
100
100
100
100
100
100
100
100
100
Transition Phase Estimating (cont.)
Transition 6 - 17
Scheduling
Migrating the business to a new production environment requires a

high degree of planning and coordination. Scheduling is driven by the
operational concerns of the business, the effort and timing of data
conversion, and the number of users and sites to be migrated.
Scheduling suggestions for Transition follow:
Project Management
Pay particular attention to the dependencies associated with entering
setup data and data conversion tasks. For example:
• Fixed assets account codes must be entered into the general

ledger before asset categories can be entered into fixed assets.
• Categories must be established before assets can be converted.
Cutoff dates for production transactions to the legacy system and the
dates that transactions can be entered into the Oracle Applications must
be determined and communicated to the user community with
adequate lead time. For example, the data conversion approach may
call for closing all open purchase orders before going live. This means
that all invoices for those purchase orders must be entered and
matched. To allow calendar time for invoices to be processed before
cut-over, you may decide that no new purchase orders or invoices can
be entered into the legacy system for two weeks before cutover to the
new applications. Purchasing and Payables would need to hold new
requisitions and invoices until they can be entered into the new
purchasing and accounts payable systems. Similar cutoff requirements
may exist for other applications.
The focus during Transition is the transfer of knowledge about the

application system to the user staff. This phase requires substantial user
involvement and possibly third party vendor participation or
networking and hardware support.
A multi-phase/multi-site deployment approach can create several

Transition challenges. You will need to repeat most, if not all,
Transition tasks for each deployment.

Data Conversion
Data Conversion tasks require careful scheduling due to complex
dependencies among conversion steps and the entry of setup data. For
multi-phase/multi-site deployments, you will probably have to repeat
data conversions for each deployment.

Acceptance Testing occurs during the first part of Transition. For multi-
site/multi-phase deployments, decide whether separate Acceptance
Tests will occur for each deployment or if you will rely on one initial
Acceptance Test.
Training
Multi-phase/multi-site deployment approaches may require training to
be repeated for each deployment.
The following factors may affect scheduling:
• site availability
• classroom hardware, software, audio/visual equipment
• instructors
• training materials
• separate database instances may be required for each class
conducted simultaneously with other classes
• development of training data to support class exercises
• identification and distribution of class operating system and
application logon IDs, passwords, and application responsibilities
• development and distribution of user manuals to classes and user
sites prior to cutover
• availability of technical support personnel to deal with problems
during classes
The production migration process will be repeated for each deployment
in a project with multiple deployment phases.

Staffing
This diagram illustrates a typical project organization for Transition.
Transition Organization
Project Management

Technical Support Training
Applications Team Lead
Data Conversion
Team Members
Data Base
Technical Architecture &

Performance Testing
Documentation Transition
Team Lead Team Lead
Figure 6-3 Staffing Chart for Transition

Transition.
Project Management
In addition to standard functionality testing, the Acceptance Test may
include:
• a test to simulate cutover and a day of production use; this is

performed in conjunction with an iteration of data conversion
• a parallel test that consists of running both the new application
and the legacy system in parallel and performing the same
operations with both; the results are verified to ensure that the
new system has the same functionality as the legacy system
Once Transition is complete, the client staff should be able to support

and maintain the application without outside assistance. Users should
be confident in their ability to use the new system.
Data Conversion
User management is responsible for the final data conversion results.
Insist that key users participate in the data conversion validation and
signoff.
For multi-phase/multi-site deployments, data conversion team

members may be needed over a long time period. Enable new team
members to be productive quickly by carefully documenting conversion
activities.

Sufficient user participation in testing will enable user management to
sign-off on the system. For multiple deployments, decide if user testing
will occur for each deployment or only for the first deployment. Testing
for subsequent deployments may trigger new requests for
customizations and other changes.
Training
There are no significant staffing issues for this process in this phase.

Do not release specialists from their team responsibilities too soon.
There are usually unexpected issues near and during production
cutover that may require their assistance.

CHAPTER
7 Production
T his chapter describes the Production phase of AIM. The goal of

Production is to monitor and ensure that the application is
performing adequately, and to plan for future functional enhancements.

Analysis Design
Data Conversion
Documentation
Performance Testing
Training
Figure 7-1 Context of AIM Production Phase
Oracle Method Production 7 - 1

Overview
This section provides an overview of Production.
Objectives
The objectives of Production follow:
• Monitor application performance and make corrections.

• Provide agreed upon levels of user support.
• Propose and plan future application enhancements.
• Propose and plan future business and technical direction.
• Audit the production system.
• Maintain the production system.
• Decommission the former system.
The critical success factors for Production follow:
• effective change control tools and procedures

• accurate compilation of volumes, transaction histories, and other
performance drivers
• adequate staff and expertise
• effective participation by business management and users
• effective technical and application architecture
7 - 2 Production AIM Method Handbook

Overview Table

for Production.
Production Migration Application Functional Business Direction

Architecture Recommendations
Application Security Architecture Decommissioned Former System
Architectural Strategy Maintained Production

Environment
Architecture Scope and Objectives
Post Implementation Production
Conversion Scope and Objectives System
Data Conversion Strategy Refined Production Environment
Detailed Transaction and System Performance Assessment

Contingency Plan
Technical Direction
Performance Risk Assessment Recommendations
performance Testing Strategy
Process Narrative
Production System
System Capacity Plan
System Management Guide
Transition Strategy
Table 7-1 Production Phase Overview Table
Production begins after the application system has gone into

production. During this phase the application implementation project is
brought to completion. The remaining development team reviews the

application under actual usage conditions. Problems are logged and
analyzed, performance exceptions are found, and tuning is performed.
The business takes over maintenance of the application and plans are
made for future improvements.
Prerequisites
Prerequisites for Production follow. You should use these prerequisites,

if they exist, prior to beginning this phase. Otherwise, you may need to
create them during Production.
Prerequisite Source
Application Functional Architecture Application and Technical

Architecture
Application Security Architecture Application and Technical

Architecture

Architecture
Architecture Scope and Objectives Application and Technical

Architecture
Conversion Scope and Objectives Data Conversion
Data Conversion Strategy Data Conversion
Detailed Transition and Contingency Production Migration

Plan
Performance Risk Assessment Application and Technical

Architecture
Process Narrative Business Requirements

Mapping
Production System Production Migration

Prerequisite Source
System Capacity Plan Application and Technical

Architecture
System Management Guide Documentation
Transition Strategy Production Migration
Table 7-2 Production Phase Prerequisites
Processes
Audit, refine, and maintain the production system, propose the future
business and technical direction for the company, and decommission
the former system.
Key Deliverables
Business Direction The functional project team, along

Recommendations with senior management, begins
planning for future improvement
opportunities.
Decommission Former System Archive historical data and software.

If necessary, delete system
components.
Maintained Production The production environment that will

Environment be maintained.

Post-implementation The production environment is

Production System carefully maintained using procedures
and techniques documented in the
System Management Guide.
Refined Production The production system will be refined

Environment through tuning, application setup
changes, and other performance
adjustments.
System Performance System transaction and reporting

Assessment performance is quantified. Metrics are
defined and applied to determine how
well the system supports the technical
needs of the business.
Technical Direction The technical project team, the

Recommendations Information Systems staff, and senior
management begin planning for using
new technologies.
Table 7-3 Production Phase Key Deliverables

Approach
This section describes the approach for Production.
Production.
ID Task Deliverable
PM.090 Audit Production System Post-Implementation Production
System
PM.100 Measure System Performance System Performance Assessment
PM.110 Maintain System Maintained Production Environment
PM.120 Refine Production System Refined Production Environment
PM.130 Decommission Former System Decommissioned Former System
PM.140 Propose Future Business Direction Business Direction Recommendations
PM.150 Propose Future Technical Direction Technical Direction Recommendations
Table 7-4 Production Phase Tasks and Deliverables

Task Dependencies
This diagram shows the dependencies between tasks in Production.
Production Production
PM.090 PM.130
Audit Production Propose Future
System Business Direction
PM.090 PM.140
PM.100 PM.100 PM.140

Propose Future
Measure System Refine Production
Technical
Performance System
Direction
PM.100 PM.120
PM.150
PRODUCTION PRODUCTION
MIGRATION PM.110
Maintain System
1 Line MIGRATION
PM.110
( 6 5/16 tall X 6 1/4 wide)
PM.120
Decommission
Former System
PM.130
Figure 7-2 Production Phase Task Dependencies

Managing Risks
The areas of risk and mitigation for Production include the following:
Risk Mitigation
Ongoing production support Retain contractors to provide support

staff does not possess during the critical period.
adequate system knowledge.
Ensure ongoing support staff are

adequately trained and
documentation is effective.
System performance cannot Refine the production system setup

adequately support and configuration based on user
production level transaction feedback regarding system
volumes. performance, reporting, and system
functionality.
Additional exception case Establish an ongoing application

business requirements are support business function with
discovered as users perform policies, procedures, organization,
job duties following and staff to address new and
production cutover. changed requirements.
Table 7-5 Risk Management Table for Production
Tips and Techniques
This section provides tips and techniques for managing Production. In


After production cutover, new system maintenance and enhancement
begins. Some related considerations are:
• New technologies that were not available or out of scope at the

beginning of the implementation may now be considered.
• New products and applications may be investigated.

• Requested customizations that were out of scope for the initial
implementation may be addressed.
• Planning for the next release of Oracle Applications may begin.
Adapt the Module Design and Build and Business System Testing
processes to support the design, development, and testing of
enhancements to the production system. Incorporate the updated
information into the Customization Strategy, Design Standards, and
Build Standards so that they represent the standards for future
enhancements. Define additional standards for tools that you may use
for future enhancements.
System maintenance falls into three major categories: routine, on-
demand, and upgrade:
• Routine maintenance includes setting up and executing hot and

cold backups, monitoring system performance, managing
tablespace, archiving and purging data, and database tuning. It
also involves tracking updates to the production configuration,
application setup, and application of patches.
• On-demand maintenance usually occurs in response to a user
request and includes setting up users, maintaining user access,
and correcting user and interface table data errors.
• Upgrade maintenance involves both minor and major upgrades.
It may need to be evaluated in terms of organizational and
structural impact, particularly in the case of major upgrades.
Minor upgrades are typically small changes or corrections to
system functionality, or performance enhancements for a specific
process.
System refinement involves soliciting user feedback and acting on

requests relative to the implementation, production system, or support.
These requests may involve adjusting application setups or profile
options, tuning a report or form, or major programming enhancements.
All enhancement requests should be logged, evaluated in terms of
impact to the system and/or organization, and tested thoroughly prior
to implementing the changes in the production environment.
It is strongly recommended that a separate shadow instance be created

and refreshed from the production instance to provide an environment
that resembles the production configuration but is safe for testing
patches, upgrades, and system refinements.


Estimating

each task by role.
Applications Expert
Database Designer
IS Operations Staff
Business Analyst
Phase Effort
IS Manager
Facilitator
Analyst
Production
ID Task
Production Migration 77.8%
F.PM.090 Audit Production System 11.7% 50 0 0
F.PM.100 Measure System Performance 2.6% 40
F.PM.110 Maintain System 38.0% 20 0
F.PM.120 Refine Production System 11.4% 10 20 0
F.PM.130 Decommission Former System 5.3% 0 0
F.PM.140 Propose Future Business Direction 4.8% 75 0
F.PM.150 Propose Future Technical Direction 4.0% 0
100.0%
Table 7-6 Production Phase Estimating

0
0
IS Support Staff
Lead Tester
Module Designer
15
20
Oracle Method
Production Database Administrat
Programmer
50
20
Project Manager
50
Project Sponsor
Quality Auditor
10
40
15
System Architect
Team Leader - Architecture
Team Leader - BR
Table 7-6
Team Leader - Conversion
Team Leader - Customization
Team Leader - Documentation

Team Leader - Performance Test
Team Leader - Training

50
25
20
20
Technical Analyst
Technical Architect
50
Technical Expert
Technical Expert Environment
Technical Expert - Existing Syste

Production Phase Estimating (cont.)
Technical Writer
Tester
Trainer
0
User
100
100
100
100
100
100
Production 7 - 13
Scheduling
The project changes its focus to providing initial support for the
production environment as well as transferring knowledge and
responsibilities to the ongoing applications support infrastructure.
Scheduling suggestions for Production follow:
Project Management
Although budgetary concerns may be an issue, retain sufficient
resources to complete the project in a quality manner.
Verify that you have completed the following activities:
• prepared the organization’s application support group to deal

with questions and initial system problems
• provided the appropriate applications and technical architecture
to support the system load
• facilitated preparation of support infrastructure mechanisms
• developed appropriate documentation for support organizations
• trained the users and provided them with effective
documentation
Multiple deployments require multiple iterations of Production tasks

which may differ in significant ways. This will have a scheduling
impact.
Complexities that can affect scheduling are:
• “Mini” AIM phases and processes may be needed for each

deployment unless the business functions operate exactly the
same at all sites.
• Procedural workarounds that address gaps may vary according
to specific site requirements and could require adjustments to the
user training classes and user documentation.

• New interface and data conversion requirements could exist for
specific deployments if legacy systems are not available
throughout the company.
• Oracle Applications upgrades may be necessary during the
rollout period.
The implementation development project does not end when the team
installs the application system into production; auditors must perform
the system evaluation, and users may have questions or issues to be
resolved. Production prepares for these situations in an organized and
systematic way. There is also an opportunity for the client and
consultants to plan future development efforts.

Staffing
This diagram illustrates a typical project organization for Production.
Production Organization
Project Management
Administrative Assistant/
Project Librarian
Technical Support Training and

Transition Support
Team Lead Team Lead
Figure 7-3 Staffing Chart for Production
Production.
Project Management
In addition to support and maintenance responsibilities, Production
requires other client involvement. Users must be prepared to provide
input into the system audit and may need to provide data on
transaction volumes and response times. In addition, users may be
asked to search for and report as many problems as possible during the
warranty period.
During Production, the project team is usually limited to developers

and support personnel. Each team member has to maintain or support
a broad functional area and must be cross-trained appropriately for this
responsibility.
All of the tasks in Production can be performed by the project team,

with the exception of the system audit (which is performed by the client
or a third party auditor). Use this time to transfer the ongoing jobs of
support and maintenance to the user.

The primary staffing challenges in Production are:
• retaining an appropriate number of team members to complete

the project
• transferring responsibilities to user groups
• managing staff during the rollout of a multi-phased deployment
when key personnel may not be available for the project duration

APPENDIX
A AIM Work
Breakdown
Structure
T his appendix provides a list of the full AIM work breakdown

structure (WBS).
Oracle Method AIM Work Breakdown Structure A - 1

AIM Classic Approach Work Breakdown Structure
The following is a list of the AIM Classic approach work breakdown
structure.
ID Task Name Deliverable
A DEFINITION
A.PL Project Planning
A.PL.BEG Begin Definition Phase Planning
A.CR.010 Establish Scope, Objectives, and Approach Scope, Obj & Approach
A.CR.020 Define Control and Reporting Strategies, CR Strats, Stds & Procs
Standards, and Procedures
A.CR.030 Establish Management Plans Quality Plan
A.WM.010 Define Work Management Strategies, WFM Strats, Stds & Procs
A.WM.020 Establish Workplan Project Workplan
A.WM.030 Establish Finance Plan Finance Plan
A.RM.010 Define Resource Management Strategies, RM Strats, Stds & Procs
A.RM.020 Establish Staffing and Organization Plan Staffing Plan
A.RM.030 Implement Organization Project Organization
A.RM.040 Establish Physical Resource Plan Physical Resource Plan
A.RM.050 Establish Infrastructure Project Infrastructure
A.QM.010 Define Quality Management Strategies, QM Strats, Stds & Procs
A.CM.010 Define Configuration Management CM Strats, Stds & Procs
Strategies, Standards, and Procedures
A.PL.END End Definition Phase Planning
A.EX.BEG Start Definition Phase Execution
A.RD Business Requirements Definition
A.RD.010 Identify Financial and Operating Structure Financial & Op Struct
A.RD.020 Conduct Current Business Baseline Current Business Baseline
A.RD.030 Develop Future Process Model Future Process Model
A.RD.040 Develop Future Business Function Model Future Bus Func Model
A.RD.050 Establish Process and Mapping Summary Process & Mapping Sum
A.RD.060 Gather Business Volumes Bus Volume Requirements
A.TA Application and Technical Architecture
A.TA.010 Define Architecture Scope, Objectives, Arch Scope, Obj & App
and Approach
A - 2 AIM Work Breakdown Structure AIM Method Handbook

A.TA.020 Prepare Architecture Strategy Architectural Strategy

A.TA.030 Establish Architecture Requirements Architectural Reqs
A.TA.040 Develop Conceptual Architecture Conceptual Architecture
A.TA.050 Conduct Technical Architecture Baseline Technical Arch Baseline
A.MD Module Design and Build
A.MD.010 Prepare Customization Strategy Customization Strategy
A.CV Data Conversion
A.CV.010 Define Conversion Scope, Objectives, Conv Scope, Obj & App
and Approach
A.CV.020 Prepare Conversion Strategy Conversion Strategy
A.DO Documentation
A.DO.010 Prepare Glossary Glossary
A.DO.020 Specify Documentation Requirements Documentation Reqs
A.DO.030 Determine Documentation Standards Doc Stds & Procs
and Procedures
A.PT Performance Testing
A.PT.010 Define Performance Testing Scope, Perf Test Scop, Obj & App
A.PT.020 Prepare Performance Testing Strategy Perf Testing Strategy
A.EX.END End Definition Phase Execution
A.TR Training
A.TR.010 Prepare Training Strategy Performance Testing Strat
A.TR.030 Conduct General Education Classes Trained Project Team
A.TR.040 Conduct High-level Overview of Trained Project Team
Application Features
A.CT.CTR Phase Control
A.CT.BEG Begin Phase Control
A.CT.SUM Phase Control
A.CT.RES Unallocated Reserve
A.CT.END End Phase Control
A.CO.COMP Phase Completion
A.CO.BEG Begin Phase Completion
A.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
A.RM.080 Release Staff Released Staff
A.RM.090 Release Physical Resources Released Physical
Resources
A.QM.050 Perform Quality Assessment Quality Report
A.CM.060 Audit Key Deliverables Audited Phase Baseline
A.CO.END End Phase Completion

B OPERATIONS ANALYSIS
B.PL.PLAN Phase Planning
B.PL.BEG Begin Phase Planning
B.PL.SUM Review and Revise Project Plans
B.PL.END End Phase Planning
B.EX.BEG Begin Operations Analysis Execution
B.RD Business Requirements Definition
B.RD.070 Create Business Requirements Scenarios Bus Reqs Scenario
B.RD.080 Determine Audit and Control Requirements Audit & Control Reqs
B.RD.090 Identify Business Availability Requirements Bus Availability Reqs
B.RD.100 Develop Reporting Requirements Master Rpt Tracking List
B.BR Business Requirements Mapping
B.BR.010 Prepare Mapping Environment Conf Mapping Environ
B.BR.020 Map Business Requirements Bus Reqs Mapping Form
B.BR.030 Map Business Data Bus Data Mapping
B.BR.040 Conduct Integration Fit Analysis Integration Fit Analysis
B.BR.050 Develop Information Flow Model Information Flow Model
B.BR.060 Develop Information Access Model Information Access Model
B.BR.070 Conduct Reporting Fit Analysis Master Rpt Tracking List
B.BR.080 Test Business Solutions Mapping Scenario
B.BR.090 Confirm Integrated Business Solutions Acceptance Certificate
B.TA Application and Technical Architecture
B.TA.060 Develop System Availability Strategy System Availability Strat
B.TA.070 Define Future Application Deployment Future Applic Deployment
B.TA.080 Develop Reporting Strategy Reporting Strategy
B.TA.090 Revise Conceptual Architecture Conceptual Architecture
B.TA.100 Define Architecture Subsystems Architecture Subsystems
B.TA.110 Propose Architecture Subprojects Arch Subproject Proposals
B.MD Module Design and Build
B.MD.020 Define and Estimate Custom Extensions Solution Document
B.CV Data Conversion
B.CV.030 Prepare Conversion Standards Conversion Standards
B.DO Documentation
B.DO.040 Prepare Documentation Environment Documentation Environ
B.DO.050 Produce Documentation Prototypes Doc Prototypes &
Templates Templates
B.PT Performance Testing
B.PT.030 Identify Performance Test Scenarios Perf Test Scenarios
B.PT.040 Identify Performance Test Transaction Perf Test Trans Models
Models
B.TR Training
B.TR.020 Prepare Project Team Training Environment Proj Team Train Environ

B.TR.050 Prepare Project Team Training Train Prep Checklist

B.TR.060 Train Project Team Trained Project Team
B.PM Production Migration
B.PM.010 Prepare Transition Strategy Transition Strategy
B.EX.END End Operations Analysis Execution
B.CT.CTR Phase Control
B.CT.BEG Begin Phase Control
B.CT.SUM Phase Control
B.CT.RES Unallocated Reserve
B.CT.END End Phase Control
B.CO.COMP Phase Completion
B.CO.BEG Begin Phase Completion
B.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
B.RM.080 Release Staff Released Staff
B.RM.090 Release Physical Resources Released Physical Res
B.QM.050 Perform Quality Assessment Quality Report
B.CM.060 Audit Key Deliverables Audited Phase Baseline
B.CO.END End Phase Completion
C SOLUTION DESIGN
C.PL.PLAN Phase Planning
C.PL.BEG Begin Phase Planning
C.PL.SUM Review and Revise Project Plans
C.PL.END End Phase Planning
C.EX.BEG Begin Solution Design Execution
C.BR Business Requirements Mapping
C.BR.100 Create Process Narratives Process Narrative
C.BR.110 Define Application Setups App Setup Document
C.BR.120 Design Security Profiles Security Profiles
C.TA Application and Technical Architecture
C.TA.120 Design Application Security Architecture Application Security Arch
C.TA.130 Design Application Functional Architecture Application Func Arch
C.TA.140 Design Logical Application and Log Applic and Database
Database Architecture Architecture
C.TA.150 Design Physical Database Architecture Physical Database Arch
C.TA.160 Design Hardware and Network Hardware & Network
C.TA.170 Develop System Capacity Plan System Capacity Plan
C.TA.180 Assess Performance Risks Perf Risk Assessment
C.TA.190 Design System Management Procedures System Mgmt Procs
C.MD Module Design and Build
C.MD.030 Define Design Standards Design Standards

C.MD.040 Define Build Standards Build Standards

C.MD.050 Design Database Extensions Database Exten Design
C.MD.060 Produce Module Functional Design Module Func Design
C.MD.070 Produce Module Technical Design Module Tech Design
C.MD.080 Review Detailed Designs Acceptance Certificate
C.CV Data Conversion
C.CV.040 Prepare Conversion Environment Conversion Environment
C.CV.050 Perform Conversion Data Mapping Conversion Data Mapping
(Map Conversion Data)
C.CV.060 Design Manual Conversion Strategy Manual Conversion Strat
C.CV.070 Design Conversion Programs Conv Program Design
C.CV.080 Prepare Conversion Test Plans Conv Test Plans
C.DO Documentation
C.DO.060 Produce Initial User Reference Manual Initial User Ref Manual
C.DO.070 Produce Initial User Guide Initial User Guide
C.DO.080 Produce Initial Technical Reference Manual Initial Tech Ref Manual
C.DO.090 Produce Initial System Management Guide Initial System Mgmt Guide
C.TE Testing
C.TE.010 Develop Test Strategy Testing Strategy
C.TE.020 Develop Unit Test Scripts Unit Test Scripts
C.TE.030 Develop Link Test Scripts Link Test Scripts
C.TE.040 Develop System Test Scripts System Test Scripts
C.TE.050 Develop Systems Integration Test Scripts Systems Int Test Scripts
C.PT Performance Testing
C.PT.050 Create Performance Test Scripts Performance Test Scripts
C.PT.060 Design Performance Test Transaction Test Transac Prog Design
Programs
C.PT.080 Design Performance Test Data Perf Test Data Design
C.PT.090 Design Test Database Load Programs Test Dbase Ld Prog Design
C.TR Training
C.TR.070 Develop User Training Materials User Training Manuals
C.PM Production Migration
C.PM.020 Design Production Support Infrastructure Prod Support Infrastructure
C.PM.030 Develop Detailed Transition & Detailed Trans & Cont Plan
Contingency Plan
C.EX.END End Solution Design Execution
C.CT.CTR Phase Control
C.CT.BEG Begin Phase Control
C.CT.SUM Phase Control
C.CT.RES Unallocated Reserve
C.CT.END End Phase Control
C.CO.COMP Phase Completion

C.CO.BEG Begin Phase Completion

C.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
C.RM.080 Release Staff Released Staff
C.RM.090 Release Physical Resources Released Physical Res
C.QM.050 Perform Quality Assessment Quality Report
C.CM.060 Audit Key Deliverables Audited Phase Baseline
C.CO.END End Phase Completion
D BUILD
D.PL.PLAN Phase Planning
D.PL.BEG Begin Phase Planning
D.PL.SUM Review and Revise Project Plans
D.PL.END End Phase Planning
D.EX.BEG Begin Build Execution
D.MD Module Design and Build
D.MD.090 Prepare Development Environment Development Environment
D.MD.100 Implement Database Extensions Custom Database Objects
D.MD.110 Create Custom Modules Module Source Code
D.MD.120 Create Installation Routines Installation Routines
D.CV Data Conversion
D.CV.090 Develop Conversion Programs Conversion Programs
D.CV.100 Perform Conversion Unit Test Unit Tested Conv Progs
D.CV.110 Perform Conversion Business Object Test Bus Obj Tested Conv Progs
D.CV.120 Perform Conversion Validation Test Valid Tested Conv Progs
D.DO Documentation
D.DO.100 Complete User Reference Manual User Reference Manual
D.DO.110 Complete User Guide User Guide
D.DO.120 Complete Technical Reference Manual Tech Reference Manual
D.DO.130 Complete System Management Guide System Mgmt Guide
D.DO.140 Provide Online Help Text Online Help Text
D.TE Business System Testing
D.TE.060 Prepare Testing Environments Testing Environments
D.TE.070 Perform Unit Testing Unit Tested Modules
D.TE.080 Perform Link Testing Link Tested Modules
D.TE.090 Perform Installation Test Tested Install Routines
D.TE.100 Prepare Key Users for Testing Prepared Users
D.TE.110 Perform System Testing Sys Tested Applications
D.TE.120 Perform Regression Testing Regression Test Exec Mod
D.TE.130 Perform Systems Integration Testing Integration Tested Systems
D.PT Performance Testing
D.PT.070 Develop Performance Test Transaction Test Transaction Programs
Programs

D.PT.100 Develop Test Database Load Programs Test Database Load Progs
D.PT.110 Construct Performance Test Database Perf Test Database
D.PT.120 Prepare Performance Test Environment Perf Test Environ
D.PT.130 Execute Performance Test Perf Test Results
D.PT.140 Create Performance Test Report Perf Test Report
D.EX.END End Build Execution
D.CT.CTR Phase Control
D.CT.BEG Begin Phase Control
D.CT.SUM Phase Control
D.CT.RES Unallocated Reserve
D.CT.END End Phase Control
D.CO.COMP Phase Completion
D.CO.BEG Begin Phase Completion
D.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
D.RM.080 Release Staff Released Staff
D.RM.090 Release Physical Resources Released Physical Res
D.QM.050 Perform Quality Assessment Quality Report
D.CM.060 Audit Key Deliverables Audited Phase Baseline
D.CO.END End Phase Completion
E TRANSITION
E.PL.PLAN Phase Planning
E.PL.BEG Begin Phase Planning
E.PL.SUM Review and Revise Project Plans
E.PL.END End Phase Planning
E.EX.BEG Begin Transition Execution
E.CV Data Conversion
E.CV.130 Install Conversion Software Installed Conv Software
E.CV.140 Convert and Verify Data Converted & Verified Data
E.TE Business System Testing
E.TE.140 Support Acceptance Test Acceptance Results
E.TR Training
E.TR.080 Prepare User Training Environment User Training Environ
E.TR.090 Train Users Trained Users
E.PM Production Migration
E.PM.040 Prepare Production Environment Production Environment
E.PM.050 Setup Applications Configured Applications
E.PM.060 Implement Support Infrastructure Doc Support Procs
E.PM.070 Verify Production Readiness Prod-Ready System
E.PM.080 Commence Production Production System
E.EX.END End Transition Execution
E.CT.CTR Phase Control

E.CT.BEG Begin Phase Control

E.CT.SUM Phase Control
E.CT.RES Unallocated Reserve
E.CT.END End Phase Control
E.CO.COMP Phase Completion
E.CO.BEG Begin Phase Completion
E.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
E.RM.080 Release Staff Released Staff
E.RM.090 Release Physical Resources Released Physical Res
E.QM.050 Perform Quality Assessment Quality Report
E.CM.060 Audit Key Deliverables Audited Phase Baseline
E.CO.END End Phase Completion
F. PRODUCTION
F.PL.PLAN Phase Planning
F.PL.BEG Begin Phase Planning
F.PL.SUM Review and Revise Project Plans
F.PL.END End Phase Planning
F.EX.BEG Begin Production Execution
F.PM Production Migration
F.PM.090 Audit Production System Post-Implement Prod Sys
F.PM.100 Measure System Performance System Perf Assessment
F.PM.110 Maintain System Maintained Prod Environ
F.PM.120 Refine Production System Refined Prod Environ
F.PM.130 Decommission Former System Decomm Former Sys
F.PM.140 Propose Future Business Direction Bus Direction Recom
F.PM.150 Propose Future Technical Direction Tech Direction Recom
F.EX.END End Production Execution
F.CT.CTR Phase Control
F.CT.BEG Begin Phase Control
F.CT.SUM Phase Control
F.CT.RES Unallocated Reserve
F.CT.END End Phase Control
F.CO.COMP Phase Completion
F.CO.BEG Begin Phase Completion
F.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
F.RM.080 Release Staff Released Staff
F.RM.090 Release Physical Resources Released Physical Res
F.QM.050 Perform Quality Assessment Quality Report
F.CM.060 Audit Key Deliverables Audited Phase Baseline
F.CO.END End Phase Completion

APPENDIX
B AIM Roles
T his appendix gives a brief description of each role and highlights its
main responsibilities.
Oracle Method AIM Roles B - 1

Role Descriptions
The application administrator is responsible for code table maintenance
and production control. This person ensures the data content of the
shared code tables, for example, application setup values, lookup tables,
and system calendar is correct prior to and during production.
Scheduling the production batch processes is an optional additional
responsibility.
The application administrator may also be responsible for administering

the data that determines which data and functions users or groups of
users may access.
Application Architect
The application architect establishes the application architecture of a
newly implemented system. To accomplish this, the application
architect translates the future vision of the business into an application
and data deployment strategy. This strategy includes decisions about
centralizing or decentralizing business data and processing,
identification of interface points and specific requirements for data
transfer and synchronization across the business, critical setup of
applications to support the business process mapping, strategies to
support the reporting needs of the business, and other less general
requirements that may impact the architecture (such as multilingual
requirements). To ensure compatibility with the overall applications
architecture, the application architect provides input to more detailed
technical design efforts such as interfaces and custom components,
The application architect works closely with the technical architect to

ensure the physical layers of the architecture are consistent with and
fully support, the business and information systems vision for the
corporation. This synergism may extend all the way from scoping and
planning the project through to the final architecture deliverables and
client review.
Application Expert
The application expert provides knowledge and guidance regarding
application functionality. This person also supports and provides
interpretation for tools, templates, and methods.
B - 2 AIM Roles AIM Method Handbook

Business Analyst
The business analyst conducts interviews and working sessions. This
person also identifies detailed business requirements and creates
business requirement scenarios.

The business line manager participates in interviews and working
sessions by providing information about business objectives and ways
in which the units operate and respond to events to achieve those
objectives. Also, this person describes problems the business unit faces
and requirements for the computer system. The business line manager
hosts site visits by staff to collect the information. The business line
manager should review the content of the analysis documentation to
ensure it accurately describes the business and requirements.
Additionally, this person is responsible for allocating staff time to
provide detailed information about the day-to-day business.
The role of the business line manager should be filled by a person who
will manage one of the business units that will use the system.

The client project manager is responsible for the day-to-day
management of the client’s contractual commitments to the project.
This person must understand the client’s business objectives for the
project so that these can form the basis for resolving problems, conflicts
of interest, and making compromises.
The client project manager obtains physical resources such as

accommodation space, office equipment, computer equipment, and
materials. Additionally, this person ensures the client allocates time to
the project. The client project manager introduces the consulting staff to
the other client staff. This person is responsible for monitoring the
project’s performance, progress against milestones, appropriateness of
work, quality of work, and seeks to resolve any problems with work or
relationships between development and business staff. The client
project manager usually performs intermediate and phase-end signoffs.
The client project manager ensures availability of users, reviews

contents of models, and ensures user commitment, review, and signoff
of deliverables.

The configuration manager plans, establishes, and controls the PJM
Configuration Management process on the project, with the following
responsibilities:
• develops, documents, and implements PJM Configuration

Management plans and procedures
• establishes project baselines and determines the content of project
releases
• ensures that no unauthorized changes are made to a project
baseline
• enforces Configuration Management procedures across all project
processes
• establishes and ensures that the PJM Configuration Management
Repository is adequately maintained and protected against
damage or loss
The database administrator is required on large projects when there are
a number of teams of analysts or designers working on different
business areas or subsystems. During analysis, the database
administrator ensures data shared by business areas is modeled by a
common data structure that satisfies the functional requirements of
those areas. During design of the system architecture, the database
administrator performs a similar function for the system data model.
The database administrator can also identify common areas of
functionality.
This person should quickly understand the functional and data

requirements of the various areas, have strong analytical skills, and
have the ability to resolve conflicting requirements.
Database Designer
The database designer is responsible for producing the logical and
physical database designs. This person reviews the module designs to
ensure efficient access to the database.
The database designer must have a thorough understanding of the

system data model. Additionally, an understanding of the technical
architecture and functionality of the system is required so that

compromises in the design can be made when different functions place
conflicting requirements on the database.
Facilitator
The facilitator runs mapping and process design sessions and keeps
momentum going.
IS Manager
The IS manager directs the client information systems organization
within a business. The IS manager acts as a business line manager for
the staff in the IS organization. This person is responsible for the
technical infrastructure of a business, including decisions about
purchases, in-house development, and operational maintenance and
support. The following information systems staff report directly or
indirectly to the IS manager:
• applications and technical architect

• technical analyst
• designer
• technical (database, network, system) administrator
• operations staff
• support staff
The IS manager defines the information systems strategy for a

corporation and puts the strategy into practice through standards,
policies, practices, and information systems selection processes.
IS Operations Staff
The IS operations staff is responsible for operating the existing
computer systems and new systems. The IS operations staff provides
information on operational requirements. This person acts as a
consumer of the training program.
IS Support Staff
The IS support staff is responsible for technical support of the client’s
systems. This person provides information about any IS standards with
which the project must comply, supports the business’ software
systems, and takes over support of the system during production. The

IS support staff participates in any training program for the system
initially as consumers and later, possibly as providers. Finally, the IS
support staff provides information about existing systems the new
system will interface with or replace.
Lead Tester
The lead tester oversees the test script planning, development, and
execution activities. The lead tester reviews and approves the test
scripts. This person manages the test execution, monitors the progress
of testing activities, and ensures that the test results and problems are
logged. The lead tester also helps prioritize problem log entries.
Module Designer
The module designer is responsible for production of application and
module designs. This person communicates closely with the database
designer to ensure the database design meets the data requirements of
the module functionality and module access data efficiently. The
module designer also produces module and link test plans. During the
various testing activities and the production phase, this person
diagnoses faults and determines corrections.
The module designer must understand requirements from the business

analysis and how to meet these requirements using the technical and
system architectures and system data model.
Network Administrator
The Network Administrator is responsible for administering the
network. This includes ensuring that the network is correctly
configured, configuring and maintaining the network environment, and
performance monitoring the network.

The production database administrator installs and configures the
production database and maintains database access controls. This
person provides consultation on performance, is responsible for
monitoring growth and fragmentation of the production database, and
ensures database backup and recovery.

Programmer
The programmer produces working code that meets the module
specifications. The programmer diagnoses and corrects faults found by
tests. During production the programmer executes regression tests on
the corrections.
The programmer must have a thorough understanding of the

specifications for the modules to produce code. This person should also
understand how those modules fit in the system architecture and
business and technical requirements that they implement.

The project administrator supports the project manager and project
coordinator by performing routine or repetitive tasks. The project
administrator prepares or maintains reports, records, logs and other
written communications, collects progress data from project leaders,
and distributes project calendars, meeting agendas, and meeting
minutes. The project administrator:
• organizes the Project Library, assigns documents into the library,

and maintains control of documents in the library
• orients new project members to the project environment, policies,
and procedures
• coordinates with administrators in client and subcontractor
organizations
• prepares project progress reports
• records and distributes minutes, decisions, and actions from
management meetings
• generates routine status information from project records
• maintains information on project staff such as grade,
qualifications, training, parent business unit or subcontractor,
telephone and address, project assignment history, and so on
For application implementations, the project administrator also

performs deliverable and template version management, gathers and
checks out deliverables, assigns document names and records new
documents into the library. This person also provides deliverable status
and advice regarding process integration.

Project Manager
The project manager is ultimately responsible for the success or failure
of the project. This person must understand the project business
objectives of both the client and consultant, and have a clear vision of
how to achieve those objectives. The project manager agrees on the
scope of the project with the client and resolves any conflicts among the
various objectives of its stakeholders.
The project manager is responsible for the project planning, resourcing,

monitoring, and reporting the progress against the plan. This person
obtains any physical resources required for the project, recruits staff,
and, if necessary, dismisses staff. The project manager is responsible for
ensuring that activities are performed in accordance with the Quality
Plan.
Internal responsibilities of the project manager role should be delegated

to subordinate team leaders, as documented in the project organization
plan.
Project Sponsor
The project sponsor controls the budget and finances the project. This
person is usually a member of senior management. On large, cross-
functional projects the project sponsor may be a board member. This
person must have a clear understanding of the project objectives,
particularly concerning delivery of the business benefits. The project
sponsor is the ultimate arbiter on conflicting business requirements and
scope changes. The project sponsor ensures the project is delivered on
time and within budget.
The project sponsor is responsible for ensuring other members of the

management share commitment to the project. This person may
provide the resources, particularly staff time, required to make the
project a success. The project sponsor usually performs the final sign-
off.
Quality Auditor
The quality auditor conducts quality audits of the project. This position
should be filled by a person independent of the project staff in the
consulting organization. The quality auditor needs training in the audit
process. The quality auditor prepares for, conducts, reports on, and
follows up on any actions raised by the quality audit(s).

System Administrator
The system administrator is responsible for administering the
development system. This person’s responsibilities include ensuring
hardware is correctly configured; installing, configuring, and
maintaining operating and development software; and ensuring that
daily backups of the system are performed. The system administrator
also designs and maintains the system’s security (for example,
establishing system accounts).
The system administrator provides first-line support for problems with

the development system and ensures faults are quickly rectified. This
person may perform the set up and initial maintenance of the
production system or advise the client’s operational staff on these tasks.
The system administrator works with the project team to optimize
system performance.
The system administrator installs packaged applications environments

and converts data.
Team Leader
The team leader plans, directs, and monitors the day-to-day work of the
team. This person assigns work packages to the team members and
ensures that they understand the requirements. The team leader is
responsible for building team cohesion, motivating the teams, and
providing assistance and encouragement to the team members.
Each team leader performs the final quality control and quality
assurance for the team by reviewing all deliverables. This person also
signs off team work completion and quality. Work that is not up to
quality standards is returned. Team leaders review deliverables from
other teams when these deliverables may impact aspects of the system.
This person reports the team’s progress to the project manager.
Larger projects may include team leaders in the area of analysis,

architecture, design, build, conversion, documentation, testing, training,
and transition. On small projects the roles of team leader and project
manager may be performed by the same individual.
Technical Analyst
The technical analyst proposes solutions and technical assumptions and
develops data profiles in support of testing.

Technical Architect
The technical architect is responsible for architecting the physical
components of the database, hardware, and network in support of the
application architecture. To accomplish this, the technical architect
needs to design the detailed database, hardware, and network
architecture to support the application architecture and deployment
strategy. This includes decisions about the physical distribution of
processing across client and server machines, capacity planning of the
technical infrastructure, detailed design of the layout of databases, and
identification and advisement of performance risks. The technical
architect oversees detailed technical work on interface and system
design to ensure the detailed work is consistent with the overall
technical architecture.
The technical architect works closely with the application architect to

achieve an integrated overall architecture supporting the business and
information systems vision.
Technical Expert
The technical expert is a generic role covering the provision of high
expertise in the use and application of the various technologies used to
construct the system where these are not specifically covered by other
roles (such as database designer). On the project there will be a role for
each technology; for example, C++ programming, Oracle Forms, and
SQL Connect. There may also be experts needed in the areas of user
interface, standards, data conversion, and performance measurement.
The technical expert provides for the provision of standards for use of
the technology (for example, C programming and GUI standards)
provision of consultancy on the technology to other team members, and
participation in reviews of the use of the technology.
Technical Writer
The technical writer becomes familiar with the business and technical
requirements of the system and how the architecture, design, and
modules achieve those objectives. The technical writer specifies and
produces the user, technical, and operational documentation.
Tester
The testers develop and execute test script. Testers ensure test scripts
are reviewed by the appropriate business analysts prior to test

execution. This person records test results during testing activities and
documents test faults in the problem log. Testers update test scripts to
reflect approved change requests or software faults that were not
anticipated in the original development. When problems are resolved
after retesting, testers update the problem log.
Trainer
The trainer is responsible for defining the training requirements,
preparing a training plan, producing training material, and delivering
courses.
User
The user is a member of the client’s staff who actually uses the
production system. The user’s responsibility is to be a consumer of the
training program and report problems with the production system.

APPENDIX
C Role Usages
T his appendix provides a general alphabetical index of the roles used

in AIM. The following table lists each role and the AIM task(s) that
requires its participation.
Oracle Method Role Usages C - 1

Role Usages
Time not included in estimate is indicated by an asterisk (*).
Role Name ID Task Name %

Application Administrator B.BR.010 Prepare Mapping Environment 20
B.TR.020 Prepare Project Team Training 20
Environment
C.CV.040 Prepare Conversion Environment 20
D.MD.090 Prepare Development Environment 15
D.PT.120 Prepare Performance Test 20
Environment
D.TE.060 Prepare Testing Environments 20
E.PM.040 Prepare Production Environment 15
E.PM.050 Setup Applications 20
E.TR.080 Prepare User Training Environment 20
F.PM.110 Maintain System 20
F.PM.120 Refine Production System 10
Application Architect A.TA.010 Define Architecture Scope, Objectives, 10
and Approach
A.TA.020 Prepare Architecture Strategy 10
A.TA.030 Establish Architecture Requirements 45
A.TA.040 Develop Conceptual Architecture 40
B.BR.020 Map Business Requirements 5
B.BR.070 Conduct Reporting Fit Analysis 5
B.TA.070 Define Future Application Deployment 85
B.TA.080 Develop Reporting Strategy 50
B.TA.090 Revise Conceptual Architecture 35
B.TA.100 Define Architecture Subsystems 30
C.TA.130 Design Application Functional 60
Architecture
C.TA.140 Design Logical Application and 40
Database Architecture
C.TA.180 Assess Performance Risks 25
C.TA.190 Design System Management 10
Procedures
C.TE.050 Develop Systems Integration Test 20
Scripts
Application Expert B.BR.020 Map Business Requirements 25
B.BR.030 Map Business Data 30
C - 2 Role Usages AIM Method Handbook

B.BR.080 Test Business Solutions 30

B.BR.090 Confirm Integrated Business Solutions 25
B.RD.070 Create Business Requirements 30
Scenarios
C.TA.120 Design Application Security 60
Architecture
Business Analyst A.DO.010 Prepare Glossary 95
A.DO.020 Specify Documentation Requirements 85
A.RD.010 Identify Financial and Operating 100
Structure
A.RD.020 Conduct Current Business Baseline 90
A.RD.030 Develop Future Process Model 90
A.RD.040 Develop Future Business Function 100
Model
A.RD.050 Establish Process and Mapping 100
Summary
A.RD.060 Gather Business Volumes 100
A.TA.050 Conduct Technical Architecture 20
Baseline
B.BR.060 Develop Information Access Model 75
B.MD.020 Define and Estimate Custom 10
Extensions
B.PT.030 Identify Performance Test Scenarios 35
B.PT.040 Identify Performance Test Transaction 10
Models
Scenarios
B.RD.080 Determine Audit and Control 100
Requirements
B.RD.090 Identify Business Availability 95
Requirements
B.RD.100 Develop Reporting Requirements 100
B.TA.070 Define Future Application Deployment 15


C.BR.100 Create Process Narratives 95
C.BR.110 Define Application Setups 80
C.BR.120 Design Security Profiles 80
C.DO.070 Produce Initial User Guide 20
C.MD.060 Produce Module Functional Design 20
C.MD.080 Review Detailed Designs 30
C.PT.050 Create Performance Test Scripts 30
C.PT.080 Design Performance Test Data 30
C.PT.090 Design Test Database Load Programs 10
Architecture
C.TA.130 Design Application Functional 40
Architecture
C.TE.040 Develop System Test Scripts 60
C.TR.070 Develop User Training Materials 45
D.CV.120 Perform Conversion Validation Test 30
D.PT.070 Develop Performance Test Transaction 5
Programs
D.PT.100 Develop Test Database Load Programs 5
D.PT.140 Create Performance Test Report 5
E.PM.080 Commence Production 20
F.PM.090 Audit Production System 50
F.PM.140 Propose Future Business Direction 75
Business Line Manager A.DO.020 Specify Documentation Requirements *
A.DO.030 Determine Documentation Standards *
and Procedures
A.RD.010 Identify Financial and Operating *
Structure
A.RD.020 Conduct Current Business Baseline *
A.RD.030 Develop Future Process Model *
A.RD.050 Establish Process and Mapping *
Summary
A.RD.060 Gather Business Volumes *
A.TR.010 Prepare Training Strategy *
B.BR.020 Map Business Requirements *
B.BR.030 Map Business Data *
B.BR.060 Develop Information Access Model *
B.BR.080 Test Business Solutions *

B.BR.090 Confirm Integrated Business Solutions *

B.BR.100 Create Process Narratives *
B.MD.020 Define and Estimate Custom *
Extensions
B.RD.080 Determine Audit and Control *
Requirements
B.RD.090 Identify Business Availability *
Requirements
B.RD.100 Develop Reporting Requirements *
B.TA.080 Develop Reporting Strategy *
C.BR.100 Create Process Narratives *
C.MD.080 Review Detailed Designs *
C.PM.030 Develop Detailed Transition and *
Contingency Plan
C.TR.070 Develop User Training Materials *
D.TE.100 Prepare Key Users for Testing *
D.TE.110 Perform System Testing *
D.TE.130 Perform Systems Integration Testing *
F.PM.090 Audit Production System *
F.PM.140 Propose Future Business Direction *
Client Project Manager A.TR.010 Prepare Training Strategy *
A.TR.030 Conduct General Education Classes *
A.TR.040 Conduct High-level Overview of *
B.BR.010 Prepare Mapping Environment *
B.BR.090 Confirm Integrated Business Solutions *
B.PM.010 Prepare Transition Strategy *
B.TR.020 Prepare Project Team Training *
Environment
C.CV.060 Design Manual Conversion Strategy *
Contingency Plan
E.PM.060 Implement Support Infrastructure *
E.PM.070 Verify Production Readiness *
E.TE.140 Support Acceptance Test *
E.TR.080 Prepare User Training Environment *
E.TR.090 Train Users *
Configuration Manager B.BR.020 Map Business Requirements 5


Scenarios
Database Administrator B.TA.060 Develop System Availability Strategy 10
C.TA.150 Design Physical Database Architecture 80
C.TA.160 Design Hardware and Network 10
Architecture
C.TA.170 Develop System Capacity Plan 20
Procedures
Environment
D.PT.130 Execute Performance Test 20
F.PM.100 Measure System Performance 40
Database Designer C.MD.050 Design Database Extensions 60
D.MD.100 Implement Database Extensions 20
Facilitator A.RD.020 Conduct Current Business Baseline 10
A.RD.030 Develop Future Process Model 10
Scenarios
IS Manager A.PT.010 Define Performance Testing Scope, *
A.PT.020 Prepare Performance Testing Strategy *
A.TA.010 Define Architecture Scope, Objectives, *
and Approach
A.TA.020 Prepare Architecture Strategy *
A.TA.030 Establish Architecture Requirements *
A.TA.040 Develop Conceptual Architecture *
A.TA.050 Conduct Technical Architecture *
Baseline
B.PT.030 Identify Performance Test Scenarios *
B.PT.040 Identify Performance Test Transaction *
Models
B.TA.060 Develop System Availability Strategy *

B.TA.070 Define Future Application Deployment *

B.TA.080 Develop Reporting Strategy *
B.TA.090 Revise Conceptual Architecture *
B.TA.100 Define Architecture Subsystems *
B.TA.110 Propose Architecture Subprojects *
C.PM.020 Design Production Support *
Infrastructure
Contingency Plan
C.TA.160 Design Hardware and Network *
Architecture
C.TA.170 Develop System Capacity Plan *
C.TA.180 Assess Performance Risks *
C.TA.190 Design System Management *
Procedures
D.PT.140 Create Performance Test Report *
F.PM.130 Decommission Former System *
F.PM.150 Propose Future Technical Direction *
IS Operations Staff A.CV.010 Define Conversion Scope, Objectives, *
and Approach
A.CV.020 Prepare Conversion Strategy *
A.TA.050 Conduct Technical Architecture *
Baseline
B.DO.040 Prepare Documentation Environment *
B.TA.060 Develop System Availability Strategy *
C.PM.020 Design Production Support *
Infrastructure
Contingency Plan
C.TA.150 Design Physical Database Architecture *
C.TA.160 Design Hardware and Network *
Architecture
C.TA.170 Develop System Capacity Plan *
C.TA.190 Design System Management *
Procedures
D.MD.090 Prepare Development Environment *
E.CV.130 Install Conversion Software *
E.CV.140 Convert and Verify Data *

E.PM.040 Prepare Production Environment *

F.PM.110 Maintain System *
F.PM.120 Refine Production System *
F.PM.130 Decommission Former System *
IS Support Staff A.TR.040 Conduct High-level Overview of *
B.TR.060 Train Project Team *
C.CV.050 Perform Conversion Data Mapping *
Contingency Plan
C.TR.070 Develop User Training Materials *
D.CV.090 Develop Conversion Programs *
D.DO.130 Complete System Management Guide *
D.TE.100 Prepare Key Users for Testing *
E.CV.130 Install Conversion Software *
E.TR.090 Train Users *
F.PM.110 Maintain System *
Lead Tester C.TE.010 Develop Test Strategy 100
Scripts
D.TE.100 Prepare Key Users for Testing 75
D.TE.110 Perform System Testing 10
D.TE.120 Perform Regression Testing 10
D.TE.130 Perform Systems Integration Testing 10
Module Designer B.MD.020 Define and Estimate Custom 70
Extensions
C.CV.070 Design Conversion Programs 90
C.DO.060 Produce Initial User Reference Manual 10
C.DO.080 Produce Initial Technical Reference 20
Manual
C.MD.050 Design Database Extensions 40
C.MD.060 Produce Module Functional Design 80
C.MD.070 Produce Module Technical Design 90


C.PT.060 Design Performance Test Transaction 60
Programs
C.TE.020 Develop Unit Test Scripts 20
C.TE.030 Develop Link Test Scripts 80
C.TE.040 Develop System Test Scripts 10
D.DO.100 Complete User Reference Manual 20
D.DO.120 Complete Technical Reference Manual 10
D.MD.110 Create Custom Modules 10
E.TE.140 Support Acceptance Test 25
Network Administrator A.PT.010 Define Performance Testing Scope, 5
B.TA.060 Develop System Availability Strategy 10
Architecture
Procedures
Environment
Production Database E.CV.140 Convert and Verify Data 20
Administrator
Programmer C.MD.070 Produce Module Technical Design 10
C.TE.020 Develop Unit Test Scripts 80
C.TE.030 Develop Link Test Scripts 20
D.CV.090 Develop Conversion Programs 100
D.CV.100 Perform Conversion Unit Test 100


D.DO.140 Provide Online Help Text 40
D.MD.110 Create Custom Modules 90
D.MD.120 Create Installation Routines 100
Programs
D.TE.070 Perform Unit Testing 50
D.TE.080 Perform Link Testing 20
D.TE.090 Perform Installation Test 20
Project Database Administrator A.PT.010 Define Performance Testing Scope, 5
B.BR.010 Prepare Mapping Environment 30
Environment
B.TR.060 Train Project Team 2
D.MD.100 Implement Database Extensions 80
D.PT.110 Construct Performance Test Database 25
E.TR.090 Train Users 2
Project Manager A.CV.010 Define Conversion Scope, Objectives, 10
and Approach
A.DO.020 Specify Documentation Requirements 5
A.PT.010 Define Performance Testing Scope, 30
A.PT.020 Prepare Performance Testing 15
A.TA.010 Define Architecture Scope, Objectives, 30
and Approach
A.TR.010 Prepare Training Strategy 60
B.PM.010 Prepare Transition Strategy 90
B.TA.110 Propose Architecture Subprojects 20

C.PM.030 Develop Detailed Transition and 75

Contingency Plan
E.CV.140 Convert and Verify Data 5
E.PM.070 Verify Production Readiness 20
F.PM.090 Audit Production System 50
Project Sponsor A.MD.010 Prepare Customization Strategy *
A.RD.040 Develop Future Business Function *
Model
B.MD.020 Define and Estimate Custom *
Extensions
C.TA.180 Assess Performance Risks *
D.PT.140 Create Performance Test Report *
Quality Auditor E.PM.070 Verify Production Readiness 45
System Administrator A.PT.010 Define Performance Testing Scope, 5
B.BR.010 Prepare Mapping Environment 40
B.DO.040 Prepare Documentation Environment 80
Environment
C.DO.090 Produce Initial System Management 20
Guide
Architecture
Procedures
D.DO.130 Complete System Management Guide 15
Environment


D.TE.090 Perform Installation Test 80
E.CV.130 Install Conversion Software 90
System Architect D.DO.130 Complete System Management Guide 15
Team Leader-Architecture A.TA.010 Define Architecture Scope, Objectives, 50
and Approach
B.TA.110 Propose Architecture Subprojects 80
Team Leader-Business B.RD.070 Create Business Requirements 5
Requirements Scenarios
Team Leader-Conversion A.CV.010 Define Conversion Scope, Objectives, *
and Approach
A.CV.020 Prepare Conversion Strategy 20
C.CV.050 Perform Conversion Data Mapping 10
C.CV.060 Design Manual Conversion Strategy 10
C.CV.070 Design Conversion Programs 10
C.CV.080 Prepare Conversion Test Plans 10
Contingency Plan
D.CV.110 Perform Conversion Business Object 10
Test
E.CV.130 Install Conversion Software 10
Team Leader-Customization A.MD.010 Prepare Customization Strategy 25
C.MD.030 Define Design Standards 10

C.MD.040 Define Build Standards 10

Team Leader-Documentation A.DO.020 Specify Documentation Requirements 10
A.DO.030 Determine Documentation Standards 30
and Procedures
D.DO.110 Complete User Guide 40
Team Leader-Mapping B.BR.010 Prepare Mapping Environment 10
B.BR.040 Conduct Integration Fit Analysis 5
B.BR.050 Develop Information Flow Model 5
C.BR.100 Create Process Narratives 5
Team Leader-Performance A.PT.010 Define Performance Testing Scope, 55
Testing Objectives, and Approach
A.PT.020 Prepare Performance Testing Strategy 70
B.PT.030 Identify Performance Test Scenarios 65
Models
Programs
Programs
Environment
Team Leader-Testing D.TE.100 Prepare Key Users for Testing 25


Team Leader-Training A.TR.010 Prepare Training Strategy 30
A.TR.030 Conduct General Education Classes 5
A.TR.040 Conduct High-level Overview of 5
Environment
Contingency Plan
Technical Analyst A.CV.010 Define Conversion Scope, Objectives, 90
and Approach
A.CV.020 Prepare Conversion Strategy 80
A.PT.020 Prepare Performance Testing Strategy 15
B.BR.040 Conduct Integration Fit Analysis 95
B.BR.050 Develop Information Flow Model 95
B.BR.060 Develop Information Access Model 25
B.CV.030 Prepare Conversion Standards 100
Models
B.RD.090 Identify Business Availability 5
Requirements
C.CV.050 Perform Conversion Data Mapping 90
C.CV.060 Design Manual Conversion Strategy 90
C.CV.080 Prepare Conversion Test Plans 90
Programs


Architecture
Environment
F.PM.140 Propose Future Business Direction 25
F.PM.150 Propose Future Technical Direction 50
Technical Architect A.TA.010 Define Architecture Scope, Objectives, 10
and Approach
A.TA.050 Conduct Technical Architecture 80
Baseline
B.PM.010 Prepare Transition Strategy 10
C.TA.150 Design Physical Database Architecture 20
Architecture
Procedures
F.PM.150 Propose Future Technical Direction 50
Technical Expert A.MD.010 Prepare Customization Strategy 75
B.MD.020 Define and Estimate Custom 20
Extensions

C.PM.020 Design Production Support 100

Infrastructure
Technical Expert-Build C.MD.040 Define Build Standards 90
C.MD.030 Define Design Standards 90
Technical Expert-Existing A.DO.010 Prepare Glossary 5
Systems
Technical Writer A.DO.030 Determine Documentation Standards 70
and Procedures
B.DO.050 Produce Documentation Prototypes 100
and Templates
C.DO.060 Produce Initial User Reference Manual 90
C.DO.080 Produce Initial Technical Reference 80
Manual
C.DO.090 Produce Initial System Management 80
Guide
D.DO.100 Complete User Reference Manual 80
D.DO.110 Complete User Guide 60
D.DO.130 Complete System Management Guide 70
D.DO.140 Provide Online Help Text 60
Tester C.TE.040 Develop System Test Scripts 30
Scripts
D.CV.110 Perform Conversion Business Object 90
Test
D.TE.070 Perform Unit Testing 50
D.TE.080 Perform Link Testing 80
Trainer A.TR.010 Prepare Training Strategy 10
A.TR.020 Prepare Project Training Environment 10
A.TR.030 Conduct General Education Classes 95
A.TR.040 Conduct High-level Overview of 95

A.TR.050 Prepare Project Team Training 25

User A.CV.010 Define Conversion Scope, Objectives, *
and Approach
A.CV.020 Prepare Conversion Strategy *
A.DO.010 Prepare Glossary *
A.RD.040 Develop Future Business Function *
Model
A.RD.060 Gather Business Volumes *
B.BR.040 Conduct Integration Fit Analysis *
B.BR.050 Develop Information Flow Model *
B.BR.060 Develop Information Access Model *
B.BR.070 Conduct Reporting Fit Analysis *
B.DO.050 Produce Documentation Prototypes *
and Templates
B.PT.030 Identify Performance Test Scenarios *
B.RD.070 Create Business Requirements *
Scenarios
B.RD.080 Determine Audit and Control *
Requirements
B.RD.090 Identify Business Availability *
Requirements
B.RD.100 Develop Reporting Requirements *
C.MD.060 Produce Module Functional Design *
C.MD.080 Review Detailed Designs *
C.PT.050 Create Performance Test Scripts *
D.PT.130 Execute Performance Test *
D.TE.080 Perform Link Testing *
E.PM.050 Setup Applications *
E.PM.080 Commence Production *

APPENDIX
D AIM 2 Data Model
T his appendix provides a general description of the AIM 2 Data

Model.
Oracle Method AIM 2.0 Data Model D - 1

Purpose and Objective of the Data Model
A sound method should be based on well-defined, related building
blocks that can be used to develop and execute a project plan by
utilizing resources, producing deliverables, and meeting business
objectives. The AIM Data Model represents these building blocks and
their relationships as Data Objects and Relationships.
The purpose of the Data Model is to help ensure quality, promote ease
of use, and facilitate integration within Oracle methods like CDM or
PJM. It provides a framework that ensures consistency among the
various AIM elements by:
• defining standard names for the building blocks

• communicating relationships among the various building blocks
For example, a project can have multiple deployments. This is depicted

by the line connecting project and deployment.
D - 2 AIM 2.0 Data Model AIM Method Handbook

Program
Organizer
of
Governed
by AIM 2.0
Data Model
Project
Initiator of
Controled
by
Deployment Revision 4 May 18, 1997
Compose
d of
Parent Within
of
Activated
Business Unit during At Site
Child of Activation Go live during
Affect
Require Conversion
Performed during Execution
Facilitated delivered
by by
Class Class Session
Created to An Execution of
support instance
of Attended
by
Activation
of Trained
Sub-
during
function of
Subject
of
Person
Function
Decomposed
Event Triggerd During High-level Business into Perform
Domain of Function Assgned
to
Trigger for
Performed by Role
Elementary Business Performer of
Function
Supported
by Application
Capable of supporting
Executed by
Source of
User Composed of
of
Accessed
by Executed during
Business Object Migrated via Conversion

Migration method for
Decompose
d into Source of Composed of
Instance of Within
Response to
Described by Application
Process Step
Process Function
Detail of
Sub-
process Executed during
of Associated Associated
Performed by
with with
following
Source of
Requirement
Associated
with
Executed A uniqe Source of
via response the
result of
path for
Gap
Requirements
Scenario Catalyst
for Closure
of Performed using
Supported Instructions for

by Impemented with Carried
An alternate
Solution Procedure out with Procedure Step
approach to
New steps to Details
support of
Mapping Scenario
Implemented
with Policy
required
to enable
Part of
Implemented
with Customization Composed of Module
created to Part of
provide
Figure D-1 AIM Data Model Diagram

AIM Data Object Definitions
These descriptions correspond to the labeled boxes in Figure D-1 —
AIM Data Model Diagram. Each description defines the data object and
its relationships with other objects.
Relationship to AIM Processes, Tasks, and Deliverables
The data objects in the Data Model represent the information that is
analyzed, documented or is the subject of work on an AIM project.
Processes and tasks operate on data objects that are then included in
deliverables. In some cases there is no deliverable for a data object. In
other cases a data object may correspond to a section in an AIM
deliverable.
Relationship to the AIM Glossary
Definitions for all data objects are included in the AIM Glossary.
Data Object Definitions
Activation
Definition
A logical event corresponding to the enabling of one High-level business
function at one site for one business unit. For example, a single
deployment will have many Activations in the process of going live,
with multiple Business Units using multiple High-level Business
Functions at one or more sites. Each Activation represents a discrete
unit of work that can be predicted and measured.
Relationships
There can be one or more Activation for a Deployment. One or more
Business Units may be associated with an Activation. You may go live
with Accounts Payable and Purchasing at a single site at the same time;
however, an Activation is only associated with one Site.

A site can be associated with one or more Activation. For example,
Order Entry and Inventory might go live at a specific site on one date;
later Accounts Payable and Purchasing might go live at the same site.
One or more Classes may be held for an Activation. If Purchasing and

Accounts Payable are going live at a specific site at the same time you
may want to conduct training classes for the users. An Activation may
have Classes; you may decide to train users from Site A at Site B, or
you may choose not to train users at specific sites.
Application
Definition
An Application is a collection of program modules that work together
to support a set of related business functions. Order Entry, Inventory,
Projects, Work In Process, General Ledger, and so on are Oracle
Applications.
Relationships
An Application may support one or more Business Functions. For
example, General Ledger supports all of the Business Functions that
provide journal entries. The Purchasing System may support the
Project Accounting Business Function as well as the Purchasing and
Inventory Business Functions.
Application Function
Definition
An Application function is a portion of an Application that supports a
subset of the Business Functions supported by the overall Application.
The Journal Entry Function of the General Ledger System is an example.
Relationships
An Application Function must relate to only one Application and an
Application must have one or more Application Functions.

Business Function
Definition
A Business Function is what an enterprise does, or needs to do, to
achieve its objectives. Manufacturing, purchasing, accounting,
engineering, and sales are Functions.
There are two special kinds of Functions in AIM: High-level and

Elementary Business Functions. They are represented in the diagram as
boxes inside of the box labeled Business Function.
A High-level Business Function is a Business Function that is at the top

of the Business Hierarchy Diagram (an AIM deliverable). An
Elementary Business Function is the lowest level in this diagram.
If Purchasing is a High-level Business Function, an Elementary Business

Function within Purchasing might be Approving Contracts. A typical
part of a Business Function hierarchy would be Approving Contracts
rolling up to a mid-level Business Functions Contract Management that in
turn rolls up to Purchasing, the High-level Business Function.
Relationships
The dotted circle on the upper right hand corner of the Business
Function box indicates that one Business Function may relate to another
in the hierarchical fashion described above.
At least one Event must relate to a High-level Business Function. For

example, receiving an invoice is an Event that may be associated with
the High-level Business Function Accounts Payable.
A High-level Business Function may be related to one or more Events.

It is possible that because the scope of an implementation project, the
team will not be analyzing Events associated with some High- Level
Business Functions. However, to understand the organizational
context, such a High-level Business Function might still be included in
the Business Function Hierarchy diagram.
An Event may be related to only one High-level Business Function. It is

possible to design a Business Function Hierarchy poorly so that an
Event appears to be related to more than one High-level Business
Functions, however, this is a sign that the function hierarchy is
ambiguous and should be revised. Sales order might be related to the
Order Entry High-level Business Function.

A Business Function may relate or one or more Requirements. There
are generally many Requirements for a Business Function. Examples of
Requirements associated with the Buyer Business Function are:
• ability to group like requisitions

• ability to automatically route requisitions to buyers by vendor or
item category
An Elementary Business Function may relate to one or more Process

Steps but a Process Step must relate to at least one Elementary Business
Function.
Business Object
Definition
A Business Object is a physical or logical object of significance to a
business (for example, a sales order, department, assembly, item,
balance, or invoice). A Business Object is analogous to a class in object
oriented terminology.
Relationships
A Business Object may be related to one or more Conversions. Fixed
Assets are Business Objects that may need to be converted from a legacy
system to Oracle’s Fixed Asset System.
Business Objects must relate to at least one Business Function. If a

Business Function for a Business Object to be converted does not appear
to be identified there is a deficiency in your Business Function
Hierarchy diagram.
Business Unit
Definition
A business unit is part of an organization treated as a separate entity
within the parent organization. Examples include a department or
distribution center.
Relationships
A Business Unit may be related to itself since there may be a hierarchy
of Business Units. For example, A Procurement Department may be
comprised of Purchasing, Inventory, and Contracts departments.

A Business Unit may also be associated with one or more Activations.
Certain applications may go live at different times for a Business Unit.
One Activation might affect one or more Business Units. Purchasing

and Accounts Payable may go live in several Business Units at the same
time. For example, a company may have regions with central
Purchasing and Accounts Payable Business Units in each region.
Class
Definition
A Class refers to the training of students on specific topics. Usually
training is provided for Oracle Applications such as Bill of Materials,
Work In Process, and so on. Training may also be provided for job
policy and procedures, Help Desk operations, and so on.
Relationships
One or more Classes may be held for each Activation. If Accounts
Payable is going live at a specific site on a specific date you may want to
hold a class for that Activation. Depending on the number of students,
you may need to have multiple classes. However, students from a
particular site may be trained elsewhere, therefore, you would not
necessarily have a Class for every Activation.
A Class must have at least one Class Session. If there are more students
than can be accommodated in one class you may need multiple Class
Sessions.
Class Session
Definition
A Class Session consists of delivering a Class to a specific set of students
at a particular place and time.
Relationships
There may be one or more Class Sessions for a Class. One or more
people may attend a Class Session.

Conversion
Definition
Conversion includes the total set of activities converting Business
Objects from legacy systems to the newly installed Oracle applications.
For example, the Fixed Assets Conversion would refer to all processes,
tasks, and deliverables associated with converting Fixed Assets data
from the old system to the Oracle Fixed Assets system.
Relationships
A Conversion may be associated with one or more Conversion
Executions. For example, a project that has multiple deployments by
region may require a separate Fixed Assets data conversion for each
region.
A Conversion must be associated with at least one Business Object. For

example, an Inventory Conversion might at least migrate Inventory
Items from the old system to new systems.
A Business Object may be associated with one or more Conversions.

For example, you may want to convert open Projects for Oracle Projects.
Open Projects may be related to open Purchase Orders in Oracle’s
Purchasing System that is how Commitments are shown in Oracle
Projects. In this case you would also be converting Open Purchase
Orders to get them into Oracle Purchasing; therefore, the Business
Object Open Purchase Orders is actually part of both the Oracle Projects
and Purchasing Conversions.
Conversion Execution
Definition
An example of a Conversion Execution would be the conversion of open
orders from a legacy system to Oracle Order Entry in one region on a
given date. Other regions may go live with Order Entry on a different
date requiring other order entry Conversion Executions.
Relationships
There must be at least one Conversion Execution associated with a
Conversion. A Conversion Execution must always be associated with
only one Conversion.

In a project with a phased deployment by region, the Accounts Payable
Conversion of open invoices may need to occur once for each region.
Customization
Definition
A customization is a change made to the standard Oracle software that
implements a Solution to a Gap.
Relationships
A Customization must be related to only one Solution. A Solution may
relate to one or more Customizations.
Deployment
Definition
A deployment is the total set of activities associated with the production
implementation of a set of applications in specific location(s) at a
specific time.
For example, going live with Oracle’s General Ledger, Purchasing, and
Accounts Payable systems in Region 1 on 1-MAY-98 is a deployment;
going live in Region 2-OCT-98 would be another Deployment.
Relationships
A Deployment is always associated with one Project. A Deployment
may contain one or more Activations.
Gap
Definition
A Gap is a relationship between a Requirement and an Application
Function where the standard Application Function will not meet the
Requirement.
Relationships
A Gap must be related to one or more Requirements and one or more
Application Functions; it may relate to only one Solution. A Solution
must relate to one or more Gaps, therefore, the inability to drill down
from General Ledger to Accounts Receivable may have been identified
as a Gap for that a Solution was developed.

Mapping Scenario
Definition
A Mapping Scenario is a detailed step by step description of how you
want team members to test the standard Oracle software to see if it will
meet the needs of a Business Requirements Scenario.
Relationships
A Mapping Scenario must be related to only one Business Requirements
Scenario. A Business Requirements Scenario may be related to one or
more Mapping Scenarios.
Module
Definition
A module is a logical program unit. Examples include forms, reports,
user exits, C programs, PL/SQL procedures, and database triggers.
Relationships
A Module must either relate to a Customization or a Conversion.
One or more Modules may be required to implement a Customization.

One or more modules may also be required to provide the custom
software to convert Business Objects from legacy systems to the new
Oracle systems.
Policy
Definition
A policy is a documented directive from enterprise management that
specifies how some aspect of the business is to be conducted.
For example, a policy might be that any expenditure over fifty dollars
must be transacted using a Purchase Requisition instead of petty cash.
Relationships
A Policy may be related to only one Solution. One or more Policies
could be related to a Solution.

A solution to a Gap may be to disallow separate costs for the same item
in different warehouses. This would be documented in a policy
requiring that all items have the same cost across all warehouses.
Procedure
Definition
A Procedure is a written set of steps that specifies how to carry out a
business function.
An example would be a Procedure for uploading journal entry data in

spreadsheet form to Oracle General Ledger.
Relationships
A Procedure may relate to only one Solution. It must relate to at least
one Procedure Step.
Process
Definition
A Process is a grouping of tasks based on common functions or
disciplines that lead to one or more key deliverables. Examples of
Processes in an enterprise include: Invoice Entry, Requisitioning,
Creating Purchase Orders, Running Material Requirements Planning,
and so on.
Relationships
A Process may relate to another Process. There may be a hierarchy of
processes in an enterprise. For example, you might define a process
called Replenish Inventory. This could be comprised of lower level
processes such as Analyze Stock Shortages, Create Requisitions, and so on.
Processes must be related to at least one Event. Several Events could be

related to one Process. The Invoice Entry Process is related to the Receipt
of an Invoice Event.
A process must have at least one Process Step. The Invoice Processing
Process might include steps such as:
• date and time stamp invoice

• sort invoices by type

• distribute invoices to Invoice Entry Clerks
• form invoice batches
• enter invoices
• check batch totals
A Process may have one or more Business Requirements Scenarios.

Business Requirements Scenarios are different paths through the
process that you want to ensure the application can handle. For invoice
processing you may have the following Business Requirements
Scenarios:
• standard invoice with existing vendor and no sales tax proration

• invoice with no existing vendor master record
• invoice requiring sales tax proration
There may be one or more Process Steps for a Process.
Process Step
Definition
Processes are comprised of individual Process Steps that represent
actions required to complete a Process.
Relationships
A Process Step must be associated with only one Process. A Process
Step must also be associated with an Elementary Business Function. A
Process Step must be associated with only one Procedure.
The Enter Invoice Process Step may be part of the Invoice Processing
Process. It must relate to an Elementary Business Function (that might
be Process Invoices). There may be a user Procedure describing how to
enter an invoice.
Program
Definition
A Program is an interrelated group of projects either run concurrently
or sequentially, that share a system goal. Individual projects may have
different goals; however, the combined set of projects will have a
program goal.

Relationships
Each program must have two or more projects.
Project
Definition
A project is a set of work processes, tasks with associated deliverables,
and resources executed over a specific period of time with
predetermined budget and business objectives.
Relationships
A project may be part of a Program that always has at least two
projects. A project will always have at least one Deployment.
Requirement
Definition
A Requirement is a specific, detailed business need compared with
Application functionality to determine if the need can be met with
standard Oracle software.
Relationships
A Requirement must be associated with a Business Function, a Process,
or a Conversion. Examples of Requirements include:
• ability to handle different item costs for the same item in different
warehouses
• ability to drill down from General Ledger account balances to
subledger detail (such as Accounts Payable, Accounts Receivable,
or Fixed Assets)
• ability to automatically track Engineering Change Orders
• ability to automatically assign new Asset categories and
associated account codes to fixed asset records being converted
from legacy systems
A Requirement must only be associated with one of the three objects

mentioned above. This AIM requirement facilitates cross referencing
and maintaining an audit trail.

A Requirement may be associated with only one Gap; however, a Gap
may be associated with one or more Requirements. For example, the
vanilla software may meet the drill down requirement from the General
Ledger to detailed Account Payable records, but it does not address all
the needs for drill down to Accounts Receivable detail. This would be
documented in AIM as a Gap related to this requirement.
Business Requirements Scenario

Definition
A Business Requirements Scenario is a formal statement of detailed
business requirements for a Process, the source of the Requirements,
how these requirements will be satisfied (either the application, manual
Procedure, Workarounds, or other application solutions), and what
prototyping steps must be taken to prove the design.
Relationships
A Business Requirements Scenario must be associated with a Process.
A Process may be associated with one or more Business Requirements
Scenarios.
A Business Requirements Scenario must be associated with one or more

Mapping Scenarios.
For example, Invoice Processing is an Accounts Payable Process. A

related Business Requirements Scenario would describe in narrative
form how the enterprise wishes to process invoices.
If the invoice processing Process has different possible paths because of

decision points, there may be multiple Business Requirements
Scenarios. One Business Requirements Scenario might deal with one
line invoices where there is no need to prorate tax lines to other invoice
lines. Another scenario would address the more complex case.
When you want to test the application to see if the standard software
will handle a given Business Requirements Scenario, you will develop
one or more Business Mapping Scenarios.
Why might you have more than one Business Mapping Scenario? There
might be different ways to use an Oracle Application to meet a given
Business Requirements Scenario. For example, assume that you can set
up Oracle Accounts Payable to handle automatic proration of tax lines
to other invoice lines in different ways; in this case you might want to
try it for each different setup option. You would create Business

Mapping Scenarios to document how team members should test the
system.
Role
Definition
A role is a generic set of activities that may be assigned to people (for
example, Buyer, Requisitioner, Fixed Asset Accountant, Planner,
Invoice Entry Clerk, and so on).
Relationships
A Role may be assigned to one or more people and a person may be
assigned a role.
Site
Definition
A site is a uniquely identifiable geographic location or place from that
one or more business organizations may be wholly or partly operating.
Relationships
A Site may be associated with one or more Activations. Some
applications may go live in a Site on one date, and other applications
may go live later at the same Site. An Activation is associated with only
one Site.
Solution
Definition
A Solution is the resolution of the discrepancy between one or more
Gaps and one or more standard Application Functions.
A Solution may take the form of a Procedure, Policy, or Customization.
An example would be the decision to build a Customization that

enhances the standard Application Function by changing or adding
software to the base Oracle Application. With the example of
insufficient drill down capability from the General Ledger to detailed
Accounts Receivable records, fields that resolve the Gap could be added
to a General Ledger form.

Relationships
A Solution must be related to one or more Gaps. It may relate to one or
more Procedures, Policies, or Customizations.
For example, assume that a Gap is an automated tax proration feature in

Oracle Accounts Payable that does not work exactly the way an
enterprise wants. One Solution might be to establish a policy that tax
proration will be done manually. An associated Procedure might be
developed indicating how to do the manual proration. A different
Solution would be to customize the Accounts Payable System by
altering the way it handles tax proration.

Glossary
24x7 A period or window of service Activation A logical event corresponding

availability that covers 24 hours day, to the enabling of one high level
seven days a week. business function at one site for one
business unit. Each activation
3GL see THIRD-GENERATION PROGRAMMING represents a discrete unit of work that
LANGUAGE we can predict and measure.
4GL see FOURTH-GENERATION Actuals Information gathered during a

PROGRAMMING LANGUAGE project concerning the actual amount of
time, finances or resources expended
A on a task.
ABT see APPLIED BUSINESS TECHNOLOGY. Advocate An individual who supports the
project within the client environment,
Acceptance The approval, typically by a without being involved in the project’s
client or user, of a project deliverable. implementation. An advocate may be a
formal or informal leader within the
Access Control The ability to manage organization.
which users or groups of users may
have the privilege to retrieve, create,
update, or delete data held in a
repository, such as a relational
database.
Oracle Method Glossary G - 1

Agent A generic term for a party which is (Oracle) Application Functional
responsible for the execution and Configuration The definition of key
completion of a process step. An agent architectural setup parameters in an
may be an organizational unit, a application instance or product group
functional unit, a business system, an to reflect the financial and operating
employee role, an external system, or environment of the business
an external party such as a customer or organizations that transact within that
supplier. application instance or product group.
Agent Channel A horizontal division on a Application Gap A recorded variance

process flow diagram that indicates between some aspect of a business
which agent performs which particular requirement and the capability or
functions within the process being features of the application system that
modeled. are necessary to satisfy the
requirement.
AIM see APPLICATION IMPLEMENTATION
METHOD. Application Implementation Method
(AIM) A method that comprises a
Application A collection of program flexible approach for implementing
modules that work together to support Oracle Applications.
a set of related business functions; see
also MODULE. Application Instance A unique set of
application tables and processes. Note
(Oracle) Application Environment A that two instances of the same version
complete application installation along of an application may share one set of
with other utilities used for business program modules but they may not
mapping, design, build, testing, or share the same set of application tables.
training. Usually, an application
environment includes setups and test Application Interface A mechanism used
data to support business modeling, and to transfer data between applications.
procedures exist to recover to A data flow between applications is
controlled starting points after sessions always implemented as a set of one or
are complete. more application interfaces; see also
NEAR REAL-TIME INTERFACE and REAL-
Application Fit A recorded match TIME INTERFACE.
between some aspect of a business
requirement and the capability or Application Process An indication of the
features of the application system that sequential execution of a series of
satisfies the requirement. system functions, possibly including
manual functions as well; see also
Application Function A portion of an MANUAL FUNCTION, SYSTEM FUNCTION,
Application which supports a subset of and SYSTEM PROCESS.
the business functions supported by the
overall Application.
G - 2 Glossary AIM Method Handbook

Application System An automated Arm’s Length Transaction An inter-
collection of business functions, company transaction that is treated as a
entities, modules, technology third party transaction.
platforms, and documentation that
performs a specified set of business Attribute Any detail that serves to
functions; see also BUSINESS SYSTEM, qualify, identify, classify, quantify, or
MODULE, PLANNED RESPONSE SYSTEM, express the state of an entity; any
and SYSTEM FUNCTION. description of a thing of significance.
(Oracle) Applications Distributed AutoText Entry Microsoft Word allows

Interface An interface between similar you to store frequently used text,
or dissimilar Oracle Applications graphics, and other items and quickly
products that have data stored in insert them into documents. These
multiple separate databases. The stored items are referred to as
databases may or may not be resident AutoText entries. If you store text and
at multiple sites (data centers). The graphics as AutoText entries, you can
corollary of this is that Applications retrieve them by clicking a button,
distributed interfaces may exist at a typing a few keystrokes, or choosing a
single site. command. Components of the
Deliverable Templates are stored as
(Oracle) Applications Interface An AutoText entries in global templates
interface between similar or dissimilar used to store boilerplate text; see also
Oracle Applications products that have BOILERPLATE TEXT.
data stored in the same database. The
interface may or may not be supported B
within the standard package products.
Backup and Recovery Strategy A storage
Applied Business Technology (ABT) A
and recovery strategy that protects
company that manufactures tools to
against business information loss
profile, estimate, and plan projects.
resulting from hardware, software, or
Oracle Services has a global licensing
network faults.
agreement with ABT. Oracle Method
makes use of Project Workbench, Baseline 1. A starting point or condition
Methods Architect, and Project Bridge against which future changes are
Modeler as its worldwide methods and measured. 2. A named set of object
project management software standard; versions which fixes a configuration at
see also PROJECT BRIDGE MODELER and a particular point in time. A baseline
PROJECT WORKBENCH. normally represents a milestone or key
deliverable of a project; see also
Approach A particular way of putting a
CURRENT BUSINESS BASELINE.
method or task to use, including risk
factors, tips from experience,
recommendations, and additional
advice; see also TECHNIQUE.

Bid and Proposal Management (BPM) Business An enterprise, commercial
Specifies the process, tasks, entity, or firm in either the private or
responsibilities, and deliverables public sector, concerned with
regarding how business opportunities providing products or services to
are qualified and responded to, satisfy customer requirements.
eventually leading to the issue of an
authorized bid to a client. Business Aim A statement of business
intent measured subjectively; for
Billable Project Expenses The project example, to move up market, or to
expenses that are billable to a client; see develop a sustainable level of growth;
also PROJECT EXPENSES. usually strategic or tactical with a 3-5
year horizon.
Billable Utilization The utilization that is
billable to a client; see also UTILIZATION. Business Area The set of business
processes within the scope of a project.
Black Box Test A test of all or part of an
application system based upon Business Constraint Any external,
fulfilling business requirements or management, or other factor that
meeting functional specifications. A restricts a business or system
black box test does not require an development in terms of resource
understanding of the actual code under availability, dependencies, timescales,
test. A system test is usually a black or some other factor.
box test.
Business Data Mapping Verification that
Boilerplate Text Pre-written collection of the underlying table structures and
words, sentences, headings, and attributes will support business
formatting in a template that you can processes.
modify to suit a specific need; see also
AUTOTEXT ENTRY. Business Function Something an
enterprise does, or needs to do, in
Bottom-up Estimate A task-level estimate order to achieve its objectives; see also
derived by calculating the estimating APPLICATION SYSTEM, BUSINESS PROCESS,
factors critical to completion of each MANUAL FUNCTION, and SYSTEM
task; see also ESTIMATING FACTOR. FUNCTION.
BPM see BID AND PROPOSAL Business Function Model A

MANAGEMENT. representation of all the business
functions within a defined scope. A
BPR see BUSINESS PROCESS REENGINEERING. wide range of techniques is available
for modeling business functions.; see
Budget A plan for determining, in also FUNCTION DECOMPOSITION and
advance, the expenditure of time, FUNCTION HIERARCHY.
money, etc.
Business Goal A statement of business
intent.

Business Location A uniquely identifiable Business Organization Type A
geographic location, site, or place from classification of a business organization
which one or more business units may into one of several functional
wholly or partly operate. categories. Each business organization
type has a distinct set of business
Business Model A model or collection of requirements. All the business
models representing the definition of organizations of a certain type will
key components of a business. typically require similar applications
Components may include models of and system capabilities. A given site
processes, objectives, functions, and may house one or more business
information; see also BUSINESS PROCESS organization types. Since business
MODEL, ENTITY RELATIONSHIP DIAGRAM, organizations may be related in a
and FUNCTION HIERARCHY. hierarchy, a high level business
organization may be composed of
Business Object A physical or logical several business organizations of
object of significance to a business; for different types. For the purposes of
example, a sales order, department, application architecture analysis and
assembly, item, balance, or invoice. A design, it is generally useful to
business object is analogous to a class decompose the hierarchy of business
in object-oriented terminology. organizations until it is composed of
atomic organization types; see also
Business Objective Business conditions CUSTOMER SERVICE, DISTRIBUTION,
which, if met, will solve the business FINANCE, HUMAN RESOURCES,
problem statement. Well-defined INFORMATION SYSTEMS,
objectives are measurable and often MANUFACTURING, MARKETING,
relate directly to business processes PLANNING, RESEARCH AND
and deliverables; see PROBLEM DEVELOPMENT, and SALES.
STATEMENT.
Business Priority A statement of the level
Business Organization Any part of a or urgency of important business
business treated for any purpose as a needs.
separate unit within the parent
business organization; for example, a
department, division, or subsidiary; see
also BUSINESS UNIT.

Business Process The complete response Business Requirements Mapping An
that a business makes to an event. A activity that describes the business
business process entails the execution requirements for a business process in
of a sequence of one or more process business language, optionally compares
steps. It has a clearly defined the current solution for a business
deliverable or outcome. A Business requirement to a proposed solution and
Process is defined by the business event specifies details for the type and nature
that triggers the process, the inputs and of the solution in a descriptive format.
outputs, all the operational steps The deliverable can also be used as a
required to produce the output, the record of key decisions, or as a
sequential relationship between the placeholder in anticipation of
process steps, the business decisions additional detailed design
that are part of the event response, and documentation.
the flow of material and/or
information between process steps; see Business Requirements Scenario A
also BUSINESS FUNCTION, BUSINESS formal statement of the detailed
PROCESS MODEL, and EVENT RESPONSE. business requirements for a business
process, the source of these
Business Process Model The collection of requirements, how these requirements
process flow diagrams that comprise will be satisfied (either by the
the complete set of business processes application, manual process steps,
within the application scope; see also workarounds or other application
PROCESS FLOW DIAGRAM. solutions), and what prototyping steps
must be taken to prove the designs.
Business Process Reengineering (BPR) Known as a BRS.
The activity by which an enterprise
reexamines its goals and how it Business Rule A rule under which an
achieves them, followed by a organization operates. A policy or
disciplined approach of business decision that influences the process
process redesign. A method that step
supports this activity.
Business Solution Testing A technique
Business Requirement A formal by which management agrees that
statement that describes application business requirements will be satisfied
features necessary to support a if the application and other tools
business process step. perform as specified by process
designs.
Business System A combination of

people and automated applications
organized to meet a particular set of
business objectives; see also
APPLICATION SYSTEM and PLANNED
RESPONSE SYSTEM.

Business Unit Part of an organization Change Effort Any activity consciously
treated for any purpose as a separate undertaken by an enterprise, business
entity within the parent organization. unit, or individual, that will result in
Examples include a department or critical change in one or more areas of
distribution center; see also BUSINESS the organization, e.g. new technology
ORGANIZATION. implementation; see also
ORGANIZATIONAL EFFORT.
Business View A frequently used subset
of information, readily intelligible to Change Management 1. The complete set
users and defined in business terms, of processes employed on a project to
derived from definitions held in an ensure that changes are implemented in
entity model. It is based on one entity a visible, controlled and orderly
and can encompass renamed attributes fashion. 2. The activity, or set of
from the base entity or any other entity. activities, undertaken to govern
systematically the effects of
C organizational change.
Change Management Repository A

CASE see COMPUTER-AIDED SYSTEMS
system for maintaining configuration
ENGINEERING.
items. It provides other services such
CASE Tools A set of integrated as version control, access control and
Computer-Aided Systems Engineering information storage and retrieval which
(CASE) and application development support the configuration management
tools that assist in software process.
development, for example, analyzing
Change Readiness A measure of an
business requirements, designing
organization’s state of readiness to
applications, generating application
realize change successfully; involves a
code, etc.
consideration of an organization’s high-
CDM see CUSTOM DEVELOPMENT METHOD. impact leverage points for change, as
well as any change impediments.
Corporate Repository Location of a
collection of documentation, Change Request 1. A request for a change
customizations, modifications, or to the required behavior of a system,
enhancements designed to alleviate the usually from a user as a result of
recreation of successfully completed reviewing current behavior. 2. The
work. mechanism by which a change is
requested, investigated, resolved and
Change A deviation from a currently approved; see also IMPACT ANALYSIS.
established baseline.

Class..A class refers to the delivery Company Baseline The Company
training to students on a certain Baseline is the supported configuration
topic(s). Usually, training is provided of hardware, software, bug patches,
regarding Oracle applicaitons such as modifications, operating systems, etc.
Bill of Materials, Work in Process, etc. that is part of a common set of business
Training may ablso be provided systems for the entire enterprise. There
regarding job policy and procedures, may be lower level of Company
Help Desk operations, etc. Baselines such as a Latin America
Baseline that is a subset of the
Client/Server A type of technical Company Baseline.
architecture that links many personal
computers or workstations (clients) to Completion Criteria Standards or rules
one or more large processors (servers). which determine completion of a task
Clients generally manage the user to an acceptable level of quality.
interface, possibly with some local
data. Servers usually manage multiple- Computer-Aided Systems Engineering
access databases, including ensuring (CASE) The combination of graphical,
data integrity and other invariants; see dictionary, generator, project
also INVARIANT. management, and other software tools
to assist computer development staff
Class Session..A class session consists of engineer and maintain high-quality
delivering a class to a specific set of systems, within the framework of a
students at a particular place and time. structured method.
Column A means of implementing an Computer Network An interconnected

item of data within a table. It can be in group of computers.
character, date, or number format, and
be optional or mandatory. Conceptual Architecture A high level
model of an enterprise’s business
Common Business Function A business application that identifies the
function that appears in more than one organizational and geographical
place in a hierarchy. deployment of the most critical
application systems and the technology
Company A commercial business; see also components required to support them..
BUSINESS. This model provides the direction for
the detailed enterprise technical
Company Base Hardware Configuration architecture analysis. It should reflect
The actual hardware configuration that the vision of the client senior executive
supports the company base management for the future direction of
configuration; see also COMPANY the information systems in the
BASELINE. enterprise.
Conference Room Pilot A system test in

an environment set up to simulate the
future production environment.

Configuration A named set of Controlled Document A document which
configuration items. Configurations constitutes or represents a project
are used to hierarchically organize deliverable for approval internally or
configuration items in order to facilitate by the client, and is subject to change
their management; see also control.
CONFIGURATION ITEM.
Controls Environmental information that
Configuration Change The affects what is possible; constraints or
implementation of one or more change limits.
requests which leaves the configuration
in an internally consistent state; see also Conversion The total set of activities
IMPACT ANALYSIS. associated with bringing Business
Objects forward from legacy systems to
Configuration Item A deliverable or the newly installed Oracle applications.
deliverable component which is placed
under configuration management. Conversion Execution An example of a
Conversion Execution would be where
Configuration Management The process open orders are converted from a
of managing hardware, software, data, legacy system to Oracle Order Entry in
and any other documentation needed one region on a given date. Other
during the development, testing, and regions may go live with Order Entry
implementation of information on a different date requiring other
systems. order entry Conversion Executions..
Constraint see BUSINESS CONSTRAINT and Conversion Fit Analysis A formal

BUSINESS RULE. statement of subsystems and entities
converted into the new applications
Consulting Grade Level A grade level database.
assigned to Oracle Services consulting
resources used to calculate the cost of a Core Business Process A major, driver
resource’s labor; 1-Administrative process that affects or influences
Assistant to 10-Regional Vice President. business objectives. The set of business
processes identified in association with
Context Diagram A high-level diagram, the objectives represent the “core
indicating the major functional processes” of the business area.
components and major internal and
external interdependencies of a system. Corporation A group of businesses acting
as part of a single legal entity.
Contingency Work effort allotted in a
workplan for all unforeseen but
possible occurrences of additional
work.
Contribution Margin see MARGIN

AMOUNT and MARGIN PERCENTAGE.

Cost The amount allotted or spent to Custom Code Coding added to a
acquire, deliver or produce anything. packaged application or module
e.g. the cost of labor to deliver generated by a CASE tool to
consulting services, the amount spent implement functionality that the
on incidental costs to deliver consulting application or generator has not
services, the amount spent on provided; see also CUSTOM EXTENSIONS.
hardware, software, etc.
Custom Development Method (CDM) A
CPU (IS It CPU or Client?) Support structured method for full life-cycle
Identification (CSI) A number custom development projects; see also
assigned to each Oracle customer. The LINE OF BUSINESS.
number is required in order to use the
Support hotline or RTSS. Associated Custom Extensions Custom modules that
with the CSI number is the client’s extend the functionality of packaged
name, RDBMS version, supported applications without modifying the
products, operating system, telephone, base functionality; see also CUSTOM
area code, and Technical contracts. CODE.
Critical Path Method (CPM) Network A Customer Service The business

network diagram that shows tasks, organization that 1. manages returns
their dependency links, and their and repairs of products that may or
critical path. may not have been purchased from the
enterprise originally; 2. responds to
Critical Success Factor (CSF) A business customer complaints about service or
event, dependency, product, or other products; see also BUSINESS
factor that, if not attained, would ORGANIZATION TYPE.
seriously impair the likelihood of
achieving a business objective. Customization A change made to the
standard Oracle software which
CSF see CRITICAL SUCCESS FACTOR. implements a Solution to a Gap.
CSI see CPU SUPPORT IDENTIFICATION. Custom Support System A custom-built

information system conceived,
CT see CUSTOM TRAINING. developed, and managed at the
enterprise level. It provides a service
Current Business Baseline The set of to one or more sites or business units.
business process and function models Such systems are designed to be
representing the current application generic, flexible, and independent of
system that supports the business area; the particular service sites. Examples
see also BUSINESS AREA, BUSINESS of custom support systems are:
PROCESS MODEL and BUSINESS enterprise data warehouses, data
FUNCTION MODEL. registry propagation systems, and
distributed application data transport
systems.

Custom Training (CT) An Organizational Database Management System (DBMS)
Change Management area providing A software environment that structures
organizations with training programs and manipulates data, and ensures data
designed to meet specific training security, recovery, and integrity.
needs identified through a preliminary
Training Needs Assessment. Custom Database Package An Oracle database
Training seeks to re-skill a work force object comprised of PL/SQL code
to optimize performance with new allowing execution of code at the server
technology. based on specific events or triggers.
Cut-over Transition to a new application Database Schema see ORACLE ID.

system in a live, production mode of
operation. Data Conversion The movement of data
from a legacy system or application to a
replacement application or subsystem.
D
Data Definition The specification of a
Database A collection of data, usually in data element to be maintained. The
the form of tables or files, under the specification includes datatype, size,
control of a database management and rules about processing: for
system. example, derivation, and validation;
see also BUSINESS RULE and INVARIANT.
Database Architecture The collective
application and database instances that Data Definition Language (DDL) A
comprise the complete system. subset of SQL used to create, alter,
drop, and otherwise change definitions
Database Function A callable routine
of tables, views, and other database
executed within a database server
objects.
environment.
Data Dictionary A part of a database that
Database Index A mechanism to locate
holds definitions of data elements, such
and access data within a database. An
as tables, columns, and views.
index may quote one or more columns
and be a means of enforcing Dataflow A named flow of information
uniqueness on their values. between business functions, datastores,
and external entities represented as an
Database Instance One set of database
arrow on a dataflow diagram; see also
management processes and an
BUSINESS FUNCTION, DATASTORE, and
allocated area in memory for managing
EXTERNAL ENTITY.
those processes. Typically, a database
instance is associated with one Dataflow Diagram A diagram
database. Note that a database instance representing the use of data by
may process data for one or more business functions; see also DATAFLOW,
applications. DATASTORE, EXTERNAL ENTITY, and
PROCESS.

Dataflow Diagramming A technique for Data Registry The master copy of the data
expressing the significant dataflows of associated with a business object.
a business system. Several databases may share access to a
common data registry to ensure
Data Integration The movement of data consistency and eliminate redundant
between two co-existing systems. The entries across multiple applications and
interfacing of this data may occur once databases. An example of a data
every hour, once a day, etc. registry would be a shared customer
master. All updates and changes
Data Integrity Testing Verification that would be made to the customer master
converted data is accurate and data registry and are then propagated
functions correctly within a single to subscribing sites. All systems
subsystem or application. requiring customer information would
interface with the customer data
Data Migration The movement of data registry.
from one database to another database
-- but not necessarily to a working Data Registry Interface An interface that
application or subsystem tables. transfers data registry data between
similar or dissimilar applications.
Data Model A representation of the
specific information requirements of a Data Replication The copying of data to
business area; see also ENTITY and from sites to improve local service
RELATIONSHIP MODEL. response times and availability;
frequently employed as part of a
Data Partitioning A technique to improve backup and recovery strategy.
application performance or security by
splitting tables across multiple Datastore A temporary or permanent
locations. storage concept for logical data items
used by specified business functions
Data Profile A description of the business and processes.
conditions that are needed to test the
application system.. Data Transfer The physical movement of
data between applications, perhaps
across sites.
Data Transformation The process of

redefining data based on some
predefined rules. The values are
redefined based on a specific formula
or technique.
Data Translation The process of

redefining data in a manner differing
between its original representation and
its final representation.

Data Warehouse A repository of subject- Deliverable Guideline A detailed
oriented data used for information description of a deliverable that
retrieval and decision support. includes: detailed description, usage,
audience, and distribution, format
DB2 An SQL-based database guidelines, control, template, and
management system. samples; see also DELIVERABLE.
DBMS see DATABASE MANAGEMENT Deliverable Management The process of

SYSTEM. managing the creation, review,
modification and distribution of
DDL see DATA DEFINITION LANGUAGE. deliverables provided to a client.
Software may be included as one of the
Decision A point in a process flow where managed deliverables.
there is a choice of possible paths. The
outcome of the decision determines Deliverable Template A tool designed to
which path the flow follows. aid in production of deliverables; a
template that gives the format and
Decision Point The diagrammatic structure of a deliverable; see also
representation, on a process flow DELIVERABLE.
diagram, of a decision which results in
the subsequent execution of one of two Delivery Vehicle The mechanism for
or more alternative sequences of producing or implementing something.
process steps. The decision is actually For example, SQL* Forms is a vehicle to
made during the execution of the produce computer programs.
previous process step. The decision
point is shown after that step for Dependency The relationship of one task
diagrammatic convenience. to another where the start or end date
of the second task (successor)
Decision Support System (DSS) An constrained by the start or end date of
application primarily used to the first (predecessor); see also
consolidate, summarize, or transform PREDECESSOR and SUCCESSOR.
transaction data to support analytical
reporting and trend analysis. Deployment ..The total set of activities
associated with the production
Deliverable A tangible, measurable implementation of a set of applications
output of a task. in specific location(s) at a particular
point in time.
Deliverable Component A subset of a
deliverable. A deliverable component Design Prototype A first working version
may be the output of a task step. of a system generated directly from
business models.

Detailed Deliverable A deliverable Distribution Management Distribution
whose structure originated from a high Management is the process to manage
level deliverable, but that contains the release and distribute of software in
significantly more detail; see also a controlled manner. This includes the
DELIVERABLE and HIGH-LEVEL kitting of software, documentation,
DELIVERABLE. patches and other. It involves initial
releases and subsequent patch tapes,
Development Life-cycle A complete upgrades and new releases. It also
process of developing computer includes providing the organizational
systems. challenges of obtaining release
approval from the Company Baseline
Distributed Database A database that is Review Board (CBRB).
physically located on more than one
computer processor. It is connected via DSS see DECISION SUPPORT SYSTEM.
some form of communications
network. An essential feature of a true
distributed database is that users or
E
programs work as if they had access to
EBF see ELEMENTARY BUSINESS FUNCTION.
the whole database locally.
EF see ESTIMATING FACTOR.
Distributed Processing The ability to
have several computers working Effort The amount of work, measured in
together in a network, where each person-hours, to perform a task.
processor runs different activities for a
user, as required. EIS see EXECUTIVE INFORMATION SYSTEM
Distribution A high-level business Element A thing of significance about
function responsible for configuring the which information is recorded; a
firmware parts of inventory, housing component at the most useful, basic
finished goods inventory (FGI), and level.
shipping finished goods to customers
or to internal sites; often synonymous Element Type Any element held in the
with a business organization; see also repository is classified as a particular
BUSINESS ORGANIZATION TYPE. type. Examples of element type are
entity, attribute, program module,
process, table, diagram, text, softbox.
Occurrences or instances of these are
called elements.

Elementary Business Function (EBF) A Entity Integrity Rules The rules that
business function which if started, must specify valid values or combination of
either complete successfully or, if it values for attributes of an entity. These
cannot complete successfully, must may include unique identifiers,
undo any effects that it has had up to domains, and multi-attribute validation
the point of failure. An elementary rules; see also BUSINESS RULE and
business function changes a business’s REFERENTIAL INTEGRITY CONSTRAINT.
data from one consistent state to
another; see also FUNCTION HIERARCHY. Entity Relationship Diagram (ERD) A
diagram that pictorially represents
End User see USER. entities, the relationships between them
and the attributes used to describe
Enterprise A group of departments, them; see also ATTRIBUTE, ENTITY, and
divisions, or companies which make up RELATIONSHIP.
an entire business.
Entity Relationship Model A type of data
Enterprise Support Systems The set of all model. Part of the business model that
computer-based systems, documents, consists of many Entity Relationship
and procedures used in support of Diagrams; see also DATA MODEL.
business enterprise operations.
Entity Test A detailed test of certain key
Enterprise Technical Architecture (ETA) data elements of a business entity that
A series of rules, guidelines, and is being converted or interfaced from
principles used by an organization to one system to another.
direct the process of acquiring,
building, modifying, delivering, and ERD see ENTITY RELATIONSHIP DIAGRAM.
integrating Information Technology
resources throughout the enterprise. Ergonomics The use of good design
These resources can include equipment, techniques that emphasize ease-of-use.
software, business processors,
protocols, standards, methodologies, IT Estimate A preliminary calculation of the
organizational structures and more. time and cost of work to be
undertaken. The construct option
Entity A thing of significance, whether calculates estimates using bottom-up,
real or imagined, about which percent adjustment, or top-down
information needs to be known or held. techniques in Project Bridge Modeler;
It is implemented in a database as one see also BOTTOM-UP ESTIMATE, PERCENT
or more tables. ADJUSTMENT ESTIMATE, WORK ESTIMATE,
and TOP-DOWN ESTIMATE.
Estimated Function Point Count 7

Function Points per System Entity + 5
Function Points per System Function.

Estimating Factor (EF) An item that Executive Information System (EIS) A
critically affects the amount of work reporting application targeted for use
effort estimated to complete a task; see by executives. Usually such
also BOTTOM-UP ESTIMATE. applications have extremely user-
friendly, graphical interfaces with a
Estimating Formula A formula that uses small local datastore derived from
estimating factors to derive an estimate connection to a data warehouse. It is
for a task. often used synonymously with decision
support system.
Estimating Guideline Text which
describes in detail how a task is Expense The amount of money allotted or
estimated. spent to cover incidental costs (e.g.
travel & living) or the cost of something
Estimating Model The combination of (hardware, software, etc.) to deliver
estimating factors and estimating consulting services.
formulas necessary to completely
estimate a route. Expense Reimbursement Expenses for
reimbursement by the client either
ETA see ENTERPRISE TECHNICAL allotted or received.
ARCHITECTURE.
(CASE Dictionary) Extensibility It is
Event An occurrence in a business’s often useful to add new elements,
environment to which that business properties, and associations into the
must respond; see also BUSINESS SYSTEM Dictionary. This is achieved by a
and EVENT RESPONSE. facility know as user extensibility.
Event Mechanism A permissible way in External Business Function A business
which an event is recognized. For function that is outside the scope of the
instance, a Customer Order may be application system, that acts as a source
entered into the system if received by or recipient of dataflows.
fax, phone, mailed-in purchase order or
internet-facilitated, but not by markings External Entity An entity that is outside
on a scratch pad. the scope of application system, that
acts as a source or recipient of
Event Response An event and the dataflows. An external entity might be
business process which responds to a person, a business unit, another
that event; see also APPLICATION application system, or any other thing
SYSTEM, BUSINESS SYSTEM, and EVENT. that might provide or receive
information from a function within the
application system; see also ENTITY.
External Process Step A process step that

is performed by an agent outside the
business area; see also INTERNAL
PROCESS STEP and PROCESS STEP.

Financial Organization A business
F organization that performs one or more
financial business functions. The data
Fee A charge, compensation, or payment
is segregated for organizational
for a service or product.
management or security. When
Feedback Response, including mapped onto Oracle Applications, a
corrections, additions, and approval, financial organization is required to
elicited from users, stakeholders, have a defined set of books. This
sponsors, and others, to any deliverable concept is more general than the set of
or deliverable component. books. It is replacing the set of books
as the key financial application
Feedback Session A meeting organized functional configuration parameter in
to present work in progress in order to releases of Oracle Applications starting
gain feedback; see also FEEDBACK. with 10.6.
FH see FUNCTION HIERARCHY. Flexfield A user-definable field in an

Oracle Application that is made up of
Field A means of implementing an item of segments. Each segment has a name
data within a file. It can be in you assign and a set of valid values.
character, date, number, or other
format and be optional or mandatory. Focus Area 1. A group of associated
activities that define and establish
File Transfer Protocol (FTP) The physical program level deliverables, i.e.
movement of data files between standards, configuration, and
applications, often across sites. processes. These deliverables are used
by multiple projects creating
Finance A high-level business function commonality and reusability across the
that handles accounting and financial program. 2. A team of individuals
functions of a company; for example, working within the Program Office
corporate, division, and subsidiary framework for a common family of
headquarters; often synonymous with a processes. These focus areas could also
business organization; see also BUSINESS be referred to as Program Office
ORGANIZATION TYPE. Projects.
Focus Group A small group selected to

provide opinions and responses to
topics or issues presented in a group
setting; an assessment technique.
Foreign Key One or more columns in a

relational database table that
implement a many-to-one relationship
that the table in question has with
another table or with itself.

Form A program for viewing or entering Function Dependency The dependency
information. Normally it refers to a of one function's commencement upon
rectangular area of the screen, which the completion of another function.
has the appearance of a paper form,
through which you can view or Function Dependency Diagram A visual
manipulate information in a database. means of recording dependencies
between business functions.
Formal Build Construction of an
information system by the well Function Hierarchy A grouping of
established steps of specify, code, test, elementary business functions into one
correct. or more hierarchical levels. Typically
the highest level corresponds to the
Format The type of data that an attribute company organization, and the middle
or column may represent; for example, level corresponds to a grouping of
character, date, number, sound, or available application functions; see also
image. BUSINESS FUNCTION and FUNCTION
DECOMPOSITION.
Fourth-generation Programming
Language (4GL) A language that Function Label A unique ID, within an
manipulates high-level objects, such as application system, used for a business
screen items and database tables, by function.
declaring what is to be done to them
rather than procedurally describing Function Name A short, succinct
how it is to be done, as in 3GLs. sentence, starting with a verb,
describing a business function; see also
FTP see FILE TRANSFER PROTOCOL. FUNCTION LABEL.
Function see BUSINESS FUNCTION, Function Point Analysis (FPA) A

ELEMENTARY BUSINESS FUNCTION, and technique used to estimate system size.
SYSTEM FUNCTION. Using Function Point Analysis, you can
calculate system size based on the
Function Decomposition A technique for number of functional element types in
modeling business functions by the system you are building, as
decomposing a single business function adjusted by its general system
into a number of lower level business characteristics and your technology
functions, and then progressively productivity factor; see also
decomposing these until the FUNCTIONAL ELEMENT TYPE.
appropriate level of detail is reached.
Function decomposition gives rise to Function Point Estimate (FPE) An
functions arranged in groups or estimate of work effort produced using
hierarchies known as a business Function Point Analysis or an
function hierarchy; see also ATOMIC equivalent method.
FUNCTION, ELEMENTARY BUSINESS
FUNCTION, and FUNCTION HIERARCHY.

Functional Currency The principle Generator A mechanism for transforming
currency used to record most business the specification of a module into
transactions and maintain accounting executable program code, also known
data while working within a particular as a code generator.
Oracle Application set of books.
Generator Template A skeleton or outline
program from which a generator can
G reuse common elements; for example,
boilerplate information, window sizes,
Gantt Chart A scheduling tool used to
OK and Quit buttons.
display the status of a project’s tasks.
A Gantt chart shows each task’s
Goal see BUSINESS GOAL.
duration as a horizontal line. The ends
of the lines correspond to the task’s Group Interview Any session where
start and end dates. users, stakeholders, or sponsors
collectively discuss the requirements,
Gap A Gap is a relationship between a
priorities, design, or implementation of
Requirement and an Application
a business solution system; see also
Function where the standard
FEEDBACK and WORKSHOP.
Application Function will not meet the
Requirement. Guideline Text that provides instructions
and advice for performing a task and
Gap Analysis 1. The process of
suggests possible approaches.
determining, documenting, and
approving the variance between
business requirements and system H
capabilities in terms of packaged
application features and technical Hardware Node A computer on a
architecture. 2. The process of network; for example, clients and
determining and evaluating the servers.
variance or distance between two items
properties being compared. Help Desk A support system designed to
assist end users with technical and
General Education Course A course that functional questions and problems.
educates the project team or users in
fundamental business concepts. It Helptext see METHOD HELPTEXT.
exposes attendees to new business
High-level Deliverable A deliverable that
approaches practiced in industry and
specifies a framework into which
provides them with a common
further details can be added; see also
understanding of relevant business
DELIVERABLE, DETAILED DELIVERABLE,
issues.
and INITIAL DELIVERABLE.

Human Resources The high-level Information Systems (IS) A system for
business function involving the managing and processing information,
management of human resources and usually computer-based. Also, a
payroll functions of a company; often functional group within a business that
synonymous with a business manages the development and
organization; see also BUSINESS operations of the business’ information
ORGANIZATION TYPE. systems.
Information Systems Strategies (ISS) A

I method that aligns information
technology priorities with business
Impact Analysis The process of
strategies and defines the approach to
understanding the complete effect of a
take to achieve those goals.
particular change; see also CHANGE
REQUEST. Information Warehouse see DATA
WAREHOUSE.
Implementation Questionnaire A tool
you use to collect business and system
Initial Deliverable A deliverable is initial
information during a business baseline
if it is intended to be updated later. An
interview. It consists of a pre-built set
initial deliverable is usually
of questions organized by business
preliminary and its content changeable
function that are to be supplemented
by a later task when more information
by the analyst with relevant company
is known.
terms and other characteristics before
use in driving the interview. IPO The Input-Process-Output technique
is a generic modeling tool that was
Index see DATABASE INDEX.
designed for framing complete process
specifications by identifying: inputs,
Information Access Model A model that
rules, process step descriptions, tools
depicts access to key process and
and outputs.
organization information for reporting
and/or security purposes.
Installation The loading of an instance of
an application system that is complete,
Information Flow Model A model that
tested, operational, and ready. An
visually depicts information flows in
installation includes all necessary
the business between business
software, hardware (including
functions, business organizations and
terminals, networks, etc.) and
applications.
documentation, and includes all
Information Model see DATA MODEL. required data; see also APPLICATION
SYSTEM.
Instance see DATABASE INSTANCE.

Integration Fit Analysis A statement of fit IPO The Input-Process-Output technique
and gaps for integration points between is a generic modeling tool that was
unique applications and installations of designed for framing complete process
the same application. specifications by identifying: inputs,
rules, process step descriptions, tools
Integration Test A sequence of steps or and outputs.
set of procedures to verify the inter-
operability of various system IS see INFORMATION SYSTEMS.
components; see also SYSTEMS
INTEGRATION TEST. ISS see INFORMATION SYSTEMS STRATEGIES.
Inter-company Transaction A transaction Issue A situation or concern which

between two legal entities that share requires a resolution. Some issues, if
common ownership, for example, not addressed, could adversely impact
under the same holding company. The the success of a project.
two companies usually have an account
relationship (for example, an inter- Item Master The master list of all items
company suspense or clearing account) available for transaction within a
that facilitates inter-company product group containing Oracle
accounting. manufacturing applications. It is also a
key application functional
Interface A linkage between systems configuration parameter.
which can be either automated (via
software programs) or procedural K
(manual).
Key A way of accessing something. Any
Interface Programs A set of programs set of columns used for retrieval of
that systematically link two or more rows from a table; see also COLUMN,
systems to each other. PRIMARY KEY, and UNIQUE IDENTIFIER.
Internal Process Step A process step that Key Deliverable A major deliverable that
is performed within the business area; is usually reviewed with the client,
see also EXTERNAL PROCESS STEP signed off, and placed under change
and PROCESS STEP. control; see also DELIVERABLE.
Inventory Organization A fundamental Key Performance Indicator (KPI) A
Oracle manufacturing and distribution significant measure used on its own, or
application functional configuration in combination with other key
parameter. The inventory performance indicators, to monitor
organizations are derived by mapping how well a business is achieving its
inventory or manufacturing business quantifiable objectives.
organizations onto Oracle Applications.
Typically they will be manufacturing
plants, warehouses, divisions, or
departments.

Key Resource A person with a wide Line of Business (LOB) Each service
range of skills or experiences who can within Oracle Services is a line of
be effective in many types of tasks, or is business. For example, Custom
critical to the completion of a specific Development, Application
task. Implementation, and Business Process
Reengineering are all lines of business.
KPI see KEY PERFORMANCE INDICATOR.
Link Test A test to identify errors in
L linked modules of an application
system. Link testing is an extension of
Labor Cost see COST. module testing carried out on a number
of levels of detail. Examples include,
Labor Cost Rate The rate (internal cost) linked modules of a program, linked
for each consulting grade level for programs of a functional area or
delivering services to a client. subsystem, and linked subsystems of
the complete application system. The
Labor Fee see FEE. link test is usually a white box test; see
also MODULE INTEGRATION TEST.
Labor Fee Rate The rate (price) for each
consulting grade level charged for Live Implementation process has ended
delivering services to a client. and the solution is put into production.
Leaf Function An function that is not LOB see LINE OF BUSINESS.

decomposed at the bottom of a function
hierarchy. It may be a leaf function Local Currency The denomination of
because definition is incomplete. currency used for transactions in a
particular local finance business
Legacy Application Interface A location.
heterogeneous interface between Oracle
Applications and a pre-existing and Localization An enhancement or
preserved legacy system. modification necessary to support
specific site requirements not
Legacy System An existing system addressed by the base configuration
repository of information and hardware and software. It is
processes. developed by and purchased from
Oracle. These site specific
Legal Entity A high level business requirements generally satisfy a
organization that operates within the government or regulatory agency
bounds of a specific set of legal requirement, although localizations are
requirements (including currency), not limited to this purpose.
typically pertaining to tax regulations
and reporting requirements Localization Approval The agreement to
modify the company standard software
and hardware configuration relative to
the site requirements.

Localization Tape A tape containing Manufacturing A high-level business
localization programs to be installed to function responsible for manufacturing
the applications software. or assembling products; often
synonymous with a business
Location see BUSINESS LOCATION. organization; see also BUSINESS
ORGANIZATION TYPE.
Logical Application Architecture A
complete map of the application Mapping A technique for establishing
instances required to support the application fit to business
applications architecture. requirements, identifying gaps and
proposing initial solutions. Also a
Logical System Design The task of technique to define the relationship
designing a system to support business between objects; see also
needs without making final decisions APPLICATION FIT and MATRIX
regarding the physical implementation. DIAGRAM.
The same logical design should be
appropriate for many physical Mapping Scenario 1. A plan for and
implementations using, for instance, record of business solution testing
different versions of a database including: business processes involved
management system. in the test, the business conditions that
are needed to test the application
Look and Feel The appearance and system, definition of test script
behavior of a system facility as execution, support tools required
perceived by the end user. This during execution of the test, and a
includes the data, the layout, and the record of test actions. 2. A detailed
user interaction through menus, step by step description of how you
buttons, text editing, and other devices. want team members to test the
standard Oracle software to see if it
M will meet the needs of a Requirements
Scenario; see also BUSINESS SOLUTION
Management The process of planning, TESTING
controlling, and completing the
execution of an undertaking. Mapping Team A group of people
responsible for the modeling, design or
Manual Function A business function mapping for a particular business
that is not system-assisted; see also process.
BUSINESS FUNCTION and SYSTEM-
ASSISTED. Margin Amount The difference between
the costs (labor, expenses, and
overhead) and revenue plus expense
reimbursements expressed as a
currency amount.

Margin Percentage The ratio between the Module A logical program unit.
margin amount and costs, expressed as Examples include: forms, reports, user
a percentage. exits, C programs, PL/SQL procedures,
and database triggers; see also PRIMARY
Marketing A high-level business function MODULE and SUPPORTING MODULE.
responsible for marketing functions
within a company; often synonymous Module Integration Test A test of related
with a business organization; see also modules in an application system using
BUSINESS ORGANIZATION TYPE. scenario test specifications.
Matrix Diagram A spreadsheet diagram Module Network A technical diagram of

where the axes represent two modules in an application system that
associated types of elements of interest expresses the possible execution paths
to information systems developers. A of business transactions.
matrix diagram is used to express a
mapping. Module Process Test Model A detailed
testing model for the development and
Mechanism 1. A particular technique or execution of testing. It is identical to the
technology for delivering a function. System Process Test Model, with the
Examples might be a telephone, a addition of module references.
computer, or an electronic mail service.
2. Resources that enable or facilitate the Module Test A procedure or sequence of
step/sequence in a test scenario. steps that determines whether a
module functions properly in isolation
Method A structured organization of from other system components, and
tasks, estimates, and guidelines that conforms to project standards.
provide a systematic approach or
discipline. MoSCoW Must have, Should have, Could
have, Won’t have, a way of classifying
Method HelpText The automated form of and prioritizing facilities for inclusion
Oracle Method’s handbooks included in an information system; used in
with every route. This may be accessed timeboxed development where the
directly from the Windows desktop scope may need to be redefined
or from within Project Bridge Modeler according to the rate of progress.
or Project Workbench; also called
online help. N
MIPS Millions of Instructions Per Second Near Real-time Interface An application
-- a measure of computer processing interface that supports asynchronous
capacity. transfer of data between applications.
It transfers data with a sufficiently
small time delay so as to leave the
interfaced applications in states that are
very close to synchronized.

Node A single computer, group of OLAP see ON-LINE ANALYTICAL
computers, or mechanism for handling PROCESSING.
some communication traffic through a
particular point on a computer OM see ORACLE METHOD.
network.
On-Line Analytical Processing (OLAP)
Non-Billable Project Expenses The On-line retrieval and analysis of data to
project expenses that are not billable to reveal business trends and statistics not
a client; see also PROJECT EXPENSES. directly visible in the data directly
retrieved from a data warehouse. Also
Non-Billable Utilization The utilization know as multi-dimensional analysis.
that is not billable to a client; see also
UTILIZATION. OO see OBJECT ORIENTATION.
Non-revenue Entity A legal entity that Operational Datastore (ODS) A data

performs services on behalf of another warehouse that is a repository for near
entity. Such services are usually real-time operational data rather than
performed in exchange for an inter- long term trend data.
company service fee.
Oracle ID An account on a database,
Normalization A technique to eliminate comprised of a database username and
data redundancy. password.
Null The state of a data item indicating no Oracle Method (OM) Oracle Services'
value. Null is not equivalent to zero. integrated service methodology which
consists of workplans, handbooks, and
templates used to provide enterprise
O business system solutions.
Objective A statement of business intent Oracle Services An Oracle Corporation
that may be measured quantifiably. business organization that provides
professional services.
Object Orientation (OO) The perspective
that systems should be constructed Oracle Survey Tool A customizable
from objects, which themselves may be database of questions used by
aggregations of smaller objects. Organizational Change Managements
to generate surveys, data analyses, and
OC see ORGANIZATIONAL
graphical reports for assessments.
COMMUNICATIONS.
Organization see BUSINESS ORGANIZATION.
OCM see ORGANIZATIONAL CHANGE
MANAGEMENT. Organization Type see BUSINESS
ORGANIZATION TYPE.
ODS see OPERATIONAL DATASTORE.

Organization Unit An element that Overhead The operating expenses
represents part of the structure of a associated with delivering services,
business. An organizational unit can such as rent, light, heat, taxes and non-
represent an entire business, a group or billable utilization.
department within the business, a
person within a group or department Overhead Factor A rate multiplier
or a role; see also AGENT, BUSINESS associated with a category of overhead,
UNIT, and AGENT CHANNEL. e.g., Corporate, Division, or Practice;
see also OVERHEAD.
Organizational Change Management
(OCM) An Oracle Services line of P
business providing change
management expertise to organizations Partition need definition.
seeking to manage the human and
organizational factors involved with Part Master see ITEM MASTER.
implementing new technology.
Organizational Change Managements PAT see PERFORMANCE ASSURANCE TEST.
includes five service areas:
Organizational Effectiveness Payment Milestone A significant project
Assessments, Organizational event at which time a payment is due.
Communications, Human Performance Payment milestones can be progress
and Development, Leadership points, dates, the completion of a task
Development, and Custom Training; or the production of a deliverable.
see also ORGANIZATIONAL
EFFECTIVENESS ASSESSMENTS, Payment Terms The terms and conditions
ORGANIZATIONAL COMMUNICATIONS, upon which payments will be received
HUMAN PERFORMANCE AND from a client.
DEVELOPMENT, LEADERSHIP
DEVELOPMENT, and CUSTOM TRAINING. PBM see PROJECT BRIDGE MODELER.
Organizational Effort Any activity or set PCM see PRACTICE MANAGEMENT.

of activities implemented
systematically by an organization to Percentage Adjustment Estimate Total
achieve a particular goal. estimate adjusted for organizational
factors.
OT see OBJECT TECHNOLOGY.
PGM see PROGRAM MANAGEMENT.
Outsourcing The practice of appointing
an external organization to provide any Phase A grouping of tasks that lead to a
or all of the services of the IS major project deliverable or milestone.
department or any other internal
Phase Completion The project
service department.
management tasks which conclude and
secure client sign-off of a phase.

Phase Control The project management (M&D) Planning A high-level business
tasks which execute concurrently with function responsible for manufacturing
phase execution, and perform project and distribution planning for one or
monitoring, directing, and reporting more manufacturing and distribution
functions during a phase. business units; often synonymous with
a business organization; see also
Phase Execution The method execution BUSINESS ORGANIZATION TYPE.
tasks performed during a project phase.
Policy A policy is a documented directive
Phase Management The project from enterprise management which
management tasks required to plan, specifies how some aspect of the
control and complete the execution of a business is to be conducted.
project phase.
Practice Management (PCM) Specifies the
Phase Planning The project management process, tasks, and responsibilities
tasks which update project plans and regarding the management of a
procedures for a phase and secure consulting practice. Specifically, this
additional resources necessary to includes client management, project
execute that phase. portfolio management, and staff
training, recruitment, and growth.
Physical Application Architecture A
complete map of the database Predecessor A task that precedes another
instances, their sites, and the task and is related to it by a task
application instances and Oracle IDs dependency; see also SUCCESSOR.
that they support. This will
incorporate aspects of the logical Prerequisite Something needed by a task
architecture, and the high level designs produced by a previous task or an
for security and interfaces. external source; see also DELIVERABLE.
Pilot An initial project which will serve as Pre-sales Cycle The series of activities
a model or template for future projects. that occur before the application was
selected.
PJM see PROJECT MANAGEMENT.
Problem A perceived variance between
Plan A scheme, method or design for the the expected and observed ability of an
attainment of some objective or to item to fulfill its defined purpose.
achieve something.
Problem Statement A concise phrase,
Planned Response System The entire set motto or goal-oriented explanation of
of business processes in a business the motivation behind buying a new
area that respond in a predetermined application system.
way to a known set of events; see also
APPLICATION SYSTEM and EVENT. Problem Report The mechanism by which
a problem is recorded, investigated,
resolved and verified.

Procedure A written set of steps that Process Label A unique reference, within
specifies how to carry out a business an application system, for a process.
function. If the business function is
system-assisted, its corresponding Process Modeling A structured approach
procedure will indicate how the used to identify, define, and document
application system carries out that the activity performed by a business to
business function; see also APPLICATION produce business deliverables.
SYSTEM and BUSINESS FUNCTION.
Process Narrative A reduction of a new
Process 1. The sequential execution of business process design down to a job-
functions triggered by one or more level description, thereby defining how
events. 2. A grouping of tasks within a the work gets done and laying a
method based on common functions or foundation for development of a user
disciplines which lead to one or more guide, role-based user training and
key deliverables; see also BUSINESS user certification or other types of
PROCESS and SYSTEM PROCESS. readiness testing. One Process
Narrative should be written for each
Process Analysis A component of a business process.; see also ROLE-
business requirements scenario that BASED USER TRAINING
facilitates quantitative analysis and
measurement of each process step and Process Owner The agent with overall
compares the current to the proposed responsibility for a complete business
process in order to sell change to process; could be the customer of the
management and to key business process, or the supplier (person or
people and systems users. organization charged with fulfilling the
request).
Process Characteristics Attributes that
describe a process and how it works Process Research A technique used in
including descriptive narrative for its testing the feasibility of a process
steps, tools required, skill levels model and gathering facts in order to
required, controls, performance offset doubters and naysayers. The
measures approach involves answering
Implementation Questionnaires,
Process Flow The passing of execution of reviewing current process
a process from one process step to the documentation, gathering statistics
next. It may include the passing of regarding volumes or frequencies,
information or materials from the first understanding policy statements and
step to the second. measures of performance, interviewing
key users to ascertain critical factors for
Process Flow Diagram A diagram which success.
shows the triggering event(s),
sequential flow of process steps,
decision points, and deliverable or
outcome of a single process.

Process Step An instance of the execution Program 1. A set of coded instructions
of a function as a step in performing a that a computer executes or interprets
process. In a fully-analyzed business to perform an automated task. 2. A
process model, all process steps are interrelated group of projects that are
instances of elementary business either being run concurrently or
functions. A business process step is sequentially and that share a system
normally composed of a series of goal. Individual projects may have
procedure steps, where tools such as different goals, however the combined
application screens, reports and set of projects will have a program
inquiries are used. Once a process goal. 3. A data object in Oracles
steps begins, all of its procedure steps Program Management Methodology
must be completed in order to achieve (PGM).
an accurate and quality output.
Business requirements are defined at Program Library The physical location of
the process steps level, while job all Program related deliverables, ,
definitions are at the procedure level. standards, tools, communications, etc.
that support an entire Program. Items
Product Group Each separate application within the Program Library are
instance of Oracle Application Object program level solutions
Library in an Oracle database. A
product group may contain any Program Management (PGM) A method
number of Oracle Applications which defines how a program is
products in addition to the single managed when executed according to
instance of Oracle Applications Object the requirements of Oracle Method.
Library.
Program Office A project executed under
Production Environment The database, the sponsorship of program
equipment, documentation, and management that establishes
procedures used in support of live commonality and reuse across multiple
business operations. projects within a program.
Profile Option An Oracle Applications Project A set of work processes, tasks

control switch that a user can set to with associated deliverables and
govern some aspect of system resources executed over a specific
processing or user interface. period of time with predetrimined
budget and business objectives.
Project Bridge Modeler (PBM) Applied

Business Technology tool used to build
the project planning and estimating
system. PBM allows project managers
to select, edit, combine, and create
project workplans or routes, that best
fit the needs of the client.

Project Completion The third and final Project Life-cycle The organization of a
part of the PJM project life-cycle. The project according to its three major
satisfactory conclusion of the project parts: planning, execution and
and settlement of all outstanding issues completion.
prior to hand over of the project
deliverables to the client. Project Management Method (PJM) A
method which defines how a project is
Project Earned Value A measure of the managed when executed according to
value of completed tasks in a project. the requirements of Oracle Method.
There are various ways of measuring
the value of a task. These include Project Milestone A significant project
percentage on commencement, event.
percentage on completion, and amount
at milestone. Project Objectives The set of criteria for
measuring a project’s success.
Project Execution The second part of the
PJM project life-cycle. The carrying out Project Office The management of the
of project plans determined during project library for a specific project.
planning for a method approach.
Project execution also encompasses Project Partition Part of a project usually
elements of control which analyze representing a coherent set of facilities
project performance and take corrective to be developed by a single developer,
action as needed. commonly organized and managed as a
sub-project.
Project Expenses Funds allocated or spent
to cover incidental or non-labor costs of Project Planning The first part of the PJM
a project. project life-cycle. The definition of a
project with respect to scope, quality,
Project Infrastructure The framework for time and cost. Project planning also
storing, maintaining, and referencing determines the appropriate
all implementation deliverables and organization of resources and
supporting materials including office responsibilities to execute a project.
space, software tools, and standards.
Project Schedule A list of tasks to be
Project Library 1. A system for storing, carried out presented against a
organizing and controlling all timetable for their completion.
documentation produced or used by
the project. 2. The physical location of Project Timeline A specification of work
all deliverables for a single project, plus to be carried out together with the
administrative and support materials. number of resources needed to achieve
An administrative office that all a target duration; see also PROJECT
members of a team should have access SCHEDULE.
to.

Project Workbench (PW) Applied PW see PROJECT WORKBENCH.
Business Technology tool used to
schedule, track, and analyze your Q
project. PW provides work breakdown
structures based on the routes selected Quality Audit An audit used to assess the
in Project Bridge Modeler and provides adherence of the project team to plans,
the capability to manage these plans. procedures, and standards.
Project Workplan A specification of the Quality Management The means of
work to be performed for a project, implementing quality policy. On a
expressed as a set of interdependent particular project this is achieved
tasks with project resources allocated through quality planning, quality
over time. assurance, quality control, and quality
improvement.
Property Any detail that serves to qualify,
identify, classify, quantify, or express Quality Review A review used to assess
the state of an element in a repository. the quality of a deliverable in terms of
fitness for purpose and adherence to
Prototype A facsimile of an end product
defined standards and conventions.
used to demonstrate a concept rapidly,
check feasibility, and/or gain Questionnaire A written or electronic
acceptance. survey instrument comprised of a
series of questions, designed to
Prototyping The construction of a partial
measure a specific item or set of items.
system to demonstrate some aspect or
aspects of the intended system
behavior in order to gain user R
acceptance or to establish technical
feasibility. RBT see ROLE-BASED TRAINING.
Publish and Subscribe A data RDBMS see RELATIONAL DATABASE

communication paradigm for MANAGEMENT SYSTEM.
implementing the data flow between
two or more applications. An event in Real-time Interface An application
a source application causes the interface that supports synchronous
application to ‘publish’ a data object or transfer of data between applications.
message to the potentially interested
Real-time Support System (RTSS) An
applications who individually opt to
electronic information system
‘subscribe’ to the data object or
accessible by Oracle and the client.
message. The subscription of the
interested applications to the data
object or message causes a state change
in the applications. Contrast Request-
Reply.

Real-time System A system in which Relational Database Management System
events control actual mechanisms. (RDBMS) A database management
Real-time systems often control system in which data can be viewed
machinery (for example, a control and manipulated in tabular form. Data
system for an aircraft) and are often can be sorted in any order and tables of
time- or safety-critical; see also EVENT information are easily related or joined
and STATE TRANSITION DIAGRAM. to each other.
Record In a non-relational database Relationship 1. What one entity has to do

system, a record is an entry in a file, with another. 2. Any significant way in
consisting of individual elements of which two things of the same or
information, which together provide different type may be associated.
full details about an aspect of the
information needed by the system. Release A baseline issued from the CM
Individual elements are held in fields Repository for delivery to a
and all records are held in files. An destination. The destination may be
example of a record might be an internal to the project environment,
employee. Every detail of the such as for testing, or external, such as
employee for example, date of birth, to the client.
department code, or full names will be
found in a number of fields. In a Reporting Database A database used by
relational system record is an alternate reporting applications. Reporting
word for row; see also ROW. databases are often duplicates of
transaction databases used to off-load
Record Type A predetermined set of report processing from transaction
fields within a file. databases.
Reference Materials Documents that Repository A mechanism for storing any

describe key aspects or samples for the information about the definition of a
current business. These are normally system at any point in its life-cycle.
compiled before the project starts and Repository services would typically be
may have been used during the Pre- provided for extensibility, recovery,
sales cycle. integrity, naming standards, and a
wide variety of other management
Regression Test Specific assurance testing functions.
on an application system release, after
defects have been corrected or
enhancements have been completed.
Regression testing is required to re-
validate an application system,
confirming that prior validations have
not regressed.

Request for Proposal The formal Research and Development These
mechanism by which a company business organizations are responsible
conveys its business requirements for the research and product
during the search for a new application development functions within a
system. Known as the RFP, this company; see also BUSINESS
document drives the Pre-sales cycle ORGANIZATION TYPE.
and provides valuable information into
the business requirements definition Resource Any persons, equipment, or
process of the implementation; see also material needed to perform a task(s).
PRE-SALES CYCLE.
Resource Category see CONSULTING
Requirement A requirement is a specific, GRADE LEVEL.
detailed business need which is to be
compared with Application Resource Database A record of the
functionality to determine if the need resources available, primarily human
can be met with the standard Oracle resources, including information about
software. the skills and experiences of the
resources.
Requirements Scenario A Requirements
Scenario is a formal statement of Revenue Income from services labor fees,
detailed business requirements for a training fees, licensed product sales
Process, the source of the and support fees.
Requirements, how these requirements
will be satisfied (either the application, Revision The authorized modification to
manual Procedure, Workarounds, or a configuration item.
other application solutions) and what
Risk The potential of an adverse
prototyping steps must be taken to
condition occurring on a project which
prove the design.
will cause the project to not meet
Requirements Workshop A workshop, expectations. A risk requires
usually attended by project sponsor, management assessment and a strategy
stakeholders, and developers, to for its mitigation.
provide a sufficiently detailed
Role 1. A skill set for resources assigned
definition for a developer to commence
to a project. 2. A generic set of
build. The definition will be further
activities which may be assigned; see
defined and refined during
also RESOURCE.
development, particularly by user
reviews; see also USER REVIEW and
WORKSHOP.

Role-Based Training(RBT) A user
training approach that focuses on
S
developing curriculum based on Oracle
Sales Business organizations that handle
Application responsibilities (i.e., roles)
typical sales functions, including
that have been defined and assigned to
generating quotes and sales orders; see
users. Application responsibilities tie a
also BUSINESS ORGANIZATION TYPE.
user to a menu of functions that can be
performed. An RBT curriculum trains Sample A statistically-significant subset
a group of users on these specific selected and analyzed to estimate the
functions, using client data and characteristics of a larger group or
highlighting client procedures. population; a set of individuals within
an organization assessed to provide
Role Placeholder A fictitious resource
information on the preferences,
name with a resource category
opinions, attitudes, and practices of the
assigned to replace a role; e.g., Analyst
group they represent.
1 - Principal, Analyst 2 - Senior.
Scenario A discrete instance of a system
Route A variation of a method containing
process; see also MAPPING
all tasks required in order to deliver a
SCENARIO.
service; a dependency network.
Scenario Test Specification A component
Row An entry in a table that typically
of a test script which defines the test
corresponds to an instance of some real
execution -- it is comprised of scenario
thing, consisting of a set of values for
information, system process
all mandatory columns and relevant
information, a series of test steps, and
optional columns. A row is often an
their associated data profiles.
implementation of an instance of an
entity; see also COLUMN and TABLE. Schema An information model
implemented in a database. A schema
RTSS see REAL-TIME SUPPORT SYSTEM.
may be a logical schema, which will
define, for example, tables, columns,
Rule of 3-2-1 A rule of thumb used during
and constraints, but which may not
process research that stresses the
include any optimization. It may be a
importance of “walking the floor” and
physical schema that includes
other practical investigation over
optimization, for example, table
conference room interviews. It means
clustering.
that roughly 3 hours of research are
normally required for every 2 hours of
Scope The boundaries of a project
process design and 1 hour of formal
expressed in some combination of
deliverable creation (like creating a
geography, organization, applications
BRS using a template or other tool); see
and/or business functions..
also PROCESS RESEARCH and
BUSINESS REQUIREMENTS
SCENARIO.

Scope Change A change to project scope. Shared Localization A customization to
A scope change requires an adjustment an application product required by
to the project workplan, and nearly more than one country.
always impacts project cost, schedule
or quality. Sign-off Agreement with a client of the
successful completion of a project,
Scope Creep The common phenomenon project phase, or deliverable.
where additional requirements are
added after a project has started Site A uniquely identifiable geographic
without reconsidering the resourcing or location or place from which one or
timescale of the project. Scope creep more business organizations may be
arises from the misapprehension that wholly or partly operating.
such small additions will not affect the
project schedule. Site Based Configuration Specific
modifications or enhancements made
Scoping Workshop A workshop, usually to the company base configuration to
attended by the project sponsor and support site requirements. The site
developers, with the objective of base configuration must remain
defining the boundaries of the scope for integrated with the company base
an intended project prioritizing configuration to maintain integrity of
requirements within the scope; see also the company base configuration; see
WORKSHOP. also COMPANY BASE CONFIGURATION.
Script 1. A sequence of coded Site Configuration The definition and

instructions executed or interpreted by management of the site base
computer programs. 2. A prescribed configuration.
set of steps to follow when testing.
Skills Analysis The collection of data
Security Profile A list of role-based from groups and individuals targeted
security specifications. in a specific training situation, to
determine the existence and nature of
Sequence A database object created such any performance gap(s); used in a skills
as a table used to generate unique keys assessment to determine training needs
(sequence numbers). and develop training goals and
objectives to be translated into
Set of Books A company or group of learningware recommendations.
companies within Oracle Applications
that share a common chart of accounts, Skills Database see RESOURCES DATABASE.
accounting calendar, and functional
currency. This concept is being
superseded by the concept of a
financial organization in releases of
Oracle Applications starting with 10.6.

Software Management Software Storyboard A technique, borrowed from
Management is composed of several the film industry, for describing screen
different processes, that when dialogues. A storyboard consists of an
combined, perform the total ordered series of pictures illustrating
management of all software in a stages of the dialogue. The pictures are
distributed organization. The annotated with notes about logic and
processes within Software Management user input.
are configuration management and
distribution management. Structured Query Language (SQL) The
ANSI internationally accepted standard
Solution A Solution is the resolution of for relational database systems,
the discrepancy between one or more covering not only query but also data
Gaps and one or more standard definition, manipulation, security, and
Application Functions. A solution some aspects of referential and entity
make take the form of a Procedure, integrity; see also ANSI.
Policy or Customization.
Sub-function A business function that
Source Module A physical program unit. has a parent function.
An application system’s repository of
source code is controlled at the source Sub-process A process performed
module level. entirely within another process.
SQL see STRUCTURED QUERY LANGUAGE. Successor A task that follows another task
and is related to it by a dependency
Stakeholder A person, group, or business link; see also PREDECESSOR.
unit that has a share or an interest in a
particular activity or set of activities. Supporting Module A module that is not
itself an entry point in an application
Standard A set of rules for ensuring system. Supporting modules are
quality. Usually, standards are defined generally shared modules that provide
for products deliverables or deliverable functionality used by multiple primary
components and processes. modules. They are usually not
referenced independently in user-
State A recognizable or definable oriented documentation. All PL/SQL
condition that a system or an object can packages, procedures, and database
be in at some point in its life-cycle. triggers are examples of supporting
modules; see also MODULE and PRIMARY
State Transition A valid change of a MODULE.
system or an object from one state to
another, modeled on a state transition Support Profile A section of a test
diagram; see also STATE. scenario that identifies support tools
required during execution of the test.
Store A collection of information or
materials used in a process. Swim Lane see AGENT CHANNEL.

Synonym 1. A name assigned to a table System Operations Function A system
or view that may then be used more function that serves to support the
conveniently for reference. 2. An continuing operations of the
alternate name for an entity. application system. Examples are
backup, recovery, audit; see also
System A named, defined, and interacting APPLICATION SYSTEM, SYSTEM FUNCTION,
collection of procedures and processes, and SYSTEM OPERATIONS PROCEDURE.
along with the organized deployment
of people, machines, various System Operations Procedure A step-by-
mechanisms, and other resources that step indication of the way in which an
carry out those procedures and application system executes a system
processes; see also APPLICATION SYSTEM. operations function. The System
Operations Guide is a CDM deliverable
System Architecture A representation of that is a compilation of all relevant
the structure of an application system system operations procedures; see also
usually confined to essentials. APPLICATION SYSTEM.
System-assisted Performed, either System Process The response which an

completely or in part, with the aid of an application system makes to an event.
application system; see also It comprises the sequential execution of
APPLICATION SYSTEM and MANUAL both manually executed process steps
FUNCTION. which are instances of manual
functions and process steps
System Facility A part of an information automatically executed by a computer
system that supports an identifiable set system which are instances of system
of business functions. A facility may be functions.
a single module or it may be a whole
sub-system. System Process Test Model The overall
basis for testing the functional
System Function Something a computer requirements of a system. The System
system does in order to support one or Process Test Model contains scenarios,
more business functions; see also data profiles, and test specifications,
APPLICATION SYSTEM and BUSINESS but no module references.
FUNCTION.
System Test A project activity that tests
System Interface The mechanism used to an application system over its complete
create connectivity between two life-cycle, using scripts and associating
systems. scenario test specifications into
chronological sequences.
System Test Flow A set of steps or a

transaction sequence used in system or
business process testing.

Systems Integration Test A project Task Dependency Network A network of
activity that consists of testing related tasks and task dependencies where
application systems using sequences or each node is a task and each link is a
scripts from two or more systems task dependency; see also CRITICAL
which interface. PATH METHOD (CPM) NETWORK.
Task Step A step within a task that may

T produce a deliverable component.
Table A tabular view of data, on a Technical Architecture The physical
relational database management hardware, network configuration, and
system, defined by one or more software tools that support the system
columns of data and a primary key. A architecture.
table populated by rows of data.
Technical Assistance Request (TAR)
Table Constraint A set of rules Oracle’s name for recorded problems.
constraining values in a combination of A TAR number is a unique number
one or more columns of a database assigned by WWSUP to track the
table. problem.
Tablespace A logical portion of a Technical Platform Architecture Setup
database used in allocating storage for rules, guidelines, and principles that
table data and table indexes. define the structure, functions, and
relationships among the hardware,
TAR see TECHNICAL ASSISTANCE REQUEST.
systems software, communications,
Target Application The primary set of and network facilities that act as the
new application modules that are technical foundation for the Business
within project scope.. Process, Information, and Application
Architectures. The Technical Platform
Task A unit of work that results in output Architecture specifies the common or
of a single deliverable. The most shared facilities and function of the
elementary unit of work, tasks, provide facilities needed to support the
the core of the work breakdown applications and data to meet the needs
structure. Each task produces one, and of the business. It supports such
only one, deliverable; see also WORK established principles as data, devices,
BREAKDOWN STRUCTURE. and location independence and formal
interfaces.
Task Dependency The relationship
between two tasks where the start or Technique A specific approach to
end date of the successor task is performing a task. A methodical
constrained by the start or end date of means of handling and communicating
the predecessor task. complex details.
Test Data Profile Specific test data values

for performing a test.

Test Environment A combination of Timebox A project management
software and possibly hardware that technique that a fixes the duration and
provides a stable environment in which resources of a task, or set of tasks, and
to test newly developed software forces the scope of the project to be
without elaborate preparation. A test adjusted based on the time available to
environment might provide test data, complete the task(s). The contingency
data structures, test scripts, automatic for under-estimation of the work is
test execution, test results recording, provided by a prioritized list of
and test results analysis. features left out if necessary. The
contingency for over-estimation is
Test Specification A set of steps or a provided by a prioritized list of
transaction sequence used in module, features that should be added in if time
module integration, system, systems allows.
integration, or entity testing.
Tool Software applications, deliverable
Test Scenario An instance of an event. A templates or any other utility suggested
point-in-time sample of the business to facilitate the completion of a
conditions and processing environment particular task.
to be tested. Each scenario may include
users working in multiple applications, Top-down Estimate A high-level work
performing online or batch processing effort estimate. This type of estimate is
being performed. derived by taking a total project
estimate and dividing it among the
Test Script A document consisting of a project’s phases, activities, and tasks.
test specification, a test data profile and
instructions for performing a test. Topical Essay A high-level illustration of
how to satisfy a business need. A
Test Sequence A series of test scripts, section of a design document that
ordered chronologically, for testing the specifies business needs, major
application system over time. features, terms, and processing
overview.
Third-generation Programming Language
(3GL) A programming language that Traceability The ability to trace an
uses procedural definitions to carry out application system component to its
tasks, and typically uses record-by- business requirement.
record processing of data. Procedural
3GL language structures include Train-the-Trainer An approach toward
if....then....else, do....while statements and training whereby inside resources take
others. ownership of delivering training to
their peers and associates..
Third-party Application Interface A
heterogeneous interface between Oracle Transaction Database A database used
Applications and the application primarily by transaction oriented
product of another vendor or an applications.
application developed ‘in-house’.

Transaction Interface An interface that User Review A meeting at which some of
transfers transaction data between the facilities of a system are
similar or dissimilar applications. demonstrated to and reviewed by user.
The objective of a user review is to
Trigger 1. A database object that executes elicit feedback on which to base future
PL/SQL code based on a change to a development and improvement of the
database table. 2. An Oracle Forms facilities being reviewed.
function that is executed based on an
event in the Forms environment. Utility A program or system facility that
performs a useful job for the users. It
U does not require the user to provide
any interaction other than perhaps
Uncontrolled Document A document initially requesting the utility; see also
which is produced once for information GENERATOR and TRANSFORMER.
only, and is not subject to formal
Utilization The amount of time a staff
approval or change control.
member books to a project accounting
Unique Identifier Any combination of system; see also BILLABLE UTILIZATION
attributes or relationships that serves, and NON-BILLABLE UTILIZATION.
in all cases, to uniquely identify an
occurrence of an entity. V
Unit Test see MODULE TEST. Vanilla 1. Standard or plain. 2. An ice
cream flavor.
Usability That quality of a system that
makes it easy to learn, easy to use and Variance The difference between a
encourages the user to regard the planned and an actual value; for
system as a positive help in getting the example, budgeted hours vs. actual
job done. hours.
User A person who uses a system to Version The rendering of a configuration

perform a business function. item which incorporates all of its
revisions starting from a given point.
User Preferences In many circumstances
in computer systems there may be Version Control A mechanism to manage
alternate ways a user can influence the multiple revisions of files, documents,
behavior of a utility, user interface, or programs, applications, or other items
other system process. Typically set by that undergo change.
adjusting values in a set of user
preferences; for example, in a program View A means of accessing a subset of
generator, preferences may be set for data in a database.
style, performance, user interface
behavior and code standards.

Workstep A step within a task that may
W produce a deliverable component.
Walkthrough Review of work in Worldwide Support (WWSUP) Oracle’s

progress, usually taking the form of a support Organization.
presentation by a developer to an
audience of stakeholders or fellow WWSUP see WORLDWIDE SUPPORT.
developers who are encouraged to
comment and ask questions. The
objective is to ensure that work is
proceeding in the right direction.
WBS see WORK BREAKDOWN STRUCTURE.
White Box Test A test of all or part of an

application system that requires
knowledge of the actual code being
tested. Module tests are usually white
box tests; see also BLACK BOX TEST.
Workaround A way to circumvent a

software problem.
Work Breakdown Structure (WBS) An

organization of project tasks into a
hierarchy for scheduling and reporting
progress.
Work Effort see EFFORT.
Work Estimate see ESTIMATE.
Work Schedule see PROJECT SCHEDULE.
Workshop 1. A meeting attended by

users and developers to create a plan,
specification or other documentation
that can guide the developers in their
development tasks. 2. A meeting
designed to facilitate interaction and
the exchange of information between
individuals or groups; see also
REQUIREMENTS WORKSHOP, SCOPING
WORKSHOP, and USER REVIEW.

FUNCNY functionality
Abbreviations HL high-level
HW hardware
ACCEPT acceptance
INFO information
ALT alternative
INIT initial
ANAL analysis
INT internal
APP application
INTERF interface
ARCH architecture
INTGN integration
ASSUMP assumption
LEVL level
BKP backup
LOC location
BLD build
MATX matrix
BUS business
MDU module data usage
CERT certificate
MECH mechanism
COND condition
MGMT management
CONFIG configuration
OPERL operational
CONSID consideration
PERF performance
CORR corrective
PM process model
CTRL control
PRELIM preliminary
CURR current
PROC procedure
DB database
PRODN production
DEFN definition
PROJ project
DELIV delivery
PRTZD prioritized
DESC description
QLTY quality
DESN design
RECOV recovery
DESRD desired
REQ requirement
DET detailed
RESPDNG responding
DEV development
REVD revised
DFD dataflow diagram
SPEC specification
DIAG diagram
ST state
DM data model
STD standard
DOCN documentation
STRTGY strategy
ENTY entity
STRUCT structure
ENV environment
SW software
EXG existing
SYS system
EXT external
TECHL technical
FEAT feature
TRANS transition
FH function hierarchy
FM function model
FOUNDN foundation
FUNCN function
FUNCNL functional

Aim - Oracle Application Implementation

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aim - Oracle Application Implementation

Uploaded by

Copyright:

Available Formats

ORACLE METHODSM

Enabling the Information Age™

T he Application Implementation Method Handbook provides an overview

This handbook contains the information needed by project managers,

This handbook, and the Application Implementation Method itself, are

Oracle Method Preface i

The Application Implementation Method Handbook is a high-level

How the Manual is Organized

This handbook consists of an overview of AIM, chapters on each AIM

Introduction: This chapter presents an overview of AIM and how to

Phase Chapters: Each phase chapter consists of a phase overview and a

• Objectives — describes the objectives of the phase

ii Preface AIM Method Handbook

• Tasks and Deliverables – lists the tasks executed and the

Appendix A: Appendix A provides a work breakdown structure for

Appendix B: Appendix B provides a description of the roles used in

Appendix C: Appendix C lists the roles used in AIM, the tasks

Appendix D: Appendix D provides the AIM data model, including

Glossary: The Glossary contains definitions of terms, abbreviations,

How to Use this Manual

The Application Implementation Method Handbook contains general

Oracle Method Preface iii

Several notational conventions are used to make this handbook easy to

Abbreviations and Acronyms

Suggestion: Verify your backup and recovery plan with your

Attention: Since project team training occurs simultaneously

For More Information

iv Preface AIM Method Handbook

Books in the AIM suite include:

• A Quick Tour of AIM

Each of these books and their relationships to each other is discussed in

• PJM Method Handbook

Oracle Method Preface v

Oracle Corporation values and appreciates your comments as an Oracle

Oracle Method - Application Implementation Group

For email inquiries use the following Internet address:

Please provide the following information:

• AIM user name

vi Preface AIM Method Handbook

CHAPTER 1 Introduction to AIM .................................................................................1-1

What is AIM? .............................................................................................1-2

Processes in AIM .......................................................................................1-3

AIM Project Phases.................................................................................. 1-10

Determining a Project Approach............................................................ 1-15

Managing an AIM Project ....................................................................... 1-31

CHAPTER 2 Definition ..................................................................................................2-1

Oracle Method Contents vii

CHAPTER 3 Operations Analysis................................................................................. 3-1

CHAPTER 4 Solution Design ........................................................................................ 4-1

viii Contents AIM Method Handbook

CHAPTER 5 Build ...........................................................................................................5-1

Oracle Method Contents ix

APPENDIX A AIM Work Breakdown Structure .......................................................... A-1

AIM Classic Approach Work Breakdown Structure ............................. A-2

APPENDIX B AIM Roles................................................................................................. B-1

APPENDIX C Role Usages .............................................................................................. C-1

Role Usages ............................................................................................... C-2

APPENDIX D AIM 2 Data Model...................................................................................D-1

Purpose and Objective of the Data Model.............................................. D-2

AIM Data Object Definitions ................................................................... D-4

x Contents AIM Method Handbook

T his chapter discusses the content and structure of Oracle’s

Business Requirements Definition