The Oracle Aerospace & Defense Solution

Order Management for

Spares and Repair Orders




Order Management Spares and Repair Orders
Introduction

In the Aerospace and Defense industry, the major OEMs and their top tier of subcontractors have
developed an infrastructure and set of procedures to deal with low volume, high dollar value, and high
complexity contracts. These practices served well in the past, but there are several sets of industry
pressures that are forcing A&D companies to rethink many aspects of their business.

There are increasing industry and governmental pressures to make the acquisition of these
contracts, and their subsequent administration and execution, much more efficient. Fixed
price contracts are becoming the norm, and commercial practices such as lean manufacturing
are being examined for their applicability to A&D.
The increasing importance of subcontractors for major portions of the systems not just
manufacturing, but also design calls for the use of emerging collaboration tools.
The ever-increasing complexity of the sum total of all contract and subcontract
documentation mandates the implementation of new, integrated, workflow driven Contract
Administration systems.

As significant as these challenges are, many A&D firms have added the additional daunting task of
adapting to a high volume, low dollar value environment for a significant portion of their business.
The driving force behind this shift is that A&D firms are looking to aftermarket spares and services
business, as these areas offer increased margins and a total potential revenue stream that exceeds the
original product contract values. However, the administration and execution procedures that are
needed for this type of business are far different than those that are in place for large program
administration.

Oracle Applications have been significantly enhanced over the past few years to address these issues.
2
Order Management Spares and Repair Orders
Business Requirements
In order to realize the potentially high margins of this area, each spares and repair order must be
processed very efficiently, with as much automation as possible. Although these orders share many of
the basic processes with large orders, the number of manual touch points can be significantly
reduced. Where a manual intervention into the process is needed, it must be made more efficient
through the use of automated workflows.

There are several sub-processes in the overall Order to Cash process that need particular attention for
the spares and repair segment of the business.

Entry of Orders - EDI
The system must be able to support both EDI receipts of orders as well as manual entry. The EDI
system should directly feed the orders into the Order Management system without manual
intervention. User defined validations can be defined so that improperly formatted orders, or those
with missing data, are rejected. The system should provide a listing of all orders entered through EDI,
as well as an exception report of rejected orders.

Entry of Orders Manual Entry
Manually entered orders shall be made more efficient by storing order profiles, either by order type or
customer, that will provide defaults for many of the data fields of the order, such as terms and
conditions, the price list to use, shipping method, etc.

Order Processing after Receipt
After the orders are received via EDI or entered manually, the system must support a flexible
workflow that will enable subsequent processing booking, approvals, interface to demand
processing, special holds for various conditions, and interfaces to legacy systems must all be handled
automatically. Approval processes should be executed via workflow, with audit trails kept of all
transactions.

Shipping and Government Documentation
A flexible picking/packing system should notify the warehouse(s) of all orders that are ready to pick
and guide the picking and packing processes in an efficient manner. Although these processes are
often carried out manually, the system should support current bar code and mobile RF technologies
for those instances where the order volume warrants the application of these devices.

The system should print a wide variety of documents to support these processes, including pick lists,
packing lists, commercial invoices, and shipping labels. The process shall be flexible and able to
accommodate user written documents, as well as an interface to third party software to produce
specialized documents such as DD250s.

Inventory Interface
The picking process shall reserve the inventory items to the order, preventing their issue from
inventory for any other purpose. After the shipment is confirmed, the inventory system shall
automatically be decremented. This interface shall operate with either Oracle Inventory or a legacy
system.
3
Order Management Spares and Repair Orders

Outbound EDI Transaction Support
A variety of outbound EDI transactions, including ASNs and Invoices must be supported by the
system. The EDI system shall be fed the data automatically based on the workflow associated with
the order line.

Accounts Receivable Interface
Invoicing data shall be transferred automatically to the accounts receivable system, whether it is
Oracle Accounts Receivable or a legacy system.

4
Order Management Spares and Repair Orders
The Oracle Solution
The diagram below outlines the major processes involved and the subsequent text describes how
Oracle applications can be used to achieve the goals stated above. This diagram addresses spares
orders processes, but is also applicable to repair orders. The additional steps involved for repair orders
will be detailed in the next section of this paper.

Although a primary criteria in the design of this solution was to achieve a great deal of automation, it
was also realized that the processing of large quantities of small orders is new to most A&D
contractors, and as a result, some elements of automation have been left out of the solution described
herein in order to keep the level of complexity reasonable and to make the solution easier to
implement. After a stable implementation is achieved, additional features can be added to further
enhance the operational efficiency. These future possibilities are described later in this paper.


EDI
Order
(850)
Oracle
EDI Gateway
Oracle Order
Management
Oracle
Shipping
Oracle
Inventory
Legacy
Inventory
(if required)
Print
Shipping Docs
(DD250 and others)
Oracle
EDI Gateway
EDI
Invoice
(810)
Oracle or
Legacy Accounts
Receivable
Non-EDI
Order
Maintain Master
Contracts
Figure 1 - Spares Order Processing



EDI Orders and the Oracle EDI Gateway
EDI orders assuming X.12 850 formatted transactions enter the system through the users EDI
translation software. This can be a translator from any of the leading vendors. The translated data is
then sent through the Oracle EDI gateway, which will populate the Oracle Order Management system
with a new order. Each EDI transaction will result in a new order, but since these orders are
5
Order Management Spares and Repair Orders
processed automatically from start to finish, there is no added transaction burden. The EDI Gateway
applies all the rules that are set up in Order Management to govern the manual entry of orders and
orders that fail one or more of the tests are rejected. The appropriate Order Management personnel
are notified of the reasons for rejection, and after resolution, the orders can be reprocessed through the
gateway.

If the incoming 850 transaction (and corresponding change orders) reflect the Contract in place
between the user and their customer, Oracle offers a convenient way of grouping these orders and
reporting against them as a whole.

Master Contracts
Complex master contracts that govern these spare and MRO orders can be maintained in Project
Contracts, but the Deliverable Tracking System will not be used. Only the terms and conditions,
correspondence, and other general documentation will be stored in Project Contracts. Corresponding
to the Contract will be an Agreement in Order Management that will handle such items as the proper
price list to use. If the master contracts tend to be relatively simple, the use of Oracle Project
Contracts can be deferred to a later stage of the implementation.

Non-EDI Orders
Orders that come from customers via phone, paper or fax can be entered in one of two ways. If the
volume is small, or if the terms and conditions change from order to order, each incoming order will
be entered into Order Management (OM) as a separate order. If there are many releases against a
master order, then a single order in OM can be setup and each incoming order simply added as a new
line.

In either case, Oracle Order Management provides Available to Promise (ATP) information based
upon inventory levels and lead times.

Order Management
Oracle Order Management is a mature product that was substantially rewritten in Release 11i to
provide users with a far greater degree of flexibility than any other order management system. Every
order line has a unique workflow associated with it, so that the appropriate approvals, holds,
documentation, shipping and billing processes are automatically carried out. Although this does
require some setup work, the setup is done only once and substantial savings result from the ensuing
automation of downstream activities.

Order Management can be performed in a centralized manner, even if the inventories are disbursed in
warehouses around the world. Alternatively, orders can be entered locally against inventory that is
either local or centralized.

Order Management provides a number of analytical reports that will assist users in the management of
this increasingly important segment of their business.

6
Order Management Spares and Repair Orders
Shipping
All shipping will be handled using Oracle Shipping. Shipping automatically decrements balances
held in Oracle Inventory, so if this module is not yet live, balances must be transferred from a legacy
system. Oracle Open Interfaces and APIs support this type of import.

EDI Gateway and Outbound EDI transactions
Since each order line can have a separate workflow associated with it, it will be easy to cause
outbound EDI transactions to be generated. Shipping notices and invoices can be sent through the
Oracle EDI gateway.

Shipping Documentation and Government forms
Oracle Shipping supplies a wide assortment of shipping documentation including pick lists, packing
lists, and commercial invoices. These document sets are user definable, and each type of order line
can be associated to the appropriate document set. These sets can be augmented with user written
documents. Also, the workflow associated with an order line can cause the appropriate data to be sent
to a third party product. Oracle partners with MilPac to print government documentation such as
DD250s (which can also be sent electronically).

Accounts Receivable Interfaces
If Oracle Accounts Receivable is live, then there will be a direct feed to that module. If Oracle A/R is
not used, the output from Shipping can be directed to a legacy Accounts Receivable system.

Inventory Interfaces
The Order Management and Shipping systems depend on accurate and timely inventory data being
present in the Oracle Inventory system. If Oracle Inventory is not in live operation, Oracle provides
Application Program Interfaces (APIs) and interface tables that facilitate the synchronization of
Oracle Inventory with any legacy system.
7
Order Management Spares and Repair Orders
Repair Order Processing
Most of the above descriptions also apply to Repair Orders. However, these orders go through several
additional steps as described below.

Manufacturing Interface
If Oracle Manufacturing is in use, the processes needed to automatically create the repair work orders
are available. If a legacy manufacturing system is being used, the order line workflow can trigger a
custom interface to that system.

Capable to Promise
If Oracle Manufacturing is being used, Capable to Promise (CTP) checks can be done to see if there is
sufficient manufacturing capacity to execute the repairs. This, of course, would depend on setting up
routings for various types of repair operations.

Warehousing Parts in Different Conditions
In a repair environment, it is critical to be able to distinguish a new part from one that has been
returned, that may be repairable, that has been refurbished, or one that cannot be repaired. Oracle
Inventory has the flexibility to segregate these types of parts without requiring the user to assign
different part numbers to show part condition.

Considerable additional capabilities for handling parts in different conditions are added by Oracle
Warehouse Management and those users, who have a high volume of repair parts that require
sophisticated handling and management, should consider this module.

8
Order Management Spares and Repair Orders
Future Possibilities
The above solution has deliberately been kept straightforward and relatively easy to implement. After
Order Management has been successfully implemented and is stable in its day to day operations, there
are several areas that can be considered to further enhance the operations and provide either increased
automation or improved management analytical capabilities.

Additional EDI Capabilities
EDI releases against a contract can be supported with current Oracle software. Functionality is
provided to enable the user to keep track of actual releases vs. the forecasted quantities and to monitor
the quantities remaining to be shipped on each order line.

In order for this functionality to be effective, the customer must first send a forecast of demand to the
users system. These forecasts are generally not yet available from the government and certainly not
in EDI format. When these forecasts for spare parts are generated by agencies like the Defense
Logistics Agency (DLA), it will be very easy for users to add Release Processing functionality to their
system.

Blanket Orders
Oracle Order Management is also adding functionality to better manage blanket orders. This will
probably be of great benefit to the user who has a mature Oracle Order Management system working
well and is ready for the next steps in automation and order management. Specifications for these
capabilities have been developed, but a date for their incorporation into a future release is not yet
available.

Advanced Billing Capabilities
The use of Oracle Project Billing can be investigated for those cases where spares and/or repair orders
are received against a master contract.

Forecasting and Planning
As a history of spares usage and/or repair frequency is developed, forecasting and planning tools from
Oracle can be added that will enable inventories to be reduced and customer responsiveness
improved.

Inventory Optimization
It is a common practice to set spare parts inventory levels based upon demand variability and the
desired service levels. However, there are other factors that should be considered in the spares
planning process: Not only does demand vary, but also the quantity of supply. Similarly, the lead-
time of the supplies exhibits variability. When the spare parts are assemblies, the user must determine
at what level of assembly the spares should be stocked and, if there is a distribution network involved,
it must be decided where to stock the spares.

Oracle Inventory Optimization, a part of the Advanced Planning and Scheduling suite, is the only
system available today that can simultaneously address all the above issues in a single, holistic
planning process.

9
Order Management Spares and Repair Orders

Additional Interfaces with Project Contracts
As more and more members of the Project Contracts Customer Advisory Board (CAB) use both Order
Management and Project Contracts, the CAB will suggest additional integrations between the two
products.
10
Order Management Spares and Repair Orders
11

Conclusions
Oracle Applications centered on Oracle Order Management can be used to effectively enable an
Aerospace and Defense company to move into the profitable arena of aftermarket service. This can
be done in a phased approach that minimizes disruption and facilitates the change management
process. After each increment of functionality is introduced, stabilized, and benefits are being
realized, further functionality can be evaluated and implemented without disturbing the features and
processes already in place.


3-12/12/02