Documents are the bread and butter of law firms, from the small practices to the multi-nationals. Firms with a document management system (DMS) will understand the key principles of version control, meta data management, security and archiving or disposal.
System administrators are able to configure your document management system so that specific users or groups of users, departments or practice areas have access only to their own documents (or those of other departments they have permission to access). You may have a knowledge or precedent library which is open to all users to share – the crown jewels of knowledge in your firm. In this comfortable world, users see only what they have permission to see and access to the document repositories are secure.
In a perfect world, document usage can be determined by looking at the DMS’s activity or history log. Administrators can see who accessed what and when. If they are feeling adventurous they can generate statistics by document type, department by period, by matter, and so on. But is that really enough? What about the following examples?
· A firm finds a dispute resolution partner accessing a large quantity of banking and finance precedents over a two-hour period?
· A team of fee earners from the Hong Kong office commercial department are identified accessing large volumes of documents from the Brussels’ office commercial department via an expensive leased line?
These are just a couple of examples of the kind of information which could be obtained from your DMS by better mapping your real world organisational structure into the relevant configuration information, and defining some additional usage rules.
There are good reasons for wanting to obtain a better understanding of why documents are being used in the way they are. In the examples above, the partner could be downloading banking and finance precedents because he or she is about to jump ship – that is information you would want to have as soon as it happens. In the second example, the team in Hong Kong may be accessing documents in Brussels because their local document management repository has been offline for a week, and a replica of the repository is in Brussels – they neglected to tell anyone about their problem and are now ramping up costs on an expensive leased line and slowing down users in Brussels due to the extra user requests.
It doesn’t take a great stretch of the imagination to come up with a number of such scenarios. In a large organisation there could be many more such examples going on right now and you’d have a much harder job determining this from the standard DMS’s activity log.
How can we achieve better visibility of document usage within the DMS and how can we be notified sooner rather than later when things look suspicious? In my approach we look at the following steps.
· ensuring the firm’s structure is adequately mapped in the DMS
· defining usage rules for all parts of the business you want to take an interest in
· deciding how and when you want usage information generated
1. Ensure the firm’s structure is adequately mapped in the DMS
As a first step, it is important to look at the structure of the firm. How are the departments and offices organised? Are there practice groups in single offices or are they split across locations? Do departmental teams work across practice groups and sites or not; likewise across jurisdictions’ for larger organisations? Are there fully utilised out-of-the-box attributes for People, Departments, and Location etc. in the system; if not is there a reason why? Understanding how the firm is structured and making use of the information available is key to being able to map this in the DMS.
Once you have this information it can be used to configure the DMS so it will better reflect the organisation. Most flavours of DMS will allow the administrator to extend the system configuration information, allowing additional managed look-up tables to be defined, extra attributes added to existing information and configuring relationships between entities in the system. Some systems are more flexible than others but, depending on how complex your model is, it may be necessary to leave the systems configuration environment and build your own information. This can be achieved by adding custom tables to the SQL database hosting your DMS, by creating a separate database and storing the information here or by using XML configuration files.
If you can add all the necessary configuration information through your DMS configuration tools (because the system is flexible enough) then you will find that generating enhanced reports on the system’s activity log is slightly easier as the new configuration information is native to the system and it will know how to utilise it. If this is not the case, a little extra work will be necessary to bring together the new configuration and the data from the DMS activity log. As a minimum though, your DMS will need to support the ability to add custom fields to a document, workspace or folder entity.
2. Define usage rules for all parts of the business you want to take an interest in
Usage rules define the criteria which will be used to compare information within the DMS’s activity or history log. These rules can then be used to generate reports, RSS feeds, or e-mails when the criteria are met. How you define your usage rules, will very much depend on the structure of your organisation. For example:
1. trainees within the IP practice area in London and New York may view ten documents an hour and print two documents an hour
2. all users in London may view five documents an hour and ten documents a day for documents located in offices outside Europe
3. users in Hong Kong may view no documents an hour for documents located in offices outside of Asia
4. all users in all locations may access 40 documents an hour in the Knowledge Library.
In Example 1, trainees are restricted in the number of documents they can print before a notification is raised. Example 2 ensures that the usage of a London user is kept low for documents outside their locality to reduce bandwidth usage costs; likewise for example 3 and users in Hong Kong. Example 4 is a catch-all to ensure no one tries to run off with the contents of your knowledge library without you knowing about it.
These usage rules would need to be ‘encoded’ so that a reporting system can use them in conjunction with the DMS activity log. This would typically be done using an SQL database or an XML configuration file. Once this is done, you have a very flexible way of looking at how your documents are being used. You can be notified which usage limits are exceeded and take immediate action. You can also analyse trends and gain an insight into who uses which documents and when.
3. Decide how and when you want usage information generated
Generation of usage information could be performed by using a report writing tool such as Business Objects or Microsoft SQL Reporting services. Alternatively, you may want to develop a custom application which takes the usage rules you have defined and, in combination with the DMS activity log, generates real-time alerts as usage rules are broken. Either way you can schedule reports or alerts to be delivered to your inbox on a daily or weekly basis or as rules are broken. You may even want notification sent to the offending users. Deciding on the frequency and the method of generating the information is up to you, but a key deciding factor will be how quickly you want to know that a usage rule has been broken.
Conclusion
In this short article I have described how you can have better visibility over your document usage by ensuring that your DMS configuration matches your real world firm structure. I have also illustrated how defining usage rules for your organisation will enable notification if activity on your documents or workspaces or folders goes outside defined parameters. Lastly, I have explained how you might deliver that information to the business.
Colin Fowle is Managing Director of Blue Car Technologies: www.bluecartechnologies.co.uk
