Leveraging ERP Planning BOMs with Smart IP&O to Forecast the Unforecastable

​In a highly configurable manufacturing environment, forecasting finished goods can become a complex and daunting task. The number of possible finished products will skyrocket when many components are interchangeable. A traditional MRP would force us to forecast every single finished product which can be unrealistic or even impossible. Several leading ERP solutions introduce the concept of the “Planning BOM”, which allows the use of forecasts at a higher level in the manufacturing process. In this article, we will discuss this functionality in ERP, and how you can take advantage of it with Smart Inventory Planning and Optimization (Smart IP&O) to get ahead of your demand in the face of this complexity.

Why Would I Need a Planning BOM?

Traditionally, each finished product or SKU would have a rigidly defined bill of materials. If we stock that product and want to plan around forecasted demand, we would forecast demand for those products and then feed MRP to blow this forecasted demand from the finished good level down to its components via the BOM.

Many companies, however, offer highly configurable products where customers can select options on the product they are buying. As an example, recall the last time you bought a personal computer. You chose a brand and model, but from there, you were likely presented with options: what speed of CPU do you want? How much RAM do you want? What kind of hard drive and how much space? If that business wants to have these computers ready and available to ship to you in a reasonable time, suddenly they are no longer just anticipating demand for that model—they must forecast that model for every type of CPU, for all quantities of RAM, for all types of hard drive, and all possible combinations of those as well! For some manufacturers, these configurations can compound to hundreds or thousands of possible finished good permutations.

Planning BOM emphasizing the large numbers of permutations Laptops Factory Components

There may be so many possible customizations that the demand at the finished product level is completely unforecastable in a traditional sense. Thousands of those computers may sell every year, but for each possible configuration, the demand may be extremely low and sporadic—perhaps certain combinations sell once and never again.

This often forces these companies to plan reorder points and safety stock levels mostly at the component level, while largely reacting to firm demand at the finished good level via MRP. While this is a valid approach, it lacks a systematic way to leverage forecasts that may account for anticipated future activity such as promotions, upcoming projects, or sales opportunities. Forecasting at the “configured” level is effectively impossible, and trying to weave in these forecast assumptions at the component level isn’t feasible either.

 

Planning BOM Explained

This is where Planning BOMs come in. Perhaps the sales team is working a big b2b opportunity for that model, or there’s a planned promotion for Cyber Monday. While trying to work in those assumptions for every possible configuration isn’t realistic, doing it at the model level is totally doable—and tremendously valuable.

The Planning BOM can use a forecast at a higher level and then blow demand down based on predefined proportions for its possible components. For example, the computer manufacturer may know that most people opt for 16GB of RAM, and far fewer opt for the upgrades to 32 or 64. The planning BOM allows the organization to (for example) blow 60% of the demand down to the 16GB option, 30% to the 32GB option, and 10% to the 64GB option. They could do the same for CPUs, hard drives, or any other customizations available.  

Planning BOM Explained with computer random access memory ram close hd

 

The business can now focus their forecast at this model level, leaving the Planning BOM to figure out the component mix. Clearly, defining these proportions requires some thought, but Planning BOMs effectively allow businesses to forecast what would otherwise be unforecastable.

 

The Importance of a Good Forecast

Of course, we still need a good forecast to load into an ERP system. As explained in this article, while ERP  can import a forecast, it often cannot generate one and when it does it tends to require a great deal of hard to use configurations that don’t often get revisited resulting in inaccurate forecasts.  It is therefore up to the business to come up with their own sets of forecasts, often manually produced in Excel. Forecasting manually generally presents a number of challenges, including but not limited to:

  • The inability to identify demand patterns like seasonality or trend
  • Overreliance on customer or sales forecasts
  • Lack of accuracy or performance tracking

No matter how well configured the MRP is with your carefully considered Planning BOMs, a poor forecast means poor MRP output and mistrust in the system—garbage in, garbage out. Continuing along with the “computer company” example, without a systematic way of capturing key demand patterns and/or domain knowledge in the forecast, MRP can never see it.

 

Extend ERP  with Smart IP&O

Smart IP&O is designed to extend your ERP system with a number of integrated demand planning and inventory optimization solutions. For example, it can generate statistical forecasts automatically for large numbers of items, allows for intuitive forecast adjustments, tracks forecast accuracy, and ultimately allows you to generate true consensus-based forecasts to better anticipate the needs of your customers.

Thanks to highly flexible product hierarchies, Smart IP&O is perfectly suited to forecasting at the Planning BOM level so you can capture key patterns and incorporate business knowledge at the levels that matter most. Furthermore you can analyze and deploy optimal safety stock levels at any level of your BOM.

 

 

How does your ERP system treat safety stock?

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.

 

How does your ERP system treat safety stock 1

 

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.

 

How does your ERP system treat safety stock 2

 

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.

 

How does your ERP system treat safety stock 3

 

What data is needed to support Demand Planning Software Implementations

We recently met with the IT team at one of our customers to discuss data requirements and installation of our API based integration that would pull data from their on-premises installation of their ERP system.   The IT manager and analyst both expressed significant concern about providing this data and seriously questioned why it needed to be provided at all.  They even voiced concerns that their data might be resold to their competition. Their reaction was a big surprise to us.  We wrote this blog with them in mind and to make it easier for others to communicate why certain data is necessary to support an effective demand planning process. 

Please note that if you are a forecast analyst, demand planner, of supply chain professional then most of what you’ll read below will be obvious.  But what this meeting taught me is that what is obvious to one group of specialists isn’t going to be obvious to another group of specialists in an entirely different field. 

The Four main types of data that are needed are:  

  1. Historical transactions, such as sales orders and shipments.
  2. Job usage transactions, such as what components are needed to produce finished goods
  3. Inventory Transfer transactions, such as what inventory was shipped from one location to another.
  4. Pricing, costs, and attributes, such as the unit cost paid to the supplier, the unit price paid by the customer, and various meta data like product family, class, etc.  

Below is a brief explanation of why this data is needed to support a company’s implementation of demand planning software.

Transactional records of historical sales and shipments by customer
Think of what was drawn out of inventory as the “raw material” required by demand planning software.  This can be what was sold to whom and when or what you shipped to whom and when.  Or what raw materials or subassemblies were consumed in work orders and when.  Or what is supplied to a satellite warehouse from a distribution center and when.

The history of these transactions is analyzed by the software and used to produce statistical forecasts that extrapolate observed patterns.  The data is evaluated to uncover patterns such as trend, seasonality, cyclical patterns, and to identify potential outliers that require business attention.  If this data is not generally accessible or updated in irregular intervals, then it is nearly impossible to create a good prediction of the future demand.  Yes, you could use business knowledge or gut feel but that doesn’t scale and nearly always introduces bias into the forecast (i.e., consistently forecasting too high or too low). 

Data is needed at the transactional level to support finer grained forecasting at the weekly or even daily levels.  For example, as a business enters its busy season it may want to start forecasting weekly to better align production to demand.  You can’t easily do that without having the transactional data in a well-structured data warehouse. 

It might also be the case that certain types of transactions shouldn’t be included in demand data.  This can happen when demand results from a steep discount or some other circumstance that the supply chain team knows will skew the results.  If the data is provided in the aggregate, it is much harder to segregate these exceptions.  At Smart Software, we call the process of figuring out which transactions (and associated transactional attributes) should be counted in the demand signal as “demand signal composition.” Having access to all the transactions enables a company to modify their demand signal as needed over time within the software.  Only providing some of the data results in a far more rigid demand composition that can only be remedied with additional implementation work.

Pricing and Costs
The price you sold your products for and the cost you paid to procure them (or raw materials) is critical to being able to forecast in revenue or costs.  An important part of the demand planning process is getting business knowledge from customers and sales teams.  Sales teams tend to think of demand by customer or product category and speak in the language of dollars.  So, it is important to express a forecast in dollars.  The demand planning system cannot do that if the forecast is shown in units only. 

Often, the demand forecast is used to drive or at least influence a larger planning & budgeting process and the key input to a budget is a forecast of revenue.  When demand forecasts are used to support the S&OP process, the Demand Planning software should either average pricing across all transactions or apply “time-phased” conversions that consider the price sold at that time.   Without the raw data on pricing and costs, the demand planning process can still function, but it will be severely impaired. 

Product attributes, Customer Details, and Locations
Product attributes are needed so that forecasters can aggregate forecasts across different product families, groups, commodity codes, etc. It is helpful to know how many units and total projected dollarized demand for different categories.  Often, business knowledge about what the demand might be in the future is not known at the product level but is known at the product family level, customer level, or regional level.  With the addition of product attributes to your demand planning data feed, you can easily “roll up” forecasts from the item level to a family level.  You can convert forecasts at these levels to dollars and better collaborate on how the forecast should be modified.  

Once the knowledge is applied in the form of a forecast override, the software will automatically reconcile the change to all the individual items that comprise the group.  This way, a forecast analyst doesn’t have to individually adjust every part.  They can make a change at the aggregate level and let the demand planning software do the reconciliation for them. 

Grouping for ease of analysis also applies to customer attributes, such as assigned salesperson or a customer’s preferred ship from location.  And location attributes can be useful, such as assigned region.  Sometimes attributes relate to a product and location combination, like preferred supplier or assigned planner, which can differ for the same product depending on warehouse.

 

A final note on confidentiality

Recall that our customer expressed concern that we might sell their data to a competitor. We would never do that. For decades, we have been using customer data for training purposes and for improving our products. We are scrupulous about safeguarding customer data and anonymizing anything that might be used, for instance, to illustrate a point in a blog post.

 

 

 

Elephants and Kangaroos ERP vs. Best of Breed Demand Planning

“Despite what you’ve seen in your Saturday morning cartoons, elephants can’t jump, and there’s one simple reason: They don’t have to. Most jumpy animals—your kangaroos, monkeys, and frogs—do it primarily to get away from predators.”  — Patrick Monahan, Science.org, Jan 27, 2016.

Now you know why the largest ERP companies can’t develop high quality best-of-breed like solutions. They never had to, so they never evolved to innovate outside of their core focus. 

However, as ERP systems have become commoditized, gaps in their functionality became impossible to ignore. The larger players sought to protect their share of customer wallet by promising to develop innovative add-on applications to fill all the white spaces.  But without that “innovation muscle,” many projects failed, and mountains of technical debt accumulated.

Best-of-breed companies evolved to innovate and have deep functional expertise in specific verticals.  The result is that best of breed ERP add-ons are easier to use, have more features, and deliver more value than the native ERP modules they replace. 

If your ERP provider has already partnered with an innovative best of breed add-on provider*, you’re all set! But if you can only get the basics from your ERP, go with a best-of-breed add-on that has a bespoke integration to the ERP. 

A great place to start your search is to look for ERP demand planning add-ons that add brains to the ERP’s brawn, i.e., those that support inventory optimization and demand forecasting.  Leverage add-on tools like Smart’s statistical forecasting, demand planning, and inventory optimization apps to develop forecasts and stocking policies that are fed back to the ERP system to drive daily ordering. 

*App-stores are a license for the best of breed to sell into the ERP companies base –  being listed  partnerships.

 

 

 

 

Is your demand planning and forecasting process a black box?

There’s one thing I’m reminded of almost every day at Smart Software that puzzle me: most companies do not understand how forecasts are created, and stocking policies are determined.  It’s an organizational black box. Here is an example from a recent sales call:

How do you forecast?
We use history.

How do you use history?
What do you mean?

Well, you can take an average of the last year, last two years, average the most recent periods, or use some other type of formula to generate the forecast.
I’m pretty sure we use an average of the last 12 months.

Why 12 months instead of a different amount of history?
12 months is a good amount of time to use because it doesn’t get skewed by older data but it’s recent enough

How do you know it’s more accurate than using 18 months or some other length of history?
We don’t know. We do adjust the forecasts based on feedback from sales.  

Do you know if the adjustments make things more accurate or less than if you just used the average?
We don’t know but are confident that forecasts are inflated

What do the inventory buyers do then if they think the numbers are inflated?
They have lots of business knowledge and adjust their buys accordingly

So, is it fair to say they would ignore the forecasts at least some of the time?
Yes, some of the time.

How do the buyers decide when to order more? Do you have a reorder point or safety stock specified in your ERP system that helps guide these decisions?
Yes, we use a safety stock field.

How is safety stock calculated?
Buyers determine this based on the importance of the item, lead times, and other considerations such as how many customers purchase the item, the velocity of the item, it’s cost.  They’ll carry different amounts of safety stock depending on this.

The discussion continued. The main takeaway here is that when you scratch just below the surface, far more questions are revealed than answers.  This often means that the inventory planning and demand forecast process is highly subjective, varies from planner to planner, is not well understood by the rest of the organization, and likely to be reactive.  As Tom Willemain has described it’s “chaos masked by improvisation.”   The “as-is” process needs to be fully identified and documented.  Only then can gaps be exposed, and improvements can be made.   Here is a list of 10 questions  you can ask that will reveal your organization’s true forecasting, demand planning, and inventory planning process.