Case studies
Four projects, in more detail than a resume bullet allows.
Every figure, decision, and outcome below is real and represents work delivered across diverse organisations and business environments.
01 · Enterprise transformation
ERP transformation — Warehouse & Distribution
Migrating Warehouse & Distribution from Microsoft Dynamics AX to Dynamics 365 Finance & Operations across AU/NZ, supporting 800+ users.
800+
users transitioned with minimal operational disruption
Problem
The business needed to move off a legacy ERP onto a modern platform. Warehouse & Distribution was the highest-risk workstream — any gap between the new system's capabilities and how warehouse teams actually worked would show up immediately as a disruption to daily operations, not a line item in a status report.
Approach
- –Owned end-to-end process design for the Warehouse & Distribution workstream, mapping current-state processes against the new system's capabilities.
- –Acted as the liaison between business stakeholders, the technology team, and the vendor to resolve gaps and design decisions.
- –Led user acceptance testing and Agile delivery (Azure DevOps) through to sign-off.
- –Ran the change management plan and business readiness activities ahead of go-live, then owned the transition to business-as-usual.
Result
- –Successful go-live across AU/NZ with minimal disruption to warehouse and distribution operations.
- –800+ users transitioned onto the new platform with processes designed around how the business actually worked.
- –The reporting and process foundations from this project fed directly into the analytics and BI work that followed.
What I took from it
Go-live and adoption are two different milestones, and it's easy to optimise for the first at the expense of the second. The change management and stakeholder alignment work mattered as much as the technical build — arguably more, because the best solution is only valuable if people actually adopt it.
02 · Transformation & systems
Multi-site transport management system implementation
Multi-site operation across Australia and New Zealand.
27%
Reduction in transport operating costs
Problem
Freight and transport costs were managed site by site, with no network-wide view of cost or carrier performance. Delivery method data was recorded 200+ different ways across the business, which meant cost and service issues were usually found after the fact — in a monthly report — rather than caught and acted on while they were still manageable.
Approach
- –Ran end-to-end transport tenders across the network to reset carrier agreements and pricing on a like-for-like basis.
- –Implemented a transport management system to give network-wide freight visibility instead of a site-by-site view.
- –Standardised 200+ delivery method codes down to 12, so cost and service data could actually be compared across sites.
- –Built ongoing carrier performance tracking (DIFOT, cost, service) as a management routine, not a one-off report.
Result
- –$5.8M (27%) reduction in transport operating costs across the 16-site network.
- –A single, consistent data model for delivery methods, replacing 200+ inconsistent codes.
- –Carrier performance and cost became visible and manageable in real time, not discovered a month later.
What I took from it
A tender resets pricing overnight; it doesn't rebuild trust in the numbers behind it. That took standardising 200+ delivery codes down to 12, so cost and service data actually meant the same thing across every site. The real work was the data discipline, not the software rollout — and that's the lesson I've carried into every system project since.
03 · Data, reporting & analytics
Power BI reporting and analytics transformation
With reporting split across supply chain, sales, pricing, and operations teams.
25–35%
reduction in reporting turnaround time
Problem
Reporting was built manually, team by team, in Excel — with no shared KPI definitions and no single source of truth. Every ad hoc request from leadership meant another spreadsheet built from scratch, and numbers from two teams rarely matched because they were never built the same way. As the business grew, that model stopped scaling and started costing real analyst time.
Approach
- –Partnered with stakeholders across supply chain, sales, pricing, and operations to agree consistent KPI definitions before building anything.
- –Designed and built Power BI dashboards and DAX-based data models to replace manual, spreadsheet-based reporting.
- –Developed national reporting packs and performance dashboards, giving leadership one consistent view of operational and commercial performance instead of several conflicting ones.
- –Built in data validation and quality-assurance steps so dashboard numbers could be trusted without a manual cross-check every time.
Result
- –Reporting turnaround time cut by roughly 25–35% across the areas covered.
- –Dashboards and insights adopted by 250+ stakeholders, replacing one-off spreadsheet requests with self-serve reporting.
- –Manual reporting effort reduced by an estimated 20–30%, freeing analyst time for analysis instead of report production.
What I took from it
Rarely was there pushed back on a dashboard's colour scheme. The push back was on whose number was right. Getting five teams to agree on one definition of a KPI before a single visual got built was the part that actually determined whether the numbers would be trusted. Skip that step and you've just built a faster way to produce reports nobody believes.
04 · Training & capability uplift
Training staff across multiple systems to build lasting confidence
Across a Dynamics 365 ERP transformation, a Power BI reporting rollout, and ongoing process changes across supply chain, sales, and operations.
250+
stakeholders trained and supported across ERP, Power BI, and reporting rollouts
Problem
Every system rollout — an ERP transformation, a new reporting suite, a change to how a process worked — created the same fork in the road: people either built real confidence and could solve problems themselves, or they quietly found workarounds and kept asking someone else to fix it. Across successive changes, the teams that skipped structured training kept generating the same support requests long after go-live. The gap was rarely the system. It was whether people trusted themselves to use it.
Approach
- –Designed and delivered training across multiple systems and rollouts — Dynamics 365 F&O, Power BI, and reporting and process changes — tailoring the format to how each team actually worked rather than running one generic session for everyone.
- –Built plain-language documentation and reference material so people could troubleshoot routine issues themselves instead of raising a request for every question.
- –Ran hands-on workshops and one-to-one coaching for individuals and teams who needed more support, treating training as a two-way conversation rather than a lecture.
- –Became the go-to person across teams for system questions — someone people felt comfortable approaching without feeling judged, which meant problems surfaced early instead of being hidden or worked around.
- –Mentored junior analysts and team members directly, building capability within the wider team so knowledge wasn't held by one person.
Result
- –250+ stakeholders trained and supported across ERP, Power BI, and reporting rollouts over multiple years.
- –Consistently the first point of contact for system questions across teams — people came back because they trusted the guidance, not just because they had to.
- –Users increasingly resolved routine issues themselves, reducing repeat requests and freeing up time for higher-value work on both sides.
- –A reputation as a trainer people found approachable and reliable, built on consistency across multiple systems and several years, not a single session.
What I took from it
Knowing a system inside out and being someone people actually trust enough to ask are two different skills, and the second one is rarer. The harder part is making people feel safe enough to ask a question, try something, and get it wrong without feeling discouraged — that's what actually decides whether someone comes back to a system on their own or quietly avoids it. If people trust you enough to ask, they'll trust the system enough to use it.
Next