The buzz of agile software implementation, most prominently represented by the Scrum methodology, has hit the doors of the board rooms. It is time to look at it from the business perspective.
In a nutshell, Scrum breaks down the development of software into small pieces called iterations (= sprints), which are realized and tested consecutively. With each such iteration, an incremental version of the future system gets produced. The period for a sprint is fixed in advance (typically 2 to 4 weeks).
So, what is in it for you? – With each sprint, you get a potentially usable system. Your organization definitely knows their current business processes. But even experienced and highly gifted process experts and key users will never realize the full impact of an SAP implementation on your processes.
Compared to the traditional method for SAP implementations, process experts and key users will be involved continuously through the whole project specifying requirements and influencing the course of actions as they learn about the system and its usage. They will not have to anticipate and guess what they need. They will simply understand it. Essentially, concrete and crucial decisions can be made at the time of requirements gathering rather than 2-3 months in advance. Both sides, IT and business, benefit from the paradigm of back and fore discussions.
Why should I bother about any software development methodology, when SAP is standard software? – Even standard software has to be adapted and customized to the specific needs of an organization. Scrum enables your business team as well as the SAP experts to jointly define which way to go. However, it is imperative to steer the whole project from the beginning.
Flexibility is great, but how to keep control? – A process driven approach provides the big picture while empowering your process owners and experts to design the business process transformation along the iterations in customizing. Your process landscape with the respective end-to-end scenarios facilitates the creation of the so called product backlog, which defines the actual scope of your SAP implementation. Getting a better understanding on how SAP works, your process experts will then further detail the scenarios and their processes to derive the requirements for each sprint backlog.
Process driven and agile, does this fit? – Join me in the following thought experiment. You, as the process owner for Purchase-to-Pay (P2P) along with the experts in your team define the end-to-end scenarios based on your company’s business models and the associated operating models. The basic characteristics and high level requirements will be captured in the product backlog.
Within the first sprint, the basic scenarios, such as “Purchasing of supply chain materials”, “Purchasing of services”, and “Purchasing of consumables” will be customized and tested, and user documentation will be created. Since, now you will be able to simulate the future purchasing processes, you are able to fine-tune them and are ready to design more complex processes. E.g.: ‘Purchasing of subcontracting with materials’ etc.
Under the Scrum umbrella IT folks regularly promise to deliver high quality and flexibility at lower cost. From a business perspective you definitely will deliver higher quality and accuracy in your requirements as seed of the implementation, because your team can focus on what is really meeting the needs.