Business Process Management

You are currently browsing the archive for the Business Process Management category.

BPM over promised and under delivered

2011/07/01 in Business Process Management by peg | 6 comments

One Saturday night the other week I was typing away on a book that I’m working on (probably called The new instability. How cloud computing, globalisation and social media enable to you to create an unfair advantage) and I let out what was probably a quite involved tweet without any context to explain it.

BPM has under delivered as it's rooted in Taylorism – *there is one true way to do the work* – but today we need to support multiple ways.
2011/04/16 7:35 pm via EchofonReplyRetweetFavorite

Recently I’ve been thinking about the shift we’re seeing in the business environment. The world seems pretty unstable at the moment. Most business folk assume that this is simply a transition between two stable states, similar to what we’ve seen in the past. This time, however, business seems to be unable to settle into a new groove. The idea behind the book is that the instability we’re seeing is now the normal state of play

Since Frederick Taylor’s time we’ve considered business – our businesses – vast machines to be improved. Define the perfect set of tasks and then fit the men to the task. Taylor timed workers, measuring their efforts to determine the optimal (in his opinion) amount of work he could expect from a worker in a single day. The idea is that by driving our workers to follow optimal business processes we can ensure that we minimise costs while improving quality. LEAN and Six Sigma are the most visible of Taylor’s grandchildren, representing generations of effort to incrementally chip away at the inefficiencies and problems we kept finding in our organisations.

This is the same mentality – incremental and internally focused, intent on optimising each and every task in our organisations – that we’ve used to apply technology to business. Departmental applications were first deployed to automate small repudiative tasks, such as tracking stock levels or calculating payrolls. Then we looked at the interactions between these tasks, giving birth to enterprise software in the process. Business Process Management (BPM) is the pinnacle of our efforts, pulling in everything from our customers through to suppliers to create the optimal straight through processes for our organisation to rely on.

Some vendors have taken this approach to its logical extreme, imagining (and trying to get us to buy) a single technology platform which will allow us to programme our entire business: business operating platforms[1]. They’re aligning elements in the BPM technology stack with the major components found in most computers under the (mistaken) assumption that this will enable them to create a platform for the entire business. Business as programmable machine writ large.

The problem, as I’ve pointed out before[2], is that:

Programming is the automation of the known. Business processes, however, are the management and anticipation of the unknown.

Business is not a computer, with memory, CPUs and disks, and the hope of creating an Excel with which we can play what if with the entire business is simply tilting at windmills.

The focus of business is, and always has been, problems and the people who solve them. Technology is simply a tool we’ve used to amplify these people, starting with the invention of writing through to modern SaaS applications and BPM suites. While technology has had a previously unimaginable impact on business, it can’t (yet) replace the people who solve the problems which create all the value. People collaborate, negotiate, and smash together ideas to find new solutions to old problems. Computers simply replicate what they are told to do.

We’ve reached Taylorism’s use-by date. Define the perfect task and fit the man to the task no longer works. The pace of business has accelerated to the point that the environment we operate in has become perpetually unstable, and this is pushing us to become externally focused, rather than internally focused. We’re stopped worrying about collecting resources to focus on our reactions to problems and opportunities as they present themselves. Computing (calculating payrolls, invoices, or gunnary tables) is less important as it can be obtained on demand, and we’re more concerned with the connections between ourselves and our clients, partners, suppliers and even our competitors. And we’re shifted our focus from collecting ever more data as it becomes increasingly important to ask the questions which enable us to make the right decisions and drive our business forward.

Success today in today’s unstable environment means matching the tactic – process – to the goal we’re trying to achieve and our current environment, with different tactics being using in different circumstances. Rather than support one true way, we need to support multiple ways.

There has been some half steps in the right direction, with the emergence of Adaptive Case Management (ACM)[3] being the most obvious one. A typical case study for ACM might be something like resolving SWIFT payment exceptions. When the ACM process is triggered a knowledge worker creates a case and starts building a context by pulling data in and triggering small workflows or business processes to seek out data and resolve problems. At some stage the context will be complete, the exception resolved, and the final action is triggered. Contrast this with the standard BPM case study, which is typically a compliance story. (It’s no surprise that regulations such as SOX drove a lot of business processes work.) BPM is a task dependency tool, making it very good at specifying the steps in the required process, but unable to cope with exceptions.

So what do we replace the Talyorism’s catch cry with? The following seems to suit, rooted as it is in the challenge of winning in a rapidly changing environment.

Identify the goal and then assemble the perfect team to achieve the goal.

Note: This was also posted on noprocess.org.


References


1. Ismael Ghalimi (2009), Introducing the Business Operating Platform, IT|Redux↑
2. Business is not a programming challenge @ PEG↑
3. Keith D. Swenson (2010), Mastering the Unpredictable, Meghan-Kiffer Press.↑

Tags: , , ,

Michelangelo’s approach to workflow discovery

2010/07/29 in Business Process Management by peg | No comments

Take any existing workflow — any people driven business process — and I expect that most of the tasks within it could best be described as cruft.

cruft: /kruhft/
[very common; back-formation from crufty]

  1. n. An unpleasant substance. The dust that gathers under your bed is cruft; the TMRC Dictionary correctly noted that attacking it with a broom only produces more.
  2. n. The results of shoddy construction.
  3. vt. [from hand cruft, pun on ‘hand craft’] To write assembler code for something normally (and better) done by a compiler (see hand-hacking).
  4. n. Excess; superfluous junk; used esp. of redundant or superseded code.
  5. [University of Wisconsin] n. Cruft is to hackers as gaggle is to geese; that is, at UW one properly says “a cruft of hackers”.

The Jargon File, v4.4.7

Capturing and improving a workflow (optimising it even) is a processes of removing cruft to identify what really needs to be there. This is remarkably like Michalangelo[1]‘s approach to carving David[2]. When asked how he created such a beautiful sculpture, everything just as it should be, Michalangeo responded (and I’m paraphrasing):

Michelangelo's David

Michelangelo's David

David was always there in the limestone; I just carved away the bits that weren’t David.

Cruft is the result of the people — the knowledge workers engaged in the process — dealing with the limitations of last decade’s technology. Cruft is the work-arounds and compensating actions for a fragmented and conflicting IT environment, an environment which gets in the road more often than it supports the knowledge workers. Or cruft might be the detritus of quality control and risk management measures put in place some time ago (decades in many instances) to prevented an expensive mistake that is no longer possible.

Most approaches to workflow automation are based on some sort of process improvement methodology, such as LEAN or Six Sigma. These methods work: I’ve often heard is stated that pointing Six Sigma at a process results in a 30% saving, each and every time. They do this by aggressively removing variation in the process — slicing away unnecessary decisions, as each decisions is an opportunity for a mistake. These decisions might represent duplicated decisions, redundant process steps, or unnecessarily complicated handoffs.

There’s a couple of problems with this though, when dealing with workflow. Looking for what’s redundant doesn’t create an explicit link between business objectives and the steps in the workflow, explicitly justifying each step’s existence, making it hard to ensure that we caught all the cruft. And the aggressive removal of variation can strip a process’s value along with its cost.

Much of the cruft in a workflow process is there for historical reasons. These reasons can range from something bad happened a long time in the past through to we don’t know why, but if we don’t do that then the whole thing falls over. A good facilitator will challenge seemingly obsolete steps, identifying those steps who have served their purpose and should be removed. However, it’s not possible to justify every step without quickly wearing down subject matter experts. Some obsolete steps will always leak through, no matter how many top-down and bottom-up iterations we do.

We can also find that we reach the end of the processes improvement journey only to find that much of the process’s value — the exceptions and variation that make the process valuable — has been cut out to make the process more efficient or easier to implement. In the quest for more science in our processes, we’ve eliminated the art that we relied on.

If business process management isn’t a programming challenge[3], then this holds even truer for human driven workflow.

What we need is a way to chip away the cruft and establish a clear line of traceability between the goals of each stakeholder involved in the process, and each step and decision in the workflow. And we need to do this in a way that allows us to balance art and science.

I’m pretty sure that Michalangeo had a good idea of what he wanted to create when he started belting on the chisel. He was looking for something in the rock, the natural seems and faults, that would let him find David. He kept the things that supported his grand plan, while chipping away those that didn’t.

For a workflow processes, these are the rules, tasks and points of variation that knowledge workers use to navigate their way through the day. Business rules and tasks are the basic stuff of workflow: decisions, data transformation and hand-offs between stakeholders. Points of variation let us identify those places in a workflow where we want to allow variation — alternate ways of achieving the one goal — as a way of balancing art and science.

Rather than focus on programming the steps of the process, worrying if we should send an email or a fax, we need to make this (often) tacit knowledge explicit. Working top-down, from the goals of the business owners, and bottom-up, from the hand-offs and touch-points with other stakeholders, we can chip away at the rock. Each rule, task or point of variation we find is measured against our goals to see if we should chip it away, or leave it to become part of the sculpture.

That which we need stays, that which is unnecessary is chipped away.


References


1. Michelangelo Buonarroti↑
2. Michelangelo’s David↑
3. A business process is not a programming challenge @ PEG↑

Tags: , , , , ,

Business is like a train…

2010/06/01 in Business Intelligence, Business Process Management, IT Strategy by peg | No comments

The following analogy popped up the other day in an email discussion with a friend.

Running a business is a bit like being the Fat Controller, running his vast train network. We spend our time trying to get the trains to run on time with the all too often distraction of digging the Troublesome Trucks out of trouble.

Improvement often means upgrading the tracks to create smoother, straighter lines. After years of doing this, any improvement to the tracks can only provide a minor, incremental benefit.

What we really need is a new signalling system. We need to better utilise the tracks we already have, and this means making better decisions about which trains to run where, and better coordination between the trains. Our tracks are fine (as long as we keep up the scheduled maintenance), but we do need to better manage transit across and between them.

Swap processes for tracks, and I think that this paints quite a nice visual picture.

Years of processes improvement (via LEAN, Six Sigma and, more recently, BPM) had straightened and smoothed our processes to the point that any additional investment has hit the law of diminishing returns. Rather than continue to try and improve the processes on my own, I’d outsource process maintenance to a collection of SaaS and BPO providers.

The greater scale of these providers allows them to invest in improvements which I don’t have the time or money for. Handing over responsibility also creates the time and space for me to focus on improving the decisions on which process to run where, and when: my signalling system.

This is especially important in a world where it is becoming rare to even own the processes these days.

We forget just how important a good signalling system is. Get it right and you get the German or Japanese train networks. Get it wrong and you rapidly descend into the second or third world, regardless of the quality of your tracks.

Tags: , , , , ,

BPM is not a programming challenge

2010/05/31 in Business Process Management, Mailing List by peg | No comments

Get a few beers into a group of developers these days and it’s not uncommon for the complaints to start flowing about BPM (Business Process Management). BPM, they usually conclude, is more pain than it’s worth. I don’t think that BPM is a bad technology, per se, but it does appear to be the wrong tool for the job. The root of the problem is that BPM is a handy tool for programming distributed systems, but the challenge of creating distributed systems is orthogonal to business process execution and management. We’re using a screw driver to belt in a nail. It’s more productive to think business process execution and management as a (realtime) planning problem.

Programming is the automation of the known. Take as stable, repeatable process and automate it; bake the process into silicone to make it go fast. This is the same tactic that I was using back in my image processing days (and that was a long time ago). We’d develop the algorithms in C, experiment and tweak until they were right, and once they were stable we’d burn them into an ASIC (Application-Specific Integrated Circuit) to provide a speed boost. The ASICs were a lot faster than the C version: more than an order of magnitude faster.

Programmers, and IT folk in general, have a habit of treating the problems we confront as programming challenges. This has been outstandingly successful to date; just try and find a home appliance or service that doesn’t have a programme buried in it somewhere. (It’s not an unmitigated success though, such as our tumble drier is driving us nuts if its overly frequent software errors.) It’s not surprising that we chose to treat business processes automation and management as a programming problem once it appeared on our radar.

Don’t get me wrong: BPM is a solid technology. A friend of mine once showed my how he’d used his BPM stack to test its BPEL engine. As side from being a nice example of eating your own dog food, it was a great example of using BPEL as a distributed programming tool to solve a small but complex problem.

So why do we see so many developers complaining about BPM? It’s not the technology itself: the technology works. The issue is that we’re using it to solve problems that it’s not suited for. The most obvious evidence of this is the current poor state of BPM support for business exception management. We’ve deployed a lot of technology to support exception management in business processes without really solving the problem.

Managing business exceptions is driving the developers nuts. I know of one example where managing a couple of not infrequent business exceptions was the major technical problem in a very significant project (well into eight figures). The problem is that business exceptions are not from the same family of beasts as programming exceptions. Programming exceptions are exceptional. Business exceptions are just a (slightly) different way to achieve the same goal. All our compensating actions and exception stacks just get in the way of solving the problem.

On PowerPoint, anything can look achievable. The BPMN diagram we shared with the business was extremely elegant: nice sharp angles and coloured bubbles. Everyone agreed that it was a good representation of what the business does. The devil is in the details though. The development team quickly becomes frustrated as they have to deal with the realities of implementing a dynamic and exception rich business processes. Exceptions pile up on top of exceptions, and soon that BPMN diagram covers a wall, littered as it is with branch and join operations. It’s not a complex process, but we’ve made it incredibly complicated.

Edward Tufte's take on explaining complex concepts with PowerPoint

A military parade explained, a la PowerPoint

We can’t program our way out of this box, trying to pile on more features and patches. We can rip the complications out – simplifying the process to the point that it becomes tractable with our programming tools (which is what happened in my example above). But this removes all the variation which which makes the processes so valuable. (This, of course, the dirty secret of LEAN et al: you’re trading flexibility for cost saving, making your processes very efficient but also very fragile.)

Or we can try solving the problem a different way.

Don’t treat the automation of a business processes as a programming task (and I by this I mean the capture of imperative instructions for a computer to execute, no matter how unstructured or parallel). Programming is the automation of the known. Business processes, however, are the management and anticipation of the unknown. Modelling business processes should be seen as a (realtime) planning problem.

Which comes back to one of my common themes: push vs pull models, or the importance of what over how. Or, as a friend of mine with a better turn of phrase puts it, we need to stop trying to invent new technologies and work out how to use what we already have more effectively. Rather than trying to invent new technologies to solve problems that are already well understood elsewhere, pushing the technology into the problem, a more pragmatic approach is to leverage that existing understanding and then pull in existing technologies as appropriate.

Planning and executing in a rapidly changing environment is a well understood problem. Just ask anyone who’s been involved with the military. If we view the management of a business processes as a realtime planning problem, then what were business exceptions are reduced to simply alternate routes to the same goal, rather than a problem which requires a compensating action.

Battle of Gaugamela (Arbela) (331BC)

Take that hill!

One key principle is to establish a clear goal – Take that hill!, or Find that lost shipment! – articulate the tactics, the courses of action we might use to achieve that goal, and then defer decisions on which course of action to take until the decision needs to be made. If we commit to a course of action too early, locking in a decision during design time, then it’s likely that we’ll be forced to manage the exception when we realise that we picked the wrong course of action. It’s better to wait until the moment when all relevant information and options are available to us, and then take decisive action.

From a modelling point of view, we need to establish where are the key events at which we need to make decisions in line with a larger strategy. The decisions at each of these events needs to weigh the available courses of action and select the most appropriate, much like using a set of business rules to identify applicable options. The course of action selected, a scenario or business process fragment, will be semi independent from the other in the applicable set, as it addresses a different business context. Nor can the scenario we pick cannot be predetermined, as it depends on the business context. Short and sharp, each scenario will be simple, general and flexible, enabling us to configure it for the specific circumstances at hand, as we can’t anticipate all possible scenarios. And finally, we need to ensure that the scenarios we provide cover the situations we can anticipate, including the provision of a manual escape hatch.

Goals, rules and process: in that order. Integrated rather than as standalone engines. Pull pull these established technologies into a single platform and we might just be closer to a BPM solution inline with what we really need. (And we know there is nothing new under the sun, as this essentially a build on Jim Sinurs rules-and-process argument, and borrows a lot from STRIPS, PRS, dMARS and even the work I did at Agentis.)

As I mentioned at the start of this missive, BPM as a product category makes sense and the current implementations are capable distributed programming tools. The problem is that business process management is not a distributed programming challenge. Business exceptions are not exceptional. I say steal a page from the military strategy book – they, after all, have been successfully working on this problem for some time – and build our solutions around ideas the military use to succeed in a rapidly changing environment. Goals, rules and processes. The trick is to be pragmatic, rather than dogmatic in our implementation, and focus on solving the problem rather then trying to create a new technology.

Tags: , , , , , , , , , , , , , , ,

© 2010-2012 Peter Evans-Greenwood All Rights Reserved