Skip to Content

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

First of all I want to tell you that I am very happy about the various comments I received so far. This was really great inspiration and the discussions are a big benefit for me an all other interested readers. Thank you very much! And please don’t stop to publish your interesting questions and share your ideas about this approach! 


Not just to have a higher number of hits but to refresh or review  what has already been discussed about the Building Blocks of BPM Transformation I politely recommend to read  SAP’s BPM Approach: The Building Blocks of BPM Transformation – Part 1, SAP’s BPM Approach: The Building Blocks of BPM Transformation – Part 2 and SAP’s BPM Approach: The Building Blocks of BPM Transformation – Part 3 of this blog series before. Otherwise I had to repeat many ideas again which would perhaps be boring for those of you that already know about the background. 


SAP’s BPM Approach: The Building Blocks of BPM Transformation – Part 3 tried to explain, how 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. I picked the Building Block 2 “Human Capital Allocation” as an example for the area “People”. 


Now let’s have a look at the area “Structures”. I’ll again try to give you some detailed examples about what has to be achieved to increase the respective level of process maturity for the Building Blocks located in this area. 




The effectiveness and efficiency of processes depends on the organizational structures where it is embedded and executed. These structures encompass mainly

–        the hierarchic structure of the company (divisions, departments, teams etc.),

–        the assignment of tasks to roles or bodies (division of labor),

–        how interaction and collaboration between them is organized (SLA’s, etc.),

–        and how these tasks have to be fulfilled (standards & guidelines, policies, service regulations, etc.). 


Perhaps it makes sense to mention briefly how the area “Structures” is interconnected with the area “People” (discussed in the former blog). People (Human Capital) can be seen as the “raw material” (sorry for that!) which is assigned to one or more role (and/or body). One role can also be shared by more than one person (job sharing). Roles and the assigned persons belong to a specific division, department or team. And bodies can belong to one or more organizational unit. 




To give an example, let’s have a look at the first Building Block of this area, “Organizational Structures”. 


Seen from a functional perspective companies normally are structured along R&D, Development, Production, Marketing/Sales, Accounting, etc. Next to these you find Service Units like HR, Controlling, IT, etc. Sometimes you may also find additional dimensions like regions or product lines on the lower levels. This kind of functional structure contributes to specialization and leads to various interfaces between these units to (re-)map the value chain of the company. 


Seen from a process oriented view you may start with the value chain and the process domains of the company. A process domain can be characterized as a bundle of processes with a high degree of interaction between them. The processes of different process domains have a significantly lower degree of interaction.


Identifying these process domains leads to an alternative organizational set up and structure for a company. The need for interfaces between process domains is far lower than in a functional structure. 


As we all know organizational structures are in parallel power structures. And therefore the transition of an existing company that is more or less organized in the classical way can’t be achieved in a single step. Transforming it into a process oriented company has to consider these power structures and has to anticipate the conflicts that will arise.   


But these conflicts are necessary and you should not avoid them at all. Things can only change if process owners on the one hand side and functional managers on the other hand side have to fight for budget, cost allocation, headcount, responsibilities, and so on.


The resulting kind of matrix organization is perhaps not only an intermediate stage of the BPM transition, but can be a long term and successful end-result. And be aware that process oriented structures are not always the most beneficial set up for all parts of the company. There may be divisions and departments where the benefits of functional structures and specialization outweigh.  


Need for changes: 


Here my summarized recommendation of what has to be achieved for the Building Blocks in the “Structures” area to contribute to a higher level of process maturity (see SAP’s BPM Approach: The Building Blocks of BPM Transformation – Part 2 for an overview):


  • Organizational Structure: 1. Establishment, extension or adaption of organizational units that have their main focus on BPM tasks. 2. The execution of business processes takes place within the boundaries of existing organizational structures. Optimizing an existing process or introducing a new process often indicates changes within the existing organizational structure.  3. Transition of functional structures into process domains where beneficial.
  • Decision-Making: 1. Establishment of decision making bodies to prioritize and decide on process activities and general BPM items. 2. Decision making in a process oriented company takes place mainly along E2E processes and not within functional units.
  • Roles and Tasks: 1. Establishment of BPM specific roles and definition of their tasks, responsibilities and competencies. 2. Definition and assignment of operational BPM roles with cross functional tasks, responsibilities and competencies. Especially the establishment of process owners is a prerequisite on our way towards a process driven company.
  • Interaction of Corporate Units: Establishment of engagement models to drive cross functional coordination and interaction along E2E processes and to have regulations in the case of conflicts.
  • Budget and cost allocation: Budget and cost allocation with focus on E2E processes instead of functional units.
  • BPM Methods: One globally used procedure model about the handling of business processes during their whole lifecycle (PML – Process Management Lifecycle) , including methods for the analysis, design, implementation and execution & monitoring of all SAP business processes to ensure maximum efficiency and effectiveness of process projects and process execution on an enterprise level.
  • Process Terminology: Clear and consistent definitions of BPM terms to ensure a common language which contributes to an improved interaction between employees. This leads to increased quality of project results, enhanced interconnection of corporate units, and between Business and IT.
  • Tool Conventions: Establishment of standardized conventions that describe how business processes are formally documented are a prerequisite to enable cross area comparison and analysis of business processes and project results to identify reusable processes, harmonize processes and to realize synergies on an enterprise level.
  • SAP Process Map: The Creation of a highly transparent, hierarchical landscape of SAP’s end-to-end business processes on defined levels of granularity and their interconnection contributes to an evolution towards process centric operations across organizational boundaries.


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

You must be Logged on to comment or reply to a post.
  • Hi,
    This is with reference to your following observations,viz,
    3. Transition of functional structures into process domains where beneficial.
    Budget and cost allocation: Budget and cost allocation with focus on E2E processes instead of functional units.
    The competition and the innovations in the  “product and Technology” often fashions the Processes and the models.Without them the processes and the models would remain far simpler.In real world however these compulsions are ubiquitous.
    Any pro active management would strive to be a differentiator and try to be a trend setter.
    Having said,the functions are vital for a contrieved R&D,upgrade of technology,the skillsets,imparting traning etc.
    If the budget is provided strictly with a focus on E2E processes instead of functional units,how can the above be achieved?How can the firm remain current with the market and the customer’s expectatios? Rather the budget should be one,namely,Strategic and Top down.If Budget does not envisage the enterprise view,the firm for sure is lost.
    Extending the above logic,in a firm which has a reasonably good process maturity,the competencies as centers of excellance is vital to support the sustinance and the growth of the maturity level;as much,the functions should remain independent and distinct;the transition of functional structures into process domains may not yield the desired results.
    • Hello Ramseh,

      thanks for questioning the idea of a “total” process orientation of a company. This is a very helpful discussion to understand, that there is not only black and white possible.

      As I already mentioned in my above blog, there is not always and in any case a clear benefit of process orientation. In most companies you’ll identify some organizational units where the benefits of functional structures are more beneficial. To enhance the degree of process orientation can then be something in addition.

      And furthermore I’m not recommending to transform any organizational unit or building block to 100% process orientation in every case. There may be some areas where it makes much sense to operate them in a mainly process oriented way and some there the functional way should overweigh. Even if you reach the highest possible process maturity level for a building block, there will remain functional aspects. As mentioned in the blog you often find a kind of matrix orgainzation in reality.

      As I see it, depending on the market situation, the strategic goals and other influencing factors one needs to find the perfect  mixture between the two extrems (this would be good stuff for a follow up discussion!). But there are no proved experiences and there is no general rule or algorithm available how to do that.


  • Hi Thilo
    Thank you for a most informative blog. As far as I am concerned the topic you are addressing in this particular article (the people/structure issue)is the most difficult aspect of establishing process orientation in a company. We all know that we need process owners. As is clear from my experience and also from the comments from Ramesh, that is not always easy to achieve. As you said, a “matrix” organization is probably the best way to leave things.

    In my experience there is a third dimension to this picture. In most organizations, there exist different processes with the same process step. For example, you could have a process for the creation of a purchase order from a purchase requisition, or the creation of a purchase order without a purchase requisition. The common step is the creation of the purchase order. Since it is conceivable that the two processes might be owned by two different process owners (not likely for this example, but in general quite common), there is always the danger that the step might be executed differently in the two processes. This creates issues for reporting and analytics, since we might be comparing apples with oranges.
    In short, my question is: Who owns the process steps? I have been involved in projects where we tried the concept of a “role owner”, where a role constitutes a collection of related process steps, almost like a role in SAP authorization. However, now we have a three dimensional matrix structure, and that becomes cumbersome and confusing.
    Any thoughts?

    • Hi Marius,

      first of all thanks for this crystal clear description of the topic and question. This topic and therefore my answer is really a little complex…sorry in advance.

      Let me perhaps start with the concept of Process Ownership (Building Block “Roles and Tasks”) and the Process Landscape (Building Block “SAP Process Map”). Both are structured as a hierarchy. You have different levels of granularity in a process landscape (e.g. Business scenario group, business scenario, process, subprocess…) and related to these levels you may define and assign different levels of process ownership (e.g. Senior PO, Operational PO, Technical PO…). If you deal with a process step, this schould be done on an operational or technical level (if the step is IT supported).

      But as you write, there may be similar activities or process steps that could be reused in different processes to realize synergies and to harmonize/standardize these process steps and possibly  also the IT implementation behind it.

      If this reusable process step is IT supported and can be realized as a Werservice this is the point where BPM is blended with Enterprise Service Oriented Architecture (Enterprise SOA). But also if it is a manual process step it makes much sense to execute it similarly all over the company.

      To ensure this, you do not only need a Process Map that represents end-to-end processes, but you need next to it something like a “Building Set” of single process activities. These pieces are the raw material to compose/assemble your end-to-end processes in the Process Map. If you use a process modeling tool that uses a database (e.g. ARIS Designer) these objects can be found in the repository of this tool. Tools that are limited to graphical representations of the process are not sufficient in this case.

      If a process owner wants to change on of these “standardized” pieces of the “Building Set” you need to ensure (process governance) that he or she first of all examines in which end-to-end processes this piece is used. Therefor a database report of the modeling tool can be used. Then all operational and/or technical process owners that may be affected by this change have to find a joint solution to avoid the emergence of unnecessary variants of this process step.

      Kind regards, Thilo