In preparation for a conference at which I am supposed to lead a panel discussion on the important issues in BPM, I started a discussion on the BPTrends LinkedIn Discussion site: (https://www.linkedin.com/groups?gid=1175137&trk=groups_about-h-dsc&goback=%2Eanb_1175137_*2_*1_*1_*1_*1_*1)
I was impressed, as I always am, by the variety of responses and by the different perspectives represented. So far, over 100 entries have been posted on the discussion. My personal summary of the discussion generates a list of 5 issues for my panel discussion. As I present them, I'll discuss each briefly.
- What notation should we be teaching new process practitioners?
This topic led to lots of discussion. Some favor of BPMN as the notation of choice. Some think BPMN is too procedural in its orientation and are much more interested in the OMG's evolving Case Management notation (CMMN). Those who favor CMMN often also favor the OMG's Value Description Modeling Language (VDML), which is a very high level notation designed to describe processes before getting specific enough to decide that a particular subprocess might be best modeled by BPMN or CMMN.
Many are concerned that BPMN is too complex. I personally think this is a Red Herring, and that one simply needs to relax a bit and just use those parts of BPMN that are useful to your specific needs. In the early draft of BPMN we spoke of Core and Extended BPMN. Core notation just included circles, rectangles with rounded corners, arrows, diamonds, swimlanes and notes. In other words Core notation provided the basic symbols that a business team needed to provide a very high-level view of a process. If Business Analysts or IT developers wanted to take it further, they could add adornments into the circles or diamonds or rectangles to convey more precise information. I don't know if any tools still support both notations, but early on there were a couple of modeling tools that supported both and you could switch back and forth to make it easy for business people to discuss the overall flow of the process, while IT people could look at the process in more detail. BPMN was specifically developed to support this type of back and forth switching.
As to Case Management, clearly many process consultants think it's the wave of the future and others think it's a distraction. A key issue is whether a process that can't be well-defined is really a process. Are there, doubters would ask, really processes that are, by their nature, ill defined. The classic example comes from healthcare, because that's where the term “case management” was borrowed from in the first place. A patient arrives at the emergency room apparently suffering from a heart attack. Is there a well defined process for handling his case? There is certainly a well defined high level process, with steps like: Admit, Diagnose, Recommend, Operate… etc. At the same time, however, there are so many personal variables, like the health of the patient, the specific diseases he has, his age, whether he has had previous attacks, his overall weight, etc. that are involved in diagnosing the patient's exact problems and determining what will be recommended. In essence, the argument for Case Management runs, this problem has so many branches that its not worth trying to define a best process in advance. Instead, one determines subprocesses, and then stitches them together into a specific process when one finds out about the specifics of a particular patient. This is the sense in which it is a “late binding” problem: We don't actually define the final sequence of specific steps until we have already started working on the specific case (instance).
Everyone seems to agree that we should teach BPMN to new practitioners, but what else we teach is still undecided, though many seem to favor CMMN.
- What is the role of BPM software tools in process work today?
There actually seemed to be quite a bit of acceptance of BPMS – although there is still a fight between those from IT that insist on using BPM to refer to software tools, and those who think BPM is the broader approach to managing business processes, which may or may not involve the use of software tools. That said, however, everyone seems to agree that, increasingly, business relies on IT, and that BPM practitioners need to have tools that can manage ongoing processes. Most seem to be able to imagine a future in which every major process in an organization will be modeled and the execution of each instance of the process will be monitored by a BPMS tool that may be involved in controlling the instance of the execution, and will certainly be involved in keeping managers aware of the status of the ongoing instances that have been and are being executed.
There was some discussion of why BPMS hasn't achieved greater acceptance, but I suspect that is just a matter of time. BPMS has been too often used by IT simply to develop workflow applications and not linked to the actual management of processes. At the same time, business people have to become more familiar with processes and modeling before they can fully appreciate what BPMS can offer. All this seems to be happening, but it all takes time. And, too, we are still waiting for some really great case studies to add an extra emphasis to everyone's use of the technology.
Still, the bottom line was: These are the tools that the next generation of process practitioners will use and we need to embrace, understand and use them.
- How do we integrate BPM with Lean, Six Sigma, Decision Management/ Business Rules, and BI, Big Data & Analytics?
There was quite a bit of discussion of the nature of BPM – and how it related to other technologies, or how they related to BPM. The broad consensus seemed to be that BPM should embrace and somehow integrate with all of the others, but this discussion didn't get very detailed. Personally, I see this happening, case by case, and expect it to grow steadily. In one company a Lean group brings in a BPM consultant to help them create a process architecture. In another, a BPM group works with a Six Sigma group to redesign a set of business processes, and so forth.
Some would certainly prefer to keep process narrowly defined, but most seem to favor a more expansive approach to process work. I can remember a conversation where someone said her organization was more focused on Big Data and Analytics at the moment, and not on process. My immediate response was: How can you separate them? If someone were to ask me about Big Data and Analytics, I would ask how they can be used to make one or more of my business processes more effective.
Similarly, there are those who still want to keep decisions separate from processes – drawing diagrams, if you would, with rectangles and no diamonds. To my mind, making a decision can be an activity. The loan committee meets to decide if they will give a loan to XYZ company. They go through a series of steps, consider various things and then vote. This whole set of activities is focused on making a decision. The decision is the outcome of the process. To understand the process you need to understand the rules by which the decision is made, what facts are used in each rule, and where the facts come from. I think most are coming around to this perspective, and that increasingly decision management and process analysis will be considered two sides to the same coin.
- How do we create an organizational culture that is receptive to BPM?
Some of the issues, like those already mentioned, are largely technical, or they involve questions about how we conduct business process work. There are, however, also broader questions. One involves how we get organizations to be more receptive to BPM? How do we sell the process perspective to senior managers? How do we instill a “vision of a process centric company?” How do we create cultures where our employees support process improvement? Everyone seems to agree that this is very important, and very hard. There is as yet, however, no consensus on how process practitioners approach culture change on an enterprise level.
- How do we prepare managers to support BPM?
This is closely related to issue 4 – except that it is more specific. Assuming the organization is committed to process work, who manages it. If we have “process managers” what do they do and who do they report to? Assuming we have some kind of matrix organization, what do the departmental managers know about process? Assuming a specific activity takes place within the marketing department, does the marketing manager responsible for those performing the activity have to know anything about process? If he or she doesn't know about process, how could incremental process improvement take place? Assuming that someone is responsible for a value chain that includes the marketing activity, what is the relationship between the value chain manager and the manager inside the marketing department who is responsible for the activity, which is, after all, a part of the value chain.
These questions are easier to define than to answer. It seems to vary widely from one organization to the next. Everyone seemed to agree that it is important, but reading between the lines, it's clear that there is, as yet, no definitive answers to how it should be done.
As I suggested at the beginning, the discussion has been wide ranging, and people have approached these issues from many different perspectives. This Column is only a summary from my own perspective and others would probably put the emphasis elsewhere. What should be obvious, however, is that BPM issues range from the technical and IT-oriented to issues that are very business oriented, and involve management practices and company cultures. It's easer to at least offer a firm opinion about the technical issues. The business issues, on the other hand, are often raised, but then said to be beyond an obvious solution.
Stepping back from the specifics, however, I can assure readers that there are a lot of people out there who are vitally concerned with these issues and who have created a lively discussion of them on our LinkedIn site. And the discussion continues.