Years ago, a popular consulting joke that described how an engineer was called in to help repair some large boiler. He spent several hours walking around and checking valves, and then went to a particular pipe, hit it with a hammer a couple of times, and, problem solved, left. He followed up by sending a bill for $5,000. The factory manager was a bit upset, and returned the bill asking for a detailed enumeration of what the engineer had done to earn his fee. The engineer promptly responded with the following.
In a sense, this simply makes a point that every good consultant already knows: The value a good consultant brings to a project is not the physical work he or she can perform, but the insight he or she can bring to understanding the nature of the problem and identifying the options. And that insight, of course, is the result of education and lots of experience.
I spend lots of time reading, listening to and talking with process consultants. I can almost immediately distinguish between the “new” consultants, and those who have real experience and a broader education. New consultants tend to be “one trick ponies” – or at least to advocate a limited range of approaches and solutions. More experienced consultants are more pragmatic. They have been around long enough to know that each problem is somewhat different and each company has a different culture and different needs. Coming up with a solution that is right for a specific client requires learning about the specific organization and considering a wide range of possible responses.
This reality is especially hard to translate into a good process educational experience. It's tempting to focus on one or a limited set of techniques and to teach them well. My own approach, and that of BPTrends, whose training I have helped develop, is to begin by providing new practitioners with a broad overview – a more or less comprehensive overview of the kinds of problems one can face and the range of solutions one might recommend. This approach results in an initial course that can seem confusing because it seems to talk about so many different things – it often seems like a “mile wide and an inch deep” approach. On the other hand, if done right, it can introduce the new practitioner to the field and establish learning goals that can guide his or her subsequent learning efforts.
Sometimes we need to focus on factors outside the organization whose process we are trying to improve. We need to examine customer needs, regulatory requirements, or management ROI requirements. At other times we need to drill down deep within a specific process and identify the requirements and constraints of a new technology that we seek to implement, or we need to focus on the fact that a given manager routinely fails to reinforce employees who perform as we expect them to perform.
Sometimes we need to focus on activities, flows, bottlenecks, and wastes. At other times we need to focus on business decisions, rules, data, the flow of information, and the algorithms appropriate to specific situations.
Sometimes we need to focus on what employees are doing. At other times we need to focus on how managers are assigning jobs to employees or reinforcing appropriate and inappropriate employee behavior. Sometimes employees don't know what to do and need to be trained. At other times employees know what to do, but don't choose to do it, either because they don't believe it's part of their job, or because they get punished whenever they try to do it.
Sometimes automation will improve a process. At other times it will cost way more than it's worth and will lead to undesirable consequences in many associated activities.
Some problems occur because suppliers deliver defective parts. At other times problems occur because our employees don't handle the parts correctly.
In some situations, the problem lies with defining or changing the goals of large scale processes and then working the consequences of such changes down to processes contained within those larger processes. Trying to sell credit cards that are inappropriately priced can waste a lot of energy and time. At other times we want to focus on very specific activities and change or eliminate them. Requiring a step that is difficult and unpleasant that adds no value to the overall process is just a way to make employees unhappy while raising process costs.
BPTrends has a problem checklist that asks new practitioners to check for Input problems, Output problems, Constraint and Decision Management problems, Resource problems, Activity and Flow problems, and Process Management problems. Within each of these six categories we identify several subcategories. I'm sure others that take a more or less comprehensive approach have similar lists. As students work through the initial BPTrends course they return to this problem checklist over and over again. You can't turn out an experienced process analyst in one week, but you can emphasize that the analysis process is complex and involves a lot of different perspectives, and you can provide the student with experience in viewing any given situation from several different perspectives.
Having taken a comprehensive course, students will, of course, want to take more detailed courses to drill down in specifics, from Lean or BPMN modeling to Process Mining. There are lots of specific technologies that any good process analyst will need to master. The place to begin, however, in my opinion, at least, is with a good overview of the whole range of perspectives and techniques that the good process analyst will need to master to be a truly productive member of his organization's process change team.