Think of business process management software as 'the oil that lubricates corporate machinery.' With dozens of options on the market, use the reverse-engineering technique to find the BPM system that best meets your particular needs. Credit: Thinkstock While enterprise applications like ERP, CRM, HRIS and others cover their respective domains, business processes often need information to flow between these systems. An organization may also have specific processes that are not well handled by these enterprise applications, for example, unstructured or partly structured processes, or those touched by people outside the organization. The last thing you want to do is to customize application code to handle these types of processes because that makes upgrades difficult, risky and expensive. Another problem is that enterprise applications may not be easily adapted to changing business conditions. To handle these situations, you may want to consider business process management (BPM) software. BPM could be seen as the “oil that lubricates corporate machinery,” allowing workflows to span multiple systems, coping with semi-structured or unstructured processes and allowing highly business specific processes to be built and maintained. Determining your BPM requirements The BPM marketplace has over a dozen major players and many smaller vendors. How do you find the BPM product that best matches your organization’s requirements? How do you find requirements you don’t know you need? SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe The first part of the answer is to use the reverse-engineering technique. Start by identifying all potential BPM products that could meet your needs. Then examine the features of each potential product and rewrite them as requirements. This technique is essentially running software development in reverse. Do this in enough detail so that when implementing the software no significant new requirements will be found. (Too many “new” requirements found during implementation cause delays and excessive costs.) The output of this process is a comprehensive list of requirements that includes unknown requirements. The second part of the answer is to have users rate the requirements for importance. For each requirement capture who wants it, why they want it and how important it is to them. Let users see their comments being written on the requirements and you will dramatically improve their buy-in. Once you have completed these two steps, you will have created your requirements profile, a comprehensive list of requirements rated for importance to your organization. Use the profile to create the RFPs or RFIs that you will send to the BPM vendors. When vendor responses are returned, use the information to perform the gap analysis and rank competing products by how well they meet your requirements. (A great tool for managing requirements and the gap analysis is Select Hub.) Use the output from the gap analysis to shortlist BPM products for demos. Finally, before you purchase the software, audit the winning RFI / RFP to verify the vendor was not “over-optimistic” with their response. BPM example As an example of reverse-engineering features into requirements, let’s look at PNMsoft, a vendor that recently moved from being a niche player to that of a visionary on Gartner’s BPM Magic Quadrant. PNMsoft has something they call HotChange architecture that allows a business process application to be changed in real time while the process is running. On top of this architecture, they have a work optimization module they call HotOperations. Take the case of a reinsurer processing a million documents per month. 90% of these documents are handled automatically by standard processes, but 10% are exceptions, e.g. incomplete forms, something new outside of existing processes, etc. There is a constant need to adapt the business process to reduce the number of future exceptions. There is also the need to allocate exceptions to people for manual processing based on availability, costs and skills. Looking at more detail, you would see that PNMsoft can run multiple versions of a process, and can route specific documents to different versions of the process. All of these are separate requirements and need to be captured as such. The ability to change processes dynamically while those processes are running is then written as a requirement. (Well-written requirements are necessary for successful evaluations). Now that you know this feature exists in at least one product, you can consider how important the requirement is to you. If you are like the reinsurer above, you might rate it as “Critical.” On the other hand, if you have only a few hundred exceptions a month, it might be rated as “Useful.” Remember to examine both functional and nonfunctional requirements. For example, consider licensing. PNMsoft licenses by the user or by the application. If there are a limited number of users and you have many different applications, then licensing by user could be the most cost effective. Alternatively, if people outside the company will use the software or you have many users and a small number of applications, licensing by application makes more sense. Other vendors may license by CPU or by server, which can be economical early on, but as usage grows so do costs. It all depends on your particular requirements. Capturing all requirements When developing software you can never be certain you have captured all requirements, but when buying software you can. The reason is that the total number of requirements is limited to those that are satisfied by the features of the products being considered. If you have a requirement that is not satisfied by the features of any particular product, that requirement will not affect the software selection at all (although it may change the scope of the project). When you identify all significant requirements up front, software purchase pains are minimized. Conclusion If you have never seriously considered BPM, selecting the right product is daunting. However, using the reverse-engineering process allows you to develop a comprehensive list of requirements, even capturing those you don’t know you need. As we like to say here at Wayferry: “Requirements are to software selection as foundations are to a house. Get them wrong, and there always will be problems.” Spend the time and resources needed to evaluate and select a BPM product properly, and you will be richly rewarded by software that meets or even exceeds expectations. Related content opinion How IT can both deliver business value and 'keep the lights on' IT teams spend too much time on u201cdaily churnu201d rather than delivering real value to the organization. Read how Mike Guggemos, CIO at Insight Enterprises tackled the problem. By Chris Doig Feb 16, 2018 5 mins CIO IT Leadership opinion 15 places to use requirements when selecting enterprise software Not understanding how important requirements are and where they are used is the root cause of most problems with implementing software. By Chris Doig Jan 29, 2018 9 mins Enterprise Applications opinion The backward way of gathering enterprise software requirements Organizations ask users for their requirements, only to find that when enterprise software goes live, it doesnu2019t meet user expectations. It turns out that we have been doing this backward for years. By Chris Doig Oct 05, 2017 5 mins IT Governance Frameworks SaaS IT Governance opinion The hidden costs of poor software purchasing exposed! Many companies think they know how to purchase software when in reality they have no idea of how little they know about the process! This article looks at the three places where money is squandered. By Chris Doig Jul 14, 2017 4 mins IT Governance IT Strategy SaaS Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe