2014 BPM Products Mature But Not Equal

Transcription

1 2014 BPM Products Mature But Not Equal Prepared By: Cindy Gregoire, TxMQ Practice Manager, Middleware & Application Integration Services ABSTRACT Comparison between IBM s ilog and Open Source (Drools) solutions total cost of ownership.

2 2 TABLE OF CONTENTS Examining ROI... 3 Evaluating BPM Products... 4 Business Requirements... 4 BPM Capabilities... 4 BPM Escalation & Exception Handling Process... 5 Reporting Requirements... 5 Platform Selection and Infrastructure Sizing Requirements... 6 Gap Analysis... 6

3 3 Business Process Management or BPM is a hot topic in With escalating costs in employee benefits and the ongoing flat or barely growing economy, finding new ways to reduce cost and people effort is a primary goal for many of our customers. BPM software options have reached a level of maturity in the marketplace with many options and levels 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. Today s mature BPM Products are an aggregation of advance technologies and components which can include; Business Process Automation (BPA), Business Process Management (BPM), Workflow Management & Automation, Business Intelligence (BI) & reporting, Modeling Tools, and support for various enterprise application integration mechanisms. Many BPM products are provided as complete packages, or as components that can be purchased as needed, or as part of a Service Oriented Architecture solution, where the various features, functions and components are delivered as infrastructure or application services that can be implemented all at once or in a staged manner. EXAMINING ROI When evaluating BPM products, it is imperative that selection criteria be based on business requirements as the primary drivers for defining the goals for adoption and the life expectancy of the product, and for attaining true cost of ownership for the solution. In addition, ongoing support costs, including the cost of training, retaining and possibly 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 a lower up- front cost, but such solutions generally are able to realize less than 75% of the functional business process requirements while failing to eliminate the overhead and cost associated with the 25% of exceptions and exception handling that you would not find cost- effective to automate. Do- it- yourself approaches are likely to require frequent rework or complete rewrites when changes to your processes occur failing to meet your business objective for cost reduction around business process automation. If your goal is to achieve somewhere less than 75% automation - and if you are certain your business process needs and business applications will not change in 5 years, you may be able to achieve a successful implementation, but it is likely the cost to customize or replace the system within the same 5 years will cause you to fail in meeting ROI expectations set by the business.

4 4 Furthermore, the operational support costs and upgrades to the supporting infrastructure are rarely considered in ROI calculations especially if memory management or system & application performance become a problem resulting in a new application requiring larger hardware and software costs than initially predicted; and this is before we factor in the aforementioned people costs to support non industry standard solutions. These costs are sure to compromise your ROI as the business experiences incremental increases in IT without accompanying increase in perceived value. What is unique about BPM initiatives is their non- functional requirements external to the business process or functional requirements from the business. These requirements must be identified and prioritized as part of the up- front project costs and product selection process. EVALUATING BPM PRODUCTS Prior to evaluating any BPM product, the following BPM initiatives would be helpful to have completed and documented: BUSINESS REQUIREMENTS Business requirements for the BPM product selection must be developed to a level that demonstrates a sufficient understanding of your business processes to allow for selection of an appropriate product. Start with detailed business process analysis of your most critical business processes including use cases that are representative of all functionality required from a product to meet your business requirements. Use cases must be prioritized by the business with well- defined metrics and acceptance criteria for each use case. These requirements should also include current costs for the way the business is being done today based on 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 business climate, acquisitions, mergers, compliance, or other regulatory changes that may impact the business process. Flexibility in modeling and making changes to the BPM product is a basic supposition characterizing BPM products from other applications that simply automate business functions. BPM CAPABILITIES BPM capabilities typically include a standardized method to allow your business process models to be executed by the BPM tool, this is most frequently done using either Business Process Execution Language (BPEL) or Business Process Model and Notation. A standards body, either OASIS in the case of BPEL, or OMG in the case of BPMN governs both of these. These are generated by first modeling your business process in a tool that is compliant with one or both or these standards or by using some sort of conversion tool. The output in either form is used as input by BPM tools for execution of the business process or workflow that provides decisions that determine the routing or processing path for a transaction flowing through a given

5 5 business process. Many tools support either BPEL or BPMN, some tools support both, while certain tools have a proprietary method to accomplish this. A solid understanding of these two standards relative to fulfilling your business and non- functional requirements is important in selection the best product. When automating a business process, flexibility is crucial for ongoing change management of each business process being automated Such flexibility requires agility in the business process model for which many BPM products do not account (buyer beware), leaving customers with the need to perform regular rewrites of their code or leaving costly workarounds, which could outweigh the initial benefits from the automation of your business processes. BPM ESCALATION & EXCEPTION HANDLING PROCESS Business Process Management involves channeling 80% of the work through business process automaton (BPA) with the 20% of exceptions bumping into BPM where each item is identified in terms of the business process status, escalated to someone who can do something about the exception (approve it, reject it, call a customer, call a supplier, etc.) with the BPM rules effectively putting into play how long something can stay in the system in a certain status until another escalation, notification, or exception occurs to initiate another management condition. This process of identifying a business event, or hung transaction, and automation according to accepted routing rules, and event management are part and post of the inherent BPM functions. State management inside the BPM database typically handles these standard BPM functions. 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 any typical application, 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 requiring different optimization mechanisms, which should be discussed with your DBA in light of your BPM transaction volumes Reporting Requirements The business process automation being put into place should have great consideration given to ongoing management and feedback to the business as to 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 adhoc reporting capability to know exact measurements and statistics about each process, possibly down to the specific characteristics of each transaction. Good 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 a 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.

6 6 Be certain that your product selection provides for robust and detailed reporting by date range input, and real- time preferably using configurable dashboards that can be customized to each business process owner whereby you can give them a URL and logon to access their information. Many of today s 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. That way, business employees are regularly adopting change and process improvement. Such tools require multiple environments to enable flexibility. Long dead are the application environments consisting of a single dev and prod instance. Flexible architectures require dev, test, stage, train, and production with additional needs for high volume transactional and integrated environments also requiring performance test and DR environments ensuring against lost of revenue in light of business or technical interruption. Platform Selection and 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 and 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 in addition to monitoring software and monitoring automation. Gap Analysis 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 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 found to be highly valued 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, which should be expressed in a clearly defined set up product selection criteria developed from your business requirements. Vendors are eager to showcase their product capability and give customer references. Check out BPM trade shows, articles, websites, and request a product demo.

7 7 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. Ask vendors to provide the basis for cost savings for each customer so that you are able to identify opportunities for realizing cost reduction with your BPM initiative. Many of the vendors have developed costing formulas that can help you to build an effective business case to drive a BPM initiative that might otherwise flounder. In contemplating your BPM approach, consideration should be given to first and foremost the selection based on best- of- breed vendor products. Best- of- breed typically involves a higher level of investment as these products are intended to be integrated as cornerstone technologies within your 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, integrating BPM services into your SDLC with a centralized team of BPM experts 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 with increased support costs in exchanging business personnel for more expensive IT personnel required for ongoing development and support of a customized open source solution. Of more concern, as business process transactions increase, you alone are responsible for scalability and performance of the open source solution on what may turn into a 7x24x365 basis.