SWOT on BPM

Toward the end of a problematic first implementation of a BPM solution, I was asked to evaluate whether it was worth pursuing this for future solutions in my organisation. The result was a SWOT (Strengths Weaknesses Opportunities and Threats) Analysis in which I put the case for persisting with BPM. An edited version of this paper follows. While I echo the optimism of vendors for large organisations there some cautions and costs that need to taken into account when embarking on the journey to adopt BPM.


Background
Business Process Modelling (BPM) is a technique for implementing IT systems that makes the process explicit usually through the use of a graphical tool that allows the process to be illustrated as a flowchart. This flowchart can be implemented directly as system of integrated application and services once these application and services have been built.

The process model represents processes of an enterprise, so that the current process may be analysed and improved in future. The development of a business process model is typically performed by business analysts and managers who are seeking to improve process efficiency and quality. The process is implemented by IT staff who may be assisted by BPM tools.

In theory, BPM tools provide business users with the ability to model their business processes, implement and execute those models, and refine the models based on real data. As a result, business process modelling tools can provide transparency into business processes, as well as the centralization of corporate business process models and execution metrics. In practice, BPM tools require significant training and needs users to work closely with other specialist IT staff to implement systems using these tools.

Our organisation has acquired Aqualogic BPM which is being used to redevelop the XYZ system. Vendor X are doing the development work. Aqualogic is new to both Vendor X and our organisation. This has meant both organisations have had to undertake learning in this technology. The project has taken longer than expected. The project will cost more than expected and the support model for this technology has not yet been developed.

This paper will assess the risks involved in moving forward with BPM and advise whether we should continue with XYZ system using the BPM product.

Analysis
When looking at the benefits related to BPM a distinction needs to be made between the BPM process and the BPM tools. Our use of BPM tools so far, has been to reverse engineer the XYZ system and implement an existing process. This is not the most beneficial way to use BPM and therefore will not immediately produce any savings for XYZ system.

More benefits are likely to flow from the revision of the business processes that is inevitable with complicated processes. The mapping and refinement on business process is the same as any continuous improvement initiative.

An effective BPM implementation is much more top-down. BPM is more suited to projects that involve a significant Business Analysis effort. The analysis of the process should be conducted at the business level. The process is then refined and optimised and where possible automated.

Computer Applications are no longer written purely for discrete business units. Modern enterprise applications link different business units with ever more complex processes involving people from all over the organisation. The emerging standard approach for this is to break applications into services (Service Oriented Architect) and link these together using BPM tools. In this way BPM can support large integrated enterprise applications. Along with a portal product and an enterprise services bus, a BPM tool is a central component of the modern SOA development toolkit.

If the right skills and tools are in place, BPM promises to enable a more agile organisation. Conventionally, changing software to implement a changed business process involves editing complicated program code possibly spread over a number of different applications. With BPM the process is presented in a more intuitively obvious form and can be stored centrally rather than spread across different applications. This enables changes and therefore more business agility because of the ability to change these processes more rapidly at lower cost.

Strengths

• BPM allows the process to be viewed and communicated to non-technical users
• The BPM can be changed by staff who understand the BPM tool
• The business process is easier to follow than the corresponding Java code.
• Status can be tracked using the BPM Tool
• Possibilities for process change can be investigated using the BPM diagrams.
• Supports Services Oriented Architecture (SOA)
• Standards-based approach to integrating diverse systems and data sources.
• Engenders Continuous Process Improvement
• Improves business agility

Weakness

• Staff need to be trained to use the BPM Tool
• The organisation needs to pay significant costs to license the BPM tool (including non-production versions)
• There are more points of possible failure in production systems.
  Production systems need to be supported which may will involve extra servers.
• Business process changes normally require constant involvement of the user. (Collaborative development model). This may require more user resource but also a change in software development approach.
• The default process management screens on the BPM Tool may not be appropriate for users. In the case of XYZ system it is costing more to implement custom interfaces.

Opportunities

• We could use the models in the BPM in our Architecture repository and benefit other projects.
• Other projects will become easier to develop using BPM once we have sufficient skills and a critical mass of services that can be used with BPM.

Threats (Risks)

• The organisation may not have chosen the correct tool and this may be replaced by a competitors product in the future.
• The Aqualogic Tool may not be supported by the vendor in the future
• It is possible to map more complicated processes. There may be a tendency to get automated tools to do this rather than simplify the business process.
• There is a performance overhead in running BPM applications. This may cause programs to perform slowly and impact users.
• BPM tool support from any vendor is limited in regional locations.
• If we write custom interfaces for users to manage BPM workflow then we have to make sure these interfaces are compatible with future versions of the tool.
• Outsourcers who have forged a partnership with our organisation will be able to charge high rates to support its BPM tool.

Conclusion
The choice of BPM for XYZ System was sensible from the point of view that the system was automating complicated business processes involving different roles. The decision was not ideal because the project did not require a business analysis stage and an opportunity to refine the business process.

The XYZ system project will therefore suffer the learning curve costs of the BPM Tool. It should also reap some benefits later on for having a process that can easily be modified our organisation retains sufficient skills to do this.

The BPM version of XYZ system should still be implemented. Handover to support should involve making sure there is an adequate support model for the product. This should involve having someone in-house that can support the runtime component of the BPM Tool and assist with the design-time component with the tool.

The investment in in-house skills should be used in other projects. The identification of the potential to use BPM should made early in a project so that the Business Analysis can be done with BPM in mind.

The risks are significant but most can be addressed by acquiring the necessary skills to use the BPM tool effectively. The benefits are also significant. An effective BPM capability will assist build integrated systems effectively and efficiently, and support implementation of a Services Oriented Architecture.

References

Rudden, J, Making the Case for BPM: A Benefits Checklist, BPTrends Jan 2007, http://www.bptrends.com/publicationfiles/01-07-ART-MakingtheCaseforBPM-BenefitsChecklist-Rudden.pdf
Sinur, Jim, The Top Five Benefits That BPM Delivers Today, Feb 4 2009, http://blogs.gartner.com/jim_sinur/2009/02/04/the-top-five-benefits-that-bpm-delivers-today/
Khadye, Vinayek, Benefits of BPM Systems, 7 Mar 2005, http://it.toolbox.com/blogs/bpm-blog/bpm-series-benefits-of-bpm-systems-4837
Cooper, Mark and Patterson , Paul, Business Process Management (BPM) Definition and Solutions, May 2007, http://www.cio.com/article/106609/Business_Process_Management_BPM_Definition_and_Solutions?page=5