Deploying SAP using SCRUM by building cross-functional value stream centric teams.

In the article “Why is that hard to deliver SAP using SCRUM?” I outlined my thoughts on typical obstacles of deploying SAP using SCRUM. From the first time I learn about SCRUM, I kept thinking about two key components of SCRUM – MVP and constant value to cost analysis before each sprint and how they can be applied to SAP deployments. The primary idea of SCRUM is to focus on most critical 20% of the total scope through effective backlog prioritization, while the “classical” SAP deployment targets to cover 100% of the scope through full functional design first. Saying it differently, every SAP deployment contains at least 80% of the waste from SCRUM point of view.

Next few pages contain my thoughts about cross-functional team composition built around Value Stream (VS) processes instead of functional areas as one of the first key components of SCRUM SAP deployment approach. I use the term Value Stream in this article as it is defined in DevOps Handbook – “the process required to turn a business hypothesis into a technology enabled service that provides value to the customer”. Rephrasing it from SAP practitioners point of view – if your company sells a wide array of let us say electronic gadgets with some made in-house and some bought from third party vendors, first VS might be the entire value chain from product design, manufacturing, and distribution; while the second VS may represent the company buying ready to sell products from third party vendors. I am not touching SAP Model Company in this posting, but having a “full blueprint” at the beginning of the project will simplify this approach even further and should be considered as an essential building block of cross-functional Value Stream (VS) centric implementation approach.

Something never sat well with me through all these years of implementing SAP – it always felt “heavy” and “big” but it did not seem that anybody had a better idea of how to do it. The process has been the following: analyze the entire scope of the enterprise, map business capabilities that SAP could do well, create SAP functional teams along business areas (procurement, finance, distribution, etc.), run the full scope design workshops to create a global template, do SAP global template and deployment related integration build, and finally deploy based on the business units making it as small as possible minimizing the risks of the big bang while simplifying interim process. It seemed that manufacturing roots of ERP and the desire to optimize individual functional process areas rather than the entire VS process became the paramount of SAP implementations. We took the core ERP concept of common Master Data set that was designed to enable vertical process integration within a company, from manufacturing – procurement – distribution – all the way to financial settlement, and for some reason extended it to do both vertical integration as well as horizontally optimizing the different types of manufacturing processes – different types of procurement processes – etc. Classical SAP implementation tries to go after Value Stream as well as functional areas optimization. What is important, we did that at the sake of the VS process optimization and increasing initial ERP implementation scope to a level of more than 50% of failure rate and initial estimate cost increase typically in 50-300% range.

The thinking goes that since, for example, Product Master is used across manufacturing, procurement, distribution, and finances we have to learn about all different types of the processes across all these functional areas and identify all Product Master attributes before we can be sure that we got it all right with one centralized Product Master. What if we do not need to do that? What if we can start from core attributes of common Master Data elements designed for the most important VS process and then keep enhancing those Master Data elements for other VS processes as long as possible or branching them out into a different versions of those Master Data elements, when the next VS process is radically different from the one we implemented already and does not fit in existing Master Data set up?

From the overall matrix process point of view the overall number of permutations and tasks is the same and it does not seem to matter that we start from the functional area first and then chain-link those individual areas into VS process, instead of starting from the individual VS processes and then looking for commonalities across functional areas for potential reuse and simplification. But if we look closer it does matter a lot. While the total number of tasks may seem to be the same the goals of these two approaches are radically different. If the costs of the individual steps of the process is the primary goal – then doing it the way, we have been doing it all these years is right. But if the goal is the speed and the flexibility of the VS process, then this old approach will not work. Here is a simplified example of the 3X4 matrix with three different VS processes across four functional areas.

Today during “classical” SAP implementation, we typically create four teams along the four different functional areas and optimize the processes within those functional areas sometimes paying little attention to the overall VS process effectiveness. We look for a potential reuse of certain processes within functional areas and may end up with something like that:

From the first point of view it looks great because manufacturing stream team collapsed all possible variations of the processes to just one, procurement and finance – two, and the only area that was left with three unique sub-processes is distribution. We marvel at the potential cost savings within these “simplified” functional areas, but do we fully understand at what costs we achieved these savings? Every reusable sub-process within a functional area created coupling across multiple VS processes. If we can tolerate this coupling and fully understand the consequences of it, then it is one thing. Most ERP implementations “assemble” VS processes somewhere around integration testing and at that time there is little we can do to decouple this big, now monolithic, process “web” into the flexible pieces. This approach creates another problem we face with ERP implementation – we must learn and design all those functional areas across all, usually not very well defined, VS processes up front to identify correctly those reusable sub-processes. This is what creates the large scope of ERP implementation with associated failure rates and cost overruns.

What if we approach SAP implementation differently? What if instead of starting from four functional streams and the entire scope of the enterprise, we will start with one VS process, one cross-functional team comprised of the experts from every functional team, and four functional architects/SMEs as watch dogs for a potential too “narrow-minded” implementation of functional areas. We should choose the most important VS process, the one where we believe that the flexibility and overall efficiency of the process is more important than savings within individual functional areas. We should proceed to design and build it the way we want to see it done without thinking too much about how much can and will be re-used by other VS processes. After the first VS has been fully designed our matrix might look something like that:

Once the first VS SAP process is designed, the project team must make a call:

1.     Ideal outcome - if the finance has been deployed already and the legacy infrastructure is not overly complicated for the interim process, we should be able to deploy just one VS process in SAP as a bare-bone MVP without any bells and whistles and keep running the rest of VSs in legacy.

2.     Acceptable outcome – if the first VS process has been fully designed but the overall legacy infrastructure is complex and it is impossible to de-couple legacy and SAP environments and run two in parallel with only one SAP VS process, the project team has to keep going after the design of the next VS process.

The team can go after the #2 VS keeping in mind that re-use of functional area sub-processes should happen only in cases when the business is sure that this additional future flexibility is not needed and coupling #1 and #2 VS is acceptable. The second VS should be the second most important process and ideally it should serve one more purpose – it should allow project team to deploy SAP. Once the second VS has been designed our revised matrix might look like that:

Ideal outcome after #1 and #2 VS design finished is a deployable SAP system. If this cannot be achieved due to the complex interim processes, the project team will be forced to keep going through the next VS process until first SAP MVP can be deployed. Once first SAP MVP is deployed, the project team will start managing N+1 environments and going after two tasks simultaneously:

1.     Keep designing the rest of VS processes in SAP until all of them are moved there;

2.     Adding new functionality to already deployed SAP MVP to improve business usability of the system.

The result cross-functional Value Stream focused implementation approach might happen to be the same as with the “classical” SAP implementation approach of using functional teams but with a few noticeable differences that should bring desired 10X quantitative improvement:

1.     The scope of the first MVP is smaller with a cross-functional team that owns the entire VS process.

2.     Decision making process within VS should be faster because the project team will “own” the process and can make decisions either “fitting in” specific task into existing process or de-coupling it quickly to focus on overall VS efficiency and flexibility.

3.     “One offs” of some low priority VS processes will not complicate and slow down the overall design of the important VS processes.

4.     Simplified role of SAP functional architects. They are the hardest to come by “unicorns” that, even under the best circumstances, have a hard job in front of them – keeping the VS process within SAP solid. The work of these architects with cross-functional approach becomes simpler because now it is a work of the VS team to keep VS process working; while the architects work within functional teams is to look for commonalities of the steps of the process within functional area and optimization of those processes. It is easier to spot similarities within functional areas then to identify incompatibilities between long VS processes.

There is one key qualitative improvement as well - optimization of the functional area sub-processes will not happen at the cost of losing a flexibility and the effectiveness of the overall VS process.

There are a few “ifs” with this approach and having strong functional SAP architects/SMEs that keep SAP functional processes running smoothly with minimal SAP customizations and keep an eye and identify the potential areas of re-use of Master Data elements not only across functional areas but across VS processes as well to keep the costs of running tasks within functional areas low.

My friend Leonard Zemlinsky reviewed the article and provided some valuable feedback. Among other things, he pointed out that while this approach main objective is to reduce the scope of SAP MVP and increase the speed of making decisions which is the key factor determining the speed of SAP implementation (“Three keys determining the speed of SAP implementation"), it does not address one more key concern. Cross-functional VS focused approach will almost entirely eliminate coordination of decisions across VS teams but will do nothing to speed up the decision-making process within the cross-functional team. The key question that he has raised is “how to speed up the decision making process on SAP implementation” both within and across the teams and this topic will require a separate posting.