Wednesday, 25 May 2011

Case Study - Practical Application of Kanban in a Complex Assembly Operation


This case study covers the implementation of a Kanban system for a more complicated range of products – the steps leading up to the implementation are described as is the change management process. 

The information presented has been desensitised - the company and its products are not identified for confidentiality reasons. 
It is divided into the following sections:-

·         Background
·         Value-stream mapping
·         Customer demand analysis
·         Kanban loop and card design
·         Advantages of the Kanban System
·         Change management
·         Summary

Background

The company, which we will call XYZ Ltd, is a division of a global concern.  It produces a range of complex and sophisticated electro-mechanical assemblies, employing over 200 people.

There are 15 live products of similar overall appearance but with different sizes and different functions. Demand is not equally split between the products. 

There are 8 sub-assembly lines feeding one common process (which we shall call the gluing line) from there on to 6 calibration/testing stations.

The sub-assembly lines are roughly split by product size, but also include new lines where new products have been developed and installed.  The test lines are also split by product size and age.

The gluing station is not particularly complex, but all the products are glued. The glue typically takes 36 hours to set. A series of roller tracks holds the products waiting to set before testing.


Sketch below shows a schematic of the process flow.




Leanpal got involved with the project because the overall productivity of the factory was deemed to be too low.  Throughput was less than expected, and the products were not coming off the lines in the expected order for the end customer.

The initial project was scoped as an exercise to improve the throughput of the calibration/test department, where it was thought that the changeover time (taking products off the test stations and replacing them with the next product to be tested) was constraining the overall output of the factory.

The supervisor of the calibration/test department, whilst open to the improvement project, maintained that the changeover time (and his department) was not the bottleneck - it was the way that the products arrived at the department which held up the overall throughput.

This was quickly investigated and found to be true.  The calibration and test was split into different product families, and could handle up to 11 assemblies any one time across six test lines.

In practice large amounts of the same size product were presented to the calibration test department at the same time.

Never mind waiting for a bus and three turn up at once – a better analogy would be like waiting at a main line rail terminus in London only to find that the first 30 trains were all going to Wales, the second 30 were going to Scotland and the third 30 were going to Cornwall rather than 1st train : Wales 2nd:  Scotland 3rd: Cornwall 4th: Wales etc.

The planning system already in place relied on line supervisors constantly scheduling and re-scheduling according to the master plan, without taking into account the queuing at the common process. 
Assembly lines were also manned by individual teams who concentrated on optimising their line performance without being aware of the bigger picture.   

This meant that labour transfer to meet demand across lines was rare and expediting critical items through production was frequent and disruptive (one senior manager spent almost all of his time on this activity).

Leanpal advised the senior and middle management that a Kanban system throughout the factory could increase throughput and conformance to customers’ schedule by better ordering the presentation of assemblies to the calibration/test department.

Value stream mapping

Value-stream mapping exercises were carried out across three of the eight assembly lines to improve the line layout, task balancing, single piece flow and pull production within the assembly lines themselves.  

It became apparent that despite the scheduling carried out by the line supervisors, assembly teams took it upon themselves to change the plans dependent on their personal build preferences.

The tail was wagging the dog.

Not only were the products’ arrival at the gluing station not being coordinated, the assembly of the products within the 8 lines were not being carried out in accordance with the plans.

Value Stream Mapping also revealed that the opportunity for significant productivity savings through task balancing within the lines, not to mention across the lines.

Customer demand analysis

The overall production demand pattern was analysed using Pareto analysis, and broadly split into runners, repeaters and strangers depending on the volume of throughput.  A “model plan” was developed to explore how the runners repeaters and strangers should (in theory) be presented to the gluing line in order to optimise the delivery of finished assemblies to the calibration/test lines.

Kanban loop and card design

Kanban cards were designed and pre-printed for the runners and repeaters. 

Blank Kanbans for the strangers allowed the product name or specification to be handwritten into the Kanban.

It became clear that two Kanban loops were required – one between test & gluing, plus one to pull products from assembly to the gluing line.

The system was designed so that only the test supervisor received a copy of the customer orders to be processed.  As runner/repeater products passed testing, the (blue) Kanban cards taken off these products were placed in the back of a Kanban box situated close to the gluing line.  This triggered a differently coloured (red) Kanban card to be sent to the eight individual assembly lines, each of which had its own Kanban box.

The red Kanban card signalled the assembly line to build the product, the build order was dictated by withdrawing the card from the front of the box.

The products assembled with red Kanban cards reached the gluing line, the red cards were replaced with blue cards, then the red cards were filed in part number order waiting for the next call off.

Staff on the gluing line were responsible for matching the assembled products with the blue Kanban cards in the order dictated by the cards coming out of the bottom of the (blue) Kanban box.

This ensured that the products going through the gluing line were processed in the order required by the testing station despite the 36 hour lag time as the glue hardened.

The sketch below shows a schematic of the line and the Kanban Loops 










Advantages of the Kanban system

The whole process significantly improved delivery measured by OTIF (on time in full) by smoothing the flow through the gluing and testing processes.

Due to the visual nature of the Kanban cards, where assembly lines had no product to be pulled, the supervisors found it much easier to manage the movement of assemblers to different assembly lines where the products were required.

Change management

The implementation of the Kanban System represented a significant change for the assembly line personnel.  They were used to managing the pace and order of their own assemblies according to their preferences, and generally stuck to one particular type of assembly rather than crossing line boundaries. Night shift and day shift competed on assembly numbers by attempting to produce the easiest products rather than the ones which were actually required by the customer according to the schedule.

Individual line and shift targets set by management had encouraged this behaviour in the past.

The installation of the Kanban System smoothed the overall flow through the factory, but forced the assemblers to build strictly in the order required by the customer, and to be flexible between easy/difficult products and across the production lines.

The design of the card system itself, the Kanban boxes, and the need for strict discipline in terms of ordering the Kanban cards was also a significant change.

In order to address this culture change, the complete system was extensively modelled with stickle bricks representing products, card labels standing in for Kanban cards and cardboard boxes standing in for the Kanban box. 

Initial table-top simulations were tested by a small team of four managers and production engineers. Then glue line, assembly line and test line supervisors were taken through the simulation to model the process and deal with any questions.

Having proved the system worked through the simulation, real Kanban cards and boxes were produced and installed on the factory floor, flow charts and standard operating procedures were drawn up to explain the process and awareness sessions were run for all the shop floor personnel to explain the system.

Summary

The installation of the Kanban system took several months to design and develop.  Whilst the concept of Kanbans is relatively simple, the devil was in the detail : understanding the demand pattern, where the issues were and how to design the practical application.

Understanding lean and the overall picture needed to be developed across senior management, middle management and shop floor staff.   

The project would not have succeeded without significant application of resource from the company to analyse the detail and adapt the system into something which would work within the company. 

Nor would the project have succeeded without a strong management champion capable of seeing the big picture and committed to addressing the whole rather than fire fighting individual departmental issues.

Thursday, 30 December 2010

Leanpal - Practical Application of Kanbans


This postexplores a practical application of Kanban systems

What do we mean by Kanban?  – (Experienced readers can skip this paragraph).

Kanban is the Japanese word for ticket – the practice originates from a factory calling off the parts it needs from stores or from another downstream production cell when it needs them and not before. This is why the term Kanban is so closely associated with “Pull” production or JIT (just in Time)

Let's explain this with a real example demonstrating the difference between push and pull production, and how we helped a factory start a basic Kanban system. 

The system is not finished or perfect – it’s rather a Work-in-Progress!

The factory has 2 production departments: Cell A supplies Cell B with volume work. 

(There are other departments and satellite supply sections – for simplicity this explanation ignores them – in practice of course we had to build the Kanban System taking them into account.)

Before Kanban

The company manages the “high level” production planning very well. They have visual management showing incoming orders and their due date broken down into weekly and daily timeslots.
Incoming orders from the customer are divided into manageable portions automatically according to pre-set rules. A computer system then issues the orders direct to a printer in Cell A, where they are printed as and when they hit the printer queue.

At this stage the supervisor of cell A selects the order, matches it to a set of standard work instructions, and hands it to the team leaders responsible for the individual machines within the cell.

The team leaders/machine operators tend to pick which job to start first – in theory this should be prioritised according to the(end customer) due date, although in practice the jobs may be processed out of sequence e.g.  easier jobs are done on this shift and more difficult jobs left for the next shift.

This system “pushes” production to Cell B which may not be in the best order for the customer.

Overproduction of certain items well in advance of their required due dates physically blocks the gangways of Cell B and causes double handling of stock, as the parts required have been blocked in by parts not required at that time.  
Sometimes cell B cannot start work on a pressing customer order as it has large stocks of one component for the final build, but zero stock of the other component required to make up the assembly.  
Six of the classic seven wastes are seen in this process:- transport inventory motion waiting overproduction and defects.

Practical Application of Kanban – Phase 1

In the process described above, the company already has a “ticket” to call off production according to the end customer needs – however it is pushing this from Cell A to Cell B. The solution is to allow by cell B supervisor to prioritise the “tickets” in the order that he wants them produced to suit flow through his cell.  This was achieved by the cell B supervisor taking control of the order of the tickets at a daily morning meeting and posting these into a load levelling box according to the timeslots when he wants them produced by.  In this way cell B is now pulling the production required.

Practical Application of Kanban – Next Steps

During the next phase we need to persuade the company to produce in smaller batches, and link more closely the flow of work between individual machines in cell A and individual machines in Cell B.

Eventually we should be able to remove the intervention of the supervisor(s)  and get closer cooperation of the Cell B to Cell A machine operators themselves to drive the visual management of the “tickets”.

During most practical applications, whilst we can see what the end game (or future state) looks like, we need to proceed carefully with the people fully involved to avoid overwhelming them with too many changes at once.

Even the relatively simple change to the prioritisation of the “tickets” required three days discussions and workshops, with simulations to demonstrate how the new process would work.

Simulations using sticklebricks or lego are a great way to help people visualise the process.

If you’re interested in how we could help you and your company implement a Kanban process, or want to comment on this case study please contact us – we will also be delighted to receive any thoughts on how we could improve this implementation still further!

We'll do another post soon on a practical implementation for a more complex production system.