Project Description
Business Process Management or BPM is a hot topic in 2014. With escalating costs of employee benefits, coupled with the ongoing flat or barely growing economy; finding new ways to reduce costs and personnel-effort is a primary goal for many of our customers.
BPM software has reached a level of maturity in the marketplace that encompass many options and variety of capability for customers to choose between. Gartner’s magic quadrant scatters a number of top vendor products having many similar attributes, but varying levels of integration capability and need for customization.
EXAMINING ROI
When evaluating BPM products, tailoring business requirements around adoption, and the life expectancy of the product are imperative in attaining True Cost of Ownership. In addition, an evaluation of ongoing support costs, including training, and retaining/recruiting skilled workers to support the products, must be included in any cost discussion. Building applications from scratch (do-it-yourself approach) may result in lower up-front costs, but such solutions are generally able to realize less than 75% of the functional business process requirements. All the while, they regularly fail to eliminate overhead costs associated with approximately 25% of exceptions and exception handling (those not cost-effective to automate).
Do-it-yourself approaches are likely to require reworking, or even complete rewriting – contributing to failure in meeting the business objective for cost reduction around business process automation. When businesses are starting from zero automation to 75% automation, and there’s certainty that the business process needs will not change in 5 years, the business may successfully implement a solution. However, it will likely be the cost to customize or replace the system within the same five years that will result in failure to meet ROI expectations.
Furthermore, the operational support costs and upgrades to the supporting infrastructure are rarely considered in ROI calculations – especially if memory management or performance become a problem with a new application, requiring larger hardware and software costs than initially predicted. This is an issue before the aforementioned labor costs to support non-industry standard solutions are even factored into the equation. Such costs are sure to compromise ROI, as the business experiences incremental increases in IT costs without an accompanying increase in perceived value. What is unique about BPM initiatives, is their non-functional requirements external to the business process, for functional requirements from the business. These requirements must be identified and prioritized as part of the up-front project costs and product selection criteria.
EVALUATING BPM PRODUCTS
Prior to evaluating any BPM product, BPM initiatives must have the following documentation fully prepared:
Business Requirements
Business requirements should be outlined, demonstrating a detailed process analysis with use cases representing all required functionality. The business units must prioritize use cases individually, with a plan to measure acceptance for each use case. These requirements should also include costs for the way the business operates, based on current and historical data.
Business requirements are basic to any application initiative, but BPM doesn’t stop there. Rarely are today’s businesses able to predict changes in acquisitions, mergers, compliance, business climate, or other regulatory impacts on business processes. This leads to the need for flexibility in modeling and making changes to the BPM product as a basic supposition, characterizing and differentiating BPM products from other applications that simply automate business functions.
BPM Capabilities
BPM capabilities typically include what is coined “BPEL” or business process execution language, which is used as input by BPM tools for the decisions that determine the routing or processing path within a business transaction. When automating a business process, flexibility must be kept in the forethought for ongoing change management with each business process being fully automated, keeping in line with the concept of 80% automation and 20% exception handling, which requires routing via BPM technologies. Such flexibility requires an agile business process model, for which many BPM products do not account (buyer beware). This leaves customers with the need to perform regular “rewrites” of their code, leading to costly “workarounds,” which could outweigh the initial benefits of automation if such rules are not externalized from the business modules.
BPM ESCALATION & EXCEPTION HANDLING PROCESS
Business Process Management involves channeling 80% of the work through automated mechanisms, with the left over 20% exceptions utilizing a BPM product. These remaining 20% of exceptions are then identified in terms of the business process status and escalated to humans who can act on the exception (approve it, reject it, call a customer, call a supplier, etc.). The BPM rules effectively regulate how long a pending action can stay in the system within a certain status until another escalation, notification, or exception occurs to initiate another management condition.
The process of identifying a business event, or hung transaction, automation according to accepted routing rules, and event management are part and post of the inherent BPM functions. These “standard” BPM functions are typically handled by state management inside the BPM database. Such database functionality can degrade quickly when transactions begin stacking up. It is imperative to validate the scalability of the underlying database technology. BPM databases behave differently from typical applications, since they are managing “in-flight” status information, and upon completion of the business process, the data is quickly archived and moved off the system. This requires different optimization mechanisms, which should be discussed with your DBA in light of your BPM transaction volumes.
REPORTING REQUIREMENTS
The business process automation being implemented should give heavy consideration to ongoing management and feedback to the business unit about the number of transactions processed straight through, versus exception handling, both historically (year over year) and real-time. Each business process owner will want automated reports, or possibly ad-hoc reporting capabilities, to know exact measurements and statistics about each process, likely down to specific characteristics of each transaction.
The best BPM solutions will provide mechanisms that allow for a variety of reporting capabilities, but should make reporting available through standard database queries, or by exporting data to a data warehouse where enterprise reporting tools and capability are readily available. This is an accepted approach, given that until such automation is in place, business owners rarely have detailed requirements around their reporting needs. Be certain that your product selection provides for robust and detailed reporting by date range input, and in real-time (preferably using configurable dashboards that can be customized to each business process owner). Each dashboard can then be given a URL or logon that the business process owner can use to access individual information and reports.
Many of today’s BPM products provide a “modeling” capability with “deployment” to a run-time environment. This approach delivers flexibility so that such models can be changed, tested, accepted, and deployed to a training environment on a regular application release basis. This enables business employees to regularly adopt change and process improvement. Such tools require multiple environments to enable flexibility. The days of application environments consisting of a single dev and prod instance are long gone. It’s far more complex now. Flexible architectures require dev, test, stage, train and production environments with additional needs for high volume transactional and integrated environments, in addition to performance testing and DR instances, insuring against loss of revenue in light of business or technical interruption.
PLATFORM SELECTION & INFRASTRUCTURE SIZING REQUIREMENTS
For each business process slated for automation (such determination must be based on current costs, current transaction counts and growth predictions, and/or SLA information in terms of time to complete), inputs must be evaluated for the BPM platform selection, infrastructure sizing and costs. Such sizing and platform selection should be based on solid business transaction volume projections for each use case. If the idea is to “grow” the infrastructure with the business transaction volume growth, then costs must also include the systems management software, personnel, and mechanisms for enabling a performance and capacity management process, as well as monitoring software and monitoring automation.
GAP ANAYLSIS
Some proactive work should be done to determine the “as-is” situational analysis, and to develop the envisioned “to-be” or target system that will address the needs or concerns with the current “as-is”. Once agreement has been attained on the vision going forward, the development of a gap analysis is necessary to identify the effort and costs to go from the current situation to the proposed vision. During this process, many alternatives will be identified with varying cost scenarios as well as timeline, and resource impacts. Formalizing an “Impact Statement” process may be highly valuable in identifying the costs, timeline, and adoption associated with the various ways to address gaps.
BPM product selection should always begin with a good understanding of your BPM needs. Vendors are eager to showcase their individual product capabilities and give customer references. Check out BPM trade shows, articles, websites, and request product demos. Within every IT shop, there are experienced and valued technicians with experience to help identify what went well and what didn’t go well with past BPM initiatives. Whether or not past BPM initiatives met their ROI or business goals can be difficult information to obtain, but well worth the research. Businesses should ask vendors to provide the cost savings basis for each customer, to effectively identify opportunities for realizing cost reduction with any new BPM initiative. Many vendors have developed costing formulas that can help businesses build an effective business use case scenario to drive a BPM initiative that might otherwise flounder.
In contemplating a BPM approach, consideration should be given to the product selection based on best-of-breed vendor products. Best-of-breed products typically involve a higher level of investment as the intent of these products is to integrate them as cornerstone technologies within an enterprise, with the expectation that critical business processes will be running on them. BPM tools are expensive, generally requiring a change in IT culture for adoption and integration of the BPM services into your SDLC, with centralized BPM expert(s) for ongoing support and maintenance of BPM suites.
If “best-of-breed” is outside your financial reach (i.e. approved budget), re-evaluate your business use cases and areas of savings. Building out the many BPM mechanisms for exception handling and management of state in a database with scalability and management capability is a difficult and lengthy development initiative with high risk. Open source BPM products have a higher risk of pushing the length of time for adoption and could possibly zero out your business case ROI with increased support costs, thus exchanging business personnel for more expensive IT personnel required for ongoing development and support of a customized open source solution. Of even more concern, as business process transactions increase, you alone are responsible for scalability and performance of the open source solution, which may turn into a 7x24x365 support basis.
Image provided by Enfasis Logistica Mexico