Those who are interested to follow up this debate may like to visit
http://www.human-interaction-management.info, where you will find a
carefully thought-out approach to the problem of processes that lie on
the human end of the spectrum. There is also a free toolset in
development - find out more at http://www.humanedj.com.
As Steve R-T points out with respect to SOA, thinking about things
formally is really a very practical way forward, and yields useful
tools. To my knowledge, HIM is the only such approach that has been
put forward to date.
--
All the best
Keith
http://keith.harrison-broninski.info
Ron Schmelzer wrote:
Hi Todd --
Glad to help spur debate on this topic, and good feedback! Of course,
you're right that most BPM systems factor in the human element through
workflow / tasklists, but they don't factor in the concept that a human
might know more about the process, its exceptions, and any conditions
than an automated system. There are many instances in human-controlled
processes where the automated system can only handle the understood
conditions and a human must handle any exceptions. Even moreso, when a
human understands more about what happens next in a process than an
automated workflow, the BPM system often simply gets in the way.
There's a desire by IT folks (myself included) to want to automate
everything and assume that users get in the way. Well, this ZapFlash
brings up the idea that maybe it's the reverse, that we should be
trying to human-enable everything and assume that systems, from time to
time, might get in the way.
Obviously the truth is that there's a spectrum here of processes. Some
can be fully automated, some partially automated, and some not
automatable at all. For those that can be fully or partially automated,
BPM systems have proved their worth. For those that can't be automated
or where humans have more control than not, and especially in cases,
like the Mechanical Turk, where a human is really the Service requester
or provider, maybe something other than a BPM is mandated.
At the very least, worth a vigorous debate. If we circle round to the
fact that BPM systems simply need to evolve, that's one case. If we
realize that a new sort of process design and control is mandated, then
we can advance the state of IT by figuring out what that looks like and
how it works.
Good thinking! Have a great weekend,
Ron
Todd Biske wrote:
This was the same paragraph that struck me, only it
raised some
questions. BPM suites all include workflow/tasklist capabilities so
that manual activities can be included in the process. As I read
this, it tells me that those efforts are a waste of money, since they
are not fully automated. Am I misinterpreting this? To me, it's
more about whether the process is well defined or not than whether it
can be fully automated. Of course, one could argue that if it can be
well-defined, then it is a likely candidate for automation.
Ron, could you clarify this for me?
-tb
On Jan 13, 2006, at 4:00 AM, Keith Harrison-Broninski wrote:
> ZapThink wrote (Zapflash of Jan 12):
>
>> And, speaking of business processes, when humans are involved,
it
>> makes very little sense to have a centralized, computer-based
system
>> coordinating business processes on behalf of humans. The
notion of
>> centralized business process runtime engines only works for
fully
>> automated processes. When a human is responsible for making
decisions
>> about where and how to fulfill Service requests, a centralized,
>> orchestrated runtime process engine only gets in the way.
Indeed,
>> each
>> Service requester or provider might know more about what the
next
>> step
>> in the process is than some central flow-control engine, since
a
>> human
>> might be responsible for fulfilling or generating Service
requests.
>
> +1 with knobs on! I couldn't agree more - see http://
> www.humanedj.com.
> Thank you and well done for describing this so succinctly, chaps
at
> Zap.
>
> --
>
> All the best
> Keith
>
> http://keith.harrison-broninski.info
YAHOO! GROUPS LINKS
|
