Solution Support for Cloud Environments

Now that customers are moving more applications to the cloud, the question of how to support those applications comes into play.  This is particularly important for the RPAS suite of applications, since those applications are generally configured specifically for each customer using Oracle’s configurable platform.

The question we get is, “Why do we need you to support these applications now that they are on the cloud?  Oracle should support the application.” Having a cloud solution does move a lot of responsibilities and support from each client to Oracle, but not all of it.

Oracle will be the first line of response when the system is not available.  This is the most important piece of support. Anytime a user or users are not able to log into the system, or the system is off-line, a ticket needs to be logged with Oracle immediately.  Other than these types of issues, understanding what Oracle will and will not support is not necessarily straightforward.

One area clients can use support is in the triage of issues, to help them get the relevant information, determine the root cause and decide if it needs to be logged with Oracle or is a configuration issue.  We had one client who logged a ticket with Oracle, and after a number of days of back and forth with the Oracle support team to provide a domain and details to reproduce, Oracle informed the client it was a configuration issue. Only then did the client reach out to us.

Understanding the difference between a platform issue (that Oracle addresses) and a configuration issue (that Oracle will not address) requires experience and knowledge of the platform.  Given a specific scenario, the issue could be platform, training or configuration related. Let’s look at an example.

Aggregation is foundational to the Oracle planning solution.  If a user is responsible for all the classes in one department, then the aggregation of each of the classes to the department needs to be accurate.  For inventory, the aggregation could be the first or last period, where sales would be the sum of the children.

If we consider a sales metric, the department in a workspace should be the sum of all the classes.  If the user manually sums up all the classes and sees it is not equal to the value in the tool at the department level, there are a number of things that could cause this.

1. The user could have entered the numbers wrong.  I know this is obvious, but it needs to be stated.
2. The user could have done something in the workbook to hide a class, which would be included in the department total displayed on the screen, even though the hidden class is not displayed.
3. The configuration of this measures aggregation method could be incorrect, for instance average instead of total.
4. The platform may have a bug in it based on the specifics of how this workspace was built.

For 1) and 2), the business administrator should be able to identify this and communicate to the user.  For 3) and 4), someone will have to know how the system is configured and be able to determine if it is a configuration or a platform issue.

There are a number of tasks that do not occur frequently, but are necessary, and that require knowledge of the technology.  The following are a list of those types of tasks:

• Periodic upgrades –  These are scheduled with Oracle and can be done by the client, but reviewing the release notes and understanding how these upgrades may affect the client configuration is oftentimes something that requires a deep knowledge of the platform.  Having a third party responsible for turning off batch and making sure the upgrade is successful does provide value to the client. Platform upgrades occur monthly.
• Year change over – Each year, a new calendar file needs to be loaded, which should have been accounted for in the initial implementation, but sometimes requires manual invention.  Along with this, an annual cleanup of the hierarchies and underlying data is recommended. The annual cleanup of hierarchies will keep the solution running efficiently from a performance perspective.
• History Mapping – The history mapping that is used to map historical weeks to future weeks needs to be setup each time an updated calendar file is loaded.
• Logging and tracking Oracle Service Requests on behalf of the client – logging a ticket with Oracle requires a lot of information, including detailed steps to reproduce.   We had one client express that it was taking 75% of one person’s time to log and track the issues. This would be an extreme case that occurs close to or during project go-live.
• Batch issues – Oracle will likely not fix batch issues, unless it is determined to be a platform bug.  Generally speaking, batch issues are a result of bad files, empty files, or no files being delivered.

We’ve put together a basic flow chart to show how a support process would work, where the green boxes, at a minimum, require platform and technology expertise.

 

With the push Oracle has made to move their planning solutions to the cloud, some of the responsibilities of retailers from a technical support aspect are now gone, but not all of them. In addition, some of the tools that were available with on-premise solutions have disappeared and require workarounds, collaboration with the Oracle cloud team and/or extensive knowledge of the platform to have their functionality substituted.