In my last article I talked about BPM and Software as a Service. As organizations look at SaaS capabilities of a BPM tool, there are many other features and capabilities that must also be taken into account and evaluated prior to making the final selection. Myriad of features available to be evaluated against current investments can make the BPM tool selection a bit challenging. In this article, we will focus on some key areas that organizations can evaluate to make the right choice.
Regardless of the preliminary recommendations presented by either IT or Business, a methodical and well thought out approach should be executed for long term success. Key to success is ensuring collaboration and partnership between IT and Business during the selection process. While business can provide long term vision for process needs and process types, IT can bring to the table the current capabilities and architecture landscape. Based on these, a detailed evaluation checklist must be created that spans across various areas that touches both business and IT capabilities of tools being evaluated.
To start with, organizations must perform a detailed proof of concept (POC) to select the final tool. I have helped many of my clients in executing successful POC where we had started out with outlining a specific business scenario with touch points into IT systems. Only when both Business and IT were on-board, did we proceed with the POC implementation. POC was conducted on client premises and in presence of both IT and Business users. This not only provides a clear picture of tools strengths and weaknesses but an intimate touchpoint into vendor and company.
This approach is totally different from the one where canned demos are shown on vendors’ own machine or laptop. Though useful in showing generic capabilities, it lacks the rigor and actual display of tool’s inner workings in real life scenario i.e. creation of a process , ease of integration with existing services or IT systems, ease of implementing business rules, and usage of dashboards.
The rest of this article will focus on some key aspects of evaluation.
Integration vs. Human centric tool: Typically organizations focus on one or the other. I strongly propose evaluating tools from both sides of the spectrum. Over the passage of time, vendors have strengthened their offerings and focused on areas where historically they were weak. The gap between the two is starting to reduce and therefore they must both be considered.
Tool Architecture: Some BPM tools are built on Java platform while others are built on .Net architecture. Each organization has varying degree of appetite for them. IT must evaluate the BPM tool architecture in light of the current architecture landscape and investments made. As part of the tool architecture, some vendors store data in relational format while other store as BLOBs with various ways to access it. Again depending on the preference, one way could be more beneficial than the other and therefore should be taken into account.
Business vs. IT ownership:Â While selecting the tool, organizations need to decide upfront if they want to empower business or IT in taking ownership of the business processes. BPM should focus on business with key support from IT. If organizations want their business groups to play a key role in process discovery, analysis, and modeling then selecting a tool that is IT centric is not going to help. Typically Pure play or Human centric BPM tools excel at these features i.e. empowering business users to focus on business processes.
IT integration capabilities: A lot of organizations have legacy systems that need to be integrated with as part of a business process. BPM tools come with out of the box adaptors that might be sufficient for this purposes. If not then the possibility of purchasing adaptors need to be looked at and cost becomes a factor. On the other hand support for Service Oriented Architecture becomes important as well. Whether it is consuming existing services or service enabling existing interfaces and consuming them, the support for SOA becomes critical. In addition, exposing a Business process implemented in the BPM tool, as a service either to its customers or internal organizations is equally critical. Some vendors can execute this task by a simple click of the mouse with out any custom coding.
User Interfaces (UI) development: A good amount of time is spent on development of User Interfaces. Some BPM tools provide the capability to import UI screen code while in others all UI is created in the tool’s proprietary language. Usually organizations are evaluating BPM tools as a replacement to their existing IT system(s) with UI built over time (custom coding) in them. Organizations looking for reuse of that code would need to look into the tool’s import capability of outside code.
Existing investments: An organization that has purchased a component of BPM suite from a vendor must also look into extending that component into full fledge BPM tool from the same vendor. Given the current economy, vendors tend to offer discounts to companies willing to purchase additional components.
As organizations start to evaluate tools, I strongly recommend looking beyond the immediate needs. Tool selection based on short term needs will typically turn out to be a limiting decision in the long run. Other factors such as licensing cost, integrated development environment needs, and dashboard capabilities are all equally important to consider that are not covered here in this article.
