Search

4. Reuse assessment

4.1 Reusability by tier

The government’s Digital and ICT Reuse Policy is underpinned by three high-level requirements:

• Reuse whenever possible – your proposed investments must plan for and make use of any opportunities to reuse existing services or tools within your agency and across government
• Design and build for reuse – if your proposed investment cannot reuse an existing digital or ICT solution, you must ensure that the service you build, can be reused by other agencies
• Enable reuse by others – you must ensure anything you create is shared for others to reuse unless there’s a good reason not to.

For the purposes of this Assessment, the concept of reuse has been applied broadly to capture as many reuse opportunities as possible. This includes consideration of opportunities to utilise existing technologies that have been built, all the way through to consideration of opportunities to leverage existing processes or patterns. As such, GovERP’s technical reusability has been considered across three tiers

1. Tier 1 use of what has already been built
2. Tier 2 building on something that exists, and
3. Tier 3 items for a whole-of-government repository.

4.1.1 Tier 1 reuse opportunities

Considering the current state of ERP capabilities, as outlined in section 3.2, APS entities have expressed hesitation regarding Tier 1 reuse (see Reference 1).

4.1.2 Tier 2 reuse opportunities

The Panel considers there is greater potential for Tier 2 or Tier 3 reusability. Building on existing GovERP capabilities with a separate ERP instance may be desirable for larger entities grappling with complex ERP requirements and integrations, particularly where those agencies have substantial in-house functional and technical skills in their digital and ICT workforces (such as Services Australia). In such a case, GovERP could serve as a potential accelerator.

• The GovERP build to date had 167 customisations to workflows, reports, interfaces, conversions, enhancements, or forms (WRICEFs). Given the size of the GovERP program, development beyond standard configuration and customisation to meet the needs of government is to be expected.
• That said, the Panel considers that larger, highly skilled entities with complex ERP requirements are best placed to make use of, and maintain, the existing GovERP capabilities and their related customisations.

Most notable from the Assessment’s engagements with the Consultative Committee, is the Department of Health and Aged Care stakeholders’ interest in leveraging GovERP’s reusable architectural patterns/architectural documents and architectural decisions. The Department of Health and Aged Care’s currently proposed approach to its own ERP upgrade is to reuse GovERP’s capabilities wherever they are assessed as being fit for purpose. 

The cost of reusing GovERP capabilities to support ERP delivery in smaller entities with less complex requirements may be a challenge, particularly given the need for strong in-house functional and technical skills to support delivery and operations. Ensuring that any commercial arrangements already in place are leveraged to their full effect (where applicable) may help offset ERP delivery and operating costs.

An entity intending to reuse any aspect of the GovERP product as an accelerator must assess the effort and financial investment required to develop capabilities based on the current build and test status. The Panel heard that any potential opportunity to save effort in implementing a process would have to be balanced against the effort to modify an existing entity’s business process to fit the GovERP implementation (or added effort to modify) (see Reference 1).

The following decision-making principles may provide a useful basis for entities considering Tier 2 reuse opportunities: 

1. first preference is to consider other SaaS or out-of-the-box solutions (SAP or alternatives) 
2. if not appropriate, then build on existing GovERP capabilities, and leverage any commercial arrangements already in place, or 
3. if SaaS or out-of-the-box solutions or building on existing GovERP capabilities are not appropriate, customised configuration will only be considered where assessed as necessary.

The Panel notes any on-premises specific solutions will likely have limited reusability.

4.2 Potential ongoing reuse costs to entities

As the current state of GovERP diverges significantly from its initial whole-of-government vision, entities will likely need to invest additional resources to customise and configure the templates to some degree to ensure they are fit for purpose (while adhering to the data standards currently built into the GovERP solution).

In this context, even if capitalising on the reuse opportunities identified in Chapter 4, the resources required to cater to the diverse complexities and requirements of different entities across the APS appears to be prohibitive for many entities, particularly if each entity was to pursue its own uplift. The Panel notes that while there are many opportunities to re-use components, licences, environments, and documentation from GovERP, only large and complex entities with sufficient capability could implement one or more instances of GovERP as proposed, and have it represented as reasonable value for money.

In an individual entity-based ERP scenario, the ongoing maintenance costs are also likely to have a substantial impost posing an increasing challenge in an environment with scarce financial resources and available skills. For example, any bespoke customisations or WRICEFs would need to be maintained in a re-use scenario, with an associated resourcing impact. Of the 167 WRICEFs potentially applicable to whole-of-government needs, 58 (35 per cent) are considered medium-high effort to maintain.

The Panel also considers there needs to more challenge against entity-specific customisations seeing to address “complex” requirements. Instead, the Panel considers that a greater focus on adoption of SaaS / “out of the box” capabilities, and avoiding designing in legacy process, could help to reduced costs.

With no single value stream completely built or viable for adoption as-is, clarity is required regarding what work arounds would be needed for any reuse opportunities.