Core values of SCP services
The weeks after I wrote my thoughts down about SAP Cloud Platform (SCP) and what should change were quite interesting. Triggered by the official end of SCP Neo trial I wrote down what I think is missing in SAP’s SCP offering. My two blogs laid out the overall idea: ease of access to SCP for those that create solutions. One point of view is about the SCP services and the marketplace idea. Indirectly it reveals one problem of SCP: what services does SAP offer that add value? In case you can choose easily to add an SCP service to your cloud solution: which one would you chose?
Once SAP talked about the concept of the core. A company needs to focus on what it can do best, what defines it and its competitive advantage. The challenge of this concept is that a company needs to find out what their core – or DNA – is. When a company knows what they are best in, they can create products that benefit from the fundamental knowledge and competitive advantage. It allows a product to excel.
In its core, SAP is an ERP company. SAP knows business processes; order to cash, procure to pay, hire to retire. Focusing on SAP’s core, the main knowledge that makes them deliver best in class products. Their ERP system is sacrosanct. It is used everywhere; it is the backbone of the world’s economy.
What is the core of SCP? What makes you chose SCP?
The base idea of SCP is to develop, enhance and integrate. In its current positioning, SCP is a PaaS offering made by SAP for SAP. You want to use it, become an SAP customer. You want to enhance or integrate your SAP systems, use SCP. It’s positioned in a way to ensure that SAP’s clientele goes to SCP. SAP customers go to cloud, they should go to SAP’s cloud. SCP offers services that solve problems that arise when you use S/4HANA, SuccessFactors, Hybris, Ariba, etc. Exaggerated: SCP solves a problem created by SAP.
When the core of SAP is ERP knowledge, can you find it at SCP? What about services that you can add to your solution and that solve a specific business problem? It’s not services like Java, or mobile services. Other PaaS offer this kind of services too, and imho SCP cannot compete with them.
Potential lies at services that offer a subset of basic ERP functionality without the need of having an SAP ERP system. When you are developing a solution and have to calculate the tax or create an invoice? A fraud detection service? A service for managing functional locations, bill of material, HR data? It can be done today when you have the right SAP backend connected. In case you ever gone through a process to license 200 external users and give them access to your SAP backend system (or even buy one) you might understand.
Some services come close to this idea: Tax service, Translation Hub, Workflow, etc. Services that you can add to your e.g. Azure web app in a modular – Lego like – way. The embrace program fits perfectly in these scenarios. The backbone of an app may be Azure, what adds the value for the business are the business-related SCP services.
As a simple example, take NF-e from Brazil where you have to send a signed XML message to the tax office. You get the whole solution from SAP today, SAP system included. Just signing the message can be realized by any developer. Adding additional features adds value. As a specialized SCP service features like managing the certificate or handling asynchronous messages may be offered. In conjunction with a free tier approach, as soon as you send more than N messages per month, you advance to the next subscription level. No other SAP system needed and anybody that needs the real, full blown solution, can still use what SAP offers.
For an app that manages just some parts information for a product, this is doable by a development team. Chances are good that soon the complexity increases, and they are overwhelmed. Having an SCP service for BOM lets them focus on other problems. The PO and architect win the confidence that the service is offered by the company that knows how to do BOM.
It is easy to develop a new app. It’s the business logic and (legal) requirements that make an app complex. If you can connect an ERP system, much of that complexity is reduced to an integration problem. If you do not want or cannot add one, you have to develop your own logic that follows the business process.
You wonder how many times a team is re-developing existing ERP functionality tailored to the scope of their problem? Because they are not aware that the feature is available in SAP? Because they do not know how to realize the integration? Or because standard SAP is just too complex and only adds costs? The answer is frightening: more often than you think.
This is not about offering the complete SAP as an SCP service. It is about getting SAP DNA into SCP services. Enough to offer significant value, and with the possibility to go from the SCP service to the real SAP product.