You can find me now at: http://ukelson.wordpress.com/

Latest post: 3 Hot Technologies Trends that Don’t Matter to BPM (and one that does)

Hope to see you there.

The deeper I go into any BPMS the more I get the feeling that it really is a specialized IDE (integrated development environment) for creating applications for structured business processes.  I think that more customers are coming to the same conclusion and the understanding that a BPMS is a tool for the IT department, not the business. I’ll make a bold claim here – there are no business users of a BPMS, a BPMS is used to create applications for business users, but the BPMS is used by IT. There I said it. It not that being a tool for IT is a bad thing – it is just that most vendors like to make the claim that their BPMS is really for business users.

Given that, I think that a lot can be learned from other model driven development theory and tools. Since I have been around long enough – I have seen a lot of attempts at creating a generic model driven development environment – none got very far and BPMS is one of the only successes.

In that vein, I just read an article in the latest (June 2011) edition of “Comunications of the ACM” (no not the ACM I usually talk about, but rather the Association for Computing Machinery“. The article is by David Parnas and is titled “The Risks of Stopping Too Soon”. It has a lot of good points – and many of them are relevant for BPMS users (I’ll paraphrase some of the key points) but first I’ll start with a quote he gives from Dijkstra: “everytime someone draws a picture to explain a program, it is a sign that something is not understood” -  I would say them same about BPMN, but that is another post.

1. A diagram (Jacob’s comment – BPMN is no different) is a good way to begin understanding something, but usually stops too soon. The developer (or business analyst) works on the diagram until it means something to them and the group they work with, and then they stop. They stop even if the diagram does not contain all the needed information or does communicate clearly to others. A diagram is always an incomplete model.

2. Premature termination also cause problems in documentation. To be honest I haven’t found to many people discussing the issues of documentation that must be provided with any application created by a BPMS. I guess there is an underlying hope that the resulting application will be so intuitive that it won’t need documentation or that the model is also the documentation (maybe that is why I am seeing more focus on user experience in applications created using a BPMS). One of the most important things documentation can do is explain how the “odd-cases” and exceptions are handled – in my experience BPMS driven applications are especially bad at that.

3.  Testing and inspection. No news here – any computer program has these problems and using a BPMS doesn’t make you immune. It is not that developers don’t do testing – it is that it isn’t clear when to stop. I remember a comment someone made to me when I was a junior programmer “bugs always come in pairs”. Jacob’s comment – It is  not clear whether model driven development (ala a BPMS) makes testing easier or harder – but it certainly doesn’t lower the need for testing.

So there you have it – 3 insights from software design that I think can be applied to any BPMS project.

Both Scott Francis (Leading from Below) and Adam Deane (BPM: Business Politics Management) did a good job of articulating and demonstrating how important politics are in implementing a BPM project. I couldn’t agree more – managing politics is a big part of getting anything done in a business of any size.

There is one point that I think they both missed (or at least didn’t focus on) – managing those politics is just as important as managing the process – and politics exist in every (yes every) non-routine process in business. Unless the process is fully automated (or so routine that it should be fully automated) – people and their judgment are involved. Once that is the case, politics are sure to follow. Those politics are managed in meetings, discussions, conversations, email and documents. Also, they are just as important as the process itself – since they influence the outcome of the process.

So yes, Business Politics Management is the cousin of Business Process Management – a kissing cousin. Most BPMS vendors don’t consider politics something a BPMS should address. In my opinion as long as BPMS tools ignore all the stuff that goes on around the process (i.e. politics), but has influence on the outcome of the process – they have a big hole in functionality.

I read a really great paper by Ethan Mollick titled “People and Process, Suits and Innovators: Individuals and Firm Performance” that takes an empirical look at whether it is the people or processes that matter most for the success of a knowledge work company. In a very real sense I think that is the crux of the ACM vs. BPM debate. If process is what really matters – then BPM takes precedence over ACM, if it is the people than it should be ACM over BPM.

Ethan looks at middle management in computer game industry to try and pick out the impact of the type of work a knowledge worker does (in this case it includes ensuring that the project meets its deadline, gets the right resources and conforms to industry standards. Effective communication with the rest of the company and with outside vendors. Making sure that team is collaborating effectively).

The final conclusion (it won’t surprise ACM advocates) – “it is the individuals who fill  the  role  of  middle  managers  –  the  ―suits –  rather  than  the  creative  innovators  that  best explain variation in firm performance.” 

Too bad he didn’t look at the tools used by those individuals. What I believe he would have found is that they use documents, email and calendar (and maybe a Microsoft Office equivalent). That is the sweet (suite?) spot of ACM – becoming the BPM of knowledge work.

I was reading a Gartner report on “Predicts 2011: PPM Goes From Managing Projects to
Managing Value and Change” (PPM is project and portfolio management – never eactly sure why it is considered separate from BPM, but that is another issue. Maybe we should try to understand why people don’t use BPM for PPM…).

It had a chart about the certainty of requirements – which led me to think about BPM projects and the certainty of requirements. In many BPM engagements, discovering the model of existing process is a large part of the project. Once the model exists, that is when the rest of a BPM suite is brought to bear. So in many ways the BPMN (or other notation) is the equivalent of requirements. That led me to the following chart (the way I believe most BPM suites view the world):

I believe that most real world processes actually look like:

Real world process requirements (especially in today’s modern economy) are lot more uncertain than BPMS vendors would like people to think.

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 was reading Sandy Kemsley’s post on “The Great Case Management Debate” from the 2011 Gartner conference. One of her comments was that Gartner saw process as a continuum from structured to unstructured.

To me there are two reasons to try and classify business processes this way – one is to help people to understand where their process is on the continuum, and use that understanding to choose the right tools for the task. Another is to use that understanding to create an ultimate process tool that can handle the complete continuum. The problem is that in the real world that just like with wave particle duality  – there is a duality of process. Every real world process is a mix of both structured and unstructured activities and tasks – it is just a matter of degree, and you’ll tend to see what you are looking for – which means that for real world processes you won’t be able to categorize them in neat silos within the continuum. Real world end-to-end processes are both structured and unstructured at the same time!

Personally I also think that there is distinction between what works for the structured part of a process, and what works for the unstructured part – both from a technology and methodology perspective.  Not that underlying technologies from structured processes can’t be applied to the unstructured processes – but not in a simplistic way.

At ActionBase we made the conscious decision to focus only on unstructured processes, which led us down a path complementary to, yet very different from the BPMS path taken by structured process vendors. We often get dinged for our lack of traditional support for structured processes – which is understandable if you look at business process from a structured process perspective. For example, we don’t enforce a workflow or do straight through processing.

But if you look at the world from a unstructured business process perspective – then you understand that structured process tools as they currently exist just can’t do unstructured, unpredictable ad-hoc human intensive processes (at least not in a way that anyone would use), but an unstructured tool can be used to execute structured process (though not without losing a benefits that a structured process tool can provide).

At ActionBase we feel we have taken the first step to bridge that duality –not by claiming that people should use our tool for structured process, but rather by enabling structured process tools a way to truly support unstructured processes in a usable way. We do that not by enforcing a structure on unstructured processes, but rather giving users a tool based on email and documents that provides manageability, monitoring and tracking that can use in conjunction with a structured process tool; without enforcing an inappropriate structure on the process and its participants.

One thing that has always bothered me about the BPM and ACM communities is that we are all techies. We claim to provide tools in direct support of the business, but in reality very few business people actually care about the nuances in the ongoing BPM vs. ACM argument – or even understand (or care about) what those tools actually are. My guess is that for most business people our ongoing ACM vs BPM vs ECM conversation is about as interesting as an argument about “how many angels can dance on the head of a pin?”. We need to focus on business issues in terminology that business people can understand and appreciate.

I was reading an article in the Harvard Business Review on “Strategies for Learning from Failure” by Amy C. Edmondson and she made some very interesting points that are very relevant for a BPM vs ACM comparison from a business perspective.  She points out that mistakes (really business process issues – but she doesn’t call them that) fall into three broad categories – preventable, complexity-related, and intelligent. Many of the articles in the same issue use a similar taxonomy to talk about the context of failure. I really liked the article (and the issue in general) because even though most don’t use the process word explicitly – they are really talking about business processes – structured, semi-structured and unstructured. But since they are business oriented, rather than technically oriented - they use very different terminology than us here in ACM\BPM\ECM community.

Using her taxonomy – BPM (as it used today) is focused on optimizing and “preventing failure in predictable operations”. She doesn’t use the words BPM anywhere but it is clear for anyone with any knowledge of BPM that a BPM  system would help enormously in this context. It is interesting that she talks about checklists in this context – which supports the idea that if ACM is easy enough to implement and use – it can provide much of the benefit of a full fledged BPM system, or at least be a good first step towards a full fledged BPM. I think this is what worries BPM vendors most.

In the second category – “unavoidable failures in complex systems”, she states that “a large number of organizational failures are due to the inherent uncertainty of work. A particular combination of needs, people and problems may have never occured before.”  In my mind she is describing exactly the domain that ACM targets – with the goals of ensuring that “small failures” don’t go unnoticed and cause a catastropic failure, and gathering information about the actual execution of the process to facilitate best practice creation and learning. For me this is why knowledge work needs ACM.

The third category “intelligent failure at the frontier’ – this is where people are truly innovating, experimenting and learning new things or “when answers are not known in advance because this exact situation has not been encountered before and perhaps never will be again”.  I don’t think ACM or BPM provide much assistance here.

So more than a technical under pinning for the ACM vs BPM debate which always seems to devolve into a feature\ function discussion by vendors and analysts, I think we need a business underpinning for process – and use that to define the different tools using a business context.

One key differentiator between BPM and ACM is the level of “ad-hoc”-ness related to the processes being served by those tools. A question that almost always comes up with respect to ACM is that whether it is a stopgap measure – a way to manage for processes that haven’t yet been structured, or that aren’t cost effective to structure. It is a sensible question for someone that spends their time looking at existing processes and use a BPM methodology create some order from what seems to  (at least at first blush) unstructured chaos.

By creating a formal description of an existing process (perhaps using BPMN, perhaps not) a structure is created for the existing process, formalizing the tasks and flow related to the work done in service of that process.  Once that is done, the process can be analyzed, optimized and codified.  All of that makes a lot of sense for large processes that have been around for a while, and that are well understood. I would add also for processes that lend themselves to being structured, but that isn’t the point here – so no reason to get into that argument.

Once you have done all that, most organizations hope that they are done, and now can just use their newly minted processes for ever. Sort of like the waterfall method for creating software. Everyone in the industry knows that isn’t true – that processes are living, changing entities. More like the iterative (or agile) methods for creating software. If you look at the “agile manifesto” for software:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

the principles are just as applicable to process management as they are to software development. These principles came to be after decades of software development, and people realized that the old process of building software wasn’t keeping up with customer, needs and there needed to be a change. Agile methodologies haven’t been mainstream for that long – but I think that most everyone in the industry believes that they are the wave of the future.

So how does BPM stand up relative to those principles? Social BPM is a way address the issue of customer collaboration (though in many cases the collaboration is around the model – in other words the contract). The growing area of process analytics is the industries answer to “responding to change”.

 I think that traditional BPM does less well on the first two principles – it is pretty clear that comprehensive documentation (the process model) is still a basic requirement. Probably because of the mindset – process and tools take precedence over individuals and interaction. So not so good on those fronts.

 Though many position ACM as a way to respond to change, for me it is a process oriented way to focus on individuals, interactions and working software (which make it more amenable to change).

It is interesting that the “Agile Manefesto” was created as a response to the existing “best practice” – for software development, just as ACM emerged from the process community. The “Agile Manifesto” was created by developers, not customers or analysts. I think it is time for the process community to create a “Process Manifesto”.