The following is an interesting guest post from frequent forum contributor David Chassels:
Over the years, questions have been raised about BPM projects where there has been disappointment with outcomes. There are those who question BPM's "survival," as evidenced in the recent question here, but they are missing the point.
BPM is a discipline, not a technology, and It is the supporting technologies that will determine the effectiveness or otherwise of a BPM project in an organization.
If we look at how early BPM projects started, they were fairly lightweight local processes that were simple but not mission-critical. The supporting technologies were correspondingly "light," but did achieve some of the objectives.
Now we are seeing a need for the BPM discipline to be applied to the enterprise-level requirements and, as such, the rise in the number of new "product lines" such as adaptive case management (ACM) that come under the BPM umbrella. The real issue is not what is built but how it is built. With the focus on the dynamic people-and-process requirements, buyers now need to have a better understanding of the skills required and the likely outcomes of a project.
Such knowledge is called being an "intelligent customer." To become that, customers have to ask questions of the software technologies being used to deliver it. This is all more important as the market for enabling software is now dominated by a few very large U.S. vendors. As such, the big vendors do not innovate with new ideas, but spend their resources embedding acquired technologies into their core offerings. Real innovation comes from smaller players, and many are focused on niche modules that included early support for BPM.
To deliver end-to-end BPM, a supporting application requires a tightly integrated system that mirrors exact requirements as opposed to a well-integrated set of application modules. In order to understand what capabilities are available, there are important questions that need to be asked in relationship to the use of BPM-supporting software to build and run collaborative and transactional applications. It is about practical functionality to deliver value for money and adaptability for future-proof investment in applications.
These are simple questions, but will be quite revealing in the answers that will aid good decision-making before enterprise-level BPM projects begin::
- 1) How adaptive is the software to support both iterative build and future change and how is this achieved?
- 2) How is the specification handled in terms of both being understood by users and developers and how is that then translated into the build?
- 3) How much custom coding is required to build custom applications and how is future change handled?
- 4) Does the core technology support reusable features to speed-up future development and does it support being used as a shared service?
- 5) Are process, workflow, rules, state and calculation engines contained in one development tool? If not how do they handle these essential requirements?
- 6) How does the user-interface present information to ensure all relevant data is available to the authorised person at the right time and that new information is easily entered only once into the system?
- 7) Can a working prototype be built quickly to test requirements and engage policy makers and users for feedback?
- 8) Is there a method to estimate time-frames for delivery of the application?
- 9) Can the development environment provide an exact record in a business friendly format what has been deployed?
- 10) What capability is there to deliver intelligent applications giving flexibility to users dependent upon circumstances?
- 11) How does the architecture of the technology fit to connect to the legacy? How does it scale and does it require SOA?
- 12) What is the total "file size" of the integrated tool?
The IT industry has largely failed to support people and their required processes to deliver the required outcomes. As a consequence, this key area is a bit of a mess and needs to be addressed. Business recognizes that good processes are assets, but to remain so, they must remain adaptable to business change. Bringing together people, their processes, and "digitization" is just commonsense, but it needs essential flexibility/adaptability.
To achieve the desired outcomes requires knowledge. As industry strategy and thought leader Naomi Bloom says: "It really matters how your vendors build their software, not just what they build."
So before a BPM project of any size begins, some research would be a good investment. We should see the BPM discipline move forward supported by next-generation software applications.