• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

Case vs. Process is a matter of scope, innovation and maturity

10 December 2012 by Robert Falkowitz 6 Comments

First, a reminder about why processes are used

Fig. 1: Frederick W. Taylor

Perhaps the most important contribution of ITIL V2 to the realm of IT service management was its emphasis on working according to well defined processes. This contribution has undoubted merits, although its unthinking, blanket adoption has come under considerable criticism. Be that as it may, the fundamental argument of working according to well defined processes is four-fold:

  • attempting to work in the same way for each instance of an activity allows that activity to be measured each time, and allows for comparisons and analysis of those measurements
  • working in a process-oriented way enables the principle of perfecting via practice
  • perfecting an activity makes it more effective, more efficient and more predictable
  • the measurements of processes may be used to determine in what ways it may be improved.

Working according to processes implements a vision often described as “Taylorism” (see Taylor, Principles of Scientific Management, 1911). Frederick W. Taylor’s great contribution to the refinement of the industrial revolution was in methods for optimizing manual labor. ITIL®, as well as many other frameworks, has adapted Taylor’s approach to the work of processes used to manage services.

What is the problem with processes?

A well defined process, such as might be delivered in a business process management context, is highly predictable. There is a predictable order to its activities. Each activity has a predictable set of inputs and outputs. The resources to be used for each activities are defined in advance. For many types of work, this approach is perfectly applicable. And for many other types of work, it is not.

We have all faced the frustration of trying to get a service from someone who is following an approved procedure, but that procedure had simply not taken into account our particular need.

Processes are agile up to a point. The so-called “dynamic business process” allows for data-driven decisions that introduce considerable flexibility into formal process definitions. But they do have limits. Anyone who has tried to follow a four page, 8 column process flow document, which contains more decisions than tasks, knows that such theoretical models can hardly work in our daily reality. What I call “spaghetti processes” can be so fragile that they often fail.

Adaptive Case Management to the rescue

Adaptive Case Management is an approach to doing work that takes into account the unpredictability of the inputs and outputs from activities and the unpredictable need for and availability of resources. It shares with process-oriented work the definition of specific goals for the work to accomplish. For example, the goals of problem management may be defined as reducing the impact of incidents by eliminating their causes or by finding effective work-arounds to resolve the incidents whose causes are not eliminated. Whether one attempts to achieve those goals via a formal process or via case work, they remain the same.

In order to be effective, Adaptive Case Management (ACM) requires the concept of a “case”, a container into which all the information and  knowledge used for resolving that case may be held. The method by which that knowledge is acquired and the goals achieved unfold as work on the case progresses. This is because we cannot know in advance what information will surface, at what time, and how it will need to be handled.

Fig. 2: Peter F. Drucker

As such, ACM is a formalism that implements a vision espoused by Peter F. Drucker (see, in particular, The Age of Discontinuity, 1969). For Drucker, the work of advanced economies is essentially “knowledge work”, performed by “knowledge workers.”

These knowledge workers, then, are the people who collaborate to resolve the case and reach the particular goals of the activity. As you might expect, knowledge workers in IT, among other disciplines, are heavily dependent on tools that help retrieve the data, information and knowledge required, as well as tools to handle the cases themselves and to work according to the various patterns that have identified that help resolve cases. As with processes, ACM is also subject to various constraints, coming from the legislation in vigor, industry practices and internal company policies.

ACM, in spite of its relative youth as an approach, already has a rich literature and supporting media and professional associations to foster its development. See, for example, Keith Swenson et. al., Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done, 2010 and Swenson et. al.,Taming the Unpredictable Real World Adaptive Case Management: Case Studies and Practical Guidance, 2011. What has become an annual web event, ACMLive (acmlive.tv), presents a combination of primers, theory and case studies. The Workflow Management Coalition (www.wfmc.org) is a rich source of information, events and persons interested in ACM. Numerous blogs and social groups, such as LinkedIn’s Adaptive Case Management, populate the web. Indeed, the concept of case management is now making its way into the IT service management universe.

How do we position processes and cases?

An early view of ACM considered it to be a reaction to the frustrations with Business Process Management, whose rigid implementation in process automation tools led to failures in more complex types of work. While this view of ACM is too narrow, it has nonetheless led some to think in terms of a binary opposition of processes and cases. Indeed, the basic works on ACM all take examples of different types of work, classifying them as either appropriate to execution via processes or execution as cases.

Figure 3
Fig. 3: Knowledge work (exemplified by ACM) and automated processes are on a continuum.

In my view, this polarization does not represent the reality of how we work. It fails to take into account three aspects of work: the level of detail at which it is analyzed, the degree to which it is innovative and the evolution of that type of work through time. By taking these perspectives into account, we see that cases and processes are more like poles in a continuum of practices, rather than being a binary opposition.

The more work tends to be innovative, the more it tends toward the type of knowledge work managed with ACM. The more that work is commonplace and routine, the more can it be performed as a process. Indeed, the most routine tasks are the most amenable to automation. Similarly, the more we look at work from a high level perspective, the more is it amenable to be described in process terms. However, when we drill down to the details of how to perform that work, it often is closer to ACM. (To be sure, work is not process-oriented just because it is viewed at a high level.) Some examples of these principles are apposite.

Example 1: The emergency rescue mission

The case of a search and rescue mission is cited by case management analysts as an excellent example of knowledge work that is not amenable to being managed as a process (see Swenson, op. cit., 2010). However, the diagram of this activity in Fig. 4 shows clearly that the full life cycle of the rescue mission can indeed be described as a process. Only the planning of the rescue, and perhaps its execution, are likely to be different in every case. When the ACM analysts describe the case, they focus only on these detailed aspects, which require all the knowledge that the mission members can muster.

Figure 4
Fig. 4: High level view of an emergency rescue process

What about the scale from innovative to commonplace? In the rescue case study commonly cited, the head of the rescue mission was called upon to perform knowledge work when he discovered that the helicopter to be used could not carry all the people and equipment as planned. Some people might say that this is not an example of using knowledge; it is an example of inexperience and a failure to maintain control over the available “configuration items.” Be that as it may, the next time the same team was called to perform such a rescue, it probably did not make the same mistake. Indeed, a rescue organization with a broader geographical scope and one specializing in rescues is likely to learn from its own experience and from the experience of other teams, such that each succeeding rescue is done in a more and more systematic, process-like way. In time, such teams are likely to acquire more specialized tools that are better adapted to the rescue work.

Example 2: Check-out at a supermarket

A customer check-out at a supermarket is cited by some case management analysts as an example of work that could hardly be more routine and that is an excellent example of work that can be managed as a process (again, Swenson, ibid.). Curiously, the same analysts dismiss the unpredictable aspects of finding and scanning price labels, calling this a “micro-level” that is not worthy of discussion. Granted that operating a cash register is less exciting than flying helicopters to rescue helpless people, but that does not mean unpredictable events, requiring a certain level of knowledge to manage, never occur. Ask this of any clerk who has had to face the problem of a dishonest customer trying to cheat the store. A friend of my daughter had exactly this problem last year. A group of crooks developed an innovative way to confuse the clerks and get back change for money they never handed to the clerks. Some clerks lost money, but others were quick-witted enough to recognize the scam. Finally, the store management generalized the practices of those latter clerks, adapting the check-out process to protect the clerks from the crooks.

Figure 5
Fig. 5: Supermarket checkout process

Example 3: Supporting a user calling the service center

One of the most common examples of knowledge work given by the proponents of adaptive case management is the work of the call center agent. Every call from a customer is different. Every way of handling the call is different. They say that the way in which the call must be handled cannot be predicted in advance.

And yet, there is no organization that resembles a call center quite as much as a service desk, and no knowledge worker more like a call center agent than a service desk agent. Many IT organizations would agree that they have successfully implemented a variety of processes that dictate the way in which the service desk agents should work. There are processes for handling incidents, for complaints, for service requests and so forth. Why do certain ACM advocates ignore this reality? There are several elements to the answer.

First of all, some advocates of case management have a tendency to think of a process in terms of only those tasks that can be automated. They focus on those activities susceptible to automation and ignore the full life cycle of the case. Since we cannot fully automate the support of a user during a telephone call, they draw the conclusion that the work cannot be done in a process-oriented way. As a corollary to this, they criticize the attempts to reduce customer support work to a series of scripts—scripts which cannot possibly predict and handle all support situations. Secondly, they focus on very detailed aspects of the service desk agent’s work rather than looking at the broader context of the work. Most everyone is likely to agree that certain incidents, for example, cannot be resolved by applying a pre-defined model. They might require a diagnosis whose steps are not completely predictable in advance. Much of incident diagnosis is pure knowledge work. But that does not mean we should ignore the more routine steps of logging calls, classifying incidents, providing post-resolution analysis and clean-up and closing the incident.

Example 4: IT problem management

One could hardly name a better example of knowledge work than resolving problems. Problems are unpredictable. We cannot know in advance how they will be solved (else they wouldn’t need to be handled as problems!). The steps required to find a problem’s causes often emerge during the analysis. But again, many IT organizations have adopted a problem management process, with a clear set of pre-defined steps to follow, no matter what the particular problem might be.

Figure 6
Fig. 6: Problem management process

Even the investigation and diagnosis of a problem is not done starting from a blank slate. The mature problem manager has a full tool kit of techniques to apply to structure and move forward the diagnostic work by the subject matter experts. Many of these techniques are themselves highly structured and process-like.

Signor Pareto meets the Knowledge Worker

Figure 7
Fig. 7: Over time, continual improvement transforms knowledge work into routine processes.

The ACM proponents make a strong case that the special characteristics of knowledge work require an approach that is difficult to automate. This might be true at an early moment in the history of a certain type of work in a certain organization. However, we should take a dynamic view of the evolution of knowledge work. Each case that is solved becomes a source of knowledge that may be applicable to other cases. As the diversity of cases becomes known and as that knowledge accumulates, it becomes possible to manage certain types of cases in a routine way. This is a standard approach in IT departments, where engineers and developers are called upon to solve problems and resolve particularly difficult incidents, but they hand over to the operations staff the know-how required to resolve similar incidents, should they recur. With the constant changes in technology and the increasing complexity of systems, there will always be cases for knowledge workers to resolve. But, one objective of continual improvement is to make such cases easier to resolve in the future, handling them in a more routine, process-oriented way. This principle is well known to IT service management practitioners, who create models for handling known types of changes, incidents, events, configurations, etc. The routine, low risk change may be handled as a standard change. Continual improvement corresponds to moving along the scale from the innovative to the commonplace. At any moment in the history of handling a certain type of knowledge work in an organization, we should always be trying to address a certain percentage of those cases in a more routine way, whereas the remaining cases represent the core of purer knowledge work. (The concept of cases developing into standard process handling was already developed by Rob England.)

Summary
Case vs. Process is a matter of scope, innovation and maturity
Article Name
Case vs. Process is a matter of scope, innovation and maturity
Description
Formal processes and adaptive case management are not really fundamentally different ways of working. They belong to a gradient based on scope, innovation and maturity
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Service Management Tagged With: acm, adaptive case management, knowledge management, knowledge work, knowledge workers, process definition, processes

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Trackbacks

  1. Patterns of incident handling | This view of service management… says:
    26 December 2012 at 11:04

    […] have discussed elsewhere in these columns the relationship between process-oriented work and adaptive case management. This framework will help us to refine the understanding of how incidents may best be handled. […]

    Reply
  2. What might availability management be? | This view of service management...This view of service management… says:
    12 September 2015 at 17:07

    […] be executed in a process-oriented way. Other activities might be more appropriately handled via case management, such as I have described elsewhere. Depending on the maturity of the service provider […]

    Reply
  3. Minimum viable process | This view of service management...This view of service management… says:
    7 February 2016 at 10:05

    […] variety of domains, including much of the work of managing services. As I have already described the use of adaptive case management for service management, I will not go into greater detail […]

    Reply
  4. Minimum viable process | This view of service management... says:
    23 December 2017 at 17:27

    […] variety of domains, including much of the work of managing services. As I have already described the use of adaptive case management for service management, I will not go into greater detail […]

    Reply
  5. Patterns of incident handling | This view of service management... says:
    24 December 2017 at 14:51

    […] have discussed elsewhere in these columns the relationship between process-oriented work and adaptive case management. This framework will help us to refine the understanding of how incidents may best be handled. […]

    Reply
  6. What might availability management be? | This view of service management... says:
    25 December 2017 at 21:28

    […] be executed in a process-oriented way. Other activities might be more appropriately handled via case management, such as I have described elsewhere. Depending on the maturity of the service provider […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

kanban training service manager manifesto for software development Incident Management flow waste impact agile automation change management risk ITIL problem kanban knowledge management resource liquidity incident management tools process definition leadership lead time tools statistical control chart knowledge work kanban board cause urgency context switching histogram rigidity bias process metrics incident service management tools change control manifesto value adaptive case management priority value stream lean
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}