Harmon on BPM: Transitioning to Cognitive Process Analysis

Business people have been working at process analysis for a long time. Modern process analysis began with Taylor in early years of the 20th Century, and involved watching how workers performed tasks, and then developing more efficient ways of recording and performing those tasks. This kind of analysis is often termed procedural or behavioral analysis because the analyst focuses on the actual behaviors that the worker employs.

By the mid-20th Century, the focus had shifted to the analysis of covert activities. The analyst was concerned with defining how a salesperson ought to go about making a sale. There was some overt activity – salespeople visited clients, smiled and asked questions to determine what products might best serve a given client's needs. But the most important activities – the activities that distinguished between the average and the good salespeople – were often covert – they involved the analysis of the client's problems and the development of a package of products tailored to help solve the client's specific needs. These covert or cognitive activities take place within the mind of the salesperson – and the analysis problem becomes focused on techniques that could make the thinking of the salesperson explicit. Refining the thinking of a performer usually involves two things: identifying the vocabulary (the concepts) that the performer uses to frame or understand the problem in question, and identifying the rules the performer uses to reason about a problem and to design a solution.

At the same time that process analysts have focused on defining covert activities, process work has been complicated by the proliferation of computers. Computers have taken over some tasks in their entirety. In those cases IT analysts have become a specialized type of process analysts who have defined what human performers were doing and then specified, via code, what the computer would do to achieve a similar result.

Increasingly, it has proved efficient to combine humans and computers to accomplish tasks. In effect, the computer assists the human in the performance of the task. The analysis of these kinds of tasks has proven particularly difficult. Too often the IT analysts have designed computer support applications that don't work very well with people. One needs only read of some of the blotched ERP installation efforts to see how computer systems can lead to suboptimal results. In spite of bumps in the road, however, everyone agrees that the future of work involves people working together with computers to accomplish the tasks the organization faces.

In the past few decades, with the proliferation of new forms of computers, from PCs to iPads to iPhones, computers have become ever more ubiquitous. At the same time, the presence of computers in every environment, the reduced cost of computers and new programming approaches have led to business processes that are increasingly dynamic. Increasingly, companies offer tailored products, flexible schedules designed to better meet customer's needs, and individualized terms that reflect complex sales models. Increasingly, more sophisticated products are each a little unique, and each business process is tailored a bit to generate these unique and somewhat different results.

At the moment we are at a point halfway between the old approach to process analysis and a new approach. Some companies still produce standardized items in the millions and struggle to produce those items faster and cheaper. This is exactly what the traditional approaches to process analysis were designed to facilitate. Last month we asked readers of BPTrends to tell us whether their organizations were relying on traditional types of analysis, or whether they were experimenting with more dynamic process modeling techniques. All respondents said they were still using “static” traditional approaches to process analysis. Clearly the new, more dynamic techniques have a way to go before they are widely adopted.

What is it exactly, that dynamic process analysis techniques attempt to accomplish? In a nutshell, dynamic process analysis attempts to let us model business processes that change from one instance to the next. It's as if we had a model with boxes and arrows, and, as soon as we used it to accomplish one task, the boxes and arrows would rearrange themselves, so that, when we went to process for the next iteration, we would follow a slightly different procedure. This is the kind of approach that is required when you offer the client lots of options and can't anticipate exactly what responses will be required.

Let me provide a simple example. Some of the car companies have been experimenting with flexible production lines. In essence, as each new car starts down the production line, a computer chip is associated with that car and it shouts out directions as it is moved along the production line. “I am going to be a red convertible with a transmission and four doors.” The machinery along the line, hearing this announcement, shifts accordingly, painting it red, making it a convertible, etc. Obviously this requires that the assembly machines be programmed to reconfigure themselves constantly. Once they are, however, it's possible to use a single production line to generate a variety of different models, responding to the specific sales orders being fulfilled.

Cognitive Process Analysis is a generic term describing several new techniques being used to capture information about and then to design dynamic business processes. Your organization may not have run into a problem requiring this type of complexity and flexibility yet, but the odds are you will in the years ahead. Now is the time to begin exploring these new techniques and thinking about where you might use them in the future.

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


  1. philippe delorem says:

    I would describe cognitive process analysis as concept modelling. Traditionnal concept modeling using subject, predicate, object requires that the analyst describe the environment in which the process lives. This enables better describes both the process and the business rules on a case by case basis.

    Is this what you mean by cognitive processes analysis?

  2. All analysis is cognitive process.
    Just you must program options paths to get realtime instance change.
    DVM contributes to guide process running. But with DVM logics probalities-calculation based, you increase cognitive level.
    Human cognition is like logics, knowledge and probalities match n’ balance. Just apply it in process DVM program.

  3. To get a better idea of cognitive process modeling, you need to look at the OMG’s CMMN specification: http://www.omg.org/spec/CMMN/ They define “activities” (folders) that may or may not apply to a given procedure, depending on circumstances. Rules are used to trigger the use of these “activities.” In essence, its a way of modeling procedures that very from one case to the next.

  4. Leen Roeleveld says:

    Just curious what the cognitive process modeling differs from constraint based modeling (or dynamic case management or rule based). Basically this means not modeling a process in a pre-defined sequence (with or without conditions per step), but modeling ‘atomic’ activities with conditions when these activities should become active for execution. The analogy with a route navigation system is sometimes used, since these systems adapt the route at any moment depending on the exact location.

  5. Leen, Agree with your summary. CMMN is a first cut at a generic approach to dealing with dynamic processes. It allows a software system to build the flow path as information is accumulated. It could work as well with rules as with other more dynamic sets of activities. It’s ironic that it uses rules (the 80s approach to AI) to try to model how a cognitive (i.e. neural network) system might work — but maybe that’s because people need to understand these systems and their flow, and its very hard for a person to understand a neural network. As I say, CMMN is a first cut, and may not be widely adopted. At this point, its more a pointer to the kinds of control we are going to need, if not the best way to actually implement that control.

Speak Your Mind