About Us Our Team Our Investments News Investor Info Blog



More on Naming HPM

September 23rd, 2008 by Jacob Ukelson

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.

Stumble it!  Subscribe

4 Responses to “More on Naming HPM”

  1. Sandy Kemsley Says:

    Gartner’s take on Dynamic BPM isn’t exclusively about rules, although that’s a part of it: it’s the ability to support process change by any role, at any time, with very low latency. It’s really agile BPM, but Gartner has to have their own names for everything ;)

  2. Jacob Ukelson Says:

    Thanks for the clarification. I think actually enabling most BPM systems for process change by any role would be very difficult on many different levels, given the way most BPM systems work today. Being able to think about processes that get modified in flight is in itself a big leap for many process designers, and being able to actually define the change needed at a granular and detailed enough level so the BPM engine could execute the change would be beyond the capabilities of most people in the process. On top of that there is the issues of testing, storing and managing all the processes variants as they arise. That is what lead me to the conclusion that in the end most BPM systems will just add rules (a good thing), but that won’t actually make them truly agile, or capable of handling the ad-hoc, unstructured human processes. It will just make them more flexible, better architected BPM systems for structured tasks.
    I think moving toward BPM folks will need to think differently about these types of agile processes, and there is a need to marry email (or in the future wiki) based HPM systems and BPM systems as the only way that could actually lead to truly agile process management.

  3. Sandy Kemsley Says:

    I’m in complete agreement on the difficulty of changing processes within existing BPMS — that’s why rules play so heavily in agility, since they provide a relatively simple, bounded, parameter-driven way of allowing a business participant to fine-tune the behavior of the process. This, of course, is not the same as actually changing the process, but that’s what passes for agility in today’s BPMS.

    Email is problematic for so many reasons, however: multiple copies, little control, etc. Wikis, providing a common repository of knowledge, are a better paradigm for this.

  4. Jacob Ukelson Says:

    I agree. Standard email in its current form won’t cut it, but still that is how people are choosing to actually “manage” these type of processes today. So I think a good solution is to let people remain in their email environment, but with some additional implicit and explict tools for managing these human processes. I think it will be a while until Wikis replace email (if ever).
    That is why I like ActionBase’s approach and is what led us to invest in them - its ActionMail product provides a repository of process information in context, a system of record for the process and its related information, a single copy (per process) of all the process related correspondence and documentation, and of-course management and monitoring of the process - all within the user’s familiar email (MS Outlook) environment. It is a way to provide them a managed version of email’s agility that can be used to manage their human processes.

Leave a Reply