Finding Value in BPM/Workflow Technology

Some recent conversations about the use of workflow and orchestration technologies got me thinking about how to properly look for value when trying to apply these technologies, whether associated with a BPM suite, or with any of the other multitude of tools out there that claim to have orchestration/automation/workflow/work management capabilities.

The one common term that always comes up is process. All of these tools always wind up having some sort of process definition be a requirement. There is one big factor, however, that has a significant impact on where you should look for value, and that’s whether those processes involve manual (i.e. done by a person) activities or not.

Let’s handle the simpler of the two cases, first, which is where there is no manual activities whatsoever. In this case, what we’re really talking about is process automation. If there are no manual steps, then there is no reason that the entire process can’t be fully automated. If we fully automate a process, what are the factors in the value equation? Clearly, if the process isn’t fully automated today, there is a one-time benefit in efficiency. The execution time should move from a variable, potentially unpredictable value, to a consistent, predictable value. This is the case regardless of what tools we use to automate it. Theoretically, I could automate the process with scripts or a programming language and achieve the same value. If you agree with me, then the real value contribution in applying BPM/Workflow technologies lies not in the run-time space, but in the development time space. By either reducing inefficiencies in the communication between analysts and developers through a common language (a process model), or by improving productivity in the development time through the drag-and-drop visual environments of most tools, value can be obtained through time-to-delivery. Beyond this, there is probably not as much value to be obtained through the “management” portion of the BPM suite. Even if the process is subject to frequent change, the area of interest is the time to deliver the change, not optimization of the process itself, since by fully automating the process, we should assume it’s also fully optimized.

If we throw manual tasks into the equation, then we have a different story. While the development time efficiencies certainly still apply, there’s now significant value that can be obtained through process analysis and optimization. I need to know how long those manual tasks take, why Judy accomplishes more tasks than John, what chaos ensues when Fred calls in sick, what the impact of task assignment and escalations are, etc. This information can be obtained by managing the processes, through instrumentation, analytics, and reporting. By doing so, we can get into a cycle of continuous improvement, and strive to optimize the manual efforts that can’t be automated.

Now the reason I bring this up is that there are no shortage of tools that claim to have workflow/business process capabilities. If you have a BPM suite, now you’re faced with the question of which workflow tool to use. What you need to think deeply about is where you’re going to get your value. Products with workflow capabilities may have advantages in development time value because they will come pre-populated with actions/tasks appropriate to the context of that tool, while a generalized BPM platform may not. The flipside, however, is that those same tools with workflow capabilities may only provide a piece of the BPM suite, namely, business process development. If what you really need is business process management, with the ability to monitor, analyze, and optimize the manual parts of your processes, then you may need to sacrifice some development time efficiencies to get the more important run-time value.

Finally, keep in mind that not all work can be defined by a process. As Keith Harrison-Broninski talks about in his book, Human Interactions: The Heart And Soul Of Business Process Management: How People Reallly Work And How They Can Be Helped To Work Better, there will always be ad hoc work. You’ll still need to consider how to best utilize technology to support those ad hoc activities, rather than trying to define a rigid process for something that isn’t.

2 Responses to “Finding Value in BPM/Workflow Technology”

  • peter foley:

    A couple of your assumptions are wrong (at least where I work) a) automated processes are not always optimal – we call that paving the cowpaths b) full automation gives you a recurrent saving on people costs.
    BUT overall you are right that the benefit of BPM is in coordinating manual tasks. We try to incorporate adhoc tasks either by specifiying them as adhoc with an overall process e.g. staff management within a publishing process or as decision points within a process.

  • Todd – Great blog. I posted my thoughts/ comments about the next level of maturity for the BPM and Workflow engine suites at the following location on my blog:

    http://entarch.blogspot.com/2009/01/thoughts-on-finding-value-in.html

    surekha –

Leave a Reply

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.