I think the BPM (or Business Process management) has been around long enough, and used widely enough  to claim that it has made a real difference in the managing of well defined, predictable, routine processes. Now that that the issues with routine process management are pretty well understood, the next big thing in BPM is the management of unstructured, unpredictable processes. The problem is that the approach to those types of processes is very different than the approach needed for structured processes. Knowledge workers, and the work they do is not a subset (or extension) of the type of structured processes handled by BPM – but rather something quite different. Keith Swenson took a stab at using a different name “Adaptive Case Management” to signify that these processes are different – but I am not sure that was radical enough to get people to switch the way they think about unstructured business processes.

I suggest that we should have a separate branch of BPM that is Business Politics Management – it is the cousin of regular BPM, but for knowledge worker tasks. These tasks are very heavily dependent on collaboration, meetings, discussions, negotiation – and yes politics (in the sense that all interactions between humans involves politics). I think using the word “politics” would cause enough of an uproar that we could actually start understanding how the two BPMs actually are different.

So how are they different? Even if you look at the adoption process of “Business Process Management” – almost every consultant would explain that you really need to get all the parties involved (especially management) on the same page, and you need to select the right process. Now if traditional BPM was really good at managing unstructured processes – it would make sense for the first BPM process to be implemented would be the process of getting management on board with BPM and selecting the process (I know that is sort of a recursive statement, but still true).

But realistically that is a job more suited to Business Politics Management, since it requires the kind of knowledge work that involves collaboration, meetings, discussion and negotiations – and yes, politics.

So no matter what your business process – BPM is for you (just make sure you chose the right BPM).

One of theme I constantly return to is that once you assume that you are building a solution for users, there are lot of issues you need to consider – even for workflow. Most BPM tools completely ignore these aspects – and many BPMS tools require that you get into relatively low level programming to do this kind of work.

That is why I am always happy to find simple best practices about usability that can easily be applied to applications built using a BPMS (or of course ACM). Jacob Nielsen wrote a good post on “Workflow Expectations: Presenting Steps at the Right Time” – it is about how to plan for user expectations when creating a workflow for users – in this case  it mostly about steps for a single user, but the thought process is applicable for workflow between users too.

I get asked quite often about Social BPM, probably because of all the hype around it at the moment. I couldn’t help but laugh when I saw Keith’s post  “Anti-Social BPM”, and I decided to chime in with my two cents.

Work is (and has always been) a social activity – you really can’t do any interesting end-to-end business process without people being involved. Even if you are doing straight through processing (the minority of actual business processes) – there are always some humans at the endpoints – and usually quite a few humans in the middle. So why is Social Business Process Management the new buzzword du’jour? Mainly because most BPM technologies (or BPMS’s) played down the roles of the humans involved and focused on the automatable part of the process. At best the humans were part of the process as secondary agents (I know that is a bit harsh, but for the most part true). BPMS technology ignored (and continues to ignore) the basic constructs of any real end-to-end business process – conversation and negotiation (Max wrote a post on this a while back – Process is Conversation, or ‘Did you hear the PIN drop?’ ). So if every business process is social – why are we only hearing now about social BPM and what does it mean?

Social BPM seems to have taken on two separate meanings (Scott has posted on this too – Process for the People ) – the first as a way to enable (and encourage) collaboration during the process of building the model of a process . BPMS vendors have started to add social technologies as part of their platform for the modeling community. This is useful, but not interesting. The reason I claim that it is not interesting – is that the process modeling process effects very few people in the organization, and it seems to be missing the point – why not enable the unstructured social aspects for every process? What makes process modeling unique?

The second meaning of social BPM makes more sense to me – acknowledging that most business processes are people processes, and enabling the management of those unstructured, unpredictable people processes. I don’t think anyone would be surprised that this is how we see the world at ActionBase – but would be surprised at how hard it is for mainstream BPMS vendors to accept this view. In discussing this with one large BPMS vendor they told me that it makes sense, but it really isn’t something they can do since it requires selling to the business, instead of IT (something that they don’t how to do).  Another reaction I get from “standard” BPMS vendors is a blank stare – since the notion of an ad-hoc, unstructured process just doesn’t fit with their notion of a business process.

So social business process (management) isn’t new – it is how business really gets done. Social BPM is new – only because BPM has become synonymous with BPMS technology and lost its true meaning of “business process management”.

I am currently reading Thomas Davenport’s book “Thinking for a Living”. Though I had scanned sections of it before, this is the first time I am giving a thorough end-to-end reading. As I read it, I thought I would pick out the parts relevant for Human Process Management.  In chapter two he gives a classification of different types of knowledge intensive processes which I think does a good job of segmenting the standard tools available today for knowledge workers.

• Transaction Model – Here companies use either bespoke applications, with the rules embedded in the app (e.g. CRM), or use BPM to build the app
• Integration Model – that is where BPM is most valuable, and BPM focus today.
• Expert Model - Browsers, Document repositories and  personal productivity applications are the tools available.
• Collaboration Model – This is what Human Process Management addresses. These are the unstructured, ad-hoc processes that people do everyday in email and documents, where  the overall work product is dependent on groups of knowledge workers collaborating. The fact that email reigns king for knowledge worker collaboration and coordination is show in a different chart, with knowledge workers spending about 20% of their day in email (even though the data is about 5 years old, itstill holds).