Skip to Content

If you look at the wide variety of existing methods that seem to be applicable for BPM, you’ll find different phase models, method collections, individual methods that fit to specific tasks or problems, and more or less comprehensive, integrated approaches.  Companies often use a wide spectrum of these, depending on the project objectives, scope, organizational areas or the skills and experience of the involved employees and experts. This should not question on the quality of these methods or their results, but tremendous potential will be wasted if the individual process initiatives and projects do not contribute to the formation of a big picture on an enterprise level. Myopia is very popular today and people that prove to be good firefighters or achieve quick wins and local optimization are often honored and celebrated as heroes. But this is not at all what BPM is about.

 

But, which are the basic requirements and qualities a BPM methodology should meet to enable big wins on an enterprise level and, to ensure that all these single initiatives and process projects within a company contribute to the roadmap towards a process-oriented company?

 

When developing SAP’s Process Management Lifecycle, we made the following experiences:

To attain the maximum impact at a company, a BPM methodology must…
  • …be an entire end-to-end life cycle model.

Mainly project-oriented methods that don’t really cover the execution phase of a process will not be enough. To achieve long term effects and to effectively manage the ongoing evolution of a business process, you need to ensure its continuous measurement, monitoring, and verification.

  • …include both, the process and its relevant environment.

Methods that concentrate too strictly on the process itself are not sufficient. A good BPM methodology always has to consider the interdependencies between the process, the organizational structures in which it is embedded, the skills and abilities of the people who execute it and the technology that supports it and enables it.

  • …enable comparability and reuse of deliverables.

Process models, project results, performance data and other deliverables have to remain comparable and reusable over time. A common framework and comparable results throughout the company are a prerequisite for efficient collaboration and help to capture cross-functional synergies.

  • …be open and flexible to the use of existing methodical know-how.

This seems contradictory to the above, but it’s not. It simply means that a good BPM methodology must define a set of comparable and reusable deliverables, but does not necessarily dictate the manner in which these deliverables are achieved. The advantage: existing expertise and experience within the company can continue to be used. Accordingly a wide variety or portfolio of individual methods can be used flexibly, dependent on the personal skills, the type or complexity of the task at hand. The only condition is that the results must accurately meet the defined deliverables, for example: a process model, the calculation of a business case, the appointment of a process owner or the definition of metrics and values for process performance measurement.

  • …be simple and usable by as many employees as possible.

When a BPM methodology is too complex, it often requires practiced experts and demands a huge training effort. It’s use generally remains restricted to a smaller elite group of BPM experts. To put a company on a solid path towards a process oriented operations, you need broad acceptance. For this reason a set of simple, easy to understand, yet effective BPM methods has often more impact than complex expert methods. This is not to say, that expert methods are not necessary.

  • …map and promote the interaction between business and IT

BPM methodologies that concentrate too strongly and exclusively on a company’s business aspects make little sense. BPM must be a common language and approach of business and IT to have maximum impact. Accordingly, a good BPM methodology has to contain specific views for business and IT and ensure their mutual interaction.

 

In all the scientific and practical literature I couldn’t find one single standard method yet, that can fully meet these six main qualities. Perhaps I should read some more books, but I’m not sure if this helps. For this reason we decided to create our own BPM approach, the Process Management Lifecycle, which is mainly build on this catalogue of qualities. Together with some of our most experienced Business Consultants we are now thinking about a roll-out of this approach and the development of a service offering for our customers.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Thilo Bischoff Post author
    To provide you further information about how SAP was building up a BPM methodology using the six qualities described in this blog, please also look up the following blogs we already published here:

    Mark Scavillo: SAP’s Business Process Management Approach
    Vanessa Huschke: Process Management Lifecycle
    Thilo Bischoff: Details on New Process Management Lifecycle (PML)

    (0) 
      1. Thilo Bischoff Post author
        Oh, …I forgot that you aready can find many informations on BPM. Just search for “Process Management Lifecycle” in the wiki space and /or in in my other blogs.

        Regards,
        Thilo

        (0) 
  2. Mendel Koerts
    Refering to a definition of BPM would help me understand your message. Have a look at http://www.capgemini.com/ctoblog/2008/05/guest_blog_mendel_koerts_on_sa.php for my view.

    If you’re saying that business analysis methods like Six Sigma aren’t IT oriented, you’re probably right. Capgemini recognized this issue some years ago and lanched SEMBA in 2007, the Structured Expert Method for Business Analysis.

    We’re in the process of sharing SEMBA with the Open Group, in order to make it open. Look for Ron Tolido’s stream at  http://www.opengroup.org/chicago2008/program.htm

    But I’m sure we’d want to share some more details with SAP, send a mail to SEMBA.nl@capgemini.com

    (0) 
    1. Thilo Bischoff Post author
      Hi Mendel,

      thanks for the information about your activities. We should definitely share some experiences!

      I also want to add the definition for BPM which we think fits to our approach, the Process Management Lifecycle (PML):

      “Business Process Management (BPM) refers to the continuous analysis, design, implementation, execution, measurement and monitoring
      of business processes in order to increase effectiveness and efficiency with respect to the corporate strategy.”

      –> BPM does not only cover the business process itself, but also the process-related environment, such as:
      – Organizational structures in which the process runs
      – Employees that perform process activities, their skills & roles
      – Technology and IT systems that support process execution 

      In particular BPM deals with cross-functional or even inter-organizational business activities.

      Best regards,
      Thilo

      (0) 

Leave a Reply