Skip to Content

SAP’s BPM Approach: The Building Blocks of BPM Transformation – Part 3

In my SAP’s BPM Approach: The Building Blocks of BPM Transformation – Part 3 I defined the Building Blocks of BPM Transformation as … 


…the essential and interconnected elements that have to evolve in a coordinated and gradual way to enable increasing maturity levels and benefits of BPM across functional units on an enterprise level.  


As already shown in SAP’s BPM Approach: The Building Blocks of BPM Transformation – Part 2 we identified around 30 Building Blocks that have to be considered to turn SAP into a process driven company.  



In this part I want to focus on the area People and try to give you an examples with some details about what has to be achieved to increase their respective level of process maturity (which in parallel contributes to the overall process maturity of the company).



The effectiveness and efficiency of processes depend on the behavior, motivation, skills, abilities and competency of the people that design, implement, run and monitor them. These people can be located within the organizational boundaries of the company or can come from outside, e.g. customers, employees from partner companies or outsourcing partners.  


To give an example, let’s have a look at the first Building Block of this area, “Human Capital Allocation”. In companies that are organized in a classical, function oriented manner (e.g. R&D, Development/Production, Sales, HR, Accounting…), headcounts and employees are normally assigned to these functional units. But the result of this procedure is often not what you needed to operate your processes as good and efficient as possible. The problem starts with the definition of roles and the recruiting of employees.  


Seen from a functional perspective companies normally tend to specialization in defining roles and headcounts. This is something covered by the tightly interconnected Building Block “Roles and Tasks” which you can find in the area “Structures” of the above figure. As these role definitions are the basis for job advertisements and for the recruiting, you will receive applications from candidates that are attracted by this job description and most probably you will decide for the specialist that fits best to this defined role. 


Seen from a process oriented view highly specialized roles and employees are a con. Next to other effects this results in too many business interfaces with all the disadvantages involved (e.g. increasing wait times, total cycle times, loss of information, error rates, etc.). To increase the performance and quality of your End-to-End process operations you often need to recruit and assign case workers that are able to deal with a broader range of the process flow and across functional boarders. This can also result in changing team structures towards integrated teams (covered by the Building Block “Organizational Structure”).  


Need for changes: 

Here my summarized recommendation of what has to be achieved for the Building Blocks in the People area to contribute to a higher level of process maturity:


  • Human Capital Allocation: Assignment of employees not on functional business units or application oriented IT units but along E2E processes.
  • Skill Profiles: Development of skill profiles to meet the requirements of process-centric operations.
  • Training: Set up and execution of trainings for employees to meet the required process oriented skill profiles, including BPM methods.
  • Knowledge Management: Creation of new and (re-)documentation of existing knowledge along E2E processes to re-use it.
  • Performance Management: Definition of personal goals on the basis of process related goals and process performance indicators.
  • Communication: Provide information about BPM, promote collaboration along End-to-End processes and enable active participation to support the transformation towards a process driven company.


In the next blogs we’ll have a look at the other areas (Structures, Processes, Technology) and discuss some more examples. I’m looking foreward to your comments!

You must be Logged on to comment or reply to a post.
  • Hi Bischoff,
    Thanks for having started this Blog.

    Assuming the Goal of a process has been defined and understood properly, the key performance indicators vouch for its implementation of the process in the desired way. Therefore in order to have high maturity level of the processes, the indicators shall be unambiguous and adequately cover / reflect the criteria for process performance. More proactive they are, more will be the scope for process improvement and should lead to innovation. A simple but timely reporting mechanism focusing on lead indicators will facilitate higher level of process maturity.
    However as the complexity of business increases, the process defined to achieve specific goal has to accommodate multiple routes which was probably not envisaged at the time of designing of processes. This (dynamic) nature of variation in todays business processes necessitates quick introduction of variants to achieve the specific goal. To cite an example, let us take a “sales incentive process” designed with a goal to “motivate high performing sales personnel”. At the time of designing the process say a list of factors that would get classified under forcemajore, if included will complicate the process design as well as measurement criteria. The process owner shall get visibility to the environment under which certain performance happened and should be in a position to make changes in the measurement criteria, in the interest of the organisation – Timely as well as quickly, ensure faith over the process performance by the people and thus pave way for sustenance and stability of the process. To elaborate more : “An order bagged by a newly sales executive, but happened as a windfall due to sudden decision of the client and not thro’ normal engagement process”. The process owner rewarded the new sales executive and motivate him, but the computation of the reward was  quite different from the one mentioned the normal process. Similarly, due to advance monsoon in a certain region, the Air conditioners sales team in that region that just managed to accomplish 75% of the target, was rewarded with a moderated % (exceeded 100%) of achievement, for that quarter. In reality timely management of such situations is possible only with help of data (on factors not envisaged) as well as capability of the process to accommodate process variants without compromising the goal as well as keeping the basic design in tact.

    Another basic principle in ensuring process maturity at the time of design is to ensure that the process goals do not conflict. Or in other words the balance between conflicting goals are defined and brought out in measurement. Again the capability to house a flexible process between start & the end of the process assumes major importance.

    Those BPM Suites which can accommodate such dynamic variations in process and help the owner to implement the process change on the fly will emerge as winner.

    T Raghu Raman

    • Hi Rangu,

      this is an extremely helpful comment! Thank you for taking the time to describe these relations and additional abilities of processes that make the difference! In today’s globalized economy something like the degree of IT agility and business flexibility is highly important not only for processes, but for the whole company (as processes, people, structures and technology are tightly interconnected).

      And I can also fully agree to the secound  principle you explain. It has to be transparent which goals for a process are related to each other. I would say that you can find at least 4 to 5 different kinds of mutual dependencies  between these process goals:

      – Which ones compete with each other (for example, if A rises, B falls)?
      – Which ones mutually support each other (for example, if A rises, B also rises)?
      – Which ones are independent of each other (for example, if A rises, B remains the same)?
      – Which ones are mutually exclusive (for example, either A or B)?
      – Which ones are a subgoal of another goal

      I would see at least three layers (goal hierarchy), that should be distinguished when defining goals: strategic, business and process goals. This leads me also to the idea to come to a goal driven approach for process modeling.

      Kind regards,

      • Thanks Thilo.. You have added clarity with your comments.
        This discussion so far has brought out a) Flexibility to accommodate process variation without compromising on the objective of the process b) Process shall be transparent enough to depict the tradeoff between plausible conflicts among goals.

        Another aspect that comes to my mind is “testing of processes”. If there is a magic tool that can test all failure modes (FMEA?), a process can be expected to come close to highest maturity level even at the time of release. However one can not eliminate the ‘time factor’ and obviously the feedback mechanism built in to the process shall pave way for continuous improvement and thus move towards higher level of maturity.

        May be as and when the points crosses my mind, I intend to add them. Meanwhile if you could bring out, how they are (planned to) addressed in the BPM model so that as we proceed, the model also get matured.



        • Hi Rangu,

          SAP’s BPM model is called the “Process Management Lifecycle” (see also our blogs “Process Management Lifecycle (PML)” and  “Details on New Process Management Lifecycle”).

          Your above mentioned point b) “transparency on goal relations” is already covered as a defined task in this methodology. To be more concrete, we have a so called PML Methhodology Handbook for internal use where this is described in detail. We also plan to offer tools where you can visualize these goals relations in a transparent but easy to use way.

          Point a) “flexibility” is not a fixed requirement that is defined directly within our BPM framework. But indirectly it is covered in a kind of checklist we provide for our employees when they think about general possibilities for process optimization. And at the moment it is also mentioned in SAP’s midterm corporate strategy. Therefore if you derive the process goals from the relevant strategic goals you will consider this aspect too.

          To add also this: The PML, our BPM methodology, can refer to itself. This means that the PML methodology can be applied to enhance its own maturity. –> Using the PML we can  continuously optimize the PML processes and procedures themselves. Sounds a little bit crazy, I know…

          • Thilo,
            Had a look at PML and the details on the New PML. Looks fine on paper. However the success lies in bringing the “Business & IT” together. May be once most of the teams able to reach a level, clarity will emerge; interfaces and relationship between various aspects viz PML, Modeling etc would have been well articulated and the final shape can be visualised by all. Hope the day is not far of.