When telecom operators talk about automating something, the default mental model is usually a workflow — a sequence of steps that, if performed in order, produces the desired outcome. Documented workflows are useful. They are also not automation.
A workflow tells you what should happen. A system makes it actually happen — observably, reproducibly, and without a human watching every execution.
Where the gap shows up
In OSS / BSS automation work, the pattern is consistent. There is usually a written runbook for whatever process needs automating. The runbook lists twelve steps. Five of those steps assume context an engineer holds in their head. Two of them branch silently on conditions nobody has documented. One of them refers to a screenshot from a system that was upgraded last year.
A workflow that requires a senior engineer to interpret it is not an automation candidate. It is the input to a design exercise.
What turns a workflow into a system
Three things, in roughly this order:
-
Make the steps unambiguous. Every conditional branch, every exception case, every "you'll know it when you see it" — surfaced and explicit. If the workflow cannot be described as a state machine, it is not ready to automate.
-
Make the actions reversible. Production telecom changes need rollback paths. A system that can do but cannot undo is not safer than the manual process; it is faster and equally fragile.
-
Make the execution observable. Every action logged with enough context that an engineer can reconstruct what the system did, when, and why. This is the difference between an automation that engineers trust and one they work around.
The honest version
Most "automation" projects in telecom fail this test. They produce a script, or a UI on top of a workflow engine, that runs the original twelve-step process slightly faster and with worse error handling. The operations team learns to distrust it within a quarter, and a year later they are running the manual process again, with the automation gathering dust.
The discipline is to refuse to automate workflows that are not yet systems. Spend the time to make them unambiguous, reversible, and observable first. Then automation becomes worth doing.
Expanded version with examples from EME / ACMA workflow automation is in development.