This article in the AIIM | The Digital Landfill was published on March 5, 2018, and written by Greg Council, Parascript VP of Product Management and Marketing. An excerpt is provided here.
“Digital Transformation is a game changer,” and “leaders embrace digital transformation”—but is it really a game changer and have we actually embraced it?
We’ve all heard plenty of talk about digital transformation. And there is no shortage of articles and research that attempt to define it:
From a CIO Magazine: “Digital Transformation is the application of digital capabilities to processes, products, and assets to improve efficiency, enhance customer value, manage risk and uncover new monetization opportunities.”
Here is another from Scoop: “Digital transformation is the profound transformation of business and organizational activities, processes, competencies and models to fully leverage the changes and opportunities of a mix of digital technologies and their accelerating impact across society in a strategic and prioritized way, with present and future shifts in mind.”
If you Google: “what is digital transformation,” you’ll find an astounding 65 million sites willing to give it a crack.
A Take on Digital Transformation that Resonates
One of the best no-BS explanations comes from an Infoworld article is that digital transformation is the adoption of technology that allows adaptation of business processes. The author uses the word “fungible” to describe a system of technology and processes that are easily exchangeable or replaceable. An HBR article from May of last year, pins the idea of digital transformation to the continuous adoption of emerging technologies.
The mature definition of digital transformation is less about digitizing data or business processes and more about adopting a strategy and corresponding technology framework to build a system that can adapt to an ever-changing business environment. When addressing document-based processes, a definition that focuses on “replaceability” is insufficient and doesn’t reach the level of most project-requirements and complex system design necessary to meet the demands of dynamic, real-world business environments.
Digital Transformation in Document-based Processes
First, when it comes to transformation of document-based processes, the topic isn’t about digitizing or automating an existing process, although doing that does produce positive effects. Digital transformation is about inserting adaptability into your processes with a focus on efficiency and the human experience. It often requires a redesign of existing workflows and system integrations to eliminate unnecessary interventions and enhance the ability for a process to dynamically change depending upon the current situation.
Still, this is high-level talk. What would a digitally transformed document-oriented process really look like?
Digitally Transformed: The Case of the Financial Audit
First, you need to take apart the existing document capture framework that is so common within many organizations. For instance, let’s take the case of a financial audit where financial staff review systems of record and verify that data via locating and matching data within supporting documents. To simplify, let’s consider an organization’s general ledger as the system of record; it records orders and payment for goods and services. Next, let’s consider the supporting documentation as the collection of purchase orders and invoices that are stored in a file cabinet.
A legacy manual workflow might be to take the data in the GL and then, entry-by-entry, look-up supporting documentation such as an invoice or purchase order, or both to verify that the data matches. Looking-up supporting documentation might first consist of locating the recorded purchase order number, or it might involve identifying the supplier name and date out of the GL. Next the process might involve manually locating supporting documentation, sifting through scanned or paper documents to locate those that align with the specific GL entry in-question. Next, a reviewer would scan back and forth to locate the details of the GL entry and then verify that the data both exists on the supporting documents and that it matches. Then the entry is either recorded as accurate or a note for discrepancies is made.
Traditional Capture Workflow
A traditional document-capture workflow might add an invoice and purchase order data capture process as a first step in order to record as much of this data as possible into an accounting system. Since no document capture system is perfect, manual review would need to occur before the data is considered accurate. Then the above tasks associated with auditing would begin, but instead of manually locating supporting documentation and comparing data from the GL entry, the comparison is automated through line-by-line matching of the data. But this process is just an automated version of the serialized manual process, not a redesigned user-centric process.
The Redesigned Process
A redesigned process would start to question the need for a front-end capture process at all. Why go through the trouble and expense of performing data entry of invoice and PO data? In a human-centered process, there is no need to perform data entry; rather an auditor simply verifies that data in a GL entry matches that of the supporting documentation. Additionally, the technology used to perform the verification could be embedded into a workflow rather than precede it.
For instance, supporting documentation could be first collated through an automated sorting process that organized invoices by vendor to accommodate GL entries that do not have corresponding purchase order numbers. The actual verification step itself could use make use of RPA that selects a general ledger entry, extracts the data, and then submits it to a document verification process. This process, would first use the available invoice # or purchase order # to locate the correct supporting documentation. Next, rather than simply locating and extracting invoice or PO data from the located documents, the next stage would take the data from the GL entry and verify presence. If the exact data is not present, best-matches would be found to record the difference in quantity of items or the total amount. Verification would culminate in an exception report that could be reviewed by the auditor.
In this redesigned process, there is no simple automation of an existing process. Rather the process is redesigned so that the auditor only needs to review the report and reconcile erroneous entries rather than performing the arduous process of verification itself. And traditional document capture technology is “loosely coupled” through integration with an RPA application. The result is an ability to adapt to the GL entry selection process, the availability of supporting documentation, or the required data to do verification. The same underlying capability can be applied to any other auditing need using any other system of record.
Down the Road: Adaptation. Adaptation. Adaptation.
Digital transformation is more than about removing paper or automating a traditionally-manual process. It is more about thinking down the road towards a process that can be adapted when required, both in terms of required tasks as well as the supporting technology.