Inventory Control concerns the management of physical goods, focusing on an accurate and up-to-the-minute count of every item in inventory and where it is located, as well as efficient retrieval of items. Relevant technologies include computer databases, barcoding, Radio Frequency Identification (RFID), and the use of robots for retrieval.

Inventory Management aims to execute the inventory policy defined by the company. Inventory Management is often accomplished using Enterprise Resource Planning (ERP) systems, which generate purchase orders, production orders, and reporting that details current inventory on hand, incoming, and up for order.

Inventory Planning sets operational policy details, such as item-specific reorder points and order quantities, and predicts future demand and supplier lead times. Important components of an inventory planning process include what-if scenarios for netting out on-hand inventory, analyzing how changes to demand, lead times, and stocking policies will impact ordering, as well as managing exceptions and contingencies.

Inventory Optimization utilizes an analytical process that computes values for inventory planning parameters (e.g., reorder points and order quantities) that optimize a numerical goal or “objective function” without violating a numerical constraint. For instance, an objective function might be to achieve the lowest possible inventory operating cost (defined as the sum of inventory holding costs, ordering costs, and shortage costs), and the constraint might be to achieve a fill rate of at least 90%. Using a mathematical model of the inventory system and probability forecasts of item demand, inventory optimization can quickly and automatically suggest how to best manage thousands of inventory items.

Is safety stock regarded as emergency spares or as a day-to-day buffer against spikes in demand? Knowing the difference and configuring your ERP properly will make a big difference to your bottom line.

The Safety Stock field in your ERP system can mean very different things depending on the configuration. Not understanding these differences and how they impact your bottom line is a common issue we’ve seen arise in implementations of our software.

Implementing inventory optimization software starts with new customers completing the technical implementation to get data flowing.  They then receive user training and spend weeks carefully configuring their initial safety stocks, reorder levels, and consensus demand forecasts with Smart IP&O.  The team becomes comfortable with Smart’s key performance predictions (KPPs) for service levels, ordering costs, and inventory on hand, all of which are forecasted using the new stocking policies.

But when they save the policies and forecasts to their ERP test system, sometimes the orders being suggested are far larger and more frequent than they expected, driving up projected inventory costs.

When this happens, the primary culprit is how the ERP is configured to treat safety stock.  Being aware of these configuration settings will help planning teams better set expectations and achieve the expected outcomes with less effort (and cause for alarm!).

Here are the three common examples of ERP safety stock configurations:

Configuration 1. Safety Stock is treated as emergency stock that can’t be consumed. If a breach of safety stock is predicted, the ERP system will force an expedite no matter the cost so the inventory on hand never falls below safety stock, even if a scheduled receipt is already on order and scheduled to arrive soon.

Configuration 2. Safety Stock is treated as Buffer stock that is designed to be consumed. The ERP system will place an order when a breach of safety stock is predicted but on hand inventory will be allowed to fall below the safety stock. The buffer stock protects against stockout during the resupply period (i.e., the lead time).

Configuration 3. Safety Stock is ignored by the system and treated as a visual planning aid or rule of thumb. It is ignored by supply planning calculations but used by the planner to help make manual assessments of when to order.

Note: We never recommend using the safety stock field as described in Configuration 3. In most cases, these configurations were not intended but result from years of improvisation that have led to using the ERP in a non-standard way.  Generally, these fields were designed to programmatically influence the replenishment calculations.  So, the focus of our conversation will be on Configurations 1 and 2. 

Forecasting and inventory optimization systems are designed to compute forecasts that will anticipate inventory draw down and then calculate safety stocks sufficient to protect against variability in demand and supply. This means that the safety stock is intended to be used as a protective buffer (Configuration 2) and not as emergency sparse (Configuration 3).  It is also important to understand that, by design, the safety stock will be consumed approximately 50% of the time.

Why 50%? Because actual orders will exceed an unbiased forecast half of the time. See the graphic below illustrating this.  A “good” forecast should yield the value that will come closest to the actual most often so actual demand will either be higher or lower without bias in either direction.

If you configured your ERP system to properly allow consumption of safety stock, then the on hand inventory might look like the graph below.  Note that some safety stock is consumed but avoided a stockout.  The service level you target when computing safety stock will dictate how often you stockout before the replenishment order arrives.  Average inventory is roughly 60 units over the time horizon in this scenario.

If your ERP system is configured to not allow consumption of safety stock and treats the quantity entered in the safety stock field more like emergency spares, then you will have a massive overstock!  Your inventory on hand would look like the graph below with orders being expedited as soon as a breach of safety stock is expected. Average inventory is roughly 90 units, a 50% increase compared to when you allowed safety stock to be consumed.

We often are asked, “Why is the software driving up the inventory?” The answer is that Smart isn’t driving it in either direction – the inputs are driving it, and those inputs are controlled by the users (or admins). Here are four things you can do to get the results you expect.

1. Confirm that your service level targets are commensurate with what you want for that item or group of items. Setting very high targets (95% or more) will likely drive inventory up if you have been coasting along at a lower level and are OK with being there. It’s possible you’ve never achieved the new higher service level but customers have not complained.  Figure out what service level has worked by evaluating historical reports on performance and set your targets accordingly. But keep in mind that competitors may beat you on item availability if you keep using your father’s service level targets.

2. Make sure your understanding of “service level” aligns with the software system’s definition. You may be measuring performance based on how often you ship within one week from receipt of the customer order, whereas the software is targeting reorder points based on your ability to ship right away, not within a week. Clearly the latter will require more inventory to hit the same “service level.” For instance, a 75% same-day service level may correspond to a 90% same-week service level. In this case, you are really comparing apples to oranges. If this is the reason for the excess stock, then determine what “same day” service level is needed to get you to your desired “same week” service level and enter that into the software. Using the less-stringent same-day target will drop the inventory, sometimes very significantly.

3. Evaluate the lead time inputs. We’ve seen instances in which lead times had been inflated to trick old software into producing desired results. Modern software tracks suppliers’ performance by recording their actual lead times over multiple orders, then it takes account of lead time variability in its simulations of daily operations. Watch out if your lead times are fixed at one value that was decided on in the distant past and isn’t current.

4. Check your demand signal. You have lots of historical transactions in your ERP system that can be used in many ways to determine the demand history. If you are using signals such as transfers, or you are not excluding returns, then you may be overstating demand. Spend a little time on defining “demand” in the way that makes most sense for your situation.