Harmon on BPM: Teaching Employees about Process

Process is a term that's been around forever, so everyone thinks they understand what it means. And, of course, people use the term in very different ways, so there is really very little effective communication about the topic.

Consider the current confusion around the topic of capabilities and BPMN. BPMN is a process notation standard that was begun in the Seventies. The Object Management Group (OMG) took over the responsibility for its development in the Eighties. The idea was to create a way of describing business processes that could be used either informally, or with great precision to generate code. For thirty years BPMN was used as an all-purpose process description language. In recent decades, as those concerned with formalizing BPMN's ability to generate code have predominated, the language has become rigid, and now process advocates are promoting other languages (e.g. CMMN) that support other types of processes. Leaving aside the pros and cons of multiple process notation languages, this little bit of history underlines that we use the term process in different ways and that our differences have grown. And, if you've heard some of the arguments about whether to use one or another notation, you know that the differences can seem serious to their various advocates.

Or, considering process in a different way, I have always used “process” loosely to describe all of the things business people do and try to control to get things done. My idea of improving a business process includes changing the way activities are sequenced, what people know about what they are expected to do, how managers act to improve employee performance and how management measures the results of various activities. In other words I use the term “process” broadly. Others think of processes as specific changes of activities. They don't consider employee and managerial practices and behaviors as part of a process. At one extreme, some IT people think of processes as IT entities that specify software sequences.

I say all this simply to underline the care required to talk about “process” in a more or less effective manner. If you simply ask a group of business people, “Does your organization concern itself with process improvement”, almost everyone will say “yes” even though, on more careful examination, you may find different people mean very different things.

In February, following up on a suggestion of Laia Mara Rizoto-Vidala-Pesoa, we asked BPTrends readers if their companies did anything to develop process thinking in their employees. Fifty percent of those who answered said that process thinking was important and that they had given short courses on the topic to their employees. I think the answer is interesting, but I also suspect that different companies offered very different courses.

Recall the CMMI process maturity ladder. At level three organizations are simply focused on defining the sequences of activities that make up their processes. At level four, organizations have put measurements in place and managers seek to use results to improve processes. At the top, at level five, organizations have involved employees and empowered them to help achieve process improvements. When most of us think of level five organizations, we probably think of Toyota, where teams of employees know what they are to do and constantly work together to devise still better ways to do their tasks. Toyota is also famous for allowing employees to halt the flow of production when quality deficiencies are found. The point, however, is that Toyota employees know that they are part of an overall process – the manufacture of cars – and that their work is a part of that process. Toyota managers are trained to support employees in improving Toyota's processes.

Process work is clearer in organizations that are centered around a production line. I have talked with employees in Toyota's sales department who say that processes and employee empowerment isn't nearly so well defined in sales. More to the point, most organizations aren't CMMI level 5 organizations. They are level 3 organizations still struggling to define their processes and to develop the process measurement systems that will help their managers improve their business processes. Most organizations have not empowered their employees to improve their business processes.

So, what do most organizations do? In my experience, most US organizations are still top down in their approach. They expect BPM groups, or at best, local managers to identify process improvements and to impose them on working groups. Often process improvement efforts are led by IT in the name of automation. IT identifies tasks that can be done by computer systems. For all the talk of Toyota employees halting production lines, in reality most tasks in a Toyota auto plant, today are done by robotics. The cutting edge in robotics is to embed quality control sensors so that robots can halt the production line if defects are observed.

For all the problems involved, I am still absolutely convinced that managers and employees need to understand processes. They need to understand that the activities that they work on are only a part of the larger set of activities that constitute the whole process – ultimately the whole value chain – and that they need to consider how their work contributes to the success of the whole.

If you asked me elaborate on this, I'd talk about understanding, about tools to improve things, and about motivation. In reverse order, you feel that something is important if it's seen to make a difference. Salespeople know their work is important because they get a bonus for making sales. Executives know their work is important for similar reasons. I believe that we should push that same idea down to lower levels and employ a lot more bonuses and incentive programs to let all employees know that their work is important to the overall success of the organization (which is, after all, the ultimate process).

Next, I believe that lots of process tools should be routinely used to help managers and employees understand where things stand and how things can be improved. Tools that process analysts use to help identify the source of problems can be routinely used in employee meetings to identify how processes can be improved. Well-conceived measures that describe process successes can be used to let employees know how they or their unit are doing. As a general principle, I think all employees ought to be able to routinely see a signboard or document that lets them know how their group is doing and compares their results with previous and expected results.

Finally, employees need an overview that lets everyone know how they contribute to creating value for customers. If their work supports others who create value, then they need to know that. I know that some employees don't care – they are just there to do some specific task. But some do care, and they are the employees that are most important to the organization and need to be encouraged and supported.

I also know that having employees sit though one more meeting where someone talks about processes and puts a flow plan on the wall is probably not the way to instill interest or enthusiasm. In my experience, the trick is to work through managers and supervisors – to get their enthusiasm up and to get them to communicate it. I know that for some readers that will sound like a big task – but I also know that really successful companies manage to pull it off. It starts with good leaders and involves developing a culture, but it can be cultivated.

Organizations need to teach employees about business processes and how everyone can benefit from improving quality and efficiency. Great organizations do it and it produces superior results.

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of Enterprise Alignment, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in San Francisco. Paul can be reached at pharmon@bptrends.com

Speak Your Mind