Every digital transformation programme I've been part of in aviation eventually runs into the same question: we can't automate everything at once, so what do we automate first? Get this sequencing wrong and you end up with an automation that's technically impressive and operationally irrelevant — solving a process nobody was losing sleep over while the actual bottleneck stays manual.
The instinct to automate everything
The natural instinct, especially early in a transformation programme, is to map every manual process and start automating from the top of the list. This feels productive and looks good in a steering committee deck. It's also usually the wrong approach, because not all manual processes are equally costly, and the cost of a process isn't always obvious from how much time it visibly consumes.
A process that takes a buyer twenty minutes, twice a day, feels less urgent than an AOG sourcing workflow that takes four hours once a month — but over a year, the twenty-minute process has consumed far more total effort. Frequency compounds in ways that intuition tends to underweight.
A simple framework: frequency × friction × consequence
- ›Frequency: how often does this process happen? Daily processes compound; quarterly ones don't, regardless of how painful each instance feels
- ›Friction: how many manual handoffs, systems, and people are involved? More friction means more opportunity for error and more time lost to coordination rather than the work itself
- ›Consequence: what happens when this process is slow or wrong? An AOG sourcing delay costs revenue by the hour. A delayed monthly report costs almost nothing beyond someone's afternoon
Score each candidate process against these three dimensions and the priority order usually becomes obvious — and it's rarely the process that feels most visibly broken. High-frequency, high-friction, high-consequence processes are the ones worth automating first, even when they don't generate the loudest complaints.
Three automations worth doing first, in most aviation operations
- ›Document intake and routing: incoming maintenance records, certificates, and correspondence classified and routed automatically instead of manually sorted — high frequency, high friction, and it unblocks every downstream process that depends on that document
- ›AOG shortlist generation: automatic identification of qualified suppliers by part number the moment a requirement is raised — low frequency compared to document intake, but the consequence per instance is enormous
- ›Status reporting and QBR data assembly: pulling usage, support, and operational metrics into structured reports automatically instead of manually compiled each cycle — frees up the highest-leverage people on the team for analysis instead of data collection
The change management piece nobody budgets for
The technical build is rarely the hardest part of workflow automation. The hardest part is that automating a process changes what the people who owned that process do all day — and if that transition isn't managed deliberately, the automation gets quietly worked around, sabotaged through inconsistent data entry, or simply ignored in favour of the old spreadsheet everyone trusts more.
The rollouts that stick share a pattern: the people whose work is being automated are involved in designing the new workflow, not just informed of it after the fact. They understand the exceptions and edge cases the process needs to handle — knowledge that's easy to miss when a transformation team designs a workflow in isolation from the people who actually run it.
Automate what's frequent, frictional, and consequential — not what's most visible. And budget as much attention for the people whose workflow is changing as you do for the system that's changing it. The best automation in the world fails quietly if the team using it doesn't trust it.