The market for Bus Process Mgt Suite (BPMS) tools is still an early, emerging market with over 150 software vendors vying for leadership. Typical of emerging markets, there will be multiple waves of consolidation over the next 2-5 years, as buyers become savvier and the technology matures into a more predictable set of features and functionality. Given these uncertainties, the best approach for investing is to implement strategically yet buy tactically. Yet many users seem to ignore these market dynamics and perhaps, unwittingly, do just the opposite. When new technologies are emerging, it is not the time to attempt to make the “enterprise standard” product choice (aka buy strategically). Rather, the greatest innovations more typically come from the new startups in the market. Similarly, tactical implementations detract from the potential high value, high visibility that new technologies can deliver for early adopters. Inevitably, users that do not think strategically or who implement tactically succumb to internal battles over vendor decisions, funding, project priorities and project scope and fail to deliver agile, flexible, adaptive processes. This article describes two typical scenarios where business process management (BPM) efforts go awry.
The first scenario is often seen in user organizations that have pursued process thinking (such as Six Sigma or LEAN) for quite awhile. They clearly understand the value of continuous process improvement and have experience streamlining manual processes. As they expand the scope of their initiatives, a key, strategic project is identified. Strategic projects have direct impact on key business performance metrics and require coordination across a number of critical boundaries, such as departmental boundaries, system boundaries and across the value chain. Critical information is shared or passed along at the boundary, the loss of which negatively impacts the outcome. With a strategic, highly visible process problem, the IT organization (ITO) wants to pick the right technology from a reliable, strategic vendor to bolster their chances of success. Naturally, they turn to the larger, public vendors with whom they have existing relationships and perceived leverage.
However, larger vendors like IBM, Microsoft, Oracle and SAP often delay entering emerging markets until they are proven to have high growth, high revenue potential. Although these vendors may market their growing focus on emerging markets, their product delivery often lags pure play startups and results from multiple acquisitions. For BPM, both IBM and Oracle have taken the acquisition path to complete their assembly of a BPMS. Microsoft has barely started to message about BPM. For SAP, “process” still equates to “application” and it is evolving its earlier technologies to be more architecturally consistent and standards based in NetWeaver.
As briefings, presentations, demos and proposals are reviewed with the BPM team, the business managers driving the process improvement initiative quickly realize that these tools are designed for IT professionals and emphasize the systems integration aspects of the process. Support for human workflow management, business rules definition and maintenance, human collaboration, document and content flow, decision criteria, resourcing rules, etc are all weak. As the business decision makers lose confidence in the such vendor’s ability to meet their process requirements in the short term, internal battles arise over who owns the process initiative, which decision belongs to IT versus business, which features are truly required versus nice-to-haves, what kind of ROI is anticipated, how long before a working solution is delivered, and architectural fit versus business user friendliness of the modeling environment.
Building a partnership between IT and business and clearly defining roles and responsibilities are the number one critical success factors for strategic process initiatives. Business users should own responsibility for the highest level process model from design through execution phases. They need to decide what tasks must be managed, where flexibility is needed, and when it is time to optimize the process again. IT, however, should own the decision about the technology implementation. Because business and IT will share responsibility for developing the complete solution, a multi level modeling environment that supports various degrees of technical specificity should be a key selection criteria. Business analysts (aka business process modelers) will need to be able to do the highest level models whereas IT professionals will have to do the architectural and systems integration models. At this stage of the market evolution, a BPMS is more of a business enabler than a long term, IT development platform.
Alternatively, in this scenario, IT should make a tactical investment in a leading edge product likely from a pure play startup vendor knowing that the vendor viability is riskier but that the technology strength and viability will persist for the duration of this strategic project and potentially beyond. Investment risks can be reduced through good negotiations, emphasis on XML Web services standards, and accessible XML metadata for future tool interoperability. Our second scenario is typical of user organizations new to process orientation. Various business initiatives such as compliance (ie SOX, Basel II) and self service (ie eGov) drive a number of new process automation requirements across different functions within the business. Typically, multiple tool decisions are made and each project works independently of others. The scope of the process automation tends to be narrow, extending only to the boundaries of the line of business manager’s authority. Thus the implementation is very tactical. Process silos result because the design only reflects the work flow and requirements of the individual process rather than recognizing the interdependence between processes across departmental boundaries and also that the same workers participate in multiple processes. Workers are likely to end up having multiple “in box” queues for different kinds of work items, defined by the different processes in which they play a role. Each manager optimizes for their own function, not across boundaries, and to their own performance metrics, which are often in direct contradiction to those within other functions. This compounds the difficulty when trying to integrate narrow processes after the initial design and optimization and causes a significant amount of waste and rework. At some point, senior management recognizes that none of the process solutions are well integrated with other management processes and is frustrated that what started as a strategic objective (ie SOX compliance) has deteriorated into a number of tactical implementations.
Just as in applications, things that are not designed to work together, don’t work together after the fact without significant rework. To avoid this situation, users should design strategically by architecting a holistic approach to SOX compliance, (following our example), using multi level modeling tools to highlight the interdependencies across process participants and functional units. In this way, processes can be optimized to meet corporate objectives rather than just meet local, departmental objectives. Once again, the emphasis of the initiative should be on strategic designs and long range objectives rather than tactical implementation details. Many Enterprise Architecture modeling tools can output models as XML schemas which many of the leading BPMS tools can import. Providing a rich process model to multiple BPMS vendors for a deployment oriented proof of concept will help to distinguish BPMS tools further.
Too often, “tactical” technology investments are thought to be “throw – away” and therefore a waste of money. They are not. When technology is new, somewhat unproven, early adopters will reap significant benefits by spending more time on strategic designs and projects and less time evaluating a dozen different vendor solutions.
