Critical path and running improvements

You'll use BPMN and a Gantt chart to see the chain of steps that sets the total duration (the critical path) and the slack — how late a step can be without delaying the whole. You'll estimate when a case in progress will finish. Then you'll calculate in advance how much changing a step would shorten the lead time, apply the option you like as a new version, and run it for real.

The critical path — the chain that sets the total duration#

In Chapter 21 you found the constraint (Finance review) and candidates for improvement. In this chapter you'll see which steps set the total duration, calculate the candidates in advance, and then actually apply one.

A process has steps that run at the same time. In the Moonlight Coffee proposal, once the request is received, Draw floor plan (Minji Kim) and Draft quote (quote agent) start together, and both must finish before it moves on to Write proposal.

                       ┌─ Draw floor plan  4.2 hrs ─┐
Receive request mail ──┤                            ├── Write proposal 6 min ── Finance review 1.8 days ── Reply to customer 1.5 hrs
                       └─ Draft quote      3 min ───┘

Even if Draft quote finishes in 3 minutes, Write proposal waits for the floor plan. The total duration is set by the chain that takes the longest. That chain is the critical path. If a step on the critical path is an hour late, the whole thing is an hour late; a step off the critical path can be a little late without affecting the whole.

The way to calculate this is the critical path method (CPM). It counts four times for each step.

Slack (float) = LS − ES. Draft quote has 4.2 hours of slack, so it can start that much later without delaying the whole. The steps with zero slack form the critical path.

CPM for business processes differs in three ways#

Unlike CPM for a construction schedule, a business process has the following. Process GPT Lite calculates straight from the BPMN.

Step times are measured times: the actual time from reaching the step until it ends, waiting included. You can view them two ways, Typical (median) and Slow case (p80).

Try it 1 — View the critical path#

On the Improve screen, open the Critical path tab.

The two lead times don't have to match: the expected lead time adds up the usual (median) time of each step, while the measured median is the usual time of whole cases. Here the calculation comes out shorter.

The Gantt chart and table below show ES, EF, LS, LF and slack for each step. Hatching is time waited, and the solid bar is work time.

Of the 2.2-day critical path, Finance review takes 1.8 days. That most of Finance review's step time is hatching tells the same story as Chapter 20 and Chapter 21, from a different angle.

Switch the top right to Slow case (p80) and it recalculates with each step's p80 time. The expected lead time becomes 4.9 days, and Draw floor plan grows to 20 hours. Even so, Draft quote still has slack.

When will a case in progress finish?#

For a case in progress, it recalculates using the actual time of the steps already done, the remaining time of the current step (usual time − time elapsed), and the measured times for the rest. It's shown at the bottom of the screen under Remaining critical path of a case in progress.

In the picture, Gwanghwamun Store #53 has actually reached Finance review, and Seoyeon Park has opened it. The floor plan, quote and proposal took only minutes, but the remaining 2.1 days is the time a case usually spends in Finance review, most of it waiting. The expected finish time is counted in the calendar time of past records (nights and weekends included).

Try it 2 — Run improvement: calculate before you change#

In the Run improvement tab, change a step and it immediately recalculates the lead time, critical path, flow efficiency and constraint utilization. The process itself doesn't change yet.

Waiting is calculated in the two kinds you saw in Chapter 21. Only waiting in line grows and shrinks with a queueing formula (the same shape as utilization ÷ (1 − utilization); with several people, a formula that takes the headcount into account). Waiting for the owner (the time spent waiting for the part of the day when this work is done) stays as it is. Changing the number of people or the amount of work doesn't change the setup of "waiting until the next morning."

Test 1 — What if you automate the floor plan?#

Set the type to Automate with an agent and the step to Draw floor plan, then click Add.

The floor plan is on the critical path, so the lead time drops by those few hours, but the wait in front of Finance review stays the same, so the effect is small. Flow efficiency actually goes down — an agent now does in 4 minutes what took a person 1.6 hours, so total work shrank, while the lead time stayed almost the same. Flow efficiency measures "how much less waiting," so it doesn't improve with changes that don't cut waiting. This confirms the answer to question 3 in Chapter 21 with numbers. Remove it with the × on its chip.

Test 2 — Aim at the constraint#

Under From the 5 steps of the theory of constraints:, click An agent drafts the review first; the reviewer only checks and Quote amount under 50M goes ahead without Finance review. Both options are added together.

The amount threshold (50M) is calculated from past records, so depending on your practice data it may come out differently, such as 40M.

You can also see why Finance review still takes 1.1 days. Seoyeon Park's waiting in line has almost disappeared, but the waiting for the owner, because she reviews only in the morning, is still there. That's where the next improvement candidate (reviewing twice a day) comes from.

Apply proposal — make a new version#

Click Apply proposal and a confirmation dialog opens. Look at what will change and the expected effect, then click Apply. Only the process owner and admins can do this.

Applying does the following:

Pick v2.0 in the version selector at the top of the screen to see the new version's BPMN and results calculated only from cases started on that version.

In our run, Gwanghwamun Store #53, which was already waiting at Finance review when v2.0 was applied, stayed on v1.0: it is still counted under v1.0 as the one case in progress, and its Finance review didn't become an agent pre-draft.

After the change — compare versions#

In our run, we actually ran two new requests after applying it.

Yeonnam Store #56's Finance review was recorded as 38 seconds of agent draft and 41 seconds of Seoyeon Park's work (just like the breakdown in Chapter 20). The version comparison at the bottom of the Run improvement tab shows the two versions side by side.

The bottom line keeps the prediction made when you applied it (expected lead time 2.2 days → 20.3 hrs, flow efficiency 5.5% → 11.4%), so once cases pile up you can hold the prediction up against what really happened.

Next#

That's the end of Part 6, "Improving processes." Team lead Jinyoung Jang turned ad hoc work into a formal process and fixed it, using nothing but chat, the editor and the Improve screen. In Part 7 you'll widen your view to growing and running this system. The first chapter is the agent Workroom, which opens the working folder where agents work (Chapter 23).