Records Management System or Information Management System?

by Frank 7. January 2020 14:02

How to manage the process via Natural Language

We have a large number of customers using our product RecFind 6 as a Records Management System and with new customers, the question always arises about how to best organize information in the RecFind 6 database to make it as easy as possible to manage and access. As the Metadata, Data Model and Business Processes in RecFind 6 are 100% configurable, every customer ends up with a unique configuration. As well as managing records, the end result also needs to be an Information Management System.

There is no one-solution that suits all. 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 IT Managers 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. It is usually up to us to come up with an agreed and workable compromise. There is no “one size fits all” paradigm here.

Whereas I fully support the principles behind most EDRMS standards (like ISO 15489) 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.

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 now somewhat old, it is still 100% relevant. You don’t need to agree with me, but please try to understand the message. End users want easy, fast access, not time-consuming complexity.

Let me tell you we solve the problem at Knowledgeone Corporation and manage our emails, electronic documents and shared drives with a hybrid system. We utilize 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 a big fan of making information as easy as possible to capture and as easy as possible to retrieve (eDiscovery). 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.

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.

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.

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.

The structure of our RecFind 6 database is mostly based on customer and prospect files; our Records Management System is also 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, processes and ‘language’ of most staff. Whenever I consult with a new customer, I always try to first determine its core business and its natural language and then design the system around these.

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 focusing on the Entity record (the Entity table is where we store the basic information on each customer or prospect organization). 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.

Ease of Access for eDiscovery

In our RecFind 6 system, every piece of information I need to refer to is just one-click away once I view the customer’s entity record. 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 have configured our RecFind 6 security system around our management structure and that works fine for us. As a Director for example, most of the stuff I save (e.g., a letter, email or quote to a customer) is with a basic security code 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, with appropriate restricted access. Like all good security systems, it is simple but effective.

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.

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, Content, etc. Alternatively, I can search for customer emails from within the Entity record just by clicking on a single link for all emails and electronic documents for that customer.

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. The members of each Security Group see only what they need to see and have only the functionality they need to get the job done

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 groups of users without frustrating any single 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 make users unhappy if you had a choice? Any Records Management System should also be an easy to use Information Management System.

 

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

Month List