The Autonomous ECM

For many years, people were convinced that the automobile industry was very advanced. We were proud of “smart” cars that were able to read traffic signs, alert us to short distances between the car and other objects, and tell us to fasten our seatbelts.

But it really wasn’t until the presentation of Google’s driverless car in 2011 that we all saw true automation in the automobile industry. Google’s autonomous car is what can really be called a smart car; it is a true milestone for this industry. It gives people the possibility of travelling without having to do the manual tasks that lead to so many errors and dangerous situations. Since 1886, when the Motorwagen was invented, it has taken the industry more than 130 years to achieve this magic.

The ECM industry is progressing very quickly, but it is still clinging to “smart” functions that are very far from what would really be a “driverless ECM”.
With the current ECM solutions, users have to “drive” in order to get anywhere they want to go:

  • Document types have to be created (in the majority of cases, codified).
  • The same is true for metadata, metadata types, diagrams, designs, etc.
  • The users must be the ones who define the entire hierarchy and structure of their document organisation.
  • And to top it all off, teams in the company have to come to an agreement in order to create an efficient strategy for using the ECM software they have purchased.

Many of you surely know what I’m talking about. The process for implementing an ECM system in any organisation is like driving down old Route 66 in a Chevrolet Bel Air. Nice, but zero automation.

Many experts would classify the ECM market as mature, but until we have true automation, it’s comparable to the human-driven car industry.

Current ECM software lacks many elements in order to meet the challenge of being a “driverless ECM”. Some of these include:

A high-definition map of the document type, metadata, and characteristics of the document.

An important step to reaching this milestone is a profound process of feature engineering of the documents that will, as a result, provide us with a knowledge base. Current ECMs could draw upon this knowledge base in order to suggest document types, metadata, and general configuration to users in addition to allowing them to reuse information they already have.

A good radar for measuring the features of documents, metadata, and characteristics.

In many cases during the operations that ECM systems carry out, you have to answer the question “Are these the same document type?”, “How are they similar?”, or “Do they have the same value for some metadata?” In the ECM industry, there are still no standard algorithms for comparison, solutions, and standards.

A high-precision laser rangefinder for modelling the real world in a document.

This is what we nowadays call a “document analysis system”. Truly incredible work has been done in this area, but the only solution that seems really industrialised is OCR. Design recognition, language detection, decoding, and some other characteristics already have solutions, but none of them can really be called a milestone yet.

Instruments for deciding where to go and what to do with the documents.

The ECM and BPM worlds have a long-standing yet rocky romance. There are very complex workflows in ECM. These flows are complex due to the elements at play, security issues, external and internal users, updates to metadata, tasks, and the many side effects that occur when a document goes from one phase to another.
The ECM industry really needs to create a “driverless experience” in this sense. Users need to have existing workflows so that the ECM can suggest a workflow to use, a path to follow. Imagine our ECM software telling us, “This is an invoice. Do you want to send it to the Accounting Department?”

A remote server farm to carry out complex tasks

The driverless car is possible thanks to a lot of currently-existing. One is the ability to distribute the execution of complex tasks (distributed computing). If the driverless car has achieved this already, the ECM world must do it now. Some of the “smart” features that we expect from a driverless ECM actually require a lot of computer processes, a lot of image processing, a lot of text processing, and a lot of autonomous learning. All of these processes must be distributed. The ECM world needs a standard in order to rid ourselves of difficult tasks and focus on the driverless user experience.

As you can see, current ECM software is still very far away from real automation. How long are we going to have to wait before we see driverless ECM?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

About mgathento