In a world buzzing with cutting edge advancements like Artificial Intelligence, Records Management is often ignored or forgotten as a technology critical for business success. In most cases, it’s considered the opposite of cutting edge and a burden to the organization. This is partially because the Records Management industry seems to be stuck using processes first developed for paper-based records and then later applied to electronic documents but have never really evolved. Thankfully, that’s changing with M-Files and AutoRecords.
Before we dive into how that’s changing, let’s take a closer look at one of the biggest culprits that tends to prevent change within the Records Management industry. Believe it or not, the concept of "declaring a record" which is entrenched in the industry, is a huge problem! As surprising as it may sound, it’s no longer necessary to declare records in a modern business environment.
To show how we can change how we think about Records Management and declaring records, let’s consider an example of a loan. Historically, we would write, type, or print the documents related to the loan and create additional copies using carbon paper or a copy machine. If the loan got approved, some of the paperwork would get declared as “records” and we would hand it all over to the Records Manager to store for different amounts of time based on the types of documents.
With the advent of electronic documents and workflow engines, many paper-based processes have been converted into electronic documents with more controlled workflows. Since we have those shiny new electronic workflows in place, it’s often tempting to just add the Records Management rules and say “this point in the workflow is where the loan application gets declared a record.” Unfortunately, this seemingly obvious solution carries the legacy baggage of “declaring a record” and leads to some important challenges later on.
The first and most obvious challenge is that it’s very difficult for a Records Manager to know where records are in their lifecycle since many documents may go through many different workflows at any given time. Building a report over retention policies suddenly involves the Records Manager being an expert in all the workflows across the organization.
Adding to the complexity is that while Records Management transactions span YEARS, most other business transactions are measured in minutes, hours, and days, with perhaps some periodic processing thrown in. As we do periodic reviews, we must always be mindful to keep tracking retention based on previous steps. When the workflow for the business processing of a document is changed many times over the course of many years, it’s likely some changes may impact the retention of those documents and corrupt the retention timing, especially for existing documents.
Over time, people move on, processes change and the File Plan that represents how long we keep documents doesn’t match reality. The only way to avoid this and ensure consistency is to implement a rigorous retention testing process for any workflow changes, again becoming a burden to the organization.
By including Records Management in the business workflows, we add a tremendous amount of complexity, burden, and room for error in the future. Instead of retention policies hitchhiking on the back of the business workflows, it’s better to think about Records Management as a distinct process. Having Records Management stand on its own eliminates the need for every change in business processes to be tested against its impact on the retention policy.
In the real world, this means that the loan process from our example exists on its own and we can change that process all we want with little impact on the retention policies. Let’s say we keep loan applications for 10 years after the loan closes. We don’t care what happens before or after a loan closes, we just care that it closes. If we need to add seven layers of approval, it doesn't impact retention at all.
Here is where we finally get around to eliminating the concept of “declaring a record.” Remember, that is the Achilles heel preventing Records Management from evolving. In the past we always declared a record based on some event in the organization, like the closing of a loan. However, people would “declare a record, " which would cause them to shuffle paperwork over to the Records Manager. Now that’s not necessary. Now, we can simply respond to an event like a loan closing.
Using M-Files with AutoRecords as the Records Management solution, let’s look at our loan example and see why we should no longer “declare a record.” In M-Files a Loan would be an “object” that has many different documents linked to it. From the moment any Loan or document is created, AutoRecords is aware of it. THIS IS A CRITICAL CHANGE.
In the past, documents existed outside of the Records Management system; at some point, people decided what a record should be. From that point, the Records Management system became aware of the document. In a more modern approach, the Records Management system (AutoRecords) is aware of every document on the system from the moment it is created. Documents aren’t separated or hidden from the Records Management system. Instead, AutoRecords sees all the documents and determines whether retention should start based on things like whether the loan is closed.
The Records Manager now has visibility to all loans and related documents regardless of whether they’ve crossed the magic line of being a “record.” This means the Records Manager can see which documents are under retention and which are in progress and don't have retention yet but will soon have retention applied.
As we go through the loan process, the loan is approved and closed or denied. AutoRecords monitors the closing date and status to determine when to begin retention and determines how long we should keep the documents based on the Records Manager's established criteria. Since it’s likely we keep documents for approved/closed loans longer than those that have been denied, there are also different retention criteria based on whether the loan was approved or denied. Importantly, no one ever declared a record.
As you can see from this example, declaring a record is no longer a thing we do. Instead, we configure policies and establish criteria used to trigger when retention should start. If the loan was set to close at the end of this month, but it gets pushed out two weeks, or if the closing date was set incorrectly, that's OK, too. AutoRecords automatically responds and adjusts retention accordingly.
In the brave new world of modern records management, we need to rethink what it means to declare a record and stop thinking about Records Management in terms of declaring records. In the world of paper, declaring a record did two things. It made the Records Manager aware of a document that needed to be preserved. In modern records management, AutoRecords is already aware of every document on the system. Rather than declaring records, we configure policies and let AutoRecords do the work of assigning retention and responding to events on the system.
In the end, the change has to do with perspective. Declaring a record used to be a transaction. It was part of a document lifecycle and meant two things: Records Management is now aware of this document and we’ll start tracking retention for the document from this point. As we evolve to modern records management “declaring a record” is a configuration. Instead of declaring a record something you do, it’s something you PLAN to have the system do. AutoRecords is responsible for carrying out that plan. It is aware of all the documents and uses the plan you build to ensure uniform application of retention policies for all documents.
It’s finally time to stop declaring records. Build your File Plan and let AutoRecords do the work for you.
No Comments Yet
Let us know what you think