Are you part of an Oracle project to move HR, finance, payroll, procurement or customer experience to the cloud? If so, then this article is for you. The move to the cloud is a big undertaking but what happens after the project is complete? This article will help you understand the role of a Managed Service Provider (“MSP”), what they do and what options you have.
Terminology
I will use the term Enterprise Resource Planning (“EPR”) as a catch-up for all or any of the modules that are moving to the cloud. ERP is a very broad term that usually describes a platform of inter-operable applications and modules to manage (often) some of your organisational resources or (rarely) all of them.
A hot fix is a patch that is applied outside of the quarterly upgrade cycle that is required to resolve a defect in the system
Platform-as-a-Service (“PaaS”) is the place where we build custom configuration extension to deliver a workflow that is not supported in the core ‘out-of-the-box’ product. “PaaS extensions” is the term we use forone or more custom scripts that are considered as a customisation.
Context
The following chart shows the hype curve for ERP from Gartner:
The hype curve shows that there are two areas of extreme maturity for ERP: firstly, the actual managed service itself (The Oracle cloud) and secondly the third party support that is available.
Third party support comes in two flavours: firstly, the system integrator that actually helps you migrate to the cloud and second is the MSP for what happens once you are in the cloud. The differences between a system integrator and a MSP far outweighs the similarities.
Moving on from a System Integrator
The system integrator helps a client through the software development lifecycle from planning through to deployment. This journey goes through analysis, design, configuration & implementation and testing prior to cutover and go-live. During this journey a series of configuration work books (“CWBs”) will be created which will document every part of the system. The CWBs would allow a third party with the appropriate skills to recreate the entire system from scratch. To this end, the CWBs are both large in number and extremely detailed. The system integrator will handover the CWBs at the end of the project. The CWBs will be the one (and sometimes only) deliverable handed at the end. You may well have spent years and millions of pounds with a system integrator and suddenly all you have to show for it is dozens of CWBs which often are simply Excel workbooks- that and the cloud based system itself. At this point you have an option:
- Support the system yourself
- Handover the support to an MSP
Support the system yourself- “Going it alone”
The first option cannot be ruled out but is highly unlikely. The system integrator will have utilised a large number of functional consultants who are experts in their application (HR, Payroll, tax, finance, procurement, recruitment etc). It’s possible that a consultant supported more than one area (e.g. Time & labour & Payroll) but the likelihood is that there were many consultants. The cloud based applications are so diverse that you won’t simply have one functional consultant who understands the whole system. These consultants did the analysis, design and configuration for their part of the system and, more importantly, understood the impact of their module on other parts of the system. Behind the scenes, the consultants would have been collaborating with each other to ensure that workflows, modules and applications all joined up so that data flowed seamlessly through the ERP system. It would have been a full time job for a lot of these consultants for 12-18 months. Some of the smaller modules (e.g. Taxation) might have required somebody with deep expertise who may have only been part-time.
Once the project is finished then the system integrator will depart (usually after a short warranty period). From this point forward, your organisation will not start still. There maybe changes to your operating model, changes to prices, tax legislation, you might be new products to market. Changes in your organisaition that will almost always result in changes to the system. In fact, any change to any drop down in the system or the business logic in terms of how the system works. Also the Oracle cloud system is upgraded every three months and this itself might bring new features you want to utilise or create a conflict with how your system was set-up in the first place. It is possible that a quarterly upgrade ‘breaks’ one of your existing key workflows. From experience, I’d recommend planning for a breakage once every five or six quarterly upgrades.
To make any of the changes to the system you are going to need deep functional expertise. This expertise will need to be as deep as those skills that first created the system. Every change needs to be analysed, designed, configured and tested with a full understand of how the system is configured and how the change will impact all of the other parts of the system. To do this safely will require a team of functional consultants as large as the team that originally built it. This might not seem like too much of a problem but the issue is that the volume of change after go-live is likely to be considerably lower than the amount of work required to create the system in the first place. Put simply, you will have a large number of expensive functional consultants sat around for a large amount of time doing nothing. Once in a while you will require one of the functional consultants to spring into life to make a key change.
It is not to say that “going it alone” is the wrong answer, however, you’ll have to do the maths to determine if the volume of change warrants it. “Highly unlikely” will be the answer.
Handover the support to an MSP
From the above description, a model of ‘fractional functional consultants’ would be a good solution. This is exactly what you get from a MSP. You will have an over-arching support contract with access to consultants with deep functional skills. The MSP will usually front this with a service desk. The MSP business model is that they will be supporting a number of clients at any one time that makes it economical to employ functional consultants for each area. The MSP functional consultants will be available for small, medium and large sized changes and their work is scheduled in on a priority basis. Most MSPs will have more than one functional consultant for each area. This helps with not only from the perspective of resilience but it also allows the MSP to allocate named individuals to specific clients so that they get to know the configuration for that client as well as the client side team.
Services provided by an MSP
Your MSP will provide two core services often referred to as “Break-fix” or “Service requests”.
Break-fix incidents
A break-fix is where there is an incident because something is not working properly. Ultimately, these are rare. For example, a customer invoice that is not being picked up by advanced collections but this is probably a ‘bad data’ in the system as a result of a training or process issue somewhere else in the organisation. It is also possible that there has been a technical issue on the Oracle cloud based platform that is resulting in processing issues in your organisation (however this is rare). Another, more common reason, is that a quarterly update has not been tested fully and that a ‘hot fix’ is required. PaaS extensions are particularly prone to issues associated with quarterly updates as Oracle will not have done in-house testing against your PaaS extension. It is often the case that the MSP will raise an Service request with Oracle themselves if the incident is related to the product or the underlying cloud based platform. Your in-house support team will have visibility of the Oracle Service Request and usually the MSP will manage the ticket with Oracle directly on your behalf.
Service Requests
This is by far the high volume of contacts made to the MSP. These can be thought of as “How do I?” questions. It’s often the case that MSPs will provide knowledge base articles that will help you find the answers and this can often be on self-service support platforms such as ServiceNow or Salesforce. Common Service Requests will be responded to by the MSP service desk while less frequent, deeper questions may get referred to the functional consultant. Unlike incidents, it is rare for a client service request to require an Oracle service request to be raised. This is because the MSP is there to support your configuration and Oracle is there to support the core product. “How do I?” Questions mostly occur as a result of a need to understand how the product behaves with the configuration itself. You won’t go far wrong if you remember that “MSP is there to support the configuration; Oracle support the product”.
