I’m with Bob Mixon – Business Process Management Does Not Equal Workflow. Go read that post now.

Like him, I hear the terms ‘Workflow’ and ‘BPM’ used interchangably, but he is right – workflow is a technology that can be used to support a business process. It’s not the only technology, though, and it isn’t always appropriate to use. Too often I see workflows with some horrible process in them for dealing a with a variety of edge cases where actually all the customer needs is to record that this is an exception to their normal process, and that it was sent to Joe Bloggs to deal with.

I’m a big fan of allowing human intelligence a role in the process. But I digress…

The point I was leading around to is that you don’t have to use just workflow to support a business process. You can actually achieve quite a lot with views, and you can provide some of the automation with just event handlers. Or, if you’re brave, you can use workflow – but Keep It Simple, Stupid! A lot of the example workflow projects are pretty simple, and short – keeping yours the same seems a safer plan.

Also, I do think keeping workflows short and simple, and having a number of them supporting a business process is generally a good idea.

We did a project just after SharePoint RTM was released where I was supposed to be using workflow. I’d been trying to build this particular workflow since the Beta 1 release, but there were still a lot of issues in the TRM version, such as:

• reading in InfoPath data from repeating sections
• populating data into certain InfoPath form fields
• Delay activities never returning
• not being able to get Modification forms working

…and a whole list of other minor niggles and complaints. The Delay activities thing was the killer for us though – they were essential to the process we were trying to support. In the end, we had to abandon workflow, but instead we used views and event handlers. With the correct views, users could still see what items were ‘late’. Event Receivers let us move items between different states. Certain users could take control of items and change statuses by hand, which mean that it dealt with exceptions well. It wasn’t as elegant as what we’d wanted to do in Workflow (which wasn’t that complicated), but it did work, and it didn’t take long to build. (That was important; the project ended up being 4 months late, which I thought was actually pretty good).

Actually, I built a similar system years ago. Most organisations, when you first go to see them, insist that they know all their business processes, and have them all well documented. Later, it becomes clear that their documentation is wrong, or incomplete (“Oh, yes, actually sometimes we have to do Y instead of X“), or contradictory – but this doesn’t matter as the people in this process are doing something different anyway.

However, we had this one particular customer who sat down with us and said “I don’t think we know our processes at all, although we think we do.” (Smart move). He went on to explain that they had a number of things that had to be done, and that as long as they were completed, nobody would really mind what order they were in. Oh, and sometimes they’d want to add other tasks that needed to be done in that specific case. We suggested a sort of ‘Task List’ for each item, with different templates of tasks for different processes.
He concurred – and it was one of the best solutions I’d written. On time, within budget, no problems.

So I guess the lessons there were:

• Be sure you really know your process
• Only automate things that actually really benefit from it
• Keep automation short, so your process is a bit more loose
• Leave human intelligence in the loop to deal with exceptions. Don’t try to design in every case – exceptions are… well, exceptional!

Bob Mixon’s note about ‘Agility’ is also worth considering when designing your solution – try to design in a way that allows future changes to your process, ‘cos it will change. Short automation and loose coupling really helps that.

Just my thoughts