The Greek philosopher Heraclitus nailed it when he said, “The only constant in life is change.” Leading, managing, and dealing with the consequences of change is something we deal with every day, whether in our personal or professional lives. When it comes to business, innovation is in the current wave of change buzzwords. You can’t have a conversation about business growth or strategy without also talking about business innovation.
I don’t think I need to spend time talking about the “why” for innovation. If you want to talk about the why, send me a letter (or even a fax), and we can block some time 😊. However, I do want to talk about the “where” part of innovation, so here we go.
The “Z” way—long live SAP ABAP
Unless you are very new to the SAP ecosystem, the idea of Z code is not new to you. SAP made it very easy for customers to extend the functionality of its core ERP system by writing extensions (user exits, enhancements…pick your preferred term) to their core code. If the standard sales order entry process didn’t meet your company’s needs, it was a relatively simple process to add additional functionality to support how that process would work. At my old company, we built extensive (pun intended) extensions to the sales order process to meet the requirements. We had to manage specific order types, pricing scenarios, and even material allocations that the standard SAP sales order process simply did not consider.
Of course, this model wasn’t without its challenges. As many of you have experienced, because these personalizations were embedded within the core, we couldn’t allow for changes without first ensuring that those changes would not negatively impact how our stuff worked. Applying enhancement packs or upgrades without performing exhaustive regression testing beforehand quickly became too much of a business risk. Net result: We could build our own innovations, but it was difficult to consume innovations from SAP.
The “cloud” way—long live SAP Business Technology Platform (BTP)
So along comes SAP S/4HANA and the idea of the “clean core.” Keep your core system as true to standard as possible so you can accept innovations—in this case, new capabilities from SAP—without going through the upgrade testing processes of the past. Great idea, but it doesn’t come without its share of challenges. How do I now deal with all the IPs we’ve created under a model that is no longer applicable? The underlying business needs are (potentially) still there, so how do I continue to support them? The SAP answer—BTP.
SAP BTP provides a framework (the “Platform” in BTP) for customers to develop and manage extensions to the core systems from SAP in a structured way, leveraging defined APIs and tools. Under the SAP S/4HANA and SAP BTP model, customers should be able to have their cake and eat it too—they can extend the core capabilities where needed while still adopting new capabilities from SAP as they’re released.
But what about the “technical debt?”
For net-new SAP customers, the SAP S/4HANA and SAP BTP combo is hands down a powerful solution for adopting change in the business. This is still the case for legacy SAP customers, but getting there is a little more complicated. Legacy enhancements must be addressed; you can leave them behind, move them to a standard function, or migrate them forward. I still see a surprising number of customers taking a fourth choice—taking a wait-and-see attitude. To quote one of my all-time favorite bands, “If you choose not to decide, you still have made a choice.” Of all the possible scenarios out there, I do not see one where a time will come that you can push a button and all your old Z programs will magically start working in the new model.
The “debt” of the technical debt is that, at some point, you’ll have to exhaust some effort to update this code to run under the new model. SAP is providing tools to help mitigate this level of effort, but it will never go to zero.
So, where do we build innovations?
Here’s the crux of my article this month. Since there will never be a time when you won’t need to provide organization-specific capabilities around your technology portfolio, what’s the right place to build these capabilities? In my opinion, the right platform should check a few boxes:
- The platform should have a broad reach. Don’t choose a platform that limits the types of software applications (or vendor solutions) you can connect to.
- The platform should support open, or at least commonly used standards. Don’t pick a platform that limits your ability to find resources to use the platform. As an example, if it only supports COBOL programming, then you must find COBOL programmers to use it.
- The platform should be as future-proof as possible. This one is the trickiest. No one can predict the future, but you can at least ask “what if.” What happens if the underlying structure for the platform goes away? Can the work done on the platform be migrated somewhere else?
The SAP platform answer is SAP BTP, and it does check these boxes, even number three. As an extreme example, if you develop a cool mobile order entry app and use SAP BTP to connect it to your SAP systems and then SAP “goes away,” you still have a cool mobile order entry app. True, but for it to be useful you’ll have to reconnect it to whatever systems you now use to manage your finance, inventory, and logistics—but at least you aren’t starting from scratch. The same is not true for a Z program. If SAP ECC “goes away,” then so does the Z program.
So, where should you build innovations? I think SAP is 100% correct in saying it should be on a platform that’s designed to support innovation. I also think there are some compelling reasons why SAP customers should choose SAP BTP as that platform. But I also know from conversations with members of the ASUG Executive Exchange community and ASUG Pulse of the SAP Customer Research that SAP BTP has not become the universal answer to the “where” innovation question.
Here is this month’s big ask: Where are you building your organization’s innovations? Are you using a pre-built platform (like SAP BTP)? Are you creating your own ad-hoc solutions? Are you still using user exits and enhancement points? I want to hear from you! This is an area where I see a lot of different choices being made by members of the ASUG Executive Exchange community, and I would love to start a discussion and provide some guidelines around best practices and the “why” of how you’re answering the “where” question.
Two final notes for this month. First, if you are attending SAP Sapphire & ASUG Annual Conference June 3–5 in Orlando, be sure to register for our ASUG Executive Exchange “pre-conference” day! We have an afternoon of great education sessions followed by an ASUG Executive Exchange Networking Dinner at SeaWorld® Orlando Shark’s Underwater Grill. Registration is free—just choose the ASUG Executive Exchange session under the pre-conference list during registration to indicate your interest. I’m pleased to report that seats are filling up, but space is limited. However, we do still have seats available.
Second, on the band quote—bonus points if you can name the band! The original quote is attributed to Rene Descartes, but he didn’t write rock music in 1980.