Why is it hard to deploy SAP using SCRUM?

After reading two recently written articles by Gartner on using Agile methodology as part of ERP implementation – “How to Build Agile ERP Support with Product Teams” and “First Steps in Applying Agile and DevOps to ERP Support” it became obvious to me that even Gartner with all its firepower and industry connections cannot come up with a definitive guide to Agile ERP implementation. A much smaller topic of using Agile for ERP support is full of untypical for Gartner fluff. I don’t pretend that I have a ready to cook recipe for Agile SAP deployment but I believe that in the last couple of years SAP did a very good job of making more ingredients available and with some tinkering we finally might be able to make it work. But first, let’s start with a simple part – why so far nobody figured out how to deliver “green field” SAP implementation using Agile?

There are 3 main obstacles to using Agile during ERP implementations and they all are well known:

ERP is the opposite of the “best-of-breed approach” of 1980-90 we are still running away from. You buy SAP because you want to get out of running an “integration” business and go back to what you do well – running your own company. ERP’s integrated business processes lead to the first challenge of using Agile for ERP – ERP deployments love “big bang” approach:

1.     ERP deployment loves “big bang” - key concept of Agile - the Minimum Viable Product (MVP) is hard to define for ERP because of its pre-integrated business processes architecture. ERP is a complete representation of your company operational processes in a computer program. It is a “digital twin” of your company. Can you imagine starting with only let’s say Accounts Payables as your only fully functional department and then adding the rest later? You buy ERP because you want most of your processes to be pre-integrated for you, selecting one end-to-end process for MVP while leaving the rest of your processes in your legacy environment is almost impossible. Once you make a decision to deploy a new ERP “all processes” have to go and this makes your ERP deployment big.

Even though most vendors tell you that ERP is an integrated system and it’s been designed this way from the beginning the reality is slightly different. ERP consists of multiple modules, every module is responsible for certain functionality, and ERP vendor works very hard to keep all those modules working like a single program. ERP relies on Master Data and Organizational Structure to enable this cross-module integration and this is the challenge #2:

2.     Most Master Data and Organizational Structure need to be completely defined - you need to define all your processes and evaluate them against SAP Master Data and Organizational Structure before your first ERP deployment to be sure that everything works fine. For example, you may decide to go-live with only one process. Then later during your second go-live you realize that a new process has to be integrated with an existing live process and to do that some of Master Data or Organizational Structure have to be dramatically changed. To make that change you may be forced to go through difficult live system modifications and in some cases those modifications may even lead to another conversion with loss of some of ERP data. That’s why ERP deployment best practice tells you that you must define your Master Data and Organizational Structure elements before your first go-live.

Lastly, while it’s proven that it’s possible to come up with “one fits all” cloud solution for HR area (aka Workday) there is no a single software vendor in the world that can build flexible enough and at the same time simple ERP system. Even if we assume that company leadership somehow convinces everybody to change and adapt “best practice” to limit ERP customization the underlined complexities of building a “digital twin” makes it a daunting task. Either you are dealing with “Dynamics” of the world and you need to build a majority of the processes in ERP yourself so you need an army of Developers or you buy a Porsche of ERP – SAP and then you need a lot of experienced but narrow-focused functional consultants to configure ERP for you. In both cases you come across the biggest challenge that goes against main Agile principle – small self-sufficient team.

3.     ERP functional scope is too broad and complex to be delivered by a small team - Small team size of 7-9 is hard to manage during ERP implementation for two primary reasons:

a.     Required broad techno-functional expertise – ERP system consists of multiple modules and each module requires expert knowledge either to configure the system or to write a code to customize it. Business capabilities enabled by individual ERP modules are comparable to the individual legacy systems you retire by deploying ERP. The only benefit of ERP is that when ERP replaces dozens of legacy systems you don’t have to deal with integration between the modules but the “fine-tuning” of individual modules is still the work that your team has to do and this work needs lots of experts;

b.     Large number of integration points - ERP implementation resembles heart transplant so integration to existing systems is the biggest chunk of work your team has to do. Typical SAP implementation requires 150-300 interfaces to be build. The sheer volume of work and required knowledge makes it impossible to deliver it all within a small cross-functional team.

Because of these 3 major reasons I described above all ERP deployments in the world go with hybrid approach – waterfall design and testing at the beginning and the end of the project with sprints in the middle during the build phase. But the benefits of SCRUM/Agile demonstrated by Amazon’s of the world are too big to be ignored and while the clear path to ERP Agile deployment is not very well defined at this point there are a few things that we can start playing with to come closer to the ultimate prize. Look for my next posting – “Deploying SAP using SCRUM by building cross-functional value stream centric teams.” to see what Lego blocks we can play with today to not only support already live system but actually deploy SAP using Agile.