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?

I have written about this topic many times in the past (see links at the end of this post) but the lesson is always the same. There are two key rules:

1.     If your system relies on people being 100% consistent and reliable it won’t work; and

2.     If you system places an additional workload on already busy workers it won’t work.

The message is, if you simplify and automate your system you give it the best possible chance of working.

If your system works as automatically as possible and doesn’t require much effort from your workforce then it has the best possible chance of being successful.

With today’s technology and tools there is simply no need to burden your workforce with capture and classification tasks. Do you still see people still using typewriters, rotary phones or Morse code? No you don’t because there is much better technology available. So why do you persist with an old, outdated and unsuccessful model? Why do you ask your staff to manually capture and classify electronic documents and emails when there are much better, much faster, much more consistent and much more reliable ways to achieve a better result? It is after all 2014, not 1914; we all use computers and smart phones now, not typewriters, wind-up rotary phones and Morse code.

Emails are managed by email servers, (yes, even Google). Email servers allow plug-ins and add-ons and are ‘open’ so you can automatically monitor and capture incoming and outgoing emails.

Electronic documents are always saved somewhere, for example on your shared drives or directly into your DMS. As such they can be captured and interrogated programmatically.

It is entirely possible to ‘parse’ any electronic document or email and its associated attributes and Metadata and make consistent decisions about whether or not to capture it and how to classify it when captured. It isn’t rocket science any more, it is just analysis, design and programming. We can go even further and determine who should be notified and what action(s) need to be initiated in response to each new email or electronic document.  

We can easily implement an end-to-end business process whereby every electronic document and email is managed from creation to destruction and we can do this with minimal human involvement. Where human involvement is required, for example making a decision or deciding upon an appropriate response, we can also automate and manage the business processes required and simply ‘present’ staff with all the required information when required.

Isn’t this was the Knowledge Management revolution was supposed to be about?

“A system that provides the user with the explicit information required, in exactly the form required at precisely the time the user needs it.”

The new model is all about automation and processing at the server rather than at the user’s workstation; a fully automatic, server-centric paradigm. A system that is all about the ‘Push’ rather than the ‘Pull’ model. A model whereby the computer services the end user, where the end user is not a slave to the computer.

We could also call it management by exception. “Please only give me what I need to see when I need to see it.”

None of the above is new or revolutionary thinking, it is all just common sense. None of the above requires yet-to-be invented technology or products, it only requires existing and proven technology and products.

The fully-automatic, server-centric approach should be the default choice and it should be a no-brainer for any organization that needs to implement an email and document management regime. Unfortunately, too often it isn’t.

If you have the responsibility of rolling out an email and document management system and the fully-automatic, server-centric approach isn’t on your agenda then your boss should be asking you why not.

References:

White papers

Posts