A problem that all of the companies using BPM and BPMS enabled BPM face is defining where they really are relative to both the more traditional structural/organizational placement view of BPM use maturity, with the new view that combines these traditional elements with capability and competency. This evaluation is important in creating ability to understand current capabilities and prepare the BPM CoE to take on bigger, higher value projects and to play an increasing role of importance in companies.
BPM evolution must be viewed within the cultural and technical contexts of each company. There is no one evolution path that fits all. BPM use has proven to be a journey to a destination that keeps moving around. This makes the journey less of an implementation of specific concepts, approaches, tools, and techniques than an evolution of capabilities built around these approaches and concepts. The tools and techniques that support this evolution are also in constant change and to some degree drive the evolution of the BPM concept because it changes what is possible to do. The ability to hit these moving targets is however, a key strength in BPM. But it requires the construction of a firm foundation for change and the political will to move to a flexible business model.
So there are few fixed milestones or points in any company’s journey into BPM. This is where the need to define and control your BPM/BPMS enabled BPM journey really comes in. The way the BPM group is viewed and the services that are anticipated, define the capabilities and competencies that are needed and thus allow the journey to be modeled – from where you are to where you need to be.
This definition needs to start with the creation of an understanding of the current state of BPM and BPMS enabled BPM in the company. This will require the adoption of a formal and disciplined BPM reference maturity model. There are few that look at an evolution of where the group is placed and how it should operate. This traditional view and model is a starting point. But we now know that what is really important are CoE’s capabilities and competencies, and the way they evolve. Together they describe the real evolution path as they show how competency needs to increase. While the number of levels will vary, the capability maturity model we use goes from a level zero (meaning no capability and no competency) to a level 7 with competencies being defined for each capability at each level of competency.
The chart above is an example of a capability maturity reference model. These should be customized for each company to depict the capabilities that are needed to support the vision of the BPM CoE’s operation – both the vision today and the vision at a time two or three years into the future.
This type of reference model defines the competency states of each capability in the various maturity phases you have adopted. This is the basis for any evaluation of a capability’s maturity. It is also the basis for determining what must be done to create a capability evolution plan and an investment roadmap for moving to a service level desired by business leaders.
Note: For best results, this reference model should not be built by people who have a vested interest in the outcome of the capability maturity assessment. Likewise, the people who will be affected by this evaluation should not be involved in determining the rating of a competency level in any capability.
An honest evaluation of competency within each needed capability will likely show different maturity level results for most capabilities. It is important to recognize that this evaluation is not an assessment of performance. Groups tend to reach a state where they have at least most of the capabilities they need to get by and they can provide these capabilities at an acceptable level of performance. Where this is not true, the group will likely be viewed as a failing operation. However this level of competency is not adequate to allow the group to take on more complex or mission critical work. They are ok where they are – doing what they are doing.
The problem in BPM and BPMS enabled BPM is that having the capabilities and competencies to continue to provide current service will not be adequate for much longer. The concepts, techniques, capabilities, and technology changes that are happening will simply not allow it. The latest example of this evolution is the advent of iBPM, which melds in performance analytics, simulation modeling, and business intelligence based monitoring.
Note: This move to iBPM follows a fairly recent expansion of BPMS support to include the generation of social media apps and the evolution of many BPMS tools to produce very scalable software solutions. Things in BPM are certainly never static for long.
This baseline capability/competency assessment is thus a look at what the BPM and BPMS enabled BPM groups are capable of doing today – not how well it has performed in the past. It is, accordingly, very possible for a group that has focused on small improvements to have a low maturity rating and a very high satisfaction rating – they are providing good service within their capability limits. If the service requirements stay where they are, the group would probably continue to provide good service. However, if the service requirements change and exceed capability competency limits, one would expect that service ratings will drop.
This fact makes it important to create a firm vision of the evolving role of the BPM CoE and the expectations of leadership for support and improvement / transformation delivery in the future. This vision cannot be casual; it must be well thought through and specific because it forms the basis of the roadmap for CoE evolution.
0 comments:
Post a Comment