SAP’S prime event SAPPHIRE is happening next week. Of course SAP will talk about how great they are, how latest acquisitions add value, the new additions to the excellent portfolio, that customers are doing great thanks to SAP, and so on. It’s an event driven by marketing and sales, what else to expect?

Personally, I’d like to see some announcements that won’t happen, and won’t be announced at any other SAP event. Nevertheless, here is my personal list of things that I believe could add value to SAP’s overall ecosystem.

Trackable announcements

As with every event, there will be a lot of success stories and product launches and should padding and everybody on stage is either a friend, longtime friend, or for companies, it’s a very special relationship. And all about how great the product is. Why not make it easy to track the success? Of course S/4 is big. What about the other announcements? If it’s announced, provide a way to see how well the product is performing. Make transparent what happens to the product after SAPPHIRE is over. Bring the customer back on stage. Let them talk about the last 2, 3 or 5 years. For instance, what happened to the Leonardo solution for analyzing the health of palm trees? Is the intelligent vending machine used in the market? How is the cloud service for tax calculation performing?

Bring back apps

SAP is really good in delivering solutions for core business processes. For the additional problems, SAP tries to offer tools to customers that make it possible to create missing solutions and apps. What a customer gets is a toolset to develop, not a solution. If you want to have a mobile app for “standard” functionality today, you have to develop it. For large companies this is not a problem, for smaller one it can be, for everyone it means that they are responsible for developing apps. And to support them.

Once we had mobile workflow from Sybase / SAP, a packaged app for mobile. Afaria was a leader in MDM. Both were sold together and client got for one price a complete mobile solution. Today you can automatically create an offline enabled app using for instance mobile cards or the new mobile development kit. Using these, you develop following standard guidelines. Every partner or freelancer can offer the very same app for a customer.

The available toolset is good enough to create apps out of Fiori apps, Mobile Cards or Mobile Development Kit. Many customers want the apps you can develop with these but do not like the idea of doing this. And having to deal with all the licensing and support issues. Make it easy to offer the developed app as an app with all licensing included. SAP could provide the standard documentation on how to create an app for a given process using the toolset from SAP, and let partners either create apps following 100% these guidelines or let them add additional features. In both cases, customer can buy what is needed, with full support from partner and SAP, and without having to license all components involved. In case customer wants to change the partner, the app is build using standard recommendation, another partner can offer the exact same app.

Redefine SAP portfolio

Trusting partners to deliver the kind of apps as they were delivered by SAP means to rethink SAP Consulting positioning and its portfolio. Once SAP Consulting was a powerful organization with competent people helping customers. From technical side, the good consultants largely left. From a functional point, situation is much better. Would be nice to see SAP consulting focusing solely where it can still offer value to customers: functional consulting. Let SAP’s own consultants advice customers on how to improve their business processes. How to do accounting using S/4, Retail or supplier management. Let everything that even slightly touches technical area complete handled by either a partner or freelancer consultant. Same for support. It’s time to stop letting SAP support people act as consultants.

Simplify Cloud

When SAP executives look at it, it must be a dream for them: customers buying HEC, cloud numbers go up, only good feedback. What enters the system and bubbles up is filtered. The lower you go at a HEC project, talking to people actually working on a daily basis with HEC, situation changes: System not correctly configured, unavailability, bad support, and so on.

Personally I had so far: HANA system that wasn’t updated for years, Gateway system with language pack not correctly installed, systems unavailable because support restarted it in PRD without informing anyone, missing components like Web Dispatcher. My personal favorite: 24/7 support from Monday to Friday during Indian business hours.

It’s time to announce when SAP is either closing HEC or restarting it’s offering. Same for SCP. Neo, Cloud Foundry, it’s nice to have choice, but please close one. Announce if Neo is going to survive or not, and give a final date. Also, separate SCP services by user groups: developers & business. Business side is interested in solutions not developer services. Give each group one view at SCP and services. A possible end of this could be to close the developer part of SCP. Bring the tools to multi cloud, aka: offer them on AWS, Azure, etc.

Fiori

SAP pushed Design Thinking and provides helpful tools and guidance on how to enable it. Many customers started to use DT thanks to SAP. The initiative slowed down. Development on Build and web site seems to be at minimum effort. I would like to see SAP investing more into BUILD. Make all UI5 controls available, integrate Bootstrap controls, include controls for iOS, Android and material design. Make it a design tool not only for SAP content, but for everything. Make it the design and mock tool at companies. To speed adoption of UI5 outside SAP context, make all UI controls part of OpenUI5. Include better support for non-OData backends.

None of this will be announced at SAPPHIRE. I just wrote this down to be able to look back in a few years to see if some ideas were good. There are additional ideas that are more suitable for TechEd, like: make S/4 architecture ready for Kubernetes. Having a work process running as pod in K8S makes it easier to scale an SAP System. Allowing arbitrary databases as backend for SAP CAPM. Add SAP technologies to Swagger (OpenAPI). Deliver software via Git. Long time topic from me, think I mentioned this around 2011 in SCN. For instance, instead of installing Fiori Apps the traditional way, let me select the app in Git and import only this app and run also the included tests. Reduce drastically RAM footprint of HANA. And many more. Maybe I will write a similar blog for next SAP TechEd.