Kanban Bin vs Kanban Warehouse

Is there an inherent difference/advantage to kanban by bin location vs. warehouse? Warehouse seems kind of generic/vague. How do you know where they are physically needed/stocked?

Is anyone using Production Kanban today and willing to offer any “tips”?

I’ve always found the idea of running “kanban” inventory from within epicor counter intuitive. The general idea behind Kanban is to make it easy to see and manage with little complexity (below this line means you need more…). Using Epicor to do it requires that all of the transactions are 100% correct and done in a timely fashion. If I could count on all of my transactions being perfect and timely, I wouldn’t need Kanban, I would just schedule everything to where it needed to go.

My (probably unpopular) opinion.

Note, that I am not talking about Kanban jobs, which I actually think can be incredibly helpful to not have to rely on signals from a computer.

That’s an interesting persective. I haven’t given it much thought from the Purchase point of view. I am speaking more about the jobs (but I assume the same can be said for both). The problem I’m trying to solve is to make the transactions much more timely by reporting subassemblies as completed using Kanban Receipts. Today, most of them don’t get reported until the very last one is done, meaning the whole thing is ready to ship. Then they go through and report everything all at once. Sometimes we have parts sitting on a rack for weeks or months because some other subassembly is holding the whole thing up.

The kanban warehouse and bin is for sending signals for the resupply request. If you have people making the subassemblies because “They just know” (as in there is an external signal) and you just want to report that they made it, then you can use kanban jobs to report them and backflush the required labor and materials.

You can set the bin to wherever you want on Kanban Receipt. So setting the kanban warehouse/bin isn’t necessary.

1 Like

Wow! I thought I had to define a Kanban replenishment method and I could only report the receipts to that location.

So do you really have no foreplanning of jobs and requirements? Like you just stock the raw materials and the workers just make the stuff when they need it?

If you need to create jobs ahead of time for scheduling and material planning and all the stuff that most companies use an ERP for… then it’s not going to have any of that. You can’t do a kanban receipt for a regular job in the system.

Oh, yeah, let’s not forget that we have to buy the subcomponents… :slight_smile: I was about to forget that little detail. I was actually using the Kanban Code as my signal for a BPM that would prevent me from firming an MRP job that was for something that we plan to Kanban. So I do need to do that still… Really, I’m talking about one product line and about 5-6 subassemblies that we’ve been Kanbanning in reality… but not in Epicor. I feel like this might be able to be used for other areas if I can work it out though.

We do plan and forecast. The “top level jobs” get forecasted and planned like you would imagine.

That works. But if you are going to kanban the sub components, the materials needed to make those need to be set with a minimum on hand drive demand. If you don’t have that, nothing will tell anyone to buy the materials needed for it.

And as for “firming” you probably would just turn off MRP for the kanban parts so that the job suggestions aren’t generated.

2 Likes

Well, I thought I knew what I was doing prior to this thread. I intentionally left MRP turned on for those parts but made it so no one would be able to firm the jobs. I left MRP on so that it would drive purchase suggestions for the materials needed for the subassembly. The forecasting of the higher level jobs should drive demand for the subassemblies, which should spin off unfirmed jobs and thus create suggestions for the materials. Am I way off?

I guess you can try it. I don’t understand why a kanban job is better than a real job though. If they aren’t reporting when they finish an actual job, why would they use a Kanban receipt? I’ve never actually implemented the kanban because it almost always comes down to that. You either make a plan and follow it, or make as needed and report what you did. You can’t really do both (make a plan, then just do what you want).

There are times where one makes things “as needed” and you just plan for the components and not the assembly. In my mind, a Kanban job sits between a Sales Kit and a Make Part. With a sales kit, you don’t create a job and Kinetic doesn’t need one. Picking is assembly and you don’t report that labor.

In a Kanban job, you report your completion and Kinetic: creates the job, engineers the job, releases the job, issues materials, earns all the labor, moves the parts to a bin, completes and closes the job all in one step. While the material issue looks like a backflush, it is better than one because you can actually pick serial numbers and/or lots before the transaction closes.

1 Like

yes, @Mark_Wonsil. I understand why you are supposed to use kanban jobs.

What I’m asking is, specifically in @dr_dan s case, if you are planning the jobs via MRP, why would you use a kanban receipt?

The problem he’s trying to solve is “People don’t report when they are done with stuff”. So another way to report something doesn’t fix the root problem.

2 Likes

No argument here. You MUST report completions. If you can’t do that, well, that’s a whole other topic for sure.

Here’s an example from PTI. We might make a plastic injection molded part in different colors. The colorant is mixed with the resin ahead of time. This combination is a new part number. MRP blows through the bill and comes up with the amount of resin we need to buy but the exact colorant amount isn’t “known” upfront because we’ll start with a fixed amount of resin and then use the proper amount of colorant to get the color for that much resin. There’s usually a bit of an overrun to account for assembly scrap too.

If using a standard job, we would firm up and release a job with both resin and colorant, and then report the labor, issue the resin first with the correct resin/lot and then issue the colorant/lot after we know how much was used, move the finished product to stock, and then have finance close the job later. We may have to alter the Job Quantity because what was produced didn’t match exactly what MRP suggested the order for.

Or do it one step with a Kanban job. :person_shrugging:

With a Kanban job, you have to backflush the materials. So if you need to issue a different amount you can’t, it only works when you do it the same way every time.

2 Likes

I had to go back and check. You are absolutely correct. I assumed the quantities could be changed in the Lot screen.

But it does enforce that the Required Amount match the Selected Qty.

1 Like

It’s not that people are intentionally cutting corners… We were not setup to capture this work previously. Over the years, we’ve had 1 or 2 subassembly stations pop up. Since then, we’ve absorbed those into their parent jobs that ultimately do the reporting when the final product is reported. Until recently, we really only used phantoms and subassemblies were rare.

Our new product line can’t be done that way. They want it to be pre-built and on the shelf to fulfill orders as they come in (make to stock vs. make to order). I’m trying to capture the work flow as it’s really happening… and do so in the simplest (and easiest to adopt) way that works for what we’re actually doing.

I view it as better in that it captures the work being done in the simplest way. No need to have a planner review MRP suggestions and take action firming/releasing/etc. As I mentioned above, we don’t have a system or person for that… so it would be creating a new process/position or adding to an existing person’s responsibilities. The line supervisors know when their rack/bin is in need of replenishment and they tell the guys who build up the subs.

I think to summarize, the Kanban bin seems to be more useful if you have more than 1 location in a warehouse that will be kanbanned and need to keep them each managed. The Kanban warehouse is a simpler means if you only have 1 location or only care about the entire warehouse quantity as a whole. I built a BAQ report that spits out a nice KB Card and I set it up to work for both… As I am testing things on our new line, I wanted to confirm which direction I should take. I chose to do the Kanban Bin because it appears to be no harder to create/manage but gives me the flexibility to add a second location in the future without needing to undo things. We Kanban in our aftermarket site by warehouse because they only have 1 location for each thing and should only ever have 1 location for each thing.

As long as you have a stock of raw materials on the shelf to make the sub-assemblies, that’s fine. But it sounds like you also wanted purchase suggestions to get materials. So if you don’t plan the sub-assemblies, you can’t plan the materials. If that’s acceptable, then you’re good to go.

Help me understand better. MRP will create suggestions as long as I enable MRP on those Kanban subs, right? I mean I suppose I should do some more playing around in Pilot as this sounds like it is not as clear as I thought.

For things like common cables/harnesses that all share common materials, I could see us changing over to minimums/safety for reorder… we don’t do that for anything today. We rely on MRP. I feel like MRP will already be calculating lead times, receive times, seasonal demand changes, and all the parameters that go into when to re-order. Why would I want to take that out of MRP and do it manually? I’m sure I’m probably just being naive but that sounds unnecessary.

You have to plan the jobs to plan the requirements. Why throw out the plan to use Kanban? You already have it.