Correcting it, and the cost of un-deciding

The situation

3 August, mid-morning. Rowaida has just understood what 12 October was doing in the ex-factory field. Putting the value right takes her about ninety seconds. Open the order, change 12 October to 10 September, save.

The order is now correct, and the week is about to disappear.

There are three jobs here and only one of them is quick

People run the three together in conversation. That is why the second one usually never happens and the third one is always underestimated.

The corrective action was one line added to the PO intake sheet: record the buyer's delivery date in the buyer's own terms, and derive the ex-factory date from it in writing. Twenty minutes, and it covers every order Nasseef takes from now on. It is the cheapest of the three, and it is the one that gets skipped, because once the value on the screen is right the problem feels solved.

The re-deciding is where the week went. 3.5 hours of Rowaida's time, 2.0 of planning, 2.5 of sourcing, 2.5 of logistics and 1.0 of quality, sitting down one decision at a time and asking what each of them would have decided if the field had said 10 September.

Add the three up. Just under twelve hours of work at Nasseef's USD 9.60 an hour is USD 113.84. Set that against the USD 59,560.00 that lesson 3's six decisions had already committed. The whole cost of putting it right is 0.19% of the cost of it having been wrong.

That ratio is the argument for everything in this course, and it points the opposite way to instinct. Correcting data is nearly free. Data work does not look expensive because it is not expensive. The expense sits entirely on the other side of the field, in the decisions, and it is invisible from the record.

The correction that destroyed the evidence

When Rowaida corrected the field, the old value was gone. The box said 10 September. Nothing anywhere said it had ever said anything else, or when it changed, or who changed it.

In November, Thurlestone queried the air freight invoice. Their position was reasonable. They had asked for goods on 12 October, the goods had been ready in September, so why had anybody flown anything? Answering that needs one thing: a record that can say what the ex-factory field held on 26 June, the morning the sea booking was made. Nasseef could not produce it. The correction had removed the only evidence that the decision made in June had been a reasonable decision at the time.

A record that cannot say what it used to say cannot defend a decision made from it. That is not a systems requirement in this lesson. It is a habit. When you change a value that somebody else has already used, write three things beside it: the value it held, the value it now holds, and who says so. Two lines in a comment box will do it.

Whose job it is to keep versions of a whole record across several people is course 10.6's subject. What belongs here is simpler. The moment a field gets a second reader, overwriting it destroys somebody else's ability to explain themselves.

Correcting and superseding are not the same operation

Now the distinction worth more than anything else in this lesson. Getting it backwards is the commonest data mistake in an office, and no system prevents it.

• You correct a value that was never true. 12 October in the ex-factory field was never true. The record should now read as though it had always said 10 September, with a note of the repair.
• You supersede a value that stopped being true. It was true, then the world moved.

They make opposite claims about the past. Choosing the wrong one damages the record in opposite directions.

Nasseef got it backwards on the cost sheet. TH-4180 was quoted in July at FOB USD 7.40. In November, with cotton up, the costing was rebuilt at USD 7.86, and the new figure was typed over the old one because it was "the current cost". Six weeks later Thurlestone disputed the July quotation for a repeat order and asked to see what had been quoted. The July sheet no longer existed. The argument was over 38,400 pieces at USD 0.46 a piece, which is USD 17,664.00. It settled at half, so USD 8,832.00 was conceded, because the factory could not show its own quotation.

The July value was not wrong. It was a true statement about July, and a true statement about July is not made false by November. Overwriting it did not fix an error. It deleted a fact. Keeping it would have cost one extra row.

The Monday checklist

Five questions over one of your own order records. It takes an afternoon, and it is the whole course.

1. Which of my fields have a written definition? One sentence each: what is counted, from when, what is excluded, in what unit. Start with the ones that cross a company boundary.
2. Which have a named owner? Not a department. A person who bears the cost if the value is wrong for a month. List the ones where you cannot name anybody. That list is your quarter's work.
3. Which of my blanks are honest? Blank, not applicable and a measured zero are three different things. And of the columns you plan from, which have blanks that share an outcome.
4. Which fields feed a decision I cannot un-make, and on what date does that decision fire? That date is your real deadline for checking the field, and everything before it is free.
5. Which of my fields can still say what they used to say? For every field with more than one reader, ask whether a correction leaves a trace.

None of this is a systems problem, and none of it is solved by buying anything. What a system can and cannot know is course 10.2's subject, and it is worth reading next. But a system with undefined fields, unowned values and unreadable blanks is the same record you have now, arriving faster.