Perspectives on emerging trends in Corporate and Shared ...€¦ · Table of Contents Foreward...

Perspectives on emerging trends in Corporate and Shared Services delivery platforms

Corporate and Shared Services Reform Program

Corporate and Shared Services Reform Program NSW Office of Finance & Services

Corporate and Shared Services Reform Program

(CSSRP)

CSSRP assists NSW Government agencies to consolidate and standardise their corporate and shared service support functions more quickly.

CSSRP provides services as part of the ICT Strategic Delivery group in the Office of Finance and Services

(OFS).

Tuesday, April 28, 2015

Pedro Harris | Executive Director, ICT Strategic Delivery E [email protected]

Anthony Lean | Deputy Secretary, Government Services E [email protected]

Corporate and Shared Services Reform Program NSW Office of Finance & Services

This document is uncontrolled when printed

mailto:[email protected]

mailto:[email protected]

Table of Contents

Foreward

Executive summary 1

Situation 2

Trends in ERP deployment models 3

Commonalities and contrasts across the ERP lifecycle 4

The ERP lifecycle 4

Key variations between ERP deployment models 6

Phase 1 - Strategise and plan your ERP journey 7

Phase 2 - Architect the ERP solution 9

Phase 3 - Procure the ERP solution 11

Phase 4 - ERP solution deployment 13

Phase 5 - Operate and evolve ERP solutions 15

Summary of commonalities and contrasts between models 17

Business Process Management (BPM) – a constant in ERP deployment models 18

The ERP processes are not the end-to-end business processes 18

Business process management is always owned by the business 19

Business process management enables continuous improvement independent of vendor constraints 20

Summary of findings 22

Appendix 24

Appendix A: Methodology 24

Appendix B: An overview of Cloud 24

Appendix C: Sources 26

Foreward

Postmodern ERP is defined as the deconstruction of monolithic ERP suites into

loosely coupled applications components. As organisations digitise their corporate

areas they will want to provision the most appropriate and agile digital processes.

This may be achieved with a blend (or hybrid) of services that may be sourced

internally from within their organisations, or a managed externally, or perhaps

outsourced. Hybrid is emerging as the dominant deployment model however it will

need to co-exist with other approaches.

This practice guide was developed to contrast the deployment approaches

associated with these emerging trends, aid project teams undertaking ERP

transformations and streamline the project lifecycle.

Deputy Secretary

Anthony Lean

Deputy Secretary

Government Services

Office of Finance and Services

.

-

’

Executive summary

The original Corporate and Shared Services (CSS)

Strategy was initiated at a time when the majority

of CSS projects were delivered through on-

premise, customised Enterprise Resource

Planning (ERP) applications (‘provisioned

internally’ or PI model). Market and technology

evolutions have since then seen the emergence of

two other deployment models (Utility and Cloud

models) which are increasingly being considered

by Principal Departments to support the delivery of

their CSS reform, in alignment with the NSW

Government ICT Strategy.

While awareness is growing around the benefits of

these alternative delivery models, there may be

some misconceptions about the particular trade-

offs involved for PI, Utility and Cloud ERP

deployments. The Corporate and Shared Services

Reform Program (CSSRP) has led extensive

research to support agencies in making informed

decisions with regards to their ERP delivery

strategy, based on Gartner analysis, Tier-1 private

service provider reports, and public sector

experience.

Key findings of our research:

ERP implementations follow the same journey

and key activities, regardless of the deployment

model adopted.

The emphasis on some key activities varies with

the choice of PI, Utility or Cloud ERP mainly

linked to the extent of customisation available,

and the impacts of change for people, financial

planning and technology integration.

Utility and Cloud ERP models shift emphasis in

Business Process Management (BPM) from the

definition of the technical solution, to the adaption

of the business processes to work with a standard solution.

Our recommendations:

Thoroughly assess your constraints before

selecting a deployment model. Each option has

trade-offs depending on your situation.

Include a Business Process Management (BPM)

exercise during your implementation journey,

irrespective of the deployment model. This

activity should not be omitted in Utility and Cloud

models, as it can significantly de-risk your

journey by providing better control over your

processes for the longer term.

Express your needs to CSSRP so that the

Program can continue to evolve and adapt its

service offerings to support agencies in PI, Utility

and Cloud ERP deployment models.

The CSSRP’s purpose is to support agencies in

their ERP implementations, regardless of the

deployment model chosen.

The CSSRP connects agencies together to share

knowledge and experiences, helping them make

more informed decisions.

The NSW Government Standard Business

Processes and ARIS platform offered by the

CSSRP significantly accelerates BPM activities

and also significantly reduces time to achieve a

business blueprint.

These NSW Government Standards are now

available on the ICT Services Scheme to

registered subscribers at no cost.

Perspectives on emerging trends in Corporate and Shared Services delivery platforms Corporate and Shared Services Reform Program 1

Situation

In response to market evolution and in alignment

with key components of the NSW Government ICT

Strategy, Government agencies are increasingly

considering cloud deployed services as an option

for provision of their ERP system needs.

Whilst a number of benefit types have been

identified through using cloud deployed

applications, there are areas in which the costs,

benefits, risks and constraints are still maturing.

According to Gartner research, most enterprises

currently focus cloud efforts on software selection

and deployment, with limited recognition that the

introduction of cloud services impacts all phases of 1

the application lifecycle .

In response to these considerations, the NSW

Government has led a Cloud Pilot Project, where

several Government Departments have deployed

cloud solutions of various types. One of the pilots,

the Department of Trade and Investment, Regional

Infrastructure and Services (DTIRIS), consolidated

multiple ERP installations into a single cloud

platform using a hybrid solution leveraging SAP

ByDesign SaaS ERP.

This study will supplement the findings of the

Government’s Cloud Pilot body of work by

presenting research and analysis focused on how

deployment model choices can impact the ERP

implementation lifecycle, taking a specific interest

in how the implementation activities link to the

CSSRP.

In the course of their Corporate and Shared

Services Reform (CSSR) journey, agencies will be

making strategic evaluations with regards to their

ERP software deployment model. To support that

assessment, this paper has three specific

objectives:

Provide an overview and definition of the main

trends in ERP deployment models, as

observed in Government. This can assist

agencies in better understanding the options

available and currently used in NSW

Government.

Describe the commonalities and contrasts

between key activities along the ERP

implementation lifecycle, depending on the

deployment model chosen. This aims to help

agencies make informed decisions on which

deployment model to adopt by understanding

the long-term impact of their choice.

Clarify if and how the CSSRP provides

relevant support to agencies shifting towards a

more diverse range of ERP deployment

models.

Post-modern ERP breaks with the traditional monolithic systems approach by accommodating various ERP services regardless of

where they are hosted.

The Impact of the Cloud on ERP and Business Application Planning, Gartner research, June 2012


1

-

-

-

Trends in ERP deployment models

ERP solutions can be deployed utilising a number

of models which broadly take into consideration two

main options for their software: to keep all activities

in-house, or to outsource some or all of their

software or service management. In the context of

these two options, this paper specifically considers

three main deployment models:

On-premise ERP (‘PI’)

ERP as a utility

SaaS ERP

Historically, the model deployed in Government is

on-premise, ‘provisioned internally’ (PI) ERP,

where agencies maintain ownership and control of

service management and IT (model A).

A utility ERP (model B) considers the use of a

shared multi-tenant ERP software instance across

Government, hosted by a service provider. This

model is currently delivered by internal Government

shared service providers, with a number of private

providers considering entering the marketplace.

This is currently an emerging model which may

become a viable solution to address the effort and

risk trade-offs of other models.

Cloud / SaaS ERP (model C) comprises ERP

software deployed via the maturing cloud software

model, in which a multi-tenant instance is

publically available to anyone in the market,

hosted on shared infrastructure. More information

about Cloud solutions is provided in the appendix.

When selecting their deployment model, agencies

should consider their constraints in terms of size,

complexity, and legal / statutory awards, as these

could render some of these models impractical to

use without significant reform.

The CSSRP recognises there is broader range of

deployment characteristics which could be

considered (e.g. greenfield / brownfield on-

premise, public / private / hybrid SaaS), but has

limited this brief to these three models as they

encompass the emerging trends currently

considered by Government agencies.

Note: This document addresses technology

implementation options, but does not cover

business process outsourcing as part of its scope.

A PI ERP

B Utility ERP

C Cloud ERP

Proprietary, unique Bespoke, adapted to Commodity, standard product implementation accelerated by Government needs across market the NSW Government Standard Business Processes

ERP software deployed on Multi-tenant ERP instance Generic cloud ERP instance agency premise, configured configured to industry deployed on public cloud and customised to the specific standards, deployed on private infrastructure, provided ‘as a business requirements defined cloud infrastructure, provided Service’ to the public market by the agency as a utility to multiple agencies with low capacity to customise

Examples include: Departments Clients of ServiceFirst and Model implemented at DTIRIS of Education & Communities, BusinessLink (e.g. Department (hybrid model) Transport for NSW, Justice, of Premier and Cabinet, OFS) and Health


Commonalities and contrasts across the ERP lifecycle

The ERP lifecycle

All agencies are in the process of implementing

Corporate and Shared Service reforms.

Given the specificities of every cluster and agency,

each manages their implementation according to

their unique environment and constraints.

However, the high level steps of that journey and

some of the lifecycle challenges remain common,

regardless of current state and ERP deployment

model chosen. As such the CSSR Program

attempts to support this common journey through

the products and services it offers to agencies, in

particular using the NSW Government Standards

to accelerate business process design.

The CSSRP has set out a generic ERP

implementation lifecycle to serve as a common

framework for discussing implementation

considerations between the three ERP software

deployment models (see next page).

The implementation steps are based on and

informed by Gartner’s typical ERP implementation

lifecycle phases, complemented and enhanced by

each individual agency, the CSSRP experience

and the Accelerated SAP methodology. We have

also consulted tier-1 private sector delivery models

for SAP on-premise, cloud, and application

managed services.

The phases are described at a high-level,

understanding that each deployment model may

require specific activities for each of these steps.

The CSSRP also recognises that in some cases

agencies may select a solution before the architect

phase, which would then inform a more

comprehensive business case.


The table below outlines a generic ERP implementation lifecycle used as the framework for contrasting

deployment approaches in this document:

Phase Description Key activities

Strategise and Plan

Establish the ERP

project and define a

business application

strategy supporting the

alignment of IT and

business

Define business / ERP implementation strategy

Determine ERP roadmap

Develop plans, budgets and high level business justification

Establish project teams

Establish project governance

Create organisational change strategy

Initiate the project

Architect Solutions

Define a practical plan

and design to deliver the

strategy, summarised in

a business case

Gather and understand business requirements

Develop blueprint of business processes

Create organisational change management plan

Define system architecture, technology and standards

Determine project delivery approach

Create detailed business justification

Select Choose the ERP Establish evaluation criteria and methodology Solution software and vendor(s) Go to market for ERP solution and deployment

with the best fit to needs Evaluate service provider responses

determined previously Select preferred solution

Update project financials

Develop implementation plan

Negotiate contracts and terms

Deploy Implement the ERP

solution, managing risks

to successfully deliver

the software to users

Execute organisational change plan

Design detailed business processes

Configure / customise solution

Build integrations

Master data management, migrate / cleanse data

Train key and end-users

Train IT and operations

Establish support capabilities

Test solution (UAT, unit-test, etc.)

Manage release schedule

Operate and Change focus to Manage and monitor the solution

Evolve production operations Manage release and change

and continuously Manage issues and support

improve the solution Install fixes and patches, upgrade solution

Manage continuous improvement of business and IT solution

Table 1 - ERP implementation lifecycle


-

-

-

Regardless of the deployment model adopted, the

implementation lifecycle is common:

Phase A PI

ERP

B Utility

ERP

C Cloud

ERP

Strategise and Plan

Architect Solutions

Select Solution

Deploy

Operate and Evolve

Table 2 - ERP deployment models across implementation lifecycle

Across the ERP lifecycle, some key areas of effort

and significant risk remain regardless of the

implementation model chosen, while other aspects

will vary.

ERP implementations are not only a technological

challenge, the people and process factors are also

critical to a successful journey in any model.

Further specific trade-offs need to be considered

for each deployment model, given the challenges

and long-term implications they involve. Each

agency has to determine their business drivers

and constraints to select the most appropriate

deployment model.

Key variations between ERP deployment models

Each ERP deployment model requires specific

focus on some key activities, due to each model’s

particular characteristics.

The diagram below schematically represents the

key variations between PI, Utility and Cloud ERP.

These comparisons are estimations only, based on

the CSSRP’s knowledge and understanding of the research material used for this paper. While the

placements below offer a general indication of

variations between deployment models, individual

solutions must be assessed by agencies to

determine their specific characteristics.

Figure 1 – Key variations between ERP deployment models

The emphasis in activities for each phase of the

ERP lifecycle is impacted by one or many of these

characteristics. This is further demonstrated in the

following sections, providing an overview of the

commonalities and contrasts between models for

each phase of the ERP.


-

-

-

Phase 1 - Strategise and plan your ERP journey

Phase 1: Strategise and plan your ERP journey

Description Establish the ERP project and define a business application strategy supporting the alignment of IT with CSSR objectives at cluster level

Common risks Lack of clear governance and common understanding of strategy

Lack of experienced in-house resources

Lack of consolidation of lessons learned from other agencies

Business led plan disconnected from IT strategy (or vice-versa)

Change of Government policy impacts strategic direction

Key differences Key areas of support

Key differences in this phase include the degree to Key area of CSSRP support in this phase is which the business may need to adapt to software knowledge sharing, by connecting agencies capabilities, the skills and governance needs in together to leverage learning and content to create both project and operational phases to support a realistic strategy and plan. different types of supplier relationship, and the focus of the cost model in the business case.

Common risks and key differences across the deployment models are highlighted below:

Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Define business Consider which parts of Consider which parts of Consider which parts of / ERP the business need the business can use pre- the business can adapt to implementation custom ERP configured ERP with public generic processes, strategy functionality minimal customisation alignment with some

Determine ERP Number of instances Consider collaboration NSW policies may be

roadmap needed to support challenges with utility required

organisational and supplier to design and Consider impacts to process requirements is deploy your solution business of potential lack a key decision of requirement coverage

Consider strategic changes to IT’s role in a Cloud / Utility environment

Develop plans, budgets and high level business justification

Budgets and business justification cost model typically focus on a large CAPEX outlay for license and initial implementation services, with depreciation, annual software maintenance and support services during operational years

Budgets and business justification cost model typically focus on subscription or consumption costs

Ensure to include a comprehensive view of costs, covering all aspects of implementation, not just the ‘headline’ software cost

Cost shift to OPEX rather than CAPEX may have implications to funding release mechanisms

Establish Consider the in-house Technology skills needs likely to be more focussed on project teams capability requirements vendor performance management than technical

Initiate the to successfully deploy delivery

project on-premise ERP: do skills exist, and can they be released from BAU

Technical delivery skills may be more focussed on internet enabled integrations


-

-

-

Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Establish Ensure governance is Governance structures should be oriented towards project constructed to significant collaboration with ERP supplier, operational governance appropriately manage as well as project/implementation

potential for scope creep triggered by over-customisation offers

Create organisational change strategy

Change management strategy can focus on business units receiving ERP functionality, embarking them on the journey to design the future system

Change management strategy should consider impacts to business end-users, as well as IT and financial teams staff who will manage an ERP in a potentially new delivery model

Consideration should be given to the fact that business teams may be required to adapt to Utility / Cloud solution processes rather than have a fully customised solution

Table 3 - Phase 1 activity contrasts between ERP deployment models


-

-

-

Phase 2 - Architect the ERP solution

Phase 2: Architect Solutions

Description Define a practical plan and design to deliver the strategy, summarised in a business case

Common risks Benefits overstated and costs underestimated in business case

Existing functionality not documented in business requirements

Business process blueprint does not sufficiently leverage existing assets

Lack of early focus on change

Lack of alignment between business and IT


Key differences in this phase exist in the focus of architecture efforts, focus of requirements and blueprint activities, focus of business case, and scope of change management plan.

Key areas of CSSRP support in this phase are the use of the NSW Government Standards to accelerate the business process blueprint for HR / PR / FI, as well as wider support in business process management. CSSRP also offers a market-leading business process management suite (ARIS) to integrate processes with policy requirements, metric and roles.

Common risks and key differences across the deployment models are highlighted below

Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Gather and Definition of business Requirements activities Requirements activities understand requirements and focus on fit / gap analysis focus on fit / gap analysis business requirements

Develop

business process blueprint to be done from the ground up

Focus on differentiating requirements and processes, to determine

Focus on critical requirements and processes, to inform

blueprint of Requirements and scope and cost of where the business will

business business processes necessary Utility ERP need to adapt to Cloud

processes need to be very customising capability and costing of accurate to inform workarounds correct costing of implementation scope and customisation

Guard against any tendency to overlook business process blueprinting promoted by vendor ‘out of the box’ claims

Create organisational change management plan

Change management Scope of change Scope of change typically focusses on management broader: management broader: business units receiving Greater change in IT Greater change in IT ERP functionality skills and financial skills and financial

Change may also be required in IT if

management; Business process change

management, in addition to business process

changing the outsource management scope may change

mix for ERP be reduced if Utility

implementation and processes suitable

support


-

-

-

Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Define system architecture, technology and standards

Architecture focus on defining and designing – from enterprise level down to information and systems, primarily within the enterprise

Architecture focus on assessing compatibility and integration, including outside of the enterprise

Consider potential misalignment with cloud service provider’s project architecture, technology and service quality

Determine Sourcing strategy will Requires strong business Sourcing strategy project delivery need to encompass all and IT SMEs to drive the focusses on service approach of software, process and understand outcomes and metrics

infrastructure and the impact of Utility ERP rather than assets services on the agency

Create detailed business justification

Financial modelling may require additional effort and less familiar approaches, to build a cost model focussed on subscription or consumption costs

Care should be taken not to overlook comprehensive implementation costs through focussing too narrowly on software subscription



-

-

-

Phase 3 - Procure the ERP solution

Phase 3: Procure Solution

Description Choose the ERP software and vendor(s) with the best fit to needs determined previously

Common risks Limited experience in large scale strategic procurement

Inappropriate business and IT mix in the evaluation team

Internal and market pressure on evaluation team

Traditional paper-based evaluation methods may favour vendor sales and marketing capability over software and delivery capability


Key differences in this phase include the focus of Key area of CSSRP support in this phase is the evaluation criteria, scope of procurement, focus knowledge sharing to leverage lessons learned, areas in evaluation, skills for negotiating contracts, connecting agencies facing similar procurement

and contract focus areas. challenges. The list of CSSRP approved industry vendors can also be leveraged as evaluation criteria.


Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Establish evaluation criteria and methodology

Develop model answers to facilitate and standardise service provider response evaluation

Ensure service provider responses distinguish between standard functionality and add-on / enhancement

Consider a broader range of assessment criteria to mitigate risks associated with emerging maturity of market and suppliers including: market readiness assessment, vendor non-functional performance guarantees, significant due diligence of supplier technical and commercial viability

Attention to security, IP protection, liability, licensing provisions which can be hard to satisfy in a multi-tenant environment

Go to market for Requires a sourcing of Will not need to source infrastructure for the ERP ERP solution software, infrastructure platform and deployment and system integrator

Evaluate service provider responses

Challenge to envision a software’s capability given the extent of customisation forecasted

Additional effort to support vendors in providing an insightful demo of their product

Challenges to compare solutions like-for-like when assessing both cloud and on-premise, in particular non-functional and financial components

Care should be taken to ensure a comprehensive view of implementation costs is included in evaluation, and avoid focussing too narrowly on software subscription

Capabilities of solution may be unproven and / or over-estimated given lack of maturity

Consider carefully the Consider carefully the supplier’s capability to potential cost of non-implement non-standard standard processes processes


-

-

-

Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Select preferred solution

Limited vendor pool in Australia

Consider the risks associated with multi-vendors, maintaining products and fit of functional coverage

Consider IT management control will be weaker

Update project financials

Availability of real life case studies to refine business case may be limited

Develop implementation plan

Plan needs to encompass all solution elements including infrastructure and software installation

Greater dependency on third party schedule who are delivering to multiple customers

Limited resource experience and skill base for planning as solutions are relatively recent in the market

Typically a greater range of delivery models available in more mature market e.g. on / offshore

Negotiate contracts and terms

Vendor may entice to pay for technology which is not needed

Cloud ERP contracts can have long-term impacts and require thorough negotiation and formalisation of services

Plan for a typically significant upfront (license) payment reflecting organisational scope and estimated user base and an annual support & maintenance charge

May be harder to lock down scope given unbounded potential for customisation

Assessment and negotiation require a shift in skills / knowledge: increased focus on SLA definition; ‘traditional’ negotiation levers are less relevant; financial modelling needs to focus on subscription and consumption costs

However, may be easier to lock down scope given likelihood of greater proportion of ‘off the shelf’ functionality

Attention to contractual treatment of the potential for mergers between suppliers in the evolving SaaS ERP ecosystem, meaning the selected product could change unexpectedly



-

-

-

Phase 4 - ERP solution deployment

Phase 4: Deploy Solution

Description Implement the ERP solution, managing risks to successfully deliver the processes and software to users

Common risks Customisation needed beyond solution capabilities; gaps not properly costed

Solution does not deliver business requirements

Lack of transformation / change focus, too much focus on technology deployment

Faults in version deployed to users


Key differences in this phase include the focus of Key areas of CSSRP support in this phase are the detailed business process design activities, use of ARIS and the NSW Government Standards removed need to install and test infrastructure and to design detailed business processes, and the application software, and degree to which tools to implement these in the ERP solution. customisation of the software can be achieved.


Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Execute organisational change plan

Establish support capabilities

Change management typically focusses on business units receiving ERP functionality

Change may also be required in IT if changing the outsource mix for implementation and support

Change management effort typically larger

Add refocus of IT roles to vendor performance management

Business change may be greater to adapt to vendor-specified processes

Design detailed business processes

Typically more effort required in detailed process design owing to design flexibility

Typically reduced effort in business process design and configuration, through use of appropriate pre-configured processes

Potential for reduced effort in business process design and configuration where pre-configured processes are available and appropriate

Change impacts may be less well understood in less mature model of adapting the business to the solution


-

-

-

Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Configure / customise solution

Build integrations

Master data management (MDM), migrate / cleanse data

Installation of both infrastructure and software required

Technical activities across all components (reports, interfaces, customisations, extensions, forms, workflows)

Unbounded customisation potential can more easily lead to scope creep and unnecessary deviation from vanilla functionality, potentially impacting future system upgrades and stability

Software and infrastructure installation replaced by providing access to users

Technical activities focus on integrations and data migrations

Remote infrastructure may cause complexities with technical development activities – from ‘front end’ desktop environment to ‘back end’ application domains

Build, conversion and test activities are likely to be dependent on cloud provider schedules and policies

Additional effort may be driven into developing manual workarounds where less mature SaaS offerings do not (yet) have the functionality or ability to support specific business requirements

Assumption is that an Assumption is that a Assumption is that a in-house deployment Utility provider will intend public cloud provider will can support any to collaborate with have limited appetite or customisations required agencies to implement ability to implement (via a systems customisations where agency-specific integrator), but at cost feasible; however ability customisations

to customise may be limited by multi-tenant deployment

Train key and end-users

Investment is typically recommended to develop custom training materials aligned with agency-specific configuration

Training costs may be lower if significant proportion of supplier-provided functionality is deployed, where standard training materials are available

Train IT and operations

Significant training could be required across the whole infrastructure and software stack,

Training needs are likely to focus on software and supplier monitoring and performance management, support processes, and commercial arrangements

depending on the degree of change, and degree to which resources have been engaged who already have required skills

Test solution (UAT, unit-test, etc.)

Manage release schedule

Testing of the full infrastructure and software stack will be required

Testing can focus on functional and non-functional outcomes rather than the underlying technology stack

Remote infrastructure may cause complexities, for example refreshing test data, automated testing tools, problem diagnosis

Activities are likely to be dependent on cloud provider schedules and policies



-

-

-

Phase 5 - Operate and evolve ERP solutions

Phase 5: Operate and Evolve

Description Change focus to production operations and continuously improve the solution

Common risks Lack of knowledge transfer from implementation to operating teams

Limited capacity or capability to deliver enhancements during operations

Workarounds become normal practice if unable to fully meet requirements


Key differences in this phase include increased Key areas of CSSRP support in this phase are the dependency on cloud or utility supplier for support use of ARIS and Business Process Management including monitoring, issue diagnosis and to manage continuous improvement, and the resolution, and upgrades. knowledge sharing enabled by the NSW

Government Communities of Practice.


Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Manage and monitor the solution

Ongoing Total Cost Of Ownership (TCO) monitoring focusses on annual software maintenance, operational staff, and infrastructure costs

Typically significant staff costs to operate and maintain platform

Vendor imposed-license audits can be costly

Costs of switching to an alternative vendor can be prohibitive

Government HR policies may constrain ability deliver efficiency

Plan for ongoing Technology support benchmarking against response entirely SLA public cloud offerings to governed consider migration or a hybrid solution where quality and cost is appropriate

Collaborative relationship may allow for some flexibility in support over and above SLAs

Ongoing TCO monitoring needs to be comprehensive in addition to software subscription/consumption costs

Focus on vendor management skills and governance over technology skills

While SaaS is typically regarded as a less costly solution, it is progressing towards maturity

Ultimately TCO may be higher if staff costs are incurred to work around gaps in system functionality

Though SaaS ERP can be presented as a scalable and flexible solution, agencies should keep in mind such a deployment model removes a lot of their control not only over IT but also over the related business activities


-

-

-

Models

Activities

A PI ERP

B

Utility ERP C

Cloud ERP

Manage release and change

Higher levels of control but greater complexity

Increased dependency on cloud supplier for issue resolution and change release

Manage issues and support

to manage

Higher degrees of customisation typically give rise to higher incidence of ongoing support issues

Install fixes and patches, upgrade solution

Agency responsible for technical upgrades (patch installation, software upgrades) as well as business change

Upgrade complexity and cost can be significant

May have lesser capacity to scale than cloud solutions, and responsibility is in-house

Utility provider may have limited capacity to implement business changes

May have lesser capacity to scale than a public cloud solution, although responsibility lies with provider

Cloud vendor responsible for technical upgrades

Agency typically needs to coordinate regression testing around vendor schedule

Potentially less flexibility to implement business change as dependent on vendor for technology change

Manage continuous improvement of business and IT solution

Retains control over business improvements, based on business processes mapped previously

IT solution improvement may require vendor support to customise

IT solution improvements would be mostly managed by the vendor

Processes carried out in Utility or Cloud ERP may become a ‘black box’ and could impede process improvements for business



Summary of commonalities and contrasts between models

All NSW Government agencies are currently going

through similar CSSR projects, regardless of the

ERP solution and deployment model they chose.

All face similar challenges to define their strategy

and plan, budget their project, select software and

hardware deployment models, manage the

change, and so on.

The CSSRP is set up to support agencies in this

journey. As a central entity, the purpose of the

CSSRP is to help agencies accelerate and de-risk

their reform implementation by consolidating and

sharing leading practices across the NSW

Government.

Engaging with the CSSRP can provide support

beyond the products and services offered – it can

help connect agencies and peers to share their

challenges and lessons learned while going

through their reform and ERP implementation.

These connections can raise awareness about

unforeseen solutions, risks and efficiency gains.

A core offering of the CSSRP remains its Business

Process Management (BPM) discipline support.

CSSRP can accelerate ERP implementations

through the use of NSW Government Standards.

Leveraging the CSSRP’s BPM framework and

definitions allows NSW Government entities to

develop business processes in a consistent way.

The previous section presented how BPM

activities need to be carried out, with contrasts in

effort depending on whether the ERP is deployed

in a PI, Utility or Cloud model. The following

section explains more in depth what are the

benefits of retaining a strong emphasis on these

activities, whatever the model – and what are the

risks of not doing so.


Business Process Management (BPM) – a constant in ERP deployment models

Business Process Management (BPM) is a key

enabler to deliver strategic goals, connect the

entire business and enhance continuous

improvement. Its importance should not be

underestimated.

While the introduction of Cloud applications

changes the way IT is delivered, it does not

diminish the importance of BPM. This section

includes Gartner and Forrester research

supporting the view that BPM is just as relevant for

Cloud or Utility deployments. BPM and ERP

should be seen as a partnership not as

competition to one or the other.

The NSW Government Standards are part of a

NSW Government Business Process Management

Framework. The framework is part of a

comprehensive system for Departments including

technology, tools, methods and templates. It is not

prescriptive with regards to a particular ERP

delivery model.

The ERP processes are not the end-to-end business processes

Business processes provide a holistic view of the

step-by-step activities performed to achieve an

agency’s strategic and reform objectives. While

ERP applications are instrumental to deliver

significant parts of these processes, they can

present two issues:

ERP covers a portion – not the entirety – of a

business process. The end-to-end process may

span a number of applications and human-

performed activities, as shown in the figure

below.

Process steps performed using an ERP may be

implicit – quickly becoming a black box for the

business, even more in the case of Utility or

Cloud ERP where users tend not to gain insight

into the application’s process models.

Figure 2 – Conceptual example of end-to-end process spanning multiple functions and solutions


While outsourcing is not the scope of this paper it

potentially adds a further element in understanding

the complete end-to-end process flow and

identifying the responsibilities of a range of parties

involved with the execution of the business

corporate and shared services.

Mapping business processes helps to gain better

understanding of the wider business,

encompassing the ERP, human interactions and

decision making, negotiations, reviews, etc. This

can be particularly valuable in terms of user

training by enabling users to have a tailored view

based on their role, yet providing them with the big

picture context. When considering Utility or Cloud

deployment, such representation can further help

in identifying whether the application is a fit or not

to the business’ needs.

Using a BPM tool can provide a visual and

integrated representation of processes, facilitating

the overall user understanding. Agencies can

benefit from the CSSRP’s support to map their processes in ARIS – a market-leading BPM tool.

Developing business processes can improve an

agencies’ ability to manage its activities, while using a BPM tool allows users to better visualise

and understand end-to-end processes. BPM can

therefore facilitate an application’s deployment and user adoption in any deployment model, but is also

instrumental in enabling future improvements.

The perception that Utility or Cloud models imply

the application can be adopted along with its

processes may need to address compliance

issues. These models simply move the point of

delivery of the ERP application – but the solution

vendors are not accountable for the business’

processes, and even less for proving compliance

to NSW Government policy.

Your business processes are yours to own,

manage and improve. Agencies leveraging the

NSW Government Standards to design their

processes will be able to demonstrate policy

compliance easily using the policy-to-process

mapping embedded in the Standards.

Category Q: The platform for

accessing the NSW Government

Standard Business Processes.

Please refer to

www.procurepoint.nsw.gov.au


http://www.procurepoint.nsw.gov.au/

Business process management is always owned by the business

Organisations can schematically be structured in

four layers supporting their strategy: business

process management, transaction delivery,

application solutions and platform infrastructure. In

this framework, business process management is

critical to define what the organisation does to

deliver its goals – an activity which can be

supported, but not owned by service providers.

The emergence of Utility and Cloud deployment

models is modifying ERP purchasers’ perceptions with regards to BPM activities. While in a PI model,

BPM is a necessary step to define what the

application should deliver, Utility and Cloud

solutions could be used nearly out of the box,

leading to a seemingly reduced need for BPM

activities. Even in models where the transactions

are delivered externally in a Business Process

Outsourcing model (BPO), the BPM layer should

be retained internally.

Utility and Cloud deployments mean infrastructure,

application, and potentially transaction delivery are

managed by a vendor.

But it should not modify the ownership of business

processes. Agencies not addressing their

responsibility for the BPM layer would then be

adopting their applications’ industrialised services, adapting their business to a solution’s constraints

instead of defining their needs to understand how

application capabilities support these.

Agencies should keep control of their processes to

know what they do, regardless of the deployment

model. Utility or Cloud ERPs might influence

transaction delivery in the agency (how things are

done), but should not impact the business process

management ownership (what needs to be done),

as shown in the figure below.

The CSSRP can support agencies by providing

them with ready-to-use BPM tool, notation rules,

framework and content through the NSW

Government Standards, which can significantly

fast-forward their BPM journey.

While the ownership of business process

management is important to know what activities

are required to deliver and manage the strategy,

the development of business processes has

benefits beyond this planning role.

Figure 3 - In-house and vendor-run layers for each ERP deployment model


This could lead adoption patterns for Cloud and

Utility to follow the PI path: adoption of vanilla

processes, followed by heavy customisations as

business needs evolve. This can make Cloud and

Utility solution upgrades potentially cumbersome

and costly.

Utility or Cloud deployments only move the point of

delivery of your processes, while BPM allows you

to know what you are moving. Agencies improving

and updating their processes during the

application’s lifecycle can keep track of what their

organisation is doing. This can help understand

how many activities remain supported by the

current ERP solution, and can help support a

potential switch in the future as technology options

continue to evolve over time.

Whichever ERP model is used, BPM is relevant to

control, manage and improve business activities.

Most importantly, BPM can alleviate the reliance

on vendors in Cloud and Utility ERP models by

enabling changes independently to the application.

Agencies using the NSW Government Standards

will be able to develop their business processes

faster by leveraging the notation rules and

framework defined for NSW Government, using

the ARIS tool to design and manage processes,

and benefiting from all the content already

provided by the CSSRP for corporate and shared

services functions.

Vendors who are accredited in the NSW

Government Standards will be able to use them in

the acceleration and development of business

processes and alignment with Government policy

and legislation.

The goal is to continuously improve the

effectiveness and efficiency of your

business processes.

This is not achieved by only implementing

new ERP releases according to a vendor’s release schedule.

Business process management enables continuous improvement independent of vendor constraints

Business processes allow organisations to focus

on what they need to do, not how they do it. By

looking away from the ERP application changes,

agencies using BPM can better identify business

needs for change – and act on these.

Leveraging the NSW Government Standards built-

in metrics and policy-to-process links, agencies

can uncover performance issues and quickly

assess the impact of policy changes – all this

through their business processes, independently to

their ERP solution. This is particularly important in

the case of Utility and Cloud ERPs, where such

tasks could become entangled with the application

vendor’s responsibilities if BPM is not used to

provide an overarching view of the business’ activities.

Once improvement requirements are identified,

BPM facilitates implementing these independently

from solution or vendor constraints. Cloud or Utility

ERP evolutions are based on the vendor’s plans

for functionality enhancements and controlled by

their release schedule. These enhancements are

driven by the vendor’s overall requirements and

may, or may not, offer value to the business.

The focus of the business on the other hand is to

be more effective and efficient while providing

better quality products and services to its

customers. Even the ‘best of breed’ ERP systems don’t give the business stakeholders sufficient

visibility into the actual execution necessary to

ensure performance improvements.

BPM helps visualise where and how work-around

activities can be used immediately to implement

process changes required by the business. BPM

effectively can be used as a ‘control-room’ to

complement ERP functionalities.

Utility and Cloud models may struggle with

answering the evolving user needs – specifically to

cover unstructured processes involving

collaboration and decision making.


Summary of findings

The Corporate and Shared Services Reform

Program’s purpose is to support agencies in their

reform journey. With changes in technological

trends and growing options to deliver the reform,

the CSSRP seeks to adapt to agency support

needs and inform decisions relating to their

options.

Based on external and internal research, this

document demonstrated important facts not to be

overlooked when agencies select an ERP

deployment model. The ERP implementation

journey and key activities may be similar, however

each model brings a set of trade-offs and

emphasis on particular tasks.

The contrasts observed between PI, Utility and

Cloud ERP deployment activities are mainly linked

to four key factors:

The extent of customisation available: high for

PI, medium for Utility, low for Cloud.

The impact of change for people: higher for

Utility and Cloud if these models have never

been used before in the organisation, lesser for

PI as it is a model people are used to

managing.

The impact on financial planning: shifting from

Capex and high upfront spend in PI, to Opex

and complex long-term TCO for Utility and

Cloud.

The impact on technology integration: only PI

requires ‘hard’ infrastructure set-up, while with

Utility and Cloud the challenges are more in

‘soft’ areas such as contract negotiations and SLAs.

There is no one solution solving all entities ERP

needs: each agency will need to evaluate their

constraints and requirements to understand the fit

of each ERP deployment model. This document

can help agencies focus on the long-term impact

of PI, Utility and Cloud models.

Research has also demonstrated the importance

of Business Process Management (BPM) in any

deployment model, contrarily to the perception that

Cloud and Utility alleviate the importance of this

activity. BPM helps agencies define, control and

improve the way they deliver their business and

reform strategy, and reduces the dependency on

vendors in Utility and Cloud models. The CSSRP

can significantly support agencies in their BPM

journey through the use of the NSW Government

Standards, providing a tool, notation rules,

framework and content to kick-start their BPM

activities.

The CSSRP will continue to monitor the

developments in ERP deployment models and

agency support needs to ensure the services it

offers remain relevant and effectively help

agencies in the delivery of their corporate and

shared services reform and planning for

postmodern ERP.



Appendix

Appendix A: Methodology

This point of view has been developed

collaboratively and iteratively, building on the

knowledge and experience of both the private and

public sectors.

A generic Government agency CSS reform and

ERP implementation journey was defined at a

high-level based on the CSSRP experience,

agency feedback, and private sector leading

practices. A range of ERP deployment options was

then selected for review based on trending models

currently observed in NSW Government. For each

of these deployment options, this paper describes

the main elements of effort and risk for an

implementation journey, helping agencies consider

the long-term implications of their ERP strategy.

The ERP implementation information provided in

this paper has been sourced from recognised

external analysts (e.g. Gartner, Forrester), cross-

referenced with feedback and lessons learned

from public and private sector projects.

Workshops were carried out to collate opinions

and feedback from agencies, validating external

research and consolidating CSSRP’s point of view for Government.

Finally, this paper discusses where and how the

CSSRP can accelerate and de-risk agencies’ implementation based on an effort and risk

analysis.

The CSSRP support can be either specific to a

single ERP deployment option, or common to all

models.

Appendix B: An overview of Cloud

Cloud, Software-as-a-Service (SaaS),

Infrastructure-as-a-Service (IaaS), Platform-as-a-

Service (PaaS), Business-Process-as-a-Service

(BPaaS) are terms broadly used across business

and IT departments, and without some level of

clarification may be subject to confusion in what

each refers to (Figure 4).

The ‘cloud’ is a set of computing elements where

shared resources such as processing power,

software applications and data are provided to

consumers (individuals or businesses), on

demand. Cloud allows customers to access

scalable and elastic IT capabilities through web

services, on computers and other devices.

In this paper, ‘cloud’ encompasses SaaS solutions

only. SaaS is software that is owned, delivered

and managed remotely by one or more providers.

The provider delivers an application based on a

single set of common code and data definitions.

This application is consumed in a one-to-many

model by all contracted customers anytime on a

pay-for-use basis, or as a subscription based on

use metrics.


Figure 4 – BPaaS / SaaS / IaaS / PaaS definitions

Cloud services can be implemented in three main ways: using the public internet to deliver the services

(Public cloud), hosting the software and hardware internally (Private cloud), or a mix of both (Hybrid cloud).

These different types of cloud offer a range of solutions for customers to select based on their priorities and

requirements.

Type of Cloud Typical features of the Infrastructure Benefits and drawbacks

Private Cloud

Private clouds are the implementation of the same virtualisation and IT automation technologies used in public cloud on internal (business owned and operated)

hardware and software.

+ Private clouds benefit from maintaining complete control and security within the organisation.

- Private clouds do not usually gain the economies of

scale and still require upfront capital investment.

Hybrid

Hybrid clouds blend internal capabilities (private cloud) along with subscriptions to some capabilities from a public cloud. This is the rapidly becoming the most common

implementation in the current market.

+ Provides a scalable infrastructure for non-core apps, while retaining control of data.

- Introduces additional complexity and the retention of in

house services often constrains possible savings.

Public CloudPublic cloud is the provision of services via the public internet. Different levels of services (IaaS, PaaS, SaaS) are all provided as pay per use.

+ Leverage of highly scalable vendor infrastructure allows for rapid deployment and agile response to changing demands.

- Potential for vendor lock-in, increased data risk.

Figure 5 - Types of cloud

Given the well published challenges with historical ERP implementations, cloud has been pinned as the next

silver bullet solution. However, moving to the cloud is not a simple ‘lift and shift’: it still requires transformation

in both business and IT. Steps such as process re-engineering, systems migration and structural changes

should not be overlooked. The journey into postmodern ERP will tend to shift the focus to ‘as a Service’ as the market matures. Postmodern ERP will involve multiple solutions rather than the traditional monolithic or single

provider environment.


Appendix C: Sources

Gartner report - The Impact of the Cloud on the ERP Select Life Cycle Phase (Sept 2012)

Gartner report - The Impact of the Cloud on ERP and Business Application Planning (Jun 2012)

Gartner report - Private Cloud Computing: An Essential Overview (Nov 2010)

Gartner report - The Five Phases of an ERP Project: How to Start the Strategy and Planning Phase (Nov

2012)

Gartner report - The Impact of the Cloud on Architecting an ERP Solution (Aug 2012)

Gartner report - Life Cycle Guide to ERP Research, Update 2012 (Aug 2012)

Gartner report - SaaS ERP Only Reduces Part of the Effort Needed to Implement and Operate Your ERP (Feb 2011)

Gartner report - ERP/Business Applications and the Public Cloud: A Life Cycle Assessment Methodology and

Key Focus Areas (Jan 2012)

Gartner report - An Easy Way to Understand the Relationship Between Cloud Computing and SaaS (Aug 2011)

Gartner report - CIO and ERP Leaders' Guide to Gartner's Cloud Computing Definitional Research (May 2012)

Gartner report - Best Practices for Managing Integration in a Hybrid Cloud and On-Premises ERP World (Jun

2013)

Gartner position - BPM Is Critical for the Adoption of Applications and Business Processes in the Cloud (Jun 2012)

Forrester report - Innovative Technologies Will Drive Enterprise Applications and ERP to A Bright New Future (Jun 2011)

Forrester report - The State Of ERP In 2011: Customers Have More Options In Spite Of Market Consolidation

(May 2011)

Forrester report - SAP In The Cloud: Market Update And Lessons Learned From Early Adopters (Dec 2011)

Deloitte report - Pragmatic Cloud Computing: Six keys to successfully using the cloud (2012)

Deloitte report – Cloud computing myths vs. facts (Mar 2013)

Gartner Predicts 2014 – The Rise of the Postmodern ERP and Enterprise Applications World (Dec 2013)



Date post:	22-May-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Perspectives on emerging trends in Corporate and Shared ...€¦ · Table of Contents Foreward...

Documents