Two records, one order

One question, three records, three numbers

On Tuesday morning Bethan Coyle sends one line of email to Meranti Garments. She is the product technologist at the brand Wildersmoor. Her question: how many metres of the check fabric are committed?

Menaka Sathar is the merchandiser. She asks three people. She gets three numbers.

None of the three is wrong. Nobody made a mistake. They are answers to three different questions. Her week goes badly the moment she treats them as one question with a gap in it.

The gap is fully explained. Explaining it is this whole course in miniature. Order WM-8814 is 24,600 pieces of the Larkfall overshirt. Each garment takes 1.86 m of cloth. So 45,756 m of cloth ends up inside garments. The cutting room at Meranti then adds 5% for the ends of rolls, for splices, and for the losses in the marker. (The marker is the cutting plan that lays every pattern piece onto the cloth.) That 5% is 2,287.8 m. Amberdene sells in steps of 500 m, so the order rounds up by another 456.2 m. Together that is 2,744 m.

Neither of those two decisions is recorded in either system. The 5% is a rule the cutting room applies. The rounding is a habit of the sourcing office. Both are typed in at the moment the requisition is raised, and they leave no trace. That is why nobody in the building could rebuild the difference between 45,756 and 48,500 without being told.

A system of commitments and a system of definitions

Take the acronyms away and the split is simple enough to hold in your head.

An ERP is a record of commitments. ERP stands for Enterprise Resource Planning. Its unit is a transaction: an order accepted, a purchase order raised, a delivery received, an invoice posted, a payment made, a quantity moved from one place to another. Every row has a date. Most rows have a money value. The whole thing is built so that a row cannot quietly stop being true. You do not delete a goods receipt. You post a reversal, and both stay visible afterwards. That is not a limitation. It is the point. The system exists so that what the company owes, and what it is owed, can be rebuilt a year later in front of an auditor.

A PLM is a record of definitions. PLM stands for Product Lifecycle Management. Its unit is a version of a description. This is what the Larkfall is. These are its measurements at each size. This is its bill of materials, this is the fabric, this is the shade. This is the comment the fit session produced, and this is who approved it. Every row is expected to change. The system's whole design problem is how to let a thing change while keeping a record of what it used to be.

Those two designs are not two flavours of the same database. They are near-opposites.

Two questions that decide who owns a fact

You will spend a lot of your working life deciding which screen a fact belongs on. Two questions settle almost every case. They are worth memorising, because they beat any list of fields.

First: if this fact changes, does somebody owe somebody money differently, or does the product become a different product? The first is a commitment. The second is a definition. The Larkfall's price to Wildersmoor is a commitment. The depth of the Larkfall's back yoke is a definition. (The yoke is the panel across the shoulders.) The number of buttons Meranti bought last Thursday is a commitment. The number of buttons on a Larkfall is a definition.

Second: can this fact be true in two versions at once? A definition can. A commitment cannot. The Larkfall exists at revision B and at revision C at the same time, and that is correct. Garments already cut are revision B garments and always will be. But the factory cannot owe Amberdene for 48,500 m and for 50,500 m at the same time. A fact that can carry two truths at once belongs to the definitions system. A fact that cannot belongs to the commitments system.

Run the same eight facts about WM-8814 through both questions. The answer stops being a matter of taste.

The sixth row is not a joke. It is the most important row in the table, and every course in this track meets another one like it. The number that reconciles two systems usually lives in neither of them. Course 10.1 covers the field nobody owns. Course 10.5 covers what happens when that number ends up in a spreadsheet. Course 10.6 covers who is allowed to change it. Here, just notice that it exists and that no screen shows it.

What this buys you before we go any further

Two habits. Both are free.

The first is to say which record you are quoting from, every time you send a number. "45,756 m at tech-pack revision B" and "48,500 m on purchase order FB-3391" are two sentences nobody argues with. A bare "about forty-eight thousand" is the start of an argument.

The second is to notice what kind of number you are typing, every time you type one into a system. Are you recording something that happened, or describing something that should be? The first needs a date and a counterparty. The second needs a revision and an approver. A number with neither will be quoted back at you in six weeks by somebody who cannot tell which kind it was.

Act as a systems analyst who has spent years untangling apparel data. You do not accept a field's location as proof that it belongs there. I want the facts on one order sorted. Facts: factory or brand [NAME], style and order [CODES], and a list of every field that appears on the order's paperwork [PASTE THE FIELD NAMES, WITH THE SCREEN OR REPORT EACH ONE APPEARS ON, AND THE VALUE IF YOU HAVE IT]. Also tell me which systems exist [DESCRIBE THEM BY WHAT THEY DO, NOT BY NAME] and who maintains each. Do the following. First, for every field, answer two questions in one line each. If this value changes, does somebody owe somebody money differently, or does the product become a different product? And can this value be true in two versions at the same time? Second, from those two answers alone, assign each field to the record of COMMITMENTS, the record of DEFINITIONS, or NEITHER, and say which of the two questions decided it. Third, put every field you assigned to NEITHER in its own table. Those are the ones that reconcile the two systems and belong to nobody. For each one, name the person who applies it today and the place it is written down, or say plainly that there is no such place. Fourth, list every field that is stored in a system it does not belong to, and say what breaks as a result. Fifth, mark any field whose stored value is a placeholder rather than a measurement, and tell me how you can tell. Do not recommend software. Ask me for anything you need rather than assuming it, and list every assumption at the end.