Lessons · Lesson 4 of 5
The field nobody owns
Separate the person who types a value from the person who can make it true, find the fields in your own record that have no owner, and price what they cost.
Lesson 4 of 5 · 17 min
The situation
After the 12 October affair, Fathy Nasseef asked for something narrower than a project. He printed the order record, all 62 fields of it, put four people in a room for three hours, and asked one question of every field in turn.
Who can make this value true?
Not who types it. Not whose department it belongs to on the organisation chart. Who, if the value is wrong this afternoon, is able to go and find out what it should be and change it with authority.
| Answer to "who can make this true" | Fields | Exceptions raised that quarter | Exceptions per field |
|---|---|---|---|
| Exactly one person, and the room could name them | 41 | — | — |
| More than one person could change it | 13 | — | — |
| The 54 owned fields together | 54 | 3 | 0.056 |
| Nobody. "The system fills it" or "whoever gets there first" | 8 | 6 | 0.750 |
Nine exceptions were raised on Nasseef's orders that quarter. Six of them came from the eight fields nobody owned. Per field, an unowned field produced 13.5 times as many exceptions as an owned one.
Owned fields go wrong too. Three of them did. The difference is what happens next. An owned field fails and gets fixed. An unowned field fails and stays failed. The person who notices is not the person who can correct it, and there is no third person whose week gets worse if it stays wrong.
The owner is the person who bears the cost of it being wrong
That is the whole definition, and it is more useful than any of the alternatives.
It is not the person who types the value. Rowaida types into about forty fields a week and can make nine of them true by herself. For the rest she is a courier carrying somebody else's claim. That is a respectable job, as long as everybody knows that is what it is.
It is not the department named at the top of the screen either. The fabric in-house date sits on the sourcing tab, and sourcing cannot see the loading bay.
The test is one question, and it is deliberately about consequences rather than authority. If this value is wrong for a month, whose week gets worse? If you cannot name a person, the field is unowned, whatever the organisation chart says. If you can name three, it is worse than unowned, and the next section is about that.
What an unowned field cost
Take the fabric in-house date, the day the roll physically lands in Nasseef's store. Three people could fill it: Refaat Sorour in the store, Sherine in sourcing, or Rowaida. So it was filled by whoever happened to be looking. Over 46 orders that meant it was filled on 31 of them, on average 6.4 days after the roll had actually arrived.
That is a field describing an event that had already happened, recorded on average most of a week late.
It matters because the cut release runs off that field. Split the 31 orders by how the field was filled:
- On 11 orders it was entered the same day. Cutting started on average 2.1 days after the roll landed.
- On 20 orders it was entered late. Cutting started on average 5.9 days after the roll landed.
A difference of 3.8 days across 20 orders is 76 order-days of float, used up by a typing lag rather than by anything physical. Float is what pays for the next problem. On those orders it had already been spent before the next problem arrived. Recovering the dates took 22 line-days of weekend overtime, at the 35% premium on Nasseef's USD 1,180 line-day, which is USD 9,086.00.
The fix was the three-hour meeting: four people at USD 9.60 an hour, USD 115.20. It named one owner for the field, the store keeper, because he is the only one of the three who can see the roll. It also named one deputy for when he is not there. That is 78.9 times the cost of the meeting, in one quarter, from one field.
Two owners is a different failure, and it is quieter
Thirteen fields could be changed by more than one person. Four of them actually had been, by two different people, in the same week.
The ship date was the memorable one. Rowaida wrote 4 October, because that was what she had agreed with the buyer. Wael Meshref in planning wrote 9 October two days later, because that was what the line plan gave him. Neither was wrong. They were answering different questions, and the field only had room for one answer.
The freight booking was made on the Thursday morning, off whichever value was in the box at 08:14. Nobody chose which of the two dates the booking was made from. Last write wins is not a decision. It is the absence of one. It produces a record where the timing of two people's keystrokes quietly outranks both of their judgements.
The fix is not a permission. It is a definition, and it splits the field in two. Committed ship date, owned by the merchandiser, is what the buyer has been told. Planned ship date, owned by planning, is what the line plan currently supports. Two owners, two fields, and the gap between them is now a visible number somebody has to close rather than a coincidence of keystrokes.
Who is allowed to change what, and how several people work on one record without overwriting each other, is course 10.6's subject. What belongs here is that the underlying problem was never a permission problem. Two people writing to one field is almost always two fields wearing one name.
Check yourselfA field on your order record is filled automatically by an interface from another system. Who owns it?Show the answer
Somebody in the system it comes from, and your job is to find out who, by name, before you rely on it. An automatic field feels ownerless and is not. Every value has a person behind it somewhere, and the interface only moves it. The dangerous version is a field that used to be typed and is now fed. The original owner stops watching it the day it stops being their typing, and nobody at the far end knows that your cut plan depends on it. Ask what the value means at source, ask who changes it there, and ask to be told when its definition changes.