[If you missed Part 1 Blog: Is it Time?]
Oracle provides overview documentation that lays out the upgrade process, sets expectations for their Cloud clients and provides information on new features and functionality that are included in the new release.
Pay particular attention to:
- R10 Upgrade Planning Document 072015
- R10 Financials What’s New
- R10 Business Intelligence for Financials
- R10 Oracle Common Tech UX What’s New
We also recommend that you review Functional and Technical Known Issues documentation for R10.
Other documentation that you may want to review includes:
- Release content documents (RCDs)
- Spotlight videos
- What’s New guides for other applications
- Product documentation
Four things you should do before starting the upgrade process:
- Preserve all custom Business Intelligence (BI) and Financial Reporting Studio (FRS) reports. Store them in the folder labeled Shared Folders>Custom. Otherwise they will be overwritten by the upgrade.
- Publish sandboxes to preserve any customizations that you want to save before the upgrade. Delete those that you are not going to publish.
- Close any open accounting periods in the sub-ledgers and general ledger, run the reports, and reconcile general ledger account activity and balances. Emtec advises all Oracle ERP clients to complete this process as part of each accounting period close.
- Run a few key financial reports, maybe one from each sub-ledger application, just prior to the upgrade. Then run those same reports again right after the upgrade and compare the reports to ensure the upgrade did not have a negative impact on the financials. Any significant differences should be investigated and resolved.
One item to note: you should determine if an environment refresh is needed before upgrading your Test environment. This will give you recent Production data for testing after the upgrade. It takes several weeks for Oracle to perform the refresh after being requested, so plan accordingly. Alternatively, you can provision an additional test environment to use for the upgrade. Again, plan ahead as this takes several weeks for Oracle to deliver a new test environment. There is additional cost for another environment.
Change Control Process
Emtec recommends that all Oracle ERP clients establish a change control process to be followed when making any changes to the Oracle applications. This process should include and enforce change documentation requirements and that the business users have successfully tested the change, recorded their test results, and signed off on the change before it is deployed in Production.
When the Oracle Cloud applications were implemented, documentation should have been created to capture the original setup and configuration of each application including any RICEW (Reports, Interfaces, Conversions, Extensions, Workflows) deployed. If not, we suggest you take this opportunity to go back and use the change control process to establish the documentation for those changes. Deployment documentation for the setup and configuration of the applications and the RICEW items function as input to the development of the regression testing suite of test cases.
Regression Testing Suite
When completing a release upgrade, as well as any other system change (e.g. monthly update patches) it is important to thoroughly test the system and all applications. Each Cloud client should build a suite of test scenarios and test scripts for regression testing of their Cloud applications. The test cases should address all standard Oracle functionality being utilized in each of the applications. The test cases should also address testing any RICEW (Reports, Integrations, Conversions, Extensions, and Workflow) components that have been built and implemented.
Some examples of RICEW items we test as part of our upgrades:
- Custom BI, FRS, and Smartview reports
- Banking integrations, Payment formats, and approval routing workflows for expense reports
- Invoices and journal
Having a strong Regression Test plan is critical since it will be reused multiple times in the future. You should already have one from your initial implementation but it may need updating or additional detail. A good System Integration Testing or User Acceptance Testing plan is the road map and the starting point for the regression testing suite you will use at each release upgrade. Build other test cases around the basic test plan to cover all functionality being utilized and any changes that have been deployed since go-live.
Assemble your Upgrade Project Team
Although significantly less effort than a traditional, on-premise application upgrade, upgrading Oracle Cloud (previously Fusion) applications still requires effort and dedicated resources to execute successfully. Ideally, you want some people on the team who have been through the Oracle Cloud upgrade process previously and can help guide the team. You will also need people who have experience and expertise in all of the applications being utilized. They will be able to identify any issues and verify functions far better than any outsider or generic Oracle expert. You also want in-house Oracle Cloud IT resources involved in the project to assist with anything to do with the specific setup and configuration of the ERP system, the applications, and any RICEW items that have been developed and deployed.
A seasoned Oracle project manager is essential to develop the upgrade project plan and timeline, ensure effective communication and keep everyone on the same page with regard to assigned tasks and due dates. An Executive Sponsor should be identified for the project to give it the high-level visibility needed across the company. Leaders of the Business areas that utilize the Oracle applications should also be put on the project team as sponsors and supporters of the project.
Last but not least, the Oracle Success Manager should be a key member of the upgrade project team to provide escalation of critical issues within the Oracle Support organization to expedite resolution. There will be some issues that you are not able to solve in-house since these are Cloud applications. Only Oracle has access to make some technical changes or bounce Cloud services and environments. It is critical that you have someone aligned with your organization and project from the Oracle Support team to ensure they are diligently working to resolve the issues that will make your upgrade a success.
Develop the Upgrade Project Plan
The typical upgrade project will last 3 to 6 months. The longer interval may be necessary if you have not previously built the regression testing suite and gotten your change documentation together. Every time you go thru the upgrade process, you should get better at doing it and be able to reduce the duration of the project. You can use the monthly patch updates as a kind of mini upgrade and use them to help you build a repeatable process that can be used for the larger point release upgrades.
While developing the plan, start outlining the post-upgrade steps. These post-upgrade steps are unique to your company, depending on applications and services being utilized, application setup and configurations, RICEW items implemented, and items that are being impacted by the new release that you want to validate.
A few of the steps found in a typical Release 10 upgrade include, but are not limited to:
- Confirm BI and FRS Reports are working; also confirm standard Oracle reports are working
- Run audit control reports and compare to same reports ran prior to upgrade
- Confirm application setups upgraded correctly
- Confirm new R10 landing page is working correctly
- Run integration processes and ensure files are loading from UCM
The project plan should also include key communications (these can be drafted during the planning phase to be ready to send out at the appropriate time).
Don’t forget training- identify any user training that may be needed on new or changed functionality, and provide for its development and delivery.
Build the Upgrade Test Strategy
The overall strategy for testing should be to run all test cases in the regression testing suite before applying the upgrade, to set a baseline for comparison. You will repeat the same set of regression testing after the R10 upgrade. The focus should be on the RICEW items and any suspect items reported as issues from others who have already applied the upgrade. It shouldn’t be necessary to pre-test “normal” functionality that the users are familiar with and do not need to further document as a baseline.
Create columns in the regression testing suite tracking document (spreadsheet) for the core team tester and the business tester for each test item, status (Pass / Fail), and comments. Assign the appropriate resource from the core team and business area to each test case.
One key thing to remember is that it will usually take a business tester twice as long to complete the test cases as it does the core team member because the business tester has their regular job to perform in addition to the testing. Schedule accordingly.
Stay tuned for Part 3 of our ERP Cloud Upgrade blog series. Have questions? Comment below or send us an email to email@example.com.