vrijdag 17 februari 2017

Oracle Procurement Cloud Blog Part V: leaving support in the hands of Oracle

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.

donderdag 9 februari 2017

Oracle Procurement Cloud Blog Part IV: Key setup differences Oracle Procurement Cloud vs On-Premise

In continuation of our blog series on Oracle Procurement Cloud, this week I will share my experience on differences between Cloud ERP and conventional ERP setup. For more information you can read our earlier blogs on the go-live, implementation speed and structural flexibility.

In my opinion, one of the best improvements in the area of any ERP setup is the ‘functional setup manager’, and it is worth diving a little deeper into this vital area  of any Oracle Cloud ERP implementation.

You can easily navigate to this section of the system when you log in for the very first time, you cannot miss it. Straight away you will be able to see specific modules of the system (purchasing, finance, etc.) for which you might have bought licenses. This avoids a lot of hassle in figuring out what sections of the systems one can access and which sections are restricted.

The best thing however is that all the steps needed to setup the system are located conveniently in one area and are nicely put into a checklist. If I could compare it to other conventional ERP systems (where you sometimes have to be an expert to know where each specific setup point is located into the system), this definitely is a  change of pace.  With the aligned checklist, one cannot miss a step in the system thus avoiding errors. Every step requires data or is dependent on a decision that you have taken in the previous step.

Furthermore it is possible to assign a specific set of users to various steps and  give a different status to these steps e.g.: in process, completed, awaiting approval etc.); this ensures that no one can interfere into another’s task. All the steps needed for a specific section in the implementation can now be consolidated in the ‘Implementation Project’ which will have the flexibility to address each task separately.

The way this setup manager works really adds to the simplicity of it all. It takes away that valuable time which was spent on thinking  ‘how to set things up’, and in turn frees up time that can be applied onto thinking ‘why things should be setup – how does it assist business processes in the best way’?  In other words: the setup of the system can be done from a more business perspective than ever before.

This does not imply that the setup functionalities are only superficial and not detail oriented (looks can be deceiving). Behind the new and updated look, many options are available to configure implementations for midsized businesses as well as huge global companies.

To conclude, the way Oracle Procurement Cloud is setup is more user friendly and logical than it was ever before. The time it takes to setup the system is significantly decreased, which leaves more time for business process optimization. Quick, simple and convenient ERP is the way to go, and the business is in charge.

Our next blog will be on the impact of hosting ERP in the cloud vs on-premise. What changes in how you are dependent on Oracle?

For more information, please refer to jasper.oskam@capgemini.com or Jeroen.sprangers@capgemini.com