A couple of years ago, presentations about SAP S/4HANA were full of detailed slides showing the technical advantages of the HANA in-memory database, highlighting the specifics in the new data models, and praising ACDOCA with almost-religious fervor. Subsequently, the focus shifted to more practical benefits, typically related to speed, efficiency, usability, and real-time access to data. Today, most of the clients I speak with have much wider ambitions for S/4HANA in realizing a modern, scalable IT platform, and in helping them expand into new businesses and business models.
I’m really happy this is the case! The transition to SAP S/4HANA is not a technical upgrade, but a holistic opportunity to unleash the full potential of technology, to move toward the intelligent enterprise, and, with the application of right architecture and modern development principles, to realize a Renewable Enterprise that is agile and adaptive to changing business environments, and supportive of new business models.
In the previous blog post in this series, I wrote about the different technical approaches to S/4HANA transformation (greenfield, brownfield, etc.). This time, I will focus on how to choose the right approach – in other words, how to make sure you are on the right field!
As I’ve written previously (blog), clients no longer ask if they should move to SAP S/4HANA, but rather how and when they should move. The majority of companies still require a business case be put together to justify the investment, and the how (when interpreted technically to refer to the transformation approach) very heavily ties into and depends upon the objectives of the transformation, as well as some other factors, which I structure into following loose categories:
- Business considerations
- IT considerations
- Technical considerations.
The key question to address at the beginning of any SAP S/4HANA transformation journey is the current business strategy and operating model, and the ability of the current ERP platform to support them. The larger the gap, in general, the stronger the rationale for choosing a greenfield approach. Ongoing or recent business transformation initiatives and major business reorganizations, as well as shifts to completely new businesses and business models are often situations in which a brownfield (conversion) approach is not sufficient.
Today’s fast-changing business environments necessitate similarly fast development cycles in ERP, to support fast go to market of new products and services. Often, the current architecture, the historical ballast of data and custom developments, the lack of process harmonization, and an inability to leverage modern development principles supported with test automation, result in very long release cycles. In these circumstances, an evolutionary brownfield approach might be inefficient in changing all this to realize a modern, scalable IT platform – hence suggesting greenfield.
An organization’s readiness for change is a key success factor for any project. If, for example, the business has just completed an ECC global implementation and rollout, it might not be possible to get business buy-in for a greenfield approach, which typically requires much heavier business involvement. In this case, a brownfield approach with minimal business disturbance and with heavy focus on subsequent development phases to realize business benefits might be better.
The preferred (or possible) deployment approach is one of the strongest drivers when selecting the overall transformation approach. In many companies with complex, highly-integrated (across business functions, geographies and business partners), fully global, and time-critical supply chains, a greenfield approach is simply not feasible: the global big bang is too risky, and would require extensive business downtime to properly set up and ramp up all the hundreds and thousands of interfaces and integrated processes in a controlled manner. What’s more, any phased deployment approach (divided, for instance, by organization or business function) would require interim solutions that are too complex to reliably sustain over the required periods of time. In these cases, a brownfield approach, with heavy exercise for data and custom code cleaning, data archiving, and migrating custom development to the cloud platform, is probably the best option. At the same time, for others, from the perspective of change management, testing, and training, only a phased approach is feasible, indicating a greenfield approach.
One of the key considerations from an IT perspective is the possible need for ERP landscape consolidation and simplification, in terms of transition from multiple ERP instances to one (or at least, to fewer) instances. In such cases, greenfield or landscape transformation-based approaches are most suitable.
Architecture models and cloud strategy are another key factor from the IT perspective. An SAP S/4HANA Cloud (SaaS) implementation is by definition greenfield (the selection between S/4HANA on premises and S/4HANA Cloud is worth a separate blog post of its own!). It’s often the case that full IT landscape re-architecting (including technology and platform selections, definition of common vs business-area-specific application principles, and the move toward a microservices-based architecture) is best supported via a greenfield approach.
ERP development is quickly moving toward agile and DevOps models, and business expectations for release cycles are shortening from years and months to weeks and days. This means IT needs to change its governance and organization models, to find new competencies, to develop different ways of interacting with the business, and, of course, to mature in areas of tooling such as test automation. It is in principle possible to evolve toward this kind of model, but often it is simpler to apply these principles and development models from the beginning in a greenfield-based approach, and to continue applying them after go-live.
The technical quality of the current system often plays a surprisingly big role. Years and decades of iterative and overlapping development, under changing management and by various partners, with low compliance to (or lack of) common principles, and the tendency of customization rather than adherence to standards, combined with other technical debts, have resulted in fragile systems that are very difficult to develop any further. In these circumstances, realizing strategic business benefits via system conversion is often impossible, necessitating a greenfield approach. On the other hand, to avoid being forced to do greenfield, many companies have often undertaken massive exercises to clean up, harmonize and standardize the current systems, so as to enable a system-conversion approach.
Data considerations are often at the center of the transformation approach decision. Data volume and quality directly affect the effort and cost of the transformation in every scenario. Typically, this is especially the case for greenfield approaches, where the data volume is minimized whenever possible. On the other hand, even with brownfield, the data volume should be reduced by archiving, so as to increase data quality, to reduce the HANA database size – and to reduce downtime to a level acceptable by the business.
When considering a brownfield approach, the importance of the maximum system downtime acceptable for the business should not be underestimated, and the required downtime should be validated via a proof of concept. The shell-copy approach (with migration only of selected data) can help dramatically to reduce the downtime, and if required additional services exist to achieve near-zero downtime. A greenfield approach with phased deployment usually enables flexibility and short business downtime, since data migration can be executed to a large extent in advance of the actual business cutover, with only the delta handled during cutover.
No two SAP customer situations are alike, and every organization needs to assess its situation to define the Capgemini Highway to SAP S/4HANA . At the same time, things are never black or white, or the field truly green or brown; but the truth and the right field always in practice lies somewhere in the middle, and the best customer-specific approach combines aspects from all of the technical approaches.
Contact me if you want to know how Capgemini can help you make sure you are playing on the right field.