The original Capability Maturity Model (CMM) was developed by the Software Engineering Institute (SEI)1 and provides a robust discipline to help developers achieve maturity in their software development processes. There are a number of factors that influence the maturity of the software development processes within an enterprise. These include the strategic plans of the enterprise, the enterprise’s own organization and culture, as well as the technologies that are adopted within the enterprise IT architecture.
The original Capability Maturity Model (CMM) was developed by the Software Engineering Institute (SEI)1 and provides a robust discipline to help developers achieve maturity in their software development processes. There are a number of factors that influence the maturity of the software development processes within an enterprise. These include the strategic plans of the enterprise, the enterprise’s own organization and culture, as well as the technologies that are adopted within the enterprise IT architecture. The CMM has been applied to several disciplines within different industries. It is not surprising that maturity models have also been applied to Business Process Management (BPM).
This article focuses on a three-dimensional taxonomy of maturity models. The three dimensions are maturity in developing BPM solutions, adopting BPM solutions, and governance through BPM solutions. We will describe potential maturity levels in these three dimensions. But more importantly, the message of this article is to focus on all three dimensions, since the optimal value of BPM and success in BPM can only be achieved when you move to maturity along all three axes.
Maturity Models in Building BPM Applications
Perhaps the most practical dimension to building BPM applications is the software engineering maturity model. BPM is a new paradigm which provides huge productivity gains. Furthermore, building BPM applications requires a robust BPM methodology. Considering the maturity from the pure project management and optimized repeatability perspective we can realize the following phases by applying the software engineering model:
- Initial: This phase is typically characterized by ad-hoc adoption of BPM. Here, BPM projects are managed like other projects, often with project delays, cost overruns, and poor quality – similar to other programming projects. Staying in the Initial phase will result in a poor perception of BPM as unpredictability both in terms of schedules and quality of the BPM solution are present in this phase. You need to move quickly to the next level: Repeatable.
- Repeatable: In this level, you start to put in place an iterative BPM methodology. The Business Process Management Suite (BPMS) platform must support the methodology. The overall project delivering the BPM solution demonstrates predictability in deployment schedules. Each iteration use cases that are mapped onto BPM elements: process flows, decision rules, information structure, and integration. The repeatable BPM level can then consistently map business requirements onto BPM objects.
- Defined: At this phase, you have various best practice patterns in building BPM solutions that are captured, document, and mandated across BPM projects. In a BPM context, the development procedure starts to incorporate re-usability models. This implies, to the extent possible, executable process models, information models and business policy models that are re-used across projects. Furthermore, different groups or projects that are building custom BPM solutions are doing so as much as possible in a consistent and predictable manner. BPM development processes and practices are in place.
- Managed: Here the BPM development process itself needs to be measured and managed. This includes the performance of the development lifecycles and the change lifecycles as well as the various participants involved in building the BPM solution. Six Sigma is one disciplined approach especially in quantitatively reducing variances in development process performance. There are other approaches. The main focus here is the maturity, practice, and success in linking higher level BPM solution delivery performance goals to BPM solution development practices.
- Optimizing: Implementing continuous improvement BPM development practices is characteristic to this level. While improvements span all the phases of an iterative methodology, improvements also potentially revise the roles – both on the business/stakeholder as well as IT side – of the participants who are involved in building the BPM solution. At this level, you also start to encourage innovation. For instance, you might introduce new ways of sharing your process and declarative rule assets; you might introduce new ways of identifying successful business rule, information, or flow patterns. You also use concrete data from deployed BPM projects to feed into the improvement of the processes and project management practices that are used in building BPM solutions. Optimization requires that you systematically conduct defect analysis to identify the various bottlenecks that were identified in various BPM projects.
Many of the principles and levels identified in this dimension of maturity are similar to software development processes with several caveats. BPM is really a different programming paradigm that closely involves business owners and builds corporate assets through automated business processes, business rules, information models, and integration components. Furthermore, the BPM platform should support the methodology that helps support the BPM development maturity levels.
Maturity Model in Adopting BPM
This second dimension of maturity deals with the permeation of BPM within the enterprise — the departmental and eventually enterprise adoption of BPM. The goal of this dimension is to eventually be able to link your corporate key performance indicators to executing processes and business rules. Note that the previous dimension reflects the maturity in the logistical support (the how) of linking performance measures to executing processes and rules while building application. The focus in the second dimension is on the what: the ease in identifying KPIs and their linkages to operational executions via processes and rules.
One potential maturity model description in the adoption dimension can be described as “bottom up.” Levels in this dimension start typically with small departmental BPM solutions that have mid-level managers championing the advantages of BPM. This is Level 1. Once the BPM has demonstrated tangible results, Level 2 realizes adoption expending within the unit or department as well as across functional units or departments. The success starts radiating within the enterprise. In Level 3, the organization across multiple departments starts re-using BPM objects: processes, business rules, integration, and integration components. Corporate assets are built and an understanding of reusability is achieved. Also in Level 3, the BPM solutions start leveraging BPM solution frameworks. These are out-of-the-box horizontal (IT, HR, SOX, Customer Relationship) or industry specific (financial services, healthcare, insurance, telecommunications, manufacturing, etc.) best practices that give you customizable BPM solutions including process flows, business rules, integration components, information model, and UI. In Level 4, you are able to tie KPIs to executing processes, as described above. At this level, managers and stakeholders have the ability to drill down and influence executing processes from management dashboards on a continual basis. You can easily complete the loop from performance goals to automated processes and policies to the service oriented infrastructure supporting the solution. Finally, in Level 5, BPM is adopted across the enterprise as the approach for building new solutions or extending existing solutions. In Level 5, you have an effective BPM center of excellence that supports BPM project governance, best practices often involving extended enterprises including trading partners and a growing repository of executable business processes and business rules shared across the enterprise. Performance management, monitoring and improvement becomes more of a science than art. You start adopting consistently management as well as process improvement methodologies.
Maturity Model in Governance or Compliance
The third dimension deals with governance and compliance. It is perhaps the least obvious of the three but could potentially have the most influence on the overall process culture of the enterprise. The goal is to establish a culture of automation and governance through BPM. The Sarbanes-Oxley Act of 2002 is now levying an enormous amount of complexity on enterprises, requiring them to document in detail their business transactions. Governance is a requirement. However, without automating the policies and the business rules encoded in SOX, “manual” governance approach simply will not scale. Instead, we should let BPM automation assist with process and policy conformance. As more processes get automated, the easier it will be to ensure governance and compliance. Therefore, the main focus of this dimension is the maturity in using BPM to implement and monitor processes for compliance. The BPM Suite can provide a repository to store and specialize business processes and business rules along a number of dimensions (product specialization, temporal, geographic, versioning, customer category, etc.). New solutions or extensions are built as specializations – without getting rid of the previous versions. Auditors can always go back and check what the policy or process was at a specific time. Levels in this dimension typically start with adoption of process automation for IT, HR and financial services operations to automation of compliance frameworks such as COBIT for IT compliance, and COSO for finance compliance. As the exceptions, control testing and change management get automated you can start expanding the automation to control procedures (e.g. identity management, training, capacity management, etc.) This goes beyond control management into expanded automation of specific detailed control criteria. At the higher levels, the focus is on performance management, optimization, and streamlining control policies within and across the extended enterprise.
Conclusion
This article presents three dimensions for BPM maturity. The first dimension is the software engineering dimension. This is closest to the original CMM model with a very important caveat: BPM is a new programming paradigm. It changes the very nature of software development. The second dimension is what you will find in most papers or discussions on BPM MM: that is the endorsement, permeation, and penetration of BPM suites within the organization. It starts with departmental deployments and matures to enterprise deployments with continuous improvements. The third dimension is perhaps the least explored yet very significant, and that is the maturity in deploying BPM for governance and compliance. The three dimensions are interrelated and not orthogonal. In fact, typically organizations will grow in BPM MMs along these three dimensions, and a healthy BPM maturity strategy will include maturity roadmaps along all three dimensions. This could potentially result in an aggregate maturity model that provides objectives for levels that consider building, adopting, and governance as integral dimensions for excellence in BPM.
