Your Automation Approach is Adding Data Debt to Your Organization!

Process automation positively impacts businesses in many ways, including the elimination of human processing errors, faster processing, 24×7 work time, and the scaling of capacity to flatten peak workloads.  With so much goodness, what could be bad?  How about the data debt that is piling up with each process automation?

With all the talk of robotic process automation (RPA), intelligent process automation (IPA), Hyperautomation, and other fancy terms, at the most basic level of a business process is the movement of data.  Data moves from Point A to Point B, PDF to system, system to system, system to report, etc.  The ultimate purpose of these data movements is to support data-driven decision making at various management levels.  If all goes well, captured data is mined for insights that improve the customer experience.

What is data debt?

Data debt is the cost that comes with a decision to choose fast solutions over the longer, more technically correct solution.  Sometimes these decisions are known at the time or origin, but they can also get established over time, unknowingly.  A relatable example of (inadvertent) data debt is the unstandardized practice for name and address entry.  Also related is the implementation of name and address entry standards after the process has matured, but a decision is made not to clean-up and align legacy data with the new standards.

In both situations, unstandardized name and address databases force downstream processes to contend with data variations.  Now, consider the processing impacts of name and address variations across Procurement, Accounts Payable, Accounts Receivable, Accounting, Sales and Marketing, and Reporting.  Human accommodations for these data deviations might not be fully understood or realized, because it is easy enough for an employee to perform a lookup and use historical processing knowledge to make the right selection.  The fact is, these accommodations are process deviations.

Process deviations across downstream processing create process waste and complexity, but also adds to the data debt that is unrealized by most organizations.

Fast forward to the future when you upgrade your name and address system to a new CRM system.  The organization is now confronted with the decision to standardize the data or convert as-is.  Standardizing the data increases the costs, time, and risk of the project, whereas converting as-is maintains (or increases) the data debt in the organization and perpetuates bad data practices.

How automation contributes to data debt

Automation backlogs consists of process candidates that are typically isolated functions (or tasks) within a larger process (e.g. invoice registration).  Decisions to “green light” or automate a process from the backlog are based on priority, projected returns on investment (e.g. hours, FTEs), and if the ‘gating’ qualifications have been met.  Most qualification guidelines include the identification of ‘known’ process deviations at a higher level (Levels 0 to 3), but it is easy to miss process deviations resulting from human accommodations to support bad data practices at the desktop level (Level 4).

To the trained and untrained eye, a business process might look to be standardized and consistent at the higher levels and even during a process (desktop) walk-through.  Automation development teams will define the process definition document and scope the business process based on the business team walk-through.  Depending on your development methodology (e.g. agile or waterfall), process variations caused by inconsistent data are identified during development reviews or during user acceptance testing (UAT).  Accommodating process variation within the current phase of the automation project might seem insignificant, but they will often add up and expand the scope of the project and in many cases increase the project duration.

Project scope creep and longer project times aside, the deeper issue is that process variations are often solved with hard-coding unstandardized data or by utilizing lookup tables, which really means the automation has now established the bad data practices as standards.

Data debt in practice

An example that exemplifies the data issues is starting with invoice registration for automation.  The AP invoice registration team receives an invoice and manually keys the invoice into the registration system.  Data entry usually entails straight entry and the utilization of field lookups to select and ‘connect’ the invoice with the vendor data and required internal coding structures.  From a top level, the process looks to be consistent and repetitive, but it is easy to miss that the processor is performing multiple lookups to identify the correct vendor or business unit entries for selection because of data inconsistencies.

It is commonplace for the lack of governance over vendor name and address entry or Purchase Order entry, therefore resulting with inconsistent data being keyed into supporting systems.  The issue this causes is that the information is a critical input for many downstream processes that will require process variations to support (subtle variations or more pronounced) the unstandardized data.

Eliminate data debt, create business agility , and transform your organization!

If you are thinking, “It is impossible and impractical to map out every process scenario,” then you are correct, but you are not addressing the root cause of the process variations, which are usually the result of inconsistent data entry standards.  To dig deeper into the issue, we need to examine where the unstandardized data originates from and address at the point of entry into the organization (where possible/practical).  From an automation perspective, this means that automating the process with the highest ROI might not be the right process to start with and you might need to start reengineering for automation further upstream to bring ‘real’ transformation to the organization.

We recommend examining all process inputs during the scoping phase of an automation, then ask if the inputs have a standardized process at their point of entry.  The Yes/No answer will help to determine if an investigation is required to examine the quality and consistency of the data.  Based on the outcome of the analysis you can determine how to best address for your organization.

Parting thought

Transformation of an organization usually does not come from the shiny object in front of you but comes from establishing the right practices to guide an aligned organization.  It is also important to note that transformation occurs though many available tools (levers to pull), such as system upgrades, reengineering, expansion of system functionality/parameters, or automation.  Too often, people want to believe automation is the only answer for transformation, but it highlights an organization that is not aligned on transformation initiatives.

In future articles we will address the important of an “aligned organization” for transformation, but for now I hope this article has been informative and thought provoking.

Please reach out on info@vigilant-inc.com. We would appreciate hearing your feedback or having discussions to learn how we can help support your data governance implementation and execution, or automation initiatives.  Thank you for reading.