I turn manual chaos into measurable flow.

Most automation efforts start with a simple question: "what's eating our time?" That's the wrong question. The right one is: "what step, if it disappeared entirely, would change the outcome?" These are rarely the same step.

I've seen teams spend months automating data entry into a system, only to find the real bottleneck was three approvals later — a manager who reviews requests once a week because nobody flagged it as urgent. The data entry got faster. The overall cycle time barely moved.

The pattern repeats because automating the visible, repetitive step feels productive and is easy to sell internally. It's a clean before-and-after story. Fixing an approval bottleneck means confronting an org design or ownership problem — a much harder conversation, and one that doesn't fit neatly into a project charter.

Before automating anything, I map the full cycle — every handoff, every wait state, every place where a task sits untouched. Not just the steps a person performs, but the steps a task waits for. Wait time is almost always larger than work time, and wait time is where automation has the least natural pull because nobody "owns" the waiting.

A simple test I use: if you automated this step perfectly — instantly, with zero errors — would the customer or the business notice a meaningfully faster outcome? If the answer is "a little," you've found a comfortable project, not an impactful one. If the answer is "yes, dramatically," you've found the actual bottleneck, even if it's harder to touch.

Automation works best when it removes waiting, not just typing.

Every organization has an audit trail. Almost nobody looks at it until an auditor asks a question nobody can answer, or a number doesn't reconcile and someone needs to know why.

The problem isn't that audit trails don't exist — it's that they're built as a compliance afterthought, bolted onto a process rather than designed into it. A log file that captures "user X changed field Y" tells you what happened, but not why it was allowed to happen, or whether it should have triggered a review.

A good audit trail answers three questions on its own, without someone having to reconstruct the story: what changed, who approved it, and what rule justified the approval. Most systems only reliably answer the first one.

When I've rebuilt audit trails for vendor and process audits, the biggest improvement wasn't more logging — it was tighter linkage. Every exception needed a visible owner and a closure date, not just a record that it existed. A 74-point finding backlog isn't a logging problem; it's an ownership and dependency-tracking problem wearing a logging costume.

If your audit trail only gets opened during an audit, it isn't doing its job day-to-day. It should be boring enough that a reviewer trusts it without reading every line — and specific enough that when something does break, the answer is already sitting there.

Lean Six Sigma still gets filed under "manufacturing methodology" in a lot of people's heads — belts, defect rates, assembly lines. That framing made sense twenty years ago. It doesn't hold up anymore.

The core of Six Sigma was never about factories. It was about reducing variation and removing waste in any repeatable process — and knowledge work is full of repeatable processes: invoice approvals, compliance reviews, client onboarding, monthly reporting cycles. These have defect rates too; they just show up as rework, missed SLAs, and reconciliation errors instead of scrapped parts.

Where Six Sigma earns its keep in a services or back-office context is in forcing a team to define what "defect" even means for a non-physical process. Is a defect a late report? A restated number? A client escalation? Most teams have never written that definition down, which means nobody can measure improvement against it.

Paired with automation and AI-enabled monitoring, the classic DMAIC cycle — Define, Measure, Analyze, Improve, Control — becomes more powerful, not less relevant. AI can help measure variation continuously instead of through periodic sampling, and automation can enforce the "Control" phase so a fixed process doesn't quietly drift back to its old habits within a few months.

The tool hasn't gone out of date. The mental picture of where it applies has just stayed stuck in 2005.