How to deliver SAP in half the time and at half the costs

The second challenge of SAP deployment using Scrum its complexity of ERP. While it’s proven, that it’s possible to come up with “one fits all” cloud solution for let us say HR area (aka Workday) there is no single software vendor in the world that can build a simple and at the same time flexible enough ERP system that would cover up majority of your business processes. Even if leadership convinces everybody to change and adapt the “best practices” to limit ERP customization the underlined complexities of building a “digital twin” makes it a daunting task. SAP consists of multiple modules and each module requires expert knowledge to configure the system and to write a code to customize it. This is where you come across another challenge that goes against secondScrum principle – small self-sufficient team.

4 Keys to delivering SAP using Scrum.

SAP is moving toward public cloud and it’s only a question of time when the individual solutions will become available across its entire portfolio. In the last couple of years SAP started assembling the line of tools to enable that eventual shift and along the way made SAP Scrum deployment possible. It’s still not a cookie cutter but it’s something we can work with.

First component is Focused build and Model Company. For as long as I can remember, SAP has had the best practices, but to use them was always a challenge. With Model Company SAP made a huge step up in the right direction of delivering starter package that is good enough to explore. Focused build and Solution Manager 7.2 are the first steps in bringing agile methodology into SAP delivery process. Now you have a starting point when you can show fully functional system to business users from the first day and ask the “why not” question.

The second component is SAP extendibility. SAP works hard to push as much as possible of its enhancements outside of core using SAP Cloud Platform, APIs, FIORI, and Mendix. You can and should deliver majority of necessary complex SAP customization without breaking any future interoperability. All these tools allow you to compartmentalize your development and what’s really important – de-couple them, from the timing point of view, from your main deployment.

Third component is an idea that not all integrations, which are the most challenging and time-consuming building blocks of any SAP deployment, should be built at once. What if we concentrate only on real time and high-volume complex integrations with MVP, use some of SAP project budget to hire temporary help, and use SAP upload programs to bring all other necessary information inside SAP or get it out? How many of your hundreds of interfaces are really critical and must be built at once?

Lastly, none of it will work with the typical SAP project organizational structure around functional areas. Instead of having project team members organized around: Order- To-Cash, Procure-To-Pay, Finance, and so forth,we may consider organizing teams around key end-to-end processes, such as:selling goods to a customer with a shipment through a warehouse, shipping goods directly to a customer, etc. Optimization of end-to-end processes, not building blocks created by functional teams, should be our top priority. These new process teams should have one of each functional area consultants and be completely self-sufficient. Consultants should have matrix reporting structure: the main one – to their process team Scrum masters; secondary – to their functional area architects. This is the fourth component.

Fine tuning these four components will take some tinkering but the core is there. For the first time we have all the components to not only support, but actually deliver new SAP implementation using Scrum. We cannot hide behind “nobody does it” and not to use this opportunity to deliver SAP in half the time for half the typical costs with almost no risk. The rewards are too high to pass.