AI Strategy 4 - Information

Information is data that has been cleaned, organised and put into context, so that it shows what happened. The data map records the data the unit holds. This second map records how that data is processed. The two are separate exercises because knowing precisely how and where information is stored does not automatically reveal from which data it was derived and what that derivation process entailed.

Three operations turn data into information. A unit is usually competent at one of them and weak at another. Cleaning is the correction of facts that are wrong, duplicated, stale, or entered in a form that nothing else can read. Organising is putting the facts into an order that permits comparison, i.e. the same fact in the same place in every record, so that one record can be set against another. Adding context is the operation that makes the data show something: this quantity against last period’s quantity, this balance against the terms that were agreed, this date against the date that was promised.

We record five things for each item of information the unit produces:

1. its processing - what is done to the data, and by whom or by what;
2. its status - whether that processing is a defined process or a habit;
3. its storage - where the result is kept, and in what form;
4. its accessibility - who can read the result and who can change it; and
5. its lineage - whether the route from the result back to the source data can be traced.

The data map page records these five things for each item of information in the same worked example, built from an invented business.

A defined process is written down and it produces the same result whoever runs it. The test we apply is whether somebody who has never done it could produce the same answer from the same data by following the record. A habit is the same work done reliably by one person, out of their own memory, with nothing written anywhere. Habits are frequently the most accurate part of the business, because the person doing the work has been doing it for years and cares about it.

However, in spite of that making them the most valuable, it also typically means that they are the least likely to be formally documented, and therefore become an asset to the business. A habit cannot be delegated, to a person or to a machine, because there is nothing to hand over. Every discussion about what AI might take on eventually arrives at this point, so if it isn’t already documented, no decision can be made about it.

In one of our audits, the CRM could output useful data but nothing in the process ever compiled a report from it, so the weekly figures the business ran on were assembled by hand, every week, by one person. The report was produced accurately and on time, and no one ever had reason to complain. However, the assembly had never been treated as a step in the process, so it would only endure so long as the person continued doing it.

We see the same thing in the structure of the files themselves. One spreadsheet can be the data entry portal, the consolidated record, and the interface that everybody reads downstream. Entries arrive in the same file as the live record and are copied across it manually. Three different functions with three sets of expectations about what the file is for and nothing stating specifically which particular role it is playing at any given time.

Where the processing happens is often nowhere that a survey of applications would find. It happens between two applications, in a spreadsheet that nobody thinks of as a system, or in the head of the person carrying the data across. Again, this is only discovered by asking a person what they do to the data before they use it.

The result of processing has a storage location and a format in exactly the way the underlying data does, and the same spectrum applies. A figure held in a field can be read, compared and checked. The same figure written into the body of an email, or into the third paragraph of a filed document, or even as prose in a spreadsheet cell, has to be found by somebody who already knows it is there. Businesses are much less careful with the second map than with the first, because the output of processing feels like a conclusion rather than a record, and conclusions are often immediately dispatched rather than permanently recorded.

With respect to version, the firm’s own written process may well require documents to be version controlled, and the mechanism might be the name of the file moving through draft, then approved, then final. Strictly speaking, that’s more of a convention rather than a mechanism, and nothing whatsoever prevents a second final!

Similarly, access to information is not the same as access to the data it was derived from, and the two often get conflated. Raw records tend to be more diligently controlled than the summaries or derivations of them.

For information, we record the same three terms as we did for data - who can read it, who can write to it, and who or what is the gatekeeper. We also ask one further question - can someone change the answer without changing anything the answer was derived from? In most businesses the answer is yes, and often more people can change the information than the data. Where that is the case the information has stopped being a product of the data. It is an assertion, held in a document, and the provenance is no longer reliable if the derivation process and its version controls are not documented as assiduously as the underlying data.

The same facts processed in two places can sometimes have different labels in different applications (or even in the same application if there is no strict ontology), making it difficult to relate them. For example, a party can be named slightly differently in each system that holds it, with no common or canonical identifier. The file system might have one name (in the folder and/or the file names), the CRM another, the accounting system another still. Each system then reports faithfully what it holds internally, but reconciling across the systems relies on human intuition or machine pattern matching, neither of which is absolutely reliable.

Similarly, one piece of work can span two applications, with each holding one part of its state. Neither application is useful for reporting the full state. A reference produced by the second application is read off the screen and typed by hand into the first, and vice versa. Again, the complete picture can only be resolved by some intuitive reconciliation process that does not survive the people with most intuition of it.

Finally, lineage. We take any piece of information and ask what data it was assembled from, its origin, and when it was accessed. If that can be answered, the information can be verified and reproduced. If not, making it the subject of an automation is going to be difficult.

A machine, especially an AI, will produce a fluent, well-organised and plausible synthesis from whatever it was provided. However, it cannot tell you what it was not given. If the route back to the source data cannot be traced, there is no way to establish whether the synthesis is sound or merely confident. And AI is brilliant at sounding confident!

Where the processing is defined, stored in a form that can be read, restricted to the people with the correct authority, and traceable back to the facts it was derived from, the information can be provided to a machine. Where it is a habit in one person’s head, stored in prose, editable by anyone and traceable to nothing, as valuable as the information might be, there is no way of reproducing it systematically, so it is pointless embarking on an automation of the process to do so.

Knowledge, the subject of the next chapter, is what the business makes of its information - the patterns in it and the multitude of factors that form it. A business that cannot say how its information was produced will still interpret it, but have no way of telling a sound interpretation from a confident one.