Comments on: More on Naming HPM http://exeedtechnology.com/more-on-naming-hpm Fri, 30 Jul 2010 15:57:49 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: Jacob Ukelson http://exeedtechnology.com/more-on-naming-hpm/comment-page-1#comment-923 Jacob Ukelson Thu, 25 Sep 2008 12:31:10 +0000 http://exeedtechnology.com/more-on-naming-hpm#comment-923 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. 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.

]]> By: Sandy Kemsley http://exeedtechnology.com/more-on-naming-hpm/comment-page-1#comment-922 Sandy Kemsley Thu, 25 Sep 2008 11:44:59 +0000 http://exeedtechnology.com/more-on-naming-hpm#comment-922 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. 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.

]]> By: Jacob Ukelson http://exeedtechnology.com/more-on-naming-hpm/comment-page-1#comment-921 Jacob Ukelson Thu, 25 Sep 2008 07:27:31 +0000 http://exeedtechnology.com/more-on-naming-hpm#comment-921 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. 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.

]]> By: Sandy Kemsley http://exeedtechnology.com/more-on-naming-hpm/comment-page-1#comment-916 Sandy Kemsley Wed, 24 Sep 2008 18:37:33 +0000 http://exeedtechnology.com/more-on-naming-hpm#comment-916 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 ;) 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 ;)

]]>