It isn't Black and White, Can or Can't

  • May 5, 2010
  • Scott

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.

Related Posts
  • September 19, 2017
  • Ariana

What is Digital Transformation from BP3 on Vimeo. CEO, Scott Francis talks how BP3 helps companies operatio...

  • September 17, 2017
  • Scott

Ray Wang wrote a great post on the subject of successful AI projects and the outcomes they seek almost a year ...

  • September 11, 2017
  • Scott

The Harvard Business Review published "Leading Digital Transformation Is Like Urban Planning" - in which they ...

  • Scott,
    Good comments. The kind of iterativeagile method you describe is certainly a way to approximate “design by doing” (and in my opinion is the right way to go about implementing any process technology).

    My point was more about BPMS vendors, than BPM as a methodology. For me “design by doing” isn't just about iterative implementation of the process – it is about having existing tools that let process design emerge from everyday work as it is being done “in-situ”. If true “design by doing” becomes possible then process design isn't a point in time exercise, but a way for real-world processes to change and morph as needed, but still be managed.
    As far as I can tell most BPMS vendors don't see this as their purview – their works starts with the existence of a rigorous model. Good practioners can get around that limtation – but why should they need to?

  • Thx for the response, love the term “in-situ” 🙂

    To the first point – I think we're in agreement, that people have been “designing by doing” without the software/technology support for probably a long time – but, as we turn to look at BPMS vendors and products like ActionBase – I think there's no question that ActionBase is a more pure form of this approach than the typical BPMS (I will refrain from saying “all” because my information isn't perfect 🙂

    I know that the BPMS vendors are talking about supporting this kind of design by doing processing, but the question to me to a software vendor is always: “what does your software do, specfically, that makes this type of work or task easier than it would be otherwise (with other software, or without software)?” …

  • Pingback: Links for May 8 « Thoughts on Collaborative Planning()

  • Leisure is more and more important in the life. Here I know a lot of leisure that is good at me. Adjust our life interest, bring us the enthusiasm of exercise. The post is very well. By the way I know some websites is very well such as XXXXX. Disscount fashionable item is hotting on sale!