Defence kicks off mammoth ERP transformation program


blog Those of you who got too deep, too early into the silly season around Christmas time may have missed the fact that the Department of Defence has taken a strong step forward in the mammoth ERP consolidation program known as “Defence Insight”. The project is a long-running initiative designed to significantly consolidate the several thousand business applications which the huge Department of Defence runs as part of its normal run of business.

In early December, the Department announced its intention to hold a vendor briefing to detail its initial thinking on the issue. The tender document associated with the briefing states:

“Defence intends to seek First Pass Approval for the enterprise resource planning (ERP) business transformation program – Defence Insight – from Government in March 2016.”

“Consistent with the First Principles Review, Defence’s intention is to proactively engage with industry. This approach has been designed to promote collaboration and the sharing of ideas and market intelligence throughout the industry engagement and procurement process. The Market Briefing is the first of these engagement activities.”

“It is intended to provide industry with an overview of Defence’s current thinking, particularly in terms of scope and complexity, the delivery models presently under consideration and Defence’s views on how to most efficiently and effectively deliver Defence Insight. It is also intended to encourage discussion and collaboration both within industry and between industry and Defence.”

Intermedium has a great deal more information on the Defence plan, including the fact that it appears as though SAP is currently the frontrunner to be the platform for much of the work. I can’t say I’m surprised (at all) by that decision, although it may end up causing issues at Defence down the track, as a number of major public sector ERP implementations using SAP (notably the Queensland Health payroll revamp) have come unstuck recently.

I’m not alleging any issues with SAP’s software per se — organisations such as the Commonwealth Bank have successfully completed highly complex SAP installations — but rather that much appears to depend on the governance structures of system integration projects involving SAP. In any case, the following information from Intermedium may give readers some sense of the scale of the work to come (we recommend that you click here for the full article):

“The agency signed a $6.36 million contract with Deloitte to design Defence’s Enterprise Resource Planning Roadmap Program on 14 April 2015. Defence CIO Peter Lawrence told the Technology in Government Summit in August 2015 that Defence makes use of roughly 2500 applications, including 300 financial applications.”

Lawrence is pictured in the image above.

To my mind, this program will one of the key major IT projects to watch in the Australian public sector over the next five years. The sheer complexity of the work involved means that there will doubtless be quite a few mini-projects as part of the greater whole that will go off the rails. In addition, the scale of the contracts involved will doubtless be quite large.

Image credit: Department of Defence


  1. If nothing else at least defence has a good background/track record in large and expensive engineering projects. They just need to transfer that knowledge over to the IT side of things and it shouldn’t get too bumpy.

  2. SAP definitely doesn’t produce bad software. The *problem* with it is that it’s highly customisable …

    Stick with SAP’s guidelines for a particular product and things are generally fine. It’s when you start hearing “standard core functionality isn’t good enough/doesn’t fit our organisation” that the problems start. I mean there will always be a certain amount of customisation but organisations need to look at why their processes are the way they are instead of reinventing the wheel.

    • Yeah often changing a company process slightly will be a far better option than sending a mass of changes rippling throughout a software package over and over.

      Chances are the software’s been designed to provide a more optimal path in the first place too. Sometimes the customer isn’t right (we just try not to tell them that ;) ).

      • +1. My standing advice to orgs is that they should strive to find a solution that does 80%-90% of what they need out of the box, and then strongly consider modifying their existing processes and workflows to conform to the software for the remaining 10%-20% it at all possible. Workflows are usually developed iteratively with the user community, and often represent an optimal(ish) way of doing things. They’ll reduce integration (and operational) complexity, and save a bundle on bespoke configuration/feature addition. If there really is a business case to make changes to the software to align with existing processes (and “We’ve always done it this way!” isn’t a business case), then at least you’ve constrained the scope of the work to be done, and constrained your ongoing support burden.

  3. Pretty sure CBA uses PeopleSoft for core Financials and HR, not SAP. SAP powers the core banking platform.

Comments are closed.