Archive for the ‘Process Book’ Category

why a process needs a system

Friday, July 26th, 2013

In my last post, I talked about what a business process is, and why it’s important to have them. However, you can’t really have one process by itself. They get lonely, and need their peers. More precisely, one process’s output is the input to another process. A system explains how they all fit together. This might be clearer if I give you an example, so let’s assume we have a toy factory. They design, build, test, and sell new toys, which means they also have to hire and mange their workers, maintain their machines keep the roof from leaking, comply with local laws (like OSHA in the US), control their intellectual property (traademark products, decide whether to sue someone who copies their designs, avoid copying anyone else’s designs), keep the office clean, decide what email program to use as the company standard, and so on. Here’s an extremely simplified diagram that shows how some of their processes fit together – each blue box is a process:

process system

You can see from this picture how one process feeds into another. You can also see a lot of other features of a process system here; for instance some of the processes I’ve shown, like “Create a New Toy” are actually made up of a whole bunch of more detailed lower-level processes. I didn’t show all of them for reasons of readability, but to create a new toy, you’d first document requirements, then create a design to meet those requirements and build a prototype. If needed, you’d write the software, and integrate it with the prototype hardware. You’d test the toy to make sure all of the requirements were satisfied, and if you were smart, you’d then let some of your target user groups try it out to make sure they liked it. (In the case of a toy, that means you’d let actual kids play with it and see if it was fun, and you’d make sure no one got hurt because of any problems with the toy.)

I drew Manufacturing as a sheaf of processes, because those vary according to the type of toy. Depending what it’s made of, you might need to form metal or mold plastic. You might choose to make or buy smaller components, like wheels for a toy car. Then you’d sand off rough edges and paint in details. For a doll, you would root in the hair and dress it in clothing; for a Lego kit there’s a whole process to combine and package the right pieces together. Some toys need documented, printed instructions. Each type of manufacturing consists a set of many smaller processes, like the design example above, but there are lots of different sets.

You can also see in the diagram that any time you have a resource, whether it’s an employee, a manufacturing machine, a vehicle or a building, you need a whole set of processes to support them. Employees must be hired, trained, given benefits. In most companies you review their performance annually and give rewards or set up improvement programs based on those results. They have to log their hours and get paid based on them. Each of those things is a process, and they’re all related. Similarly, machines need to be bought or built, maintained, inspected and calibrated; buildings and vehicles need to be bought or rented, cleaned and maintained. They may need to be inspected to make sure they pass local laws.

The graphic above is drawn from the point of view of a product being manufactured; the main line is the processes it goes through and the arrows show how it’s tangentially affected by other processes, like the hiring process that brings in the engineer who does the design work. Not all organizations produce a product, though; for a hospital, I might draw processes from the point of view of a patient. There would be processes for admissions and for providing facilities – rooms, beds with clean linen, food, wheelchairs, and so on. There would be lots of different processes for treatment and nursing care, depending on what the patient is being treated for. There would be the same sorts of processes we saw in the last example for hiring qualified doctors, nurses and other staff, making sure that they take their required continuous education courses, scheduling them so that all shifts are covered even when someone is on vacation and (hopefully) no one is working 24-hour shifts, providing them health insurance and desks and computers. Hospitals also need processes for evaluating when, for instance, a new MRI machine is required, deciding which one to buy and then maintaining it.

Everything I’ve talked about here is part of the process structure, and I hope its value is self-evident. There is also another component of the process system, which I’ve called the process environment in my book. This controls how you publish a process – it includes templates, a repository and a delivery system and maybe a process of its own (yes, a “process on how to write processes” – it can be good to have guidance for people who are inexperienced in this as in any other task). The templates govern the look and feel of a process document, so that all the ones in a company are structured in the same way. This saves time on both ends: the process creator doesn’t have to make decisions on how to organize their document, and the reader knows where to find the information he or she needs within a document. The repository is an online library or database, so that processes are stored in an organized way and the user always gets the latest version. The delivery system is usually an intranet page; it should be organized in an intuitive way so that process users can easily find the documents they need.

Of course, I used a lot more words and details to explain all of this in the book! There is a lot to think about: how to structure your processes and keep track of their relationships, whether to have a Quality manual that states your Quality Policy, commitment to quality for your customers, and explains the process structure, whether you need to comply with a standard such as ISO 9001, and lots of other considerations.

Friday, July 12th, 2013

SuccsfulBizProcssMgmt

What is a Business Process, and Why Should I Care?

Thursday, July 11th, 2013

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.