Automation needs understanding first. A process you cannot describe precisely is a process you cannot encode, and automating around that gap simply moves the confusion into software. Clarity is the harder task, and it is the one worth doing first.
There's a recurring conversation I have with leaders. It usually starts with a list of things they want to automate. Manual processes that take too long. Reports that require human intervention. Tasks that seem like obvious candidates for elimination.
The instinct makes sense. Automation is tangible. You can point to a process, measure its cost, and calculate the savings. It feels like progress. It produces results you can show.
Practitioner note: in live implementation work the request almost always arrives as a list of things to automate, not as a description of how the work runs today.
But as we dig into the details, something else emerges. The manual process isn't slow because it's manual. It's slow because no one agrees on what it's supposed to produce. The report requires human intervention because the underlying data doesn't make sense without interpretation. The task can't be automated because the rules that govern it were never clearly defined.
The problem isn't automation. The problem is clarity. And clarity, it turns out, is much harder to achieve.
Automation cannot encode a process that nobody has articulated precisely. Establishing that clarity is the more demanding discipline, and its difficulty is precisely why organisations postpone it in favour of visible implementation work.
Automation requires understanding. You can't encode a process you don't fully comprehend. You can't build rules for decisions that haven't been articulated. You can't eliminate human judgment from a task that depends on context nobody has documented.
Most organizations have less clarity than they assume. The processes that run every day are often held together by tacit knowledge, by people who know what to do when the system produces an unexpected result, by informal rules that never got written down. When you try to automate, you expose all of this. The gaps become visible. The ambiguities surface. The exceptions multiply.
Practitioner note: in live implementation work this is the most common cause of delay. The build stalls not on the technology but on the first question nobody can answer precisely, which is what the process actually does when the exception arrives.
I've seen automation projects stall not because the technology wasn't ready, but because the organization wasn't. The team couldn't agree on the business rules. The edge cases kept expanding. Every time they thought they had defined the logic, someone raised another scenario that didn't fit.
This isn't a failure of the project. It's a success of a different kind. The effort revealed something important: the process wasn't actually understood. What looked like a straightforward automation target was actually a web of undocumented decisions, informal agreements, and situational judgment.
Clarity is harder because it requires choices. You have to decide what the process should do, not just describe what it does. You have to resolve the ambiguities that people have been navigating around. You have to make explicit the rules that have been implicit. And that often means having conversations that organizations have been avoiding.
It's easier to automate than to clarify, in the sense that automation can proceed even when clarity is missing. You can build something that works for the common cases and handles exceptions manually. You can create a system that mostly functions and requires human cleanup. But you haven't solved the underlying problem. You've just dressed it up.
Practitioner note: in live implementation work the projects that stall are rarely blocked on technology. They stall on the first question nobody can answer precisely, which is what the process does when the exception arrives.
I wonder how often automation is pursued as a substitute for the harder work of understanding. It's appealing to believe that technology can bypass the need for clarity. That you can automate your way past the ambiguity. That the system will figure out what the organization hasn't.
But systems don't create clarity. They encode it, or they encode its absence. If the inputs are confused, the outputs will be too. If the logic is muddled, the automation will faithfully reproduce the muddle at scale.
I wonder, too, about sequencing. What would happen if organizations pursued clarity first, automation second? If they invested in understanding before investing in encoding? If they treated the articulation of business rules as a deliverable in itself, not just a prerequisite to something else?
The benefits wouldn't be as visible. Clarity doesn't produce screenshots or dashboards. It doesn't have a go-live date. It's harder to celebrate and easier to defer. But it's often the thing that determines whether everything that follows will succeed or struggle.
I've come to think of clarity as infrastructure. Not glamorous, not exciting, but load-bearing. The processes that work well are usually the ones that were clearly defined. The automations that deliver value are usually the ones built on solid understanding. The decisions that get made quickly are usually the ones where everyone agrees on the facts.
Some organizations find it valuable to invest in clarity deliberately, to map what they actually do, surface the ambiguities, and resolve them before trying to automate. Not as a delay to progress, but as a foundation for it.
That foundation, I've found, pays dividends long after the project is done.
There's a recurring conversation I have with leaders. It usually starts with a list of things they want to automate. Manual processes that take too long.
Automation requires understanding. You can't encode a process you don't fully comprehend. You can't build rules for decisions that haven't been articulated.
I wonder how often automation is pursued as a substitute for the harder work of understanding. It's appealing to believe that technology can bypass the need for clarity. That you can automate your way past the ambiguity.
These published sources cover the detail behind the points above:
Softype is an Oracle NetSuite solution provider with more than 25 years of experience and over 600 implementations. Our team sets NetSuite up around how your business already runs, then stays on to tune it as you grow. To see what that looks like for your own numbers, book a meeting with our team.
Automation requires understanding: you cannot encode a process you do not fully comprehend.
Leaders often arrive with a list of things to automate before the process itself is clear.
Automation is sometimes pursued as a substitute for the harder work of understanding.
Clarity is slower to reach than automation, which is exactly why it gets skipped.
Mapping what a process does, including its exceptions, is the step that makes automation stick.
Write down what the process does when nothing goes wrong. Then write down every exception someone handles by judgement, and what tells them the exception has occurred.
That second list is the one that matters. It is usually undocumented, it lives with experienced staff, and it is what an automated workflow will get wrong if nobody captures it first.
Helping businesses thrive with integrated ERP solutions.
NetSuite
Service
Company
Contact Us
Copyright © 2026
