This post is a response from “guest blogger” Oli Parker to my earlier post on Search & Collaboration Networks. Oli Parker runs DeepGreen Consulting; an information management consultancy with a particular interest in ECM systems and collaboration. He can be contacted at email@example.com.
You’ve put your finger on a number of commonly-recurring issues with EDRM systems; issues which the EDRM (or ECM as it’s now called) community would do well to address.
However I think that we need to lay out some territory for the discussion before doing the addressing. While it is easy to list the problems with certain approaches, it is also worth looking at what they offer. In fact, before doing that, perhaps we should look at what is trying to be achieved – to find some requirements and investigate the way in which they can best be met.
The main distinction we need to make is between documents and records. Or putting it another way, are we setting up a system in which in to store records (bearing in mind the various definitions and particularly the importance of records) or a system in which information more generally will be stored? These are two significantly different requirements which will lead to quite different systems if addressed comprehensively. (Yes, there may be a requirement for a system that does both of these, more later.)
If records are to be stored, a more formal approach needs to be taken. Records bring with them retention schemes and access control issues. Applying these is something to be taken seriously; often these are backed up by legislation which it is wise to stay on the correct side of, and sensitivities which need to be respected. Records ‘belong’ to a corporate body, and the corporate body has a duty of care for them. The internal structure of the corporate body may (and often does) change, and the storage system needs to be robust in such a circumstance. Equally, the corporate body may split, with functional parts moving to another organisation, or parts of other organisations joining. (Machinery of Government changes are the public-sector equivalent of changes of ownership of companies or brands in the private sector). The change in ownership of records in these circumstances needs to be handled efficiently, with as little administrative overhead as possible.
CFP’s are Good! (Honestly)
And these are the reasons for a Corporate File Plan (CFP). By keeping records relating to a certain function, activity or transaction together, you can readily apply both access permissions and retention rules to them all, as access and retention are usually boundaried by the limits of a given activity or function. By dividing records by function, you can re-organise the teams within your corporate body as much as you like without needing to change your record storage. You can also very readily pass a particular function (perhaps that of regulating financial markets or of issuing licences for exhuming dead bodies) to another organisation, and by ‘snipping off’ the CFP at the relevant point, you can pass on all the relevant records pertaining to this function at the same time.
These are all good reasons for applying the rigour of a CFP to your corporate record storage. Without structured organisation of records such as that offered by a CFP you may gain apparent short-term benefits (such as it being easier to find a ‘suitable’ place to save items), but in the longer-term you will find managing records to be much more difficult because – simply put – they aren’t organised. Trying to find all the HR records relating to an employee who left 7 years ago when no effort has been made to keep them in the same place will be an exercise akin to trying to find a complete pack of 52 playing cards for a game of poker when they are not all kept together. You can’t play the game with an incomplete pack, but while the appeal of both exercises wears off after only a few minutes of searching, the game of poker can be readily abandoned; the other can’t.
The benefits of a CFP are therefore clear. But let’s not confuse a CFP with an ECM (EDRM) system. An ECM system is simply a set of tools which automate a number of the more laborious aspects of record-keeping; tools which work on a collection of records, in whatever structure they inhabit. These tools are primarily concerned with security, retention and access, although a mature ECM tool will offer a raft of other functionality as well.
It is important that the storage structure is seen as a separate entity to the collection of ECM tools. All too often, the design of a CFP and the implementation of an ECM system are seen as being two parts of the same project; a view which often gets them dangerously confused in the eyes of the user. They should be introduced and presented to the user separately, in order that their separate purposes are clear. A CFP can be used to store information regardless of medium or system; in an ideal world, the CFP would be used to structure the storage of both electronic and hard-copy media. It should be used to manage eMails as well as ‘Office’ items (why would you want to use a different structure for eMails?), for microfiched as well as paper-based items. A CFP could (and should) out-last an ECM system by several generations; if an ECM is correctly seen as merely the tools that are available to manage items within the CFP, changing the tools for a new – updated – set should be readily possible, without any need to change the underlying structure of the information being managed.
CFPs therefore offer useful benefits which are hard to ignore. Users need to understand the purpose of a CFP and the reason for using one, in much the same way that they need to understand the purposes of and reasons for keeping records (all of which are commonly dismissed as ‘just filing’; an attitude that is as unhelpful as it is short-sighted and too often badly overlooked). However CFPs are also difficult to get used to and to use; people don’t think in terms of functional structure when either saving or looking for an information item. (They think in terms of areas of work that they are responsible for, or that their team are responsible for, and tend to file accordingly.) For precisely this reason, users should not be presented with a CFP without also being shown a mechanism for easily navigating to the parts of the structure which they will most frequently use. In the same way that a sales employee has no need to understand the structure of the HR department, so such an employee need not know the detail of the HR function of the CFP; that both exist is all they need to be aware of.
Nonetheless, the aforementioned sales employee may need ready and quick access to a number of apparently disparate parts of the CFP; the sales and marketing area, the product development area and their own personnel file, perhaps. For this reason, it is important for them to be able to (and to understand how to) set up shortcuts to these parts of the CFP relevant to them, such that in their regular work they need only access these shortcuts and not concern themselves with the rest of the fileplan; a fileplan which is not ‘theirs’ (it belongs to the corporate Records Management department) and over which they have no control. They must then be able to arrange these shortcuts in whatever way they please and thus can create their own personal fileplan (of shortcuts), for their own use. This personal fileplan needs to be available to them whenever they access the record store – either for retrieving or saving items. Once created, these shortcuts should be persistent – if created correctly there is no reason why they should ever lose that which they point at.
When a CFP is less useful
However for the majority of information held by most organisations this is still a bit tedious, and focuses heavily on the storage of items. It hasn’t addressed the central concern of information retrieval and collaboration.
CFPs are useful for keeping records, but such rigour isn’t necessary for the vast majority of the information held by organisations. Notes, papers, drafts, discussion documents, articles and blogs are all very useful information artefacts, but do not need the degree of management offered by a CFP. They are not usually subject to a retention schedule or access restrictions as Records are. Such items need a gentler management touch; they can be held in such a way as to be readily searched and retrieved, such that the intellectual value contained within them can be readily capitalised upon.
An information environment that maximises the utility of such items will, by it’s nature, be a lighter-weight and faster-moving affair. Storing items needs to be quick and easy, and yet they need to be readily retrieved when necessary. This presents an interesting challenge in terms of tagging and indexing, but such an environment can be designed around a looser structure, using a different set of tools (most notably search) to retrieve items. Given that items within such an environment are more likely to be used for research (as opposed to reference), the use of search as a tool to navigate them becomes more appropriate.
Search is, by its nature, a processor-intensive task, and as Moore’s Law tells us that processing will get ever cheaper with time, we can assume that search tools will become more useful. Your article outlines a number of areas where search has a large amount to offer, and we can expect to see good progress on a number of these fronts in the near future.
Then again …
However, you also talk about a number of pre-requisites for the operation of a search tool, as follows:
“For search to work across a collaboration network, then there is a requirement to:
- apply appropriate access controls to collaboration areas within the network
- search across all collaboration areas (subject to access controls) in the network
- provide consistent metadata across all collaboration areas in the network (to allow search to work accurately)
- actively manage the long term retention of content i.e. close down collaboration areas that are not being used and migrate content to archive areas
- provide governance in the setting up, management and disposal of collaboration areas (to avoid the situation where the number of collaboration areas grow in an uncontrolled manner or individual collaboration areas to not conform to the standards of structure or metadata) “
I wholeheartedly agree with these points, but would suggest that many of them are simply re-stating the same needs outlined earlier, namely those of access and retention; needs which were met by a CFP. While I would agree that the rigour of a CFP is not necessary for collaborative systems, it would appear that there is a need for some form of structure to underlie the information holdings. Indeed, you mention such a need in an earlier stage of your article – “It makes sense that an EDRM system needs a folder and file structure at a basic level.”
So, what are we saying? That there is a need for some form of structure in which to hold information artefacts; a structure that allows management of these artefacts. Different artefacts need different degrees of rigour in management, with those being held as records demanding more rigour than those that are not.
Steps to Improvement
Given these differing needs of governance for different forms of information, what can be done corporately? A modern organisation will need both records management as well as information management, so how is this to be achieved? One-size-fits-all doesn’t work, as you have pointed out; you either find yourself applying too much rigour to information, or lack the management capabilities for records. What is the solution?
I’d suggest a two-pronged approach. Recognise the differences, and use systems accordingly.
- Prong one would be a CFP for corporate records, with an ECM system to manage the contents.
- You could then implement this alongside a less-structured system (Prong two). Perhaps use some (relatively) unstructured nodes within Microsoft SharePoint (much loved by users for its support for collaborative working), and encourage users to do their collaboration and thinking using this system.
Aforementioned users should need to know enough about the importance of record management to understand the differences between the two, and to save discussions from Sharepoint to the ECM as and when they become records. That sounds hopeful. And you could also then run an enterprise-wide search tool to retrieve from either (or both) system.
You’re right. Trying to persuade users to use a CFP when it’s not necessary will cause users problems, and introduce a barrier to the adoption of an ECM system. And this is perhaps where many an ECM implementation has foundered; trying to use the wrong tool for the job is always a bad idea.
However, the converse is also true. Trying to manage important, lasting records without the correct degree of governance and control is also going to cause problems – of a different form. Again, the correct tools are needed for the job in hand, and the CFP is a very useful tool to use in the management of records.
The right way forward is to understand what is trying to be achieved (management of records or management of information), and building the system accordingly. Such an understanding needs to be agreed by everyone up-front – ‘everyone’ including system owners, project sponsors, records management departments, systems integrators and users alike.
Only when such understanding and agreement is reached can an ECM implementation be successful. To try and proceed with any project without this agreement is to embark on a project which has – at best – a limited future usefulness.