| | JULY 20209CIOReviewSAP. As Jeff Sutherland, one of co-creators of Scrum, elegantly put it in his book "The art of doing twice the work in half the time" the prioritization of a backlog gives Scrum its main advantage ­ a concentration on things that matter. Even with all the efficiencies of small teams and kiezen nobody can all of a sudden increase their productivity by the factor of 4. The real benefit of Scrum lies in the fact that for most software projects, where the real scope is hard to define,80% of work will be never done. Majority of the improvements that users are fighting for fall off when the "good enough" product becomes available. SAP and Scrum are meant to be together ­ both of them help companies focus on what is really important. The real challenge is that until recently nobody knew how to deliver greenfield SAP implementation using Scrum.Why companies do not deploy SAP using Scrum?ERP's integrated business processes lead to the first challenge of using Scrum for ERP ­ ERP deployments love the "big bang" approach. The 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's operational processes. It is a "digital twin" of your company. 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 be implemented at once and this makes your ERP deployment big. 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. 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
< Page 8 | Page 10 >