Your host started his IT career at IDC, in the previous millennium. Working for IDC gives one a perspective on analyst relations with vendors and end-users. Analysts are little bit like movie reviewers -- they like technology as much as movie reviewers like movies. And the economics of the technology analysis business is such that it's difficult for analysts not to be cheerleaders for technology, in the same way that movie reviewers find it difficult not to be cheerleaders for movies, or, considering the subject of this website, cheerleading for BPM software.
With this model in mind, it's interesting to note a general enthusiasm this year for the prospects of BPM software technology. The arrival of BPMN 2.0 has the potential to make adoption of BPM software easier, for larger groups of users, and possibly even business analysts. Other factors conspire to create the preconditions for BPM liftoff in 2012, including the experience gained in a decade of incremental BPM software adoption and a business "scissors" crisis, consisting of a deep recession on one hand and frightening international competition on the other.
So between business motivation and technological readiness, the case for accelerated BPM software technology adoption in 2012 looks good! To emphasize the business case for BPM, it's worth underscoring a point made elsewhere on this website, which is that BPM is the technology for enabling business model adaptability -- and business model adaptability is what you need to respond to both recession and competition at the same time.
With the tea leaves in place, why might 2012 turn out to be just another good year for BPM -- where new organizations adopt BPM and discover that BPM is very worthwhile -- but that overall the business of IT is conducted as usual? As they used to say, "what if they announced the revolution and no one came?" or in this case, what if projects which could be done in BPM software are instead implemented using existing approaches, for example as an add-on module to the ERP platform, or maybe constructed in a Java framework etc.
What are the stumbling blocks which might slow the adoption of BPM software?
* * *
There are three key reasons for suspicion about the prospects of BPM. If you can address these questions, then you will have removed your own roadblocks to BPM achievement -- and this could be your year of "living BPM"!
1) MASTER DATA MANAGEMENT (MDM) -- Business processes live in the sea of data that is any organization. As discussed elsewhere on this website, MDM, or more generally data modelling and data management, defines what is possible in any organization. And the state of data models and data resources is not pretty -- and it's getting worse, which is to say that data entropy is increasing.
Data modelling and data management problems may not impact the development of a simple process, but just adding a few simple processes is not what one expects in the Year of Living BPM. Real business value is achieved by implemented ambitious, cross-functional processes. Ambitious BPM is exciting, but data chaos makes achieving this vision technically difficult.
2) BUSINESS PROCESS GOVERNANCE -- Taking the idea of an "ambitious process goal" even further, we run into the serious problem of process governance. One doesn't have to be an Enterprise Architect or an SVP of Supply Chain to know that real business processes are often undocumented, overlapping, poorly interfaced and poorly understood. You can't remodel the kitchen if you can't find the kitchen!
This analogy might seem unreal and unfair until one considers supply chain processes such as procure-to-pay or order-to-cash, where physical, informational and financial flows are almost always uncoordinated with each other and for which no one business executive can be said to own end-to-end responsibility. Ambitious BPM is exciting, but a lack of real business process governance makes achieving this vision organizationally difficult.
3) BUSINESS PROCESS VALIDATION -- The last challenge to achieving ambitious BPM goals is not a problem inherent to a host organization, but rather is a problem related to BPM technological maturity itself. BPM technology is based on graph theory and complex mathematics, which is fortunately hidden from the IT process designer or business analyst. Nevertheless, in the same way that the mathematics of relational calculus lies behind relational database products, heavy duty graph theory or pi calculus lies behind BPM software.
The delivery of BPM products based on mathematics is what distinguishes serious BPM software technology from the ad hoc workflow technology products of the 1990's. Workflow basically consisted of a series of queues to which tasks could be allocated -- and said task then progressed to another queue according to the workflow diagram. But just as relational software technology guarantees consistency and correctness of databases under scale, so to does BPM software technology guarantee consistency and correctness of processes under scale, i.e. when diagramming the true richness of organizational reality.
The only problem with this nice vision of BPM software technology is that the technology is not as mature in its process space as relational technology is in its data space. And the lack of maturity in BPM technology becomes all the more apparent under scale, i.e. when tackling the ambitious processes we want to tackle in our Year of Living BPM.
With the current state of technology, it is common to require programmatic intervention in business process deployment in order to ensure that the process works. And this means that ambitious BPM programs become much more expensive than one would anticipate. Not only are ambitious BPM projects more expensive because process complexity cannot be handled by diagramming alone, but the inevitable adaptation of any business process becomes increasingly difficult. Ambitious BPM is exciting, but a lack of mature BPM software technology undermines the BPM business case compared with traditional software development alternatives..
* * *
What is the way forward for BPM? This website advocates BPM as the answer to business software needs. BPM is the software technology directly concerned with work. And that means the BPM is about the work of business. And however good current BPM technology is now, it's assured to get better in the future.
The release of BPMN 2.0 is certainly a step forward. But the full promise of business process software technology will not be realized until the issues of data chaos, process governance and BPM technological maturity are resolved. Each one of these issues is enough to seriously retard BPM software adoption -- between all three issues, 2012 will more likely be "The Year Of Incremental BPM".
As for the BPM
- 30 -