03 · Practice
Systems, automation & applied AI.
Workflow automation, systems integration and AI consulting for Australia's mid-market.
The technology layer of operating change. Connecting systems, automating manual work, and building the reporting infrastructure that turns operating control from a goal into a daily reality.
Most mid-market businesses do not have a technology problem because their systems are bad. They have a technology problem because their systems landscape has fragmented over time. Multiple tools, each doing one thing reasonably well, none of them talking to each other. Data has to be exported, reconciled and re-keyed. The ERP is doing things it was not designed to do. Reporting depends on one person’s spreadsheet. Workarounds have become load-bearing.
The Systems & Automation practice rebuilds the technology layer that sits underneath the operating model and the workflows. System integration. Data architecture. Reporting and dashboard infrastructure. Workflow automation. And, where the work genuinely warrants it, custom software built specifically for how the business runs. The patterns that determine whether technology supports execution or quietly works against it.
01
The Situation
Why leadership teams engage us for this work.
The engagements that arrive at this practice usually come from a CEO, COO or CFO who has identified that technology is no longer supporting the business but is not sure what to do about it. They are not technology buyers. They are operating buyers facing a technology problem. The patterns are familiar.
01
The systems landscape has fragmented.
There are six, eight, ten different tools in use across the business. Each one does one thing reasonably well. None of them talk to each other. Data has to be exported from one, reconciled, and re-keyed into another. The integration problem is now bigger than the original problem any single tool was bought to solve.
02
The ERP is doing things it was not designed to do.
The system that was meant to be the operational backbone is straining. Workarounds have proliferated. Custom fields, side processes and exception handling have built up over years. The system technically works but increasingly nobody trusts it without manual checks.
03
Reporting is built on people, not systems.
The numbers leadership trusts come from one person's spreadsheet, not from any system. When that person is on leave, reporting breaks. Decisions wait. The reporting infrastructure has never been formally built. It has emerged, organically, from whoever was patient enough to assemble it manually each month.
04
Off-the-shelf tools do not fit the work.
The business has tried multiple SaaS products. Each one solves 70% of the problem and creates new ones with the missing 30%. Adoption is patchy because the tool does not match how the team actually works. The question of whether to build something custom has started to come up, but the leadership team does not know how to think about it.
Some businesses arrive at this practice with one of these patterns. Most arrive with three or four, and the patterns are usually compounding on each other. The work is rebuilding the technology layer so it supports the business rather than gating it.
02
The Work
Rebuilding the technology that carries the work.
Systems & Automation is the technology layer of operating change. It sits below Operating Model & Governance and Process & Workflow Redesign, because technology should be designed to serve how the business needs to operate, not the other way around. The work spans five connected questions.
01
What systems should this business actually run on?
Not what the market is selling. Not what the previous IT decision committed to. What does this specific business, at this specific scale, in this specific sector, actually need to run on. We map the current systems landscape, identify what is genuinely working, what is not, and what needs to be replaced, integrated or simplified.
02
Where should the systems connect?
Most mid-market technology pain comes from systems that should be connected and are not. We identify the integrations that genuinely matter, design them, and build them. Not every system needs to talk to every other system. The integrations that move the business are usually a small number of specific data flows.
03
What manual work should be automated?
Automation is most valuable where the manual work is repetitive, error-prone, and consuming senior time. We identify those automation opportunities, build them, and embed them. We are deliberately conservative here. Automating a broken process is faster than the original broken process, but it is still broken. Workflow redesign comes first, automation second.
04
How does the business get reporting it can trust?
We build the reporting and dashboard infrastructure that gives leadership real-time visibility into operations, finances, and delivery. Built on systems data, not on spreadsheets. Owned by the systems, not by a person. Designed around what leadership actually needs to decide, not what is easy to extract.
05
When does custom software make sense, and when does it not?
Most businesses should use off-the-shelf tools wherever they fit. We are honest about that. But there are situations where the work is specific enough, the volume is high enough, and the off-the-shelf options genuinely do not work. In those cases, we design and build custom workflow software, as part of the engagement. We do not sell software development as a standalone service. Only as part of an operating engagement we have already diagnosed and designed.
The output is not a technology strategy deck. It is a working systems environment the business actually runs on, with reporting leadership trusts and automation that holds.
03
The Methodology
Where this practice sits in the Infinikey Operating Method.
Systems & Automation engagements run through all four phases of the methodology. The centre of gravity is in Implement, because systems work is the most technical and time-consuming layer of operating change to build.
PHASE 01
Diagnose
Substantial
We map the current systems landscape, the data flows, the integration gaps, and the reporting infrastructure. The Control Index is scored with weight on the visibility dimension. The Priority Register names which systems issues to fix first, which to fix next, and which to leave alone for now.
PHASE 02
Redesign
Targeted
Redesign for systems work is sharper and more contained than for the other practices. The Operating Model Blueprint at this layer becomes a systems architecture: which systems do what, where they connect, and what the data flow looks like. We design with operators and leadership in the room, not with the systems vendors.
PHASE 03
Implement
Centre of gravity
This is where most of the work sits. System builds, integrations, data migrations, reporting deployments, and any custom software development happen here. The Implementation Backlog is the working artefact. We build, deploy and stay through the first wave of the new systems environment going live. The methodology is judged by what holds in the field once real work starts running through the new systems.
PHASE 04
Hold
Critical
Systems work is uniquely prone to a particular failure mode: the system stays in place, but people quietly stop using it the way it was designed. Shadow workflows emerge. Spreadsheets reappear. We run Operating Cadence Reviews to surface where the new systems environment is genuinely supporting operations versus where it is being worked around. Without Hold, systems engagements look successful for the first quarter and quietly fragment.
Systems engagements without a Hold phase are how most mid-market businesses end up with the fragmented landscape they started with, just with newer tools. We have structured our practice around this conviction.
04
The Artefacts
Eight working artefacts your team uses on day one.
The deliverables of a Systems & Automation engagement are not slides. They are working artefacts that become part of how the business runs. Drawn from the named outputs of the Infinikey Operating Method, weighted toward the artefacts most central to technology work.
- The Operating Map
A single-page representation of how decisions, work and information actually move through the business. The starting point for understanding where technology should support the work.
- The Control Index
A scored assessment across four dimensions of operating control. For this practice, the visibility dimension carries the most weight, alongside execution.
- The Priority Register
A prioritised view of which systems issues to fix first, which to fix next, and which to leave alone. Includes explicit recommendations on what not to do, which is often as valuable as what to do.
- The Operating Model Blueprint
At the technology layer, this becomes a systems architecture: which systems do what, where they connect, what the data flow looks like, and where the boundaries between off-the-shelf and custom-built sit.
- The Implementation Backlog
A sequenced, owned, dated list of systems changes being made: integrations, automations, reporting builds, custom software development if applicable. Used by your team and ours.
- The KPI Architecture
The reporting and dashboard layer. Built on systems data rather than spreadsheets. Designed around what leadership needs to decide, not what is easy to extract.
- The Adoption Plan
Role-by-role view of who needs to change what they do as the new systems go live, supported by training, comms and on-the-ground support during transition. Systems work fails at adoption far more often than at build.
- The Operating Cadence Review
The structured Hold-phase review held monthly for the first quarter, quarterly thereafter, where we sit with leadership and look at whether the new systems environment is genuinely supporting operations or being worked around.
Each artefact is owned by a named person in your business by the time the engagement closes. None of them sits in a folder.
05
The Shape
What a Systems & Automation engagement looks like.
The engagements that arrive at this practice rarely start with a clean problem statement. They start with a CEO or owner-operator who feels something is structurally wrong and cannot quite articulate it. By the time we are in the room, the symptoms are usually familiar.
Entry point: the Diagnostic.
Every Systems & Automation engagement begins with a Diagnostic. Two to four weeks. Structured discovery, systems audit, data flow mapping, reporting infrastructure review. At the end of the Diagnostic, you have a clear view of where the systems landscape is breaking down and what we would do about it. If you decide to continue into a full engagement, the Diagnostic work feeds directly in.
Active engagement: four to ninemonths.
Systems work has the widest range of any of our practices because the scope varies enormously. A focused integration project might run four months. A full ERP-adjacent rebuild with custom software development might run nine. The Diagnostic gives an honest estimate before either of us commits.
Hold phase: six to twelve months, lighter touch.
Monthly Operating Cadence Reviews for the first quarter after the active engagement closes. Quarterly check-ins thereafter. Structured re-scoring against the original Control Index baseline. The Hold phase is what prevents the new systems environment from quietly fragmenting back into the old one.
Engagement model: senior-led with technical depth.
Malik leads the engagement. The Infinikey team includes senior consultants with deep systems and integration experience, plus custom software development capability when the work calls for it. The team that scopes the engagement is the team that delivers it. We do not subcontract systems work.
The shape is consistent across sectors. The systems environment changes. A construction business is rebuilding its project controls and ERP integration. A field service business is rebuilding its dispatch and field-data infrastructure. A care provider is rebuilding its claim, clinical and reporting systems. The pattern is the same. The work is sector-specific.
06
Selected Engagements
What this practice looks like in the field.
A selection of recent Systems & Automation engagements across our three priority sectors. Client identities anonymised at request. Outcomes will be quantified as case studies are released.
Construction & Project Services
Project controls integration
A commercial fit-out firm in NSW. Estimating, project management and finance were running on three disconnected systems with manual reconciliation each month. Margin visibility was always a fortnight behind reality. We rebuilt the project controls layer, integrated the three core systems, and built a project margin dashboard sourced from live data. Leadership gained real-time margin visibility for the first time.
Trade & Field Services
Field-to-office data flow
A commercial HVAC business with mobile technicians across the metro area. Job data was being captured on paper and re-keyed at the office, with significant lag and error rates. Off-the-shelf field service tools had been tried and rejected because none fit the specific way the team worked. We designed and built a custom mobile job-completion workflow integrated with the back-office systems. Same-day invoicing became the default.
Aged Care & Allied Health
Reporting infrastructure rebuild
A multi-site allied health provider in Victoria. Monthly reporting was being assembled by one person from data extracts across four systems, taking five days each month and frequently delaying leadership decisions. We built a reporting and dashboard layer sourced directly from the operational systems, with consistent metrics across sites. Leadership reporting became real-time and the manual assembly work disappeared.
All engagements anonymised at client request. Detailed metrics released alongside named case studies as clients approve disclosure.
07
The Fit
When this practice is the right answer, and when it is not.
Systems & Automation is the right practice when:
- The systems landscape has fragmented and integration friction is now a real cost.
- Reporting depends on people and spreadsheets rather than on systems.
- The ERP or core operational system is straining under workarounds.
- Off-the-shelf tools have been tried and have not fit the work.
- The leadership team is sponsoring a major systems decision and wants operating-led rather than vendor-led advice.
- The business needs custom workflow software but does not have the in-house technology depth to build it well.
Systems & Automation is not the right practice when:
- The primary issue is structural rather than technological. (Operating Model & Governance is the right practice.)
- The primary issue is workflow design rather than systems infrastructure. (Process & Workflow Redesign is the right practice.)
- The need is for software development on a design produced by another firm. We only build software as part of an operating engagement we have already diagnosed and designed.
- The business is below the scale where formal systems work makes economic sense. We typically work with businesses of 25 to 250 staff.
If you are not sure which practice fits your situation, the Diagnostic is built to answer that question.
08 · How to Start
Start with a Diagnostic.
Every Systems & Automation engagement begins with a Diagnostic. Two to four weeks. Senior-led. Built to give you a clear view of where the technology layer is breaking down and what to fix first, before either of us commits to a larger engagement.