Skip to Content

Sure, SAP offers great software to support a company’s business processes. And with the development of the “Galaxy” BPM Tool, SAP will also provide a powerful solution that should bring the business and IT worlds closer together.

But how do you know that you’re getting the most out of your SAP investment? How can you ensure that, when “Galaxy” is released, you have a Business Process Management approach that can take advantage of this tool? And finally, what about all the manual processes you have that aren’t supported by an ERP system? Aren’t they important too?

As I mentioned in my initial Who’s Writing about the Management of Business Processes?, the SAP Process Office has taken on the challenge of turning SAP itself into a process-oriented company. And we want to make sure that we have a culture of continuous improvement to take advantage of things like Enterprise SOA. But we also want to improve all SAP internal processes, not just the ones supported by our own solutions.

The big question we are faced with is how to do that in an ever-changing environment and a company that’s growing at an incredible pace. Well, after a year of research, pilot projects and interviews, we’ve come up with a number of steps (what we call Building Blocks) that we believe need to be completed for any company to become truly process-oriented.

Just so everybody is clear, this sequence of blogs will not be discussingg SAP or partner solutions or how best to implement SAP software. What I will be discussing, however, is a BPM Roadmap that we developed and that we believe will pay off major dividends for SAP in the mid-term. I hope that this Roadmap will be useful for some of you BPXers out there as well!

The BPM Roadmap

Although we’ve defined about 30 Building Blocks (I’ll share those with you some other time), we’re focusing on eight critical ones right now. And these eight we’ve put into a cyclical roadmap based on our BPM Framework, the Process Management Lifecycle (PML): 


The four steps are:

  1. Design (in our case re-design) the Enterprise Process Map, assigning Process Owners and defining comprehensive Process Performance Indicators (PPIs) as well (Building Blocks: Process Map, Roles & Tasks, Process Performance Measurement)
  2. Analyze the as-is process maturity and begin measuring the PPIs (Building Blocks: Process Maturity Plan, Corporate Process Reporting)
  3. Prioritize processes for improvement projects (Building Blocks: Decision Making Bodies, Process Maturity Plan, Project Portfolio Management)
  4. Drive prioritized Process Projects (BPM Methods, for example Six Sigma, the PML Methodology, etc.)

The beauty of this approach is that you can basically start with any of these steps first. For example, some companies may find it easier to start with optimization projects, requiring documented processes, assigned process owners and defined PPIs as deliverables.

In the next blogs, I’ll go into more details on what we’ve done so far in each phase of the Roadmap. But I’d love to already get some feedback on whether BPXers are also interested in this type of information related to Business Process Management. I certainly hope so, since a solid BPM approach is fundamental to implementing best practice processes and fully utilizing future SAP solutions!

To report this post you need to login first.


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

  1. Richard Hirsch

    I’d be curious to know what parts of the approach are SAP-specific and industry-specific?

    There are many paths to Rome… Could you explain why SAP choose this particular approach to deal with its processes?



    1. Hi Dick,
      Thanks for your questions. Honestly, I don’t believe that there is an industry-specific approach. Up to know, I haven’t even found a standard definition for Business Process Management.
      What I’m describing is all SAP-specific, since what we did was take “best practice” pieces from such sources as APQC, Michael Hammer and Gartner and adapt them to our needs.
      In the future, I’d will provide more details on our approach and hope to get an exchange of information going between other process experts on implementing BPM in an organization.
      I hope that you’ll keep in touch!
  2. Hamdan Muhammad
    I have always been fascinated with the tremendous opportunity that lies with the BPX to continuously evolve and improve the business processes but falter to envision the “streamlined ecosystem” being realized in the diverse cultural settings around the world and addressing the change management aspect of human nature. I have been into consulting for the past 6 years and still see this as the greatest challenge specifically in large enterprises.

    How do you see this part being addressed through the outlined approach?

    – Hamdan

    1. Hamdan,
      I agree that change management is the biggest challenge and is one of the things we have to focus more on internally. We use various communication and training activities to increase awareness for process management at SAP, including: a bi-monthly newsletter, articles in our SAP magazines and other communication media, our own intranet site and training on our BPM methodology. The key, at least in my point of view, is to explain BPM as simply as possible – even using situations outside of work where people also work with processes (for example, going grocery shopping). Recently, I’ve gotten in touch with Kerry Brown, who has a team that offers Organizational Change Management for SAP customers. She also has some very good concepts and has a site in this BPX community.
      I hope I’ve answered your question. Feel free to contact me if you’d like to discuss anything further.

      Regards, Mark  

      1. Former Member
        I was interested in Hamdan’s comments and Mark’s reply and would like to add to that….

        Describing change in relation to BPM as a ‘challenge’ presupposes  difficulty and that ‘explaining BPM as simply as possible’ presupposes that the reason is its complexity…

        We should bear in mind that process of course, IS change, changing to a desired state through a series of steps and something that our brains are designed to do easily.  Emphasising this can help to create a more natural, confident, engagement to take place..


        Sharon Knight
        Change Consultant

  3. Former Member
    Hi Mark,

    Interesting viewpoints.

    A number of years ago I worked in a company with a staff of over 10,000 that changed from a vertical to a horizontal company. That meant going from a departmentally based to a fully program and program/project based organization. In doing that we changed to a much more process based organization.

    During that time I was managing a number of projects that were designing and redesigning processes and targetting significant cost reductions, process- and product improvements. Some of these projects had time-horizons of days but others of many years.

    In that design process there were a number of levels and layers. We kept track of these by using both our configuration management processes, tools and (legacy) IT systems. (Note: these processes had to be ‘approved’ by ‘regulators’.)

    When ERP really took-off at the end of the 90’s the quality of process based thinking and tools improved tremendously and spread widely. And supported all those working in process design and improvement.

    The reason for the arrival of BPM (it is not new but it is a shift in priorities – same with SOA) might be that there was a lot of work to be done on process description and companies had to get used to process thinking. And that now we are entering a maturity stage where we go into a new phase and find that ‘managing’ processes has been somewhat neglected in the past.

    Finally, based on my experience, I would like to predict that you’ll end up with at least two different process development layers in major organization. To explain it in simple terms, one is topdown and the other bottom up. Future methodologies and information systems should be able to support that.

    I am looking forward to hearing from new developments in this field.


    1. I am currently writing additional blogs with more details on our approach. If you feel that the information is not sufficient, then please contact me directly to discuss what you need and what we can provide you.


  4. Former Member
    when this software packages started coming into daily life of industries, i think they are made to align with the existing processes. and a serious attempt to stadardise these processes is successful for most of the companies whcih again restrcited the use of Expensive software packages like SAP to a set of well strcutured and stadardised companies. then came the competitions and smaller versions which could be easily tailered to the needs and thus used by several industries came into existance.I think, as Eric (below)said,  this is not a new phenomenon but which is gaining a definitive shape. as far as the mention of bottom up and top down thought process is concerned,i think its one and  the same.BPM in my veiw has nothing to do with the software. ERP software is inherantly shed by the processes in the industry. A generalisation and more adoptability is what is being attempted now.Correct me if i am wrong.I think every cncept is an evolutionary one based on its predecessor concept. hence we need not assume that “this is not new”, there cant be any “new thing” completely seperated from the past. NEW exists because of OLD:). I am extremly lucky to have involved and seen the growth of software from punchcards to nanos and from simple T sqaure to autocads. and from MRPs to Weavers!!! Excited to see what these SOAs and BPMs lead to. Change configuration with the help of design patterns in the processes may help these concepts to take a more definitive form. Proud to be here…Sudarshan
    1. Former Member
      small correction a typo which really changed the meaning of what i wanted to say  “wrong sentence= ERP software is inherantly shed by the processes in the industry”  what i intended” ERP software is inherantly shaped by the processes in the industry”  – I apolozige for the typo.
      1. I agree with you that BPM is not about software. This is exactly why I started blogging about this as an SAP employee. I work for the largest ERP software company – however, what our team is doing is trying to create transparency on what SAP’s processes look like and then (from the bottom up) link them to the existing SAP software that we are using to support them. It’s a long process but I believe that it will be very benificial for us.

Leave a Reply