I read some some articles on “Dynamic BPM”, one by Scott Byrnes of HandySoft (http://www.dmreview.com/dmdirect/20070323/1079086-1.html) and a newer take on the same theme by Ian Louw from PNMSoft (http://bpmfundamentals.wordpress.com/2008/09/16/information-overload-making-a-case-for-dynamic-bpm/) and thought that perhaps Dynamic BPM could be a possible candidate for a name instead of HPM. So I did a quick search of Dynamic BPM and came back with a blog post by Sandy Kemsley (http://www.column2.com/2008/09/gartner-bpm-dynamic-bpm/) which points to Gartner’s use of Dynamic BPM as a way to descibe the addition of external rules to a BPMS - a very different take on things than the other usage (which focused on email overload). That brought home something that I suspected - any name that uses a prefix to “BPM” will be considered just an additional feature to BPM - and I believe that HPM is a fundamentally different (though complementary) category. It isn’t that I don’t think external rules will be a valuable addition to BPM toolkits, it is just that they won’t solve the problem of ad-hoc, evolving, human intensive business processes now being managed through meetings, documents and emails. I think managing those types of processes will require something very different than what is available in today’s mainstream BPMS.
Archive for September, 2008
I was reading a Forrester report “The Emerging Technology Trends that CIOs Should Care About“ and was struck by what they call “Dynamic Business Applications” where they claim that “Most business applications are too inflexible to keep pace with the businesses they support, as they force people to figure out how to map isolated pools of information and functions to their tasks and processes, and they force IT pros to spend too much budget to keep up with evolving markets, policies, regulations, and business models.” I couldn’t agree more, especially since they break this out separately from BPM.
This is especially relevant for the fluid environment needed for the kind of work done by knowledge workers, especially for ad-hoc processes or exception handling. This type of work needs a new paradigm where the ad-hoc, human way people actually handle most process needs to be the guiding mechanism. Knowledge workers use an implicit process framework that they use for their tasks, but almost every instance is some sort of exception. I think this one reason the use of email is so pervasively used by knowledge workers for their processes. This very different from the structured processes that are handled by BPM - and we’ll need a new paradigm for it. I have started to use the term Human Process Management - but I am not sure that is the best name for those ”process frameworks (usually handled via email and meetings) for ad-hoc “unstructured” human centric processes.
I was at the Gartner BPM conference last week. Walking around the vendor showcase, one thing that struck me was how similar all of the vendors offerings seemed to me (with a few exceptions). Sure some were traditional enterprise software, some were SaaS, some vendors stressed one set of features, while another stressed a different set - but to me all the vendors in certain BPM space (document centric vs. integration centric) all looked pretty similar. I am guessing most people interested in a BPMS feel the same way.
What interested me was how they proscribed the process for creating a BPMS based application to implement an existing business process. For most, the first step is to create a model describing the process - using a BPMN modeling tool. The model is usually created by a business analyst (usually someone in the IT department) that understands the process. This model is a high level description of the business process which is used to bridge the gap between the business (they understand the process) and IT (they understand implementation and data). What struck me was how much the methodology reminded me a of the “traditional” top down ways of creating software . Since it very difficult to automatically create the actual complete, executable production system from the BPMN model - the model serves as a requirement definition for the development phase - which is handled by IT. Any end-user iteration and understanding is around the BPMN - which is a very abstract description of the process to be implemented. This is then handed to the IT folks for implementation - with the standard lag of months between requirements and actual system. This will work fine for processes that are rigorously defined, unchanging and complete, it may work for processes that are rigorously defined with a small number of exceptions - and will completely breakdown for ad-hoc, unstructured Human Processes. The reason is that these ad-hoc human processes are not well defined, and exceptions are the rule. The only way to approach this is same way you approach building human intensive software - iteratively, working intensely with customers on working prototypes - either low-fidelity or high-fidelity. John Gould and Stephen Boies taught me long ago that iterating on the spec (i.e. requirements or model) just doesn’t work. I also learned that if you are implementing an existing process - you want to keep it as familiar as possible to the users, which means let users continue to use whatever they are used to (or feels natural to them) whenever possible.
This is why I think that existing BPMS vendors won’t do well in the ad-hoc, unstructured Human Process space. It will require a much lighter weight, flexible (or bottoms up) environment where processes can be easily created, modified and tested in the field - with the turnaround between versions (including the initial version) is measured in days (or hours) instead of weeks or months. I personally believe that the more Human Process Management Systems let users remain within familiar user environments (currently eMail and MS Office tools, Wikis and other tools in the future), the easier it will be to get these systems accepted by the organization and end users.