GovERP Technical Assessment

5. What can be reused and how?

5.1    Overview

The current state of GovERP diverges significantly from the original program design and original operating model. The project has also seen an abrupt pause partway through development. While certain aspects of GovERP hold potential as accelerators for entities, it's important to recognise that entities will likely need to complete and potentially further customise the templates while adhering to existing data standards; AGD’s experience necessitated similar considerations for use of GovERP.

To leverage GovERP components as accelerators, additional considerations and negotiations regarding whole of government licensing implications will be necessary. For large entities grappling with complex ERP requirements and substantial IT workforces, particularly those reliant on SAP, GovERP could serve as a potent accelerator, potentially featuring numerous enhancements tailored to government needs.

The foundational premise of GovERP and its proposed operating model was intended to create a reusable platform across the government landscape. However, with the project's scope now reduced  minimum viable product and shared services suspended, coupled with a departure from the initial operating model and the componentisation of GovERP, achieving the desired level of reusability presents a challenge.

In alignment with the Reuse Hierarchy, the following components have been identified as capable of reuse.

Whilst the above focuses on specific technologies which can be reused, blueprints and patterns for the other technologies identified in section 5.7 could be reused by other entities as well (outright or as accelerators).

The conditions and considerations pertinent to the reuse of these components are discussed in the subsequent sections.

5.2    Practical re-use considerations

When considering the reuse of a substantial ERP technology solution, it is essential to assess not only what could be reused, but also whether it should be reused. While some entities may be closer to adoption than others, consistency doesn’t always translate to simpler or more costeffective implementation. Therefore, practical considerations for reusing components should be thoroughly evaluated in every scenario.

5.2.1     Componentisation

While the GovERP solution was not originally conceived with componentisation in mind, there was consideration given to implementing an iterative go-live approach, indicating that some level of modularisation may be feasible. 

However, it is important to acknowledge that achieving true modularisation presents substantial challenges without established commercial agreements, hosting solutions, complete components, and adherence to data standards. 

Given the current hosting arrangements, an iterative go-live strategy and the potential for reuse seem most appropriate for Services Australia's implementation of the solution. 

5.2.2     Operating Model

The original GovERP operating model included the concept of a Technology Hub, which would encompass all core products and enhancements and manage maintenance and upgrades.  This hub was intended to be ‘linked’ to a variable number of Provider Hubs, allowing entities to benefit from the core system while making bespoke changes as needed in their own versions.

In this model, the Technology Hub would be hosted and managed by an entity with the requisite SAP skills and workforce to properly oversee the core GovERP product and government enhancements. Entities would be responsible for managing any customisations they made for themselves, while core maintenance and enhancement uplifts would be managed by the Technology Hub provider.

For the current ERP product, two different operating models could support reuse:

1. Lift and shift: Services Australia could assist entities in packaging (and supporting) a copy of the GovERP codebase (in whole or in part) for deployment into their own landscape, thus expediting their ERP implementations.
   This would likely require significant effort from Services Australia, and lead to several other implications, such as commercial considerations, data management, and process alignment, which would need to be considered.
2. Vendor SaaS: Subject to commercial considerations, the product (and associated components) could be stabilised and offered by vendors as one or multiple SaaS products to other entities. 
   This would likely require substantial effort from Services Australia, and lead to various other implications, including commercial factors, data, management, and process alignment, which will need to be addressed accordingly.

5.2.3     Commercial

There will be commercial implications to any reuse, including the finalisation of the existing build, potential software end-of-life costs, and upgrade implications. These considerations are likely to require advocacy from the DTA as whole of government considerations for some or all the GovERP components, including:

1. reuse of the end-to-end GovERP product: Once (if) it is finalised.
2. component reuse: Can entities take some or all the code as the current package, but only pay for the specific services that they use?
3. SaaS vendor solutions: If some of the solution accelerators are packaged up, and vendors sell them to other government entities, is there a whole of government discount licence as a part of this?
4. lift and shift: If this option is chosen, there will likely be one-off costs incurred on the Services Australia side to package the solution up, in addition to licensing implications and adoption costs from entities wanting to utilise what has been built.

5.2.4     Data

For any re-use of the current solution, whether in its entirety or component-based, onboarding or reusing entities would need to adopt the data standards currently built into the GovERP solution. Further, if entities are using part of or integrating back to their processing platforms, these data standards will need to be adhered to both for migration to go-live and transactionally for ongoing use. Work will be required to define the data standards in a way that entities can consume and understand the effort. 

5.2.5     Maintenance

Balancing standardisation with customisation is crucial to meet specific government needs effectively. Standardising processes where possible reduces complexity, improves maintainability, and facilitates interoperability among government entities.

Therefore, any agency intending to implement GovERP will require a dedicated team to maintain and operate the platform. Properly sizing and monitoring the resource consumption of the WRICEF components will be vital to ensuring GovERP continues to meet business requirements over time.

The current GovERP asset may be able to assist large entities with complex ERP needs, particularly those with substantial IT workforces and/or using SAP, as it can serve as an accelerator, given the availability of support teams for maintenance requirements.

Despite the build status, SAP have advised (see Reference 1):

• "There is nothing visible in the core solutions that would limit supportability in the future using GovERP template for Services Australia ERP”.
• “There is nothing visible that would limit its reuse nor deem it not supportable”.
• "No changes to standard / core code, as well as all WRICEFs [having been] reviewed by the SAP Premium Engagement team”.

5.2.6     Integration

For any reuse of the current solution, whether in its entirety or based on components, onboarding or reusing entities would have to adhere to the integration standards already established in the GovERP solution.

Effort will be needed to define these integration standards in a way that entities can easily understand and adopt.

Adopting consistent integration standards, even if not all components of GovERP are used as accelerators or reused, would still reduce lower implementation costs and minimise impact across government entities by aligning data standards more closely across the whole of government.

5.2.7     Business process alignment

Entities should recognise that to effectively utilise any aspect of the GovERP solution (i.e. for it to be cost-effective and reusable), they must adopt the envisioned business processes outlined in the template. 

Any deviation from this will likely necessitate additional enhancements, data modifications, and integration considerations.

Further, entities will need to conduct a fit-gap analysis to determine any specific business process requirements that extend beyond the template.

5.2.8     Solution Gaps

At this point, any entity intending to reuse (or use as accelerators) any aspect of the GovERP product must assess the effort required to develop capabilities that are currently absent or require enhancement based on the current build and test status. 

5.3    H2R | SAP SuccessFactors

5.3.1     Residual build requirements

SuccessFactors serves as a comprehensive HR management platform, encompassing core HR and payroll, talent management, sales performance management, people analytics, and workforce planning. 

Configurable learning modules within SuccessFactors allow for agency-specific training to be incorporated into localised versions. While version MVP 1.1 with AGD enhancements demonstrated capability in these areas, the full functionality build remains incomplete, representing a partial build for the common template.

5.3.2     Implementation options, timeframes, and potential costs

Substantial effort would be required to map existing process, align data and integration standards, and potentially decouple the existing SuccessFactors solution from the GovERP landscape, to use as an accelerator. Entities will also need to consider the implications of using this within the SAP Sovereign Cloud.

SuccessFactors blueprints/patterns can be reused in their current state once requirements and implementation planning has been undertaken by interested entities.

SAP has advised the logical module groupings, which could be deployed in a phased approach, are:

• EC (core), ECP & Time Tracking
• Recruitment and Onboarding
• Performance & Goals and Learning
• Succession & Development

By componentising these modules and implementing them in phases, SAP suggests the development burden is potentially reduced, although this has not been quantified. The suitability of these groupings will need to be assessed based on agency requirements at the time of product consideration.

5.3.3     Procurement and Commercial

The whole of government agreement for licencing and implementing the SAP SuccessFactors platform is currently under negotiation. The existing panel (SON3464296) expires June 2024. Professional Services cost estimations will be explored further post-completion of the whole of government SAP negotiation. Other commercial implications exist as per section 5.2 of this document.

5.3.4     Technology and architecture

MVP1.1 includes 5 WRICEF enhancements to the Leave and Absence Management, and Payroll Services modules within SuccessFactors. An additional 12 WRICEF interface designs under the Employee Management, Payroll Services, and Leave and Absence modules are built, supporting reusable capabilities upon completion of build and test activities

5.3.5     Security, data, and storage

SAP SuccessFactors does not possess formal Australian Government security certifications. Entities intending to use the product suite should pursue their own security certifications. Given SuccessFactors’ storage on the SAP Sovereign cloud, integration with SAP Sovereign Cloud is necessary if using the GovERP version.

5.3.6     Governance

Without formal ownership of governance documents and a dedicated uplift and maintenance strategy, the current state common template and GovERP blueprints and patterns risk becoming archival records. Ongoing management of the SuccessFactors MVP templates is crucial.

5.3.7     Ongoing maintenance and support

SuccessFactors follows a 6-monthly release cycle, whereas ECC6 previously followed a 12-month release cycle. For each release, the client agency will need to undertake testing of the proposed upgrade and any support and remediation activities associated with it.

5.4    R2B + B2R + P2P | S/4HANA

SAP S/4HANA serves as the primary Finance and Procurement solution within GovERP, covering the value streams of Budget to Report (B2R), Revenue to Bank (R2B), and Procure to Pay (P2P).

5.4.1     Residual build requirements

Any remaining build requirements for the MVP must be finalised and tested, including systems integration testing and user acceptance testing. Given the ongoing development and testing needed for B2R, R2B and P2P, a detailed cost estimate from Services Australia is necessary to address any gaps.

Furthermore, it is expected that additional configuration will be necessary to align with the requirements of individual entities. Therefore, each agency will need to conduct a gap fit analysis as part of their implementation process, including configurations and conducting associated testing.

5.4.2   Implementation options, timeframes, and potential costs

Based on the available data and SAP's advice, two pathways are apparent for the S/4HANA components associated with GovERP.

1. Utilise a copy of the Services Australia version as an accelerator in an agency's own Azure instance. 
2. Upgrade the version of S/4HANA to the latest release and migrate to the SAP Sovereign Cloud. 

It is essential to acknowledge the implications outlined in this document, including commercial considerations, ongoing maintenance, versioning, and end-of-life considerations, before proceeding with either option.

5.4.3     Procurement and Commercial

The current licensing agreement for S/4HANA was issued under GovERP. Services Australia and the DTA have indicated that confirmation is necessary before another agency can use it. Therefore, each agency may need to negotiate new licensing arrangements in line with their implementation option. 

Negotiations for the licensing and implementation of the SAP S/4HANA platform under the whole of government agreement are currently underway. The existing panel (SON3464296) is set to expire in June 2024.

Further investigations into the estimated Professional Services costs to complete this will be required once the whole of government SAP negotiation is finalised in June 2024.

5.4.4     Technology and architecture

SAP S/4HANA serves as the core FMIS, currently hosted on a private instance in Azure. It is supported until 2040 under existing commercial arrangements.

The current version of S/4HANA being used is already two releases behind the current version. To make it cloud ready, an upgrade would be necessary at some point in the future to maintain integration with SAP SuccessFactors in the SAP Sovereign Cloud (SSC).

Within the S/4HANA landscape, there are also systems like SAP Master Data Governance, Open Text Vendor Invoice Management (VIM), MS Sentinel, and MS Active Directory, all of which need to be packaged to ensure future reusability.

While progress has been made, further work is needed on the S/4HANA product to fully realise the envisioned core financial management capabilities outlined in this document.

MVP1.1 incorporates 61 WRICEF enhancements tailored to the whole of government template for the standard SAP S/4HANA product, serving as reusable accelerators.

As advised by SAP, the current FPS01 (2021) instance of S/4HANA needs upgrading and reconfiguration to at least the October 2023 (FPS00 2023) release to ensure long-term connectivity to any SAP Sovereign Cloud solution as a viable reuse option.

5.4.5     Security, data, and storage

Security, data, and storage considerations are crucial for SAP S/4HANA, a central component of the current GovERP product, integrated with other SAP components via SAP BTP.  Currently, S/4HANA is deployed within Services Australia’s private Azure tenancy. 

S/4HANA has an independent security certification (IRAP/Cloud Security Assessment), which can be leveraged by other entities outside of Services Australia’s tenancy. However, it’s important to note the IRAP assessment focuses on the private cloud edition of SAP ERP, which may not align with alternative reuse strategies. 

Given the S/4HANA is implemented on Services Australia’s infrastructure, the responsibility for maintaining patching, upgrades and maintenance requirements falls on Services Australia.

5.4.6     Governance

Without formal ownership of governance documents and a dedicated uplift and maintenance strategy, the current state common template and GovERP blueprints and patterns risk becoming archival records of the program's status as of 2023. It is crucial to note that ongoing management of the S/4HANA MVP templates will be necessary.

5.4.7     Ongoing maintenance and support

As noted previously the existing GovERP asset could potentially serve large entities with complex ERP requirements, especially those with substantial IT teams, particularly in SAP expertise, to expedite implementation. However, it's crucial to note that ongoing maintenance and support of the S/4HANA solution will be necessary on the client side.

5.5     TEMS | Expense8

Expense8 is a Software-as-a-Service (SaaS), cloud-based travel and expense management solution provided by 8common. It has been operational in the Australian Government since 2011.

5.5.1     Residual build requirements

As a Software-as-a-Service (SaaS) product, Expense8 is developed and maintained by the vendor. It's advised that the current whole of government template, employed by over 40 entities, necessitates straightforward configurations rather than intricate setups before deployment.

While the product is ready for use, integrations with S/4HANA have not been established (e.g., APIs) and may be necessary for adoption by another agency by using this technology state. 

However, the vendor has indicated integrations with various other technologies (such as TechnologyOne, SAP ECC6, Sage, Dynamics) are already in place.

Furthermore, the vendor has indicated any additional GovERP template builds will be integrated back into the configurable SaaS product. This will allow entities to toggle the features and functions as needed.

5.5.2   Implementation options, timeframes, and potential costs

Expense8, being a cloud-based Software-as-a-Service (SaaS) product, offers two deployment options: 

• either as a standalone solution, or
• integrated into existing or legacy tools.

Implementation of Expense8 typically spans 3-6 months with a team of approximately 2-5 FTE. 

Factors influencing the timeline include scope definition, resource availability, existing technology stack and infrastructure, customisation and configuration requirements, data migration and cleansing, user training and change management, regulatory compliance, security, testing, quality assurance, and external dependencies. Ongoing costs are subscription-based.

A typical rollout as provided by the vendor, involves several stages:

• understanding agency readiness, including change management and communications
• discovery using the GovERP template as an initial baseline and the Expense8 ‘Early Adoption’ program
• configuration and customisations
• testing
• deployment and training
• sustainment.

Being hosted on AWS as a SaaS product, Expense8 shows no performance limitations. The main risk to successful implementation lies in resource provision within project teams. While the implementation effort for Expense8 is generally low, appropriate resource allocation, especially for data sourcing and migration activities during the initial release, is crucial for success. This implementation risk is not unique to Expense8, but it's worth noting as highlighted by current use cases during the assessment of the GovERP ecosystem.

5.5.3     Procurement and Commercial

Expense8 is available through the Cloud Marketplace (SON3668352) managed by BuyICT. 

Entities need to obtain their own licences, as there is no whole of government licence and no ‘piggy backing’ contractual clause (see Reference 2), although Services Australia has a head agreement with the vendor 8common.

5.5.4     Technology and architecture

Expense8 key features include but are not limited to pre-trip approval, real-time tracking of travel costs, and automated expense reporting and reimbursement. The product operates as a Softwareas-a-Service (SaaS) model stored and maintained by the vendor.

Expense8 notes they are the sole product in the market that integrates with the CTM travel provider. Enabling users to book and manage travel expenses within a unified interface. As a sovereign platform, it provides tailored functionality for users to request and order corporate cards for APS travel and expenses.

The Expense8 core platform is equipped with integrations and APIs compatible with numerous technology platforms, including Technology One, SAP, Chris21/HR21, Sage, Dynamics, and Oracle. This broad compatibility allows Expense8 to seamlessly integrate with multiple Australian Government entities, regardless of their financial management and HR technical solutions. However, customisations specific to the localised version of the GovERP platform, such as those for AGD, may not be reusable unless the target agency shares the same capability requirements.

MVP1.1 incorporates 10 WRICEF enhancements tailored to the whole of government template for the standard SAP S/4HANA product, serving as reusable accelerators.

5.5.5     Security, data, and storage

Expense8 has obtained IRAP certification (2023, PROTECTED), hosted on AWS servers located in Australia. Notably, Expense8 operates within two distinct hosting environments:

• protected cloud: This environment is exclusively accessible to suitably security-cleared personnel within Australia, making it the preferred option for most Australian Government workloads.
• public cloud: Accessible by offshore staff who support Expense8, this environment serves specific purposes within the operational framework.

Moreover, Expense8 complies with the Payment Card Industry Data Security Standard (PCI DSS), which necessitates security measures for handling payment card data.

5.5.6     Governance

Governance requirements for this solution are minimal.

5.5.7     Ongoing maintenance and support

Ongoing maintenance and support for Expense8, being a Software as a Service (SaaS) solution, is handled entirely by 8common. Entities are responsible for covering the costs of licences on an ongoing basis. Any customisations needed will require negotiation with 8common. 

5.6    GovERP Processes | SAP Signavio

SAP Signavio comprises a suite of business process management (BPM) and transformation tools offered by SAP. 

5.6.1     Residual build requirements

No residual build requirements have been identified for SAP Signavio.

5.6.2   Implementation options, timeframes, and potential costs

Although an archival version (see Reference 3) of the system has been extracted into .pdf form, the extracted artefact has lost editability and will diminish in value as a reuse tool over time. A copy of the Signavio file can be provisioned by Services Australia, which is expected to retain all functionality and features, however, will require another entity to hold appropriate licences to access the file via Signavio.

Services Australia has indicated that approximately four other Australian Government entities (e.g. Department of Health and Aged Care (DoHAC) and the Department of Infrastructure, Transport, Regional Development, Communications and the Arts (DITRDCA)) are interested in accessing the Signavio system for process map usage. This interest indicates a government-wide need to maintain or find a suitable digital alternative for long-term access to information within the Signavio platform.

Given Services Australia’s position to discontinue the use of Signavio (refer Section 5.6.3 Procurement and commercial), the only viable option for reusing this content is to transfer a full copy of the archive file to the DTA (see Reference 4) or DOF. The DTA or DOF will then be responsible for maintaining the process maps in consultation with key stakeholders, such as Services Australia.

The exact cost implications for SAP Signavio will depend on the number of users and modules required, with larger organisations likely to incur significantly higher costs than smaller ones. 

5.6.3     Procurement and commercial 

The current licencing arrangement for Signavio is due to expire in July 2024 and Services Australia intends to let the current licence arrangement lapse due to availability of other platforms in the Services Australia ecosystem, such as Aris, which better suits their needs.

The original intent was for Signavio to be rolled out to other entities so that BPM could be used across government entities, especially once GovERP was onboarded by those other entities.

5.6.4     Technology and architecture

Signavio is a standalone process mapping tool, and other parts of GovERP do not rely on Signavio to run or operate. However, the current ERP Solution Manager is integrated with Signavio via SAP BTP to facilitate the exchange of process documentation content.

5.6.5     Security, data, and storage

Signavio has been IRAP-assessed (Cloud Security Assessment - March 2023) for Australian Government use, providing assurance of its suitability for government purposes.

5.6.6     Governance

The governance arrangements which lead to the creation of the Signavio process maps have effectively disbanded. There was considerable governance within the GovERP Program to ensure agreement where possible to drive process consistency across entities. There is value maintaining this governance government-wide.

The entity that takes possession of a Signavio archive file will need to ensure appropriate change controls are implemented to ensure the process maps reflect the ERP system builds and are updated accordingly.

5.6.7     Ongoing maintenance and support

As a SaaS solution, all maintenance, upgrades, and enhancements are managed by SAP. 

Entities will be required to cover the ongoing costs of licences any customisations will need to be negotiated with SAP. Maintaining the process maps to ensure they remain contemporary and aligned to the chosen ERP solution will require substantial effort.

5.7 Other technologies intended to augment the GovERP solutions 

Various technologies within GovERP can be considered to augment the GovERP solution. The table below delineates these factors.

References

1. Per Supportability and GovERP reuse for Services Australia ERP, as provided by SAP Australia on 11 April 2024.
2. As per discussions with Expense8 and Services Australia.
3. Signavio archive and an XML archive
4. Note, the DTA have made an interim decision to have the Signavio file transferred to them.