Interfacing Oracle to Your Legacy WMS - A Good Idea?

January 10th, 2008 |   Send this article to a friend!

Over the years I’ve been involved with several Oracle implementations where the decision was made to retain the existing warehouse and inventory management systems in place of Oracle WMS. Perhaps your organization had made a similar decision knowing that the existing warehouse solution was best suited for your operations. Not to say that Oracle WMS is the best warehouse management solution out there – because it may very well not be. In fact, it may be true that your Legacy inventory system is the best fit for your business. Not only may it be the best fit, but keeping the existing system in place also eliminates any risk involved in changing the systems of what can be a fragile inventory and shipping operation. In other words, if it ain’t broke, don’t fix it – right?

Perhaps, but before you go down this path there is another factor that should be taken into consideration: ensuring the order fulfillment process as a whole remains seamless and intact. What is the impact to the order entry, scheduling, pick release, on-hand availability and reservation processes if an interface is built to an outside WMS? The answer to this question is especially important in a high-volume environment where your organization fulfills hundreds to thousands of orders a day.

Generally, when an interface between Oracle (or any order processing system for that matter) and a Legacy WMS is built, a division of duties is established. Oracle is given the responsibility to capture orders and release these orders for shipment when ready. The Legacy WMS system is responsible for accepting shipment requests, processing these

shipments, and sending the results of the shipment back to Oracle. Essentially, the Pick Release process in Oracle is the “throw” to Legacy WMS, and the Ship Confirmation step is the “catch”.

Since the nature of both system’s responsibilities require access to inventory data, your organization must understand that not only are you building a shipping interface, but you are committing to maintain two sets of inventory data that may require several interfaces. Oracle will need access to on-hand balance and reservation information so that order processors have insight to product availability and so that the system knows what orders are eligible for shipment. The Legacy WMS will of course require inventory data to maintain on-hand balance and deduct balances upon shipment. Oracle inventory data, to a degree, will need to be in synch with inventory data in Legacy.

To what degree must be decided. Your organization may determine that both sets of inventory do not require real-time synchronization. For example, you may decide that manual adjustments made to inventory in Legacy may only need to be interfaced through a daily polling process that posts these updates to Oracle. If this direction is taken, then you will need to decide how your shipping interface will handle exceptions that may result from an on-hand balance delta between Oracle and Legacy inventory.

How can an inventory delta occur? Well, let’s say at the time we place an order for an item in Oracle there is 1 quantity available for reservation. However, during the day a warehouse worker reviews the item and determines that it fails to meet quality standards and as a result he/she performs a manual transaction in the Legacy WMS to issue that quantity to scrap. Because Oracle is unaware that this transaction occurred, the interface will continue to release the ordered item for shipment - even though there isn’t enough quantity on-hand in Legacy.

In this situation, you will need to ensure that this situation (among many others) can be handled by the interface. From a business prospective, a decision needs to be made to determine how exactly this delta should be handled. For example, you may want to leave the interfaced transaction in an error status and continue to retry until inventory is made available. Or you may want to cancel the transaction entirely. Whatever that action may be, it’s important that there is visibility to these kinds of inventory deltas.

If your organization decides that Oracle inventory and Legacy inventory requires real-time synchronization, your interface will still need the ability to handle situations that result in inventory deltas. Let’s face it – we’re all human. Any level of time and effort that is put into a real-time interface could still result in situations unaccounted for. And as best practice, an error handling procedure should still be implemented, especially in an environment where you require real-time synchronization.

Attempting to identify all scenarios that require a communication between Oracle and the Legacy WMS can get pretty crazy. Here are some examples of scenarios that would need to be included:

• Order cancelations in Oracle
• Shipment cancelations in Legacy
• Manual inventory transactions in either system
• Inventory location transfers, but this is only important if your organization is utilizing hard reservations at order time, which in this case you should seriously rethink using an interface.
  
• Split and partial shipment scenarios

We could go on and on with the list of scenarios to cover - these are just a small fraction of what can occur. And as I mentioned, even if you think you’ve listed all scenarios, you still need an error resolution process.

I can’t stress more the importance of error resolution in the event of an inventory delta. Whether it’s an automated or manual solution is not important, but the most important point is making sure that if an unidentified inventory delta situation occurs that the interface can be capture and handle this error. At minimum, if the error cannot be handled, at least provide the tools necessary to bring visibility to the situation. Trust me - there is nothing worse than going live with an interface and experiencing errors that were unaccounted for.

This all may come off as something you probably learned in a beginner’s course for software design, but I’ve seen and witnessed the aftereffects of an unsuccessful inventory interface launch with some very reputable clients. What results is the very situation that the client wanted to avoid in the first place - a chaotic situation that requires the involvement of lots of time and resources that the organization did not budget for but has no choice to deploy in order to fix an interface that is the backbone of their business.

Some brief examples I’d like to share…

Example #1

Working with a life sciences client to implement Oracle Order Management a few years back, the organization decided to keep their existing mainframe inventory system with the idea of avoiding risk and cutting costs. The consulting group at the time recommended against this decision, but the client continued on and even decided to take on the effort using internal resources.

In a nutshell, the core exchange of the interface was centered on the Pick Release and Ship Confirmation processes. Testing was lackluster and didn’t cover all scenarios such as partial line shipments or order cancelations. More importantly, there lacked a substantial volume test.

What resulted at go-live was a disaster. Because of the bugs around partial line shipping, some orders were shipped two, three, and occasionally four times over. It took a team of 10-12 people during go-live to identify the dozen situations that were causing the Pick Release failures and shipping issues. Overall, it had taken a year+ to stabilize the situation and resulted in an exceeded IT budget and sales losses to the client. A team still exists today in maintaining and monitoring this interface.

Example #2

A publishing organization implementing Oracle decided to build an interface to their existing warehouse system. Aside from its age, this system was a beta version of the vendor’s product. It was heavily customized and interfaced to dozens of other order processing systems already. Cost and risk were definitely a factor.

Results at go-live were also poor. Multiple or no shipments were occurring. Since shipment sets in Oracle were not in synch with the activity that occurred in the legacy system, it caused many issues. An extensive amount of resources were needed to help stabilize the situation. Over time, the client became limited to the amount of functionality that could be used in Oracle. For example, for an order that had several shipping locations, separate orders had to be created for each shipment vs. establishing different shipping addresses at the order line level.

Additionally, the client implemented a daily process that “synchronizes” the Oracle on-hand balances with Legacy on-hand balances if a delta occurs (scary). Overall, it has taken nearly 2 years to stabilize the situation and currently has resources dedicated to the effort today.

As you can see, clients typically downplay the risk exposed to the rest of the fulfillment process when implementing an inventory interface to “protect” the shipping operation. Even worse, these organizations had made the decision to keep the legacy WMS because it was determined that the implementation effort in replacing the system was to costly compared to building the interface. Looking at this short-term, this may be true. But like most system interface projects, the cost of maintaining such a beast can greatly exceed the cost of implementing a new WMS over time (at least based on my experience).

If you’re an organization that is the process of deciding upon an inventory and shipment interface or a new WMS, I hope you can take the above situations into consideration. In going with the direction of an interface, you must also take into account:

• Increased Go-Live Risk – In case the situation gets ugly, you’ll need extra time and resources to correct and stabilize the situation. Also will need to factor in any impact to the business and sales it may cause.
• A New Department – The interface itself will be a unique process that will require several individuals who understand and are familiar with the process and include expertise in both the Oracle and Legacy inventory systems.
• Difficulty or Inability to Upgrade/Change – Being that the interface will be a delicate process requiring much involvement from both systems at a technical level, any changes to the table structure on the Oracle side as a result of an upgrade or customization could result in breaking this interface. Likewise, any changes done to the legacy side could also adversely affect this interface. With that said, expect all upgrade efforts to your system to exponentially increase.

My position should be pretty clear from all my ranting – DON’T DO IT! Or at least if you do, thoroughly evaluate the alternative of implementing a new WMS. Hopefully through the experiences I’ve shared, you’ll find that both options are exposed to the same level risk, but that the long term cost benefits of implementing a new WMS will prevail.

---

Mr. Thompson is a Senior Oracle Applications Consultant with Lexerd Group Consulting. Visit www.LexerdGroup.com to find out more about our firm.

Interested in hosting your own blog? Lexerd Group’s Internet Services division provides specialized blog hosting services that utilizes the Wordpress blogging platform. Visit http://www.lexerdgroup.com/blog-yourself/ for more details.

Entry Filed under: Order Management, Technical, Shipping Execution, Order to Cash, Inventory