In ops work, one person often knows that a CRM customer account number differs from the ERP account ID, and how to find one using the other. They know which system supplies the inventory report, which system receives the shipping confirmation, and how the data must be formatted for that handoff. When the connection between systems fails, the message goes to them.
This person may be highly effective, yet they also represent a concentration of operational risk that few teams have examined. The knowledge needed to connect the systems is rarely recorded. It remains in their head, built up over months or years of dealing with edge cases nobody else had time to capture.
How This Pattern Starts
It begins with a concrete requirement. Two systems must exchange data, but no automated route exists. Someone works out the manual steps and takes responsibility for them. Since they handle it well, the task remains theirs. More work then gathers around it. The person managing the CRM-to-ERP transfer also performs the monthly reporting export, compares the purchase order log with vendor invoices, and knows what to do when a payment gateway file does not quite fit the accounting system's expected format.
No one intentionally assigned all these tasks to one person. They gathered there because that person was available, capable, and willing. The organization chose to have one person carry the coordination burden instead of creating a dependable process for every handoff.
It is sensible in the short term but expensive as an architecture over time. The expense appears when that person is unavailable.
The Vacation Test
The clearest sign of a human-link dependency is what happens during that person's week off. Can the ops team run every process that normally passes through them? Or does work pile up, leaving them to spend their first day back working through the queue?
The vacation test works as a useful proxy because it poses the issue within a limited, recoverable period. A week's delay to the monthly export is a problem, not a crisis. Finding the same dependency after the person leaves the company offers no such recovery window.
This pattern does not mean ops teams are being careless. It emerges in response to a real need: two systems require data from each other, but no structured route connects them. The person bridges the gap. Eventually, that person is the gap.
What the Cost Really Is
The direct cost is time. If the ops connector spends four hours each week moving data between systems, those hours cannot go toward analysis, process improvement, customer response, or the other work they were hired to perform. Over a year, more than two full work weeks are consumed by activity that is fundamentally mechanical.
The indirect cost is fragility. Any process dependent on one person has a single point of failure. If they are promoted, change roles, or leave, the processes they maintained must be documented again and reassigned. That is when organizations often learn how much operational knowledge was never recorded anywhere else, and that replacing it takes longer than expected.
Accuracy creates another, less obvious cost. Moving data manually between systems creates opportunities for mistakes at every stage: a transposed value, a skipped export row, or a format mismatch resolved through a judgment call about which value belongs. Such errors are generally small and eventually found. But "eventually found" carries a lot of weight. Some are missed, becoming discrepancies that appear at month-end, during an audit, or when a customer reports that something does not match.
Map the Dependency First
To address a human-link dependency, first make it visible. Meet with the person who holds the knowledge and record every manual process they run. For each process, capture its trigger, the systems involved, the form of the input and output, the edge cases handled through judgment, and how often it runs.
This exercise is useful even before automation begins. It spreads the knowledge, makes the processes visible to the team, and establishes a baseline for what an automated version must handle.
In every exercise we have completed, the person interviewed can identify the three or four processes responsible for most of their connector time. Those three or four are the best place to begin automation, not because they are complex, but because they happen often and become costly when delayed.
The aim is not to remove this person from the ops team. Their value comes from understanding the system connections so well. The aim is to take routine mechanical work out of their day, allowing that understanding to guide exception handling and improvements instead of repeated data transfer. That uses their accumulated knowledge more effectively and gives the processes they alone hold together a more resilient structure.
