Automating a Process Portfolio: How to Sequence 40 Broken Processes Without a Failed Pilot

Why do process automation pilots fail?

Most failed pilots were not failures of the tool. They failed because of what was chosen first and how success was judged. A leadership team that has already watched one pilot stall is right to be sceptical of a second, and the way to earn that trust back is a sequence that makes early success likely and visible, rather than a bigger promise.

• The pilot started with the most painful process, which was painful precisely because it depended on the legacy system nobody can connect to.
• The data the automation needed was inconsistent, so the flow spent its time handling exceptions and people stopped trusting its output.
• Nobody in the business owned the process, so every design question waited for a meeting and nobody signed off the result.
• Nothing was measured before the build, so nobody could show whether the automation helped.
• A single developer built it, and every other department joined a queue behind that person.
• There was no environment, DLP or deployment discipline, so the pilot worked in a maker environment and could not be promoted safely.

How do you score forty processes with a triage rubric?

Score each process on the four criteria below, using a simple scale such as one to three, in a workshop with the people who run the process rather than from a spreadsheet of process names. Volume, error cost and regulatory exposure measure value; integration difficulty measures effort. Then apply two gates that are not scored but decide eligibility for the first wave: is the data source clean, and is there an owner who wants this. The output is a ranked list, and processes that score high on value but fail a gate go into a later wave with the gate as a named prerequisite, instead of being dropped.

Why must the first automation have a clean data source and a willing owner?

The first wave is not only a delivery; it is the evidence the rest of the roadmap is judged on. It has to go live, work reliably and produce a measured result that a sceptical leadership team accepts. A clean data source means the automation handles the normal case most of the time, so the result reflects the automation rather than the state of the data. A willing owner means requirements are decided quickly, testing happens with real cases, and the business announces the result instead of the delivery team.

That usually points the first wave at processes such as approvals, intake and routing, notifications, and document handling around Microsoft 365, Dataverse or Dynamics 365, rather than at the core legacy transaction. Approval processes are a common first choice because the decision can live outside the legacy system even when the transaction does not; how approval flows work for finance teams is covered in our article on how Power Automate approval flows save mid-market finance teams time.

How do you classify legacy ERP integration before estimating effort?

Every process that touches a legacy system is classified by the best route into that system, and the class drives both the effort estimate and the wave it belongs in. Use the highest class available, and treat screen automation as a last resort rather than a shortcut. Solzet builds the automation side; we do not implement or modify the ERP itself, so where an interface needs creating on the ERP side, such as an export, a staging table or an import routine, we specify it and your ERP team or vendor builds it.

How do you sequence waves with a measured result before the next?

A wave is a small group of processes delivered together, with its measure agreed and baselined before the build starts. The next wave does not start until the previous one has been measured, and that rule is what stops a portfolio turning into forty half-finished flows. Measures come from the business process, not the platform: cycle time from request to completion, manual touches per case, rework or error counts, and backlog at period end. We do not promise a figure in advance; the baseline and the measured result are yours.

• Wave 0, foundations: environments, DLP policies, service accounts, solution-based deployment and a standard for error handling and alerting, before the first process is built.
• Wave 1: two or three processes that pass both gates and connect through classes 1 to 3, each with a baseline measured before the build.
• Measurement point: the result against the baseline, reported by the process owner, plus reliability in production over an agreed period.
• Wave 2: the next ranked processes, reusing the connectors, adapters and patterns wave 1 produced, which is where delivery starts to speed up.
• Later waves: processes whose gates needed work first, such as data cleansing or a new ERP export, and screen-only integrations once the engineering discipline for desktop flows is in place.
• Every wave ends with a short review of the ranked list, because the scores change as integrations become available and priorities move.

What governance and DLP must be in place before automation scales?

Governance is what lets a programme run more than one stream of work without every flow becoming a support problem. It belongs in wave 0, not after the first incident. How to stand up a full Center of Excellence, including the environment strategy, DLP, ALM and the team options behind it, is set out in our guide to building a Power Apps Center of Excellence with a nearshore team, so only the minimum a roadmap depends on is listed here.

• Separate development, test and production environments, with production flows deployed as managed solutions rather than edited in place.
• DLP policies that classify connectors as business, non-business or blocked, so automation cannot move data somewhere it should not.
• Service accounts or service principals and connection references, so no production flow depends on one employee account.
• A standard for error handling, logging and failure alerts on every production flow; the build steps are in our guide to monitoring Power Automate flows and alerting on failures.
• One intake route for new automation requests, scored with the same rubric, so priority is decided by the portfolio rather than by whoever asks loudest.
• A clear line between what trained makers in the business build and what the delivery team builds, which is what stops every department queuing behind one developer.

How is an automation programme staffed when there are no internal developers?

A programme without internal developers still needs internal ownership; what it can source externally is delivery capacity and architecture. Solzet provides senior consultants and full-stack developers with 8+ years of Power Platform and Dynamics 365 delivery, working remotely from Yerevan, and scales the team per wave. Our Power Automate consulting describes the flows, business process automation and resilience engineering we deliver.

Which processes should not go on Power Automate at all?

A good triage also says no. Some processes should be fixed, retired or moved into an application before anyone automates them.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. Where the triage shows a group of processes is really a missing system, for example case handling, account management or service delivery spread across spreadsheets and email, a Dynamics 365 application or a custom CRM may serve it better than a chain of flows.

• Processes nobody can describe consistently: automating an unclear process makes the confusion run faster, so agree the process first.
• Processes due to disappear, such as those tied to an ERP replacement already under way.
• Very low volume processes with low error cost, where the automation would cost more to maintain than it saves.
• Processes that are really an application: many users working cases over days, with screens, security and reporting, which belong in a model-driven app, Dynamics 365 or a custom CRM with automation inside it.
• Processes whose only route into the legacy system is its screens while an API, database or file route is being built; wait for the better class.

What can a leadership team have in ninety days?

Ninety days is enough for a credible roadmap and a first wave, provided the first wave is chosen by the rubric rather than by pain alone. The shape below is typical rather than guaranteed: how far the first wave gets depends on licensing, access, the owners and the integration classes involved, and we agree the scope before committing to it.