takt-based scheduling and sequencing of a flow line with Kanban withdrawals !

does this blog header sound like something out of an Asimov book? Have you ever considered doing it on SAP? oh yes... it's standard functionality, adheres to lean principles and comes right out of the box.

Let's first talk about what I actually mean by that headline: If you make product that can be put in a catalog and you sell these on a regular basis, you will have to make these products on a regular basis. If you make these products on a regular basis, you need a production line and workers who can make these products on a regular basis to standard work instructions. And if you make these products on a regular basis, to the same standards, you can compare the production of one period to another. And if you want to do just this, I suggest you measure your performance with rates per period (of course, if you want to, you can also create discrete orders for the production of various lots and then compare one production order to the other - but only a job shop would do that, right... or not?).

Now, that kind of thing is called 'Serienfertigung' in SAP (I refuse to use the english SAP translation since I get most of you upset with that term and you will stop reading on). And in that kind of thing your orders request rates per period and you will be able to establish a takt to which the line is fed. If the demand is high, the takt is short and the line is fast. Think of this as like a conveyor belt which is running at a certain speed. If you are a manufacturer of Rum, you could takt a bottling line and if your demand is high you release a bottle in very short takts, but if the demand goes down you release the bottles at longer distances and therefore you slow down the rate (I know, you don't make Rum! But don't you think that your standard products couldn't be controlled by a rate per period either?)

So why would we want to do such a thing? First, if you control rates, you can control the utilization of the line without producing to the waste of overproduction. Through the takt time you control the speed of the line and you make sure that you manufacture to demand.

Second, your schedulers save a ton of transactional work. No more conversion of planned orders into Production orders. In Repetitive Manufacturing (oh my, I said it out loud!) MRP generates executable Run Schedules and if you are using Sequencing, schedules them right away within available capacity. You then perform a collective availability check and next weeks schedule is set.

But it comes even better: The plan is the plan, but the execution is by demand only! Remember, that I talked about autonomous versus central planning in one of my blog posts? Sometimes you need to leave the workers down on the line with the decision what to make and what not. They are down there, seeing a lot more than the planner in the central office in Cleveland.

That's why we use the plan to reserve capacity and order raw material, but the signal to execute and produce the order is coming when a demand exists. The way you make this work with standard SAP is to use MF50 with Sequencing to fix the plan for next week (to reserve capacity and  make raw material available). But you also have a Kanban control cycle  for every material that runs on this line. If you use the replenishment strategy "Planned Orders with MRP", then the signal 'Kanban empty' will not generate a new order but simply attach itself to one of the orders in the plan. If your workers have the ]Supply View Kanban Board' (PK12N) next to the line, they can execute right to demand and will have capacity and material available for those orders.

I know this sounds simple and like it makes a lot of sense... so... why do you still have production orders?

Is it because your Controller says that they must report cost this way? If that is the case, then ask them why they created additional Zreports to take the order related cost and normalize it to a 'material per period' cost.

 Repetitive with its cost collectors does exactly that - in standard SAP without any additional programming.