Leverage Incremental MVP to Enable Agile SAP Product Implementation
A Minimum Viable Product (MVP) is a concept or technique to learn the development of new product or website with sufficient features to satisfy the clients. The complete set of features is designed and developed after considering feedback from product's initial users. This allows the team to collect the maximum amount of validated learning about clients.
A Product Owner (PO) who finds it difficult to pick and articulate the first set of Epics and user stories during the early days of an agile SAP project. Therefore, such moments of foundational crisis can be addressed by envisioning the Minimum Viable Product (MVP).
Incremental MVP for Cash Application Process
Cash application is a process relating to Accounts Receivable (AR), where incoming payments are applied to the corresponding customer invoice. Whether it is a cash or wire (EFT) payment, the Accounts Payable (AP) assistant and the AR assistant perform monthly bank reconciliation. Organizations should continuously update and monitor the processes to ensure that they accurately reflect business operations.
AR cash application process, also known as Lockbox process in the US is viewed by a FICO Functional Consultant Persona. The Functional Consultant typically treats the entire cash application process as MVP because it is a singular Report, Interface, Conversion, Engagement, Form (RICEF) or functional design document, in a classic project task list. Hence, the whole nine yards that emerges from blueprinting becomes the MVP. However, the challenge is to figure out how to deliver the entire process in a single sprint, as it is too extensive to consume at one go. Inclusion of the User Acceptance Testing (UAT) within the sprint may further compound the challenge, resulting in the team rejecting agile as a way forward.
Instead of viewing the entire process as single MVP, businesses can view each step as a progressive MVP by integrating the data file from the bank during initial sprints and performing a UAT just for piece of the process flow (an inbound interface). The user experience from UAT will give a perspective of the received data. This perspective will help users to fix data concerns upfront rather than letting it flow into the system. Most importantly, we get further insights into how the process should work forward, assuming the data received will aid in better articulation of subsequent stories. Compare this to the conventional approach and the immediate benefits of agile will become visible. While earlier any gap in data file would have been realized only at the very end during UAT. Agile enables better learning by adapting quickly even when a lot of work has gone into building the entire process.
Once this inbound interface is built and accepted that is UAT is completed, the next few sprints could revolve around processing the data using out-of-the-box SAP logic and building any custom extension logic. For example, if the business process is to match a payment to its invoice based on three custom attributes A, B and C, each could be achieved as a separate story and business can prioritize which one to consume first. For example, if 70% of the matching is aligned to Attribute A, 20% to Attribute B and remaining to Attribute C, then the initial sprint can be built to test Attribute A-based logic. The next sprint can add Attribute B-based logic to the already working Attribute A logic and so on.
It is important to note that without the Attribute A-based logic in place which accounted for 70% of matching, there is no MVP. But once that is in place, the Product Owner from the finance business team can decide the need for Attribute B-based logic which accounts for 20%. If the existing application has a match rate of less than 70%, there is a strong case to have MVP with just the Attribute A-based logic and move the package to production; subsequently work on the other stories in incremental sprints. However, if the existing process has an 85% match, it is crucial to build Attribute B-based logic for a viable solution. Therefore, features can be sliced vertically for developing and testing within the sprint resulting in an incremental “cash application” process.
Product Owners can leverage the same slicing logic across each of the other Order-to-Cash (O2C) processes to help define MVP at the track level. Expand the same approach across tracks like Procure-to-Pay, Record-to-Report and so on. We can create a release or project level MVP through O2C Process. The intersection of the expanding bubble between tracks will grow as we learn from our initial sprints and retrospect our learnings.
Progressive MVP View: The Ideal Pivot Point
The positive aspect of the MVP view highlights that it is not just a good pivot for executing teams, but also for the Project Management Office (PMO) and the Steering Committee. Every Enterprise Research Planning (ERP) project has its share of rough weather. So when the dark clouds hit the project, the PMO or steering committee can look at the MVP to initiate time-cost-scope negotiations.
For example, move the cash application MVP to production with just 70% match based on Attribute A and the remaining attributes after going live. Conversely, if the cuts start to reach a point where the product is no longer viable, PMO can look at other levers to manage the project without further reducing the scope. Thus, this way, MVP becomes the control point and at same time a vertically sliced part of scope which can be consumed by development and testing teams, delivered within a single sprint.
Learn how to elaborate MVP in SAP S/4HANA finance context and what to avoid in the initial versions of MVP, including the key risk of assuming that MVP is a static list. If you’d like to leverage incremental MVP model with your SAP applications, then feel free to connect with us on LinkedIn.