An Analysis of Oracle Order to Cash Implementations

July 20th, 2006

Introduction

The Diebold and Stryker projects are both representative of the large-scale, global Oracle implementations for Deloitte Consulting.   As leading manufacturers within their respective industries, unique requirements would need to be met that would test the limitations of the Order to Cash (OTC) process from a functional, technical, and performance prospective.   The Order Management module, a major hub to the OTC process in Oracle, was one of the more challenging modules to implement for both projects.  

This will not serve as a critique, but will simply report on the similarities and differences of the OTC implementations for both Diebold and Stryker Orthopaedics.   We will briefly compare the global Order to Cash business requirements for both clients and discuss the solutions and enhancements provided by Deloitte Consulting to satisfy these requirements.

Background

Diebold, a leading manufacturer of automated self-service transactional systems and electronic security, was looking to Oracle to consolidate its global operations in the Americas, Asia-Pacific, Europe, Middle East and Africa.   Much of its operations had recently been acquired and had been operating independently of the US operations.   With this kind of corporate structure, it was impossible for Diebold leadership to get a financial snapshot of its global operations from sales, marketing, and production prospective.   With the help of Deloitte Consulting, Diebold established a global business process to be followed by all divisions of the company, particularly sales and cash management.   This global process was then translated to Oracle design and implemented as a single global instance, serving as the central source of information for global Diebold operations.   Currently, Diebold’s EMEA, Australia, and Mexico sales facilities are live, with Latin America, China, and their US operations remaining.

Much like Diebold, Stryker Orthopaedics, a leading orthapaedic implant and health equipment provider, also wanted to consolidate its global operations.   With four manufacturing plants in the US and Europe, Stryker was operating three separate ERP systems across its facilities – making the overall outlook of its global operations difficult to foresee.   Deloitte Consulting and Stryker would team together to consolidate its IT infrastructure into a single global instance of Oracle.   With a global implementation planned for 2006, Stryker hopes to establish a concrete platform for company growth, reduce the use of redundant and inefficient systems, establish a common business process across all business units, and better adhere to Sarbanes-Oxley compliance laws.

OTC Implementation Approaches

Diebold

Deloitte Consulting and Diebold would adopt a phased approach, where Diebold would first implement all sales and distribution offices prior to its manufacturing facilities.   There were several reasons why Diebold chose to implement its sales and distribution facilities first.   Firstly, the self service products manufactured consisted of very complex configurations that required complex item creation and manufacturing processes.   In comparison to the manufacturing implementation, the efforts to implement Diebold’s sales and distribution services were seen as a lesser challenge.   Secondly, as implementation efforts for their sales locations would go underway, Diebold could work concurrently on finalizing their item creation and manufacturing processes with the intentions of finalizing these processes once all sales and distribution divisions were fully implemented.

From an OTC prospective, this approach essentially created a two-step implementation effort.   With Diebold’s sales divisions fully implemented (online) and their manufacturing facilities remaining (offline), this would mean that sales and distribution facilities on Oracle would treat the manufacturing facilities not yet implemented as a third party vendor rather than an internal manufacturing facility.   This meant that during the period, purchase orders would be issued from Oracle to the manufacturing facilities (rather than internal requisitions) for product orders placed through the sales offices that needed to be fulfilled by manufacturing.     To meet this requirement, the SO/PO (Sales Order to Purchase Order) process was utilized.   In this process, product entered on a sales order that was sourced from a manufacturing facility would automatically generate a purchase order.   The paper purchase order would then be issued to the

manufacturing plant for the product.   Once the sales office receives product from the manufacturing plant against the Oracle purchase order, the received inventory would automatically be reserved against the sales order.

However, once the manufacturing facilities are fully implemented this scenario will change.   No longer are the manufacturing facilities considered outside vendors, but are now setup as internal organizations in Oracle.   This in turn means that purchase orders will no longer be issued and that internal requisitions would be created in Oracle to fulfill the demand for manufactured products.   The process of creating the customer sales order, issuing an internal requisition, and triggering an internal sales order in the manufacturing plant would spawn another Diebold customization that would streamline this process further than the seeded Oracle IR/ISO processes in place.   We’ll discuss this customization in greater detail later in this document.
 
One of several reasons why Diebold decided on Oracle was the Oracle Configurator module, which based on bills of materials (BOM) and a set of rules, product could essentially be “built” and configured during order entry by sales representatives without any engineering knowledge.   The functionality of the configurator was perfect for the nature Diebold’s self-service banking products – where each self-service product was custom configured to meet the specifications of each of their clients.   Implementing the configurator module would enable sales representatives to easily configure the BOM interactively for the ATM products sold without the consultation of Diebold engineers.

While the configurator module was definitely an excellent addition to the Diebold order entry process, performance issues would arise during data entry for models that consisted of extremely large bill of materials.   For example, a particular product, depending on the configurations available, could contain up to 100+ sub-lines on a sales order.   On a typical sales order for this product, 200+ units could be sold.   And due to the customer requirements, each of these units needs to be shipped to a different customer location, which would require splitting each of the 200 units as a separate line item on the order – which in itself was time consuming.   But also resulting from this, a sales order could have up to 20,000 order lines (100 sub lines x 200 units).   In performance testing this scenario, it was discovered that ATP scheduling high volumes order lines led to severe delays in the order booking process that could take up to 2 hours for the booking process to fully complete.  

With up to 20,000 lines that needed to be scheduled on an order, there was really no way to speed up the process to be an immediate step of order entry.   And as a result, the decision was made to move scheduling from the foreground of the booking process to the background as a concurrent job.   Instead of having scheduling executed at booking, which caused a system hang up of for several hours, the concurrent process would be executed on a regular basis to schedule all high-volume orders.   Although this doesn’t necessarily speed up the scheduling process, it does free up the system to allow the user to navigate and perform other tasks.

The Order to Cash implementation effort for Diebold has proven to be a success despite the challenges posed by the business and the technology.   With Europe, Australia, and Mexico sales forces fully live on Oracle, this should provide the forward momentum needed to implement the rest of Diebold’s global operations for the 2006 and 2007 years.

Stryker

Similarly, Stryker would also adopt a phased implementation effort with a slight difference.   Stryker would instead implement their US operations entirely which consisted of both manufacturing and field sales offices.   Once all manufacturing and field divisions in the US are fully implemented, Stryker plans gradually move to its European facilities to implement the Oracle ERP solution.

Like Diebold, this will potentially create a two-phased implementation effort in OTC.   Once the Stryker US operations go live and the European facilities are awaiting implementation, internal sales going both directions between the European and US facilities would be done through the SO/PO process.   For product issued to Europe from the US, a purchase order will be issued to Stryker US via the Electronic Data Interface (EDI) generated by European legacy systems, which in turn automatically creates the sales order in Oracle for the US.   The beauty of EDI is that it eliminates the need to exchange a paper copy of the purchase order and automatically generates and loads the sales order directly into Oracle.

Product issued from Europe to the US facilities would also utilize EDI.   Purchase orders issued from the US will be sent to Europe through the interface where it will be automatically created as a sales order in European legacy systems.

Once Stryker’s European facilities are fully implemented, the process then will follow the IR/ISO process, where both the US and European facilities are on Oracle and thus internal transactions can occur between the two.  

However, the decision to go to the IR/ISO process post European go-live has not been finalized by Stryker for many reasons.   Firstly, in Oracle there is no ability to split lines in the internal sales order once it’s created (ex. splitting a line for a quantity of two into two separate lines).   In Stryker’s current inter-company process, their US operations submit a request to their European facilities for a specific number of products based on min/max planning.   Based on the demand for those products worldwide and the manufacturing schedule of the product line, Europe will provide the US a supply schedule that over an interval of time will satisfy the entire request.   So for example, if a quantity of 100 is requested for item X, Europe may propose a schedule that will supply 10 items every 3 weeks until the entire 1000 has been supplied.

One proposed solution was to receive this manufacturing schedule during entry of the internal requisition.   Performing the line splits and establishing the requests dates for each line in the internal requisition would carry over during the creation of the internal sales order in the supplier organization.   However, another quandary of this process is that the supply schedule may change after the initial schedule has been issued.   Say after three months, the European manufacturing plants now want to change their initial supply schedule of product X from 10 items every 3 weeks to 7 items.   This would require a split line and request date change to the ISO – both of which cannot be done in Oracle.

From a financial prospective, there are many benefits to using the IR/ISO process for the obvious reason that it streamlines the inter-company accounting.   However, in the end, the Stryker finance and order management teams will need to revisit their current inter-company processes and international product supply rules to see if this is the most efficient way of conducting their business.   And based on this conclusion, they’ll need to decide whether it is worth using another custom process to simulate the inter-company transaction versus utilizing the standard Oracle IR/ISO process.

Another major Stryker challenge to note from an OTC prospective was the automatic replenishment orders, also known as ARO.   To give some background, Stryker had a number of close business relationships with hospitals across the country where they would set aside inventory within the possession of Stryker that would be reserved strictly for use by the hospital.   As the hospital uses this inventory, Stryker would bill for the material used and automatically replenish the supply.   At a high level this involves two sales transactions.   The first transaction occurs when the hospital uses product from their reserved supply and Stryker sends an invoice for the product used, which involves billing the hospital and decrementing inventory from the customer reserved supply.   The next transaction consists of replenishing this supply by making an internal inventory transaction from general Stryker supply to the customer reserved location.

In Stryker’s legacy system (PRMS), the software had been customized to automatically prompt the user for a customer inventory replenishment order upon entry of the billing order for product used by the hospital from this designated supply.   By doing this, the user could easily enter an order for replenishing the reserved supply as the hospital used the product.  

Initially, to mimic the process in Oracle while avoiding customizations, Deloitte suggested manual steps that involved copying the billing sales order after booking, then from this copied order, create the replenishment order.   But this was unacceptable to the client as the steps in doing this were much more cumbersome than the streamlined process that was provided in their legacy systems.   As a result, a major enhancement would be developed to mimic the ARO process in Oracle.   We’ll review this enhancement in greater detail later in this document.

With a February 2006 go-live date for the US, Stryker Orthopaedics is well on its way to a successful transition to Oracle – bringing Stryker headquarters and sales facilities to a single global instance.

Enhancing Order to Cash

As you can see from each of the implementation efforts, the global nature of both the Diebold and Stryker projects posed various challenges to their respective Order to Cash designs and implementation efforts.   And from these challenges arose various enhancements that would be developed to satisfy the requirements of global order to cash.

IR/ISO, the Diebold Way

As mentioned earlier, Diebold would introduce an enhanced version of the IR/ISO process.   The seeded Oracle IR/ISO process begins with entry of the internal requisition.   If the requisition is placed against another geographic location within the company, an internal sales order is spawned in that internal organization with the requisition requester as the customer.   The internal sales order is then fulfilled and shipped to the requester, where the requester receives the order against the internal requisition that was placed.

Diebold’s business followed a similar process that started from order entry.   Often Diebold sales facilities would receive an order from a customer for product that was manufactured and sold from another internal facility.   So in an Oracle World, after booking the sales order for this product, a separate IR would have to be entered and issued to the internal organization that offers the product.   From this point, the process would follow the standard IR/ISO process.   Once the product is received against the IR, then the inventory would need to be manually reserved against the sales order.

Rather than performing the manual steps of entering the IR and reserving against the sales order once internal product is received, an enhancement would be developed to automatically generate the IR from a sales order based on the sourcing rules of the product ordered.   This process would become formerly known as the SO/IR/ISO process.   For example, if a sourcing rule was setup for product X that stated that X was manufactured in a European facility, a sales order entered in the US for product X would automatically create an internal requisition for product X upon booking.   This eliminates the need to manually enter the IR and creates a physical link in the system between the sales order and the internal requisition needed to fulfill the order.   The auto-generated IR follows the seeded Oracle IR/ISO processes up until the point of receiving the product against the internal requisition in the requesting organization.   From this point in the process, the product is then automatically reserved against the sales order that spawned the IR – eliminating the need to manually reserve the internally received inventory against the sales order.

In the end, Diebold received a fully streamlined process in Oracle that would allow them to place sales orders in any region that could be fulfilled from any of their facilities globally.   The enhancement proved to be a huge success in testing and is planned to be deployed once Diebold’s US, China, and Latin American manufacturing facilities are fully implemented.

Stryker Notifications and Auto-Replenishment Process

Stryker would adopt a number of enhancements of their own that would enhance the notification processes.   Seeded Oracle processes provided notification capabilities that were too rigid for the Stryker business.   With standard functionality, a profile option was provided that could be used to designate a responsibility or user whom would receive all notifications for product returns that required approval.   This was an issue because several of the Stryker’s order to cash processes such as customer credits, customer debits, and surgical instrument product orders required financial approvals, despite the fact they system returns weren’t occurring.

Another issue with the standard notification process is that there is no hierarchical capability (This applies to fulfillment notifications.   In 11.5.10, hierarchical notifications were introduced to negotiation workflows).   For example, with Stryker’s surgical instrument product orders, two levels of approval were required – first from the local field sales manager, second from customer operations headquarters.

Lastly, Stryker also wanted an enhancement that would provide the ability to select the approver during order entry from a list of approvers assigned to a given set of field offices, which could be maintained by Stryker headquarters.

To meet these requirements, an enhanced workflow would be established for credit, debit, and surgical instrument product orders that would allow the user entering these orders to select an approver from a descriptive flexfield list of values.   This list of values was populated based on the type of order, the organization from which it was being entered, and could be maintained by Stryker through the QuickCodes form.   Upon booking an order, the enhanced notification workflow would refer to the approver selected in the descriptive flexfield to send the notification for approval, rather than referring to the profile option as standard Oracle processes did.

The second level of notifications (strictly an email notification) that was required for surgical instrument product orders would be designed to send an email to the customer operations Outlook email group.       This email notification would be triggered upon approval of the first notification sent to the field operations manager.

An even more advanced notification workflow would also be created to meet the requirements of Stryker’s pricing discount approval process.   In this process, an approval hierarchy is established based on the amount discounted from the sales order and which customer is the sale being conducted.   For example, some of Stryker’s products required 1 level of approval for a 5% discount, 2 levels of approval for a 10%, and 3 levels of approval for a 15+% discount for select clients in their customer base.   Standard Oracle notification processes simply couldn’t handle this complexity.

In response to these requirements, an enhanced workflow was created to dynamically build an approval hierarchy based on a custom table that stored different types of discount approval settings.   A form was built to maintain this table and allowed users to build approval hierarchies starting with the discount levels, who should be notified at each level of discount, and what customers this approval hierarchy should apply to.   The enhancement, known as the One-Time Discount process, proved to be a success.

The auto-replenishment order (ARO) process enhancement that Deloitte would introduce was another major undertaking for the Stryker Order to Cash implementation effort.   This Oracle enhancement would operate much like Stryker’s current ARO process in PRMS that was described earlier.  

Structurally, each hospital that had its own personal inventory would receive its own sub-inventory in Oracle.   The setup of this sub-inventory would reflect that this inventory is financially owned by the hospital.  

With this structure intact, the process begins with the entry of the Bill Only order, where inventory is decremented from the hospital owned sub-inventory and an invoice is sent to the hospital for the product used.   After this Bill Only order is booked, the user then has the option to create the auto-replenishment order, which is an additional option added to the Tools menu.   When this option is selected, a separate window comes up that provides a preview of the ARO order.   This order preview carries over information from the Bill-Only order that was entered such as items, quantity, ship-to and bill-to addresses, and the hospital sub-inventory to replenish.   This preview form allows the user to massage the order prior to initiating the replenishment.   After all changes have been made, the user can then automatically create and book the replenishment order, where this replenishment order effectively creates the demand for the product to be shipped from general inventory space and to replace product in the hospital sub-inventory.

The ARO process enhancement proved to be an eminent success to the Stryker implementation and has proven to be a design feat that will carry the organization through its Order to Cash go-live in 2006.
 
Recap

The Diebold and Stryker Oracle implementations presented many design challenges to Order to Cash – many of which were beyond the realm of standard Oracle functionality.   Customizing any application is usually frowned upon because of the costs of developing and maintaining the enhancements.   However, the expectation that an out of box solution is sufficient for any global order to cash process across all industries is also unrealistic.  

We saw that the overall implementation efforts had the same general direction – phased roll-outs of the system based on geography.   But what these implementation approaches different was the way they conducted sales.   These differences existed because of the products they sold, their sales and logistics methodologies, and the industries they served.   And because of these differences not only does the implementation approach need to adapt, but the end solution needs to adapt as well.   Oracle Order to Cash products provides this type of flexibility.   And in conjunction with the dynamic knowledge and expertise of Deloitte Consulting, a global order to cash solution can be delivered.

Entry Filed under: Order Management, Order to Cash