In continuation of our blog series on Oracle Procurement Cloud, this week I will share my experience on the support model for Cloud ERP. For more information you can read our earlier blogs on the go-live, implementation speed, structural flexibility and Setup.
One of the key characteristics of Cloud is that the application is hosted off premise (either public or private cloud). The client is no longer burdened with managing the infrastructure of its ERP system. This new way of working has a great deal of consequences for implementing and supporting the system.
The most important outcomes are listed:
1 How to monitor my environments?
The first thing you see when you gain access to Oracle Cloud ERP is the service dashboard. In this useful overview you see all the technical details of your instances, including any planned maintenance that causes downtime of the system.
From this dashboard you can also gain an overview of all the different applications that are hosted (for example both test and production). The dashboard functions like a web landing page, but it is also possible to go straight to the ERP application without accessing the dashboard. It is mainly used by administrators to get a quick overview of the status of the system.
A few examples of information shown on the dashboard:
- Data center: which center is your application hosted?
- Version number: which version is your system currently on?
- User logins: how many (unique) users have logged into the system?
2 Patches & upgrades: how does it work?
In the past, the user was responsible for keeping the environment up to date with the latest patches and upgrades. Based on my experience, it often happens that due to multiple reasons either the environment is not updated thoroughly and several patches are missed out or the environment is still running an old version.
Oracle Cloud has made this task simpler where several different patches are installed on a frequent basis; below are the key areas:
- First, there are monthly and quarterly updates. Both updates can either contain bug fixes but also the latest adjustments in the area of tax. This helps keeping Oracle up to date based on the impact of latest changes in the law.
- Second there are the major release upgrades. For example, the upcoming upgrade from Release 11 to Release 12. These upgrades have a big impact on the functionality of the application and thus require a more thorough impact analysis than monthly updates. In collaboration with Oracle, the upgrade is first performed on the test environment before it is installed on the production environment. It is important for the system integrator to think about the impact of these regular updates on the support model after the implementation is completed. It also impacts your test strategy; the user needs to test frequently but in less extensive manner than before.
- Lastly, the irregular bug fixes and patches. If you find a bug, a service request can be logged to fix it. In the past it could take a long time before a bug was fixed and moved to the production environment. Whereas now, once the bug is fixed it will come with the first available monthly update for the testing on the test instance before it is moved to production.
3 What is the impact on the cloning procedure?
Since Oracle is now responsible for the environments, a clone is always initiated via a service request (SR) which can be logged on the Oracle support site. It is important to keep in mind that you are fully in control and you carefully plan out when you want to clone and on which specific environment. You have to at least three weeks in advance when you want to perform the cloning process. Of course, there are exceptions, but Oracle requires a three weeks minimum advance notice.
After the date has been set, the next step is to discuss with Oracle on the best time for the clone (nighttime for example) and once all is confirmed you will receive a time indication depending on the amount of data that is stored in your cloned environment .
A key point to mention is that as per standard you will receive two environments: test and production. A production to test copy is possible, but not the other way around (not that that will be needed often). Traditionally, most on-premise implementations have a development and user acceptance test environment as well. Cloud ERP does not require a development environment anymore, since customizations are not used, it is more about configuration. It can be argued if a user acceptance environment is needed or not, but then additional fees have to be paid.
For more information on the cloning procedure, please refer to Oracle support doc ID 1537549.1 (only accessible if you have an Oracle support account).
To conclude, there is a big impact on the Oracle support model with Oracle Cloud ERP. My experience is that it does require another way of thinking, and once you know how it works, you will never have it any other way.
Our next blog will be on user experience.