Nine actions, and the line drawn through them

The desk that approved everything

Serdana Apparel makes woven outerwear and skirts. It runs about 1,400 machines, has four merchandisers, and carries roughly forty live orders at any moment. In March it connected an action system to its order records and its mailbox.

Be clear about what that means. The word covers three different things, and only one of them is this course. A system that writes text for a merchandiser to send is the subject of course 15.2. A system that reads a document and fills fields in a record is the subject of course 15.3. This one does things. It writes to records. It sends messages. It books space. It issues an order. Nothing it does is a suggestion. Every output is a change in the world, or a change in a record somebody else will act on, which is the same thing with a delay.

Suha Ashour runs the merchandising desk. She set the system up the way any careful manager would. Nine action types, and every one behind an approval. The system proposes. The proposal appears in a queue. A person reads it and clicks. Only then does the action run. Everybody in the room agreed this was the prudent setting.

Nobody priced it.

What the prudent setting cost

Eleven weeks later, Ashour priced it. Two numbers came out, and they are not the same size.

The reviewers' time is easy to work out. The desk handled 580 proposals a month. Each took a measured average of 4.1 minutes to read and click. That is 39.63 hours a month. At Serdana's own loaded merchandiser rate of USD 11.50 an hour, it comes to USD 455.75 a month.

The second number is the wait. A proposal sat in the queue for an average of 6.38 hours before somebody clicked it. That includes overnight and weekend gaps, because the order does not get those hours back. Ashour replayed six months of closed orders. For each action type she measured how many days of order clock the wait actually cost. Serdana prices a day of slip on the critical path at USD 214.00, taken from its own late-delivery history. Course 10.3 derives a figure of that kind properly, and this course takes it as given. Added up across the nine types, the approvals cost USD 14,870.86 a month of order clock.

USD 455.75 against USD 14,870.86. That is a factor of 32.6. Every meeting about the agent, for eleven weeks, had been about the smaller number.

Nine actions, and what was measured about each

Here is the list Ashour worked from. It is not a list of features. It is a list of actions, which is the only inventory that matters, and it was written before anybody looked at a tool.

Read the last column first, because it is the column nobody expects. Answering a buyer's status query is the action the desk most wanted off its hands. Removing its approval wait saves Serdana 0.00 days of order clock. The buyer gets an answer sooner, which is a real and decent thing, but it does not move the ship date by an hour. Booking container space is the row that frightened people most, and it was carrying 0.90 days of clock inside an approval queue.

Two actions with exactly the same error rate

Now the number the conversation usually starts with. Ashour measured how often each action type would have been wrong. She replayed six months of closed orders, let the system propose, and compared each proposal against what the desk actually did and against what turned out to be true.

Two of the nine came back at the same figure. Allocating a fabric receipt line was wrong 1.9% of the time. Answering a buyer's status query was wrong 1.9% of the time. Identical accuracy, measured the same way, over the same six months.

One of them is on the machine side of Serdana's boundary today. The other can never go there, and no improvement in accuracy would move it.

That is the shape of this whole course. Accuracy is one term of four, and it is not usually the term that decides:

value of removing the approval  =  n  x  D  x  V
expected cost of removing it    =  n  x  p  x  C

n is how often the action happens. D is the days of order clock the wait actually costs. V is what a day is worth. p is how often the action is wrong. C is what a wrong one costs. Accuracy is p. A buyer answer and a fabric allocation share a p. They differ in C by a factor of nine, and in D by everything.

Three settings, and the two everybody argues about

With those five terms measured for all nine rows, three whole-desk settings can be priced. Lesson 4 does this row by row. Here is the summary, because it frames everything in between.

approve everything     clock cost 14,870.86   plus 455.75 of hours
approve nothing        gain      14,870.86    expected loss 18,209.06   net  -3,338.20
the line, four of nine                                                  net  +4,559.14

Approve-nothing is worse than approve-everything, and both are worse than a line drawn through the middle. The two settings that get argued about in most factories are the two worst ones available. The gap between the better of them and the real answer is over USD 4,500 a month, on a desk of forty orders.

What this course does not settle

It is worth being explicit, because four other courses touch this ground and none of them owns the boundary.

• 15.1 owns what these systems can and cannot do at all, and the arithmetic of when an answer that is mostly right is worth less than none.
• 15.2 owns the daily craft of getting usable work out of one, and the review cost you must count against the time saved.
• 15.3 owns extraction from your own documents, and the reconciliation problem underneath it.
• 15.5 owns governance, the contract, and what a factory owes its buyers and its workers.
• 10.3 owns the critical path itself: who is allowed to move a date, what float is, and who owns it. This course asks only whether a machine may be one of the people who moves one.
• 24.1 owns the arithmetic of decision points and latency. Lesson 4 leans on its result heavily and does not re-derive it.

I run a merchandising desk in a garment factory. Below is a description of one of our processes. Turn it into an inventory of ACTIONS, not features: every distinct thing a system could be permitted to DO, written as a verb against a named record or a named counterparty, one per row.

For each row give me four empty columns to fill in myself: how many times a month it happens, how many days of order clock its approval wait currently costs, how often it would be wrong, and what one wrong one would cost all the way to the end.

Then, in a separate list, flag any row that (a) states that something was checked, inspected, received or approved, (b) sends something to a party outside my company, or (c) writes a field that keeps no history of its previous value. Do not tell me which rows should be automated. Do not guess any of the four numbers.

Here is the process:

What you own at the end of this lesson

An inventory of actions rather than of features. The two costs of an approval, in hours and in clock, written in the same sentence. And the knowledge that two actions with identical accuracy can belong on opposite sides of the line.

Next: what a wrong action actually costs, and why the undo button answers almost none of that question.