Most of us are familiar with this situation. We’ve just unpacked a box from a certain Swedish furniture store and are standing there, looking at all the pieces. We’re wondering how all these components are going to fit together to make the cabinet/table/chair we want. But thank goodness there is an illustration that gives step-by-step directions on what to do. This instruction sheet is precisely where an end-to-end process model begins. Its goal, too, is to explain processes step-by-step. And to lead to a specific result. This kind of documentation is aimed at presenting to all stakeholders an easy-to-understand and transparent overview of all processes and how they’re interconnected. Sounds plausible enough, right?
But let’s be honest. Not everyone agrees when it comes to modelling end-to-end processes. In general, there is much controversy over granularity when mapping processes. Whereas classic IT proponents are satisfied with a logical list of technical objects, most employees in specific user departments see it differently. They want a clear depiction of all processes, especially as they relate to business requirements.
So, who’s right? The answer is, as so often in such cases: Both. And… It depends.
Here’s why: Each modeling method has its merits. Depending on the specific scenario at hand. At the heart of this discussion lies both the problem and the solution. An approach that can satisfy all needs can also lay the foundation for classic IT that aligns with business requirements. In other words, both sides can unite to create a solution that works for everyone. In this respect, the Solution Documentation functionality in SAP Solution Manager has always offered a reliable way of doing just this. Even if organizational and technical conditions are less than ideal. Such as the process hierarchy having only three levels. But everyone knows that by SAP Solution Manager 7.2 at the very latest, this problem will have been resolved.
Below is an outline of how best to document your processes so it really benefits your company. It essentially consists of five steps:
|Create a technical basis||establish a system landscape
|Identify system usage||
Conduct a usage analysis
Define core processes
|Form a process model hierarchy||From scratch or template
Depict processes and functions to reflect your organization’s reality
|Construct a graphical process model||Show workflows with interconnections
Illustrate the distribution of roles and systems
|Activate subsequent functionality||Plan and activate usage scenarios
Incorporating feedback for configuring the Solution Documentation
But what’s the right kind of Solution Documentation for me? Is it a more modular hierarchy of business processes? Or is it a graphic model of workflows? Here, too, the decision will ultimately be based on specific objectives. Both prioritization of components and degree of detail have to be geared toward whether process documentation is intended for monitoring purposes or whether it’s to be used for Test Management or Change Management. So a simple answer will not suffice. After all, requirements differ, even when it comes to Test Management, depending on what kind of tests are to be conducted – technical regression tests or integration tests including role distribution.
Common to all process model types is the need for a sound and broad information base. In order to coordinate standardized data with customer-specific usage and system modifications. In all seriousness, this kind of alignment can be compared with putting together ready-to-assemble furniture and fitting it into a spot within your own four walls. Defining a Solution Documentation should never be an end in itself, but should be done with a specific objective in mind. Only then does the effort really pay off.