Search

2.4.2 Build status

This phase examines the current state of the GovERP system’s construction. Technical capabilities are evaluated based on a standard system development lifecycle, with an assessment of each capability’s progress.

Within GovERP, three templates exist:

1. MVP1.0: The ‘full’ GovERP solution, and the initial template as per Decision 12 (see Reference 1) outlining the MVP, which is assessed within this report.
2. MVP1.1: This is the agreed template that was being developed by Services Australia at the time of GovERP pause, which is assessed within this report (see Reference 2).
3. MVP1.1 with AGD enhancements: This was the template, developed for AGD, which incorporates specific requirements identified during implementation discovery.

For the purposes of this assessment:

• MVP build assessment: The assessment has focused on the build of MVP1.1. The build status against MVP1.1 with AGD enhancement has not been explicitly considered, however, any changes from the base product (i.e. WRICEFs) (see Reference 3) have been included for visibility.
• definition of built: Built means development has occurred, and functional testing has been conducted. As agreed with Services Australia, where functional testing was not completed, the build status has been listed as not built. Note, no system integration testing (SIT) or user acceptance testing (UAT) was conducted as part of GovERP, which are required prior to deployment into a production environment.

Further, assessment against the following dimensions of the build completeness has been
conducted:

• value streams and processes: Evaluates the business perspective of developed components for potential application in other entities’ organisational needs.
• functional capabilities: Reviews a technical capability and outlines the architectural development of the product.
• customisation and configuration: Analyses specific enhancements made to the base products to understand the deviations from the standard ‘out-of-the-box’ configuration, known as WRICEFs. In respect of the WRICEFs, each have been assessed on the below scale of effort to maintain:
  • low – Configuration changes only.
  • medium – Development support required to adjust code (e.g. Business Add-in) and support enhancements.
  • high – Full development support required (e.g. solutions implemented via SAP note where code has been written).
• data and security: Highlights key security and data storage information essential for understanding GovERP’s foundational elements.

The evidence gathered throughout the review can be categorised into three main areas:

• cite: The assessment team has observed and validated relevant aspects of the system.
• documented: Documentary evidence provided (e.g. test reports, Gateway reports,technical specifications).
• interviews: Discussions with, or testimonials from, key stakeholders.

To understand the current state of the GovERP build, extensive research has been conducted,
including:

• document review: architecture artefacts, build and test reports, technical specifications.
• interviews: discussions with technical and business leads from Services Australia.
• vendor engagement: interactions with SAP and 8common.
• external agency engagement: AGD, Department of Finance and Department of Defence.

2.4.3 Potential for reuse

This phase is concentrated on identifying concrete opportunities for reuse within GovERP. The concept of reuse has been broadly interpreted, encompassing the use of existing technology and leveraging pre-existing processes or patterns. Nonetheless, to reuse something is to make use of it more than once for a different purpose, or for a subsequent time.

The Digital and ICT Reuse Policy outlines three high-level requirements for reuse:

• reuse whenever possible – 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 a proposed investment cannot reuse an existing digital or ICT solution, the proposed investment must ensure that the service built can be reused by other agencies.
• enable reuse by others – ensure anything created is shared for others to reuse unless there’s a good reason not to.

Based on the policy, the current build status, environmental considerations around data, integration and hosting, reuse has been conceptualised at three distinct levels:

• Tier 1: Use of what is already built by fully adopting all components within a specific product.
• Tier 2: Building on something that exists by adapting a copy of the product as an accelerator for individual entities use.
• Tier 3: Repository, such as learnings, business processes.

These three levels are shown in the figure below.

GovERP was overseen by the Shared Services Sub-Committee (SSSC), comprising 13 Government entities (see Reference 2). Program delivery was a collaborative effort between the GovERP Program, Provider Hubs, and Client entities across three releases, focusing on staged delivery of an MVP in line with the P2A framework (see Reference 3).

Smaller entities were envisaged to utilise alternative technology bases such as TechnologyOne / Aurion (overseen by the Department of Industry, Science and Resources) or Oracle, and larger entities were envisaged to utilise an SAP solution overseen by Servies Australia.

The Program aimed to serve approximately 90 Commonwealth entities and around 130,000 APS staff, replacing existing ERP systems in use at five shared services hubs (see Reference 4) within:

• Department of Finance
• Australian Taxation Office
• Department of Foreign Affairs and Trade
• Department of Home Affairs
• Services Australia

The Program’s intended operating model was two corporate service ‘hubs’, specifically:

• Technology Hub: The Technology Hub was to provide infrastructure, platforms, environments, and support, and regularly update the code base and master data for use by the Provider Hubs.
• Provider Hubs: Multiple service provider hubs which were to operate independently, however, share the common code base and subset of master data, and provide services to entities.

In November 2023, the Minister for the Public Service announced a new APS ERP approach, concurrently repurposing GovERP for use by Services Australia.

Figure 5 provides a high-level overview of the significant events in the history of GovERP. Further details can be found in Appendix I.

3.2 Solution

3.2.1 Minimum Viable Product (MVP)

The MVP (see Reference 5) encompasses the planned capabilities for GovERP, as agreed by the Shared Services Steering Committee as outlined in Figure 6 below.

The MVP was determined based on Steering Committee Strategic Policy Decision 12 
(December 2020; see Reference 6), which specified mandatory and non-mandatory capabilities. These capabilities represented what an agency would mandatorily need to deliver on; that is, the requirements that are mandated through legislation, policy, and enterprise agreements. 

The salmon boxes in Figure 6 refer to those Decision 12 MVP components which were deprioritised in response changes identified during delivery of GovERP, and were not built by Services Australia. Therefore, the assessment of what has been built by Services Australia excludes these MVP salmon boxes. 

Capabilities beyond the MVP were labelled as ‘target’ (or ‘extended’; see Reference 7), and were intended for future phases of the GovERP program. 

Entities requiring capabilities beyond the MVP scope were required to facilitate their own integration using standard interfaces of those out-of-scope areas. This applied to both capabilities that are entirely out of scope and capabilities where a consumer chooses to use an alternate solution to that provisioned in the MVP.

3.2.2 Value streams

To support the future one-APS vision, it was important to consolidate and standardise disparate corporate processes within the Australian government. The GovERP value streams comprise:

1. Hire to Retire (H2R): This value stream manages the entire human resource lifecycle within the APS. It encompasses recruitment, onboarding, mobility, pay, performance management, workforce management, and separations.
2. Budget to Report (B2R): This value stream covers the financial management lifecycle of an agency, from external budgeting to the release of financial statements. It includes external budgeting, internal budgeting, sub ledger aggregation, consolidation, adjustment, closure, and reporting.
3. Revenue to Bank (R2B): This value stream oversees the revenue lifecycle of an agency, from revenue generation to Banking and Treasury functions. It includes proposing funding and charging arrangements, formalising agreements, delivering services, invoicing, banking, managing outstanding items, and reporting.
4. Procure to Pay (P2P): This value stream manages the purchasing and contract lifecycle for acquiring goods and services to support an entity’s business. It includes sourcing, requisition, order processing, payments, and reporting.
5. Travel and Expense (TEMS): This value stream handles the lifecycle of reporting issues or lodging requests, from triage to resolution or fulfilment. It also includes supporting materials such as knowledge base articles or help cards to assist users in resolving their own issues.
6. Enquire to Resolve (E2R): This value stream manages the support lifecycle of reporting issues or lodging requests, from triage to resolution or fulfilment. It’s important to note that this value stream falls outside the scope of this report.
7. Prepare to Adopt (P2A): This value stream manages the lifecycle of change management that guides individuals, groups, and organisations through transitions. While its primary focus lies in facilitating entities’ onboarding into GovERP, it also serves ongoing functions. During onboarding, this value stream supports seven project phases, ensuring readiness to transition, initial engagement and discovery, preparation and planning, design, documentation, building, training, and testing, monitoring and stabilising, and continuous improvement. In its ongoing capacity, P2A aids in assessing planned change, consulting stakeholders, preparing communication/training materials, implementing change, and managing change (see Reference 9). It’s important to note that this value stream falls outside the scope of this report.

Service and functional capabilities within the business capability model have been mapped to value streams in Figure 7 below. These highlighted capabilities represent most of the functionality for each value stream, although not necessarily all capabilities involved.

Entities are expected to access services through value streams, which delineate the scope of offerings. While five value streams support functional capabilities, two of them (Prepare to Adopt and Enquire to Resolve; see Reference 10) are pivotal for the service management and the on-boarding of client entities and Provider hubs.

Value streams transcend capabilities and functions, and entities within shared services, integrating these elements to deliver value to stakeholders. 

Rather than representing discrete services, value streams embody overarching lifecycles in which all entities participate to achieve business outcomes. 

Each value stream encompasses a series of customer journeys and associated processes.
The MVP was designed as a foundational template encompassing essential solutions necessary for supporting critical government functions. These solutions included robust capabilities in human resources, finance, procurement, and travel and expense management, forming the core framework of the ERP system designed to meet specific APS requirements. 

Additionally, it embraced additional edge functionalities like recruitment, onboarding, learning management, success planning, and performance measurement, enhancing the versatility and utility of the ERP solution.

Core and edge capabilities were categorised as:

• core capabilities: These are fundamental building blocks required to deliver a basic ERP solution.
• edge capabilities: All other capabilities beyond core functionalities.

The Core implementation was standardised; however, entities had flexibility to choose Edge products according to their specific needs. A panel of products and partners was established, offering a range of options for Edge products.

GovERP adopted an incremental delivery approach for both core and edge capabilities, aligning with a whole of government solution template.

3.3 Technical architecture

GovERP’s core offerings comprised SAP S/4HANA and SAP SuccessFactors, with various other capabilities operating as ‘Edge’ systems extending the core. Provider Hubs used this template to create an instance of the GovERP system to support their client entities.

External and internal traffic was expected to pass through an outsourced Secure Internet Gateway (SIG), with all GovERP SaaS applications hosted on secure clouds in Australian data centres. Note, a vendor was procured for the SIG, but the contract was not executed given the pause of the GovERP Program.

References

1. GovERP End to End Solution Architecture v2.0
2. Entities represented on the SSSC included: Department of Finance; Australian Taxation Office; Department of Foreign Affairs and Trade; Digital Transformation Agency; Bureau of Meteorology; Services Australia; Department of Health; Department of Agriculture, Water and the Environment; Department of Education, Skills and Employment; Department of Industry, Science, Energy and Resources; Australian Financial Security Authority; Department of Social Services; and the Department of Home Affairs
3. Per Decision 22 of the Decision Framework Briefing_Outcomes of SSSC, page 145
4. Per Decision 7 of the Decision Framework Briefing_Outcomes of SSSC, page 47 
5. Per Decision 12 of the Decision Framework Briefing_Outcomes of SSSC, page 91. 
6. Per Decision 12 of the Decision Framework Briefing_Outcomes of SSSC, page 91. 
7. Extended capabilities represented functions that are used and required across many entities, but not necessarily all.
8. During delivery of GovERP, within the Human Resources business area, “Work Time and Attendance” and “Time Sheet Recording and Management” were combined into a single set of processes within SAP Signavio. From there, a single capability, “Work and Time Attendance” was reported on at a capability level.
9. Note, the above does not include vendors or solutions for Secure Internet Gateway or Centralised Identity Provider, as procurement activities were not finalised.
10. These two value streams (Prepare to Adopt and Enquire to Resolve) are out of scope of this assessment