Resources

A must read for business analysts, business process analysts, business process managers,  business process designers and business architects.

This BPM Salary Survey report outlines a regional comparison across the USA, Canada and EMEA (Europe, Middle East and Africa). It is based upon the data collected in the BPM 2015 Salary Survey conducted by BPMInstitute.org which represented the first such survey and formed the baseline for our future research in this area.

What is the value proposition of BPM and how do I communicate to my senior leadership team is one of the most frequently asked questions on BPM.

In answering this question, the first order of priority is to ensure that people in the organization have a common shared understanding of BPM. In our view, BPM is not just modeling processes, it’s not just launching improvement projects, and it’s not just monitoring process performance for continuous improvement.

Instead, it is all three of these – in other words, the modeling, AND the improvement AND the management of the large cross functional processes in the firm.

Once, a shared understanding of the definition of BPM is achieved, it is then possible to outline the approach, benefits and pitfalls to avoid in BPM to demonstrate the value it can provide.

Some of the key principles and the general approach in BPM are outlined in Table 1 below:

Adèle selected her process improvement team very carefully. She needed to ensure that different types of expertise and knowledge were represented. Each of her team mates had specialised knowledge of a particular division of the company. Every single one also came to the table with a unique career path and background. She got to know her colleagues quite well during the interview process and was very pleased with the team she had assembled. They were extremely competent and motivated to improve the company’s operations.

This past year, I had the privilege to travel to the Kingdom of Cambodia to visit the great temple complex of Angkor Wat. For those not familiar with Angkor Wat, it was built in the first half of the 12th century and is still today the largest religious structure in the world. However, Angkor Wat is but one of hundreds of temple complexes many crumbling ruins spread about the countryside around the present-day city of Siem Reap. For those fortunate to visit the area, the best means to travel about the temples is via a rather primitive means of transportation – the Tuk Tuk. The best way to describe a Tuk Tuk is to think of a rickshaw pulled by a moped. Most Tuk Tuk’s have a roof spanning two facing seats. Depending on the size, two to four individuals may ride comfortably. But there are variances to Tuk Tuk’s. At the high end of the market are elaborately hand carved and highly lacquered versions – a work of art unto themselves.

While controversy may continue to exist on whether size matters in areas as diverse as sex, bacteria and even blue whales – there is little doubt that size matters enormously when it comes to Business Process Management (BPM).

Tackling larger, cross functional processes is at the heart of success with BPM.  This applies to both process improvement and process management.  The potential size of the prize increases proportionally with improvement efforts targeted at larger, cross functional processes such as inquiry to order, order to delivery, request to receipt and idea to launch as these initiatives target critical non-value added activities across department boundaries. 

For Six Sigma, Lean, Reengineering and other process practitioners, it is in our nature to adopt what I label a process perspective. Whether consciously or subconsciously, we think in process terms. Every activity is a series of steps and we cannot help but introduce improvements with the passage of time. This pattern of behavior often transcends our work life… and enters into our personal life – sometimes to the chagrin of our family members.

Corinne was at first very pleased to have been asked to implement a process change. She was the one who first identified a problem in operations and who suggested a few modifications to the procedure. After raising the matter several times over many months with senior executives, she finally received the go-ahead to make the necessary changes.

As Corrinne approached her colleagues with the idea of changing the process, she was at first greeted with support. Her work environment was generally professional and courteous. But the more Corrinne engaged her coworkers about the idea of changing a process, the more subtle the pushback she received. Confused, Corrinne pressed on with figuring out a way to bring the different departments together to have a conversation about changing the process.

If you have been involved in very many BPM projects you have inevitably seen some which progressed through the entire development lifecycle with no major warning signs only to fail when put into production.  They fail because the delivered system does not solve the problem which the business needs solved.  They typically go through a complete lifecycle with verification at each stage.  The Business writes its requirements.  Business Analysts turn these into a functional requirements document, approved by the business.  The development team creates then implements designs and finally QA tests the system and verifies that it satisfies the documented requirements.  Yet in spite of all of this, the resulting system is not usable for its intended purpose.