What is an Emergent Workflow?
I’m not sure if there’s any consensus on the definition of an emergent workflow. It’s a term that I use to describe a pattern I have witnessed in business software. To me, an emergent workflow is a workflow that was not designed explicitly into a piece of software, but slowly evolved via users’ usage of the system, and the development of conventions to support workflows as they develop. If you have ever developed a piece of business software that manages any form of workflow, and that software has been in production for more than a year, you can be certain that there is an emergent workflow within that software – whether you realize it or not.
The first time I saw one in the wild was about 13 years ago. I was deployed to Florida for Hurricane Charley. I was lead developer on a claims management system, and back then it was common for me to be deployed onsite to write modifications to support the myriad new things that popped up on every event. Three more hurricanes hit soon afterwords: Francis, Ivan, and Jeanne, all within the same month. This presented many many workflow challenges, but the first we encountered was duplicate claim numbers. One of our customers stored multiple claims for the same insured as duplicate claim numbers with different catastrophe codes. This workaround served their purposes, but our system had been designed to disallow duplicate claim numbers.
However, I wasn’t informeed of this conflict in the systems. One of the field managers, being the industrious problem solver that she was, crafted a workaround: She added an * to the claim number for Francis claims, ** for Ivan, and *** for Jeanne. It took a couple of weeks for me to discover this, and by then it was too late for me to implement a proper solution. The workflow was now in full motion, for better or worse. Due to the pace of catastrophe response work there was no opportunity to retrain the adjusters on a cleaner system. This convention created all sorts of reporting and accounting issues, but there was nothing we could do to stop it.
Why are They a Problem?
They Make Reporting More Difficult
Often times you will not know that a new workflow has emerged until you are asked to report on it. In fact, the decision makers in the organization may not know it either. That’s why they’re called emergent workflows. They generally do not emerge via a coordinated decision making process. They are usually the result of one or two people working around a problem and shimmying a solution on their own. And importantly, the majority of these emergent workflows rely upon hand-entered text into fields that were not originally designed for this purpose. As anyone who has ever written a report knows, reporting is a nightmare when you have to report on hand-entered data that should have been a lookup.
Humans make a lot of mistakes when hand-entering data into a system. A whole lot. And aside from mistakes, they are not consistent in their naming of things. (See my other blog post about that) This doesn’t matter when the data they’re entering is intended for human consumption, such as notes fields and other peripheral information. But it is acutely important when they are entering data that is intended to have data integrity and be reported upon. This last point is why emergent workflows are insidious: They usually leverage a data point that was relatively unimportant to store data that is vitally important. Or worse: take an existing vital data point and overload it, destroying the integrity of the existing data and introducing a new piece of hidden business logic.
Users do not Understand Normalization or Data Integrity
Even when these emergent workflows are not subject to data entry errors, they can result in broken data. A common way this occurs is when users ask for new options in a drop-down menu, or even for an entirely new drop-down in the system. This was clearly demonstrated to me earlier in my career on the aforementioned claims management system. Our dispatcher asked for a new drop-down called “Assignment Code” for dispatch locations. I asked her exactly what that meant, and she said that it’s just an arbitrary code that our customer wanted us to mark locations with. I created the drop-down and added entries as the client gave us new assignment codes. Eventually the new assignment code requests became numerous enough that I gave the dispatcher the ability to add them herself. Big mistake. Below is a rough sample of what some of the data looked like:
| ZPC102: Zone – Property – Commision |
| ZPD103: Zone – Prop – Day Rate |
| ZPM104: Zone – Property – Management |
| ZFC105: Zone – Flood – Commission |
| OPC106: Office – Property – Comm |
| OPM107: Office – Property – Mgt |
To anyone familiar with normalization it should be pretty obvious that this “arbitrary assignment code” is actually an amalgamation of multiple data points: One data point being “Zone” or “Office,” one being “Flood” or “Property,” and finally “Commission, “Day Rate,” or “Management.” However, when the assignment codes were first created they did not contain such structured data. At inception they were indeed fairly arbitrary. However, over the years the dispatcher and the customer developed this naming standard.
At a glance this may not seem a big deal. However, this table had several hundred records in it, and there were far more disparate data points being tracked that should have been normalized out. This had become a critically important data point, and we received requests for reports derived from parsing these strings on a weekly basis. My team tried to untangle the mess, and we ultimately found that it should have been normalized out to around 20 tables. Soon after we attempted the normalization process we learned that our customer had internal business logic based on the string names of our assignment codes. They had an internal emergent workflow based on our internal emergent workflow. We were simply unable to fix the mess without impacting our customer’s internal workflow.
The above anecdote is a microcosm of what I have seen any time you allow users to populate drop-downs.
Difficulty of Replacing Legacy Systems
Emergent workflows are far more numerous with off-the-shelf products than with an actively maintained custom solution. The reason is obvious: A custom solution is designed to exactly model your business processes. Any time there is a need for a change to the process, or a new process, a custom solution can be implemented – by a software developer – that matches your company’s needs. With an off-the-shelf solution this isn’t possible. In the cases where the software doesn’t match your company’s needs one of two things happens: Either a) the users track the workflow outside of the system (usually in a shared spreadsheet), or b) the users concoct a wacky convention for tracking this workflow within the system.
In my opinion, identifying and replacing emergent workflows is the most difficult part of replacing legacy systems. It isn’t the reverse-engineering, it isn’t the database design, integration, analysis, programming, or any of that. Identifying the emergent workflows can be dauntingly difficult.
Nine years ago I was the lead on a software project to replace a legacy Sharepoint system. I spent months interviewing every manager, and I developed workalikes for every process I could find. I interviewed employees from every role – or so I thought. There was one table in the legacy system that represented a generic call log. I had interviewed all of the managers in charge of call tracking, and they defined a normalized set of CallTypes to fix the inconsistency of free-form text entry of call types. They renamed one or two of them to more closely fix what they actually were. Two weeks after we went live with the system a problem arose. There was a critical document that all applicants were guaranteed to receive within 10 days of their initial call. Nobody had received that document in 14 days.
How did this happen? Tucked away in one of 500 cubicles was a contractor whose job was to send out this letter. Her (emergent) workflow was to log into the system every morning, export a spreadsheet of the previous day’s calls, and depending on the call types would send out various documents to the applicants. When she encountered “FNOL” as a call type in the spreadsheet she would send out the application document. She had not seen an “FNOL” call type in 14 days because the managers had renamed the normalized type “First Notice of Loss.” in the new system.e
If you had asked anyone on that project the process for sending that document to the applications, not one person could have told you how it worked. The person who had trained the contractor wasn’t even on the project any longer. The contractor sending out the applications was performing a rote function and didn’t really know the specifics of the documents she was sending.
Variants of this story happen on every legacy system replacement. The older and larger the system, the more of these hidden emergent workflows exist.
Increased Impact of Employee Turnover
When your organizations’ workflows are explicitly encoded into your systems there is a reduced training burden on your employees. When a user is presented with a drop-down of options, there is little opportunity for them to damage data. When there is business logic blocking the withdrawal of an approved invoice, again, your employee requires less training. However, what if your process consists of “We add the letter ‘A’ to an invoice comment to denote it was approved. Do NOT withdraw an invoice that has an ‘A’ at the end of the invoice comment…” That is a training burden, and in a large organization with complex processes, you can create a labyrinth of conventions like this to bend an off-the-shelf product to your needs. Not only is it difficult to train new employees on these weird processes, often only one or two employees will know it exists. Because it’s not explicitly encoded into the system, it’s up to humans to track it. And because it was an emergent workflow it is probably not documented anywhere. It is not uncommon for an employee to quit – or for the company to fire the employee – only to have processes halt because they were the sole guru of a wacky workflow.
To be Continued…
Hopefully by now you understand what I mean when I say emergent workflows. Hopefully you also understand why they are so common and so problematic. In part two I will cover identifying and mitigating emergent workflows. I will also cover some guidelines that will help you avoid their emergence at all.