With the wide range of available tools on the market today together with the large number of white papers, articles and books on BPM, determining the correct solution for your organization can be daunting. With so much emphasis on the effectiveness of BPM tools for improving productivity, streamlining the value chain and gaining competitive edge, it’s easy to get caught up in all the hype and end up with a much more sophisticated and expensive solution than the business really needs. On the other hand, fear of making a selection that may result in a failure to meet strategic goals or achieve adequate return on investment can cause delays in making the decision to adopt a BPM tool and, by omission, result in the same problems. A well thought out, phased approach for selecting and implementing a BPM tool can reduce these risks. Even if the decision is to buy a full end-to-end solution in the beginning, there can be good reasons not to implement all components at once or at least not in all areas of the business together.
The term ‘BPM tools” is commonly used to refer to those that are used to model business activities in an executable format to create an automated application of business rules to drive workflow complete with interactive forms, and notification capabilities. Another term, ‘BPA tools’ is a term that applies to tools that perform in depth analysis of business process performance and the impact of potential changes to its structure through a variety of methods including reporting, KPIs and simulation capabilities. In this article, ‘BPM tools’ is primarily used to describe both types.
BPM tools and suites offer functionality ranging from basic diagramming to varying degrees of analysis, execution and business rules management. However, just because there are tools out there that can ‘do everything’ doesn’t mean it is the right solution for the organization. Just as new application software should not be acquired without a clear understanding of the business problem being addressed including defined requirements, the same is true when purchasing BPM software. Pricing varies dramatically from a few hundred dollars to half a million dollars or more, so a comprehensive plan for what the tool will and will not be used for together with a realistic budget will narrow the search considerably. To provide an alternative to large upfront investments, it has become more common for vendors to offer both purchase and subscription pricing models. In the subscription scenario, the software and data is hosted by the tool vendor. In some cases the hosted site may even be a third-party provider. Subscription pricing allows organizations to experience the benefits of a full function tool without significant upfront software and infrastructure costs. However, it can introduce security and compliance risks as corporate data is passed between the internal applications environment and the hosted procedures and business rules site.
Identifying the requirements for the correct tool will depend on the BPM strategy adopted. One strategy may be to include documenting as-is and to-be process models as a standard project deliverable. These models are used for developing business requirements and test scenarios and become part of the project documentation. They are not deployed as part of the system and user manuals nor are they maintained as the day-to-day processes evolve and change. In some cases, they may be used as a starting point for future similar projects but the reality is that they will likely never be looked at again. In this scenario, the required functionality would be process diagramming and a means to capture basic information about each artifact such as a description and the business role performing the work. The objective is to provide sufficient detail in a format that can be disseminated across the project team. Another approach is to maintain process documentation as part of a continuous improvement strategy which would include regular updates to any process impacted by strategic and operational decisions or by changes to existing application functionality and allow execution of what-if scenarios. This documentation can be used as the baseline as-is process model when starting a new project eliminating significant work from the beginning of the project. The to-be process model delivered by the project becomes the new official as-is process documentation at the completion of the project. The required functionality in this scenario would be process diagramming, detailed process documentation and simulation capabilities. For a fully integrated end-to-end BPM strategy, the required functionality would include everything from process diagramming to automated execution within the production systems environment. This would also include a business rules engine either as a native component of the BPM suite or a separate but integrated tool. In this scenario, business processes and business rules are viewed as valuable business assets which are deployed and managed in a controlled, secure environment.
One step in defining the BPM strategy is to identify and define the key business processes that support the business value chain. The current maturity level of each should then be assessed and the required level appropriate to support the organization’s business strategy identified. The results of this analysis will help determine the required BPM strategy to meet organizational objectives and define the tool requirements. Ideally, as outlined in The Process Audit by Michael Hammer published in the April 2007 edition of the Harvard Business Review, this evaluation should be performed together with an evaluation of the maturity of the Enterprise.
Process Maturity models vary in the number of levels and the complexity of each. The targeted levels should be defined by the organization based on its business objectives, available resources and type of product or services offered. Following is an example of how tool requirements might map to maturity levels.
When evaluating tools, consider the possibility that the first one selected may become disposable. This may be a valid choice if the BPM strategy is vague or incomplete or if there are anticipated changes to the business over time possibly due to market influences or economic conditions. In these cases, starting with a free or lower cost tool may also fit the initial need. Some vendors are now offering free modeling tools in the hopes that their BPM suite will be selected when the organization is ready to move to the next level. It is, however, important to understand the limitation of these tools. While it may be desirable to select a single tool, don’t sacrifice functionality if you don’t have to. Consider vendor partnerships that provide opportunities to begin with a diagramming and process analysis tool and then move to a process/business rules execution tool later. This may, in fact, result in getting the best of both types. Most tools today support BPMN and provide standard export/import capabilities to allow models and artifacts created in one to be used by another. No matter what the choice of tool, the important thing to remember is that there must be a clear vision of what the tool will be used for and how it will help support the overall business objectives.
