The systems you did not buy

A policy was asked for; a survey was run instead

Erimtan Konfeksiyon sews outerwear and tailored jackets for three buyers: Halbertsma, Trewithen and Karvonen. That is 118 styles a year, across seven lines, with 312 people. In January the owner asked Ayla Tekand to write an AI policy. Tekand runs quality, and the computer systems quality depends on.

She did not write one. She spent two weeks asking the 46 people in the office one question each: what do you use to do your job that answers back?

The answer was 11 separate systems, in nine departments. One of them had been bought.

That single sentence is the whole lesson. Every factory that runs the same survey gets the same shape of answer. Governance arrives attached to buying, and buying starts with an invoice. Ten of Erimtan's eleven systems arrived with no invoice. So ten arrived with no security question, no contract, no note to the buyer and no named owner. Nobody was careless. Nothing in the building was pointed at them.

The eleven, sorted by the only thing that matters

Sorting them by department told her nothing useful. Sorting them by supplier told her nothing at all, because most had no supplier anybody could name. What worked was sorting them by whose data goes in and what decision comes out.

Read the bottom row twice. Two systems in the building were making judgements about named people. Both had been adopted by a competent manager solving a real problem. Both were free. Neither had ever been mentioned in a management meeting. The one that had been bought was an extraction tool that reads purchase orders, and it sat in the middle row.

Tekand ranked all eleven by exposure. Her rule had three parts: whose data, what decision, and what a wrong answer costs the person it lands on. The system Erimtan had governed ranked eighth of eleven. The whole governance effort of the company had gone on its eighth-riskiest system, because that was the one with a purchase order behind it.

What the governance of that one system had cost

USD 1,232.10 is not a large number, and it was not badly spent. The problem is where it went. A hundred per cent of the effort landed on nine per cent of the systems, and the thing that chose them was the invoice. An invoice has nothing to do with risk.

The mistake nobody made: a price that was produced, not received

The clearest case of the eleven was the quietest. A costing clerk was using a spreadsheet assistant to finish quotations. Where a supplier's price was missing, the assistant filled the gap with a likely one. That is exactly what it is built to do. Quotations went out complete and on time, which is why nothing was noticed for five months.

Three quotations went out carrying a number nobody had received. One of them was won.

Nobody did anything wrong. The clerk asked for help with a gap and got it. The system produced the most likely value, which is its whole job. The cost sheet accepted the number, because a cost sheet has a column for the price and no column for where the price came from.

That is the general rule, and it is worth more than the incident. A system that produces likely values is safe in a document that records where a value came from. It is dangerous in a document that does not. The fault was in the form, not in the tool. Ten minutes on the survey's second question would have found it: what comes out, and does the document it lands in say whether the value was received or produced?

The four columns

Erimtan's register is one row per system and four columns. It is not a risk framework and it scores nothing. It asks four questions, and a blank in any of them is the finding.

1. What data goes in? Named, not categorised. "The buyer's tech pack" rather than "product information". A tech pack is the buyer's written specification for a style.
2. Whose data is it? Ours, a buyer's, or a worker's. This column decides which duties exist at all. Lessons 2 and 3 are the two answers that are not "ours".
3. What comes out, and what decision does it feed? Plus the extra question the cost-sheet case bought: does the document it lands in say whether the value was received or produced?
4. Who is accountable when it is wrong? A name. Not a department, and not "the user".

Course 24.1 has four blanks of its own for a data-capture project: the decision, the person, how often, and what one instance of that decision is worth. Those four answer a different question: is this data worth having at all? These four answer are we allowed to use it, and who pays when it is wrong? Keep both pages in the same folder. Neither replaces the other. A system can be worth having and not permitted. It can be permitted and worth nothing.

Act as a governance lead in a garment factory who has seen a policy written about the one system that came with an invoice. I will paste raw survey answers. I want a register, not advice. For each system somebody named, I will give you: [WHAT IT IS, IN THE WORDS THE USER USED], [WHICH DEPARTMENT], [WHAT THEY PUT INTO IT], [WHAT COMES OUT AND WHERE THAT OUTPUT GOES], [FREE OR PAID], [IS THERE A CONTRACT, YES OR NO], [WHO ADOPTED IT]. Do the following. First, build a table with one row per system and exactly four columns: what data goes in, named rather than categorised; whose data it is, answered as ours, a buyer's, or a worker's; what comes out and which document or decision it reaches; and who is accountable by name when it is wrong. Leave a cell blank where my answers do not settle it, and list the blanks separately as the findings they are. Second, rank the systems by exposure using only two things: whose data goes in, and what a wrong output costs the person it lands on. Tell me where the one with a contract sits in that ranking. Third, for every output that lands in a form, ask whether that form records the source of a value, meaning whether it tells a received value apart from a produced one, and flag every form that does not. Fourth, tell me which single system I should deal with first, and what the first action is. Do not write me a policy and do not recommend a framework.

What to take away

1. Run the survey before writing the policy. Erimtan found eleven systems in use and had bought one.
2. Governance follows the invoice, and the invoice has nothing to do with risk. Erimtan's governed system ranked eighth of eleven on exposure.
3. Sort by whose data goes in and what decision comes out. Those two questions create every duty in this course.
4. A system that produces likely values is safe in a document that records where a value came from, and dangerous in one that does not.
5. Four columns, one row per system: data in, whose it is, decision out, who is accountable for a wrong one. A blank is the finding.
6. Course 24.1's four blanks ask whether data is worth having. These four ask whether you are allowed to use it, and who pays when it is wrong.