Most businesses do not wake up saying, "Our digital operating architecture is weak." They describe the symptoms instead. Onboarding is messy. Reporting takes too long. The CRM is there but nobody trusts it. A customer issue has to be chased through three people. The same information is copied from one system into another. Automations work until an exception appears.
These are not isolated annoyances when they happen repeatedly. They are signals that the systems underneath the operation are carrying friction.
Growth makes weak systems more expensive
A manual workaround can look harmless when ten transactions move through it. At a hundred, it becomes a workload. Add more staff, customers, software and handoffs, and the business starts paying for every ambiguity in the process.
Google's site reliability engineering book has a useful name for this kind of work. It calls it toil: work that is manual, repetitive, automatable, reactive, without lasting value, and that scales linearly as the service grows. The last property is the one that hurts a growing business. Toil does not get cheaper with volume. It grows in step with it.
The cost is not only labour. It appears as delayed responses, duplicate work, inconsistent customer experiences, weak reporting, management time spent reconstructing reality, and dependence on the people who happen to know how everything works.
Growth does not necessarily create operational weaknesses. It often reveals weaknesses that smaller volume was hiding.
A worked example
A Durban-based packaging supplier grows from 25 to 70 staff over four years. When it was small, the sales administrator checked stock by walking to the warehouse, confirmed delivery dates by phoning the transport coordinator and keyed orders into the accounting package. At 70 staff there are three sales administrators, two warehouses and a dispatch team. The same checks now involve WhatsApp groups, a stock spreadsheet updated twice a day and a daily meeting to confirm what shipped.
No single step is broken. Yet the business now employs people whose main job is to carry information between systems and between other people, a condition described in why high-value employees become human middleware.
More software is not automatically better infrastructure
Businesses often respond to friction by adding tools. A new CRM, dashboard, automation platform or AI product can feel like progress because it is visible and purchasable. But software cannot resolve operating logic the business has never clarified.
If ownership is unclear, the platform will encode unclear ownership. If the handoff between teams is badly designed, integration may only move bad information faster. If data quality is weak, a better dashboard can create a cleaner view of unreliable data.
Tool sprawl becomes especially expensive when every application solves a local problem while making the overall system harder to understand. Microsoft's 2023 Work Trend Index found that 62% of survey respondents struggle with too much time spent searching for information, and 68% say they do not have enough uninterrupted focus time in the working day. Fragmented systems contribute to both. The broader argument is made in why more software can make the business harder to run.
The real system has three layers
A useful way to think about the digital operating environment is through three connected layers.
1. Digital Infrastructure
The applications, platforms, data structures, integrations and technical foundations that operations depend on.
2. Digital Operations
The workflows, handoffs, roles, information flows, reporting and process logic through which work actually moves.
3. Business Automation
The automation layer that coordinates repeatable actions across people and systems.
Problems appear when these layers are designed separately. An automation can be technically correct but operationally wrong. A workflow can be sensible but unsupported by the software. A platform can be powerful but poorly matched to the business process.
When diagnosing friction, it helps to ask which layer the symptom lives in and which layer causes it. A slow monthly report looks like an infrastructure problem. Often the cause is an operations problem: three teams define "active customer" differently, so someone reconciles the numbers by hand every month.
Automation should follow process clarity
There is a simple rule worth keeping: do not automate a broken process merely to make the broken process run faster.
Before automating, ask what should happen, who owns each decision, what information is required, what exceptions exist and what the business should do when the happy path fails. Sometimes the best automation project starts by deleting steps rather than adding technology.
AI belongs under the same discipline. Some work benefits from language models or agents. Other work is better served by deterministic rules, a database constraint, a simple integration or a person making a controlled decision.
Visibility is part of the operating system
Reporting is not a decorative layer added after the work. A business needs to see enough of the workflow to know whether it is healthy. That means status, ownership, errors, bottlenecks and meaningful outcomes should be observable at the points where decisions are made.
When visibility is weak, management often compensates with meetings and manual status chasing. That can hide the architecture problem rather than solve it.
Reduce key-person dependency without removing human judgement
Strong systems do not try to remove people from every process. They reduce the amount of essential operating knowledge that exists only in individual memory.
Documentation, clear ownership, system logic and visible exception paths make the operation less fragile while keeping human judgement where it matters. The risk of leaving this knowledge in heads is explored in key-person dependency is a systems problem.
Warning signs worth taking seriously
- The same data is typed into more than one system as a matter of routine.
- Status questions are answered by asking a person, not by looking at a system.
- Month-end or reporting cycles depend on one or two individuals.
- New hires take months to become independent because the process is unwritten.
- Each new tool was bought by a different team to solve a local problem.
- Automations exist, but staff still check by hand whether they ran.
How to measure friction you cannot see
Friction is hard to see because it is spread thinly across many people. A practical approach is to pick one end-to-end process, such as quote to cash or hire to productive, and count the touches: how many times a person re-keys, checks, chases or reconciles something between the trigger and the outcome. Multiply by volume and an approximate hourly cost, and the hidden workload becomes a number the business can discuss. Methods for this are covered in how to find the manual work nobody is measuring.
When diagnosis is more useful than another purchase
If the business can clearly define the required integration or workflow, implementation can begin directly. But when several symptoms are interacting, diagnosis is usually more valuable than choosing another platform.
A useful assessment should identify what to keep, what to fix, what to integrate, what to automate, what to replace and, equally important, what to leave alone. That is the purpose of a digital systems audit.
What to do first
- List the five symptoms that cause the most complaints from staff or customers.
- Trace each to the process it sits in, and note which layer is the likely cause.
- Pick the process with the most symptoms and count its touches and handoffs.
- Remove or simplify at least one step before buying anything.
- Only then decide whether integration, automation or a different tool is needed.
The goal is not a more impressive technology stack. The goal is a digital operating environment that people can use, understand, maintain and improve as the business changes.
Sources and further reading
- Google SRE - What is Toil in SRE: Understanding Its Impact (last verified 10 October 2026)
- https://www.microsoft.com/en-us/worklab/work-trend-index/will-ai-fix-work (last verified 10 October 2026)
Related Mellorca reading
- Piling on more software is not digital maturity
- How to separate urgent systems problems from merely annoying ones
- Why technology spend does not automatically create business value