I was honored to give the keynote on the second day of the BPM2014 conference, and promised to answer questions, so here are the slides and summary.
Slides are at slideshare:
(Slideshare no longer has the ability to put an audio together with the slides, so I apologize that the slides alone probably don’t make a lot of sense. I hope to get invited to present the same talk at another event where they video.)
Nice of you to notice! The talk went on schedule and as far as I know there was nothing that I forgot to say.
It is a little of both. There is a tendency for managers of all types, especially less experienced managers, to want to over-constrain the processes. At the same time, programmers tend to implement restrictions very literally and without any wiggle room. I don’t think we can let either one off the hook.
This was one of my key points: if our goal is to make ‘business’ successful, maybe there is more to it than just increasing raw efficiency in terms of reducing expenses. Maybe an excellent business needs to keep their knowledge workers experienced, and possibly our IT systems should be helping to exercise the knowledge workers.
This tweet got the most favorites and retweets. I had not realized that this was not clear before, so let me state it here. I included in the presentation the definition of BPM that was gathered earlier this year. I mentioned that this was not exactly the definition that I had formerly thought, but the discussion included a broad spectrum of BPM experts, and so I am willing to go along with this definition.
Under this new definition, ANYTHING and EVERYTHING that makes your business processes better is included. Some of you thought this all the time. Previously, I had subscribed to a different (and wrong) definition of BPM, which was a bit more restrictive, and that is why in the past I have stressed the distinction between BPM and ACM. However, this new, agreed upon definition allows BPM method to have and to not have models, to have and not have execution, etc. So BPM clearly includes ACM because it also is a way of supporting business and processes. This is the definition now that so many have pledged to support, and I can support it as well.
I am still teaching myself to say “Workflow-style BPM” or “traditional-BPM” instead of simply ‘BPM’, and I have not completely mastered that change.
There is no doubt: knowledge work is more satisfying to do. I spoke to some attendees afterwards, who felt I was being ‘unfair’ to the routine workers: they are doing their jobs too, why pick on them just because their job is routine? I am not sure how to respond to that. I think most people find routine work dull and boring. Sure, it is a job, but most people would like to be doing more interesting things, and that generally is knowledge work that depends upon expertise you acquire. In general, automatic routine work will allow a typical business to employ more knowledge workers, particularly if the competitors are doing so. It is somewhat unlikely to think that all routine worker individuals will switch and become knowledge workers, but some will, and for the most part the transition will occur by hiring exclusively knowledge workers, and losing routine workers by attrition.