This article corroborates the assumptions I made in a previous blog post. It highlights a talent shortage within the SAP ecosystem, partially attributed to the surge in S/4 migration projects impacting the industry.
In early November I chatted with Bonnie Graham, Dave Maloney and Jennifer McClure on the topic of “From Users to Creators: The Employee-Led Tech Transformation”.
You can find the recording here: https://www.linkedin.com/video/live/urn:li:ugcPost:7127716692142538752/
I strongly advocate for the relevance of Low-Code/No-Code within the ecosystem, emphasizing its significant value in the progression from concept to realization.
Nevertheless, I am of the opinion that the enthusiasm generated by analysts may have been overstated, and the actual market opportunity might not be as extensive as initially anticipated.
With SAP’s move to the Cloud, along with shifts in paradigms and some anticipated SAP technology resource issues, the SAP community will likely face some challenges in the near future. Going forward, the community needs access to a larger resource and talent pool in order to extend and enhance SAP applications and functionalities. This might seem like a tall order, but SAP has consistently developed the kind of resources that attract top talent. More than anything, they have continually shown that they are dedicated to advancing its many offerings to provide the solutions its customers need to succeed.
Perhaps the best example of SAP’s dedication to support is ABAP (Advanced Business Application Programming), the company’s proprietary programming language. 20 years ago, SAP followed a simple, single development stack, relying primarily on the ABAP language for any development that needed to be done. Over time though, ABAP has been greatly expanded, now supporting Object Oriented approaches and web-based protocols. It also recently evolved to run independently in SAP’s Business Technology Platform. With roughly 70,000 developers around the world, the ABAP community is a proud one, and with the introduction of an ABAP stack in the cloud, it is clear that ABAP is here to stay.
The value of this non-ABAP option is already apparent. At Rizing, those who’ve adopted the Cloud Application Programming Model have seen 20-30% efficiency gains compared to other SAP extension paradigms. Additionally, we have customers in areas such as the Hawaiian Islands, where getting access to local ABAP developers is often challenging. Using a cloud-based extension paradigm based on more popular programming languages helps them overcome their resource shortages and more easily connect with other like-minded developers.
None of this is to suggest that ABAP doesn’t still have an important role to play in SAP development. ABAP is still the most popular choice among existing SAP developers and it remains the only language possible for certain enhancements, even in SAP’s S/4 HANA. However, a growing community needs to attract new talent and SAP’s Cloud Application Programming Model is a great alternative to bring in developers that use more common programming languages. Couple that with SAP’s long-standing penchant for resource development and I am confident that they can bring in and support this new influx of talent.
As the recession looms, SAP customers will need to make some changes going into 2023. For current SAP customers, economic trends have made the transition from R/3 systems to S/4 HANA more challenging, while potential customers are now weighing their options to decide if it’s worth starting the transition at all. On the one hand, customers are becoming increasingly cost-conscious due to the economic downturn. They are eager to reduce spending, and less likely to want to pay for SAP technologies. On the flip side, companies in regulated industries will still be required to run a supported system, thus making ERPs like SAP necessary regardless of their cost. Additionally, enterprises using an SAP ERP will have to migrate to S/4HANA by 2027, meaning that many cannot afford to wait until the economy gets better.
Prior to recession concerns, many companies were struggling with their S/4 transition, either due to a lack of corporate buy-in or appropriate skills. Still, the challenges of the coming year will no doubt create new obstacles. The best option is to identify where SAP customers might struggle in their transition process and present solutions to make the process easier to navigate.
With a technical upgrade, users update their existing systems without necessarily taking the time to build them into their larger business structure. This can be appealing because it’s almost always the cheapest option. However, it will still require some money and changes to system configuration and processes. While the short-term costs are lower, the long-term result is usually all-costs with minimal benefit, offering little in a business case.
2. Full Business Transformation
Some businesses aim for more extensive efforts, embedding the technical changes they’re making into a much larger business transformation undertaking. Many businesses are hesitant to make this call since the costs are high and it requires a company-wide effort, meaning everyone needs to be on board for it to work. However, the benefits ultimately offset the costs with companies often seeing major gains in profit and operational efficiency. Additionally, a full business transformation doesn’t require profound organizational change management, as users become part of the transformation.
3. Best Practice-Based Approach
A ‘best practices’ approach can be seen as a middle ground between a minor technical upgrade and a more in-depth full business transformation. Companies rely on industry best practices as their starting point rather than trying to determine a unique path for their company specifically. They go with standard processes and configurations, only being truly unique when it comes to competitive differentiators. This approach is generally more worthwhile than a simple technical upgrade, driving a substantial amount of operational efficiency improvements while keeping migration costs low. That said, it requires more of a leadership commitment and higher effort in organizational change management compared to a full business transformation.
Even with a clear migration path in mind, SAP customers will likely face some pushback as they look to migrate to S/4 HANA, especially as the recession takes hold. Still, there are options for SAP customers looking to “sell” others on the migration process. There are two major options to explore: lowering costs and showcasing business value.
The first option is the most obvious one: one of the biggest reasons that top leadership resists tech initiatives is because it’s expensive. Finding ways to lower costs can help significantly in getting others on board. This starts by working with your trusted SI to work out new commercial models, along with efforts to try and lock in rates or capacity. Some simple optimization can go a long way toward reducing costs and driving value in the process.
The more difficult and rewarding path is to push the value of SAP services to encourage continued usage and migration. This involves finding pockets of high-value business processes to clean up to balance and improve one’s business case. From there, simple AI additions can be implemented, which have the potential to unlock millions of dollars in annual benefits. SAP solutions can cut costs and boost efficiency, so highlighting those benefits prove that the expenses are worthwhile in the long run.
While there’s no doubt that the recession will create challenges going forward, SAP is dedicated to helping customers unlock the full potential of their business and make their investments worthwhile.
With the flood of SAP projects hitting the SAP system integrator community (see other article), S/4 transitions are facing risks beyond the standard list we encounter in any S/4 implementation. SAP resource shortages could lead to unanticipated project extensions. Project extensions in turn lead to deferred benefit realization and additional implementation cost, and in this case, additional maintenance cost for not hitting SAP’s 2027 deadline.
An environment such as this forces us to think about mechanisms to derisk projects by accelerating no-regrets activities and see resource availability as ‘a’, if not ‘the’ critical success factor.
One opportunity is the acceleration of technical content migration and creation.
Technical work is usual seen as supplemental to the functional work of an implementation, and therefore successive to a business blueprint. In contrast to a net new implementation, a substantial amount of the technical work of a transition from ECC to S/4 is the migration of existing logic into a new IT paradigm.
In analyzing past and present S/4 projects, we determined that each project contains approximately 35% of technical tasks. Further analysis determined that 65% of those technical tasks could be executed ahead of the S/4 transition. This number contains activities such as the migration of ABAP Add-on’s into a side-by-side model, moving integration scenarios to the Cloud and providing insights to decision makers by developing Analytics Cloud and Data Warehouse Cloud-based dashboards.
Sample resource demand for SAP S/4 migration.
The activities must be triaged to determine a ‘no-regrets’ status.
Technical objects supporting a static business process receive the status right away.
Objects related to an improving business process are evaluated to determine if the technical objects stay consistent across envisioned business process changes or can be developed in a way that can accommodate the envisioned improvements
All other objects should be evaluated to see what prerequisites exists to assign them a ‘no-regrets’ status.
If the S/4 transition is taking place soon, the simplest way to structure the segmentation is by pulling the movable BTP tasks forward into a ‘Phase zero — BTP work’ whose end coincides with the start of the S/4 transition program.
In case the S/4 transition is not scheduled for a few years, you can create a program to move the component as outlined above with one adjustment. The components you move out of ECC are replacing existing non-BTP component and reduce the necessary transition work that would occur during the S/4 transition timeline.
Sample resource demand for SAP S/4 migration after acceleration of BTP activities.
The benefits are plenty:
SAP’s Business Technology Platform is gradually introduced into the organization to get developers and operators comfortable with it
Technical challenges are less likely to impact the critical path of the overall implementation, thus derisking the project and with it the benefit realization timeline
Higher likelihood of achieving the planned go live prevents paying incremental maintenance fee or worst-case working in an unsupported system
Reducing the BTP resource demand in the high demand/high-cost phase we are expecting in the coming years
For all of us that are working in the SAP ecosystem, December 31st, 2027, is the date that will drive us and our industry for the next years.
SAP is committed to provide mainstream maintenance for Business Suite 7 — the release that a lot of our customers are still using — until the end of 2027. Companies have the option to buy a maintenance extension until 2030 for an incremental 2% in maintenance fees. The prior 2025 support deadline was pushed to 2027 after customers requested more time to move to the new release in 2020 making it unlikely that the 2027 deadline will be moved yet again.
When assessing the current installed base of Business Suite 7, Gartner estimates that 70 percent of Business Suite 7/ECC customers have yet to migrate to S/4 HANA, but SAP S/4 HANA sales are growing at record levels based on SAP latest financial results and comments from SAP CEO, Christian Klein.
Combining these factors, we will see a wave of Business Suite 7 to S/4 migrations hitting the SAP System Integrator community in the next few years. We always knew it was coming, but the pandemic took 2 years out of our planning cycles.
Projected SAP resource demand over the next 10 years
So, here we are at t-5 years with countless customers that have yet to make the move. For IT practitioners, 5 years sounds like a long time, but everyone who has been working on large enterprise initiatives knows: you must create a business case, allocate funding, work with SAP on a license agreement, select an implementation partner, perform the implementation itself, roll it out and ultimately drive adoption of the solution to collect the business benefits you originally committed to in the business case.
If you are a small organization and don’t mind big bang rollouts you might be able to execute this in a year, but for most enterprises we work with, you easily look at an average 2–3-year timeline for transforming from ECC to S/4.
Working in the SAP implementation space, we are equipped to handle a steady stream of SAP projects, ranging from small add-ons to large implementations. We are also equipped to handle ebbs and flows in demand, but the wave we see coming is more analogous to a Tsunami hitting us on all fronts. Business process experts need to re-assess what improvements and benefits S/4 implementations can bring, functional experts need to configure S/4 and various technical teams must migrate interfaces, extensions and any other customer-specific content into the new Cloud-based paradigm.
For SAP customers that means you should start the journey as soon as possible, build your business case, estimate your implementation duration and certainly find and lock in your implementation partner as resources will get sparse and potentially more expensive as demand will undoubtedly outpace supply. Depending on your estimated implementation duration, you might have an alternative to delay the implementation and use the option of paying a premium to SAP. Most companies will likely want to use the 2027–30 timeline as a contingency, though.
To make the S/4 business case more attractive, the industry is continuously working on improving both factors (benefits and cost) of the equation.
New SAP applications and technologies open additional areas of benefit realization, but our teams, as well as our customers, must be equipped to see the potential, implement the changes in the system, processes and most important of all, take their people on the journey to increased efficiency.
Compared to the standard, consultative approach used in the past, cost reductions in the implementation effort can be achieved by standardizing and harmonizing business processes while following and utilizing best practices.
In the SAP implementation space, we are working hard to add capacity and ensure our implementation resources are trained up and ready for the hard work and long hours.
It has been a year and a half now of me coding again. I can honestly say it has been a steep learning curve, but fun and exhilarating.
The question that haunts me when I have 10 minutes to think about all the things I have learned is: “How do we get all the people like me to move?”.
I have a fairly unique position in that it is my job to dig into new paradigms, approaches and languages. But there is a whole SAP industry out there whose job it was and is to write RICEF’s (Reports, Interfaces, Conversions, Enhancement and Forms). They are busy 40 hours a week of delivering on projects and have very little time to catch up on new functionality. The most they learn is the 6 new commands that were added to ABAP.
That whole community, the thousands of them, might struggle to make the jump without a major re-education of certain concepts such as:
Storage of code in a repository that is not internal to SAP
CI/CD – Continuous Integration and Delivery
Cloud approaches such as Blue Green Deployments
Containerization
… and others
I don’t have the answer, but it is a question that keeps me thinking.
