Can BPMS really support "Design by Doing"?

As I mentioned in my last post, I really like Jim Sinur’s term “design by doing”. It is a great term, but doesn’t describe a new work paradigm – the news is the ablity to allow people to do their work in a way that is natural to them, and then track and montor the work in such a way that it can, over time, be abstracted into a design. The problem is that it just doesn’t fit with where BPM suites are today – or where they are going. BPMS tools are built for developers, and are becoming more and more complex. A BPMS is used to model and then create applications that replace the way people do their work today. So “design by doing” is almost the antithesis of the reasons BPM suites are adopted and used.

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. 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. It requires technical people to get it up and running, and to create an appropriate application. Until that upfront work is done, a BPMS is just something that IT bought, and has no relevance to business users.

That is why email and documents ALWAYS win as the tool of choice for ad-hoc, unpredictable human work. They are available and ubiquitous. They are under the user’s control. They have a familiar interface and usage paradigm. They allow the job to get done.

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.


5 Responses to “Can BPMS really support "Design by Doing"?”

  1. Scott Says:

    Good post, Jacob – as usual I enjoy reading your blog. 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 your product is a great answer to that need. As you say, 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.

  2. Process for the Enterprise » Blog Archive » It isn’t Black and White, Can or Can’t Says:

    […] 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 […]

  3. Jacob Ukelson Says:

    I think what you described is a great example of iterative or agile design and implementation, which can simulate “design by doing” in some cases, but not what I would call “design by doing”.
    For me, the way to do “design by doing” is to let people do the task in a completely freehand manner for a while using the same tools they always do, to catch both the normal workflow and exceptions, and gain understanding of how the current process realy works. Then take that understanding (without the need to have them switch their tools) and put just enough structure on the process to make it manageable, but not so much as to strangle it.
    So how is this different? – First it doesn’t require people to describe or simulate what they do – you actually see it unfold as they work over time. The second difference is that there is no break between the tools they currently use, and the tools they will use. Finally doing this way makes it robust to change – when a new variation or a change to the process happens – the user won’t break out into a separate tool to get around the system and make the whole process irrelevant. So “design by doing” turns into continuous design.
    Adding email to the BPM mix isn’t on its own enough to make this feasible – but without email in the mix it will never happen.

  4. BPM Quotes of the week « Adam Deane Says:

    […] can BPMS support “Design by Doing”? – Jacob Ukelson The only way “design by doing” can work is if you observe knowledge work […]

  5. Links for May 8 « Thoughts on Collaborative Planning Says:

    […] Jacob Ukelson weighed in with: can a BPMS can really support “Design by Doing”?  Another attempt to make it clear that when you “live in the flow” you don’t make processes happen the same way as those who “design flows for others in advance”.  Email is the tool for those who live in the flow, and his irrefutable conclusions is that use of an Adaptive system will have to be as easy as email. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: