here are so many people out there who call themselves business process
experts that you have to wonder if discovering, analyzing and designing end-to-end business processes (workflow) is akin to riding a bike; just hop on, scuff your knees a few times and voila!…you’re a business process expert. The Internet certainly provides few barriers to self-promotion in this area (I heard it on the Internet so it must be true). And the cornucopia of business process management (aka process automation) software and platforms don’t do a lot to clear things up. Shocking, I know!
I thought it would be valuable to talk about a basic understanding of workflow so we can sift through all of the noise out there and focus on what is really important. I gleefully steal ideas from others and put them together in ways that suit me so if any of this sounds familiar, now you know why. It’s nothing new; it’s just re-packaged.
There are many misconceptions as to what a business process is. It wouldn’t be worth pointing out if they didn’t cause great harm. Here are a few things to watch out for and avoid:
- Procedures – “how” to perform an activity. This is a method, not a process
- Process Areas – A group of related business processes. For instance, Customer Relationship Management (CRM) is not a process, it’s a group of related processes
- Process Fragments – the flow of work through a functional area of an organization
- Sub Processes – processes that are contained within an end-to-end business process
Attempting to improve any of these things by themselves can actually make things worse. When you identify the wrong collection of activities as a business process you can either make your scope too small, or too large. It’s always important to understand what is in scope, and what is out of scope; misidentification at the front end will ultimately lead to scope creep as anticipated business outcomes are not realized.
There is also the notion described by Eliyahu Goldratt in The Goal of “local optimization leading to global suboptimization.” This is something that happens when a sub-process or an activity is misidentified as a business process. There are many good examples out there if you like to read books; but I will try to remember to share some in future posts for the short attention span theater crowd.
Even though we are often charged with improving a smaller scope than an entire business process, it’s very important to identify the true business process in order to better coordinate inputs and outputs and hopefully avoid the impact of local optimization. Good luck! I struggle with it every day.
Alec Sharp, in his book Workflow Modeling: Tools for Process Improvement and Application Development, lays out a very clear and compelling set of criteria for identifying business processes.
It Involves Work
Many people will focus on the work, or the activities that go into generating a result. Certainly, a process involves work performed by a collection of actors (people, machines or both). However, the work is far less important than the result, as the desired result will be fairly static, while the work performed to achieve it can change over time. This is beginning to sound a lot like outcome-driven innovation talk…
Named in Verb-Noun Form
A process will always be named in verb-noun format, and possibly with a contextual qualifier. For instance Assign Consultant, or Assign Consultant to Process Project. These are almost always defined in the singular.
The name must also indicate the result of the process. So, if you flip the name around to noun is verbed you would get Consultant is Assigned. Here’s a table of examples used by Sharp that help eliminate confusion, and apply specifically to the realm I work in much of the time, CRM.
| Suggested Process | What it Really Is | Why Is/Is Not a Process |
| Customer Relationship Management | Process Area | Doesn’t deliver a single, specific result; a set of related business processes meeting an overall objective |
| Acquire New Customer | Business Process | Delivers a single, specific result and meets all other criteria. An end-to-end business process. |
| Assess Prospect Financial Status or Set Up Customer | Subprocess | Too small – both deliver specific results, but are intermediate results in an end-to-end business process |
| Calculate Customer Credit Limit or Create Customer Account | Activity, step, task… | Much too small – a part of a subprocess. Possibly described in a procedure or use case |
| “The Inside Sales Process” | Function | Doesn’t deliver a single, specific result; an organizational unit that participates in multiple business processes |
| “Our Oracle CRM Process” | System | Doesn’t deliver a single, specific result; a system that supports multiple business processes |
| “Our e-business process” | Technology | Doesn’t deliver a single, specific result; a technology employed by multiple business processes |
Delivers a Specific, Essential Result
Since the process is named in a way to defines the result of the process from the customer’s perspective, the result of the process must meet these criteria:
- The result must be discrete and identifiable – Individual instances can be identified clearly, such as Mike B was assigned as the consultant for ABC’s process project.
- The result must be countable – You are able to count how many consultants were assigned each hour, day, week, month, etc.
- The result is essential – The result is fundamentally essential to the operation of the enterprise and not simply a consequence of your current process implementation. For instance, if the process were Notify Consultant of Assignment, we would have to challenge a process that was named Email Project Assignment to Consultant. A business process name focuses on the what, not the who or the how.
Keep in mind that there could be more than one customer for a process (internal and external) but they still get a discrete, countable and essential result; such as customer gets a product, company gets a payment. But at the end of the day, a process must deliver what these customers want, not what you want to do.
Produces Results, Not Objectives
A result is the output of a single execution of the process, such as Consultant is Assigned. An objective is a performance target of the process over time. For instance, you might establish an objective or goal that minimizes re-assignments due to skill mismatches to 5% a year. That is not a discrete result, and therefore not a business process.
Name with Action Verbs, Not Mushy Verbs
Customer Relationship Management is not a business process (sorry all you CRM consultants). Just try flipping the name and you will get Customer Relationship is Managed. Let’s talk about how we would count that result. I’m happy to take suggestions! In a nutshell, this means nothing. What we are actually looking at is a process area.
Mushy works like manage, administer, monitor, handle do not support the discrete action verb requirements of a business process. For example, try counting how many customers were handled.
Initiated by a Specific Event
Now that we know that a process must have discrete results on one end, we need to know how a process is triggered on the other end. When describing a process, it’s critical that we identify the triggering event that initiates it. These fall into 3 categories:
- Action Event – These occur when someone decides to do something. Your customers do this to you all the time! How’s this for an action event… it’s time to re-evaluate our workflow!
- Temporal Event – These occur at predetermined dates or times. This might be a recurring billing to a customer, or getting your employees paid every two weeks.
- Condition or Rule Event – These occur when a condition is met; such as inventory dropping below a certain level
Steps Should Also be Named in verb-noun Format
Finally, in the middle we do things that take a token, item or information through a series of transformative and value-adding steps. Each of these steps is triggered by the preceding step and has a discrete and identifiable result. Therefore, you can use the same tests for a business process name when evaluating how to identify a step within the process.
On a final note, processes aren’t always linear. At times, there could be collaborative steps where actors come together to make decision or transform an item within the workflow and there can also be parallel steps. At other times, there will be 1:Many relationship from one step to another; which tend to spawn subprocesses (and M:1 relationships leading back to the core process). An example might be a process which is triggered by an action event (customer orders product) but at some point down the line items queue while waiting for a batching process triggered by a temporal event (e.g. many items are delivered in a single truck at 11am each day after waiting on the loading dock overnight). So, there is much more to discuss, but we have a good start now by understanding what a process is, and what it is not.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
