Process Management Lifecycle

[VaneHuschke]

PML 2.0

A central element of Business Process Management (BPM) in any company is the BPM lifecycle. At SAP, we refer to the set of activities performed to manage business processes as the Process Management Lifecycle (PML).  In the first iteration, SAP developed its PML framework to help the company organize, automate, and analyze business processes. To better understand the following, have a look at our first PML. http://www.sdn.sap.com/irj/sdn/bpx-cycle)    Based on knowledge gained through implementation of the first framework, SAP has enhanced the PML. I will use the following questions to describe in detail our thought process for enhancing the existing PML: 

Is an Optimize Phase necessary?

The first PML had five phases: Analyze, Design, Implement, Execute, and Optimize. In effect, optimization is just a re-iteration of the first four phases as you constantly improve the process. Therefore, optimizing existing processes means:

• You analyze the as-is process,
• You design one or more (optimized) to-be processes,
• You implement and roll-out this enhanced process and finally,
• You run and monitor the process

That is why SAP's enhanced PML now has just four streamlined phases.

Are we only analyzing existing processes?

In our previous PML, we used an uninterrupted circle to describe process improvement. But, does BPM only cover the analysis of existing processes? The truth is that part of BPM is also the creation of new processes that help the company to perform more efficiently and effectively.  Therefore, SAP's enhanced PML depicts the two possible triggers for an Analyze Phase: how new processes are affected by external factors and how existing processes need to be optimized.

Should the IT side of BPM be better represented?

In most cases, BPM not only has an impact on IT but is also dependant on available technical functionality. If you think about service-oriented architecture (SOA) and especially the SAP concept of an "Enterprise Service-Oriented Architecture"; a process-centric interaction between business and IT is a key success factor. To extract the maximum benefit, IT's role in process management needs to be more proactive.  To represent these developments in our PML, we decided to clearly document the different activities of IT and business within the phases of the PML and in parallel interconnect them to ensure effectiveness and efficiency of all SAP process activities. One method for connecting the respective to-dos of business and IT is to define a set of minimum deliverables, which has to be accomplished before the next phase can begin.  As you can see in the graphic below, business and IT interact much earlier on in the cycle. IT is already involved in the Analyze phase. Unlike the previous PML, the Design and Implement phases are now joint phases and performed together by business and IT.

[Former Member]

The blog was interesting and also thought provoking . Mapping and aligning Business processes to IT functionalities is a deft mechanism . Processes behave differently in different scenarios . I have done a bit of research on processes and have come to assign specific attributes to each in diff contexts . The blog def is a starter , it needs to be revamped more to get at the crux of the issue .

[Former Member]

I agree that Optimization is often a new iteration and thus starts a new cycle.  What I don't see clearly defined is Evaluation: measuring the new process against the goals.  The results could require another iteration through the Implement, or even the Design, phase.  Else, the new process is accepted and the "Lessons Learned" published.  Without a formal Evaluation step or phase, even succesful process changes can come to be seen as "change, just for the sake of change".

[Former Member]

I definitely agree with the fact that IT and business must interact in an earlier phase. With eSOA in mind process modeling practices must adapt to make optimal use of web services. On the other hand the orchestration of web services must adapt to the way business processes will be modeled.

I think the blog is basically correct in identifying the optimize phase as kind of redundant. Not to say that this should not be done! In my opinion this activity fits into the run/monitor phase. I think evaluation as in measuring the implemented processes against the set goals is monitoring. Evaluation as in how producing a lessons learned should be done, but not be part of the continuous BPM Life cycle. 

Perhaps the name of the run/monitor phase should be made more explicit to accentuate the fact optimization is a part of monitoring...

[Former Member]

I think it is interesting that you are trying to take a different approach. What I have heard from customers is that most will adapt and adjust the SAP prefered methodology to their needs. I understand that you want to come up with a framework, but best would be to allow for some flexibility and allow for companies to incorporate their own identity inside as well.

I am not sure if we still need to assess the as is situation in many cases. Perhaps it would be better to remove the as is analysis in most cases. What is the necessity to perform an as is analysis if you want to transform and innovate anyways ?

I think what does make sense is having a repository of possible current processes that you can utilize, where definitions are crisp and well understood. How you reuse them and then update this repository would be another topic I would like to see discussed.

I still think customers will use SAP methodology as a baseline and will perform a fit/gap analysis against best practices where necessary. Then it would be good to share in the community what worked and what needed to be customized.

Does anyone agree ?

[Former Member]

The framework should be at a very high level and is consistant for every business in that segment (Example a framework for the financial industry).  The differences between companies will come at the lower business process levels.  Every analysis needs to have the AS-IS process.  You need to know where you are to understand where you need to go.  If you are trying to innovate and do not want to taint the the team in how things currently work, then have the business analyst just share the benchmark metrics and the metric goal with the team responsible for creating the TO-BE.  After the creation of the TO-BE, have the team look at the AS-IS and create the GAP analysis roadmap showing how the business will transition from the AS-IS to the TO-BE.  This will provide you with a complete plan that shows management the impact of going from the AS-IS to the TO-BE.  The Business Analyst will have the complete process map showing how the manual processes outside of the automation (SAP) will be impacted and provide a mechanism to measure the success of the implementation.

[marilyn_pratt]

This heard at a Gartner conference about BPM:  "the relationship between an IT organization and the business units it supports can be less than friendly. In the new world of BPM, the need for better collaboration between the IT and end-user organizations is a critical success factor. Moreover, joint ownership of some business processes and across organizations, and service-level agreements (SLAs) in who can use and change them, will almost be required as reusable business services and components are implemented along with new assembly and (dynamically changeable) business process/workflow technologies help decrease cost and add speed-to-market for business solutions. To achieve these benefits, it will be necessary to have more clearly defined roles and responsibilities than in the past."
The BPX Community Project is a good place to evolve examples of this dialouge and even examples of what a service level agreement can look like.  Our own process office can be helpful in structuring the examples of where the hand-offs occur.  I'd like to invite more eyes and contributors to that wiki conversation to see if we can share good AS-IS and TO-BE scripts and flows.  Hopefully thats where a good example of "IT side better represented" happens.  We already have technologists interfacing with Business folks, live on SDN/BPX.
thanks for this blog and ensuing comments
Marilyn

[Former Member]

That is an important issue. I was working out that SAP approach with my collegues and can give you som details on that:

1. When reworking the SAP PML we included a first evaluation within the design phase. This one is based on estimated values, e.g. time, amount, cost values. These values have to be estimated by process experts on the level of the detailed to-be process model. To perform such an evaluation, you need to have a qualified process analysis or process simulation tool for the (please do not try to use excel...). The results increase the quality of the business case which should be the basis of the go/no-go decision to step into the implement phase.

2. In the implement phase you do not only implement the process itself, but also the measurement points for the defined KPI's (in the context of processes we call them "Process Performance Indicators" (PPI's). To measure the PPI's, you again need a qualified performance measurement tool.

3. In the run/monitor phase you continuously measure the process (PPI's) gather variancies and analyze them. This can lead to the initiation of a new process optimization cycle. In my eyes this is a continuous evaluation of the process by the process owner.

[Former Member]

In our new SAP PML approach process optimization is initiated within the Run/Monitor phase but can't be seen as a part of this phase.

Catalyst for the initiation of optimization activities can be variancies in the data we gathered with a process monitoring tool or other feedback. The optimization then is performed within the Analyze, Design and Implement Phases of PML.

Another possibility are process adjustments, which can be done by usage of set screws within an existing business process. In this case you normally do not have to train the involved employees. Therefore I would not see this as an optimization cycle.

Also pure system optimization activities are not seen as part of PML, because they normally do not change the business process itself but only improce the relating IT service or system performance.

[Former Member]

Perhaps you could give us some more insights to your ideas concerning the scenario dependent attributes of processes.

[Former Member]

To clarify this: The new SAP PML was created for SAP internal use and processes and does not include a recommendation adressed to our customers. But we do like to discuss this framework with all interested BPM experts in- and outside SAP.

I do not think that the analyze phase can be removed. But we don't need to do it full blown in every case. A fit/gap analysis against benchmarks or best practices is definitely part of the analyze phase of our reworked SAP PML. You also have take a look on strategic items and the business goals to get an idea about the direction of optimization activities. It is not only cost and time. What about a business process that is relevant in terms of legal compliance. The target of an optimization then could be to align this process to legal regulations, regardless of cost, time or other quantitatve process goals.

[Former Member]

To clarify this: The new SAP PML was created for SAP internal use and processes and does not include a recommendation adressed to our customers. But we do like to discuss this framework with all interested BPM experts in- and outside SAP.

I do not think that the analyze phase can be removed. But we don't need to do it full blown in every case. A fit/gap analysis against benchmarks or best practices is definitely part of the analyze phase of our reworked SAP PML. You also have take a look on strategic items and the business goals to get an idea about the direction of optimization activities. It is not only cost and time. What about a business process that is relevant in terms of legal compliance. The target of an optimization then could be to align this process to legal regulations, regardless of cost, time or other quantitatve process goals.

[Former Member]

As in most cases process optimization is not for free, you normally need to ask for a GO/NO GO decision on the optimization activities. I think the recommended transition roadmap would be one element for this, but had to be added by further data. As a result I would see a "BPM Business Case" as a main deliverable at the end of the Design Phase.

Which items should such a BPM adjusted Business Case template include? Do you have an idea? I would like to discuss in detail, what you think is needed to enable a really qualified decision to step or not into the implementation phase.

[Former Member]

I believe the Business Case should become the basis for the Evaluation discussed in other posts.  As such it must layout what the expected costs and benefits of the effort will be:
1) Business Drivers - Financial, Regulatory or Strategic
2) "Process Performance Indicators" - As Is PPI's vs. To Be PPI's
3) Organizational Impact Statement - what business units and departments will be impacted

This indicates the need for the Analysis phase to include a view of the As Is, else there will be no comparable results for the PPI's.  The Business Drivers are usually an indication of the authority and budget that will be available.  Without an OIS, the true cost of the process change can not be calculated.

The details for the templates should come from the various Industry focuses.  They could start by publshing a set of Best Practice PPI's for each process in their industry.  This would also help in mapping the business process to the correct system process.  One could search the PPI's and know that the map was correct when the Business PPI's and the System PPI's aligned.