What have two meteorites got to do with SAP & S/4, and how to deliver continuously?

SAP has a 50-year history of success. The “SAP market,” whilst not quite that old, is very mature and is something that SAP AG created to support their growth, recognizing early on the importance of partners to success. The role of partners has evolved over this time, and in a recent set of videos that David Lowson and I did we discussed how the #SAP world has changed and how there’s now an increased expectation of a continuous flow of benefits, which is driving us towards a continuous delivery mentality and approach.?

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

Everything was simple 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 “packaged” application on, in most cases, a global basis.

At the start of this process, we had 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, we were building new, fresh client server landscapes, and so benefits were delivered immediately.

?In this world, support quickly became reactive. The focus of clients, and the wider market, was to roll out the integrated SAP platform as widely as possible to gain the most benefit from integration as fast as possible. We accepted some incidents would arise, we kept the lights on, and we implemented trouble-ticket-based support services that were successful and served their purpose.

SAP was now the key vehicle to support the globalization of business as Y2K and the millennium bug came and went, but as with any services there is a maturity curve and, as we sought to improve return on investment on these applications, we started industrializing delivery and utilizing different lower cost delivery locations. We started to enter the Rightshore? age!

?The “separation of responsibilities” trend had already started, but the drive for industrialization increased the momentum significantly. Previously, support and development teams were the same team, but due to a need to focus on rollouts, whilst 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.

Meteorite no. 1 – Software is evolving quickly … support models less so

The growth of SAP continued rapidly, but this led to diverging objectives across the SAP market – development v’s support. Whilst 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 examples, 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 meteorite number 1 – software as a service #SaaS – as the business decided to spend its IT budget directly with new providers and so procured their own “new” departmental systems outside of the core SAP platform. Even the #CIO came under threat from the Chief Digital Officer - the #CDO.

Even though the approach to SAP support had indirectly contributed to this meteoric re-modelling of 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.

Meteorite no. 2 – 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 covered by the new market entrants. Even so, the traditional ways of working continued. But on June 18th, 2011, the first official version of the new SAP #HANA database was released. Unbeknownst to many at the time, and still to quite a lot of people, 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 for four more years before SAP packaged up the compelling value proposition of S/4HANA and the Intelligent Enterprise, but by then it was clear that whilst a move to #S4 and IE delivers business opportunities, there is an opportunity to transform the IT support team at the same time. Ultimately, if that’s not done, then you could argue the business transformation will not succeed.

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 that mean for an integrated delivery team?

We firmly believe that support organizations must change to ensure that the SAP investment can be incrementally exploited and to keep 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 enhancements become blurred. In addition, new technologies such as #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 now about proactivity and business focus. SAP support services now respond to early signals – 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 to be delivered using new Agile, #DevOps, or product-based delivery approaches.

But is this expensive? SAP has always been seen as having a big price tag, but its success demonstrates a compelling business case, and we are talking about new services that increase efficiency and continue 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 all ensure that the total cost of ownership is kept low. And the packaging is changing, too – more pricing based on outcomes and service levels based on business metrics ensure that value is no longer simply about “more for less,” but about driving businesses forward and creating new software-enabled opportunities.

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

1.??????SAP support should not be an add-on. It’s an integral part of your #S4HANA journey

2.??????Think different about S/4, think different about support – new skills, new ways of working, embedded QA and innovation, new tooling

3.??????Don’t just think about business transformation but ensure your IT organization transforms so you don’t lose momentum.