The more things change, the more your SAP and IT strategies can’t stay the same

SAP R/3 – Get global, save costs, and do more with less

Everything was simpler back then, and SAP made it even simpler with R/2 – and then R/3. Different departmental systems in different countries (often built from the bottom up) were decommissioned and replaced by a single, integrated or “packaged” application. In most cases, this was done on a global basis. At the start of this process, there were combined teams from an implementation and support perspective following the integrated team structure of the business analyst and analyst programmer. Since there were no previous global systems to replace, fresh client server landscapes were being built – so benefits were delivered immediately.

In this world, support quickly became reactive. The focus of clients (and the broader market) was to roll out the integrated SAP platform as widely as possible – and to gain the most benefit from integration as fast as possible. It was accepted that some incidents would arise, the lights were kept on, and trouble-ticket-based support services were implemented that were successful and served their purpose. SAP was now the key vehicle for supporting the globalization of business as Y2K and the millennium bug came and went. However, as with any service, there’s a maturity curve. As clients sought to improve the ROI on these applications, the market started industrializing delivery and utilizing different lower cost delivery locations. It started to enter the Rightshore® age!

The “separation of responsibilities” trend had already begun, but the drive for industrialization increased momentum significantly. Previously, support and development teams were the same team, but due to a need to focus on rollouts (while at the same time continuing support), separate teams and flying squads came into being.

It’s a fact (not limited to SAP) that if you require global, enterprise-level application support, then an element of structure is required – and this was the case as the SAP worlds of applications development and management emerged. The upshot of this is that a level of change inertia begins to build in order to mitigate the risk of negative impacts from new changes on the business-critical global system.

Development vs. support – Software is evolving quickly … support models less so

The growth of SAP continued rapidly, but this led to diverging objectives across the SAP market in the form of development vs. support. While some parts of the business, such as sales, were driving for more and more change, the business criticality of a global SAP solution pushed back on that. At the same time, other parts of the business, for example, finance and IT, were focused on ensuring stability and availability to all – and so something had to give – but not the budget!

With hindsight, this tension was probably one of the causes of software as a service–as the business decided to spend its IT budget directly with new providers. This meant that they procured their own “new” departmental systems outside of the core SAP platform – and even the CIO came under threat from the chief digital officer.

Even though the approach to SAP support had indirectly contributed to this meteoric model in the IT market, the need to change from existing ways of working was low, and so the SAP market continued with separate waterfall-based implementations and ITIL-based support. Change continued to be slow, and support continued to be reactive, but when SAP is only supporting your core back-office applications, you don’t want to rock the global boat too much.

The advent of SAP HANA – Let’s think in memory … let’s rethink support

As the SaaS market evolved, SAP developed its “New Dimension” products and made acquisitions to cover much of the ground taken by new market entrants. Even so, the traditional ways of working continued. But on June 18^th, 2011, the first official version of the new SAP HANA database was released. Unbeknownst to many at the time, the market for SAP services was going to change drastically – and support was going to be at the core of this change.

Since SAP had an already large installed base, a lot of the responsibility to exploit the new SAP investment would fall onto this part of the market. It was still around four more years before SAP packaged up the compelling value proposition of S/4HANA and the intelligent enterprise. However, by then it was clear that while a move to S/4 and IE would deliver business opportunities, there was an opportunity to transform the IT support team at the same time. Ultimately, if this wasn’t done, then you could argue that the business transformation would not succeed.

Staying up to date – Continuous value through continuous delivery

The scope of SAP has changed because it now impacts more than just the core. So, how has the market changed, and what does this mean for an integrated delivery team?

We firmly believe that support organizations must change to ensure SAP investments can be incrementally exploited, along with keeping the lights on and business processes stable. A continuous, integrated delivery approach must see build and run activities as a continuous partnership commitment between IT (client and partners) and the business and end customers.

From an implementation perspective, many SAP trends – particularly SAP RISE – are driving towards a more managed service model in which the boundaries between MVP, pilot, roll out, and enhancement are becoming blurred. In addition, new technologies such as the SAP Business Technology Platform (BTP) are enabling rapid change that cannot be inhibited by old ways of working. The handoff between “project” and “support” is now seamless.

From a support perspective, reactive is too slow – it’s all about proactivity and business focus. SAP support services now respond to early signals – or alerts. They monitor the business process for availability and efficiency; they predict and prevent incidents. They are also more proactive around change. Monitoring and mining generate insights that feed improvements through to the build pipeline, which are delivered using new Agile, DevOps, or product-based approaches.

But is this expensive? SAP has always been seen as having a big price tag – but it has also always delivered a compelling business case. With the changes discussed, we’re talking about new services that are boosting efficiency and continuing to deliver value across an increasingly wider scope. For example, monitoring and testing tools that improve business process stability or automation tools that accelerate incident resolution ensure that the total cost of ownership is kept low. And the packaging is changing too, with pricing that is contingent upon outcomes and service levels that are based on business metrics. This ensures that value is no longer simply about “more for less,” but about driving businesses forward and creating new software-enabled opportunities.

Prioritize and rethink support, and take concrete action toward the transformation of your IT organization

So, we’ve travelled a long way, but how much has really changed? Here are the key takeaways we’d like to leave you with:

1. SAP support should not be an add-on. It’s an integral part of your S/4HANA journey
2. Think different about S/4 and think different about support – new skills, new ways of working, embedded QA and innovation, and new tooling
3. Don’t just think about business transformation – but ensure your IT organization transforms so you don’t lose momentum.

To learn more about what Capgemini’s ADMnext for SAP Solutions offering can do for your SAP support, IT transformation, and business as a whole, drop me a line here.