You probably heard it many times over: "we will reduce your inventory by 30%" (when? which inventory? why?), "we show you things in SAP you have never seen before" ( that's great, but what is the value in that?).. "Don't ever use an add-on. These are bad" (really? Is that a rule?); "...the way to better business is by Information Maturity" (has there ever been a more useless slogan?) or "safety stock can lead to excess or insufficient stock(duh). We show you how to solve that problem with exception management" (oh boy! Are you trying to tell me that I should reduce variability in MD06??).
Too vague in my mind. And they're all selling tools... which are supposed to get you sign off on an optimization project that might cost you a lot of money without getting much, or anything out of it.
I truly do believe you should constantly improve and optimize your SAP supply chain but beware of the Sharlatans and "thought leading" experts who do a good talk but never show up when the rubber hits the road.
Here are the first four of ten bits, I think you should watch out for when the people who halfheartedly reveal all the opportunities and promise ongoing value, show up at your door knocking.
First: "only the very best advisors will do!" Most SAP consultants get away with not knowing much during the implementation. As long as they know a little bit more than the user (who, at that time usually knows only little or nothing about SAP), they look credible and knowledgeable. But once your buyers and planners were exposed to the workings of the system for years and are experiencing severe pain and developed their own work-arounds - it will take a very, very experienced and solution oriented consultant who is a top notch communicator to get your team back on track.
Be very careful and get to know the people who will perform the actual work with your team and don't let the consulting company fool you with their best few during the assessment. Very often the consulting company comes in with a "thought leader" who speaks big words and does his 'Spiel', only to leave you with a team that is inexperienced and overwhelmed with the task at hand. It also does not take a horde of consultants to do the job right. If they give you one for Purchasing and another one for Forecasting, you know that they don't have a view of the big picture. And in an SAP supply chain optimization you can't work in silos.
Second: "30% inventory reduction is not always a good thing". If they come in, telling you that you will recoup the investment in the project with an inventory reduction, ask them what inventory they talk about. Finished Goods? so that we can't ship or sell? Raw materials? So that we can't start production? WIP? So our production lines starve?
A blind reduction of inventories (and it is a blind suggestion because the consultancy can not possibly know your situation at that point in time) can backfire in the most devastating way. In supply chain optimization, it's all about having the right product in the right quantity at the right time in the right place. And that sometimes requires an increase of inventory.
Flow benchmarking in Factory Physics is a great way (one way out of several others) to determine the appropriate level of inventories (either as a total or broken down into finished goods, WIP and raw materials) but how many SAP consultants can tell you how that works?
Third: "Don't ever pay for an assessment!" One of the greatest scams ever is when you have to pay for someone figuring out how best they can position themselves to define a long term project with you.
If they want to see how they can help, let them take a look. If they come up with a convincable, sensable proposal then go for it. But how do you know that they are able to do that? And why would you take that risk? Let them come in and show you what they will do for you. As crazy as it sounds; i have seen SAP Optimizers who actually don't care what's in it for the customer but rather what's in it for them. No kidding. They actually think that's how it works. Must be a cultural thing!? If they recommend the book "who moved my cheese", you know that you are dealing with people who would be really good running a Kindergarden rather than optimizing your supply chain (but they might be funny and entertaining on the project).
Fourth: "a policy is a policy is a policy" In my personal opinion a supply chain optimization can only work when your buyers, schedulers and planners fully understand how to continuously and sustainably adjust the settings that drive optimized inventory levels and effective, automated strategies. A policy is what helps your user to do that. Your consultant should know what a policy is (at the least) and know how to set it up.
If your optimization partner uses some LIS transactions and key figures to show you what could be wrong, they give you a one-time fix and not a strategy for continuous improvement. Knowing that a certain item has a high dead stock is interesting, but how does that help you? They give you a "top ten hitlist of high dead stock items" and tell you to reduce the inventory. That's not an optimization. That's "hitlisting"!
So how do I get the dead stock down? And how can I avoid build-up of dead stock on other items? ...in an automated fashion without having to go through every item manually?
The answer is segmentation, classification and policy setting. If they pitch an inventory reduction and don't ever talk about policies... watch out!
The entire SAP supply chain is driven by policies which optimize and automate. A good consultant knows that and can utilize and convey their principles so that your users apply them effectively. A bad one gives you "Top Tens" and "One Time Fixes"
... more in the next blog
SAP Mentor, supply chain management enthusiast. Advocate for science as a basis to optimize the SAP supply chain. Active in Europe and North America. Sailboater, private pilot, motorbiker. At home in Tribeca, NYC. The opinions expressed in this blog are mine!
Thursday, September 20, 2012
Wednesday, September 19, 2012
Inventory Analysis with the LIS. Really?
...as you probably know, SAP has provided so called 'Information Systems' as part of their software offering since the 90's. There is a Sales Information System, a Purchasing Information System, a Shop Floor Information System and many more. Each one of those has Info Structures which can be configured to collect data resulting from daily transactions. A user may then call up transaction codes which display the data through key figures and characteristics associated with the specific info structures.
The Logistics Information System, or short 'LIS', is one of these reporting systems and was mainly meant to be used for inventory analysis.
One of the problems with the LIS is that it is very rigid. There are a number of info structures provided and with those a number of key figures. And that is it. Unless you want to configure your own info structures and key figures. And that, with all due respect, is a hell of an effort. And once you set it up, there is no way you can change it again. To expect a user to maintain all of this, goes above and beyond what one can ask a buyer or planner to do. It requires a lot of technical knowledge and many, many hours of maintenance which, in the end, might be resulting in rarely used reports.
No wonder SAP stopped supporting the LIS and provided the Business Information Warehouse. But BI requires a lot of setup too and has some shortcomings as well - in my personal opinion. A major one, I think, is the fact that a data extract is generated and that means everything you see is at least one day old.
So what can you do? A very good option to do Inventory Analysis is by use of SAP Consulting's Add-On tools. There is a an MRP Monitor which allows you to perform an ABC, XYZ, LMN and EFG analysis (and much more...), which is very helpful to classify your materials for the optimum replenishment or planning policy and is neither available in standard SAP nor in the LIS (short of a very rudimentary ABC analysis).
fig.1 - ABC Analysis with the MRP Monitor
SAP Consulting offers also an Inventory Cockpit which allows you to call up reports made up of any key figures imaginable and uses the previously mentioned analysis.
fig.2 - Inventory Cockpit
fig.3 - result of the Inventory Analysis
fig.4 - more results
fig.5 - hitlist for important results
These Monitors use as a starting point the result of a 'Material Document Aggregation' that gives you utmost flexibility in filling a data table with the information you need and want. (In the LIS you can not exclude transfer postings (and much more...) from the data basis for your analysis.) Following some selection criteria that may be employed for the building of your analysis basis:
fig.6 - various, flexible selection criteria for the building of the analysis basis
There are more add-on tools available from SAP Consulting and these are all developed within the SAP namespace and therefore inside standard SAP. Marc Hoppe, the driving force behind these developments, writes about these in his books available through SAP PRESS.
There is yet another possibility that I consider very, very helpful if you want to perform an effective inventory analysis: It is using the Spreadsheet Server for SAP , QueryExchange and SmartPak offered by Global Software Inc. These are tools that you install on your laptop in Excel. The Spreadsheet Server allows you to formulate any query (KPI) you need and then goes off and pulls the relevant data out of SAP and displays it in Excel. What is important to note here is, that this does not create a a data extract (which then contains outdated information) but rather pulls the data right from the SAP table and uses an Excel formula to produce the up-to-date result.
It is a beautiful tool which practically lets you put together ANY report, KPI or query you desire, without limitations and with utmost accuracy and currency of information. Global Software's SmartPak offers you many pre-designed and pre-configured KPI's and Queries for Inventory Analysis and the graphics you can generate make the LIS graphics look like they were developed in ancient times (which, by the way, they were!)
I know that there are still consultants out there promoting the LIS - there are even consulting companies that built an entire methodology around the LIS - but don't get fooled; after they show your buyers and planners the "beautiful graphs and reports" from the early 90's and they teach them how to do a Dual Classification that looks like it should have been performed in the 80s, or a Dead Stock Analysis that runs for days - they will leave you with little or nothing that will help to determine replenishment or planning policies to optimize your safety stocks, lot sizes or inventory levels.
I am not saying you should not use the LIS anymore (...SAP does) but to spend money on a project to educate your busy users about how to use tools from the last century that are unsupported and don't really provide you with any value is not a good idea.
Wednesday, August 29, 2012
Service Levels and Fill Rates
This is not a simple subject. But it is yet another project very worthwhile doing right. However, it requires people hanging out on the same deck.
Here is my personal take on the topic: First; I believe in making a difference between MTS and MTO! Why? Because if you are planning for it, you should have it and if you make it to a specific request you should not expect your production planner to have it readily available.
Therefore we call the service level for MTS items a 'fill rate'. The MTO performance I call 'Service Level'. It does measure if we can stick to what we promise. Because we can't fill, we have to promise; after the replenishment lead time.
Now that we know that we have to distinguish we can start figuring out how to measure. For MTS products I would simply say that we take the availability checks result. If it found inventory, all is well; if it failed, the fill rate degrades. How can you measure this? Look at the availability check and if the material availability date is the same as todays date you are good, if not, your fill rate declines.
In an MTO scenario you have to work with the total replenishment lead time. There should not be any inventory. Therefore, your service level is good if you adhere to the result of the availability check (which should tell the customer that they can have the product after that time).
Bottom line: make a difference between MTS and MTO when it comes to service level. Standard SAP doesn't really have a good report for this. Global Software Inc. out of Raleigh, NC has a cool solution. But more about that later...
Here is my personal take on the topic: First; I believe in making a difference between MTS and MTO! Why? Because if you are planning for it, you should have it and if you make it to a specific request you should not expect your production planner to have it readily available.
Therefore we call the service level for MTS items a 'fill rate'. The MTO performance I call 'Service Level'. It does measure if we can stick to what we promise. Because we can't fill, we have to promise; after the replenishment lead time.
Now that we know that we have to distinguish we can start figuring out how to measure. For MTS products I would simply say that we take the availability checks result. If it found inventory, all is well; if it failed, the fill rate degrades. How can you measure this? Look at the availability check and if the material availability date is the same as todays date you are good, if not, your fill rate declines.
In an MTO scenario you have to work with the total replenishment lead time. There should not be any inventory. Therefore, your service level is good if you adhere to the result of the availability check (which should tell the customer that they can have the product after that time).
Bottom line: make a difference between MTS and MTO when it comes to service level. Standard SAP doesn't really have a good report for this. Global Software Inc. out of Raleigh, NC has a cool solution. But more about that later...
Lot Sizing optimization in SAP with an Add-On
Today I saw something great! It has always been a bit of a problem to me to go to end users, having to tell them that, in order to find the best lot size procedure, you have to do a lot of leg work. And if your portfolio exceeds a few hundred materials it becomes an impossible thing to do..
Well... Marc Hoppe and his team at SAP Consulting have a solution: a lot sizing simulator!
I have written about Hoppe's Add-Ons before. These cover 'white spots' of functionality not available in standard SAP, with solutions written within the SAP namespace. Beautiful stuff. As an example there is the MRP Monitor and it comes, amongst other things, with lot size simulation. The Monitor serves as a basis for many things and lets you store a table containing your portfolio with various data to analyze. You put this record together in that you collect historical data, usually coming from table MVER. However, SAP Consulting provides another option: you can use MVER, the standard consumption history, or you build your own. Building your own gives you the ability, as an example, to exclude certain movement types (like transfer postings). You can also exclude slow movers or new materials which don't have meaningful information yet.
After you built your analysis this way, you can use the various simulation tools and one of these is the lot size optimizer. With it you select a segment of your ABC / XYZ analysis (which the MRP Monitor has put together) and you run the simulation. What this does is exciting. For every material the solution looks at the future demand and tests every lot sizing procedure you choose. It then comes up with a list where for every lot size you can see the cost of replenishment, comparing ordering cost with stock keeping cost!
You can then choose to generate a list which shows for every material and demand situation the optimum lot sizing procedure. In this list you also see a comparison of your cost with the existing lot sizing compared to the lower cost one and the cost saving you get by switching over. With the push of a button all materials are updated with the best procedure and the next MRP run produces best possible order quantities and dates.
Periodically you run the optimizer again and keep your lot sizes in tune with your changing demand situation... This, by far, beats the impossible labor required by your MRP controller to have the best lot sizing methods maintained. The sheer impossible amount of effort needed is the main reason while only static and periodic lot sizes are in use. This simulator enables the optimizing lot sizes right away.
Wednesday, August 8, 2012
Strategies and Policies in the SAP supply chain
In an earlier post I talked about Strategies in an Enterprise
Breaking down from - and supporting - an enterprise strategy, we can employ three major sets of strategies in standard SAP; these are the replenishment strategies to automate the procurement of components, raw materials and products, the planning strategies to separate the MTS from MTO (and other strategies) and the production scheduling strategies to run the lines according to lean and agile principles.
Each one of these strategy groups contains individual strategies. In replenishment you may, as an example, procure based on past consumption or based on future requirements. As for the planning strategies you may plan for Make to Stock or you may plan on an assembly level for Finish to Order or for the Production Scheduling Strategies you may employ takt-based, repetitive scheduling.
In either case you need to do some work so SAP can support the strategy you decided on. This work usually requires setting up some basic data. The combination of settings that support a certain strategy, I call a policy. Please note that a policy is not an SAP term. SAP didn't pre-set policies; they left it up to you to put the appropriate combination together to retain utmost flexibility. The downside to this is the fact that you need a lot of experience and detailed knowledge to figure out the right combination for the right strategy. But who said that SAP is easy? And your consultant should know how this stuff works out. (in a previous post I pointed out the necessity for a consultant who explains all the options and does NOT simply give you the solution.... you will have to flexibly adjust new solutions to changing requirements. So if the consultant gives you the solution upfront - without you understanding the dependencies - you WILL be screwed once the influencing factors vary.)
Back to policy: a policy can be described in words like :"replenish based on a automatically determined forecast model on past consumption, ordering weekly demand with a minimum of 5 pallets, rounding to a pallet size, keeping safety stock in line with growing demand and at 3 days, receiving only Tuesdays and Thursdays, sourcing with Quantity Contracts and Quota Arrangements" and then needs to be set up in SAP accordingly. In this example the setup would like something like this:
Breaking down from - and supporting - an enterprise strategy, we can employ three major sets of strategies in standard SAP; these are the replenishment strategies to automate the procurement of components, raw materials and products, the planning strategies to separate the MTS from MTO (and other strategies) and the production scheduling strategies to run the lines according to lean and agile principles.
Each one of these strategy groups contains individual strategies. In replenishment you may, as an example, procure based on past consumption or based on future requirements. As for the planning strategies you may plan for Make to Stock or you may plan on an assembly level for Finish to Order or for the Production Scheduling Strategies you may employ takt-based, repetitive scheduling.
In either case you need to do some work so SAP can support the strategy you decided on. This work usually requires setting up some basic data. The combination of settings that support a certain strategy, I call a policy. Please note that a policy is not an SAP term. SAP didn't pre-set policies; they left it up to you to put the appropriate combination together to retain utmost flexibility. The downside to this is the fact that you need a lot of experience and detailed knowledge to figure out the right combination for the right strategy. But who said that SAP is easy? And your consultant should know how this stuff works out. (in a previous post I pointed out the necessity for a consultant who explains all the options and does NOT simply give you the solution.... you will have to flexibly adjust new solutions to changing requirements. So if the consultant gives you the solution upfront - without you understanding the dependencies - you WILL be screwed once the influencing factors vary.)
Back to policy: a policy can be described in words like :"replenish based on a automatically determined forecast model on past consumption, ordering weekly demand with a minimum of 5 pallets, rounding to a pallet size, keeping safety stock in line with growing demand and at 3 days, receiving only Tuesdays and Thursdays, sourcing with Quantity Contracts and Quota Arrangements" and then needs to be set up in SAP accordingly. In this example the setup would like something like this:
MRP type: VV
Lot Size: WB
Forecast Model: J
Min Lot Size: 2,500
Rounding: 500
Range Of Coverage Profile: 003
Planning Calendar: TT
Source List: YES
As you can see, we need to be clear on what out strategy is first; then we need to define the policy supporting that strategy and finally we need to maintain the master data (this can be quite extensive work to do for an MRP controller and therefore I highly recommend looking into Marc Hoppe's Add-On tools by SAP Consulting - I mention these in another post). The following graphic represents a simple decision tree for replenishment strategies:
I personally consider policy setting and maintenance one of the most important tasks in the SAP supply chain. Most users don't understand that MRP type PD is not a policy! Neither is strategy group 40. But if you combine a PD with a Range of Coverage profile and a Lot Size Procedure EX, you have put together a policy! One that supports the strategy of planning on future demand with a safety stock that dynamically adjusts itself to changing demand. It also makes sure that your safety stock never exceeds a maximum level (EX helps with that).
Figure out first what what you want the system to do. Then tell it to do just so. SAP has done a wonderful job to provide you with all the levers and switches. They are not easy to handle but that is why we pay the big bucks to our advisers and educators, isn't it?
Tuesday, July 24, 2012
Fix the Date or forever be separated...
Have you ever heard about mis-communication between the production scheduler and the sales department? The availability check with its rules and conditions is the link. I am mainly talking about order entry here, but, of course, the forecast and setup of MTO vs. MTS are two more areas of friction between sales and production - unnecessary if the right strategies and configuration to support those are in place (an educated user who can execute the functions well, must be the most important part of the whole).
Now when you enter a sales order into your SAP system, it represents a demand for a sellable product. The sales order is looking to get product from somewhere, so as to fulfill a customers desire to increase your revenue. The sales representative can not possibly understand why the company s/he works for would not deliver the product right away or wouldn't do anything to fulfill the request asap. But there are other goals: a supply chain that is as waste-less as possible, low finished goods inventory, high production utilization, low production cost and a smooth, undisturbed production program. Unfortunately these goals - and the Sales Reps mission - are usually not in line.
In SAP the availability check is using a rule and may be different depending on the business transaction you perform. In other words: a Sales Order may check differently than a Production Order. The rule by which the check is performed can be assigned in the material master and therefore can differ from one product to another. This rule, together with the fact that you create a Sales Order, form the framework within which delivery dates with the customer are agreed upon.
As an example: if a customer wants 50 pieces but there are only 30 in inventory, the availability check finds out for you when the company is able to deliver the goods. In its simplest sense the additional 20 may be delivered after the time it takes to bring them back or at the date when we receive the next batch from production. This is the difference between checking with or without replenishment lead time.
In the checking rule you can identify what stocks - safety, blocked, restricted - are to be included in the check. It is also possible to specify whether planned orders (firmed or all), production orders, requisitions and/or purchase orders are used to determine the availability date.
As you can see the choice is ours what we let SAP automatically determine as the date we tell our customer, when they can expect the goods. But there seems to be a problem. At least I see that quirk everywhere I look: the sales rep is on the phone with the customer entering an order and the availability screen says "you can have 30 pieces today and 20 pieces next week Tuesday." "Great" the customer says and the sales rep saves the order without fixing the date.
Not fixing the date has no meaning for the sales rep but in MD04 the entire order of 50 pieces stands with a requirements date of today. That means a red light and a signal to the production scheduler to make 20 pieces... NOW ! And tomorrow it means Now! And the day thereafter too. And the customer does not expect the 20 pieces before next Tuesday and is quite happy with that (in the end he won't get them before next Tuesday anyway).
Would the sales rep have checked on the fixing, we would have seen a delivery for today and another one for Tuesday in MD04 and production would have executed that order, which the availability check saw. The customer would have received what they were promised and the world would have been a little bit better place to live.
It is incomprehensible to me why companies don't have a policy in place that supports better practices when it's so easy to do. Instead people fight you to the end to not fix the date. I have no clue why but I have customers with whom I have been discussing this issue for years and they still don't do it or only with much reluctance. "What if I have it available earlier ?" they ask. So you really want to have hundreds (if not thousands) of false delivery days per week disturbing your production program, in exchange for that one time chance to deliver on Monday instead of Tuesday? And even then... it's an exception... and those are meant to be handled manually - not the rule.
Of course, if your availability check produces false results because your basic data setup is incorrect or you mix up MTS with MTO, then you have to do something else and can't fix the date. However, in that case we have to take a couple of steps back and are not ready yet to have production and sales sing to the same song...
Now when you enter a sales order into your SAP system, it represents a demand for a sellable product. The sales order is looking to get product from somewhere, so as to fulfill a customers desire to increase your revenue. The sales representative can not possibly understand why the company s/he works for would not deliver the product right away or wouldn't do anything to fulfill the request asap. But there are other goals: a supply chain that is as waste-less as possible, low finished goods inventory, high production utilization, low production cost and a smooth, undisturbed production program. Unfortunately these goals - and the Sales Reps mission - are usually not in line.
In SAP the availability check is using a rule and may be different depending on the business transaction you perform. In other words: a Sales Order may check differently than a Production Order. The rule by which the check is performed can be assigned in the material master and therefore can differ from one product to another. This rule, together with the fact that you create a Sales Order, form the framework within which delivery dates with the customer are agreed upon.
As an example: if a customer wants 50 pieces but there are only 30 in inventory, the availability check finds out for you when the company is able to deliver the goods. In its simplest sense the additional 20 may be delivered after the time it takes to bring them back or at the date when we receive the next batch from production. This is the difference between checking with or without replenishment lead time.
In the checking rule you can identify what stocks - safety, blocked, restricted - are to be included in the check. It is also possible to specify whether planned orders (firmed or all), production orders, requisitions and/or purchase orders are used to determine the availability date.
As you can see the choice is ours what we let SAP automatically determine as the date we tell our customer, when they can expect the goods. But there seems to be a problem. At least I see that quirk everywhere I look: the sales rep is on the phone with the customer entering an order and the availability screen says "you can have 30 pieces today and 20 pieces next week Tuesday." "Great" the customer says and the sales rep saves the order without fixing the date.
Not fixing the date has no meaning for the sales rep but in MD04 the entire order of 50 pieces stands with a requirements date of today. That means a red light and a signal to the production scheduler to make 20 pieces... NOW ! And tomorrow it means Now! And the day thereafter too. And the customer does not expect the 20 pieces before next Tuesday and is quite happy with that (in the end he won't get them before next Tuesday anyway).
Would the sales rep have checked on the fixing, we would have seen a delivery for today and another one for Tuesday in MD04 and production would have executed that order, which the availability check saw. The customer would have received what they were promised and the world would have been a little bit better place to live.
It is incomprehensible to me why companies don't have a policy in place that supports better practices when it's so easy to do. Instead people fight you to the end to not fix the date. I have no clue why but I have customers with whom I have been discussing this issue for years and they still don't do it or only with much reluctance. "What if I have it available earlier ?" they ask. So you really want to have hundreds (if not thousands) of false delivery days per week disturbing your production program, in exchange for that one time chance to deliver on Monday instead of Tuesday? And even then... it's an exception... and those are meant to be handled manually - not the rule.
Of course, if your availability check produces false results because your basic data setup is incorrect or you mix up MTS with MTO, then you have to do something else and can't fix the date. However, in that case we have to take a couple of steps back and are not ready yet to have production and sales sing to the same song...
Friday, July 6, 2012
MTS, MTO, ATO, CTO, ETO… Strategies to connect Sales with Production
The interface between the Sales and Production departments
is a critical one. Very often the two departments work in silos. All strategies
discussed here, are at the crossroads between demand and supply. It is a goal
to be agile and fulfill every customers wish on time and on quantity, but it is
also important to minimize waste and enable smooth replenishment and
production. Proper use of the planning strategy helps achieving both goals.
A big problem, one that I encounter a lot, is that products
are not optimally set up for either one of these strategies. Either the wrong
assignment happens, or Production has a different idea than Sales, about what
the product assignment should be. Additionally there is the need to
periodically analyze the product portfolio because what’s MTO today might be
MTS tomorrow.
The ultimate achievement, one that both Production and Sales
strive for, is to have the right product at the right place in the right
quantity at the right time. Planning strategies are one of the most important
drivers to achieve exactly that.
Make To Stock Planning
When your product is a commodity that can be sold out of a
catalog and is defined and specified through a master record, it can be planned;
if it is somewhat predictable. A steady consumption in the past helps
predicting the future, however, there may be events in the future which require
a more forward-looking planning process.
In any case, if you can somewhat predict what will happen,
you may consider a Make To Stock strategy. Even if it is hard to predict the
future, but the customer does not accept long delivery times, you might be
required to make some of your product to stock.
Making to stock means production without actual
requirements. The Sales Order does not drive the production program but the
forecast does. Incoming Sales Orders use existing inventory for the delivery
which keeps the customer lead time to a minimum.
Once your product is identified as a ‘Make To Stock’ the
availability check in the Sales Order must
look for inventory and not place additional load in the production program. If
there is no stock your service level degrades and the customer needs to wait
for the next receipt from production.
Disconnect between
Sales and Production #1: the “customer is king” paradigm does not have
any validity in an MTS scenario. If you want to make the customer the king you
need to make your product to that customer’s order.
Make To Order Production
This strategy still is for standard products which have a
clearly defined specification. Other than MTS, there is absolutely no forecast
on products which are made to an order from a customer. You start production after the customer’s request comes in
and not, like with MTS, beforehand.
When you identify a product to be made to order, the availability
check in the Sales Order needs a lead time; the time it takes to replenish or
produce the product from soup to nuts. Therefore when a customer requests the
item, no freely available stock to fulfill the order can be found. Everything
is made from scratch and takes its time.
Disconnect between
Sales and Production #2: You cannot plan for a 100% (or more!)
utilization on the production line and allow for the free flow of orders, which
were set to MTO, into the production schedule. All too often there is pressure
to fully utilize the line; and that can only be done with orders resulting from
a forecast. If MTS fills the line and MTO orders drop on top, they fall into
backlog and the quoted lead time to the customer is a farce.
Assemble To Order or Finish To Order with placement of the Inventory/Order
interface
This type of strategy allows for a placement of a stocking
point, the inventory/order interface, at the most effective spot in the product
structure. What this means is that you can decide at what point in the BoM,
material is kept in stock readily available for further processing. Therefore upstream
of the inventory/order interface we are making to stock and downstream from it
we are pulling to order.
This also means that downstream from the I/O interface we
have lead time to the customer whereas the availability check does not need to
consider time for the processes upstream from the I/O interface.
ATO provides flexibility, speed and helps reduce waste.
Other people would say its agile and lean at the same time.
Disconnect between
Sales and Production #3: Assembly strategies have the capability to
generate a production order to assemble the finished product right out of the
sales order. As this happens, the system can also check on component
availability and if there is a shortage, it can provide a reasonable date for
when the finished product can be delivered. If that date is not fixed, and I
have not seen a Sales person fix a date yet, production scheduling is burdened
with a demand for today… and tomorrow for tomorrow… and so on and so forth.
Please take a moment to think about what is done here: the Sales Rep agrees a
date with the Customer who would be quite happy to get the product on that date
in the future. However, that same Sales Rep tells the Production people that
the product needs to be available right away. Consider how many orders there
are and that this pressure pops up every day from now on until the order is
delivered, you can easily see that there is room for improvement in the communication
department.
Configure To Order
When a standard product has variations in its specification,
one needs to answer the question whether to create a material master record
number for every variation or to make use of the variant Configurator. In case
the VC is used, an underlying structure will have to be build, which allows you
to configure a variation of one (configurable)
material number based on features and options. The underlying structure has optional
values and characteristics that have dependencies and limitations. Be cautious to know that In the same way that
there is a line where it becomes more efficient to use options and
characteristics to build a spec, there is also a line where it becomes more
feasible to use a whole new project to build a complex product which has never
been built before; or in other words: to build the underlying structure with
features and options and dependencies becomes far too complex.
So there is an upper limit as well as a lower limit in
complexity where Configure To Order has its right to exist.
Configure To Order is a strategy that closely resembles MTO
or ATO for the finished product and components can be made to stock using a
forecast based on probability factors maintained for options and features.
Engineer To Order
The Variant Configurator most always fails when that fine
line was crossed where ETO should have taken over! It is not the lack of
functionality and features of the VC which make it fail, it is mostly that the
VC is used for a structure where projects and work breakdown structures would
much better suit the handling of the complex product or structure in question.
Engineer To Order is used when complex structures are build.
In most cases these projects organize many tasks and follow a long timeline to
produce large, highly customized products to specific customer specifications.
The finished product, and also many components and subassemblies, have never
been built before and receive brand new product codes. Work Breakdown
Structures and Projects are used to structure and manage the procurement of
long lead-time purchased parts, the dependencies in production and procurement
and cost and timely delivery of the final product.
All of these strategies have many variations. What was
discussed above is just a generic description. A more detailed discussion is to
be had around SAP planning strategies where there are countless combinations
and opportunities.
…so here is a summary of my view on these strategies on a
very generic level.
MTS: standard
product made to a forecast before
any committed orders come in
MTO: standard
products not held in inventory and made after
a committed order comes in
ATO: standard
product where some components are held in stock and the finished product is
finished after the order comes in
CTO: The standard
product has variations; as many as not to justify the creation of a part number
for every variation but not as many as to make the underlying structure too
complex to handle
ETO: complex structures and customer
specified projects which were never built before and make it impossible to be
handled with standard variations
Saturday, June 2, 2012
To pull or not to pull… the German Autobahn would work much better if it would be controlled by conWIP.
A production line is like the German Autobahn. If you keep
pushing, it will break down. Like a production line, the Autobahn has
measurable parameters. Release rate; at what frequency are cars coming on to
the road from the ‘Einfahrt’. Urilization; what is the percentage, or portion,
of the road that is occupied by cars. Variability; to what degree are drivers
out of sync with the speed at which they are driving, slowing down, stopping
and starting up again. Lead time; how long does it take cars to travel a
certain segment of the road. And throughput; at what rate are cars leaving the
Autobahn through the ‘Ausfahrt’.
So what happens when the Autobahn underlies a push
principle?... let’s take a step back here and first explore the question: “What
is it, that implies we are working within a push principle?”
In a push environment, entities enter the system according
to a planned or random moment in time. A planned order released to the
production line according to the planned start date, a baby entering this world
(there’s your push), a car driving onto the Autobahn. All of these entities
enter the system without any regard of what’s going on inside the system. A
newborn does not care what the world is like; whether there are too many of us;
it just wants in. A car going on a trip is a bit different (some people might
listen to the traffic report), but not much. And your jobs scheduled to go on
the line? Are they not being released into the process when the packaging line
at the very end is down? Of course they are. Otherwise the plant controller
would scream murder, when with the packaging line, the other work stations go
down too.
But herein lies the difference between push and pull. In a
pull environment, the release rate is controlled by the system itself and what
goes on inside. Take air traffic control; If the runway for landing in Newark
is down, every plane within the system that wants to fly to Newark is placed in
a holding pattern and therefore WIP, or the inventory of airplanes in the air,
is going up and it starts getting crowded around the New York airspace. Some
smart person has, at some point in the past, decided to put a limit on the
amount of airplanes that are allowed to fly around, within the New York
airspace. Once that limit is reached, no other plane is allowed to take off
from any airport to go towards New York.
I call that the WIP cap and that is what makes the air
traffic control system a pull system. In a pull system, once the WIP cap is
reached, another entity is only allowed to enter, if another entity leaves the
system, so that there is constant WIP.
Let’s summarize: A push system is driven by start dates; a
pull system is controlled internally by way of a WIP cap. (That also makes
clear, that babies will always be pushed into the world)
Back to the Autobahn. Back in the 60s when there was no
traffic radio or iphone traffic information, the Autobahn was a pure push
system. Later, all these traffic reports were introduced and we control a
little bit better, but not much, when cars will enter traffic. I we were able
to enter the era of pure pull in automobile traffic, everybody wanting to
travel, would receive a spot at which time enter the road. In the perfect world
you would stay at home until your ticket is called and then you would enter the
Autobahn at the same utilization (amount of cars per kilometer) as always.
(btw… if we are able to extend the air traffic systems so that you get a call
when to go to the airport, we could avoid the piles of passengers at airports
when there are flight delays).
All of the above is very desirable and people are working hard
to make this a reality sometime. To switch a production line from push to pul
is far more easy, but it still doesn’t happen much. Why is that?
In my mind it is because we do not point out the
inefficiencies resulting from push with a scientific method like Little’s Law,
the VUT equation (by Factory Physics) or a value stream map. We just look at
the perceived cost of having a work station down. There are other reasons to
not release a new job onto the system (e.g.waste of overproduction) and when
WIP piles up downstream, it is certainly not smart to keep introducing raw
materials to the process upstream. But there is always someone shouting that
the lines must be utilized as much as possible.
We have to prove these people wrong!
Friday, June 1, 2012
Planning Strategy 81... My favorite
Planning strategies represent the interface between demand and supply and are set in the material master's MRP3 screen in the field strategy group.
It's called the strategy group because it actually allows you to set a group of strategies which contains one main strategy and possible alternative strategies, which the sales rep might want to use instead of the main.
Strategy 81 belongs to the family of assembly strategies. These have a tight connection between the sales order and the supply element. In fact the assembly strategies create the respective supply element right out of the sales order and perform an availability check - not on the finished product, which is not available at this time, but - on the components necessary to assemble or finish up the final product. Hence this is an 'assemble to order' or 'finish to order' strategy.
Strategy 82 creates a production order (or process order if you use PP-PI) and strategy 81 creates a planned order out of the sales order. That makes it a great instrument, if you are using the tools of repetitive manufacturing! (yes I know... I can see some of you going "here he goes again... promoting REM")
So... :-) if you are a manufacturer of standard products and you make those products repeatedly... why not automating things? Your planners will thank you. Here is what could be done with 81 and REM:
Let's assume you make toasters; small toaster, bagel toasters and industrial toasters. Small and bagel toasters you sell to Target and you produce them to forecast and keep stock. The industrial toasters are made to order. All toasters are made on the same line and there is no doubt that this represents repetitive manufacturing, is there?
So naturally you employ takt or rate based scheduling to fill the line with transaction LAS2. Here I suggest to use strategy 40 for the small and bagel toasters. That would mean you'd have a forecast which creates run schedules (planned orders) for a long time to come, which may be used to fill the production line to, let's say, 80%. Here is your leveled load!
If you set up strategy 81 for the industrial toaster, which is MTO, every time a sales order is created, SAP generates a planned order (run schedule) and performs an availability check for all the components needed to make an industrial toaster. According to that availability, a committment date is determined for the customer and, if you fix the date, the assembly order is placed on the schedule - on that date within 20% of open capacity.
Should the production date change, the sales order will now be updated and vice versa.
Isn't this magic? Not really... Its just SAP...
It's called the strategy group because it actually allows you to set a group of strategies which contains one main strategy and possible alternative strategies, which the sales rep might want to use instead of the main.
Strategy 81 belongs to the family of assembly strategies. These have a tight connection between the sales order and the supply element. In fact the assembly strategies create the respective supply element right out of the sales order and perform an availability check - not on the finished product, which is not available at this time, but - on the components necessary to assemble or finish up the final product. Hence this is an 'assemble to order' or 'finish to order' strategy.
Strategy 82 creates a production order (or process order if you use PP-PI) and strategy 81 creates a planned order out of the sales order. That makes it a great instrument, if you are using the tools of repetitive manufacturing! (yes I know... I can see some of you going "here he goes again... promoting REM")
So... :-) if you are a manufacturer of standard products and you make those products repeatedly... why not automating things? Your planners will thank you. Here is what could be done with 81 and REM:
Let's assume you make toasters; small toaster, bagel toasters and industrial toasters. Small and bagel toasters you sell to Target and you produce them to forecast and keep stock. The industrial toasters are made to order. All toasters are made on the same line and there is no doubt that this represents repetitive manufacturing, is there?
So naturally you employ takt or rate based scheduling to fill the line with transaction LAS2. Here I suggest to use strategy 40 for the small and bagel toasters. That would mean you'd have a forecast which creates run schedules (planned orders) for a long time to come, which may be used to fill the production line to, let's say, 80%. Here is your leveled load!
If you set up strategy 81 for the industrial toaster, which is MTO, every time a sales order is created, SAP generates a planned order (run schedule) and performs an availability check for all the components needed to make an industrial toaster. According to that availability, a committment date is determined for the customer and, if you fix the date, the assembly order is placed on the schedule - on that date within 20% of open capacity.
Should the production date change, the sales order will now be updated and vice versa.
Isn't this magic? Not really... Its just SAP...
Drum, Buffer, Rope... and other scheduling systems
Very recently I was asked how to do 'Drum, Buffer, Rope' in SAP.
The person asking was interested on how to work with constraints; mainly the
bottleneck work center. There are many theories out there and each one has their on scheduling heuristics. 'Lean' has heijunka, 'agile' has FIFO and the 'Theory of Constraints' has Drum, Buffer, Rope (DBR). They may all be used interchangeably and SAP has them all pre-configured. You just have to know where to find them.
Heijunka is a leveling, sequencing and
scheduling method, which can be employed when using the tools of repetitive manufacturing. There is a strategy profile which is called Heijunka.
As you can see, there is also a strategy called FIFO in the scquencing board.
As you can see, there is also a strategy called FIFO in the scquencing board.
These strategies are not limited to repetitive manufacturing. They can also be used with discrete orders which are scheduled, capacity leveled and sequenced in CM25 - the graphical planning table.
Drum, Buffer,
Rope is a
similar thing in that it is employing algorithms in order to come up with a
paced production program in a certain sequence, and it is based on the Theory
of Constraints. This theory is concerned with running the bottleneck work center and the following gives a bit of an explanation on how this could be achieved.
Managing the constraint is mostly about managing the non-bottleneck systems and making them
“aware” how fast they should work — when they should slow down, when they
should stop, or when they should increase pace and by how much. The
Drum-Buffer-Rope system allows for such a systems-wide awareness.
The Drum is the bottleneck or constraint and acts as a drum — it sets the rhythm that the whole system should follow. In Lean Manufacturing, this is also called
“Takt Time.”
The Buffer. There are situations when when upstream processes can’t produce as much as is needed by the bottleneck; the result is that the constraint is starved and the overall system output is compromised. So, we must have a buffer of inventory that is the size of the accounted-for variation in demand. This will help to level-out variation. A buffer will assure that the constraint never has to wait and, waiting is a form of waste. Similarly, if upstream processes are producing more than the constraint has the capacity to handle, then there’s going to be excess inventory sitting in front of the constraint and, hence, another form of waste. Put another way, the buffer is the inventory and inventory is directly related to lead time (remember my blog about Little's Law?)
DBR is used to avoid either of these scenarios — the Feast or the
Famine — by dictating the batch size and frequency of the inputs into the
Buffer.
The Rope is a method by which the constraint can signal to the upstream processes (non-bottleneck processes) when
to slow down, when to stop, or when to produce faster. This is
called “Pull Scheduling” in Lean Manufacturing terms.
so in SAP terms one could say that we schedule the bottleneck (drum) with a takt-based method like heijunka or FIFO in MF50 or LAS2. The buffer may be a consumption based replenishment method like a reorder point or material forecast method, an external forecast on component level or a kanban control cycle. In the end the buffer inventory in front of the bottleneck needs to be designed exogenous to the DBR system. The rope then is some sort of a pull system that may come from another kanban, conWIP or a range of cover profile.
There are many ways on how to design a production line so that it follows a Drum, Buffer, Rope philosophy... the point is: you can do it with standard SAP-ERP.
There are many ways on how to design a production line so that it follows a Drum, Buffer, Rope philosophy... the point is: you can do it with standard SAP-ERP.
Subscribe to:
Posts (Atom)














