These are exciting times. Business Process Management Suites (BPMSs) are becoming increasingly mature, and we are witnessing the emergence of the BPMS Center of Excellence (CE) in a number of large Fortune 1000 organizations. These are also challenging times. We are bombarded with confusing messages when it comes to the methodologies, tools, and overall culture that need to be developed within an organization to realize the full potential of the BPMS CE.
These are exciting times. Business Process Management Suites (BPMSs) are becoming increasingly mature, and we are witnessing the emergence of the BPMS Center of Excellence (CE) in a number of large Fortune 1000 organizations. These are also challenging times. We are bombarded with confusing messages when it comes to the methodologies, tools, and overall culture that need to be developed within an organization to realize the full potential of the BPMS CE. While it is generally accepted that a BPMS platform is essential, it alone is not sufficient in guaranteeing the success of a BPMS solution, with tangible and measurable ROI. A well-thought out BPMS Methodology is a critical component of a successful CE. The methodology describes who the main participants or role players are; what the workflows are in each phase; and how to realize governance in an end-to-end BPMS project. The methodology should also articulate the artifacts that are produced in each stage of the development. A winning BPMS methodology involves measurable and continuous improvement, development and deployment lifecycles.
In order to implement a successful BPMS CE Methodology, several core principles and requirements must be met:
1. The Methodology Starts With The Business Case and Identifies a Best Choice Opportunity: The earliest phases of the methodology needs to first identify a business case and then define the best choice (what to implement first) opportunity to guarantee the success of the BPMS deployments:
- The Business Case: There are several factors that make up the business case. Higher level motivations include:
o Innovation: Ability to create and quickly introduce new products and services.
o Growth: Related to innovation is the focus on growing the revenue as well as the market share of the business.
o Productivity: A service oriented enterprise attempts to increase the productivity of its employees but also its customers, trading partners, and other serviced communities.
o Compliance: A substantial percentage of IT and Business resources are spent dealing with compliance issues.
Careful analysis and quantitative and qualitative ROI is critical in this initial business case phase.
- Best Choice Opportunity: The second issue may be less obvious. Once a business opportunity is identified, there are often many use cases that could potentially be digitized and automated. The BPMS project leader needs to decide where to start and which of the candidate use cases must be deployed first. This choice is critical for the overall success of BPM projects. If the wrong decision is made early on, a project may run longer and cost much more than the initial estimates. Identifying and agreeing upon which use case to automate first is an important success factor that business and IT need to agree upon in the initial phases of the BPMS project. One proven approach is to choose a quantitative strategy that attempts to discover the use case with the least effort and highest business value.
2. The Methodology Reflects the New BPMS Paradigm: Business Process Management is a new paradigm and a new way of thinking about solutions deployed across the extended enterprise. There are principals that are common with any good-old Software Development Life Cycle (SLDC) and iterative methodologies such as the Unified Software Development Process. These approaches have phases, workflows, roles and artifacts that are adjustable and applicable to BPMS. However, there are core differences that need to be taken into consideration. In BPMS you are trying to elevate the programming paradigm so that processes and business rules are captured, represented, and implemented directly. Furthermore, the main drivers in BPMS are participants that have new and emerging roles such as Business Analysts and Process Architects. Capturing and implementing change in BPMS is quite different from “over the wall” conventional programming methodologies (i.e. throwing requirements from the business side to IT). Speed of development is faster. The potential of narrowing the IT – Business divide is tremendous. In some scenarios, business participants introduce new process flows or rules directly in the deployed BPMS solutions. These roles are different from the more technically oriented architect and development roles. The competencies, talents, capabilities and responsibilities required are quite different, and this must be captured and reflected in the Methodology. With BPMS conventional software development walls and roles are challenges and obliterated.
o Modeling and Execution: In this new paradigm modeling is important. It is the start. Modeling needs to move onto execution. In fact, you need to very quickly go from models to execution, with as little mappings or switching of tools as possible (none is the best option). One can model “as is” and improved “to be” processes to ones heart’s content. I have seen entire rooms filled with elegant models of processes, with nothing to show for the execution and ROI of the models. Your methodology should spur you to execution – a central theme of the new paradigm. The methodology phases should enable immediate execution of a model, elegantly, and without any loss of semantics.
3. The Methodology Leverages the BPMS Platform: There are good and elegant platform-independent BPMS methodologies out there. For a successful BPMS project, a BPMS execution platform is needed. Ideally, it would be possible to use a methodology with any BPMS execution platform. In order for that to happen, a consistent and standardized, detailed, and sufficiently complete meta-model needs to be embraced by all major BPMS vendors. But this is far, very far, off – no single meta-model is endorsed by all platforms and won’t be any time soon. Therefore, for the foreseeable future, the deployed BPMS methodology should leverage the BPMS platform that will be executing the business processes and rules. The methodology should leverage the best-practice platform-independent approaches. However, in its specific phases the methodology should use the terminology, roles, portals, and meta-models of the target BPMS platform.
o BPMS Platform Support: Ideally, the BPMS platform itself should support the methodology. This is the converse of the methodology being platform specific, and in fact re-enforces it. For instance, the platform can capture best practices as specified in the methodology and conduct a pre-flight analysis to check if the best practices are reflected in the solution that is about to be deployed. It could also raise and warn about potential areas of conflicts or problems, again reflecting the methodology’s recommendations.
o BPMS Is Holistic: In BPMS, you need to model and implement with a single object meta-model and model for your business integration, business data, business rules, and business flows. This is critical. The methodology needs to take this into consideration. In object orientation, applications are built through classes. These classes have meta-properties (persistent, transient, etc.). They also have attributes and operations. Classes have different types of relationships with other classes (generalization, association, aggregation, composition). Your methodology should help you in your classification schemes and your application will be as elegant, extensible, and maintainable as your classes. You can impose component architectures on top of your classifications, but your building blocks better be solid. Your methodology needs to identify the abstractions, analysis and design details in designing your classes. Enter BPMS. Here also you need your classification. Except that you have a much richer representation and meta-model for the classes that are used to build your BPMS application. Here your methodology needs to specify clearly when and how to model and build your process models, when to use business rules, what type of rules, and how to implement the synchronous (service invocation) and asynchronous (message or event based) interactions with external systems.
4. Methodology Is Driven by Continuous Improvement Measures: This too is critical. Business strategies, must be translated into a number of key lagging or leading indicators and continuously monitored for ROI or improvement opportunities. Execution gives the ability to aggregate over process data and make reasonable assessments of how progress is made toward achieving your goals. Iterative and continuous improvement is paramount, but more than that, the methodology should help you continuously monitor and measure your improvements. This also helps align your business stakeholders and the IT implementers. The BPMS projects need to be constantly monitored and measured to make sure they are delivering value to the business. For instance, automation through processes or business rules could introduce shorter cycle times in building products, or delivering services, or responding to customer requests. Each iteration could result in additional improvements. The methodology should introduce a “monitor and measure” phase that quantifies the advantages of each iteration. This needs to be an essential component of the methodology.
5. Methodology Helps Build Corporate Assets: Why BPMS? Just as DBMSs managed the data or information independent of the applications, and in fact, allowed for data sharing across multiple applications, similarly BPMSs allow business rules and processes to be managed as corporate assets independent of the applications. It is important to be able to organize these corporate assets along a number of dimensions. The methodology needs to help you specialize, extend, or expand incrementally and build your corporate assets. In other words, the methodology should be asset-building aware. For instance, you might have all your business processes and declarative rules that deal with risk management. The ability to digitize, organize and deploy these is a tremendous asset for an organization. Risk calculation, risk mitigation, exception handling for risk management can be shared throughout an organization for different purposes or specialized for specific types of risk management applications such as governance in IT or governance in Finance. The methodology should specify how and when the process and business rule assets are constructed, classified and specialized.
The previous sections identified five essential BPMS methodology principles. Sometimes software is developed by developers and for developers. BPMS is different. As mentioned above, it is really a new way of thinking about problems and solutions, while closely involving business stakeholders. These five principles are a litmus test that can help you design or select a methodology for successful and continuously improving BPMS solutions.
