Here is an early discussion of S+C which eventually grew into the S+C book.

Introduction
Case managment
Standard models
Standard+Case
. Approach
. Process
. People
. Improvement
Service Response Case Management
. Methodological Tools
. Software Tools
. Taxonomy

Introduction

If you seek to break a rock, many types of stone have a crystal structure which create fracture planes: hit the rock in the right place and it drops into two; hit it in the wrong direction and it just chips.

When you attempt to categorise stuff into two or more types, if division comes easily and is clear to everyone then you have found a categorisation which reveals something about the underlying nature of the information. If it is hard to do and the results are messy and debatable, then you are trying to force an unnatural taxonomy onto the data.

Look at how we deal with responses in "classical" IT Service Management. By Responses I mean Request, Incident, Problem, Change, Event.... any "ticket" which requires a human response.

If you read the ITIL books or just about any other body of work on ITSM, it talks about following a process for dealing with the response, and that process coming from predefined models of how to deal with them. if we encounter an unknown "exception" condition, most guidance gets vague: it turns into a fuzzy cloud that says "resolve it". Problem Management is an area where almost every "ticket" is a previously unknown condition, so Problem Management guidance tends to have more information about dealing with un-defined situations, but the guidance is still generally vague outside of some formalism around root cause analysis.

I had been puzzling about how to deal with these non-standard exception conditions. This thinking re-surfaced as I read this:

[Business Process Modelling] and [Adaptive Case Management] are useful for different kinds of business situations.
Highly predictable and highly repeatable business situations are best supported with BPM.
For example signing up for cell phone service: it happens thousands of times a day, and the process is essentially fixed.
Unpredictable and unrepeatable business situations are best handled with ACM.
For example investigation of a crime will require following up on various clues, down various paths, which are not predictable before hand. The are various tests and procedures to use, but they will be called only when needed.

Case Management is about managing "cases", where each new situation must be dealt with differently. Cases are dealt with by knowledge workers, known here as case workers. Examples are medical, crime, legal, social work, audits, emergency responses, military attacks ... or many IT requests, incidents, problems and changes that don't fit a standard model.

I have become more and more convinced that approaches derived from shop-floor manufacturing methods - such as ITIL, Lean, TQM, Six Sigma - don't work so well for knowledge workers. There's too much emphasis on efficiency and not enough on effectiveness. Knowledge professionals find those approaches de-humanising. E.g. this resonated with me:

the system has to be ready when the flow comes: you need the idle resources that BPM or LEAN want to cut as waste

I'm moving away from process-oriented approaches in general, hence Tipu's informality.

Now I understand why. The natural split in user "tickets" is Standard vs Case. Current ITSM theory is good on dealing with the stuff we know about, the pre-defined standardised responses. It is not so good on dealing with unfamiliar or unknown situations: that is why we need to bring in Case Management thinking.

Case Management

But first a bit more about what Case management is.
A case is a situation to be dealt with, e.g a medical case, a legal case, a traffic accident, a crime.

• A case has a series of execution states and a goal(s), not a process, steps or a lifecycle.
• A case might still have decision gateways or milestones (Rob's opinion)
• The states are determined dynamically as the situation unfolds.
• External events can change the state.
• There are multiple options for what to do at each state. The actions are determined dynamically as the situation unfolds
• Some of those actions might be well-understood, pre-defined sub-processes
• Those actions will involve the use of resources, which the case worker chooses dynamically. The case worker assembles resources as necessary. Resources include templates, checklists, content, policy, procedures, tools, people...
• The states and actions are unpredictable
• Even the specific goals will change as the case develops
• So planning is part of execution, not (entirely) a design activity.
• Because process is loose or undefined, good policy is essential, to define the principles, rules, bounds and guidelines.
• A case has an owner and a currently assigned individual(s)
• Data is central. Case is driven by data, with process secondary (the opposite of BPM).
• Because Case is data driven, Change Management is integral to execution, to manage dynamic (and adaptive) changes to that data
• Input and output content is added as necessary (although there may be defined outputs as goals, and required inputs as policy rules)
• That content will be large volumes of unstructured data in a wide variety of formats
• Visibility and record of communications between all parties is an essential part of the data
• Enterprise architecture as input to Case is required, to model business (markets, channels, partners...), organisation, capabilities, processes, IT.
• Security is about auditability not just authentication
• A case ends, is resolved

There is an Adaptive Case Management movement within the IT community. Case Management is "Adaptive" when the ACM system changes in response to the external environment to make Case Management more successful. E.g. learning from past cases to improve stored knowledge, templates, checklists or procedures.

Some of this section draws from the ideas in Mastering the Unpredictable .

Standard models

In addition to talking about Case, we also need to discuss Standard Models, before we put them together to make Standard+Case.

ITIL talks about Models for dealing with Requests (SO2011 4.3.4.2, 4.3.5.7) and Incidents (SO2011 4.2.4.2) and Changes (ST2011 4.2.4.5), and even Problems (SO2011 4.4.4.2) though these will be rare.
Since Event Management is a process, I think you can have Event models too, though ITIL doesn't explicitly mention them.
ITIL also talks about Incident models and some Change models being Standard. In the case of Change, Standard means pre-approved but the bit we care about is that it is well understood and repeatable.

For the purposes of S+C a Standard model must be:

• assessed on risk not scale of activity. Big activities can be standardised if low risk, and small activities aren't automatically standard ones until proven to be low risk
• repeatable
• fully documented and tested: this is the "standard" bit.
• [Most of all] unambiguously defined. Before you open the standard door, it has to be agreed and clear what constitutes that type of activity... and what doesn't.

Case Management talks about "templates" as guides to how to resolve a case. These can be thought of as partial models, or models that have not yet been standardised. We could call templates "non-standard models", or stick with the ACM terminology of "templates". What do you think?.

The Standard+Case approach

The combination of Standard and Case concepts gives a complete description of ticket handling, for any sort of activity from Incidents to Changes.

• Standard tickets are predefined because they deal with a known situation. They use a standard process to deal with that situation. They can be modelled by BPM, controlled by workflow, and improved by the likes of Lean IT and ITIL.
• Case tickets present an unknown or unfamiliar situation. They rely on the knowledge, skills and professionalism of the person dealing with them. They are best dealt with by ACM, being knowledge-driven and empowering the operator to decide on suitable approaches, tools, procedures and process fragments.

Note: ITIL and Lean do fit this S+C paradigm, if you use them in the right situation: Standard responses. S+C extends them with better tools for non-Standard cases: ACM, Kanban, Knowledge Centered Support(KCS)... Better still, this S+C approach might let the ITIL and anti-ITIL camps live in peace and harmony at last.

Here is a PDF white paper about how S+C fits with the Cynefin situational model.

Process

This isn't about abandoning the "ITIL" processes: request fulfilment, incident management, problem management, change management. The only part of the process that Case will replace is the Resolution step.

See the diagram: is there a standard model for responding to this ticket? If yes, then it is a Standard ticket. If no, then we need to use Case to resolve it.

Standard+Case is about having little or no process for the Resolve step in Case tickets (so I used a fuzzy cloud not a process box), and otherwise process is pretty much unchanged.

There are any number of procedures we can use as resources and assemble as needed during Resolve. Some of those procedures one might glorify with the title of "sub-process" but I don't like that term when there is no parent process.

And there is no parent process for the Resolve step. The case changes state in response to information uncovered and external events, and actions taken. This is unpredictable.

We also have checklists of certain things that must happen in the case before it is done, and of things that should or could happen. MoSCoW. We also list input and output data artifacts that must, should or could be included.

And of course we have policy which defines principles, strategy, rules, guidelines and bounds.

That's the whole point of Case: there is no process but it can still be highly structured and controlled. We get locked into this thinking in IT that process provides controls. It is only one way and it doesn't work in unfamiliar situations.

It's not a new way of working: good knowledge workers resort to case management to deal with "hard" tickets already. But S+C formalises the non-process-driven "exceptions" into a methodology and defines rules around who and when.

The "adaptive" part of ACM is supported by our existing ITSM improvement processes, where present. Cases should be reviewed for improvements to all the Case resources, especially the templates/models and the knowledgebase.

People

Service desks have always struggled to offer challenges and growth to professional SD analysts. Gamification is a cool new solution to that issue.

S+C links up with gamification to give a career path:

• Rank the Standard models by difficulty in executing them
• Give SD analysts training in each model (maybe an hour? could be online CBT)
• Give staff a badge for being certified for a model (gamification)
• Some models we prefer they be executed by a certified staff member, some models the staff member must be certified (e.g sensitive data)
• Only the most senior, Case-certified staff members (those who have "leveled up": gamification) get to do Case Management, to deal with non-standard tickets.

Now the SD Analyst is not faced with the prospect of resetting passwords or adding people to Active Directory groups for the rest of their lives.
And the new guy doesn't get tossed into the deep end of coordinating techs and knowledge to resolve tricky cases.

Empowerment

As mentioned, much of the criticism of process-centric approaches like ITIL is that they don't empower the service worker or knowledge worker. Take this discussion (sent to me by Aprill, thanks!!)

frontline employees are give 0 power to do anything and told to resist anything other than the normal procedure. Requiring you the customer to get angry and ask for a supervisor who has the ability to do what you want.
Customers frequently have requests that are outside of the box. Some really can't be solved ... but some... easily can. My issue is with companies ...failing to serve their customers because of minor obstacles.

Standard+Case says that sufficiently skilled and experienced staff should be pre-approved to treat non-standard tickets as a Case (to work out how to solve it based on the situation at hand), whilst providing them with good tools, access to knowledge, and clear policies and guidelines. That's empowerment.

Improvement

Standard+Case creates a self-adapting system so that process stays current with some of the changes in our environment by creating and capturing new workflows for new types of ticket, e.g provisioning users to a previously unknown system, resetting a new type of handheld device.

We standardise our process models for various ticket types. As the world changes, suddenly we get exceptions. Case management deals with the exceptions. The review process captures repeat exceptions and creates standardised process models which we feed back into the knowledgebase.

Service Response Case Management

So now we can build a picture of what we need to do and have in order to perform Case Management in the context of service management responses, i.e. the case-oriented half of the Standard+Case approach. Let's call that Service Response Case Management (SRCM).
Here is my own in-development working definition of what SRCM looks like, what I think they are - I'm making this up as I go:

• Policy (principles, rules , bounds). This is #1, and is huge. If you empower people you MUST give them rules and bounds.
  Great analogy from Mastering the Unpredictable: hard rules are the guard-rails on the road, soft rules are the painted white lines.
• The system should enforce as many of the hard rules as possible, but only warn on soft rules.
• Knowledge: tools to provide access to as much request-fulfilling and problem-solving information as possible
• Tools to support collaboration become much more important in Case: people need to work together to find answers quickly when there are no Standard answers
• Standard and Case ticket tracking must be integral, one tool. Case is a branch, not an independent system. See Process.
• Support emergent process: allow flexibility, the ability to create and change dynamic procedure on the fly
• Empower our expert staff to act as they see fit (expert=people have to earn and keep the right). This changes management, RACI, HR, security ...
• Manage varying levels of skill, e.g through certification and gamification
• Value and study diversity of approach.
• Provide and constantly develop:
  • templates: standard tasks, documents we expect to see, data we want.
  • more granular standard tasks: "mini-processes" that can be assembled by workers as required e.g. root cause analysis, forming a war room, running a supplier teleconference...
  • checklists of tasks and other deliverables: the flow may vary but there are often sets of outputs we require before the case is done.
  • support for (constant) planning as well as doing
  • knowledgebase
  • content management, and change management of that content, are important
  • providing and recording communication between all parties are important (Note: this means social tools are only useful if we capture a record)
  • support and automate the repeatable bits e.g. calculations
  • archives and records management
    

  These resources should embed policy rules, guidelines and bounds (business, legal, marketing, CRM...).
  They need access controls and audit trails to mitigate the freedom we give the case workers.

• Deadlines, reminders and calendaring become much more important in Case than in Standard processing
• Monitor and manage to time and outputs not to actions and sequence
• Review individual cases for improvements to resources (as compared to improvements to processes in a BPM model)
• Review and improve knowledge. KCS has useful concepts here for rating knowledge and counting usage.

Every SRCM ticket has:

• just like any ticket: an owner, a record, a defined work product, a response SLT
• can have workflow tasks like a Standard ticket, though tasks must be dynamically added and assigned as the case evolves (and that has to be easy enough for the knowledge workers to do themselves)

Methodological Tools

Knowledge Centered Support is almost certainly going to prove very useful for SRCM - more on this soon

Checklists will play an essential part in making sure we know what must, should, or could happen before the case is over, and must, should or could be input or output.

Hence the MoSCoW technique will also be used.

Root Cause Analysis techniques such as Ishikawa and Kepner Tregoe

Kanban for managing case workload???

Software Tools

Case is about the approach people use, not the tools. Don't seek a technical fix to a non-technical requirement. Current tools will often be good enough.

Advanced Case Management, rather than being a new technology, is actually just a new way of thinking about how the technology we use integrates with the services we provide.
Social Solutions

I dislike one aspect of the Mastering the Unpredictable book: it paints an idealised tool nirvana as an essential condition for successful Case. I don't buy it. I'm not going to decline to adopt a better way because my tool doesn't support it. I'll either (a) use the current too for managing requests and branch to a different tool for the Case Management bit or (b) find a way to manage Cases in the existing tool even if it wasn't designed for it and extend it where necessary or (c) set the vendors salivating by looking for a new tool with both Case and BPM capabilities.

My initial belief is that current ticketing tools will be fine. If Case requires advanced knowledge management capabilities, many of us have resorted to a separate knowledge management tool anyway because the ticketing tools suck so badly at KM. (Same issue when you try to do KCS, for example)

Nevertheless we'll list some tools here useful for Service CM:

• Can anyone suggest ticketing tools that have dynamic user-configured workflow, and powerful unstructured KM?
• Apparently IBM have a Case Manager tool, I believe it is BELA
• Floxxium has been suggested. I don't know anything about it
• CaseNet, web-based
• e-Case

The ideal SRCM tool provides:

• A Case status within requests, incidents, problems, changes
• Define goals
• User (not admin or programmer) to dynamically create and change workflow
• Attach rich content or link ticket to content management system objects
• Set calendar deadlines and reminders against ticket and tasks
• Apply a template(s) when we change to Case status not when the ticket is created
• Template to set goals, create workflow, attach rich content
• Assign ticket and tasks to owners. Link and manage other participants
• Capture and store all communications
• Provide knowledge management or link ticket to objects in knowledge management system
• KCS-compliant capabilities e.g. to rank and improve knowledge
• Create an audit trail of the ticket history
• Embed business rules (hard) and guidelines (soft) in functionality
• Create a digitally signed archive package on close

I don't think you will find many of those. Don't over-invest in trying to create one until the ACM practice is mature.

Taxonomy

I believe ITIL's Incident vs Request is not a useful categorisation of user service. I argued long ago on the IT Skeptic blog that Incident vs Request is wrong. To me an Incident is a sub-type of Request (along with a dozen or so other sub-types). This is not a natural fracture line.

We don't need to debate here whether I'm right or not in that assertion: it is an example of where I think something doesn't split cleanly and is in fact distracting us from the best way to split service desk response (as an example of responses). Even if you want to maintain the Incident-Request division, Standard+Case is useful and important to you.

S+C suggests a Response taxonomy that differs from ITIL Request in several ways:

• Responses are a generic entity type which is further broken down into types of response, which are child objects inheriting properties of the parent.
• Responses cover Request, Incident, Problem, Change, Event.... any "ticket" which requires a human response
• Incident is one type of Response, not a totally separate "bucket"
• ITIL says all requests should have a model (although it also says "some" in places). S+C says only Standard requests do.
• When I remember to, I call them Response rather than Request to make the distinction

Standard+Case suggests a new taxonomy in the sense of categorising tickets, but it is not displacing the categorisation by ticket type, it is at right angles to it: I'm talking about a categorisation of how we deal with tickets not classify them

Any one of the classes of Response that we use in order to decide WHAT action is required, can then be categorised by HOW we are going to deal with it: Standard process or Case management. For example many Provisioning (Access) requests will be Standard, but occasionally they will be unusual and need to be dealt with as a Case. Conversely perhaps fewer requests for Help will be Standard, and many will need individual attention as a Case.

None of these categorisations should be overly visible to the user. We don't need to tell them that "I am going to handle that as an Incident, in fact a Standard Incident". As far as users are concerned they are all Requests or Responses or Tickets or whatever you want to call them. (Occasionally we do need to explain why we are handling this request different to his last one because it is a different type)