Avontuur

Some of you may have seen hints about this on Facebook, but I realized I should announce it properly: I start work (paid-job-type-work) tomorrow.

I will be a Quality Manager at a medium-sized company that provides “Complete architectural, engineering, environmental analyses and property survey services for commercial, government, institutional and healthcare industries” (the words are from their website). I’ll mostly be working with the local part, that builds and modifies fabs for semiconductor and medical-tech companies; they’re in the process of merging with a slightly bigger company that is more into the general office architectural side so I get to help get the two sides’ process systems to play together nicely.

This is the job I really wanted, that I had three interviews for; I’ve worked in semiconductors but not architectural work, so it ought to be the perfect blend of stuff I know and new things to learn. The company has all kinds of awards for being a great place to work, with excellent benefits, and the commute is 5-10 minutes – in fact it’s just down the block from teds company, so we might be able to carpool, though as it’s less than 2 miles away biking is also an option.

I think I’m ready to go back; with the book done, I need a new challenge. Tomorrow will be mostly orientation, so should be an interesting but quiet start to being employed again.

Wish me luck!

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:

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.

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.

I’ve turned my book in to the publisher, so now it’s all done but the copy-editing and the author questionnaire (information they need for marketing, etc). That one is hard! I’d like to be able to say “Oh, yes, everyone involved in quality and process improvement reads the same magazine; it’s called Quality Today, and you can send them a copy to review.” Unfortunately that just isn’t true; discussions of this stuff happen all over the place and there aren’t a lot of good central media sites (some that do exist, like the American Society of Quality, seem most interested in pushing their own publications; others, like the relevant groups on Linked In, are open discussions that aren’t run by a central organization).

But the most difficult thing for that questionnaire is choosing a photo for them to use.

That’s hard! It’s made a bit easier because Ted has all our photos organized in iPhoto so that I can just sort for the ones with my face, but still it’s a tough decision. First, of course, there’s ruling out all the photos of myself that I hate. (I’m not very photogenic; any photo of me that you’ve seen is one I can tolerate, selected from among many more that I hated.) Then there’s ruling out the ones I actually like, but that are just not right for this purpose for one reason or another. Here are the also-rans:

A very old photo, hiking in Big Bend, Texas. Braids are the best for keeping your hair controlled on a backpacking trip, but they just don’t say “professional”!

Paula as Godzilla, about to stomp the city. (It’s Madurodam, which contains all the significant buildings in the Netherlands, in miniature.)

Me at the Ice Hotel. That’s all vodka in the red sequined bottles!

Me having a rest on the Oregon beach. Again, probably not the alert and businesslike impression I want to portray.

Me crowned as Queen. (The crown is part of a planter in front of Copenhagen City Hall.)

Classic cheesecake pose.

OK until you look close – it’s a rowing t-shirt, and the caption says “Every stroke counts!” No double entendres allowed on my business book cover.

I was considering this one, taken at Taroko Gorge in Taiwan, until I looked closer; I’m wearing a Jewish star necklace (actually, a rowing necklace in which the star is made of tiny oars) and I think including a statement of my religion is more sharing than I want to do.

Me with my nephew, when he was two months old. I love the photo, but it’s also definitely *not* the image I’m going for here. (Sorry, Mom, but no. Not gonna use this one even if you do think he’s the Cutest Baby Ever.)

I’d actually planned to use this one, until I realized it’s too blurry – they asked for “high resolution”.

And here are the four I’m considering: respectively, at my brother’s wedding; on a tower in Lisbon, on the Oregon coast (same as the “cheesecake photo above, but zoomed in closer), and at a library in Helsinki. I put them up on FB and so far have at least one vote for each of the four.