e-Commerce, change management, project & programme management, it, logistics, supply chain & retail
Current Trends in ERP Implementation Part 2 - An Analysis from Big i Consulting
Part 1 examined the move towards agile methodologies in ERP implementation and discussed the issues resulting and a review of costs and business benefits
In part 2 the strategic decisions around starting an ERP programme are discussed and suggestions for choosing the software and implementation partner are made
Current trends in ERP implementation methodologies have some important considerations for businesses who are taking this important step. Although each ERP has its own methodologies they are increasingly converging in their route to delivery, with differing names describing similar methodologies.
These methodologies have implications that senior business managers need to consider during the initial phase of the project, before the ERP or implementation partner (or systems integrator depending on your terminology) is chosen.
Strategic Planning
Before selecting software and suppliers a strategic plan for the programme needs be prepared. A good template for this planning is the Prince2 Project Initiation Document. As well as following the Prince2 template the following areas deserve greater attention.
Governance Structures
Consideration should be given to the programme governance structures to be used throughout the programme. As discussed earlier Prince 2 provides an excellent model. The relevant structures need to be decided upon and there is a benefit to having some, if not all, of the governance structure operating early in the programme.
The following governance areas deserve greater attention.
Risk and Issue Management
During the strategic planning phase, several risks and issues will be identified and early documentation and management of these will deliver greater clarity for the programme as a whole.
Change Management
Traditional change management structures concentrate on change requests that come from within the programme itself. Business change also happens outside of the programme and can often have a direct impact on the programme.
A governance structure for overall business change is beneficial and key members of the programme team should be part of the business change governance structure. In businesses undergoing significant change away from the ERP programme putting this in place early is recommended.
Project Quality
A structure, individual or mechanism to ensure project quality is recommended. The reporting for QA should be outside of the normal reporting channels within the programme, reporting directly to a senior executive sponsor or steering committee.
Gap Analysis
A traditional approach to the early planning of an ERP is a gap analysis.
‘Where are we now, and where do we want to be?’
The strategic requirements which are driving the ERP programme, wherever possible, should be broken down into a number of gaps and each gap reviewed with a view to changing the business process to reduce the gap before an ERP programme is started. Experience demonstrates that it is far easier to implement an ERP with a view to streamlining existing processes, delivering efficiencies, than it is to implement new processes simultaneous to the introduction of an ERP. This methodology also minimises both overall solution risk and cutover failure risk.
There will often be the requirement for new capability (or process) to be delivered by the ERP. In these circumstances, operational requirements frequently change as the business’ view of what it requires evolves. Until the business has visibility of how the ERP delivers the capability, the business will not be in a position to grasp its exact requirements. This becomes an iterative process. Agile methodologies work well in these circumstances but come with a risk of cost and time uncertainty.
There will also be areas where the business is unhappy with the current state but does not know what the final state requirements will be. Business reporting is a typical example of this area, which is why it is often problematical:
The current reporting landscape represents the capability of the business (and its systems) to deliver reporting that informs or dictate business responses to situations (within the current capability of the business and its systems). The capability of the ERP is unlikely to be known until later in the programme and hence the reporting requirements are unlikely to be known until then.
For these kind of situations, it would be better to consider them as separate but necessary projects within the wider ERP programme and for them to be specified and cost justified when the overall capabilities of the ERP are clearer. In the example of reporting, care needs to be taken within the overall programme scheduling to ensure that key business reports can be defined earlier within the programme timeline and less important reports considered for post go-live developments.
Business Change Velocity & Complexity
The rate of change within a business and the complexity of that business add risk to programme cost and time overrun managed by waterfall methodologies
Rapidly changing businesses are frequently the ones that have the most complex landscapes which results in difficulty in choosing the correct methodologies for the programme. Complexity management favours waterfall, change management favours agile. A business should examine its strategic goals and look to find a window of greater stability in which to deliver an ERP programme.
Resourcing Requirements
As part of the development of the business case a strategic review of resourcing requirements needs to be undertaken to determine what resources will be required and when in the programme they will be required. A strategic resourcing plan should be produced to complete the business case, highlighting the requirements for both internal resource, external resource or service delivery partners.
It is important to understand the experience of the existing teams within the business. Either look to bolster those teams with greater experience or release team members to the programme and back fill the members.
As well as needing business expertise to be allocated to the programme there are requirements that are needed to deliver the programme. Programme and project managers, project QA and other roles.
The following key areas need consideration and experienced resource or specialist service partners should become part of the strategic resourcing plan.
Testing
Testing in business is often viewed simply as the testing users perform to validate the system: user acceptance testing. The scope of testing is much wider, encompassing many disciplines such as static testing, data testing, systems testing, systems integration testing and non-functional testing.
It is recommended, where a business does not have deep testing experience of ERP, to engage with a testing service provider (or experienced testing professional) at this stage in the programme to discuss requirements and options.
Thorough testing provides confidence and assurance that the ERP programme will deliver its desired outcomes for the business and is fit for purpose and reduces programme risk.
A strategic testing plan is useful addition to the business case.
Data Migration
Where a business does not have an existing master data function data migration is likely to need dedicated resourcing. Consideration should be given to the current location of the business and financial master data and the controls already in place to maintain quality and the number of places the data is replicated.
Resourcing requirements typically include an IT resource for data extraction, technical experts to manage the data migration and transformation processes and a competent specialist to manage the process.
A strategic data migration plan is a useful addition to the business case.
Training
Training models should be considered in the light of business maturity in delivering training to the user community. Typically, an ERP implementation partner will offer a ‘train the trainer’ model, but this may not be appropriate for the business requirements.
It is recommended, where a business does not have previous training experience of ERP, to engage with a training service provider (or experienced training professional) at this stage in the programme to discuss requirements and options.
Successful training delivers a user community able to make rapid use of the delivered system and reduces the time where system change causes inefficiencies.
A strategic training plan is a useful addition to the business case.
Budget Planning
Budget planning at this stage is a useful part of the strategic plan. Although there will still be many unknown elements, not least of which is ERP and implementation costs, the previous aspects of the strategic review can be used as the basis of an outline plan.
Consideration should be given to the likely methodologies for different areas of the programme and the analyses around complexity and change to ensure sensible tolerances in the business case are in place.
The greater the detail available at this stage the more robust the business case for the programme will be.
Choosing the ERP and Partner
It is an important point to consider when selecting an ERP and implementation partner that ERP providers are in the business of selling software, licences and support and that implementation partners are in the business of selling services, support and often licences.
Use the Strategic Planning
Use the strategic planning in discussions with the implementation partners (who typically specialise in one ERP) to find the closest match to your business’ requirements and strategic plans. Typically, the partner will bring a pre-sales team to presentations but it should be a requirement that a solution architect is present in all the discussions and should contribute significantly to the discussion around the capabilities of the ERP solution without customisation. Look for close match not just in requirements terms but also in the following areas:
- Project management methodologies. Do these meet your strategic needs and environment?
- Capabilities. Do these capabilities fill any of the gaps in your in-house expertise?
- Governance. Does this complement your governance requirements?
- Costs. How competent is their costs analysis compared to your budget planning? Are their arguments realistic and compelling?
- Resourcing. What is their resource model; in house staff or contract experts?
- Previous experience in delivering the ERP version into your business sector.
Partner Planning
Once shortlisted it is important to have a detailed understanding of a proposed partner’s overall expertise in the actual version of the ERP software you are deploying. As previously discussed current trends are diverging from previous versions and the methodologies so some of the tools a partner may use to deliver a proposal may not be relevant. Visit reference sites without a chaperone from the partner.
It is also important to meet the actual teams that will be implementing the ERP and not just the pre-sales teams and to have open discussions around the risks and issues identified within the strategic planning to understand how these can be managed.
Licencing Complications
ERP licencing is often highly complex and the actual licence requirements of differing users, equipment and connected systems are subject to interpretation and negotiation. It may be worth engaging a third-party licencing specialist to assist with the negotiations and to consult legal counsel for the relevant legal interpretations before committing to licence cost.
Typically, deals will be available for buying the licences early and in the volumes that will be required for the landscape post implementation.
Consideration should be given to only buying the licences you need to run the ERP programme and re-evaluate licence requirements closer to implementation. Should the programme fail or significantly over-run early licencing discounts for volumes not needed will have been an unnecessary cost.
Design Decisions and Environment Considerations
ERP solutions are moving to cloud based services. It is important that partners can credibly explain the differing options around environments and types and prepare a realistic plan for the environment requirements (and typical costs) for the lifetime of the programme through to the post implementation landscape.
It is important to understand what the extra costs of the environments are in terms of both the hardware (or cloud costs) and configuration and set up costs. It is worth considering flexing your environmental needs based on cloud architecture during the programme. Examine the cost differential between always on offerings compared to pay by the minute offerings. A localised project with development effort in the same time zone rarely needs a development environment to be in operation 24 hours per day.
Resourcing & Budget Re-Planning
As a short list of partners and ERP solutions crystallises the resourcing requirements and budgeted costs will become clearer. Redo the exercises from the strategic planning and re-examine the business cases for the final shortlisted partners and solutions selected before any decision is made. Should the estimate ranges from the partner be too wide, look to discuss arrangements where the risks and rewards are shared with them.
Legal Counsel
Ensure all contracts and schedules are examined by legal counsel as a standard ERP or partner contract will be heavily weighted in their favour. If necessary proceed on the basis of a letter of intent until the legal documents have been amended and approved by all parties.
Summary and Conclusions
The current trends in ERP implementation methodologies and tools, dictated by the software vendors, place a great deal of power in the hands of the software vendor and the implementation partner. The risks associated with this are project overrun in terms of time and budget.
Although business benefit can be realised early within the programme for relatively simple landscapes, complex landscapes need careful preparatory and planning work performing before any discussions with vendors or partners.
The opportunities for recovery of failing programmes are diminishing with poor (or lacking) early strategic decisions dooming a programme to failure. Recovery is increasingly difficult as reversing poor decisions often requires significant programme rework and possibly even a re-launch. Since businesses are frequently loss averse this can prevent failures from being rectified early and leads to inevitable programme failure after further overrun before there is an acceptance that an intervention needs to be made.
Thorough preparatory work is the key to improving the chances of programme success and businesses need to ensure suitable expertise is available to both manage and contribute to this process.
A simplified chart showing typical programme overrun caused by business change requiring re-planning. Two re-planning instances are shown here but there could be several and it is possible a programme may never complete.
