What is dead stock in SAP? It has nothing to do with farm animals and neither is it safety stock. The dead stock portion of your inventory is simply that amount of stock, that you do not dip into, during a defined period of time. It is waste... unused inventory.
If we do an analysis in the LIS, we can see how far the stock comes down posting issues and how it goes back up after a receipt... day by day. So naturally, you can see the lowest point during any given period. That is your dead stock portion of that period... at least approximately. And I say approximately, because if you call this graph up from the LIS transactions that are based on info structures (MC.9, MC.A etc.), then you get the ending inventory day by day - and not the lowest point during that day. If, on the other hand, you are using the document evaluations (MC50), then your dead stock calculation is accurate, since that transaction goes through all goods issue and goods receipts documents, that were ever posted within the period of examination. But that comes at a price: runtime! and if you are not on HANA yet, you will have to talk to your user about patience and the appropriate scheduling of coffee breaks.
Looking at one of those evaluation graphs, you can see that the dead stock during 2008 was at 6,000 and in 2009 we had dead stock that we never dipped into, of 2,800.
The dead stock key figure is an excellent measure to build hitlists and find 'high opportunity' items. Especially if you make it more meaningful and relate it to your average inventory holding. The higher the percentage of dead stock of your average inventory, the more you have waste lying around.
Now as I mentioned before, the LIS transactions do not really produce the key figure dead stock (even though you can make a guess in the graph) and neither does any report looking at the material consumption table MVER. The only way to get dead stock in ERP, is by using transaction MC50, which does the calculation by going through every single document (that is why that transaction is a 'Document Evaluation' transaction). And depending on the period of examination and the amount of materials you are looking at, this calculation can run for a very long time (days or even a week). And, to make matters worse, you can not just simply save the result in a table and add on to it later. No, you would have to start the analysis for a new period all over again.
Not so, if you use the Inventory Cockpit, another great Add-on tool by SAP Consulting (see my videos and blogs on Add-On tools by SAP Consulting). The Inventory Cockpit is based on the analysis result of the MRP Monitor, but... it also uses some additional key figures like dead stock and slow moving items. And those key figures are being calculated using the Material Document Aggregation, short MDA, the data basis for the Add-Ons. The MDA, as the name implies, aggregates material documents and therefore has the exact information necessary, to calculate dead stock and slow movers. But even better... it allows you to save the result in a table (many versions of it if you want) and then gives the great ability to append to the table month by month.
In other words... you save your own material consumption information in a table, much more detailed than table MVER, append to it every period and use the information - like dead stock values - whenever you need to... without the necessity to run hour long calculations.
One use for the dead stock is in evaluations within the Inventory Cockpit. the Inventory Cockpit allows you to set target inventory levels (that can be calculated based on past consumption, replenishment lead time and MAPE) and analyze your inventory levels with grahics that put the LIS to absolute shame.
More detail on the Inventory Cockpit will follow in one of my videos, but ere is a taste and some screen shots.
Inventory Analysis with the LIS is still possible, but tedious and not very effective. If you are already doing it, by all means continue... and look to replace some functions by better tools like the Monitors discussed here. But if you are not and you are looking to do something effective in SAP... Do NOT spend money on these people that show you the 'hidden power of the LIS'. It's a worthless undertaking that gets you nowhere. The entire suite of Add-On tools by SAP Consulting (all within the standard SAP namespace) will cost you about a quarter of the money these opportunists will charge you for a six months inventory reduction program. And then they walk away and you will ask yourself 'what now?'. With the Monitors your staff is empowered and ready to continuously and sustainably optimize inventory levels, safety stocks, use the right lot size procedures, decide properly on MTS versus MTO, keep dead stock down, correct lead times and much more!
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!
Wednesday, January 30, 2013
Tuesday, January 22, 2013
Strategic Materials Planning with SAP Consulting's MRP Monitor
<a href="http://blog-connect.com/a?id=5361966382900373366" target="_blank"><img src="http://i.blog-connect.com/images/w/folgen4.png" border="0" ></a>
Monday, January 21, 2013
a new course from the bigbyte academy online: "SAP-LIS analysis"
I have been writing about the subject in my blog quite often. Here is now a hands-on class, that I wanted to provide on the topic.
Opinions on the LIS differ widely and I do not want to take sides at this time. Please decide for yourself...
Opinions on the LIS differ widely and I do not want to take sides at this time. Please decide for yourself...
Friday, January 18, 2013
bigbyte online course: SAP availability check options
I am now providing online video courses on a channel on YouTube, so I can better transmit the experience I gather at various customer sites. Have a look and send me requests for subjects, that I should cover in future online courses.
Thursday, January 10, 2013
SAP ERP on HANA
Today I was invited (thanks @finnern - as an SAP Mentor and bigbyte representative - to participate at the announcement that SAP's business suite now runs on HANA, a superfast, real-time, in-memory database technology. I attended in New York City and the launch took place in parallel in Frankfurt and Palo Alto.
SAP HANA is data base technology and sometimes also called in-memory computing. I certainly don't want to (snd can't) go into details, but it makes things a whole lot faster. So far it was used mainly for BW analytics and CRM and today it was announced that HANA is also available to run the business suite, ERP, the application... whichever you want to call it.
That is very good news, because it means that your transactions can run up to 1000! times faster than they run today. Batch processing will be unnecessary and it opens up very wide windows on 'what if' analysis, reporting, production scheduling heuristics and forecasting and S&OP. And you could start the planning run a thousand times a day! Seems crazy? Maybe at first glance but think about the opportunity to keep everything current at all times. Hasso's original dream or (promise?) - real time is what the R stands for in R/2 - come true.
Hasso Plattner, the man himself, spoke first. "Design thinking is what got us here... and we are now finally dealing with the most important person... the consumer... the user". I love that. A technology company coming around. The end purpose or final cause in mind. And he admitted, just a little bit, that this was not always the case. But by saying 'finally' he sounded to me like that was always on his mind.
In fact I do believe that HANA will enable things for the user that are hard to predict yet. The launch was compared to the release of R/3 twenty years ago and I do not disagree. To have free reign on transaction usage because there is no resource issue anymore will prove to be invaluable to the performance of a materials planner and their daily work.
However, here is a word of caution: to run a falsly configured process much faster produces chaos in a blink of an eye. This stuff is for the companies that have their foundation in order and not for the techno enthusiast who does not know how to keep the inventories down whilst maintaining great service levels.
And at least one of those four poster-customers that were shown today needs a little more groundwork before they run that SAP run company too fast.
Keep your house in order, then speed it up and achieve great results. And keep in mind what Hasso says "...finally we are with the consumer!"
https://www.youtube.com/embed/QEuvpgBaerM
SAP HANA is data base technology and sometimes also called in-memory computing. I certainly don't want to (snd can't) go into details, but it makes things a whole lot faster. So far it was used mainly for BW analytics and CRM and today it was announced that HANA is also available to run the business suite, ERP, the application... whichever you want to call it.
That is very good news, because it means that your transactions can run up to 1000! times faster than they run today. Batch processing will be unnecessary and it opens up very wide windows on 'what if' analysis, reporting, production scheduling heuristics and forecasting and S&OP. And you could start the planning run a thousand times a day! Seems crazy? Maybe at first glance but think about the opportunity to keep everything current at all times. Hasso's original dream or (promise?) - real time is what the R stands for in R/2 - come true.
Hasso Plattner, the man himself, spoke first. "Design thinking is what got us here... and we are now finally dealing with the most important person... the consumer... the user". I love that. A technology company coming around. The end purpose or final cause in mind. And he admitted, just a little bit, that this was not always the case. But by saying 'finally' he sounded to me like that was always on his mind.
In fact I do believe that HANA will enable things for the user that are hard to predict yet. The launch was compared to the release of R/3 twenty years ago and I do not disagree. To have free reign on transaction usage because there is no resource issue anymore will prove to be invaluable to the performance of a materials planner and their daily work.
However, here is a word of caution: to run a falsly configured process much faster produces chaos in a blink of an eye. This stuff is for the companies that have their foundation in order and not for the techno enthusiast who does not know how to keep the inventories down whilst maintaining great service levels.
And at least one of those four poster-customers that were shown today needs a little more groundwork before they run that SAP run company too fast.
Keep your house in order, then speed it up and achieve great results. And keep in mind what Hasso says "...finally we are with the consumer!"
https://www.youtube.com/embed/QEuvpgBaerM
Friday, January 4, 2013
Operations Management with SAP
For many years now, I have been helping my clients to get better use out of their SAP investment (with bigbyte). Primarily in the areas of Sales & Operations Planning, Production Planning, Scheduling and Execution, MRP, Inventory Optimization and Procurement. Whenever we define the scope, everybody - including myself - has been speaking about 'Supply Chain Management'!
Isn't a much better description of what we're doing here 'Operations Management' ?
Let's see; Wikipedia defines operations management as "...an area of management concerned with overseeing, designing, and controlling the process of production and redesigning business operations in the production of goods and/or services. It involves the responsibility of ensuring that business operations are efficient in terms of using as few resources as needed, and effective in terms of meeting customer requirements. It is concerned with managing the process that converts inputs (in the forms of materials, labor, and energy) into outputs (in the form of goods and/or services)."
In Factory Physics, Hopp and Spearman define it very similarly "...the term operations refers to the application of resources (capital, materials, technology, and human skills and knowledge) to the production and distribution of goods and services."
By this definition we can say that operations management would include all functions to operate the business; including the operation of the supply chain. That would mean that operations management is a broader area than supply chain management, which, in turn, would mean that what we do here - improving the business result with better operations - might not address all the areas necessary, if we only look at supply chain management, but might address too many areas if we look at operations management. I therefore suggest we take on the broader term - operations management - and define the scope by being more specific in it.
Splitting hair? yes, I might get carried away here a little, but I have had too many bad experiences defining scope by use of all those buzzwords: lean, agile, MRP, MRP2, TQM, TPS, BPR and lately SCM. And I am trying to find a way to effectively communicating what we try to do.
How is this?: "Optimization is an initiative to improve operations as they are supported and managed by SAP functionality !"
Now as for the scope of the initiative... Very often a company's goal (to make money... (See my blog on final and formal cause) is depicted in a value stream. And then people look at the value stream diagram and think to themselves... "That's a supply chain!" I am not arguing that it is not, but it certainly is depicting a material flow and an information flow. And that kind of terminology is much closer relating to a framework that we can use for improvement initiatives than a supply chain could ever do.
All functions in a value stream are 'operated' by either a system or a human. And here is where we can get better: "finding a way to better operate the functions that contribute to the value creation of our information or material streams."
Therefore, all we have to do is to lay out your value stream, ask pertinent questions about what areas we can improve and then design the initiatives around them
This approach will not only help getting clarity about what we are trying to achieve, but also allows us to define the goal and how we get there. All we need to do is to look at ways to better manage our operations which drive value and therefore sales, revenue, productivity and efficiency - all buzzword-free!
Operations Management with SAP 2.0 !
Isn't a much better description of what we're doing here 'Operations Management' ?
Let's see; Wikipedia defines operations management as "...an area of management concerned with overseeing, designing, and controlling the process of production and redesigning business operations in the production of goods and/or services. It involves the responsibility of ensuring that business operations are efficient in terms of using as few resources as needed, and effective in terms of meeting customer requirements. It is concerned with managing the process that converts inputs (in the forms of materials, labor, and energy) into outputs (in the form of goods and/or services)."
In Factory Physics, Hopp and Spearman define it very similarly "...the term operations refers to the application of resources (capital, materials, technology, and human skills and knowledge) to the production and distribution of goods and services."
By this definition we can say that operations management would include all functions to operate the business; including the operation of the supply chain. That would mean that operations management is a broader area than supply chain management, which, in turn, would mean that what we do here - improving the business result with better operations - might not address all the areas necessary, if we only look at supply chain management, but might address too many areas if we look at operations management. I therefore suggest we take on the broader term - operations management - and define the scope by being more specific in it.
Splitting hair? yes, I might get carried away here a little, but I have had too many bad experiences defining scope by use of all those buzzwords: lean, agile, MRP, MRP2, TQM, TPS, BPR and lately SCM. And I am trying to find a way to effectively communicating what we try to do.
How is this?: "Optimization is an initiative to improve operations as they are supported and managed by SAP functionality !"
Now as for the scope of the initiative... Very often a company's goal (to make money... (See my blog on final and formal cause) is depicted in a value stream. And then people look at the value stream diagram and think to themselves... "That's a supply chain!" I am not arguing that it is not, but it certainly is depicting a material flow and an information flow. And that kind of terminology is much closer relating to a framework that we can use for improvement initiatives than a supply chain could ever do.
All functions in a value stream are 'operated' by either a system or a human. And here is where we can get better: "finding a way to better operate the functions that contribute to the value creation of our information or material streams."
Therefore, all we have to do is to lay out your value stream, ask pertinent questions about what areas we can improve and then design the initiatives around them
This approach will not only help getting clarity about what we are trying to achieve, but also allows us to define the goal and how we get there. All we need to do is to look at ways to better manage our operations which drive value and therefore sales, revenue, productivity and efficiency - all buzzword-free!
Operations Management with SAP 2.0 !
Tuesday, January 1, 2013
Fixing the Date after the Availability Check in the Sales Order... or maybe not?
Have you ever wondered whether or not you should fix the quantity and date after the availability check in the Sales Order? Because of the integrated nature of the availability check and because very often SAPs sales aand Distribution modul is implemented by a different team than the one who cares about production scheduling, this is a point of contention and a very possible source of mis-communication.
Usually when a sales representative enters a customer order into the system, an availability check is carried out and a screen that looks like this, pops up.
I hope this helps to clarify at least to some degree. There is so much disconnect between the sales order demand and the production program that a focused effort to align the two is necessary in most SAP installations I have seen. Get started with the decision for MTO and MTS but then look into the availability check and its setup and ability to automate. It's an effort worth taking on.
Usually when a sales representative enters a customer order into the system, an availability check is carried out and a screen that looks like this, pops up.
This screen is the result of the availability check and gives insight on whether a customers desired delivery date can be kept and, if not, what other possibilities there are. In the example above a customer wanted 840 lbs delivered on the 20th of August 2012. However, a full delivery to 8/20 was not possible and the availability check produced three options: first, on time delivery of 840 lbs is not possible (and the customer could decide to go elsewhere). Second, a complete delivery can be made on January 7th or, third, two partial deliveries can be made whereas 240 lbs can be delivered January 3rd and the remaining 600 lbs on January 7th.
It is now up to the customer what they want to do and up to the customer sales representative to communicate what the customer wants, to the rest of the supply chain. And that must be done using the right settings in your SAP. Following I describe the options you have and what's most important to note is that first and foremost a decision will have to be made whether an item is planned ahead of time (Make to Stock) and therefore is produced to stock driven by a forecast or if we plan the item not at all and wait until a dicrete demand come up. That decision has a profound impact on the availability check and the option that needs to be taken.
Typically, one analyzes past variation in sales to decide if a product is 'planable' at all but even more important is the replenishment lead time. If a customers accepted wait time to get the product delivered is longer than the time it takes to produce or replenish it, then we can wait until the customer orders before we spring in action. If, however, that is not the case, then we need to plan ahead and put the product in inventory using a forecast.
Once the decision for MTO vs. MTS has been made, we can look at the four options we have for materials that are not planned beforehand - typically MTO.
a (MTO). The delivery proposal is confirmed (to confirm the delivery proposal you click on the check mark) and the field Fix qty/date is checked on. With that option the two lines (one with 240 lbs and the other with 600 lbs) become MRP relevant and the two material availability dates (3rd of January and 7th of January) are displayed in MD04.
b (MTO). The delivery proposal is confirmed and the field Fix qty/date is NOT checked. In that case the delivery proposal is ignored and the required quantity still shows with the required delivery date in MD04. Therefore the original date when the customer wanted it is what's told production to deliver it by. Should that day fall into the past, then the system keeps showing today's date.
c (MTO). The customer request is not confirmed. To do this right one would have to click on [Continue]. If the field Fix qty/date is checked on, the demand disappears and does not show in MD04 anymore
d (MTO). The customer request is not confirmed again (clicking on [Continue], however the field Fix qty/date is left unchecked, which means that the demand remains in the system (in MD04) to the requested delivery date by the customer. A new MRP run will generate a planned order to cover the demand.
what does all of this mean for our customer, the sales rep and the production scheduler? for MTO products option a would mean that the customer accepts two deliveries on dates later than what the customer wanted. This also means that with fixing the dates, the production scheduler is informed about when the goods will have to be delivered and what was agreed upon with the customer. Option b, however, would mean that even though the customer agreed to the new dates, the sales rep tells the production scheduler to make the product immediately and to the old requested delivery date. Options c would mean that the customer does not want the product anymore and option d means that the demand is handed over to MRP which will generate and schedule a planned order to make the requested quantity. As soon as that happened the sales order would fall into 're-scheduling' functionality and the new availability check would promise the customer a date consistent with the planned order's supply date.
now on to the other case where we have a forecast and produce to inventory - MTS:
a (MTS). you click on the check mark to confirm the delivery proposal and fix the quantity and date. This implicates that the customer order schedule line items are displayed in MD04 and are consuming the respective forecasts.
b (MTS). the delivery proposals are confirmed but the fix qty/date indicator is NOT checked on. Therefore, even though the availability check couldn't confirm enough material to the date that was required by the customer, the demand from the customer order will still be displayed to the requested delivery date in MD04 and MRP will try to supply to that demand. A consumption of forecast also takes place, scheduling from the requested delivery date.
c (MTS). The order is NOT confirmed (we click on [Continue] but the fix qty/date indicator is checked on (fixed). No demand will show in MD04 and therefore no consumption of forecast takes place and no planned order is generated. The demand is simply gone.
d (MTS). The order is NOT confirmed and the Fix qty/date indicator is NOT checked on. Even though the demand can currently not be confirmed to the requested date, the demand remains intact to the requested delivery date by the customer and is shown in MD04. Even though the customer order is not confirmed it will still consume the forecast and the new MRP run will generate a planned order to fulfill the demand.
option a would correctly communicate the customer's acceptance of a new delivery schedule, whereas option b would drop a new demand into the production schedule (a new planned order would probably be generated - with exception message 30). Option c again will assume that the customer does not want the product anymore and goes elsewhere. For an MTS item this is a very likely situation since the customer only accepts very short lead times and, even though, we could try to make it as soon as possible, it would probably still take too long for the customer. If you are making to stock with a forecast, you can simply not always deliver. This situation is what degrades your fill rate in MTS. That is why you should probably never use option d in a MTS environment. That option drops demand into production that can mever be fulfilled and isn't even desired by the customer.
I hope this helps to clarify at least to some degree. There is so much disconnect between the sales order demand and the production program that a focused effort to align the two is necessary in most SAP installations I have seen. Get started with the decision for MTO and MTS but then look into the availability check and its setup and ability to automate. It's an effort worth taking on.
Subscribe to:
Posts (Atom)