What's your records system repertoire
For the last 50 years (and longer), we've had structured data systems.
Somehow, as a profession, we still pretend that these aren't records systems.
How does this belief stack up with other professional groups?
- Would business people say "we can't rely on that finance management system, it's structured data."
- Would lawyers say "that's not evidence - it's structured data" to a judge.
- Would bankers say "oh no - we don't owe you that money, our core banking system uses structured data."
- Do public servants say "I won't make a decision based on that - our case management system uses structured data."
Do records managers say "that's not a records system - it uses structured data."
We do.
Why?
Personally, I think it's because it exposes one of the core limitations of records management and what it was created to do.
There's an implicit assumption in records management that people will do their work, and then records will take custody of the work product and look after it so that it can be found later.
It's been that way for thousands of years.
But the world in which people were needed to do that, doesn't really exist anymore.
Most of the time, people place their records in the custody of a system themselves - and they do it happily.
Once upon a time, they may have found a sense of comfort from giving their work product to records to look after - custodial records has a certain sense of comfort about it.
Now though, I think that most people only feel comfortable when they can give custody of their work product to a system that they have organised themselves.
Whatever they felt, business systems (in whatever flavour) ask their creators to go much deeper than records ever had to.
People designing business systems have to go right down to the work that people are doing, and exactly the data that they need to do it effectively, and to manage it, and how they manage the completion of work and the flow of work through time and between people.
In other words, in business systems, the content is overwhelmingly the most important thing to the people creating the system.
In records systems, it's the container and how the container is structured.
The challenge for us, is that overwhelmingly, the largest risks and performance opportunities come from specifying and managing the quality of the content.
The quality of the bucket that it's put in is largely irrelevant - or relevant only such a small fraction of the time that mostly people haven't been burnt enough to actually want to use the records system.
So we have a huge gap between the records skills we have a body of practice for, and the records skills that our organisations are asking for.
In a nutshell, we have records management skills, and people designing business systems are focusing on the record keeping - because the point at which information and knowledge is recorded is the single biggest opportunity to influence record quality, and record quality is the single biggest opportunity to improve performance.
To me, this is the critical next thing for records.
We need to add business systems to our repertoire.
It's both a big transition, and also a very small one.
We just need to move from focusing on the record management, to the record-keeping.