The Kanban method (billboard in Japanese), like Lean Manufacturing takes its roots from the Japanese automotive manufacturer Toyota. It was implemented to improve manufacturing efficiency and reduce waste by providing a simple and visual material replenishment process, so that every step of the production process would get just enough in a timely manner to operate smoothly, without stockpiling raw materials or components. Basically, each time a certain quantity of material is consumed - immediately visible as an empty box or an empty shelf -, a visual signal (typically a card) is sent to trigger replenishment for the same quantity. From here, the Kanban system gained influence in several fields, in particular in software development with the Agile management philosophy, or in supply chain management, as a simple method to avoid overstocks.
Origins of Kanban and evolution outside manufacturing
Originating in the 40’s/50’s, in a post World War II environment with virtually no computers or digitalization available, the Kanban had the huge merit of rationalizing the world of manufacturing through a simple and yet elegant system with little more than paper cards and boxes or bins.
In their efforts to reduce waste - and therefore unnecessary inventory on the factory floors or stores - the Toyota engineers devised a system in which replenishment was directly related to the actual consumption. They chose to follow a pull system rather than a push system. There is a fundamental dichotomy between the two. Traditionally, the production of goods is based on the anticipation of the demand (usually materialized by demand forecasts); goods are produced in advance and then pushed to the market. With pull, the system is demand-driven and goods are made to order. Production and replenishment only come when needed and not in anticipation of the demand.
There are several ways to implement a Kanban system. The simplest expressions are the 2-bin system or the 3-bin system. For instance a warehouse using a 2-bin system would display shelves sized to accommodate two boxes full of items, each box containing a Kanban card, typically including information about the item (reference, barcode, quantity, etc.). Whenever a box is empty, the box is put aside to be reused later on and the Kanban card is moved to a visible location - typically at the end of the row, on a special table or container. While the second box is used, the Kanban cards on display are taken by a handler who is going to bring back a full box from the stores and replace the Kanban card inside. Ideally, when the handler brings in the replenishment, the other box is not yet used up, but close to. The idea is simple: there is a main box and a spare one, when the spare starts to be used, it’s time to replenish the main and so on. In fact, the spare box is nothing more than a safety stock.
In a 3-bin system implemented in a factory, one bin/box of materials is placed on the factory floor to be processed for production, one bin is located at the factory store level, and one on the supplier’s premises. When the content of the first bin has been used by the production process, a signal is immediately sent to the store to pull in the content of the full bin stocked in the store. In turn, the factory store, now holding an empty bin, pulls in the content of the third bin held by the supplier, who will then refill it. The stock only comes in when consumed and depleted. An empty bin creates a Kanban trigger to order a dispatch of more materials in a predefined quantity. Again, no unnecessary stock is held further than the bin at the factory store level - a buffer or safety stock - and the process relies on bins being replaced smoothly and on the supplier being able to process the replenishment orders without unplanned delays, that is, no more than the time it takes to empty a bin.
Just like the Lean concept itself, the Kanban, with this idea of cards or signals bringing visibility through the production cycle and avoiding unnecessary accumulations, has flourished way beyond the field of manufacturing. It has been widely adopted in software development or marketing as a workflow management method to materialize logical steps. It can be as simple as presenting a task board with three columns (To-do / In progress / Done), with cards highlighting parts of the project to be implemented and to be assigned to team members. Tools like Trello can provide useful and ergonomic Kanban systems for project management.
Software development has refined the process with Agile management. A board would display buckets such as Build / Test / Complete. A list of prioritized tasks is established, such as features to be developed based on user feedback; any developer can take a card from this list to develop a particular feature; when developed this feature then enters a testing stage before being released. Additionally, each bucket comes with a Work In Progress limit designed to fit the team’s capacity: concretely, a maximum amount of cards can be placed in a bucket. The advantage of such a board is the easy visualization for the whole team of the tasks to do, the quick identification of potential bottlenecks created (e.g. accumulation of cards in the Testing bucket) and the ability to keep track of the workflow’s efficiency (how many cards are handled, how fast do they proceed from one step to another, etc.).
Pros and cons
Pros
Beautiful in its simplicity and design, the Kanban has many advantages that can explain why the method became so widespread. First of all, such a system is easy to understand and to implement - at least a simple version of Kanban would be - therefore gaining traction both with management and teams, and making change management less of a challenge. It is also flexible and versatile by nature and can easily fit a company’s specificities or be compatible with processes already in place. It is up to each company to define its bins/buckets and the logical steps that make sense within the organization. Simple analyses and reports can in turn be produced based on a Kanban system to analyze the system’s efficiency or shortcomings related to one specific step or another.
One of the main reasons why Kanban is so easy to understand is its use of visual signals: a card, an empty space, or a box. In an ideal Kanban system, everything is designed to make things obvious. Empty boxes are placed in conspicuous locations, tables with a specific size can be arranged to display defective items so that an alert is raised when the table is full and no more items can be placed on it, etc. Cards are usually of bright colors and use large fonts; they can also contain additional information such as recipes or series of moves to be accomplished to gather all simple and relevant information in one place. The main idea is to be able to assess a situation with one glance (need for replenishment, bottleneck, accumulation of defective items, etc.) and take appropriate action in a very routine and automatic manner, almost without thinking about it.
Additionally, by relying on simple visual cues such as cards, Kanban doesn’t need IT to function. Nowadays, there are digital versions of Kanban (e-Kanban), with dematerialized cards, directly integrated in ERPs, etc. They have their advantages, and can reduce some manual mistakes, but one of Kanban’s great strengths is that it was designed to function in a world without computers. An organization can implement Kanban with zero IT dependency and for workers with no access to computers - and therefore no training to use terminals and such.
The way Kanban is designed, with conspicuous signals always calling for the same immediate action in a repetitive and non ambiguous way makes it a real-time system, in fact even more so if no IT is involved. Once the system is in place, actions are automated and little communication is needed within the team. This is worth mentioning, as pretty much any other alternatives introduce delays related to decision-making (validation steps, authorization and so on).
These characteristics make Kanban a robust system, leaving little space for mistakes and misinterpretations. The pull approach of Kanban makes it even sturdier when it comes to manufacturing or supply chain management. Pulling based on actual consumption is less risky; it means that replenishment is based on facts rather than on forecasts (by nature never fully accurate). As a consequence, implementing Kanban usually leads to inventory reductions, and therefore costs reduction, storage space gains, dead stock reduction, etc. That is the goal of a Lean process.
Sensitive points
Implementing a proper Kanban system comes with a certain set of rules without which Kanban can quickly become inefficient or void of meaning. Without going into detail and displaying Toyota’s six Rules, we can highlight some caveats for those who might be considering implementing Kanban.
One of the keys to a good Kanban system is strict monitoring and observance of the rules. Kanban cards need to be placed properly, actions need to be taken in a precise and timely fashion. One of the system’s strong points lies in the automation of actions: e.g. a defective part is always placed in the same container in the same place, a card signaling a need for replenishment is always placed at the end of the warehouse row in the same way, etc. If actions are not taken properly and some steps are forgotten or twisted, the well-oiled mechanic can quickly go awry and a domino effect can be triggered. Everything needs to be monitored, all the time and handlers need to be trained precisely. With e-kanban, this places a lot of stress on the accuracy and reliability of the IT system, in particular, the electronic inventory accuracy. E-kanban was meant to avoid manual mistakes, but errors in data entries or bugs in a system do happen…
Kanban is initially flexible in nature in the way it can fit to a lot of situations, but once fully implemented and fine-tuned for bin sizing and so on, the system is meant to be very strict. In fact, once implemented and unless challenged anew, Kanban loses all flexibility. For instance, once set, the amounts placed in bins/boxes are not supposed to be changed by the user to accommodate a specific situation. This poses the threat of lack of adaptability. Unless used in an extremely steady environment, Kanban systems need to be reassessed on a regular basis as additional tuning might be needed.
Cons
Kanban is not suited for every situation either. As is often the case, the devil is in the details. First of all, Kanban’s simplicity can sometimes hide a lot of hidden complexity… Two bins seem simple enough, but properly sizing them in order to make sure they operate smoothly without stopping a production process or clogging a supply chain is difficult. By using Kanban, a lot of organizations feel that they will escape the need to forecast demand that comes with a classic push system. Partly, they will, but only to a point. The size of the bins, boxes, buckets, or any space to be filled in a Kanban system is in fact the product of a forecast. It is directly related to the amount an organization chooses to use as a buffer or safety stock. It is a risk mitigation, and therefore based on a risk assessment. The fact that most of the time, this assessment is not data-driven, but rather empirical and made through months of fine-tuning and operating by dichotomy and readjustments, doesn’t make it less of a forecast. The fine-tuning of a Kanban system can be a lengthy process if not made properly and if no proper assessment is made of the complexity of the reality covered by the size of the bins.
In particular, special emphasis should be placed on the ability to get replenishment from suppliers and third parties. The size of the bin can be construed as a safety stock, which in turn is directly related to the supplier’s lead time. Basically, the question is the following: how long should a bin last to cover the needs of a process for the time it takes for a supplier to deliver new items? If the supplier is reliable and lead times are consistent, the answer is straightforward. Experience shows that it is not always the case however. Therefore, in situations where suppliers are not reliable, or lead times are fluctuating, or the quality of materials used for a production process is itself fluctuating, Kanban can be tricky to put in place. Not being able to take into account lead time fluctuations could in the end lead to unnecessarily large buffers being kept at all times.
The same holds true when demand varies over the year, with strong seasonality for instance. Even with a pull system, the demand needs to somehow be accommodated to avoid lost sales. Whether for production or supply chain management, bin sizing should not remain constant when such is the case. At the same time, if bins are constantly being reevaluated, the system loses a lot of its meaning. Therefore one of the main reproaches that could be made when it comes to the Kanban system is the lack of proactivity and adaptability.
Kanban also becomes inefficient - or much more difficult to implement - when it comes to production in batches and economies of scale, which are by nature quite opposed to a “just enough” way of thinking. On the contrary, the idea is to produce in large quantities in one go (or buy more by placing a big order to a supplier for cheaper prices) to reduce costs. This means also taking the risks of producing or stocking too much in anticipation of a demand that might not be forthcoming. Taking such risks can come with high reward, while Kanban in a more steady way, might not disappoint, but might not be so rewarding either.
Finally, it can be argued that Kanban relies on a very local vision, with an optimization of step after step, and a local and simple action to be taken as an answer to a particular event. It derives its strength from such a local vision, but at the same time Kanban remains blind to network effects, a bad distribution of flows or resources across a system, etc. It will also be weak against systemic risks. For instance, in some B2B businesses, certain categories of products only exist if a certain customer exists. When said customer disappears, the need for the product disappears entirely. Kanban is simply not designed to take such a risk into consideration. Same goes for obsolescence issues. These disadvantages do not disqualify Kanban as an efficient system. They just highlight that it should be used with an understanding of its inherent limits.
Kanban applied to SCM and inventory control
Initially related purely to manufacturing, Kanban has followed its sister method, Lean, to the field of Supply Chain Management (SCM). The principle remains the same: a simple and visual method to issue a purchase order for a predefined quantity when stock is depleted, in order to minimize inventory and the risks associated. This is not surprising, as Kanban initially came from the observation of consumers in supermarkets. Consumers do not buy goods to stockpile them at home; they buy what they need and come back again when the goods have been consumed. They do so with the knowledge that there will always be more goods available whenever they need them. In the supermarkets themselves, the shelves are organized to hold a certain amount of products and never more; whenever they start to get empty as the content has been consumed, they are refilled accordingly. There are classically several standardized depths of shelves to take into account the rotation of the products. Any handler going through the shelves can quickly assess at one glance whether a refill is needed or not.
What is true at the local level for supermarkets and points of sales in general can be extended further. In SCM, the 3 bins method could be interpreted as follows: a first “bin” is placed at the store or point of sales level to satisfy the initial demand, a second bin is located at the warehouse level (or any equivalent inventory point), and a third one is at the supplier’s. When the store uses its stock, it signals for replenishment from the warehouse, which then turns to the supplier. What was said above about bin sizing remains true: the size of the “bin” is directly related to the amount of safety stock the organization is willing to hold and to the supplier’s lead time and their ability to replenish in a reliable fashion. Additional considerations can come on top at the supplier’s level, such as MOQ (Minimum Order Quantity), as the supplier might not be willing to replenish unless certain quantities are met, which can be common to several references and might not be considered SKU by SKU. Sometimes it boils down to a matter of price per unit. Small replenishment might be possible, but costly.
The pros and cons of Kanban for SCM are the ones mentioned earlier and they are not different from what could be said for manufacturing. Applying Kanban usually reduces inventory (and the risks and costs attached), partly at the cost of flexibility and by introducing a stronger dependency to suppliers and their lead times. It makes it trickier to benefit from network effects or leverage supplier MOQs (Minimum Order Quantity), MOVs (Minimum Order Value) or price breaks.
Additionally, by using a rather simple view of inventory, Kanban is blind to situations where erraticity might be a plus. Kanban is based on the premise that the production needs to move forward without interruption and replenishment needs to keep coming whenever the stock has been used. However, there are situations where stockouts can be desirable when it comes to products at the end of their life cycle or seasonal products. There are also situations where unreliable suppliers, or rather suppliers with long or erratic lead times, can mean lower prices per unit. Selling some items which are sometimes out of stock but come with high margins can be a good thing, and conserving safety stocks (or full bins) high enough to never get out of stock is usually not practicable. For some products, leveraging the fact that they are produced intermittently (e.g. local strawberries) or are susceptible to market fluctuations (e.g. productions linked to world market prices) can be a huge plus for an organization. Kanban doesn’t really allow it.
However, when demand is extremely stable, or extremely low, so much so that forecasts are highly inaccurate, Kanban can be one of the better options available. For instance, in fashion, some small points of sales are subject to low volumes of sales in a very erratic way. Some SKUs might get only a couple of sales during a season. For these points of sales and these kinds of references, Kanban can be a go-to solution, because anything else is failing.
We already explained that Kanban alleviates the need for forecasts but does not suppress it - bin sizing being a kind of forecast per se. It can therefore be argued that mixed approaches are possible. Forecasts can invade Kanban, and reciprocally, it is possible to integrate a flavor of Kanban within a forecasting process through some heuristics for the situations that require it.
Lokad’s take
The power of Kanban is the power of well-chosen heuristics and enforced invariants. They are an approximation, yet they are sturdy and unmoving. They are implemented with correctness by design and risk limitation in mind, which is often difficult to outperform. It could be said that there is an “uncanny valley” between Kanban and other methods. Kanban can definitely be surpassed, but doing so requires a lot of effort. The use of simple forecasting tools (classic mathematical models and such) or half-baked AI solutions - especially on some types of data - usually won’t do the trick. For a lot of situations, the forecasting method needs to have real superiority to overcome the benefits of Kanban and its simple bins/safety stocks and cards.
However, this simple method remains a static one, with a local vision, unsophisticated and blind to certain classes of risks (and rewards). It won’t be useful when it comes to network issues, or assessing the advantages of irregularities. At Lokad, we believe that it is possible to make the best of both worlds and going beyond Kanban by leveraging, when the situation requires it, smart heuristics anchored in the reality of business. This is one of the ideas behind the prioritized lists that we try to implement with the Quantitative Supply Chain: keeping things simple and visual for the user, while providing an evolutive, measured, pondered and revised solution that is always data-driven.