When you first implement your ERP system, it is important to recognise that there will be updates in the future.  Careful planning right from the beginning will help avoid major problems deploying these future upgrades.

At the outset, a well organised ERP implementation will involve a project team.  The size and shape of the team and its members will depend on the size of the company, the scope of the project and the skill levels of the individuals required.  It will normally comprise of at least a project sponsor (generally the CEO, CFO, or other director), a project manager and one or more department heads.  The vendor will generally be represented also on the project team with one or more staff members.  It is important that documentation as to the structure of the project is maintained.  This will act as a reference point in the future where an upgrade project is undertaken.

Pre-planning for future upgrades can start at any time, but the best time to do so is at the very outset of the initial project implementation.  Quite simply, this will have an impact on the direction of the overall implementation.  A number of factors should be considered:

Infrastructure

What deployment method has been chosen for the implementation (on-premises, cloud, hybrid?)  When choosing the deployment method, think about not just what suits for now, but what does the future look like?  If you go with, for example, an on-premises solution now, how difficult will it be in the future to move to a cloud model?  Or vice versa?  In our experience many companies install an on-premises solution for various reasons (poor internet connectivity at a remote location, for example) but intend to migrate to a cloud hosted solution in 2, 3 or 5 years time.  With EFACS this is not a problem as the entire system is browser based.

Upgrade type

No two upgrades are exactly the same.  There are regular software “updates” which are designed to fix issues identified to the author over time and there are software version upgrades, typically issued every 12 to 24 months.  While all vendors recommend that you try to stay on the latest version where possible this is not always practical.  Sometimes even a version upgrade can be relatively minor, whereas other times it can involve complete rewrites of modules or key functions.  Each time an upgrade is released an assessment should be made as to whether or not to deploy it.  Factors to consider here include:

• Is this a major or a minor upgrade?
• How long is it since we last deployed the latest available upgrade?
• Does the new upgrade contain functionality we actually need (review release notes?)
• Does the new upgrade address potentially serious security concerns?
• What is the cost (financial and business disruption) and does the return outweigh this cost?

Customisations

Many ERP implementations will involve at least some element of customisation.  This may be simple reporting tweaks or it may be much more involved workflows, custom applications or validations built right into the software.  There is the potential for these customisations to cause issues when upgrading.  If there is going to be any significant customisations used in the new system, it is best to plan for a development or test environment from day one.  This does not need to be a huge or costly thing – most systems can use a much scaled down server or even virtual machine for a test environment.  Then when a new upgrade is available, it can be deployed in the test environment, fully tested, tweaked if necessary before going live.

Of course, where possible it is always best to avoid customisations.  This is not going to be possible in all cases but generally there will be people asking for a report to be rearranged to suit their preference, or for some element of customisation that is not strictly necessary.  Every customisation request should be deeply considered before being approved.  Unless absolutely necessary, ensure all customisations are delivered via the ERP system’s inbuilt customisation tools.  At all costs, avoid author bespoke unless it is supported and will be upgraded automatically by the author as new versions of the software are released.  As a general rule of thumb, the less customisation there is, the easier the migration process will be.

Training approach

The initial software implementation will involve training – both at project team and end user levels.  The structures used for training should be documented and maintained.  These can be used again when it comes to deploying upgrades.  The training room setup, the training environment, who conducts the training session, who should attend, the equipment used and the training documentation are all part of the consideration here. There really is no need to re-invent this for every upgrade.