The Lobbi Delivery Team
Operational Systems Engineering
Walk into any post-mortem of a failed automation project and you'll hear the same set of explanations. The integration was harder than expected. The team was understaffed. The vendor's documentation was wrong. Requirements changed. Scope crept.
All of those things might be true. None of them are the cause.
The cause is almost always a decision made three months earlier: the team picked an automation tool — a workflow platform, an iPaaS, a low-code builder, an AI agent framework — before anyone had drawn the process the tool was supposed to automate.
Why that's fatal
Every automation tool comes with a model of how work should flow. Workflow platforms assume linear sequences with branching. iPaaS tools assume event-driven syncs between systems. Agent frameworks assume goal-directed loops. RPA tools assume deterministic UI scripts.
The model isn't visible until you start building. By then it's too late to swap, because half the team's understanding of "the process" has been re-shaped to fit the tool's assumptions. The tool, in effect, has written the process for you. The process was never quite that shape — but now everyone is acting like it is.
The diagnosis-first alternative
Diagnosis-first ops projects look slow at the start. Two or three weeks of mapping with no shipped code. A team that's used to "move fast and ship" can mistake this for procrastination.
It's not. It's the only way to be sure that:
- The boundary is right (SIPOC).
- The owners are right (RACI).
- The handoffs are visible (swimlanes).
- The wait time is real (value stream map).
- The customer-facing impact is understood (service blueprint).
Once those five artifacts agree with each other, choosing the tool is straightforward. The tool's model has to match the actual model. The decision becomes mechanical instead of religious.
What this looks like in practice
The teams we work with that have this pattern internalized share three habits:
1. No tool selection in the first month. The first month is diagnosis. Vendors stay out of the room.
2. Process artifact greater than slide deck. Decisions are made against the maps, not against summary slides.
3. The build phase has a tight scope. Because the diagnosis was thorough, the build phase is short and well-defined. The reverse — short diagnosis, long build — is the failure mode.
The companies that ship lasting automation are the ones that resist starting the build. The ones that don't ship usually started building in week two.
Pick a tool before you draw the process, and the tool will draw the process for you. The tool is rarely right.
Sources
Topic clusters