A simple definition for lean is to reduce lead times through the elimination of waste. Inventory is waste, which led to the creation of JIT. Just In Time also known as Just Isn't There (when it's rushed in as a tool and not well thought out and implemented) came about to improve quality, reduce cost and improve cash flow.
One of the most widely publicised tools for implementing JIT is kanban. Toyota uses simple kanban cards which circulate through the supply chain to trigger replenishment of parts to the line. When I worked on the sealer line, every time we would start using a new stack of sound dampening asphalt sheets, we'd pull the kanban card and drop it down a shoot. Then a little bit later, a waterspider (material handling person) would drop off parts and pick up the kanban cards for the next delivery run. These internal kanban cards would go back to the warehouse and trigger external kanbans that would order more parts from the suppliers. It's a beautiful system in it's simplicity. The little cards work better than any ERP system I've seen because the cards self correct and reflect reality with no additional keystrokes. If you get a bad batch of parts, the kanban gets pulled sooner and new parts are brought quickly based off reality, not a schedule (but that's a whole nother discussion).
When working with non-manufacturing groups, transparency is often a problem. You can't see the work, because it's information and it's in peoples heads. You can't see what's coming at you and how do you plan and adjust resources? Hmmm, how about a kanban system?
'No, you don't get it, that won't work here, our work is to complex and changes to often. Silly little cards are for manufacturing'
Okay, so tell me about what it is you do? In this case it was a group of engineers designing very expensive custom devices. These devices had hardware, software, electrical, mechanical, hydraulic and pneumatic systems. The group was broken up by system type.
Some groups worked a lot of overtime, some not so much and others, it depended. Resource utilization was a primary problem. Timeliness of information was another. There were a bunch of orders piled up, so when you finished with one, you grab the next, or your part of the next. Oh wait, here's another problem. Some groups were way ahead of others and the systems are not completely independant. As groups got caught up, they would find issues which resulted in rework for those that worked ahead, now they were behind.
What to do? It was a multifaceted problem with several dimensions. One of the first issues was to look at the complexity model for the devices. The devices fell into several product lines. Within those product lines there were about 5 distint layers of difficulty to design ranging from, we've done it before (plug and play) to never done that (and with that). I worked with the team to re-evaluate the model and came up with a simple and reliable model. Now they could look ahead and know what faced them in terms of work load and not just number of orders.
As with most lean tools, it can be done in a simple way, the tough part is having the discipline to follow the process. From a technical side, each team set up shared folders on their network. One for work in process and completed projects. When they were ready to start a new project, they would go to their supplier and pull the next project from their "Completed Projects" folder and move it to their "WIP- Work In Process" folder. When they completed it, they would move it to their "Completed Project" folder and so on.
This process in and of itself is pretty simple and straight forward. It provided a simple way to visually move work through the system with no complex software or added cost. The novel part was that the team developed limits within their respective folders and an elaborate reaction plan.
It was not a work to keep working as long as the suppliers Completed Projects folder had work. They would work till their Completed Work folder hit it's limit. At that point they would stop and check with their customer to see what the issue was and why they hadn't pulled anything as they were off takt. If they could help them, they would.
If they couldn't help them, they would go back to their process and see if anyone else in their group needed help. If not, they would then look at their special project lists and any outstanding kaizen items. Finally, they had developed in skill and out of skill development plans. One electrical engineer noted that a hydraulic system follows a lot of the same rules as an electrical circuit and started to train on how he could jump in to help as they often completed their designs before the mechanical engineers.
Over time the teams became much better balanced and understood each others functions which further helped them improve their own designs. They also weren't getting way ahead and creating additional mistakes. In addition to balancing workload, they improved their flow and reduced lead time and overtime.
The teams also played with various magnet boards and small dry erase cards that they put up to show visually where work was in the system and derive performance metrics around the system. Over time, once the discipline was installed and they knew what they wanted, they could then start to look at ways to automate or get software to help. But the last I heard from them, they were still using the simple folder and magnet board process.
As with most lean tools, it can be done in a simple way, the tough part is having the discipline to follow the process. From a technical side, each team set up shared folders on their network. One for work in process and completed projects. When they were ready to start a new project, they would go to their supplier and pull the next project from their "Completed Projects" folder and move it to their "WIP- Work In Process" folder. When they completed it, they would move it to their "Completed Project" folder and so on.
This process in and of itself is pretty simple and straight forward. It provided a simple way to visually move work through the system with no complex software or added cost. The novel part was that the team developed limits within their respective folders and an elaborate reaction plan.
It was not a work to keep working as long as the suppliers Completed Projects folder had work. They would work till their Completed Work folder hit it's limit. At that point they would stop and check with their customer to see what the issue was and why they hadn't pulled anything as they were off takt. If they could help them, they would.
If they couldn't help them, they would go back to their process and see if anyone else in their group needed help. If not, they would then look at their special project lists and any outstanding kaizen items. Finally, they had developed in skill and out of skill development plans. One electrical engineer noted that a hydraulic system follows a lot of the same rules as an electrical circuit and started to train on how he could jump in to help as they often completed their designs before the mechanical engineers.
Over time the teams became much better balanced and understood each others functions which further helped them improve their own designs. They also weren't getting way ahead and creating additional mistakes. In addition to balancing workload, they improved their flow and reduced lead time and overtime.
The teams also played with various magnet boards and small dry erase cards that they put up to show visually where work was in the system and derive performance metrics around the system. Over time, once the discipline was installed and they knew what they wanted, they could then start to look at ways to automate or get software to help. But the last I heard from them, they were still using the simple folder and magnet board process.
Posts
