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). 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 contrast to the past – when a bug was found, the fix was
implemented faster, but with a time span of multiple weeks, not days. 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 user 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.
