Changing records management architecture - lets stop designing things for filing clerks.

For a really long time, the business activity of people keeping records was the keeping of records.

It was all they did.

They were professionals.

So they organised their information for the job that reflected the bulk of their work - that of filing clerks.

Largely, the structural elements of records still reflect that job.

Which is odd, because filing clerks don’t really exist anymore.

And all the work in records systems is done by people whose job isn’t anything to do with record keeping.

This means that the structures we are creating were designed for a job that doesn't exist anymore.

The tension it creates is the one that sees the horrifically low capture rates of lots of records systems.

It's the tension between the technical requirements of the system that's been built, and the requirements of people trying to coordinate a business process, or to achieve work in groups.

For me, this is the tension that’s pressuring us to make two major architectural shifts.

They mirror the shifts in the work that is being done, and the work that they system has to do.

The two major architectural shifts for records are towards how processes are organised, and how people are organised.

This isn't news.

Business Process Management people cottoned onto one aspect of this shift 25+ years ago.

The idea of "groupware" (technical systems for organising people as groups) is even older.

They are also echoed by even older ideas in management thinking.

So we need to make an architectural transition.

Or we could keep designing systems based on the needs of filing clerks.