NI Water recently became the first organisation in Ireland to successfully upgrade to Oracle’s eBusiness Release 12. Alan Stewart, Colin McGuckin and Keith Scott explain the ten key steps organisations contemplating a similar upgrade should consider.
Oracle 11i e-Business Suite extended support ceases in November 2013. With only a year to the deadline, users of this system need to be considering moving to Release 12. NI Water uses Oracle Financial, HR, Payroll and Asset modules and has recently upgraded to Release 12.
STEP 1 : Decide on your approach, plan your upgrade, secure resources and get the core project team in place
The most important part of any implementation is the planning stage. The first decision for any organisation is whether to upgrade or re-implement. Upgrading uses predefined Oracle supplied scripts to migrate the system to the next version.
Re-implementation provides organisations with the opportunity to redesign their Chart of Accounts or significantly amend business processes. Re-implementing will require significant data migration activities as General Ledger Balances, Open Orders and Invoices and other documents will need to be extracted from the legacy system and then loaded into the re-implemented system.
A high proportion of organisations will decide on upgrading as it is likely to be a faster and more cost effective option. Once re-implementation or upgrade is chosen, it is important to put together a strong core team of system professionals, with representatives from all user groups.
This ensures that all business processes are covered, indeed new ideas for enhancements can most often come from the users operating the system every day.
STEP 2: Review functionality and identify existing problems that need solving
As discussed in step 1, a key area to consider whether upgrading or re-implementing is to take the opportunity to review any functionality the new system offers or identify any processes that need to be improved or introduced.
Areas to consider include:
- the benefits of new functions to your business;
- the ease at which the organisation can implement, use and integrate the new functionality;
- the ability to integrate into current business processes; and
- the capacity of new functionality to facilitate the removal of any customisations.
These questions are all important to ensure that new functionality is going to be utilised efficiently and not just added as a feature because it is available. All new releases of software may provide fixes for issues that have been highlighted by other organisations over a period of time.
STEP 3: Get the system through a first build or upgrade with no enhancements as soon as possible
It is helpful, especially when upgrading, to get your system through the process as quickly as possible with limited or no customisations. A user testing environment, termed a Conference Room Pilot (CRP 1), will allow you to:
- estimate the time it will take to put your system through the upgrade process;
- provide a test system with your data to show to users and gather views; and
- identify areas that may require significant change management or training. CRP1 is essential for the initial testing, starting with the most important processes that are carried out on a regular basis. It is helpful to have testing scripts (step-by-step guides) available as they can be reused throughout the project.
End users from specific teams (e.g. General Ledger, Procurement, Payroll) can now begin to assist the project team with testing and gauging the initial look and feel of the system.
STEP 4: Review all customisations and identify changes that are required
Most organisations will have system customisations that have been developed over time. These will normally have been designed in conjunction with the IT team or by the service provider to meet the individual needs of the organisation.
As these customisations were designed and built for 11i, they must be reviewed for Release 12 for three reasons:
- to determine if Release 12 provides any new functionality that would mean they are no longer required;
- to assess if Oracle may have introduced table or data changes which may result in your customisation not working as planned; and
- to establish if the customisations are fit for purpose in Release 12.
Any issues can then be identified early in the project and plans agreed to develop new customisations or amend others.
STEP 5 : Review your reporting and identify problems for resolution
As with customisations, there is a risk that underlying table changes will impact significantly on your reporting solution. This is particularly the case at Release 12 as Oracle has significantly changed the General Ledger with the introduction of Sub Ledger Accounting Module (SLAM).
Every accounting system will have linkages to a reporting tool – whether it is the accounting system’s own reporting tool, an external reporting tool from another organisation or indeed an in-house reporting tool. Reporting can be a complex area, especially for organisations that have statutory and regulatory reporting requirements. It is therefore essential that current reports are tested against the new release as soon as possible. This can be carried out in parallel with the system process testing and CRP1 is a useful starting point.
The opportunity should also be taken to review your suite of reports to agree and refine reporting requirements with the business users – assisting the organisation to work smarter, not harder.
STEP 6: Carry out a second build upgrade with customisations and new functionality
A second Conference Room Pilot (CRP2) is a subsequent upgrade of the live system but with the added overlay of the organisation’s individual customisations and enhancements. Such customisations and enhancements should be built in to this upgrade test system and be available to the project team and users to ensure that full end to end testing can take place.
A thorough testing plan should be put in place for this period to ensure that each business process is looked at rigorously.
STEP 7: Get buy in and commitment to testing from business process users
Involving business process users is critical to the success of the project. While the project team in place may be knowledgeable about all aspects of the systems, testing is better carried out by those who use the system on a daily basis. Users are the people who know their side of the business intimately and may have ideas on how to make the system or process more efficient. They may also have specialist knowledge on certain areas or new processes available, e.g. online tax returns, treasury and linkages with banking systems, BACS and CHAPS processes.
STEP 8: Focus on system delivered outputs
One of the most important aspects of accounting in conjunction with day to day transaction processing is system delivered outputs, many of which involve third party interaction. Some examples of outputs are:
- Cheque prints;
- Purchase orders;
- Accounts Receivable Invoices;
- Payroll Payslips;
- Payroll BACS transmissions;
- Bank Statement Loads;
- Tax requirements.
All of these outputs need to be robustly tested as many will be critical processes. It is essential to secure input from third party suppliers e.g. BACS processing centres or third party payroll suppliers to fully test from end to end.
This also provides a good opportunity to work with third party suppliers to try and improve the processes and take advantage of their experience in delivering similar outputs to other organisations.
Oracle has made significant changes to the underlying technology which delivers these outputs. During the upgrade at NI Water this area caused the most difficulty.
STEP 9: Final dress rehearsal of upgrade prior to go-live
It is imperative to undertake final User Acceptance Testing (UAT) of the system, i.e. the testing time where final end to end testing takes place and final management decisions are required on the chosen system.
It also provides the final timeline for the live upgrade or implementation. This will include days required for database administrators from the third party or internal IT to undertake their necessary configuration. A trial run should take place of the transition processes from the legacy system to the new system to determine how long the transition will take and refine timings.
STEP 10: Prepare for handling post go-live issues
Once you have completed your upgrade or re-implementation of the systems, the final stage is to handle post go-live issues. It is unlikely, no matter how good your testing has been, that you will have covered every scenario and fully tested every small part of the system. You may have decided to go live with some minor issues from UAT not resolved. Bugs and issues will come to light at this stage and you need to be prepared to deal with these with your service provider/IT team.
Organisations embarking on a move across to Release 12 should consider a range of areas outside the above. With careful planning and project management, it is possible to successfully move across to Release 12 in a controlled way.
Alan Stewart is Head of Financial Systems at NI Water (email@example.com); Colin McGuckin, MEng is a Senior Systems Accountant in Financial Systems at NI Water (firstname.lastname@example.org); Keith Scott, ACA is Business Performance Manager at NI Water (email@example.com).
NI Water is responsible for the delivery of water and sewerage services in Northern Ireland servicing an asset base of £8 billion. It is one of Northern Ireland’s largest companies. The Company and its predecessor, DRD Water Service, have undertaken successful upgrades and a reimplementation of the Oracle E-business suite since 2001, with the support of its service provider, Fujitsu.
This article was originally published in the December 2012 issue of Accountancy Ireland.