• Cost
• Company Size
• Reputation
• Resource Compatibility
• Experience

Certainly, all of these factors should be considered to some extent.  The challenge lies in determining how much weight needs to be added to each of them.  

I have an opinion on this, as I have seen a lot of customers choose the wrong SI which ultimately creates a solution that is unusable.

Cost

The cost will always be a factor in deciding an SI, but it should not be the only nor should it be the most important.  There are two components to cost: 1) daily or hourly rate and 2) total cost of ownership. All you have to do is look at clients who have chosen the cheapest option and compare that to user adoption.  What often happens when the SI with the cheapest rate is chosen is the project starts, it finishes, and then the users don’t use the system and another more expensive and/or experienced integrator has to come in and fix it or re-do it.  You can learn from other’s mistakes; you get what you pay for.

Company Size

This isn’t used as much but can be important to some for financial stability reasons.  Customers want to make sure a company won’t fold while their project is going. This is usually the case for larger projects.  The irony of this is that if it is a big project, the company is getting paid, so for the resources on the project, they won’t be going anywhere.  

The other reason customers look at company size may be to know they have enough resources to support the project.  This is valid, depending on the size of the project.

Reputation

This should have a lot of weight.  Find out about who you are considering.  Don’t ask for references; find them through your own channels.  I’ve always thought asking someone for a reference was odd, since the only reference you will get are the ones that they want you to talk to.

Resource Compatibility

This one is hard to articulate; you either have it or you don’t.  Different organizations have different cultures, and sometimes those cultures don’t mesh.  Make sure you find one that will. Ask the SI who will be on the project. SI’s can provide you with names and resumes, but understand that the bait and switch may happen depending on project timelines and start dates.  That’s OK if you set the expectation up front that you have to approve the resources who will be on the project. Ask to interview the candidates that are being proposed and make sure it is clear that you have the right to ask for a resource to be replaced.

Experience

One of the biggest challenges faced by SI’s is knowing where the pitfalls are.  The clients don’t know where they are, so the SI’s must. Knowing these pitfalls comes with experience.  I’ve seen too many clients that use large, high priced SI’s who provide inexperienced teams which leads to a slow, over-architected solution that is essentially not useable – a lose-lose for everyone.

In the end, the best advice is to ask the right questions and do your homework.  Find out about the companies you are considering and what they have done before engaging them.  This is a “service” industry, which means customer service is important.

The following chart represents what I believe is important.  There certainly are other factors to consider, and I would be interested in hearing any feedback on my recommendations:

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.

The Jet user interface (UI) is Oracle’s latest and greatest front-end user experience for their planning applications, and that is not an exaggeration.  The look and feel of this UI is exceptional. If you are used to the older UI’s (Fusion Client or Classic Client), an upgrade to the cloud and this new Jet UI will be a big step forward.  This blog will highlight some of the area’s that we believe provide the most significant benefit over previous versions.

Dashboard

A true dashboard exists that is easily configured by system integrators and allows users to see graphical views of key metrics and exceptions when they first log into the application.  From the exception dashboard, a user can drill directly into the workspace where the exception exists.

Note: A “workspace” is equivalent to a “workbook” in previous version terminology. 

Recent Plans

Users can now easily view which plans they have worked on recently from the newly added “Recent Plans” section, which is always available.  In previous versions, users had to log out and go through a number of steps to see what was saved most recently.

Auto Save

Workspaces (previously workbooks) are automatically saved.  There is no longer a need to debate what the difference is between save and commit.  Users simply need to grasp the commit concept, as saves now happen automatically.

Multiple Workspaces

Users can have multiple workspaces open at any time.  There is no longer a need to launch a new browser and log in again, as was required with the Fusion Client.  Users can work in both workspaces at the same time.

Expanded View

Oracle has listened to its customers suggestions about screen “real estate” that the solution takes up; and they have added an “expanded view” option.  This minimizes the overhead on the screen and displays as many cells on the screen as possible. Additionally, there is a font adjustment button that can also be used to fit more data onto the screen with smaller fonts.

Views Docking Area

The UI has a docking area with pre-configured view formats.  This is a similar concept to a measure profile, if you are familiar with that, just better.  While on a view, users can see all the additional view layouts they have requested and can drag and drop them onto the view to see multi-pane views.  The user can build new custom lay-outs and save as many as they need to the doc. They are saved for that user only.

What-if Scenarios

The solution no-longer needs to be configured to have additional “what-if” capabilities (additional calculations, different versions etc), the base platform provides this functionality.  Users can create exact copies of their plans and do additional planning. At any time, they can promote this what-if plan to their primary working version of the plan, or they can discard it.

If you are on an older version of RPAS and haven’t seen this new UI, I strongly recommend requesting a demo, this blog does not do it justice.

It is no secret that most software solutions are now cloud based.  If they are not yet, they either will be soon or they won’t exist. The RPAS technology made the move in 2017 to the cloud, and although on-prem versions are available, the cloud version is the future.

There are a countless number of retailers who have the on-premise version of this software, and they rightfully need to wonder if they should upgrade to the cloud version.  It may not be for everyone, and there are some implementations that will be harder to migrate than others, but what we do know is that Oracle really wants their customers to upgrade and have been creative with converting existing, on-premise licenses to cloud licenses.  This may not be the case for long, as they continue to increase the number of clients on this new platform.

We have done both migrations to the cloud and fresh installs.  The migration process is less painful than you would think. Here are a few things to consider when trying to understand what the process could look like for you:

• Be up front about when you want the solution live for the users.  Back track to align licensing, provisioning, configuration and deployment.
• Some solutions migrations can be accelerated.  Merchandise Financial Planning, for example, will likely be faster than Assortment Planning because of the new capabilities that are delivered with the platform to make Assortment Planning easier to use.
• The cloud version of the solution has a new user interface (called the Jet UI), which is really nice and current.  We will blog about that soon.
• The batch architecture is quite simple.  There is a scheduling tool with the cloud version, and as long as you don’t have any special processes, all you need to do is deliver the files to an SFTP site.
• Oracle requires clients on the cloud to continually update the platform, only allowing them to be a few months behind at most (this is a good thing).
• You no longer need hardware to support the solution, although there is still support needed for the solution.  Oracle will support keeping the system running, but if there are issues with the configuration, that is your responsibility.
• Make sure you have done your work with your network.  There are fairly easy tests that you can run to see how quickly you can connect to the Oracle cloud.

The bottom line is that by moving to the cloud, you are eliminating the responsibility and efforts needed for the upgrade and maintenance of your hardware and servers.  This is a tremendous benefit. Most clients fail to upgrade their RPAS solution, and find themselves at a point where the solution is not supported and it is costly to upgrade.  Total cost of ownership should be similar, but the headaches should be significantly less, allowing retailers to focus on being retailers.

We want to create a place where we can share the knowledge we have gained over the past 20+ years we have been working with the RPAS technology.  We have pretty much seen everything, and over time, we will post blogs with information that we think retailers and integrators will find useful.

Oracle has recently made a big push to go to the cloud that includes a new UI that is modern.  We will be covering anything that you want, but until we receive requests, we will be covering topics like “Why should we move to the cloud”, “What is the difference between the cloud and the on-premise solution”, along with more specific topics related to the solutions, including forecasting.

Please use the “contact us” form to send us topics you would like us to talk about.