Jacob Ukelson is once again pushing email and documents as the way process should happen when it is "design by doing":
The only way ?design by doing? can work is if you observe knowlwedge work in its natural setting. That means email, documents, meetings and telephony. That just doesn?t mesh with a BPMS. I think that most BPMS vendors would like people to tidily do all of their unpredictable, ad-hoc work in the BPMS, but the real world doesn?t work that way. People use what they like, and like what they know.? They are not going to change their habits just because the vendors think they should.
The idea that design by doing is antithetical to BPM doesn?t seem right to me ? there?s a spectrum between these poles, and i?ll give you an example.
The way I?ve seen Lean applied to white collar (officework/knowledge work) processes resembles design by doing. You start by running whatever they currently do, document the wasted effort/steps, try out changes in the process, til you get it right. Then you start training more and more people to follow the process. A BPMS can support this kind of work because you can iterate fast enough to keep up with the changes, even over a very long improvement cycle with many changes.
Now, design by doing isn?t quite the same as ?unpredictable work? ? but obviously, they are related concepts. If the work is inherently unpredictable, or improvements to it do not justify IT investment in a doing-by-design approach then I think ActionBase is a great answer to that need. As Jacob says, email and documents are the tool of choice when one doesn?t have a process ? precisely because of their ubiquity and rather than compete with that, I like how ActionBase leverages that truth.
As to his characterization of BPMS vendors - he may be right that they would prefer to have the unpredictable work go into tidy processes. But this is not a fair description of the BPM service provider community (or at least, of the firm yours truly works for), which has often been creative about applying hybrid structured and unstructured techniques to address knowledge work.
No matter what the vendors say, no business user can take a BPMS out of the box and start using it for their own work.
True - if you mean to use it without a single implementation dollar spent.? But if you have 100s or 1000s of people doing this email and document thing for a process, you can probably afford to spend a few IT dollars to figure out what the best practices are. Let the doing guide the design, but you have some efficiencies of scale to achieve. In general, BPM has to get simpler - and the kind of approach ActionBase takes seems (to me) to be a great example.
Jacob wraps up with something I couldn't agree more with:
So if we are really to make ?design by doing? a reality as part of BPMS, then somehow the tracking and management of? existing end-user tools and work paradigms (especially email) have to become a part of the conversation.
So true. BPMS vendors need to be able to track email-based processes.? A Lean or other process improvement expert can work without this technology, but as with structured processes, it is so much easier to get to the "right answers" when technology supports your efforts.