Perspective
Automation promises something every organization wants: less manual work, faster execution, fewer errors, and more time for people to focus on higher-value work.
But automation does not automatically improve a process.
If a workflow contains unnecessary approvals, duplicate data entry, inconsistent procedures, unclear ownership, or workarounds that developed over years, technology can simply make those problems happen faster and at greater scale.
That is why the first question shouldn't be, "What can we automate?" It should be, "How does this work actually get done today?"
Most organizations have an official version of a process.
A request arrives. Someone reviews it. It gets approved. The work is completed. The customer is notified.
Simple. But the real process might look very different.
An employee receives the request by email. Information is copied into a spreadsheet. Someone messages another department for missing information. A document is downloaded, renamed and stored somewhere else. An approval sits in an inbox. Someone follows up manually. Another employee maintains a separate spreadsheet because the primary system doesn't provide the visibility the team needs.
These variations matter.
Microsoft describes process mining as a way to use event data from systems of record to visualize how organizational processes actually operate, identify inefficiencies, investigate their root causes and monitor KPIs. Its documentation specifically highlights discovering unnecessary actions, mistakes and automation opportunities.[1]
That distinction between the intended process and the actual process is critical. You cannot intelligently redesign what you don't understand.
Imagine an organization receives customer requests through email. An employee manually reviews each request, determines where it belongs, copies the information into another system and forwards documents to the appropriate team.
The obvious automation opportunity might be: automatically read the email and enter the information into the existing system. That could save time.
But it doesn't answer more important questions. Why is email the intake mechanism? Why is information being entered twice? Why isn't ownership established when the request arrives? Which requests actually require human review? Why are documents moving between systems? What happens when information is missing?
If those questions aren't addressed, the organization may successfully automate a workflow that shouldn't exist in its current form.
If you automate a workflow that shouldn't exist in its current form, you've made the wrong process more efficient.
Automation comes after understanding — not before it.
Before designing an automation, map what happens from beginning to end. That means identifying the trigger that starts the process, the people involved, systems and data used, decisions and approvals, handoffs between teams, exceptions and workarounds, and the outcome the process is supposed to produce.
Modern process-mining platforms are built around this idea. For example, UiPath describes process mining as reconstructing processes from system event data so organizations can expose deviations, exceptions, bottlenecks and workflow inefficiencies before prioritizing optimization or automation opportunities.[2]
This doesn't mean every organization needs sophisticated process-mining software before automating anything. For smaller workflows, interviews, observation, existing system data and a well-constructed process map may reveal plenty.
The important part is that the current state is understood before the future state is designed.
Once the process is visible, another mistake becomes easier to avoid: assuming every manual step is a problem.
Some work is manual because it involves judgment.
A manufacturing engineer deciding whether a drawing is technically feasible is different from someone manually copying an RFQ number from an email into a spreadsheet. A healthcare professional making a clinical judgment is different from someone repeatedly transferring administrative information between systems. A manager approving an unusual exception is different from automatically notifying that manager that the exception needs attention.
Good automation distinguishes between them.
Technology is particularly useful for repetitive, rules-driven work: moving information, creating records, routing tasks, generating notifications, synchronizing systems and surfacing information for decisions. People should remain where context, judgment, accountability or expertise matters.
That creates a different objective: don't automate the most work — automate the right work.
There is an important nuance here. "Fix the process before automating it" should not become "make every variation disappear before doing anything."
Real organizations have legitimate process variations. Different locations, customers, regulations or transaction types may require different paths.
UiPath has argued that organizations should focus on understanding which process paths should be automated and the business outcome they are trying to achieve, rather than delaying all automation until every variation has been consolidated into one universal process.[3]
So the objective isn't perfection. It is intentionality.
Understand why variations exist. Remove unnecessary ones. Preserve legitimate ones. Then design automation around the process the organization actually wants to operate.
An automation can work perfectly from a technical perspective and still struggle operationally. Why? Because a workflow is also a human system.
Employees need to know what changed, what the automation handles, what they remain responsible for, what happens when something fails, and how exceptions are handled.
And when automation removes repetitive work, organizations need to think about what employees do with the capacity that has been created.
The goal isn't simply: person did task → software now does task.
The larger opportunity is: software handles repetitive work → people spend more time on work requiring judgment, relationships, analysis and decision-making.
That is where automation starts becoming operational transformation rather than another technology deployment.
Deployment isn't the finish line. Organizations should define what improvement means before implementation.
Depending on the process, that might include cycle time, manual touches, error or rework rates, backlog, exception volume, customer response time, employee effort or processing cost.
Then measure the process after implementation.
This is also why process-mining platforms increasingly emphasize continuous monitoring. Microsoft describes process mining as a way to monitor KPIs and identify performance issues,[1] while UiPath emphasizes measuring automation's effect on end-to-end processes and continuing to optimize them.[2]
Without measurement, an organization knows that it deployed automation. It doesn't necessarily know that it improved the operation.
The most useful automation conversations don't begin with a product demonstration. They begin with questions.
What are we trying to accomplish? How does the work happen today? Where does it slow down? Where is information duplicated? Which decisions require human judgment? What should the future process look like?
Only then does the technology question become useful: what should we automate?
At DaVinci-X, that's the principle behind how we approach operational modernization. We start with the operation, understand the current state, identify unnecessary friction, redesign where necessary, and then determine where automation and connected systems can create meaningful improvement.
Because making a broken process move faster isn't transformation. It's just faster dysfunction.
Technology should follow the operation—not define it.
