I’ve been talking about writing my book since the beginning of this year, but I’m not sure if I’ve ever really discussed what it’s about in any detail.
To start at the beginning, the title is Successful Business Process Management: What You Need to Know to Get Results. In the book I cover processes, process systems, and a bunch of other useful stuff. Here, I’ll start with the process, and I’ll start at the very beginning: what is a process, and why does it matter? (I’m going to write this on a very basic level, for people who haven’t thought much about standard processes before; even if you have, you might find this post and following ones useful
A process is a series of tasks to get from the situation you’re in to the situation you want to be in. At the beginning, you have a series of inputs, which can be things, tools, raw materials, information. (It is possible to distinguish between inputs that get changed, like raw materials, and resources that don’t, like tools. I thought hard about whether to make this distinction in the book, and finally decided it wasn’t worth bothering – and anyway, where would something like expertise fit? They’re all stuff that you have to have before you can execute a process, and that’s the important thing.) At the end of a process you have outputs, which again can be concrete or not. An output could be a manufactured product, a certification you’ve been approved for, updated information, stuff that’s been moved from here to there.
Filling up your car is a process; the inputs are a car that needs more fuel than it has, a working gas pump, gasoline, and money. The primary output is a car with a full tank, from the driver’s point of view. If you keep careful records, an updated ledger might be another output. (That’s assuming the process is written from the customer’s point of view. From the gas station owner’s point of view, the primary output is profit received.)
For most kinds of work it’s useful to standardize at least some of your processes. In any kind of work you do, from washing dishes to brain surgery, you’ve probably evolved a consistant way of working that seems most efficient to you. Some tasks have one best way to do them – for example, athletes warm up in a standard way before competition because they perform better if they do. In other cases, there might be lots of equally valid ways to work, but it’s useful to have multiple people, who do the same task, do it in the same way. That way everyone has a shared vocabulary to discuss the work. When multiple people perform the same task, or when there’s a need for understanding between different people or groups, as when someone else provides the inputs you need for your tasks, or is a customer for your outputs, then it’s necessary to get the process written down.
Having a process standardized and documented can help bring new employees up to speed quickly; provide the capacity for someone else to do a task when the usual person is away; and provide interface agreements to make sure that what you’re delivering meets your customers’ needs (in a business, this is often an internal customer like the group down the hall). Standardization also allows a process to be measured in a standard way so that you can see where process improvement is needed, or where some employees need more training to improve their productivity. Without these metrics, you might be able to tell when you need to improve the process (screaming customers are one clue!) but you won’t be able to tell how much you’ve improved it, and it’s a lot harder to figure out what improvements you need to make; you’d almost have to go and document it, at whatever level, just so you can say, “There! We’re wasting a lot of time in that step!”
Not all processes need to be documented to the same level of detail: when you’re building an airplane, you need hundreds of documented processes, all linked in an intricate hierarchy. On the other hand, a pilot doing a preflight check for a 4-seater plane uses only a checklist to make sure she doesn’t miss anything.
For anything a bit more complicated, a process document is built around a process map, which is basically a flowchart showing the order of the process steps, and which ones can be done in parallel. (When I was in college, they told me flowcharts were obsolete. And here I am writing about them, though not in context of computer programming, a quarter century later.) If you’re documenting a process, make very sure you get this right, because it will often be the one thing people read.
Speaking of getting a process right, the way to do that is by consulting with all of the people involved (or at least each of the various roles – users, management, process customers – when there are too many people involved to talk to all of them). That will also help avoid resistance, because many times people who don’t want to follow a standard process feel that way because it’s wrong, and other times when they say it’s wrong, they really just feel they haven’t been heard.
But though I can (and did) write for pages about how to document processes properly, that’s only one third of the work, one leg of a stool. The other two legs to support a process and make it a real living thing rather than an unread pile of paper are to launch it properly and manage its operations after the launch.
To launch a process, you need a plan covering three things. 1.) What infrastructure is required? This can include facilities, hardware or software tools, people, etc. 2.) How will you launch it? Will you run a small pilot first, to make sure everything works? Will you launch it group by group, or step by step, or try to get the whole user population and the whole process working at once? 3.) What will you communicate, to whom, and how? Will you just send emails, conduct in-person classes, or something in between? You need to think about this from the perspective of the people who will use the process; tell them not what you know but what they need to know, and explain how the change will benefit them (or benefit the company in ways they can understand).
After a process has been launched, you need to monitor and manage it. Six Sigma uses a thing called a control plan, and that’s basically what I’m advocating here. Format doesn’t matter, just the information in it: what data (key process indicator) will be watched to make sure the process works? Who will watch it? What should they expect the data to be, and when should they take action? What action should they take? (In some cases, that will just mean defining who to call, or an escalation path, when things don’t work as expected, and the action will need to be determined on a case-by-case basis.)
Of course, in the book I say all of this in my more fun detail, with lots of example!
Questions are very welcome.