We have a large number of records and document management customers using our product RecFind 6 and with new customers the question always arises about how to best organize information in the RecFind 6 database. As the Metadata and business processes in RecFind 6 are 100% configurable, every customer ends up with a unique configuration.
Some records managers want the shared drives structure replicated in the database. Some want everything filed under a strict hierarchical classification system or Taxonomy. Some customers want the whole process simplified so end users clearly know where to file stuff and where to find stuff. Different managers in a single customer site will often disagree about how the information should be managed. Usually, the IT manager disagrees with the records manager and it is up to us to come up with an agreed and workable compromise; no easy task! There is no “one size fits all” paradigm here. We have grown to accept these discussions as part of every new installation.
Whereas I fully support the principles behind most EDRMS standards as espoused and recommended or even mandated by records management consultants I also find myself agreeing with most end users who just want the whole process simplified and expressed in natural language, not as an arcane, complex, inconsistent and difficult to navigate hierarchical classification system.
To wit, the way you classify information should not dictate how you store, manage and retrieve information.
I have written a paper of this exact subject and although it was in 2009 it is still 100% relevant. Please see this link Do You Really Need a Taxonomy? You don’t have to agree with me but please try to understand the message. End users want easy, fast access, not time-consuming complexity.
Maybe I should begin by telling you how we solve the problem at Knowledgeone Corporation and manage our emails, electronic documents and shared drives with a hybrid system. That is, a combination of RecFind 6 and shared drives. This is also a model we regularly recommend to our customers as an acceptable compromise; one that is simple to implement and one that always works.
I am obviously a big fan of making information as easy as possible to capture and as easy as possible to retrieve. This is especially important to the long-suffering end-user class who have no interest in becoming part-time records managers and who simply won’t use a system if it is too difficult to use and too time-consuming.
End users want direct access to information in the easiest and most timely fashion possible, they do not want to go through a third party or ‘information broker’. This means we need to have both a simple search system as well as a security system that ensures people only see what they are supposed to see.
And of course, the biggest problem with complex, hierarchical classification systems is that no two people file the same way and even a single user will often file things differently over time. This in itself makes the act of finding something by browsing through a classification hierarchy a hit and miss affair.
At Knowledgeone Corporation, we implemented a hybrid model that uses a simply structured shared drive resource plus automated tools to ensure everything that should be captured is captured. This approach is also all about separating the functionality of the Authoring packages (e.g., Word, Excel, Outlook, etc.) from the functionality of the EDRMS. They have different roles to play.
Let’s dispense with the notion that shared drives are evil just as we should dispense with the notion that paper is evil. Each has a part to play in a well management information management system
We use our product GEM to automatically capture all work related emails and we use our product RecCapture to automatically capture all work-related electronic documents from our shared drives. We all use a common shared drive structure to write and store our original electronic documents. Note that we do not use the feature in the RecFind 6 Button to force all ‘Saves’ into RecFind 6. We have this feature because the industry dictates it should be there but it is not popular and most customers never turn it on. Not everything you write should go into RecFind 6 and not everything you write is ready to go into RecFind 6 (though we do have a special ‘draft’ type for those customers that want drafts stored in RecFind 6).
We don’t use what you would call a formal taxonomy, we use what I call a ‘natural’ classification system. For us this means a classification system that perfectly reflects our business practices, processes and vocabulary. In our case, we are customer-centric so everything (apart from a little administrative and supplier stuff) is organized in customer or prospect folders and the lower levels are minimal, being things like Correspondence, Quotes and Orders.
Our RecFind 6 database is mostly based on customer and prospect files; it is our CRM. Customers and prospective customers are our core business just as members and cases are the core business of unions. Every industry has a core business and in my mind this should always be reflected in the classification system used so that it perfectly aligns with the work practices and processes and ‘language’ of most staff. Whenever I consult to a new organization I always try to first determine its core business and its natural language and then design the implementation around these.
We also use RecFind 6 to run our business so it is also our asset management system, our help desk and incident system, our project management system and our R&D development system. For these applications and others that we have implemented in RecFind 6, we have nothing outside of RecFind 6 to capture because all relevant information (e.g., customer support calls, details of meetings, phone calls, quotes, orders, annual leave request, etc.) are entered directly into RecFind 6 by our staff or captured automatically. RecFind 6 is our company repository and the source of all knowledge for my staff.
Because we are customer centric I need to be able to see everything about any customer or prospect in one place. For us this means centralizing on the Entity record (the Entity table is where we store the basic information on each customer or prospect). As RecFind 6 is a relational database we then store all related information in linked tables, all linked to and accessible from the Entity record with a single click.
In our RecFind 6 system, every piece of information I need to refer to is just one-click away once I view the entity record. I can also find any customer’s record instantly in RecFind 6 just by entering the customer number or a part of the organization name. Once I select the customer record, everything thing else I need to know is just one-click away and all links are viewable in a single screen. We are a customer-centric business and our RecFind 6 database is therefore organized as customer centric.
In practice, if someone at Knowledgeone Corporation wants to find something they always look first in RecFind 6 because it is a lot easier and faster than trying to search the shared drives or Outlook. Because we use automated tools (GEM and RecCapture) we are confident that everything that should be captured is captured. We don’t rely on our already too busy staff to remember to capture every important email or electronic document; it is done for them. All they have to do is search and create. Plus most of our information is stored behind customer/prospect/partner numbers in the Entity table so all information is both easy to browse and search (Text, Metadata, BOOLEAN, Saved Searches, etc.).
As a backup, every staff member has the Button installed (in Word, Excel, PowerPoint and Adobe Professional) but they rarely use it.
We have a security system configured around our management structure that works fine for us. As a Director for example, most of the stuff I save is with a basic security code (e.g., a letter to a customer) because everyone needs to be able to see it. However, as a Director I also have the right to save things with higher levels of security, e.g., Manager, Director, where appropriate with restricted access. Like all good security systems, it is simple but effective. I am not a fan of overcomplicating anything.
Our searching is also structured the same way. We have configured RecFind 6 to add the objects we need to search on as menu items in the search function just as we would do for any customer. We therefore have a Metadata search menu of Attachments (electronic documents, emails and images), Entities (Customers, Prospects, Partners and Suppliers), People, Incidents, Bugs, Quotes, Invoices, Timesheets, Support agreements, etc. We repeat this with Boolean searches. We make it as easy as possible and as logical as possible so our staff can find anything as fast as possible. After all, I am paying their salaries so I want them to be as productive as possible.
Most importantly, we provide multiple entry-points for searches. I can for example search directly for emails with a Metadata search, searching by a combination of Sender, Recipient, Date, Subject, etc. Alternatively, I can search for customer emails from within the Entity record just by clicking on a single link for all attachments for that customer. We give our staff multiple options just as we give our customers multiple options.
You can search on any field and different classes of users can have different Metadata to both view and search on. The security system determines what each class of user (security group) can both see and then do with the information they can see. That is, the security system determines what tables and fields (and electronic documents and emails) you can see and then what methods (Add, Modify, Clone, Delete, Search, Print, etc.) you can use. Each security group sees only what it needs to see and has only the functionality it needs to get the job done
Because the system is flexible, the records manager for example could choose to search for emails on the way they were classified (say a 3 level hierarchy) but end users could choose to search using a natural selection of Metadata fields such as Sender, Recipient, Subject, Content, Date or ranges of these fields combined in either a Metadata or BOOLEAN or (making it easy for end users) Saved search.
Its horses for courses!
Following the above hybrid approach also means that you can still implement and manage all the recordkeeping principles such as retention and disposal schedules, location tracking, auditing, etc.
My point is that it is possible to meet the needs of all classes of users without frustrating any group. It just requires a hybrid approach and the configuration of the system to suit each class of user.
Making everyone happy is a lot better than making some people happy and some people unhappy. Why would you do this if you had a choice?