I build the transformation as a system the business can own.
You have probably already been sold the fix. What broke wasn't the software; it was ownership, governance, and decision logic. That's the part I take.
I start inside the operating business, bind the people, workflows, systems, vendors, and decisions into one delivery frame, then keep cycling until the result holds without me.
Vendors are trades. Someone still has to own the build.
Before business systems, I spent roughly fifteen years as a general contractor on complex construction projects. That trained the habit I still run on: vendors are trades. Someone still has to own the build.
Thirty years in business-system transformation, 50+ implementations, and 15 full transformations at scale trained the same reflex from the systems side: read the room, find the real decision path, hold the line above the subcontractors, and leave the owner with something they can operate.
I design above the vendors.
The vendor stack matters, but it cannot be the transformation's owner. I make the business architecture explicit: systems in their places, data governed as a core asset, workflows mapped to the operating reality, and decisions visible enough for executives and operators to act on the same truth.
Most independents stay independent by staying outside. They advise and leave at go-live. I'm the inversion: I embed, I own the build above the vendors, and I leave you an asset you own. Independent through commitment, not detachment.
My first two calls are to the CFO and the Compliance Officer.
Not the innovation team, the people who carry the consequences. A vendor can demo capability; they can't tell you whether it survives an audit, a regulator, or discovery. That answer comes from having sat with those roles through a real transformation: the financial close, the revenue definitions, the controls underneath. Get those two in the room first and the work stops being a science project and becomes something the business can actually run. This is sharpest in finance, where a wrong number isn't a bug; it's a finding.
I run this model before I bring it to you.
I build it in a governed environment, the business owns the asset at the end, and I run my own practice on it: built, owned, run.
The strongest shape keeps what works: keep your ERP, and we build the agentic workflow stack alongside it.
See the systems I run onTransformations fail when delivery splits into disconnected languages: executives talk mandate, vendors talk scope, project teams talk tasks, and operators keep the real work moving in the gaps. I collapse those languages into one observable loop. Build against reality. Observe what the work reveals. Adjust until the business owns the system, not just the go-live.
The people who run the work are the system's center.
I map the beehive first: where work actually moves, who carries exceptions, who knows the undocumented paths, and which operators can lead the change from inside the business.
This is delivery mechanics. If the people who run the work cannot see, test, challenge, and eventually own the new system, the transformation is theater with a go-live date.
Every operating business runs on the same six.
Your culture is unique. Your operating mechanics are not. Procure to pay, order to cash, plan to make, systems to support, data to report, and master data management show up in every install.
The makeup differs by company. That is the diagnostic work: where the constellations sit, how they weight, which systems and people carry them, and where delivery is breaking.
Delivery is where the asset gets proven.
The work runs in an agile-fall cadence: fast cycles where operators need iteration, clean phase discipline where the board, CFO, and audit trail need control. The owned asset gives the work a visible delivery frame: deliver the workflow, validate it through real use, then mark it done/done only when both axes are green.
The test is what remains after I leave.
The drag eases where you feel it most. The close runs faster. Exceptions stop piling up. Vendor meetings stop being standoffs. The board updates stop sounding defensive. Quietly, the business starts running better than it did before I arrived.
Measured by
Cleaner decisions, fewer exceptions, faster close cycles, less vendor drag, and operators who can explain how the system works because they helped validate it.
Leaves behind
A living operating asset the business owns: mapped workflows, governed data, visible delivery state, self-maintaining SOPs, and a team capable of carrying the next cycle.
Operator to operator
Bring the messy version.
The current systems, the stalled decision, the vendor knot, the executive mandate, the agentic ambition. I do not need a polished problem. I need the real one.
Start a conversationFor how the model plugs in, see Engagement →