Diagnostic, then pilot, then scale.

Diagnose the process, not the department.

I sit with the people who actually do the work, trace every handoff and every spreadsheet that quietly holds the process together, and write down where time, money, and risk are really going. This is the same diagnostic instinct I used as a controller: the process on paper and the process in practice are rarely the same thing, and the gap between them is usually where the money is.

Pilot on a contained scope.

I'd rather prove an approach on one vendor category, one reconciliation, or one approval chain than propose a company-wide rollout before anyone's seen it work. A pilot also tells us quickly if a step should stay manual, which happens more often than most automation pitches admit.

Scale what actually held up.

Once a pilot proves out, in results and in whether it survives an audit trail check, I extend it to the rest of the process or the wider team. I keep the same control points intact at scale that I checked at pilot stage. Nothing gets automated wider than it's been tested.

The controls checklist I run before recommending automation.

Before I recommend automating any step in a finance or procurement process, I check:

• Who currently approves this, and does that segregation of duties survive the automation
• What audit trail the new process leaves, and whether it's actually reviewable later
• What happens to this control the one month something goes wrong and needs a human to catch it
• Whether the data involved needs restricted access, and whether the tool respects that

What I won't automate, and why.

Some steps exist because a human needs to exercise judgment on an exception, a large or unusual transaction, a new vendor, a number that doesn't look right. I flag those steps and leave them alone. A process that's faster but blind to the exception that actually matters isn't an improvement, it's a new kind of risk.