Insights for the
Modern Enterprise.

Most companies have never comprehensively mapped their business processes. Processes exist in people's heads, in fragmented documentation, and in system configurations that no one fully understands. Process mapping is the act of documenting current state processes in detail: what steps are in the process, who does each step, what systems are involved, how long does each step take, what are decision points and exceptions. Process mapping is often viewed as a tedious, low-value exercise. In reality, it's one of the highest-ROI investments you can make. Why? Because you cannot optimize what you do not understand.

Process mapping creates visibility into how work actually happens. It surfaces inefficiencies and waste that are invisible otherwise. It identifies where processes are broken or non-compliant. It reveals opportunities for technology enablement and automation. A company with 500 employees operating with 50 core processes might spend A$50-80K to comprehensively map those processes. That investment typically surfaces A$500K-1M in cost reduction and efficiency opportunities. That is a 6x-20x ROI on the mapping investment alone.

Yet many companies skip process mapping because it seems low-priority. They view it as administrative overhead that delays 'real' work. They believe they already understand their processes because they've been executing them for years. This is a critical mistake. Undocumented processes are fragile, difficult to scale, and impossible to improve systematically. When a key person leaves, process knowledge walks out the door. When you hire new staff, they have to learn processes informally, creating inconsistency and rework.

Process mapping enables several critical outcomes. First, it creates visibility. Executives and managers gain clear understanding of how work flows across their organization. This visibility surfaces bottlenecks and handoff problems that were invisible before. Second, process mapping enables optimization. You cannot improve what you do not measure. Process mapping establishes baseline metrics: how long does this process take? What is the cost? What is the error rate? With baselines, you can measure improvement. Third, process mapping enables compliance. If your processes are undocumented, you cannot demonstrate that they comply with regulations. Documented processes, aligned to regulatory requirements, reduce compliance risk.

Process mapping ensures that technology implementation aligns with redesigned, optimized processes. Good process mapping has several characteristics. It is comprehensive: it covers all major flows and decision paths, not just the happy path. It is detailed: it documents who does each step, what systems are involved, what information flows between steps. It is accurate: it reflects how work is actually done, not how it should be done in theory. It includes metrics: cycle time, cost, volume, error rates. It identifies exceptions and workarounds: process owners typically implement informal workarounds to handle exceptions; good process maps document these so they can be addressed systematically.

The article concludes with a framework for identifying which processes should be mapped first. Not all processes are equally important. Prioritize processes that have the highest cost impact, the highest customer impact, or the highest regulatory impact. Process map your top 30-50 processes, then use those maps to identify improvement opportunities. This systematic approach turns process mapping from a tedious administrative exercise into the foundation of continuous improvement and business transformation.

For the last 20 years, the build-versus-buy decision has been simple: SaaS is cheaper and faster than building custom software. Cloud platforms are commoditized, skilled engineers are available, and SaaS licensing is affordable. You buy SaaS. This calculus has shifted due to AI-accelerated development. GitHub Copilot and similar tools have reduced software development time and cost dramatically.

This changes the build-versus-buy analysis fundamentally. For many problems, building a custom solution is now cheaper and faster than buying and customizing generic SaaS. This article walks through how to evaluate build-versus-buy decisions in 2026. First, understand the true cost of SaaS: license costs plus implementation, training, support, and customization. A SaaS platform that costs A$100K annually in licenses might cost A$200K annually when you account for all the other costs. Second, understand the true cost of building: engineer time, infrastructure costs, maintenance and support, technical debt management. Third, compare total cost of ownership over a 3-5 year period. Often you'll find that building custom is actually cheaper.

The article provides frameworks for deciding when custom build makes sense. Build custom when: you have unique requirements that don't fit SaaS, when you can build faster than you can implement and customize SaaS, when integration complexity is high and SaaS requires expensive custom integration, when you want control over data and don't want to rely on a third-party vendor. Buy SaaS when: the functionality is generic and SaaS has solved the problem well, when you need to move fast and SaaS implementation is faster, when you don't have engineering resources to build and maintain custom software, when the SaaS vendor has solved the problem at scale and the solution is mature.

The article also discusses the risks of custom building: maintenance burden (custom software requires ongoing maintenance), technical debt (shortcuts taken during development cause problems later), skill continuity (if key engineers leave, you're vulnerable). The conclusion: there is no universal answer in 2026. Some problems should be solved with SaaS. Others should be solved with custom building. The difference now is that more problems are worth solving with custom build than was true five years ago. The key is being intentional about the decision rather than defaulting to SaaS because 'that's how we've always done it.'

Before you implement AI, you need clarity on whether your organization is ready for AI. AI readiness is not just about having data and infrastructure. It's about having clear processes that you're trying to improve, well-defined success metrics, and organizational alignment on what problems AI should solve.

This article outlines the components of AI readiness. People readiness: do you have people who understand AI and can guide implementation? Process readiness: do you have clear processes that you're trying to improve with AI? Data readiness: do you have data quality and governance sufficient for AI? Technology readiness: do you have infrastructure to support AI? Governance readiness: do you have processes and policies for governing AI use responsibly?

The article argues that process readiness is often the binding constraint. Most organizations have some data. They have some technology capability. But they lack clarity on what processes should be improved and how AI should fit into those processes. This is where business process reengineering becomes critical. By clarifying your processes, understanding current pain points and inefficiencies, and identifying where AI can add value, you create the foundation for successful AI implementation.

The article walks through a real case study: a healthcare organization that wanted to implement AI for patient scheduling. They believed AI could optimize their scheduling and reduce staff idle time. However, when they conducted process discovery, they discovered that their scheduling process was broken at a more fundamental level. Scheduling staff was done manually based on availability sheets that were out of date. Managers had to make phone calls to determine who was actually available.

Fixing the visibility problem manually was the priority; AI scheduling could come later. They fixed the visibility problem first through a simple technology implementation. Once visibility was clear, AI scheduling became feasible and valuable.

The article concludes with a practical assessment framework for AI readiness. Ask yourself: Do we have clear processes? Do we understand our pain points? Do we have data that could inform decisions? Do we have leadership alignment on what AI should solve? Do we have the governance in place to use AI responsibly? Answer these questions honestly before you fund AI initiatives. This discipline prevents wasted investment and dramatically improves success rates.

The Australian Privacy Act underwent significant changes in 2024-2025. These changes raise the bar for customer data protection and increase penalties to A$50M. Mid-market companies are particularly exposed because they typically lack dedicated privacy resources.

The key changes include: new requirements for explicit customer consent (consent must be specific, informed, and documented), mandatory breach notification (you must notify customers if their data is breached), enhanced security requirements (you must implement and maintain security controls proportionate to the sensitivity of the data), broader definition of personal information (more types of data are now protected), and new rights for data subjects (individuals can request access to their data, request correction, and request deletion).

The article walks through what these changes mean operationally. You need updated consent mechanisms that clearly explain what data you're collecting and why. You need documented data retention policies that specify how long you keep data and when it's deleted. You need incident response procedures that you can activate immediately if a breach occurs. You need security controls that meet Privacy Act standards. You need data protection impact assessments for high-risk processing. You need vendor agreements that require your vendors to protect data according to Privacy Act standards. You need staff training so everyone in your organization understands privacy obligations.

The article provides a checklist of 20 items that mid-market companies should audit: Does your consent process comply with new requirements? Do you have data retention policies? Do you have a data protection impact assessment? Do you have an incident response plan? Do your vendors have sufficient data protection agreements? Are you using encryption for sensitive data? Do you have access controls limiting who can access customer data? Have you conducted privacy training with your staff? Do you have a documented privacy policy? Are you handling data deletion requests promptly? The list goes on and covers the practical, operational aspects of Privacy Act compliance.

The article concludes with a timeline recommendation: mid-market companies should conduct a privacy audit in Q1 2025, identify gaps in Q1-Q2 2025, and remediate gaps by end of Q2 2025 before enforcement intensifies. The OAIC has indicated they will significantly increase enforcement starting in Q3 2025, so the window for remediation is now.

Digital transformation projects fail at high rates. Gartner estimates that 60% of digital transformation initiatives fail to achieve their expected benefits. This article analyzes why. The common pattern: companies invest in technology (new platform, cloud migration, digital tools) without first understanding whether their processes are designed to leverage that technology. The technology fails not because it's bad technology but because it's being implemented on broken processes.

This article walks through a real case study: a company spent A$2M on an ERP implementation that was supposed to reduce operating costs by 20%. Three years later, they'd realized 5% of the expected benefit. Why? Because their actual business processes didn't align with the ERP's standard processes. The ERP was designed for a lean, streamlined operational model. The company's actual processes had evolved over 20 years and included workarounds, exceptions, and redundant controls. To get the benefits of the ERP, they would have needed to fundamentally redesign their business processes to match the ERP's standard processes.

The ERP implementation became expensive (2 million became 4 million due to customization), slow (took 18 months instead of 9), and delivered minimal value.

The article contrasts this with a different company that conducted business process reengineering first. They spent 8 weeks understanding their processes, identifying inefficiencies, and designing a future state for how they wanted to operate. They identified their top 20 process improvement opportunities. They understood that to realize 20% cost reduction, they needed to eliminate 30 full-time equivalent staff positions through process automation and consolidation. Only after this clarity did they select an ERP platform. They chose a platform that supported their redesigned processes, with minimal customization. The ERP implementation was faster (9 months instead of 18), cheaper (A$800K instead of A$4M), and delivered 18% cost reduction as expected.

The key difference: one company understood its processes and redesigned them before implementing technology. The other tried to implement technology without understanding processes. This article is specifically positioned for prospects who've had failed digital transformation projects and are cynical about their next initiative. It validates their experience (yes, digital transformation often fails). It explains why (technology-first approach is flawed). And it positions DSV's methodology (business first, then technology) as the antidote. If your prior digital transformation failed, it's not because digital transformation is impossible. It's because you tackled it in the wrong order. Start with business process clarity. Then select technology that supports your redesigned processes. This approach has dramatically higher success rates and delivers measurable outcomes.