Re: [service-orientated-architecture] Re: [ZapFlash] The Human in the Machine

[Ron Schmelzer]

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 > > > > > > -- _____________________________________________________________ Ronald Schmelzer [EMAIL PROTECTED] Senior Analyst ZapThink LLC Direct: 781-577-2779 / Main: 781-207-0203 YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.