Purpose Case Management

Preamble

After many years of process-dominating approach to our work, we have collectively “discovered” that the process is not the only way of doing things. There are many unstructured activities and even social activities that have to be governed and managed. These activities affect our daily productivity and, at the end, an efficiency of our businesses. We emphasise that we’ve finally recognized the reality without answering “why this has happened now?” Unfortunately, this awakening comes with a cost.

When looking from an enterprise viewpoint, it becomes clear that in spite of great ideas, decisions and even smart architectural solutions (believe it or not, but some enterprises have started using this capability), many companies cannot deliver because of… their business processes.  Moreover, nowadays business and project management is getting split between “methodology camps” that try to establish their exceptional superiority in the business and technical domains. It seems that traditional BPM-oriented business and technology governance is outdated and needs a revision.

How can we move forward in such situation? This article argues that a Purpose Case Management model is the foundation of enterprise governance that can overcome “method-wars” and establish priority of enterprise objectives over “how we do things overhear” tradition. The article reviews hype-promises of several business management styles and proposes an overarching model, which is set in line with the corporate business goals. We will try to defeat a blind belief into the magic of methodology-regardless-context vision and restore a subordinating order between enterprise objectives and an individual project.

Why We Do What We Do and How to Manage It

Our life is full of surprises. At work, we tend to minimise surprises or, at least, prepare for them having our arsenal ready. Regrettably, it does not matter how hard we try, there are others out there who love to surprise us.

We try to plan if not our life than our work. Planning assumes certain organisation and predictability. So, we organise our actions into business processes and, thus, we need business process management (BPM) methodology and practice [1]. A business process is finite, predictable and repeatable; we can transfer knowledge and clone the business processes for new workers, i.e. we can reduce specialization and encountered cost.

Since the majority of these processes is performed by people, the human factor is very strong and, in some cases, business can capitalise on social elements and interpersonal relationships if social elements are managed properly. This leads us to so-called social BPM (SBPM) – an emerging discipline and methodology [2]. The SBPM in essence is a collaborative aspect of business management that utilises a collective network environment. Whether this is a new thing or a previously ignored one, we will see.

Since we cannot prepare for everything, there is a lot of situations where we do not have a business process but we still have to act now, in an absence of structure. This does not mean that we never knew about the situations or events that triggered particular set of unstructured actions – we could anticipate some them but we did not. We can blame our resource limitations but this does not help much. Eventually, some sets of unstructured actions can transform into new process for the similar cases but until this happens we are on our own. So, the proponents of “unstructured processes” (UBPM) have stepped forward.

The first attempt to “mix-n-match” a structure with the absence of the structure has been performed in the theory of Adaptive Case Management (ACM) [3]. The ACM concentrated around the role of knowledge worker who is capable to decide what to do in particular situation. While the concept of knowledge worker resonates with the social BPM, some people attribute content, process, rules, collaboration, analytics, information presentation/dashboards etc. to the ACM rather than to SBPM. The emphasis of the ACM is on how to make the next move. The knowledge worker is supposed to challenge any decision at any step even if he or she deals with a process, i.e. with pre-defined logic. What the ACM misses or conceals as a tacit knowledge is why the next step is needed, what for, are criteria used by the knowledge worker correspond to the overall purpose of the motion or these are just simple “job saving” activities.

Given quick observation demonstrates that we have, at least, four methods that teach us how to deal with the management of problems and tasks we have to solve at work. If we take an outside-in look on this quartet, we can find that none of the methods clearly justify its appropriateness to the overall business goal. The rule is simple: “here we do things this way. Period.” If the “way” is process-centric, everything is about processes; if the way is about unstructured activities, then each process becomes a persona non grata. The management still focuses on doing things that can deliver “whatever” results and this may be all right, for now. The only way to re-rail “this way” to “right way” is a governance of management, i.e. governance of implementation methods of enterprise architectural decisions.

Nowadays, there are intensive discussions running across information media between camps of BPM, UBPM and ACM specialists about which one of them is “more valuable” and more important for business; “one form fits with all” – this is what each of them proposes to the enterprise. If this is not a self-saving tactic, then what is it? Every enterprise knows that the quality of the procedure - whether it is better or worse - is immaterial if it targets a wrong task. Peter F. Druker said once, “There is nothing so useless as doing efficiently that which should not be done at all.” However, for the people who do the management the entire picture may appear like in a mirror where right becomes left and vice versa. 

We assume that all business actions in an enterprise - ordered or unstructured – have to help it to reach its objectives and goals. This is not only a declaration but also criterion of management suitability to business needs. In other words, all our actions have to have their purposes that collectively aim at corporate business goals. If the actions just blindly follow routine method rules, the risk of deviation from corporate business goals is very high.

We argue that the BPM-SBPM-UBPM-ACM competition may be resolved via valuating each method against the business objectives, i.e. verifying their adequacy or relevance to the particular needs and goals of the company. If we treat corporate business goals as part of the purpose of each management case, the Purpose Case Management (PCM) therefore becomes the overarching concept.

The PCM is a natural and logical container where all other management methods are situated. With the PCM, managers can switch between processes and unstructured cases depending on available information and resources, while preserving the same business purpose at every step. The purpose is the end that drives the means.

Hype about Flexible Processes

It is amazing how much effort people make to demonstrate that the familiar and reliable engine at one time can be a perpetual motion to serve them forever; the BPM is a bright example of this. To survive, BPM crusaders insist now that a business process is a flexible model.

The question is whether a business process is flexible caused by the situation in an external market, which requires fast and frequent responses to changes. In contrast, a process, and the business process in particular, should be unchangeable. If one creates a structure of business processes properly, the process works toward its own stability. On one hand, this facilitates the creation of a silo for each process. On the other hand, one monolithic process wants to own everything around it. If a business organisation were built on the structure of business processes only, it would not be able to cope with the dynamics of an external environment. “When the rate of change outside exceeds the rate of change inside – the end is in sight”, said Jack Welch, the legendary CEO of General Electric.

Any deviation of process execution from its logic and step-values is a change. Any change is a disturbance to a process by definition [8]. A change can break stability and, thus, compromise the quality of a process leading to the outcome defects. If changes happen frequently and in different points of the organisation, a structure of processes faces a risk of massive destruction, dysfunction and, finally, can crash. Some business process specialists have recognised the described threat and proclaimed an “alternative opinion” saying that a process may be very agile to changes. We assume that being agile to changes means being able to adapt as needed. Let us look into this matter because agility is one of the main objectives of enterprise architecture and, if its implementation via business processes might be made agile, this would be a great benefit for both architecture and enterprise.

First of all, we have to understand how one process differs from another and where the board-line between a changed process and a new process is. If we try to distinguish processes by their inputs or goals/outcomes, more than one process can have the same inputs or goals/outcomes, i.e. these attributes are not informative for us. The same relates to people working in a process – the same skilled team can work in more than one process at a time, and the same process may be executed by different teams as well. If we use process actions to differentiate processes, the same set of actions can serve more than one process and, thus, does not help us again.

The only element of a process that uniquely characterises it is the process’ logic – the rules that set the order and conditions for its steps. We say ‘steps’ instead of ‘actions’ because the process is interested in specific results at certain times only. The ‘personalities’ of individual actions are immaterial to the process - different actions can produce the same results while a process is more than a sum of used actions. For example, if supplier A delivers car parts packed into the container using a lorry and supplier B does the same with a much smaller vehicle, does the car assembly manager worry about how the car parts were delivered?

Popular opinion that the process is, in essence, a collection of actions is based on the perception that they were performed before and now we only have a certain order for them. The perception is easy to understand because it is about natural transformation of critical quantity into new quality. However, knowledge of an order allows us to abstract actions and even use a competition between them. Today one winner will be used by a process, tomorrow – another one.

At the same time, any action brings a risk of failure in delivery of the action results. If the action fails, it can hurt the process; therefore, it is better for the process owner to control not only the process’ logic, but also all related actions/sub-processes provided by others. The idea of such control leads to the monolithic process “kingdom”, where the process owner manages all the owners of sub-processes in the process structure: the super-process owners do not want to share sub-process with other processes (sharing creates additional dependency and potential shortage of resources for the process).

Thus, a change in the process logic generates another or new process. Even if we change one condition in one of the rules for step N, we create a new process. Yes, the same people perform the same actions but now in a different order, and this can lead to a different outcome or different quality of outcome. By changing one condition, we replace one process with another. Why do not we note this replacement? It is because even process workers think about their actions as realising a certain business function, but no functions change due to the change in their realisation. However, this is a different topic – the sphere of Business Services (functions) implemented by business processes...

(Click on the image to enlarge it)

Figure 1

So, when we talk about adoption of a change in a process and related “quality of flexibility”, we really mean not a change in the process but a change in external things – actions or action providers - that the process uses, as shown in Figure 1. In other words, there is no such thing as a changed process. To adopt a change, we create a new process every time. Strictly speaking, the process flexibility does not exist.

Enterprise planners, including Enterprise Architects who helps business and managers to improve operational efficiency have to clearly understand – they help to improve business capabilities regardless terminology of Six Sigma. Moreover, immutability of a process helps to understand that a new, replacing process does not necessarily need to carry over the old process resources, habits, subordination and relationships, which altogether constitutes serious cultural shift in the enterprise.

Defining Flexibility

Why is it so important to know that a process is inflexible? Let us point to just a few areas where such knowledge has a significant impact:

• Operational efficiency – information about upcoming changes signals that new processes should be created until it isn’t too late
• Management of the skillset - people with a process-oriented mindset have difficulties thinking and acting in abstracted processes (services), which results in a slow operational transformation
• Risk management – tensions between a process routine and changes negatively affects the overall outcome
• Resource consumption – awareness of process immutability helps to save time on exercises of process changes by shifting the focus on creation of a new process and replacement of an old one.

It is a matter of fact that all strategic re-engineering of business processes starts with re-interpretation of processes into business capabilities, i.e. as Business Services. It is much more convenient and efficient to operate with services than with processes, because each service may manipulate a variety of processes that provide the same outcome, which has different operational logic.

To complete the discussion about flexibility, we explain what a flexible solution – process or service – means. Flexibility – an ability of adopting changes – may be graded from low to high. How the adoption is realised – by changing internal actions or by changing the order of actions – is irrelevant to the concrete final result. However, the particular way of adoption can influence the cost of adoption. If the adoption of changes is cheap, this indirectly manifests that the adoption is easy, i.e. flexibility is probably high.

In numeric expressions, flexibility may be associated with a grade set against a scale. There may be many different concepts of the scale and we offer just three simple ones:

1. Putative – a subjective or commonly recognised scale
2. Relative – created via comparison of analogous results for the known set of cases. Alternatively, this scale may be called Comparative
3. Empirical – based on the historical data of Relative scales created in the past.

Solution flexibility may be viewed from several different perspectives such as technical, managerial, financial, and others. We have chosen the financial perspective as the form that may be presented more easily to decision makers who are accustomed to deal with this obstacle on a daily basis. We also know that before the solution goes live, we can only estimate its flexibility.

Our estimate of the flexibility is based on three parameters:

1. Actual cost of making a change (ACC) to a solution; this includes all analysis, design, development, regression testing, deployment and training
2. Cost of solution maintenance (COM) combined with the cost of adjusting/refining/integrating existing systems/operations to make them work with or when a changed solution is present
3. Time to market (TTM) that is a delivery time of the change to a live execution mode.

The Table 1 contains a description of a method we call Flexibility Estimate that we use to grade flexibility of existing or new solutions. The flexibility of a solution reaches its maximum when the ACC, COA and TTM become minimal simultaneously [9], e.g., next to zero.

Table 1

Using the Flexibility Estimate method, we can demonstrate in numbers that if a solution is “quick and dirty”,for example, TTM and ACC may be low but the COM appears high, the overall flexibility is lower than in the case where the TTM and ACC are a bit higher but the COM is much lower. We hope that the Flexibility Estimate method would help business management professionals (including IT management) to defend new innovative solutions before the decision makers, by discussing the same business language of money and time with them.

Hype about Unstructured Process

As we learnt in previous sections, regular processes cannot keep up with the dynamic business environment. This has caused a desperate attempt to “mix ice and flame” by introducing so-called unstructured processes, which, according to the definition of “process”, is an oxymoron. Instead of “unstructured processes”, we recognise unstructured sequences of activities, that are our reality in many cases.

Chris Adams, a VP of Product and Technology at Ultimus, believes that "the majority of processes in business have ALWAYS been unstructured" [6]. In Chris' classification, a workflow is the lowest hanging ‘fruit’, structured processes is the middle ‘fruit’, and unstructured processes is the highest ‘fruit’ to attain. At the same time, Scott Francis argues [7] that technically the unstructured processes are easier to implement than even a workflow.

In our discussions with many BPM professionals, we have uncovered that champions of process management believe that “everything we do is a process”. We disagree with this view; it seems more similar to religion than to a reasonable and logical conclusion. For instance, we know that ‘everything we do’ is a set of actions. One action is not a process because there is no logic for the next action, just as there is no next action. The sporadic actions are not a process because they have no relationships with each other. Only if we are aware of a special logic that tells us what results we have to obtain to make the next step, or how to act from now on, then we deal with a process.

In an unstructured “process”, the logic and the next step are not pre-defined. Those who have to perform the next step have to decide on-the-fly what to do and why. Since we cannot compensate incompetence of a worker in the unstructured “process” by professionally mastered rules and prescribed actions, an unstructured “process” is in general unpredictable. This is why it must be closely monitored and managed; otherwise a risk of extraneous results is high.

According to Scott Francis, Lotus Notes applications, email, or SharePoint are examples of unstructured “processes” provided by IT. It is hard to believe that operations with any application is unstructured, and we are curious what constitutes an unstructured “process”, e.g., in e-mail? What is the action logic that is absent in an e-mail?

Technically, e-mail is a means of transitioning a finite amount of information from point A to point B via a mediating network and concrete transport protocol. Sending an amount of information from point A results either in an appearance of this information in point B or in a failure. The network passing between A and B is finite and well structured. If we add a human user “to” the e-mail system, the number of human actions applied to an e-mail is very limited and may be structured in a combinatorial^[1] manner.

Finally, if we consider e-mail as an IT contribution to human interactions and argue that this very set of activities is unstructured, does this constitute that the e-mail based process is unstructured as well? No, it does not: we have a classic isolation between the e-mail process – the instrument - and unstructured human activities – how the instrument is used.

The last hope for unstructured “process” realisation with e-mail is on the process of human dialogue. Indeed, we do not know whether the counterpart would respond to a sent e-mail. However, knowing the action and structuring the action are not the same thing. In the case of dialogue, interaction via e-mail is structured: there may be only two possibilities - the e-mail will be responded to or not (with some time-out variations). This gives the sender enough information to structure their next logical step: if e-mail is responded to, perform Step X; otherwise perform Step Y. If someone argues that our e-mail may trigger an e-mail to an expected recipient, i.e. performs an unstructured action, we notice only that this new e-mail belongs to another dialogue and is out of the scope of our initial process. Therefore, the e-mail based dialogue is fully structured.

It seems that a notion of unstructured process is just marketing hype related to the motto of omni-process. The BPM professionals have found unstructured activities as a real threat to their monopoly and tried to “lead the rebels”. Unfortunately, for them, an absence of structure is the process antipode; it cannot exist under the rules of process structure proving life outside of a process.

We are not cherry-picking in this analysis. To understand what to do next, we need to know where we are in reality, without clouds of political correctness. That is, things have to have concrete definitions, which do not leave room for opinions and misinterpretation. The more straightforward a definition is, the easier it will be to operate with it. If we get into a situation where we do not know what to do, the best way to proceed is to admit our inability. We frequently see that in such situations people (management especially) try to do whatever they can, instead of trying to find out what has to be done. For example, if a team needs to change a certain business function in an already operating environment, it is fairly obvious that the first task is to understand the consequences of this change. In the first observation, a team finds several areas that will be affected by a change. The team starts immediately digging into these areas instead of making sure that they have not missed other areas that might be even more important than the ones found.

Hype about Social Business Process Management

Innovations are always surprising either in their outcome from simple things or in their unusual nature. However, judging from the perspectives of 'surprising', we have to distinguish between a real innovation and a hype aimed at satisfying personal ambitions.

One of the latest trends shows that the term “social” fires up everywhere: in communications, media, in the concept of capitalism and, apparently, in business processes. The parade of titles like “BPM Goes Social” (Software AG), “BPM Gets Social” (Oracle) and the “BPM Socialite” (IBM) is enough to put attention on a trend. Yet, we have to warn you – read what is written rather than repeat the slogans.

For example, analysts Phil Wainewright and Dion Hinchcliffe talk about “a new meme in town called social business that says we should design enterprise systems around the people that use them, rather than trying to make the people work to the constraints of the systems they've been saddled with” [13]. Phil and Don talk about the ‘systems’, not about social business, and they mention nothing about business processes built “around the people that use them”; the majority of people in an enterprise are processes workers, not users.

So, what do we know about “social BPM”? Not much besides enthusiastic proclamations. Forrester Research first introduced social BPM to their “2009 BPM Tech Radar” report, which highlighted the use of Web 2.0 and social tools within BPM implementations. It was not social BPM as a special type of business process management, but rather a tool set that supported more uncontrolled collaborations between people. Did this collaboration relate to a process? This was still the question but a new buzz was coined and started to roll.

Some people suggest that the problem with understanding of social BPM is in the personal perception that associates all 'social' prefixes with Facebook and Twitter that are hardly applicable to internal corporate business processes. Others say that social media, where social BPM roots come from, is, in its nature, too unpredictable and watery to be seriously considered. Finally, some people blame the absence of acceptable definition, difficulties with the changes of organisational culture and process management. All these people do not doubt that social BPM has a sense. Well, has it?

Verna Allee, the author of the concept of Value Networks and the method of Value Networks Analysis (VNA), notes:

“Every business process has a hidden network pattern of human interactions. Traditional work design approaches ignore the critical human interactions that build relationships and make the processes work”[9].

Verna’s statement is made primarily for the network of human interactions, and we fully agree with her about the presence of human interactions in any business process.

Well, business has known about this for years and some processes are deliberately made strict to minimise the human factor as the cause of deviations, i.e. process defects. That is, human interactions in processes are noticed but not taken as an absolute boon in all cases.

When looking closely, it is possible to note that enterprises already widely use social elements in certain types of business processes, particularly via e-mail and internal instant messengers. Some companies utilise the concept of Centre of Excellence to facilitate individual initiatives and innovations. However, this relates only to particular types of business activities.

The first and the most obvious position of social BPM may be found in enterprise client relationship management (CRM), where the social element is the basis without any BPM merits. The second position for social BPM is in the corporate management of strategic employee motivations. These are known as ‘people processes’ that also require business management. We think that just an amendment of existing business process with some social interaction tools does not really create social BPM.

David Meggitt, an expert in Value Networks methodology, says:

“Merging social/informal networks with formal process requires a radically (and disruptive) conversion of perspective - one from a process to a human or people centric viewpoint and incorporation of role play with real people in contributing value as perceived by collaborators at every step and level in work activities”.

This seems the right warrant but it is still about how to proceed with a merge, though we are not yet convinced whether it is really needed.

By definition, business processes, like any processes, are ordered sequences of steps with absolutely concrete (if done right) business logic. The notion of 'social' includes spontaneous, emotional and unpredictable human behaviour. Such behaviour does not fit into a paradigm of concrete order; it is also not compensated by human creativity. For example, when a company produces medication by mixing components Alpha with Beta, it does not matter what and how people, who do this mix, say or feel - Alpha and Beta must be mixed in a prescribed proportion at a certain time, and nothing else is allowed.

What can business processes gain from socialising? The best outcome is full integrity between social and process paradigm. The worst outcome is where people do not accept process logic or chosen operations and try to short-cut them. This may be the fault of a process or people skills, but in any case it must be the signal to a business.

BPM has Value Chain or streaming in the background. Because of this, each action or option in a process must produce a tangible business value. Can a social activity produce it? Proponents of social BPM insist on that human element in the process producing additional intangible values. The VNA has concluded [12] that the majority of intangible (particularly, social) values never materialise and, thus, cannot be measured in terms of Value Chain. That is, business has to first possess the understanding of intangible values of Value Networks, and only then decide where these values really help (or disturb) business processes.

During an interview with Peter Schooff [10], Craig Le Clair, a Principal Analyst at Forrester Research, said

“…today, we have to invest more in that information-world worker and in these knowledge workers that are becoming, more and more, the embodiment of our intellectual property and are critical to providing the higher level of services required.”

Le Clair was describing so-called Dynamic Process Management (DPM) that uses a lot of common concepts with S-BPM, but may have different wording. He concluded

“…whereas BPM and traditional ECM [M.P.: Enterprise Content Management] tended to script and lock down a process, dynamic case management frees the information worker so that the driver of the system is a combination of technology and that human being who must make decisions and must use judgment.”

Well, the “human being … must make decisions and must use judgment” if another human being had not done this before and prepared process logic for a particular case.

If the logic is in place already, the working human being must be very accurate if replacing an existing decision in a process with his or her own, because individual judgement may be simply incompetent in a given situation. We see examples of this nature every day in development practice – developers-designers still believe that they may make decisions instead of listening to architects. The Architects supposedly consider a much wider range of dependencies, and may have information and constraints that are simply not provided for developers-designers, but this does not stop them. From this perspective, a perfect designer’s decision may be inadequate for a particular execution context. Processes that include mandatory human decisions and corrections are barely repeatable and cannot be replicated with assurance, i.e. cannot scale and support enterprise evolution.

We recognise the dynamic or social BPM as an important part of collaboration during the building phase of a business process. Yet, we disagree that most business processes should be "people processes". Instead, it is the outcome of business processes that should be people-centric. The same relates to systems. Business processes are created to dictate to people what, when and how to deal with them, in order to produce the products required by the same people.

Some Notes about Adaptive Case Management

Unstructured actions only take place when no structure is available to use. For such cases, the ACM proposes to use knowledge workers. The ACM does not assume that all our actions are always structured. Dave Duggal from Consilience International LLC, explains that the Case Management identifies a situation where known processes are helpless like a ‘Case’. “A Case is a folder metaphor, a container for organizing artifacts (documents, forms, process fragments, etc.) and logging activities related to a business objective.” When comparing a Case with a process, Dave says:

“Having a goal doesn’t make the Case a process, it makes it work for a purpose like a Business Service. Completing related, but disconnected, activities of a Case is not a process. The inclusion of a process fragment in a Case, does not make the Case as a whole a process”. Also, “The Case may involve multiple contributors, collaborative work, but that does not make it a process. This is a semantic, not an existential question. That unstructured human activities are not processes does not diminish them in any way” [7].

Dave’s explanations clearly show that ADM is quite different from a business process, though they both seem similar to an external observer.

Notions of unstructured and unknown are frequently mixed. When dealing with unknown, we try to understand it first and then react to it through actions. Keith Swenson, Chief Architect, VP of R&D at Fujitsu America Inc., has described these actions very well [8]:

“a case manager works through a case, continually assessing the situation, making decisions that define the course of the work. After it is completed, the case manager knows all the facts of the case...It is easy to think that the whole “process” could have been set up in advance.” Indeed, “Our minds naturally put form on what would otherwise be indescribable, we vastly underestimate the variability of action that could have occurred. We vastly underestimate the amount and nature of exceptions that occur. Most of all, we vastly under-appreciate how well intelligent people can use experience”.

Common knowledge tells us that we do not know how to resolve the problem in certain cases. This confusion may be caused by many things, e.g., we were not aware of such a problem before, or we recognised it but considered it invaluable, or we tried to address it in the past but did not have enough resources that time. It is rare that we can say a problem is totally unknown; more frequently, we are not prepared to deal with it in the regular manner. We react to an event-in-problem but we act with no particular structure. Note we do not go crazy because of our own unstructured actions, though we cannot initially explain the action logic even to ourselves. If we agree with his, why are we obstinately trying to knot unstructured activities with a structured process?

ACM is, probably, the most powerful management method among those observed. It can give a manager an instrument to do the right things at the right time, but it does not enforce the “right doing”. A presence of unstructured actions in ACM makes the method outcome dependent on the individuality of a manager. That is, though ACM can effectively solve problems, it is still non-repeatable and non-scalable. To work properly in most cases, ACM needs strong and objective governance provided by Purpose Case Management (PCM).

Purpose Case Management: What and How to Do It

We assume that it would be difficult to imagine a business model in which the business did not know what to do at the next stage. Such a model contradicts the essential idea of enterprise. When working, we suggest that one knows the final goal or purpose of one's actions, but we might not have appropriate management methods to reach this goal.

When we face an unplanned situation, we can engage ACM. The adaptation in ACM may only have one of two criteria: whether the next action leads 1) to one of the case’s goal; or 2) to the solution of the overarching business task, which is not necessarily the same as the case goal. The use of the second criteria transforms ACM into PCM, because it constitutes the governing control over each ACM action.

The PCM allows some pre-existing or prepared solutions like business processes and related BPM. Also, in contrast to ACM, all actions in PCM must be challenged against the overarching business purpose (OBP) before executed. ACM might assume purposeful intents, but it does not make this requirement explicit. Instead, ACM relies on the managers and knowledge workers to justify taken actions, which may not be a good idea in some cases (because people can easily substitute objective reasons with subjective ones – just in order to report the delivery of something).

In PCM, to deal with unplanned, we need mechanisms for:

1. Easy and flexible adoption of our actions to a changed situation
2. Quick valuation of our action results in order to make a decision about the next step sooner than later.

Such mechanisms can include:

• Methods of pattern recognition and subject matter analysis (a combination of human creativity and knowledge, such as in DPM) – to identify a situation and choose from an available arsenal of reactions
• A rules engine or another ‘engine’ similar to our ability of applying our knowledge and foreseeing possible outcome of an action.

Some potential actions might result in the finding of an existing process that could start at this point (not earlier). Nevertheless, if this process does not fit with OBP, it appears useless to us. If no processes are identified yet, we repeat the whole exercise again and again until we resolve the task and complete one Case, or we find a suitable process and run it, as shown in Figure 2.

The PCM plays the role of container of business management methods. In particular, the Case goal can be invalidated depending on the circumstances, which occurred during the Case processing, while the OBP or task cannot. The latter represents a strategic intent and only certain external (to the Case) forces can invalidate a business task; the former is more tactical and more likely to be affected by the results of our own actions. The business purpose, referred in PCM, also evolves but likeness of its changes is much less compared to the changes of an individual Case goal.

How can we find the right next action in PCM? Actually, a “try-n-go” approach is not a reliable business solution, though it might work in some states. We suggest that a more effective approach may be learned from the mathematic theory of approximation. One of the possible applications of this theory is called “Spline Tactics" [11]. The fundamental idea of that “Spline Tactics" is: in the absence of the rules, to properly adjust your next step (action) you have to learn about the “future”; you have to look into the “future” as far as you feel comfortable with and confident in your findings (using actual information or simulation). When you make your step, the learning starts again, but now based on previously collected knowledge about the “future”.

Returning to PCM, we propose to analyse Figure 2. It illustrates two scenarios where the PCM is realised with structured and non-structured actions. Conceptually, the PCM contains one or several Cases with their individual goals. We can say that the PCM performs as the cross-Case controller-dispatcher, while within the Case the ACM preserves an “equal opportunity” for unstructured actions and processes, where applicable. Therefore, the PCM allows smoothing transitions between unstructured and structured actions across BPM, DPM and ACM – it sets the reason for every action, regardless of the process or unstructured management methods.

(Click on the image to enlarge it)

Figure 2

In Figure 2, in Scenario 1, the chain of business processes is triggered. In one of the process steps (Case 1), the predefined sequence of actions does not happen and, to meet the business purpose, it is necessary to switch to the peculiar case management (Case 2). It is peculiar because it is not predefined as a part of the running business process. In Case 2, the business action is happening in the ACM mode, based on a business decision made outside of the process business logic or rules. However, when this action is performed, the situation becomes suitable for starting a new business process (Case 3), which completes the chain of business actions and meets the OBP.

In scenario 2, a business event does not trigger any of the existing/available business processes, and it becomes necessary to act in the ACM mode (Case 4), i.e. performing unstructured actions. In the given example, there are two unstructured actions, while in real life their number may be big but still finite. For both actions, the peculiar business decisions are made. Fortunately, the second action has changed the situation and one business process was found suitable for it (Case 5). This business process triggered another business process, and only the last one completes the business task.

The PCM Example

A consultant has to participate in a meeting with their client, and travels to the client’s office. The consulting organisation has certain policies for booking tickets and hotels but cannot predict, control and direct all situations that may happen on the way. For instance, even if a consultant follows policy for an overnight stay, the available hotel may appear to be too far from the client’s office.

So, the consultant has to decide to take a taxi or bus to the office. To make this decision, the consultant has to be absolutely clear about the purpose of the trip: it may be reaching the client at a certain time when the meeting starts, or reaching the client taking into account minimal travel cost. If the latter is the purpose, the consultant will take a bus, though he will arrive late at the client’s meeting by an hour. If arrival time at the meeting is more important, then taxi is the best choice.

A much more complex situation takes place if there are several Cases at the same time. To manage these actions, it may be necessary to constantly prioritise Case goals and use change management techniques accordingly. In our example, taking a taxi to reach the meeting on time, despite the cost, is a classical ACM. However, if the consultant is very important to the client, he or she can ask them to re-schedule the meeting.

Thus, the OBP of the actions stays the same – meeting with the client, but the Case goal – getting to the office by using a pre-defined time, changes together with the Case. In the new Case, the meeting starts whenever the consultant reaches the client’s office, and the consultant can now use the bus. This is the PCM.

Thoughts to ‘Take Away’ (Conclusion)

Presented observation of different management models leads to several conclusions that should be taken into consideration when developing enterprise architecture and enterprise level solutions. The conclusions include:

• Business process is defined by its business logic; a change in the logic results in new process
• Business process is robust and inflexible. Process flexibility is a wish rather than a fact of reality. Flexibility is a an economy of solution for adapting business changes
• “Unstructured process” is oxymoron; it does not exist
• “Social BPM” is the term for management of human activities in social environment that is volatile due to human reactions and emotions; it is not constrained by predefined actions. Social aspect of business processes is always present but not necessarily beneficial to every process
• Adaptive Case Management deals with unstructured actions that the Business Process Management is not suitable for
• Purpose Case Management encapsulates BPM, SBPM, “unstructured BPM” and ACM as special, peculiar models and narrows them to the overarching business purpose or goal
• Adaptive Case Management addresses how we operate in the cases where we do not have prepared receipts (process) for actions while Purpose Case Management sets the top priority to the action purpose and constraints management. In PCM, the rational of overall business purpose prevails over the Case goals.

All business situations begin with the Cases that, if possible, transform into the processes under BPM or into unstructured actions under ACM. In the PCM, any one of the aforementioned management models can be switched into another one at any moment if the situation changes and current plan of actions becomes less effective.

(Click on the image to enlarge it)

Figure 3

The PCM is the end, the ACM and BPM are the means. The PCM sets the purpose and goal for both ACM and BPM in line with the main business needs. The PCM is a logical container for both ACM and BPM as shown on Figure 3. As a result, the PCM allows tooling capable to switch between purely unstructured/adaptive and process management techniques. However, the tooling is a special theme that deserves another article.

Acknowledgement

I would like to express my gratitude to Dave Duggal and Dr. Alexander Samarin for fruitful discussions on topics of business process and adaptive case management.

About the Author

Dr. Michael Poulin consults on enterprise and solution architecture mostly in the financial industry. His experience in this area includes several years of working in the U.K. and the United States in lead architectural roles. He specializes in building bridges between needs and capabilities in both business and technology. He is listed in the international "Who's Who of Information Technology"(2001) and writes about different aspects of service orientation being a member to OASIS SOA Technical Committee where he co-authors the latest Reference Architecture Foundation specification. He also authors a book “Ladder to SOE” and several articles published in InfoQ and Sys-con.

References

[1] BPMInstitute.org. On-line resource

[2] Clay Richardson, “Is Social BPM A Methodology, A Technology, Or Just A Lot Of Hype?”. Forrester BLOGs, Forrester.com, May, 2010. On-line resource

[3] Public Description - Adaptive Case Management. Workflow Management Coalition. On-line resource

[4] Shriyanka Hore, “Tracing the Roots of BPM to a Pin Factory”. On-line resource

[5] Michael Poulin, “Ladder to SOE” (How to Create Resourceful and Efficient Solutions for Market Changes within Business and Technology). Troubador Publishing Ltd., June, 2009

[6] Chris Adams, “Architecture of an Adaptive BPM Platform". Ultimus, June, 2010. On-line resource

[7] Dave Duggal, “Why business process is always structured?”, comments to the BLOG posted by M. Poulin. ebizQ, December, 2010. On-line resource

[8]: Keith Swenson, “Structure is in the Eye of the Beholder”. “Collaborative Planning & Social Business”, BLOG,January, 2011. On-line resource

[9] Verna Allee, “A Baker’s Dozen Principles of Value Networks”. ValueNetworks.com, January, 2011. On-line resource

[10] Peter Schooff, “Tip: A dynamic approach to case management: Craig Le Clair explains”. ebizQ, February, 2011.On-line resource

[11] Michael Poulin, "SOA Strategy and Spline Tactics". InfoQ, March, 2010.

[12] Verna Allee, “Value Networks and the true nature of collaboration”, Chapter 7. On-line resource

[13] Phil Wainewright, “Redesigning the Enterprise from the People Up”. The Connected Web, ebizQ. March, 2011. On-line resource

^[1]Combinatorial is a mathematic terms standing for “of, relating to, or involving combinations”