Along with our friends in the SAP industry, we have spent too much of our time in the past year in the debate around the merits of a ‘Greenfield’ approach versus a ‘Brownfield’ approach for customers moving to SAP’s newest ERP platform. ‘Greenfield’ is based on the premise that it is better for customers to start with a blank slate and re-implement, while ‘Brownfield’ is based on the premise that customers should migrate their current system functionality to S/4HANA. In our opinion this ongoing ‘philosophical debate’ is taking attention and energy away from the primary customer concerns which involve the time, money and risk involved in getting the maximum benefits from SAP S/4HANA as their Digital Core. The effective debate should be based on asking and answering the question “How fast can we go?” This whitepaper lays out smartShift’s vision and approach for solving that problem.
Our customer’s business vision, strategy and plans are heavily geared towards Digitalization. This means that every industry we work in, the effects and influences of Silicon Valley are being felt. Tesla, GE Digital and Amazon are changing the game in their sectors and competitors must respond immediately. The Digital game is all about speed. With this in mind, when we at smartShift look at the best way to manage ERP technology, we start with the question we call ‘WWSVD’ – What Would Silicon Valley Do? Would 3-5 years to production be acceptable? Would implementation budgets in the 8 to 9 figures be acceptable? How about project teams with hundreds of staff? Would these timeframes and prices be acceptable while critical market and business priorities are on hold? We think not. So how do world-class Digital companies approach these kind of problems and how can we apply that thinking to ERP?
We think there are 3 key concepts in the ‘Digital Playbook’ that are directly relevant and have massive benefits for your Digital Transformation strategy. We will discuss each of them and then tie them all together in a case study.
- Minimum Viable Product
- Agile/DevOps Approach
- Automation and Tooling
SAP S/4HANA MVP
Minimum Viable Product (MVP) in the technology business means the minimum product that early adopter or beta customers can receive utility from. In an environment where speed matters, defining the MVP is a critical step in finding the fastest path to market. The MVP does not represent the end of the journey – it is just the baseline to get into the market and begin to receive real-world feedback from customers so the product can be further developed and optimized.
When customers initially think about MVP for a production ERP system, it doesn’t seem to translate well. Factory operations, supply chains and global finance teams that have been optimized over decades cannot revert to a simple, minimalist approach easily. Hence, the ‘Greenfield’ approach inherently must begin with a massive redesign effort to document a very complex MVP that the business would accept. MVP in the ‘Brownfield’ camp is similarly daunting as MVP represents rebuilding all of the functionality you have today working exactly the same way, but on a completely different technology. So ‘Brownfield’ customers now face a massive technology design effort in lieu of a functional design.
We think it is helpful to pause here and think about the move to SAP S/4HANA as two logically distinct efforts. One is a change in the technology stack – the other is a change in the functional paradigm. Combining and conflating these two distinct changes is what leads to complexity in defining the S/4HANA MVP. It is worth noting that while digital companies frequently undertake both of these they rarely combine them into a single effort, resorting to that approach only if required.
Based on this concept and the work with our customers we have defined the SAP S/4HANA MVP as a solution that:
- Does not disrupt any current key business process unless necessary
- Takes advantage of any ‘free’ or obvious process or functional improvements available in the upgrade
- Achieves the technology platform upgrade as quickly as possible
- Lays the foundation for iterative/agile improvements going forward
The most difficult part of identifying the S/4HANA MVP is that the knowledge required to understand the true costs behind these decisions is dispersed across many parties in your organization, which brings us to the next principle.
Agile/DevOps Approach
When packaged ERP went mainstream in the 1990s, the implementation approach was universally the Waterfall methodology. Today Digital Companies approach technology projects in a different manner based on Agile Development. Agile was created as a response to the shortcomings of Waterfall development, specifically:
- Waterfall is not responsive or adaptable to changing requirements or conditions
- It requires significant oversight and micro-management, increasing at scale
- It depends on highly specialized and compartmentalized resources
The Agile approach, in contrast leverages self-organizing, cross-functional, lean teams with short cycle sprints to incremental releases using evolutionary design thinking. When one thinks about business cycles today, it is hard to rationalize multi-year waterfall projects for anything if Agile is a viable alternative. The challenge is that virtually all of the skilled and knowledgeable resources in the ERP market have been trained in Waterfall, thus the dominant planning paradigm is Waterfall. The hallmarks of a Waterfall-based approach are:
- The first phase of any project is a lengthy planning and design exercise
- There are clearly delineated business, functional, application, infrastructure and testing teams and resources, usually with conflicting views and objectives
- The primary issues raised are about ‘what could go wrong’ and ‘how might I be blamed’
In contrast, when adopting an Agile-based approach we see:
- The first steps are action oriented, for example a pilot based on a defined MVP
- There is a single team with representatives from all disciplines but one common goal
- The primary issues raised are around ‘how can we go faster and do better with less’
The reason we absolutely must change the way we approach an S/4HANA project has to do with optimizing the decision making. The fundamental trade-offs between ‘Greenfield’ and ‘Brownfield’ are about the overall costs and benefits of migration versus reimplementation. These decisions are both complex as well as granular. That is for any given piece of system functionality there are different costs and benefits that require input from many angles. The only way to address this is with a cross-functional team making these cost/benefit decisions together. The problem with ‘Greenfield’ versus ‘Brownfield’ is that you have effectively made a unilateral and overarching decision on the approach for all functionality, as well as effectively enabled the traditional Waterfall-based approach to persist.
At the executive level, the appeal of Agile-based approaches is the size and cost of the teams. One of the hallmarks of Digital businesses is the leverage gained from relatively small groups of resources that do not adhere to the traditional ‘silos’ or hierarchies that we are all so conditioned to. The practice of having all specialties represented in a single team is referred to as DevOps where a single team designs, develops, tests and deploys a product. As this approach is rapidly taking over the technology marketplace, a key differentiator is emerging which can be a game-changer for ERP. A core discipline in DevOps is maximizing the use of Automation and Tooling throughout the entire process, allowing people to focus on the high-value and complex decisions and work, while delegating the lower-value work to machines. And this brings us to the final game-changer…
Automation and Tooling
When we think about the cost of migration or re-implementation of an ERP system there is a factor of scale that we just cannot avoid. These systems have massive scope in terms of functionality, data and interfaces. The most obvious example every customer can relate to is the cost and complexity of a single full regression test on a major ERP release, which is usually the limiting factor in the frequency of releases of SAP (it is mathematically impossible to do monthly releases when you have a three month testing window). Another example, and one we address daily at smartShift, is the complexity of modifying and managing the massive customizations customers have made to their system to ensure they continue to work and perform as the system is modified. The massive scale of these problems ensures that if addressed with expensive and unpredictable human resources they will take a long time, cost a lot of money and have unforeseen issues arise along the way.
However, if these problems are addressed by designing processes where machines do the bulk of the work, we can plan once and execute over and over. So while standing up an automated testing regime for a single release is not cost-effective, in a world of monthly releases investment in testing automation has tremendous payoffs. Similarly, implementing Automation to manage your customizations to make 1000 code-changes once may not be cheaper than shipping the code offshore for a given project, but over several technical and business releases Automation installed once will create significant economies. Silicon Valley companies clearly understand this approach as they use it to its maximum extent. There is no other way that they could develop and manage billion-dollar generating products with daily releases managed by teams that can be fed with two pizzas.
With respect to the S/4HANA move, Automation plays an absolutely key role in changing the game by fundamentally changing the cost/benefit decision in defining the MVP. In the classic ‘Greenfield’ versus ‘Brownfield’ perspective a large amount (if not all of) of your system has issues that require manual labor through either technical re-design and implementation or through process reengineering and reimplementation. So no matter what you do, cost is high in this paradigm. While Automation cannot redesign business processes, it can dramatically lower the cost of bringing forward existing functionality without manual effort. For the tech geeks, think about what Docker does for legacy apps moving to Cloud infrastructure. Working with smartShift, our customers use Automation to identify and categorize functionality into four major S/4HANA ‘buckets’.
- Is not actually being used enough to justify keeping – decommission
- Will migrate with no intervention – no need to change
- Can be migrated by using Automated Transformation – no need to change
- Requires significant rework – should be evaluated for re-implementation or replaced with standard S/4 functionality by redesigning the business processes.
As opposed to a pure ‘Greenfield’ approach we are limiting the scope of the redesign significantly, and when compared to a ‘Brownfield’ approach we are significantly reducing the costs of many of the technical changes with Automation while singling out the especially problematic ones to be re-implemented. Thus we are using the optimal framework for best cost/benefit decisions leading to the optimal MVP. Of course, this approach only works when we have a cross-functional team that is fully empowered, informed and bought into this approach.
For customers, the idea of taking on a new approach that is neither pure ‘Greenfield’ or ‘Brownfield’ to get to S/4HANA much faster, cheaper and with less risk has to be appealing. The real question is does it work in the real world. Lets look at a case study.
The Döhler Example
Döhler is a global producer, marketer and provider of natural ingredients, ingredient systems and integrated solutions for the food and beverage industry. They have run their operations on SAP ERP since 1993 and have a highly customized and specialized system with over 33,000 custom objects. With S/4H Döhler wants to provide a digital core system that enables them to run new business processes and even new business models.
To meet the need to get to S/4HANA Döhler assembled a core team representing all disciplines within SAP reflecting the agile principles. The team used smartShift and SAP Solution Manager’s Automation capabilities to perform a thorough analysis of all functionality in their system. Using this information, they were able to identify two sequential MVP releases that could be accomplished within time and budget windows acceptable to management.
The first release was a ‘lift and shift’ to Suite on HANA (SoH) swapping out the database layer without making functional changes to the system. This project was completed end-to-end in 3 months total time. Technical scope was optimized by performing an assessment of risk and maximizing the amount of predictable automated transformation that could be performed resulting in about 210,000 technical changes either required for HANA compatibility or ‘low hanging fruit’ to enhance performance or simplify the configuration. Because the core team clearly understood the dependencies and risks quality was extremely high with 15 total errors in testing – a clear example of the power of applying the dev ops approach.
Immediately following the SoH release, Döhler launched the sprint to S/4HANA. This release contains a more complex combination of functional and technical changes. Döhler informed this decision by running the SAP Simplification Database which identified over 5500 functional gaps to be addressed in the move to S/4HANA They then used the 4 ‘buckets’ approach discussed above. Working with this approach they reduced the functional changes requiring process engineering to the top 100 with suitable migrations for the remaining 98%+. With a four month window to make the MVP S/4HANA release this allowed Döhler one business day per process area. Döhler’s first S/4HANA release preserves all critical functionality and limits S/4HANA optimization to the most critical areas. Döhler is now moving to an iterative approach to perform incremental S/4HANA optimization as the users become more familiar with the Fiori interface, SAP release cycles for S/4HANA, or natural business changes create opportunity.
For customers that believe that their system is more complex than Döhler, we would counter that Döhler’s level of customization puts them in the top 5% of enterprise SAP systems and that the biggest global systems never have more than 4x Döhler’s level of customization. This remarkable case is a function of taking a fundamentally different approach resulting in a markedly different and faster outcome.
Please contact us if you are considering the next step to S/4HANA, would like valuable insights from our experienced team, or want to learn more about smartShift’s S/4 automation platform!
DE