Published: 25th May 2006
Copyright © 2006
The number one reason for such broad inclusion of BPM functionality in vendor portfolios is the flexible nature of business process management. Rather than encapsulating specific process-centric functions in software, as is the norm in process applications prior to BPM, the more generic workflow tools of BPM allow vendors to address anything (and almost everything) that falls outside (or on the edges) of current process offerings.
Basic BPM functionality allows organizations to use software in the operation and management of organizational activity in both atypical packaged process scenarios and for process scenarios that are not encapsulated in process-centric software. Because every repeatable activity in an organization can be modeled, operated and managed with BPM there is no limitation to where or how BPM can be used.
In this respect, BPM software is like a programming environment, or better, an application development environment. What makes BPM truly unique in this regard is the level of abstraction BPM offers in comparison to traditional application development tools. This abstraction varies on a vendor-by-vendor basis, from being a mix of graphical ‘no code’ development interfaces with programming interspersed into functional areas where code is used to implement specific capabilities, to very programming-centric products; to products that can be implemented without a single line of code ever being written.
Further, the use of BPM has expanded to cover a broader set of processes over the last year or so. These processes fall into four major categories including: business processes that are primarily human-centric where ‘actors’ (direct participants in the process) are the employees/partners of the business; business processes that have a mixture of human and machine actors; business processes that have only machine actors (better termed Business Services rather than business processes); and business processes where the customer is an actor (direct participant) in the process.
Where the focus is, depends on the focus of a given vendor, their customers, and their strategic direction. In reviewing BPM products (this is a focus area right now for the Process Practice) the variation in product strategy shows a stark contrast between these approaches. The BPM market is not an “apples to apples” product space but, instead, a cornucopia of products from the truck garden of BPM.
Yet most of these approaches have merit. Adobe is focused on processes where customers are direct participants in the processes. Onyx is driving towards advanced flexibility within their process applications that focus on CRM/SFA. TIBCO is strongly positioned on human/machine mixed actor processes while Ultimus has its sweet spot on a no code development that is primarily human-centric processes. That gives a flavor of the diversity that abounds in the BPM market.
All of these approaches have merit. In fact, product/market approaches in general within the BPM market have merit—as the flexible nature of even basic BPM functionality makes it much easier for an organization to adjust and adapt to changes. When we combine the actors in BPM (employees, machines, customers) with the flexibility and agility inherent in the BPM approach to activity operation/management, the basis for such broad adoption by software vendors becomes understandable.
What has now begun is the refinement of product and market positions. Software vendors are working hard to ‘fine tune’ their product offerings—a fact that has taken us to new functions and features in many BPM products that, though often highly touted by their respective vendors, are really market tests to see how well these features and functions do at adding value. Customers have begun to think they know what features they need (such as segmented modeling ‘views’, simulation, optimization and complex event processing) but we are still in the field trial stage for all of these capabilities.
Most will produce extended value to BPM product offerings (although a byproduct of this activity for some vendors is that they are now treading dangerously along the edge of too much flexibility/capability that results in increased complexity at every level), at least within a target demographic. Exactly how they produce value, how much value they produce, and what the best design case is for each of these features will come from the results and lessons learned in their initial use.
That said the conclusions that can be drawn today are that:
Posted: 6th June 2006 | By James Taylor :
An interesting assessment. The proliferation of BPMS solutions is perhaps a good reason for keeping business rules in a business rules management system - that way multiple BPMS solutions can be used without compromising/duplicating critical business logic.
The messages above were all contributed by IT-Director.com readers. Whilst we take care to remove any posts deemed inappropriate, we can take no responsibility for these comments. If you would like a comment removed please contact our editorial team.
We automatically stop accepting comments 180 days after a post is published. If you would like to know more about this subject, please contact us and we'll try to help.
Published by: electronicdawn Ltd.