Note: During a NetWeaver Strategy Session Business Innovation Life-cycle at the recent Sapphire in Orlando, we had discussions about the role of different KPIs on process design and I started to reflect about how processes are designed. In particular, I thought about assumptions that BPXs make about how process owners view the processes for which they are responsible. In particular, I realized that process owners often exist in a corporate environment where pressures from multiple origins impact how a successful process is viewed.
My Sapphire Reflection: Data Collection in Process Improvement Projects – Lessons Learned from Historians concerned the data collection methods necessary in the “AS-IS” phase of a typical process improvement project. In this blog, I’d like to move to the next phase of the process improvement project – “To-Be / Design” phase. Let’s take a quick look at the definition of this phase from the SAP SDN wiki.
Having understood the AS-IS situation and the optimization potentials, the purpose of the TO-BE process design phase is to define and document the optimized TO-BE processes, eliminating the identified weaknesses (emphasis is mine)
The interesting word in this sentence is optimized which depending on context may be a highly subjective term. Examples of the issues that arise when examining this term in more detail are:
- Optimized for whom – for the process owner, for the organization in which the process exists, for the individuals involved in the daily instantiation of the ideal process.
- Despite its highly subjective nature, the basis for optimization is often defined in terms of objective metrics (KPIs) that must be achieved in order for the process to be viewed as efficient.
In this blog, I’d like to examine in detail the difficulty associated with selecting these metrics. I propose that such measures are often assumed to be part of a harmonious unit whereas, in reality, 1) individual metrics may conflict with each other and 2) the relative importance of such measures may change over time.
A caveat: Before readers interested in more technical topics tune out and switch to other blogs, I’d like to suggest that the necessity of looking at processes in the context of the entire organization is an important part of SAP’s tool strategy.
Diagram taken from BPM Roadmap
Thus, the discussions of KPIs and other more non-technical matters are definitely something that we will probably see in future manifestations in SAP’s various BPM tools.
Note: This KPI-related discussion is based on two assumptions.
- It is possible to associate a particular process with one or more KPIs
- It is possible to measure how process traits are associated with the achievement of particular KPIs. For example, if a process is able to increase the number of service calls concluded in a day to 20 calls this improvement equals a 5% achievement of a KPI related to customer satisfaction
Both of which may not be applicable in all organizations. The ability to associate KPIs to processes, despite its importance, is usually only achieved within organizations with a relative high level of process management quality.
When processes goals conflict with one another
Usually when designing a process, there is an assumption that there is one particular way to represent the process. Of course, there may be alternatives available at certain points in the process but these alternatives are responses to particular possibilities for a single decision/task in a process.
Note: Picture taken from “Workflow Pattern Coverage in SAP NetWeaver BPM 7.11“
What happens, however, when the basic assumption that there is only one goal (for example, a KPI that focuses on increasing customer satisfaction by 6%) is questioned? What would happen if a process owner was confronted with not one KPI but several KPIs by which his process is judged? A design that focuses on the achievement of just one KPI might therefore be unacceptable, because such a focus would mean that the process owner might be unable to meet the second KPI. The problem is that the process design may be different based on which KPI is to be achieved. The process may not be entirely different but parts of the process may be different based on which KPI is met.
Of course, it might also be the case that a process that meets one KPI has a detrimental effect on the achievement of another KPI. For example, a KPI that demands that the number of service calls handled by call centers increase may lead to higher levels of employee stress which impact a KPI dealing with a reduction of sick days.
Of course, it would be great to say that there should be two processes – one optimized for each KPI – but this would probably be very inefficient. Thus, the process owner must somehow make a decision regarding which goal is more important and, thus, should receive more attention in the process design. As a BPX, it is our role to support the process owner in describing the best process design to meet his/her selected goals.
Furthermore, it may also be the case that the process owner wants a process design that is not mutually exclusive but achieves partial achievement of the involved KPIs. For example, a process that achieves a 65% percent achievement of one KPI and 35% percent achievement of a second KPI. The result is a series of possible designs.
The question is how can the BPX support the process owner to make the correct decision? Ideally, the tools available to the BPX would allow such “what/if scenarios” so that the BPX could somehow display all possible variation of a particular process. Some might say “We don’t want to confuse the process owner with 50 different possible processes.” The problem is that as BPXs we are not responsible for the process – we can not make the final decision about which a process will be judged. Our goal should be to act as an advisor supporting the process owner. The BPX should describe the different paths with their respective effects on KPIs and let the process / KPI owner decide which path to take.
Of course, if one process impacts multiple KPIs and the involved KPI owners are different from the respective process owners, then there may be conflicts.
Once again, the soft skills of the BPX -this time as a negotiator – are critical.
When goals change over time or responding to real-time data
Usually, changing process design once a process has gone live is impossible. Of course, the next process improvement project might come along at a later date but this evolution is relatively inflexible and means that process owners really can’t respond quickly to real-time events. If the market changes or the relative importance of a KPI suddenly changes, then it is usually impossible to change the process itself. Individuals usually make the best decisions based on real time data (see Upcoming Webinar – Exclusive Preview of SAP BusinessObjects Explorer. An aside: What about feeding the Business Explorer with BPM- / process-related data?) The same need exists in the process arena as well.
What happens if over a two month period, the relative importance of two KPIS that are associated with a particular process switched. Wouldn’t it be useful if the process owner could respond to these real-time events? Ideally, the process owner could have some sort of dashboard with real-time data that are associated with the run-time process environment. Based on this data, the process owner could adjust his process accordingly
What I’m talking about are process alternatives rather than the decision-related alternatives mentioned above. These process alternatives might be defined during the design phase and be presented to the process owner at run-time. Thus, the process could have more flexibility to respond to changes in the market rather than starting another project improvement project with the associated time-lag
Of course, the ability of a BPX to design processes that cover all possible scenarios is impossible. Designs – irregardless of whether there are 3 or 50 – created in March may no longer be relevant in June when unexpected market conditions require different designs that weren’t thought of earlier.
Note: Cognitive dissonance is an uncomfortable feeling caused by holding two contradictory ideas simultaneously.
In this blog, I’ve discussed the apparent need to support multiple design-time and run-time variations of particular processes in order that the complex corporate environment in which process owners exist can be supported. On the other hand, it is obvious that a process environment that is so dynamic would have great difficulty in achieving acceptance from users and support staff who demand a stable environment. The recognition of the relevance and importance of these two precepts leads to cognitive dissonance in BPXs that try and meet both requirements: dynamism / ultimate flexibility to meet decision-makers’ needs coupled with stability to maintain corporate harmony.
I don’t have a solution to this dilemma. I only know that the process landscape in any organization is complicated and the reduction of a particular process to a BPMN model without taking in the organizational context into account may be better for the mental health of the BPX but the reliance on such horse blinders rarely lead to processes that revolutionize the corporate environment in which they exist.