Start with financial management
You cannot diagnose an operation you cannot measure. Reporting comes first when the numbers are late or unreliable.
Four areas of practice.
The work covers operational strategy, engineering design, AI-driven automation and multi-entity financial management. They are listed separately because they are distinct skills, but they are rarely sold separately — a real engagement usually touches three of the four.
What follows describes what each one involves in practice, and the conditions under which it is the right place to start.
01 — Operational strategy
Bottleneck analysis and operational design
Finding the one constraint that sets the ceiling on everything else, and changing it.
Operational strategy here means something narrower than the usual definition. It is not a planning exercise. It is the identification of the specific point in a business where work accumulates, and the redesign of that point.
What it involves:
- Mapping the actual flow of work — orders, projects, patients, installations — from entry to cash collection, including every handoff and every wait state
- Quantifying cycle time and cost at each stage rather than estimating it
- Isolating the binding constraint and separating it from the loud-but-harmless problems around it
- Designing the intervention: process change, staffing change, automation, or a control that removes rework
- Defining the measures that prove whether it worked
Start here when: revenue is growing but margin is not, headcount has been added without a proportional increase in output, or the same category of problem keeps recurring after being "fixed."
02 — Engineering design
Designing infrastructure and process to a specification
Applying engineering method where a business has been improvising.
Engineering design means stating the requirement before choosing the solution, modelling the constraints, and building to a specification that can be verified. Businesses frequently skip the first two steps, which is why they buy systems that do not fit and re-buy them two years later.
What it involves:
- Writing the actual requirement — throughput, tolerance, capacity, compliance obligation, cost target
- Modelling constraints before committing capital: physical, financial, regulatory and human
- Designing infrastructure and workflow against that specification rather than against a vendor's product
- Documenting the design so it survives staff turnover
- Verification — testing that the built thing meets the specification it was built to
Start here when: a capital decision is imminent, an existing build-out is underperforming its stated capacity, or the business is about to select software or infrastructure without a written requirement.
03 — AI-driven automation
Removing repetitive, rules-based work
Applied to the parts of an operation that are mechanical — and deliberately not to the parts that are not.
Automation is worth doing where work is high-volume, rules-based and currently consuming trained people. It is not worth doing where the task depends on judgment the system cannot access. Most disappointing automation projects fail on that distinction rather than on the technology.
What it involves:
- Identifying which tasks are genuinely rules-based, measured in hours consumed per week
- Fixing the underlying process first — automating a broken process produces errors at higher volume
- Document handling and data capture: invoices, timesheets, purchase orders, field reports
- Reconciliation and exception routing, so people see only what needs a decision
- Automated reporting that reaches the owner without someone assembling it manually
- Defining the failure mode: what the system does when it is not confident, and who it escalates to
Start here when: qualified staff spend significant time on data entry, reporting takes days to assemble, or the same information is keyed into more than one system.
04 — Financial management
Multi-entity financial management and real-time reporting
15+ years of managing finances across related operating entities, not a single set of books.
Multi-entity structures create problems a single-company chart of accounts never encounters: intercompany transactions, shared cost allocation, consolidated reporting that has to reconcile, and a control environment that must hold across all of it.
What it involves:
- Chart of accounts and entity structure designed for the reporting that will actually be needed
- Intercompany flows and cost allocation that survive review
- QuickBooks configuration and advanced automated reporting
- Real-time financial insight — closing the gap between an event occurring and the owner seeing it
- Internal controls proportionate to the size of the business, not to an audit template
- Cash visibility across entities rather than entity by entity
Start here when: month-end close lands too late to act on, entities are reported separately with no reconciled consolidated view, or nobody can answer a cash question without a manual exercise.
Sequence
Which one first
The order is not fixed, but it is not arbitrary either.
Start with operational strategy
When the constraint is already visible in the data, go straight to isolating and redesigning it.
Start with engineering design
Before money is spent on infrastructure or systems, the requirement needs to be written down and verified.
Automation
Automation amplifies whatever process it is applied to. It belongs after the process is right, not before.
Not sure which one applies?
That is a normal starting position. Describe what keeps going wrong and the sequence becomes obvious quickly.