GovERP Technical Assessment

2. Introduction

2.1 Purpose

This Reuse Assessment Review report is an independent assessment of the Australian Government ERP ecosystem, GovERP.

Taking into account what has been built as part of MVP 1.1 in preparing to onboard the Attorney-General’s Department (AGD) and the full scope of the ERP requirements of Commonwealth entities (MVP1.0), the assessment provides evidence upon which to assess the reuse potential of the GovERP solution and the ability to implement the Hire to Retire (H2R), Budget to Report (B2R), Revenue to Bank (R2B), Procure-to-Pay (P2P) and Travel and Expense Management (TEMS) value streams.

The report provides:

• an assessment of the completeness and maturity of the GovERP system. Where Services Australia GovERP development is incomplete or ongoing, an assessment of what capabilities are outstanding and the schedule for their delivery.
• consideration of the feasibility of incomplete parts to provide an understanding of how long it would take other Commonwealth entities to use the capability.
• capabilities, functions and/or modules that meet the reuse principles and why.
• capabilities, functions and/or modules that do not meet reuse principles and why.
• expert insights that assist the DTA to provide recommendations to improve the reuse potential of the capabilities, functions and/or modules that do not meet the reuse requirements.

2.2 Scope

2.2.1 In scope

This report includes the following:

• a catalogue of business functions that the GovERP provides, and a mapping of alignment between these capabilities and the underlying and supporting IT infrastructure (software and hardware), including any modules or extensions with GovERP.
• GovERP solution’s value streams, Hire to Retire, Revenue to Bank, Budget to Report, Procure to Pay, and Travel and Expense Management.
• functional diagrams, at the application and infrastructure levels, of the GovERP system.
• evaluation of environments, systems, processes, GovERP configuration, design data, and IT architecture artefacts (e.g. business catalogues, interfaces, APIs, and SAP core function customisations).
• all components of the GovERP system, including Application Programming Interfaces
  (APIs) and other connection points with external systems.
• implementation considerations for other entities when exploring GovERP’s potential reuse.
• evaluating the build and implementation status of GovERP, including readiness for reusing existing environments, systems, processes, and data (standards and integration).
• identifying elements of GovERP that could potentially be reused, including any limitations which may be applicable.
• outlining how other Australian Government entities can reuse GovERP for their needs.
• offering insights into GovERP’s reuse potential and specific implementation pathways for other Australian Government entities.

2.2.2 Out of scope

This report does not cover:

• assessment of GovERP’s scope or the validity of the original business case, or other elements of the GovERP Program beyond the technology focus of this report e.g. appropriateness of the scope of the MVP.
• analysis of the program’s performance or factors leading to the GovERP Program’s pause.
• the following value streams:
  • Prepare to Adopt (P2A) as this relates only to change management and the implementation of GovERP, and as such no technologies were designed or built which could be considered for reuse.
  • Enquire to Resolve (E2R), as this is focused on IT Service Management, rather than a functional build of the ERP solution.
• comparison of existing entity business processes with those in GovERP.
• mapping of GovERP architecture to existing entity architecture.
• detailed costings related to implementation, as these depend on agency-specific factors (e.g. the approach to be taken, the maturity of the capability and the existing workforce capabilities).
• consideration of any customisation / configuration or data migration requirements.

2.3 Relevant artefacts

The report refers to the following government artefacts:

• Digital and ICT Reuse Policy: Sets out requirements for entities to consider and enable reuse in digital and ICT capabilities.
• Australian Government Architecture (AGA): Provides guidance on aligning solutions with government’s digital direction.
• Other frameworks relevant to GovERP’s capabilities or products: Secure Cloud Policy, Hosting Certification Framework, Protective Security Policy Framework, Essential Eight, Digital Service Standard.

2.4 Reuse assessment approach

2.4.1 Approach

The approach developed to undertake the reuse assessment is outlined in the figure below.

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.