ERP and WMS Co-Existence: When System Worlds Collide

ERP and WMS Co-Existence: When System Worlds Collide
Featured Author - Joseph J. Strub - June 17, 2003

Introduction

Typically, after the enterprise resource planning (ERP) software has settled in, you may start to investigate ways to improve your warehouse management and operations through the use of a warehouse management system (WMS). Unless you're faster than a speeding bullet and can leap tall buildings in a single bound, normally you do not install both ERP software and a WMS at the same time. Regardless of your approach, early on you will notice an overlap in warehouse functionality between the ERP software and a WMS. When comparing the warehouse functions and features embedded in ERP software against those in a WMS, the ERP software usually comes out on the short end of the measuring stick. So your path is obvious; use the WMS for inventory related functions. Not so fast big fellow.

Focusing on warehouse functionality that is typically contained in both software solutions, this article discusses the merits of using the features of one software solution over the other. This discussion will concentrate on outbound, inbound, and miscellaneous warehouse processes. Most importantly, it concludes with an identification of the critical interfaces, where a majority of the work is to be done. While there are no exactitudes and you may be left with more questions than answers, completing the thought process can help you gain an appreciation of the complexities of making these two software solutions work together effectively for your organization.

Outbound Processes

The outbound function consists of processes that deal with getting product to the customer. As shown on the outbound processes chart, there are functions such as order taking, invoicing, cash receipts, and accounting activities that are not part of a warehouse's operations. The choice for each of these processes is simple since they should only exist in the ERP software. However, when discussing inventory, there are several choices. Picking comes in two flavors: (1) picking for production orders and (2) picking for customer orders.

Picking for production orders is the process whereby ingredients and parts are moved from the warehouse to the production lines. Typically, the decision on what to make or produce is based on what you have in inventory in terms of ingredients and parts. There is considerable scheduling and setup required for a production run. Furthermore, a decision to make one product over another could make resources and equipment unavailable for other operations. This all means that assurances must be made that you can actually make what you plan and schedule. For these reasons, picking of ingredients and parts should be an integral part of the production cycle. Since production is part of the ERP software, it makes most sense that picking for production orders should also be made in and using the ERP software.

Picking for customer orders is the process of selecting finished goods resulting from production runs, assembling them for shipment and loading, and, then, shipping the goods to customers. Assuming that you produce in bulk or volume, picking for customer orders occurs more frequently and in smaller quantities (See TEC article on What You Know Before Selecting A WMS Posted on May 29, 2003). Consequently, efficiencies to be gained from these picks can be more significant and numerous than those for production orders. Rules for tweaking the way picks are generated are typically more flexible and accommodating in a WMS. For this reason, picks for customer orders should be made in the WMS. To complete the customer order processing, it is only logical to perform the shipping and logistical processes in the WMS as well.

You will have to wait until the exciting conclusion to read where the official inventory, both ingredients and finished goods, are to be maintained. The fact, that inventory has to be updated in both the ERP software and the WMS, doesn't offer much of a clue.

Inbound Processes

The inbound function consists of processes that deal with ordering, receiving and storing material used to manufacture products. As with the outbound discussion, there are certain processes for which there is no choice. These processes include purchasing and purchase order generation, vendor invoice processing, cash disbursement, and accounting activities as indicated in the inbound processes chart.
Disposing of these administrative tasks, the physical act of receiving and storing the inventory in the warehouse can best be accomplished in the WMS.

Even when not using ERP software, purchasing information needs to be ported to the WMS in order that receipts can be validated and approved. Since at some point information must be transferred and inputted into the WMS, receiving represents a clean demarcation. This being the case, the receiving process initiates the inbound processes resident in the WMS. A WMS will have putaway logic to suggest stock locations whereby ingredients and goods are more readily accessible, reduce warehouse travel time, and maximize the use of available space. Likewise, since this inventory will eventually be used to satisfy production and customer orders, it is logical to use the barcode and label functionality available in a WMS as materials are being placed into stocking locations. Again, inventory updating would need to be accomplished in both software systems.

Miscellaneous Processes

Miscellaneous processes consist of those activities needed to ensure that the warehouse inventory is accurate and that promote good warehouse practices and procedures. These processes include inventory control and management, stock consolidation, and stock locator. Inventory control and management includes physical and cycle counting and intra and inter-warehouse transfers.

It is a general rule of thumb that a software solution that focuses on one discipline is better at supporting the single discipline as opposed to software supporting multiple disciplines. This is why you look to a WMS to satisfy these miscellaneous processes. A prime benefit of a WMS is suggested inventory movements and consolidations to increase warehouse efficiencies. Inventory counting schemas in a WMS are typically more adaptable to your environment, thereby creating the least downtime and disruption to warehouse operations.

Obviously, inventory management functionality of both software solutions needs be evaluated objectively. However, any WMS worth its reputation and cost should be able to provide more effective tools to solve your existing warehouse problems. If not, you should question the purchase of a WMS in the first place.

Critical Interfaces

So far we have established the following:

• Pick tickets for production orders are to be generated by the ERP software.
  
  
• Pick tickets for customer orders are to be generated by the WMS.
  
  
• Receiving, putaway, and barcoding and labeling processes are to be accomplished in the WMS.
  
  
• Inventory control and management processes are to be accomplished in the WMS.
  

The first conclusion that you can draw is that there are two sets of inventory records: (1) ERP and (2) WMS. But before we can talk about synchronizing both sets of inventory records, the foundation data, namely ingredient and product codes, UOM (unit of measure), and warehouse locations and characteristics, must be defined. A convincing argument for defining this foundation data in the ERP can be made because of the more encompassing scope and expanse of functionality in the ERP software. In other words, if you use the WMS to define such structures, the changes require in the ERP software could be significant, if not overwhelming. This approach is further supported by the fact that the ERP software is usually already installed and running. Consequently, the first interface is the loading and ongoing maintenance of data structures from the ERP software to the WMS. Do you automate the maintenance activity or do double entry in both systems? How often is maintenance, namely adds, changes, and deletes, performed? Do you need reporting to identify out of sync situations between ERP and WMS inventory balances or do you wait for your customers to tell you?

Inventory data, such as quantity on hand and warehouse location, must be timely and accurate. If you accept a customer's order, you must be certain that you have the product to satisfy the need. If not, you may not have customers for very long. Consequently, as activity occurs in the warehouse, it must be reflected in the ERP-maintained inventory records on a real time basis. Alternatively, you could modify the ERP order taking process to query directly into the WMS-maintained inventory. Regardless, either approach requires a moderate to complex programming effort, representing an enhancement to the foundation ERP software. The ongoing and costly effects of package enhancements have already been discussed in several TechnologyEvaluation.com articles.

The thought process is the same when going in the opposite direction, namely picking ingredients and parts for production orders. Since the argument was presented to pick ingredients from the ERP-resident inventory, the inventory balance changes must be reflected in the WMS-resident inventory. However, depending on the runtime of production cycles, you may be able to get away with operating in a batch update mode.

Because the volume associated with picking processes is fairly significant, the questions we asked about the foundation data above are inappropriate. Double entry is not feasible, practical, or reliable. However, reporting to highlight out-of-sync situations would still be warranted and prudent.

Other transactions that require careful and similar consideration are:

• Transfers
  
• Adjustments
  
• Cycle count adjustments
  
• Receipts and putaways
  
• Shipments
  
• Miscellaneous receipts and issues
  

As dictated by which processes are performed by the ERP software and the WMS, the diagram below indicates from a conceptual perspective the required interfaces.

click here to enlarge

Summary

Experience dictates that you will be maintaining two sets of inventory records, one residing in the ERP software and the other in a WMS. With its more encompassing toolset, the master resides in the WMS and the slave in the ERP software. Depending how lean you run your inventory, synchronization will be at the transaction level (i.e. transfers, adjustments, receipts, picks, etc.). Confirmation will be at the summary level, namely verification that balances are consistent. When inconsistent, exception reports will help identify differences and, hopefully, causes. When all else fails, a complete upload or download of inventory records between software solutions should be tested and waiting in the wings to run.

Having two major pieces of software in the same organization is not a pretty or simple picture from a usage, maintenance, or interface perspective. It is this perspective that has driven the "one stop shopping" ERP concept. However, as stated in my previously referenced article, as we continue to look for more areas from which to squeeze savings out of our operations, selecting "best of breed" software for critical function, such as the warehouse, will become more of a necessity. When traveling down this path, and even if you are installing the ERP software first, look down the road and try to conceptualize your warehouse requirements so that you can minimize the difficulties and tunneling between the ERP and WMS software solutions.

If you would like a copy of the transactional requirements for the interfaces between ERP and WMS software and the charts used in this article, please e-mail me.

About the Author

Joseph J. Strub has extensive experience as a manager and senior consultant in planning and executing ERP projects for manufacturing and distribution systems for large to medium-size companies in the retail, food & beverage, chemical, and CPG process industries. Additionally, Mr. Strub was a consultant and Information Systems Auditor with PricewaterhouseCoopers and an applications development and support manager for a Fortune 100 company.

He can be reached at JoeStrub@writecompanyplus.com.