Tally sticks, databases and records management

I’ve heard people talk about the history of records with great pride.

They are quite justifiably proud that they’re part of such an old, noble profession.

Records text books in particular like to focus on the evidence of practice from the past.

Tally sticks.

Clay tablets.

Cave murals

Tokens of all kinds of materials.

They talk with great pride about how these things were stepping stones on the way to the pinnacle of civilisation that we’ve reached.

And then we almost all go off to work and run a records program that ignores business systems and databases, or treats the data and the way it’s presented to users as irrelevant - but takes great pains to point out that the documents in those systems are special and have to be managed in a special recordsy way.

The point of this isn’t to rub anyone’s nose in it (even if that’s the result), it’s to say that the way we practice now is inconsistent with the glorious past that our profession has, and that we seek to own when we conjure it with talk about the past.

Records management exists because there are gains to be made from the proactive management of recorded information and the processes that create it - it's also a skill, and skilled people get more out of it than less skilled people.

When we decide that there’s a particular class of information (databases and business systems) that we’re going to ignore, we create one of two things for other people -

1. A problem.

2. An opportunity.

For managers in the organisation who are now using those systems without the benefit of proactive management, they have a problem.

For other people who see the problem, it becomes an opportunity.

This is why the whole data management industry exists - because we left several classes of information unmanaged for long enough that a whole professional group sprang up to manage it.

For a certain amount of time, it has been fine for both groups to trundle along relatively independently.

Now though, privacy and cyber risk have become important enough that organisations are appointing C level executives to manage them.

So this is the point that the inconsistency is going to resolve itself.

It’s going to happen (and is indeed happening) in one of two ways.

Top down - C level people aren't going to use two sets of language, two sets of tools and two different groups to manage information because of semantics about whether databases contain records - the databases create cyber risks, and privacy risks, and people make decisions based on what's in them all day long, so any argument about whether they're records or not will be ignored - because the executive needs to manage cyber and privacy risk, not engage in semantic arguments that regulators and shareholders don't care about.

Bottom up - practitioners are going to see the inconsistency and resolve it. This is already happening in many organisations - mostly with the data side taking over records because to them, it’s just less structured data. Sometimes it is going the other way - mostly in programs where the quality of records is tied to operational outcomes, and it has become clear that people are indeed making decisions based on business system information, and the operational outcomes can’t be met without managing it all together.

Ultimately, organisations want to know that they can trust the information they’re using to make decisions, and that they’re paying a reasonable price for the privilege. They don’t care what label we give it.

If we want to honour the glorious history of records, we shouldn’t either.