Technical Approach and Methodology

Oracle Unified Method (OUM)

The Oracle Unified Method (OUM) is Oracle’s standards-based method that enables the entire Enterprise
Information Technology (IT) lifecycle. OUM provides an implementation approach that is rapid, broadly
adaptive, and business-focused. OUM includes a comprehensive project management framework and
materials to support Oracle’s growing focus on enterprise-level IT strategy, architecture, and governance.
Oracle’s Global Methods team has packaged OUM to accelerate your IT projects. OUM presents an
organized, yet flexible, approach. Its defined, operational framework helps anticipate critical project needs
and dependencies. With OUM, you can move efficiently through the IT lifecycle to quickly realize
measurable business results.
OUM 6.3 will be used as the main method to manage the implementation of this project. However, OUM is
a flexible methodology, therefore, only relevant OUM activities and tasks will be carried out as per the
project plan that will be developed after the project’s kick off. As for documentation, OUM templates will
be used as much as possible. Nevertheless, documentation will be done to serve the purpose of its relevant
activity and task, even if it doesn’t completely comply with OUM templates.

Benefits of OUM
▪ More Focused Effort – OUM enables projects to clearly define business scope as well as the need to
create architectural models of the enterprise. This planning results in tighter scope control, more
accurate business understanding, and a firm foundation to align with client expectations.
▪ Built-in Flexibility – By combining activities and tasks in different ways, OUM can be applied to
many types of information technology software development and implementation projects.
▪ Saves Time – Seasoned information technology practitioners representing years of experience have
contributed their knowledge to OUM. Project teams to take advantage of this experience by
leveraging these leading practices along with industry standards.
▪ Higher Quality – OUM subscribes to an iterative approach that incorporates testing and validation
throughout the lifecycle, rather than testing for quality only at the end of the project.
▪ More Cost Effective – OUM facilitates improved control of project expenses by using a flexible work
breakdown structure that allows you to perform only necessary tasks.
▪ Reduced Project Risk – Implementing an iterative, broadly applicable method mitigates
requirements mismatch. A key focus of each iteration in OUM is to identify and reduce the most
significant project risks. This allows for the most critical risks to be addressed as early as possible in
the project lifecycle, which results in a measurable reduction of schedule and budget risks.

Project Phases for Control

Projects are delivered by phase, chronological grouping of tasks in an approach, in order to reduce risk.
Each phase allows a checkpoint against project goals and measurement against quality criteria.
OUM includes the following phases:
▪ Inception - The overriding goal of the Inception phase is to have concurrence among all
stakeholders on the lifecycle objectives for the project. Therefore, the Inception phase is critical for
all projects because the scope of the effort, high-level requirements, and significant risks must be
understood before the project can proceed.
 ▪ Elaboration - The goal of the Elaboration phase is to move development of the solution from the
scoping and high-level requirements done during the Inception phase to developing the detailed
requirements, partitioning the solution, creating any necessary prototypes, and baselining the
architecture of the system to provide a stable basis for the design and implementation effort in the
Construction phase.
▪ Construction - The goal of the Construction phase is to take the solution from detailed
requirements models, through configuration of standard packaged software functionality,
development and testing of custom components, and integration to a system that is ready for a
first release that goes into production, often a limited release and often called a beta release. In
short, complete the development of the application system, validate that all components fit
together, and prepare the system for the acceptance test and deployment.
▪ Transition - The goal of the Transition phase is to take the completed solution from installation
onto the production system through the acceptance test to launch of the live application, open,
and ready for business. Validate that the system is tested systematically and is available for end
users. During this phase, the new system is accepted by the client organization, the organization is
made ready for the new system, and the system is put into production and, if the new system
replaces an old one, a smooth cutover to the new application is provided.
▪ Production - The goal of the Production phase is to operate the newly developed system, assess
the success of the system, and monitor and address system issues. This includes monitoring the
system and acting appropriately to maintain continued operation; measuring system performance;
operating and maintaining supporting systems; responding to help requests, error reports and
feature requests by users; and managing the applicable change control process so that defects and
new features may be prioritized and assigned to future releases and put into a plan for future
enhancements to the application system, as well as determining, developing, and implementing
required updates.

Confidential Document 1
Implementing an OUM Project
The Implement focus area provides a framework to develop and implement Oracle-based business
solutions. OUM uses project phases and processes to include quality and control checkpoints and allow
coordination of project activities throughout the project. During a project phase, the project team executes
tasks in several processes.
Project Processes for Continuity
All OUM tasks are also organized into processes that group related tasks together. Project team members
are assigned to these groupings according to their specialization and background. OUM includes the
following processes.
Business Requirements
In the Business Requirements process, you define the business needs of the application system. The
business requirements for the proposed system or new enhancements are identified, refined, and
prioritized by a tightly integrated team of empowered ambassador users and experienced analysts. The
process often begins from an existing high-level requirements document and a scope document, such as
the Project Management Plan. However, it is possible to begin from an agreed on scope and objectives
before requirements have been defined. The Business Requirements process delivers a set of requirements
models and a prioritized list of requirements as a basis for system development. Both the models and
requirements list are dynamic and may change as the understanding of the team develops with the system.
The main outputs of this process are the business objectives and goals, the list of functional requirements,
and the supplemental requirements.
Requirements Analysis

Confidential Document 2
In the Requirements Analysis process, the functional and supplemental requirements identified and
prioritized during the Business Requirements process are analyzed further into a Use Case Model that is
further refined by adding use case details in order to establish a more precise understanding of the
requirements. The Use Case Model is used as the basis for the solution development. This process helps
provide structure and shape to the entire solution. The Use Case Model is used to document in detail the
requirements of the system in a format that both the client and the developers of the system can easily
understand. The main outputs of this process are the Use Case Model, a prototype of the user interface,
and a high-level description of the software architecture.
Mapping and Configuration
In the Mapping and Configuration process, the key business data structures and associated values are
defined and established within a prototype environment. The business requirements are assessed and
mapped to the standard application and system features. A prototype environment is updated with
detailed setup parameters and an iterative series of workshops are conducted in order to validate that the
prototype aligns with the business requirements. Resolutions to any gaps between the business
requirements and the standard application features and functions are defined, along with the
documentation of detailed setup parameters. The main outputs of this process are the Application Setups
and the Validated Configuration.
Analysis
During the Analysis process, the captured requirements are analyzed and mapped onto the chosen
commercial-offthe-shelf (COTS) product set, if any, to ascertain which requirements can be met directly by
configuring the product’s capabilities and which requirements will require extending the product
capabilities through the development of custom application software or custom extensions. Beyond
product mapping, the purpose of Analysis is to refine and structure the requirements via a conceptual
object model, called the Analysis Model. Most simply put, the Analysis Model is the collection of all of the
analysis related artifacts, just as the Use Case Model documents the system’s functional requirements. The
Analysis Model provides a more precise understanding of the requirements and provides details on the
internals of the system. The Analysis Model is described using the language of the developers as opposed
to the requirements obtained in the Business Requirements and Requirements Analysis processes where
the emphasis is on the functionality of the system expressed in the language of the client. Thus, it
contributes to a sound and stable architecture and facilitates an in-depth understanding of the
requirements. Many of the outputs produced during the Analysis process describe the dynamics of the
system as opposed to the static structure. The Analysis Model is also considered the first cut of the Design
Model, since it contains the analysis classes that will be further detailed during the Design process. The
main output of the Analysis process is the Reviewed Analysis Model that includes a set of analysis classes
(class diagrams) that realize the use cases. In addition, new software architecture views are added to the
architecture description initially developed in the Business Requirements process and further enhanced in
the Requirements Analysis process.
Design
In the Design process, the system is shaped and formed to align with all functional and supplemental
requirements. This form is based on the architecture created and stabilized during the Analysis process.
Design is the focus during the end of the Elaboration phase and the beginning of Construction iterations.
The major outputs created in this process ultimately combine to form the Design Model that is used during
the Implementation process. The Design Model can be used to visualize the implementation of the system.
The main output of this process is the Reviewed Design Model that includes an object model that describes
the design realization of the use cases and design classes that detail the analysis classes outlined in the
Analysis Model.
Implementation
Through a number of steps, mostly iterative, the final application is developed within the Implementation
process. The results from the Design process are used to implement the system in terms of source code for
components, scripts, executables, etc. During this process, developers also implement and perform testing
on software components. Implementation is the main focus of the Construction phase, but it starts early in
Confidential Document 3
the Inception phase in order to implement the architecture baseline (trial architecture and prototype).
During Transition, it occurs in order to handle any defects or bugs discovered while testing and releasing
the system. The main output of this process is the final iteration build that is ready to be tested.
Testing
The Testing process is an integrated approach to testing the quality and conformance of all elements of the
new system. Therefore, it is closely related to the review tasks in the Quality Management process of
OUM’s Manage focus area and to the definition and refinement of requirements in the Business
Requirements process. It addresses mainly functional testing; however, it also includes systems integration
testing for projects with requirements for interfaces to external systems.
Testing activities are a shared responsibility of developers, quality assurance engineers, and ambassador
users, working together as an integrated project team. The Testing process presupposes that there is a
highly visible user interface from which system events can be driven and results validated. The higher
proportion of artifacts that are visible to the ambassador users (for example, user interfaces and reports)
the more they will be able to participate in the Testing process.
Performance Management
The objective of the Performance Management process is to proactively define, construct, and execute an
effective approach to managing performance throughout the project implementation lifecycle in order to
validate that the performance of the system or system components is aligned with the user's requirements
and expectations when the system is implemented. Performance Management is not limited to conducting
a performance test or an isolated tuning exercise, although both those activities may be part of the overall
Performance Management strategy. The requirements that drive Performance Management also impact
Technical Architecture and the two processes are closely related.
Technical Architecture
The goal of the Technical Architecture process is to design an information systems architecture to support
and realize the business vision. The tasks in the Technical Architecture process identify and document the
requirements related to the establishment and maintenance of the application and technical infrastructure
environment for the project. Processes and procedures required to implement, monitor and maintain the
various environments are established and tested.
Data Acquisition and Conversion
The objective of the Data Acquisition and Conversion process is to create the components necessary to
extract, transform, transport and load the legacy source data to accommodate the information needs of
the new system. The data that will be converted is explicitly defined, along with its sources. This data may
be needed for system testing, training, and acceptance testing as well as for production. In some cases, it is
beneficial to convert (some) data at earlier stages to provide as realistic as possible reviews of the
components during the development iterations.
Documentation
Quality documentation is a key factor in supporting the transition to production, gaining user acceptance,
and maintaining the ongoing business process. The requirements and strategy for this process vary based
on project scope, technology, and requirements. For projects that include Oracle Application products, the
Oracle Application manuals are the foundation of implementation documentation. The Documentation
process includes development of documentation to augment the standard Oracle Application products
manuals with specific information about the organization's custom software extensions and specific
business procedures.

Organizational Change Management

The Organizational Change Management process starts at the strategic level with executives and then
identifies the particular human and organizational challenges of the technology implementation in order to
design a systematic, time-sensitive, and cost-effective approach to lowering risk that is tailored to each

Confidential Document 4
organization’s specific needs. In addition to increasing user adoption rates, carefully planning for and
managing change in this way allows organizations to maintain productivity through often-difficult
technological transitions. This in turn enables the organization to more easily meet deadlines, realize
business objectives, and maximize return on investment.
Training
The objectives of the Training process are to make sure that the project team is adequately trained to begin
the tasks necessary to start the project and the users are adequately trained to take on the tasks of running
the new application system.
Transition
The goal of the Transition process is to install the solution, which includes providing installation procedures,
and then take it into production. This process begins early in the project by defining the specific
requirements for cutover to the new application system. It then includes tasks to carry out the elements of
that strategy such as developing an installation plan, preparing the production environment, performing
the cutover, and decommissioning any legacy systems.
Operations and Support
The goals of the Operations and Support process are to monitor and respond to system problems; upgrade
the application to fix errors and performance problems; evaluate the system in production; and plan
enhancements for increased functionality, improved performance, and tighter security. The development
project does not come to an abrupt end when the team installs the application system into production. In
fact, the months following that milestone can determine the real success or failure of the project. Internal
auditors have not yet produced the system evaluation, and users most likely still have a few problems to
uncover. There are certain to be requirements with lower priorities that have not been implemented. The
‘could have’ requirements and any remaining ‘should have’ can now be re-prioritized into an enhancement
plan, from which upgrades can be defined.

High-Level Project Plan and Milestones

A detailed project plan will be developed during the project’s initiation of the relevant phase which will set
the target dates of tasks, activities, and milestones completion, hence a target Go Live date for the phase.
The below depicts a high-level project schedule and milestones
Project Initiation
Project Kick Off
Project Plan
Project Charter
Inception Phase
Current Process Model
Future Process Model
Present and Future Organization Structures
Data Acquisition and Conversion Requirements
Elaboration Phase
System and Integration Design
Conference Room Pilot 1
Reports Fit Analysis
Functional Security
Construction Phase
Data Mapping
Reports Development
Integration Development
Confidential Document 5
 Conference Room Pilot 2
Document System Setup
User Guides Development
Cutoff Strategy
Transition Phase
Training and Knowledge Transfer
User Acceptance Test
Production
Master Data Migration
Go Live
Operations and Support

Deliverables Review and Acceptance Procedure

▪ Customer’s Project Manager and key users will make all reasonable endeavors to complete the
review of documents and deliverables in accordance with the agreed upon project workplan.
However, the following time frame will prevail.
1st Review 2nd and Final Review
3 working days 1 working days
▪ The requirement for more review of a deliverable or document will include the reasons of that and
the parts of the documents that needs further review and modification
▪ If after the periods specified above, there is no communication from reviewers, either approving or
requiring further review, documents and/or deliverables will be considered approved (Deemed
Accepted)
▪ Every change to an approved document will be considered as Requests for Change and has to
follow a change request procedure

Project Team Structure

The following structure illustrates the project team’s organization structure

Confidential Document 6
Confidential Document 7
Project Team’s Credentials
The following table describes project team’s credentials in terms of minimum relevant years of experience
in successful implementation of Oracle projects in the past 5 years of their professional experience.

Project Manager
Number of Resources 1
Minimum Relevant Experience 5 Years
Minimum Education Level Bachelor’s Degree
Functional Consultants - Oracle
Number of Resources 6
Minimum Relevant Experience 5 Years
Minimum Education Level Bachelor’s Degree
Technical Consultant - Oracle
Number of Resources 1
Minimum Relevant Experience 5 Years
Minimum Education Level Bachelor’s Degree
Oracle DBA
Number of Resources 1
Minimum Relevant Experience 5 Years
Minimum Education Level Bachelor’s Degree
Developer
Number of Resources 1
Minimum Relevant Experience 5 Years
Minimum Education Level Bachelor’s Degree

Mobilization Period
A mobilization period of 2-5 weeks is required from the date of contract signature to the project’s kick off.

Confidential Document 8
Knowledge Transfer
Hands-on training will be conducted one time in one session, after the training material is developed and
before the User Acceptance Test. Trainees are Key Executives, key users, End Users, and System
Administrators. Each session will have a maximum number of 10 attendees. The table below describes the
working days requirement for each course.

Item Description Key Executives Key Users End Users IT Admin

Financial 1 10 10 -

Inventory 1 3 3 -

Purchasing 1 3 3 -

Order Management 1 3 3 -

Sales Cloud 1 3 3

System Administration - - - 6

Database Administration - - - 4

Application Development - - - 4

Landed Cost - 2 2 -

Sourcing 1 2 2 -

Discrete Manufacturing 1 2 2 -

iSupplier Portal 1 2 2 -

Project Costing 1 2 2 -

Project Planning and Control 1 2 2 -

Hyperion Planning Plus 1 4 4 -

Marketing Cloud 1 2 2 -

Service Cloud 1 2 2 -

Hyperion Administration - - - 3

Attendees Prerequisite Skills

▪ Understanding of the basic Internet concepts

▪ Experience using a Web browser
▪ Functional skills of Windows operating system

Confidential Document 9
Confidential Document 10
User Acceptance Test
User Acceptance Test (UAT) is conducted to ensure that the system operates successfully based on design
specifications. Once UAT is successfully completed and accepted then the system acceptance certificate will
be issued.

UAT will take place in the transition phase by the customer’s key users. Key users will perform the UAT after
they receive their user system training. Test scenarios that cover real-life functional cases will be prepared
before the UAT. Then the UAT will take place on a stable (golden) version of the system on the Test
Environment. The Testing Team will use a representative subset of known data and transaction types to
evaluate Oracle EBS application functionality.

Test Issue Log

A testing management log will be implemented, which organizes and tracks issues. This will provide the
whole project with a single set of results against the agreed test scripts for testing sign-off. The log will also
provide status of the fault resolution.

Issues Documentation
Each discrepancy between system test results and expected results will be documented as an issue and
referenced by an issue number. All issues must be logged in the issue log Sheet with its details and severity

Issues Resolution
Our project manager or relevant consultant will assign and route all issues to a technical or functional team
member(s) or he will provide feedback for issues where only explanation or clarification is required. Upon
resolving the issue, the assignee must update the issue log sheet to denote that the issue solution is ready
for retesting. The proper resource will determine that the system test cycle or a portion of the system test
cycle should be re-executed to validate the issue resolution.

Issues Categories
Priority Fault Category Description
1 Complete Loss of Service ▪ Block format, corruptions, invalid index entries, corruption of
meta-data, incorrect results returned
Priority 1 should be
assigned when an ▪ System process hangs indefinitely
application defect causes ▪ System Crashes Repeatedly
complete loss of service, so ▪ Critical Functionality not Available
that the customer cannot
use the application ▪ Application Produces Incorrect Output
▪ Application Fails to Update Database
▪ Existing saved state (for example, an Oracle Form, Report,
Display or Library) is lost or corrupted without warning while
using the product.
▪ The execution or the installation of an application damages
the environment so that the application or other applications
do not run under any circumstances
2 Severe Loss of Service ▪ Internal system error, causing system to fail. Restart or
recovery is possible
Priority 2 should be
assigned when a product ▪ Severely degraded performance due to system error.
defect causes an internal ▪ Important functionality is unavailable, but system continues

Confidential Document 11
 system error, or incorrect to operate.
behavior causing severe
▪ New work cannot be saved.
loss of service. No
workaround is available ▪ A crash or hang results in loss of unsaved work (but no
that is acceptable to the damage to saved state).
customer, and restricted ▪ Application hangs, requiring system reboot or application
operation continues termination through the operating system
▪ Unacceptable visual behavior or unusual appearance of a
software function at runtime
3 Minimal Loss of Service ▪ System error, for which there is an acceptable customer
workaround.
Priority 3 should be
assigned when an ▪ System error or incorrect behavior with minor impact to
application defect causes operation of system.
minimal loss of service, or ▪ System error requiring manual editing of configuration or
the impact of the script files to work around a problem.
application defect is a ▪ A feature of the interface does not work as documented, but
minor inconvenience (such the software provides another way to use the feature.
as a manual bypass to
restore product ▪ The visual appearance of the screen appears to become
functionality) corrupted, but can be restored in the same session with a
refresh, re-sizing the window, or other GUI operations.
▪ Undesirable visual behavior or appearance of system
function. The behavior or appearance does not affect
software usability or occurs in an infrequently used aspect of
the software.
4 Minor Error, No loss of ▪ Product defect causes no loss of service. The defect is a
Service minor error, incorrect behavior or documentation error that
in no way impedes the operation of the system.

User Acceptance Criteria

User Acceptance Testing will be for the purpose of obtaining sign-off and the issuance of System
Acceptance Certificate by the customer. Customer key users will perform all the User Acceptance Testing
using defined Business Scenarios built into the test scripts to ensure that complete tests are performed.
The business owner will be asked to sign-off the UAT indicating that there were no critical problems with
the operation of the System.
Unit and integration tests will not be considered complete and successful until the following criteria have
been met:
▪ Resolution of all Issues with priority 1 and 2 logged during the UAT milestone. Issues classification
will follow the criteria set above in this chapter of the Project plan. Issues will be logged by
customer’s key users and sent to us for resolution.
▪ All issues with priority 3 and 4 will be schedules for resolution after the UAT.

Confidential Document 12
Assumptions & Conditions
This section lists the assumptions and conditions that our proposal was built based on. Customer and all
involving parties have to conform to these assumptions and conditions in order for our proposal to be valid.
▪ The system setup and configuration is unified across all the customer’s business units
▪ The vendors or implementers of the systems with which our system will integrate will provide full
support from their side to ensure the integration is successful
▪ Test, Development, and Production environments will be made available and ready by the
customer in a timely manner according to the project plan
▪ Customer will provide work space and meeting rooms, equipped with Personal Computers and
Internet access for the project team, where they can either work on the customer’s PCs or their
own personal computers
▪ Customer will provide training rooms to carry out the training activities mentioned in this proposal
▪ Customer will designate knowledgeable and dedicated resources during all project phases in their
specific areas. Those resources are called Key Users. These Key Users will work closely with our
team and they will be part of the project team. Customer key-user team will be available in
Amman-Jordan during the whole duration of the project except for the government holidays
▪ All project deliverables will be submitted in English only

Confidential Document 13