Reservation systems have been observed in Kanban implementations since 2008. They are used immediately upstream of a delivery kanban system, to indicate the desired start date of the request for work (a work item).
Reservation systems have been observed in Kanban implementations since 2008. They are used immediately upstream of a delivery kanban system, to indicate the desired start date of the request for work (a work item).
2-phase commitment
Reservation systems facilitate 2-phase or asynchronous commitment between the requestor and the delivery kanban system (also known as a service or workflow). 2-phase commitment can be useful when it is difficult to get the requestors, the customers or businesspeople, together with the delivery organization, at the same time, or, when it is possible to determine that something is needed, without a specific commitment to when it is needed or when it should be started. If scheduling can be separated from the determination of need (¨yes, we want it¨ or ¨no, we don´t need it¨) then a 2-phase commitment is useful. It enables business people or customers to make decisions about what, independent of the delivery organization that controls the scheduling of when.
2 types of reservation systems
We have observed two ways to implement 2-phase commitment, and hence reservation systems, the first is a simple queue, as observed in the Posit Science case study (2007-2009) and used in our Kanban System Improvement (KSI) training, and the second is a schedule or calendar, first reported in a blog by Sami Honkonen in 2011.
While queues are useful and can provide an additional lead time for signaling other long lead time activities such as marketing and public relations, they are relatively simple and quite boring. For example, the Posit Science case study features a 10 place FIFO (first in, first out) queue, and the delivery rate of their kanban system is approximately 1 item per week. Hence, the ¨Top 10¨ queue provides 10 weeks of advanced first-phase commitment. Something in the queue is required and its approximate start date is determined by its place in the queue and the delivery rate of the kanban system.
However, it is schedules or calendars with bookings to start a request item on a given date that is much more interesting and powerful. The remainder of this article discusses the utility of a booking system, particularly for dependency management. For clarity, the terms ¨booking¨ and ¨reservation¨ are used interchangeably in this article.
Implementing a Reservation System
A reservation system is typically implemented as a calendar using weeks of the year and visually displayed above or to the left of a kanban board. Each ticket in the calendar represents a request to start an item on that date – in other words, a request to pull the item from the upstream backlog or pool of options, or ready buffer, on the date indicated. Note that it is a request to start, the action over which we have control, and not a request for delivery on that date. Items with hard delivery dates are usually handled with the Fixed Date class of service, and the requested start date would be reversed out from the desired delivery date, based on anticipated lead time.
The number of slots per week should be equivalent to the average delivery rate (or throughput) from the kanban system for the same period e.g. 1 week. We know that delivery rates tend to exhibit a Gaussian probability distribution and hence it is reasonable to use an average. We do not want to take bookings for more than the average throughput of the system as this would overburden the system and cause problems and delays.
However, we do not want to throw away one of the great advantages of a kanban system – deferred commitment. We do not want the use of a booking system to schedule work in advance to encourage a lot of ¨big planning upfront¨ and early commitment when that isn´t appropriate. So, our booking system needs to be flexible. It needs to be able to cope with late-breaking news, new arrivals, last-minute reservations, and important and urgent work that must take precedence over existing bookings. We call this adaptation to our reservation system, a dynamic reservation system.
Implementing a Dynamic Reservation System
To cope with uncertainty such as the arrival of last-minute requests, or late-breaking requests that are both urgent and critical, we need to introduce classes of reservation – we need to treat reservations differently based on their risk. To adequately hedge our risks, we should allocate capacity for different classes of risk. Classes of the reservation should generally reflect the cost of delay and indicate the preference a request is given for starting on the requested date.
The image in Figure 12.12 taken from our book Kanban Maturity Model, illustrates how to calculate the allocation of classes of booking using real throughput data from a business in Germany. In this example, the average throughput is 20 work items per week, and the range is 8 to 32. The minimum throughput seen in recent history is 8 items per week. This allows us to offer 3 classes of booking with the following capacity each week…
- Guaranteed class of reservation – guaranteed to start on this date with a capacity of 8.
- Preferred – will start if capacity is available. If not started may be bumped to guaranteed for the next or a subsequent replenishment, with a capacity of 6.
- Standby – indicates preferred date but the item will compete for available capacity on merit. If unselected, a preferred reservation may be made for a later date, using the remaining capacity of 6.
These 3 classes of reservation seem adequate to handle most circumstances when coupled with 4 classes of service once an item is started and pulled into the kanban system. The goal is to put some adequate expectations around customer experienced lead times, delivery predictability while preserving the flexibility to cope with items of varying urgency and varying degrees of notice for a request before its start date. The reservation system should enable us to avoid too much unwarranted and undesirable delay before an item is started while enabling us to have the confidence to defer commitment and not start items needlessly early.
Where to implement a Dynamic Reservation System
We recommend that such reservation systems are implemented for internal shared services, platform services, and anything that handles irrefutable demand (or dependent demand generated by a request already committed to a customer). They are extremely useful for managing dependencies and any form of irrefutable demand that cannot be rejected, but the demand can be shaped, and the flow smoothed out by carefully scheduling ¨must do¨ items.
Reservation systems can also be implemented on external customer-facing services. They are likely to be useful when coping with low or broken trust relationships. They are particularly useful for genuine fixed delivery date demand where commitment and start date are deferred until close to the last responsible moment. However, they will always be more effective after internal capabilities have been improved first.
Conclusions
Reservation systems enable us to take better control of when items will start, they are not a guarantee of delivery. To improve delivery timing and predictability, it is always necessary to improve the predictability of the kanban system lead time and to have a thin-tailed lead time distribution. Reservation systems simply give us another tool, another practice to utilize, to enable better customer satisfaction and fit-for-purpose service delivery.
