Harmon on BPM: Process Problems and Solutions

I was happy to see that readers responded to our January mini survey by saying that they expect a busy year with lots of process improvement work. At this time, being busy is good.

In the last two months, I have considered some of the broad types of business processes that companies seek to improve. Specifically, there are manufacturing processes, service processes, and, at a bit of an angle to the other two, management processes.

This month, I thought I would step back and consider an even broader perspective: the range of problems that a business process practitioner might address. I fully realize that most of us are in jobs that limit our scope. We are expected to look at some problems and ignore others. For all that, however, it's worthwhile to be aware of the range of things that can cause business problems. Even if we aren't in a position to address them, just knowing we can't, and not wasting our time with false solutions, saves time and frustration.

So, most broadly, there are problems that are company-wide, others that are division or department-wide, and still others that are concerned with specific, local sets of activities. If an upstream process consistently delivers the wrong items to the process you are focused on, or simply fails to deliver anything on time, you have a problem, and focusing on the local process won't solve it. You need to be able to address why the upstream process isn't functioning as it should. We traditionally seek to address this type of problem by talking about value chain or enterprise issues.

In an ideal world, someone engaged in process work should be responsible for maintaining an enterprise or value chain perspective. Specifically, they should have an architectural model that suggests how all the major processes in the organization (and perhaps even some processes maintained by business partners) fit together to deliver value to customers. Using such an architecture, one can trace the flow from orders through manufacturing to delivery (or from request for service through provisioning and then delivery of service). By looking for bottlenecks or disconnects, one searches for the true cause of major process problems.

In a similar way, every given business process uses the outputs of support processes. Suppliers must be paid to provide resources. Employees must be hired and trained and paid. Phones and software systems must be installed and maintained. Support processes, like upstream processes can be a source of problems and can limit the effectiveness of other processes.

There's nothing more frustrating than to be asked to improve a process, only to find that the source of problems lies with another process that one is not to touch. Good process practice begins with a broad survey of potential sources, and focuses on the subprocess that is really the source of the problems.

Assuming one has done the enterprise architectural work and truly zeroed in on the process with the problems, then it's a matter of considering the sources of problems within a given process. Historically, when we think of process, we think of flow. We think of a series of activities that need to be performed in order. As we step back, however, we realize that there are many dimensions to a flow. There are people who perform tasks. There are software systems that execute programs and there are machines that do things. There are resources that need to be available when needed and there are tools that are either available when needed, or not. All of this, in turn, is coordinated by managers or supervisors, or at least by manuals that specify procedures. A basic list of things to check when one looks at a specific process includes:

Activities: Is there a well-defined sequence of activities? Is the flow reasonable? Are decision-points well-established and decision criteria well-understood?

People: Are they there? Are they trained? Do they know what to do? Are they motivated to do it? (Are they discouraged from doing it?)

Logic: Are their business rules that define what needs to be done and what should not be done? Are they well-understood and consistently applied?

Information: Is information (data) required for the process to proceed? Is it available as needed? Is it correct and adequate? Is it understood?

Programs: Are there applications used in the process? Do they function as they should? Do they generate the desired results?

Machines: Are there machines used in the process? Do they function as they should? Do they generate the desired results?

Resources: Does the process consume parts or subassemblies that must be available at a given point in the sequence? Is inventory adequate? Are things available as needed? Are they adequate? Are facilities adequate and located as needed? Are tools adequate and available as needed?

Management: Is supervisory support available when needed? Are goals clear? Is feedback available and adequate?

Measurements: Are there established ways of measuring results? Are the results of measurements available as needed to make decisions?

Obviously each of these considerations apply at a broad level, and can then be used again as one drills down and considers subprocesses and more detailed activities or tasks.

Very broadly, a business is a process that results in delivering value to customers and other stakeholders. Thus, sooner or later almost all aspects of the business must be considered if you are really to maximize the efficiency and the effectiveness of a process.

Over the years different groups have tried to summarize process work and define systematic approaches. There Lean, Business Process Reengineering, Six Sigma, Human Performance Management, IDEF, Business Rules, and many more. They all provide tools that the well-educated process practitioner needs to solve business process problems.

Armed with a broad set of process improvement tools, you should be ready to go forth and deal with the challenges of 2022. Good luck.

PDF Version

Bio
Latest Posts

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 BPTrends Associates, 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 Las Vegas. Paul can be reached at pharmon@bptrends.com