Business Central expert
Fulfill all your needs for PLANNING and managing AVAILABILITY in BUSINESS CENTRAL.
In this article, we explain what you should require, how you avoid customizations, and which APPS to use.
Typically, planning is basically about customers wanting to buy goods from us, and we want to make sure we have enough items in stock, but we also don’t want to have more items in stock than we can sell.
Inventory Binding vs. Customer Service
The conflict in planning is between inventory binding, which is the money tied up in the warehouse – and the service level, which is the percentage of the sales orders we can deliver. The Sales Manager wants a high service level, and the CFO wants a low inventory binding.
The conflict between inventory binding and customer service level is a planning classic.
On the one hand, you want a high level of fulfillment provided to customers. That means that you want to be able to deliver an item as quickly as possible when the customer requests it. If you can fulfill all the customer’s orders, you have a service level of 100%.
It requires that you have all items in stock in very large quantities.
At the same time, you also want as little capital as possible tied in inventory. You don’t want to have items in inventory for too long, tying-up capital and becoming obsolete. A common rule of thumb is that an inventory costs 20-25% per year. If you have 10 million tied up in inventory, it may cost you 2 million per year in inventory costs. This is why capital tied in inventory is incredibly important to your finances.
The head of Sales wants a high customer service level to make the customers happy, and he is not interested in capital issues. The head of Finance wants a low level of inventory binding, and he is not interested in the customer service level. And the Planner has the task of finding the right balance.
Planning and availability is about being able to predict what customers are going to buy, so that we can purchase and produce the right items – in the right quantity – at the right time. Planning is mathematically complex – even if we only buy and sell goods.
We purchase goods in large quantities and in good time to get the goods at the best price. What we actually make money from is taking the risk by having the item in stock so that it is available when the customer wants it.
The longer the delivery time for the product and the larger batches we have to buy the product in, the greater the need for planning. We need to forecast how large a number of items we will need. If we sell to retailers, we want them to forecast their sales or place orders in good time.
When a customer would like to place an order, we would like to be able to see what is available in the warehouse and reserve the goods for the customer.
» Reservations and Allocations
When we buy in containers that are sent from the other side of the world and take a long time to arrive, we want to keep track of what exactly is in the container.
If the arrival time changes, we would like to be able to change the date for all the purchase lines in the container, and then we need to be able to plan what consequences this has.
We produce an item which consists of several components, and some of those components are also produced from a number of components. In this way, we have a bill-of-material (BOM) structure with production in several levels.
A sales order contains a number of the finished top item, and then we have to break this need down into purchasing needs for all the components included in the BOM structure. That task is called MRP, which means material requirements planning. If we know the sales orders and forecasts at the upper level, then Business Central can calculate the product requirements at the lower levels.
MRP is comprehensive to use in Business Central. Of course, this requires that all BOMs be maintained in Business Central, and that can be a lot of work.
In principle, automated MRP is feasible. The challenges arise when the reality changes, as it does all the time.
Then, the automated MRP system will suggest changes that are problematic, illogical or practically impossible. We need a planning engine which is much simpler to use.
» Agile Planning for SMBs
In our experience, very few companies achieve to run fully automatic MRP. Most companies give up because it demands an incredible amount of configuration or is simply not flexible enough for their situation.
The very straightforward example we often see is where the dates on the sales orders are in the past. If you have sales orders that were supposed to be delivered a month ago, you run into problems with MRP.
» Material Requirements Planning (MRP)
Why must MRP absolutely use the demand date as the starting point for everything?
We want to plan on the basis of what is actually feasible.
If the shipment from your vendor is delayed, or never could be delivered by your preferred date, then it is clearly better for the ERP system to suggest a new delivery date to your customer – than for it to suggest you get the vendor to deliver several months ago.
If the system knows what you have in stock, and what receipts you already have planned, and what your lead time is on purchases, and what your production time is on an item, then the system can suggest sales order dates to make all processes throughout the hierarchy feasible.
If you follow the traditional MRP approach, you must spend hours manually changing purchases and productions. If you work it out the other way round, it usually requires only a single change to a sales order date.
» Planning in Reverse
Big companies using big ERP systems are often living in a different reality to small and medium-sized companies (SMB).
Big companies have a relatively easier time forecasting their sales. If we have been selling lots of sausages for 50 years, we have a good chance of forecasting our sales, so we can lock in our production volume early, making planning easier.
If we have a highly complex production with many, perhaps expensive, components or a long production time, we need to lock in the production forecast. A car factory must decide early on how many cars to produce. Otherwise, production cannot be planned at all. And we can’t just decide, halfway through the month, that half the sedan production is to be SUVs instead.
That is why the big ERP systems work on the assumption that our demand is known in relatively good time, because we won’t be able to base purchase planning on it otherwise.
For most small and medium-sized companies, however, the reality is different. We must be very agile. ERP systems for small and medium-sized companies are therefore often full of customizations to address the need for flexibility.
When our customer suddenly decides that the shipment in 2 weeks’ time has to be orange instead of black, we move heaven and earth at the factory, do some custom spray-painting and rush the items through the door at the last moment – and then our customer thinks we are fantastic.
This is what many small and medium-sized companies must do to stay competitive – and the ERP system must support it.
Agility has become incredibly important in the planning of production and purchasing. Most MRP solutions in ERP systems are simply not ready for this level of flexibility. They return illogical change suggestions if the demands change dramatically.
If we have high withdrawal predictability and relatively few items, MRP planning is easier to use.
If we have many items and often create new ones, or new configurations or combinations, or if it is hard for us to predict withdrawal and if customer demands often change, traditional MRP will often fall short.
We must ask ourselves what level of flexibility we need – and how much we can put up with having to manage manually.
The “reverse” approach is a very clever method for many SMBs.
There are many obstacles when we try to automate MRP: order sizes, safety stocks etc. Everything must be set up correctly on the item card and reflect a sensible reality if the MRP system is to behave intelligently.
Even if the system has all the pre-requisites for calculating intelligently, we can easily find ourselves in a situation where it suggests a lot of change lines that we do not consider optimal.
This happens because new sales orders are arriving between existing ones, and the picture is changing all the time. Each time we carry out a calculation, MRP will suggest changing it all. This generates a lot of noise.
A classic example is when we have registered a sales order that is broken down into some demands, and we have created a purchase order to obtain the necessary components.
Now, the customer wants delivery a day earlier, and you bring the date on the sales order forward by one day. Then MRP also recalculates your purchase order and proposes moving it by one day. It carries on doing this every time a new sales order arrives or something changes.
It may be that the purchase order cannot be moved at all. That ship has sailed. Fortunately, in most MRP solutions you can lock the purchase order so that MRP knows no more planning is to be done on it. It is locked tight.
However, we still have a raw material demand for the day before, so MRP will immediately suggest we create a new purchase order for the day before.
Unless the purchaser is alert in this situation, we risk purchasing the same item again, perhaps with express delivery in order to meet the date.
With the right overview, perhaps we would rather change the delivery type on the existing purchase order (to a faster delivery type) or persuade the customer to have the sales order delivered a day later.
The problem is that MRP doesn’t always provide the necessary overview.
We want to be able to base planning on what is actually feasible – and not just on the demand date. This is what is called “reverse” planning.
If we produce items consisting of hundreds of components, MRP makes a lot of sense, but the volume of
change suggestions in MRP can also become quite unmanageable.
MRP is smart when it is correctly set up and all the data is in place. But it becomes a roadblock if a shipment of one component is delayed, forcing us to manually work through many levels of the hierarchy and make adjustments.
We rarely find that MRP can cope with everything automatically via the change suggestions returned by the algorithm. What usually happens in practice is that companies run MRP on a subset of their items.
This can make sense if we run MRP on the 10% of our items that represent the majority of our flow.
The other 90%, on which there is relatively little movement in practice, should rather be handled by means of a simple item availability check that only creates new order suggestions on the basis of the reordering point.
Running MRP on all items usually causes too many problems.
When we have opted to use MRP, there are all kinds of detailed things we would like to be able to do in our planning in the ERP system.
Here are some of the things we encounter most often – things that are not always addressed as standard in the ERP system.
Plan selected sales order lines
We want the ability to plan using a filter on a sales order line. If an important customer places a big order and wants a particular delivery date, it would be nice to be able to isolate the planning for the item the customer ordered.
This requires us to be able to put a filter on the sales order line so that the calculation takes account only of the item in question and all items in the hierarchy below it.
The practical reason is that, if we are running full MRP planning, there might be 3,000 lines in the journal, so it can take some time to tell which lines have to do with our order, whereas, if we only planned on the Items below the top Items hierarchy, there might only be 30 lines.
Inventory profile overview
We will also need to have an overview of the inventory profile.
On a sales order line, perhaps we find out that we cannot deliver a particular item, so we want to have an overview showing when it will arrive in stock. This can help us avoid ordering items that will be arriving in stock the next day.
This knowledge and this overview will put us in a position to make sensible decisions.
The most user-friendly version is a graphical overview showing the inventory levels over time and all expected receipts and issues.