When Deterministic Scheduling Meets Kanban

One of the fun things about my job is that often I find myself knitting together multiple disparate systems and scheduling philosophies.  In this case, I’m working with a client on a field scheduling problem and we’re identifying how the multiple constituencies within the organization can collaborate to deliver a high level of service to the customer base – while at the same time ensuring an appropriate level of cost.

From a very macro level, we are now trying to solve an equation for two optima…..how do I deliver world class service to a customer base that needs responsive, predictable performance….while at the same time juggling crews and equipment such that I am ensuring maximum capital utilization?

When we are solving for one or the other optima, life is simple.  I can simply get more resources than I need, have them sit idle and waiting for the work to pass through – in which case the work doesn’t get delayed.  Or I can simply schedule the crews according to their optimal schedule – which may not respect commitments to my clients (the classic “cable man” or “appliance delivery” scenario).

We see the same discussion in other domains.  For example, from some of the discussions I’ve participated in within the last couple of weeks:

  1. In IT, I have a limited number of testing resources.  I need to run all of my projects through this testing bottleneck….hence I want to structure the project to reduce the time between design and release….but I also want to optimize the use of my testing resources.
  2. From a more macro IT portfolio sense, managers struggle with committing resources to projects before the projects actually can demonstrate a need for resources.
  3. In drilling, we have a limited number of rigs that must run from well to well performing drilling activities.  Meanwhile, each well requires a series of activities to get ready for the rig arrival.  Bringing the rig in too early simply means that it sits idle.
  4. In oilfield maintenance scheduling, I’m working through a backlog of maintenance tickets and trying to ensure efficient crew utilization.  (Ok – this is not a perfect comparison, as we lose a bit of the deterministic element, but still in the rough ballpark of the discussion.)

Theory of Constraints provides us some guidance here, as in TOC, we would identify the bottlenecked resources, i.e. the crews, and then ensure that the deterministic scheduling approach creates a backlog of work in front of them, i.e. the bottlenecked resources are always utilized.

Schedule Challenges

First, let’s look at how to approach this via scheduling – and this is  quite similar to a discussion a while back on release scheduling.  The basic gist is that the deterministic schedule only predicts an early readiness date for the construction crew to start their work….and then identifies a window within which they will perform the work.  The length of that window is then defined by the anticipated volatility and workload of the crew schedule.  (Which would mean that the more work they have….or the more variables that would be expected, say during a season where weather disruptions are to be expected…would mean we would want to lengthen that estimated window.)

As the readiness date approaches, the deterministic schedule dates may be adjusted based on real time field conditions.  At a defined milestone, the readiness status is handed off to the construction team….who then slot the work into the schedule for the next planning period, i.e. 2 weeks or 1 month.

This means a couple of things:

  1. We need to treat the construction date within our deterministic schedule as a target, but not a specific date on which work will be done.
  2. We need to identify a triggering task or condition prior to that date that indicates the work is ready to be scheduled within the construction scheduling queue.
  3. We need to have a separate scheduling queue for the constrained resource, i.e.  a process to define when work is ready to enter the queue….and how that queue interacts with the overall logic of the deterministic scheduling model.
  4. We need a way of assessing readiness for the work to be put into the construction scheduling queue.  If the work is not ready, we don’t want to waste everyone’s time scheduling construction.

image

Communication Challenges

From a communication perspective, we need to ensure that the systems/groups communicate very specific data between each other.  Using the model above, that would look something like this…and feel free to substitute any relevant constituency for “Crew” in this picture, i.e. drilling rigs, IT testing resources, etc.

image

The key here is to recognize the respective value that both perspectives have on the fundamental problem, i.e. that we’re attempting to solve an equation for both speed and efficiency.  Hence, we need to build a system (which includes people, process and technology) that can solve – and reconcile – for both.

When Deterministic Scheduling Meets Kanban