The IT Skeptic - Comments for "The Standard+Case approach: applying Case Management to ITSM"

some assembly required

skeptic — Thu, 16 Aug 2012 20:00:00 +0000

Yes there are any number of procedures we can use as resources and assemble as needed. 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. 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.

recall also that we are only "abandoning" process for the Resolve step. All our receive, record, diagnose and categorise steps are unchanged before we get to Resolve.

No process?

beach — Thu, 16 Aug 2012 19:06:05 +0000

Hmm, again. I guess I still have a problem with "no process" although we might just be wrestling with an issue of granularity in our definitions. I have long been in the data networking business (ugh, even before internet). Working for the DoD, we were highly reliant on technical control facilities to troubleshoot transmission media failures. One of the worst things that can happen is when young technical controllers (on both ends of the circuit) would start throwing in loopbacks all over the place, sometimes introducing more errors, sometimes restoring service before they knew what was wrong, i.e., we dreaded the number of "cleared while testing" reports we received.

In many case-based activities, there are still steps. Almost certainly, you want to diagnose problems before you start throwing fixes into the system. Depending on the type of incident that you are addressing, the diagnosis process may be more or less structured. Under change management, or certain SLAs, the service provider may need to include steps that ensure impacted parties are notified of outages or changes.

I have neither been a lawyer or medical Dr. But my experience is that even doctors and lawyers will have some degree of standardized routine so they can efficiently get down to the actual management of the case. Granted, the actual diagnostic and resolution processes may be more or less, perhaps even completely unstructured. But that is not my personal experience. All a process is is some type of input, transformation and output. I certainly will not argue the fact that the transformation may be more or less structure (cloudlike) and that we err when we try to over-structure an inherently unstructured activity. But I just hate to throw the baby out with the bath (and I think there is at least a tiny baby that can be spared by maintaining a some degree of a process orientation.

technical solutions to non-technical challenges

skeptic — Tue, 14 Aug 2012 09:01:27 +0000

yes i agree we can leverage existing tools for a long way into this.

Thanks for the reference to that paper. I only just got around to reading it. it does contain similar ideas and i got some new ones. Unfortunately, just like the "Adaptive Case Management" book, it looks to technical solutions to non-technical challenges: the broader behaviours and practices. Tools help they don't solve.

Also the Cap Gemini paper seems unable to let go of a process-centric perspective: it seems to see Case as a different kind of process, not a non-process. I guess if you want to use existing process tools you have to see it that way, but I found it uncomfortable.

A great read though. thanks again.

splits neatly

skeptic — Sun, 12 Aug 2012 21:58:56 +0000

"Event" of course means something more narrow to this audience.

But if you mash requests (including incidents), problems, RFCs, and operational events together as all "tickets" to be dealt with, then yes that whole mashup splits neatly into Standard+Case.

You remind me that Event is a ticket that can also be dealt with by Standard+Case.

we abandon process completely

skeptic — Sun, 12 Aug 2012 21:51:00 +0000

I'm not sure exactly where your thinking is at John, and I know you think deeply about this, having read a draft of your new book :)

At a crude level (where I always operate) we abandon process completely for the resolution phase of a Case ticket - one where by definition there is no predefined model - because:

A case has a series of execution states and a goal(s), not a process, steps or a lifecycle.
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
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.

We may choose to dynamically assemble process fragments at runtime but that's not the same as having a process.

We use the same process for both Standard and Case responses for all steps except Resolution

So i think it is fair to say Standard+Case is about having no process at all for the Resolve step in Case tickets (so I used a fuzzy cloud not a process box), and otherwise process is pretty much unchanged.

Some thoughts from a non-purist

beach — Sun, 12 Aug 2012 21:19:29 +0000

I have always wrestled with the degree of granularity used in defining ITIL processes. Increased granularity provides more detail and nuance, but it risks information overload and sometimes can result in a check list mentality where value gets lost in the details.

I am a firm advocate of the KISS principle, at least in defining local practices -- especially where resource, generally human, constraints exist. I want to be careful, yet efficient, in defining roles and responsibilities... and processes.

My thinking on this is that I have wanted effective tools for tracking workload to individuals. Since the technical specialists in my shop were not often dedicated to servicing requests, incidents, problems, changes, etc. I wanted a common tool for managing these disparate processes. We tried to develop our own, but at the time I left, the ticketing system remained a work in progress.

In my view, everything we worked on was an "event." We used different methods or processes for handling each type of event. Thus, our network monitoring system might fire off an "incident event" and the change management system might fire off a "change event." We would then worked with the technical analysts to determine the best approach to prioritizing all of the events to which he or she was assigned.

We did not have SOA and our ticketing system leaned toward a case management approach. But we were starting to collect data on events over time that would have permitted some more structured processing of selected types of events.

I guess in conclusion, I see the value in distinguishing between standard and case events.

Process orientation

beach — Sun, 12 Aug 2012 21:02:39 +0000

Academics are likely the worst about splitting hairs and defining terms, however... I am not sure that the term meta-process is required. In the operations management literature, processes are recognized as being more structured versus less structured. Hence a less structured process is still a process. I do not think that we need to discard a process orientation (at least not completely) to process cases.

I wonder if our emphasize on BPM and SOA have distorted some of the long term thinking about and learning about process management.

Meta-Process

avallesalas — Tue, 07 Aug 2012 17:46:33 +0000

Just to add a few thoughts on this thread about S+C for ITSM.

First of all, I had an email conversation with Rob talking about the concept of "Standard Incident" and the need to push the concept of problem management. He convinced me that in the real world, there is plenty of standard incidents, managed by people at the service desk.

Yes, that is true. But as this blog post says, probably a "standard incident" is the same concept as a known error (it's a problem, it has a known workaround. No, I don't agree with ITIL on the point that a KE must have a known root cause).

The other thought I wanted to share here is the idea of Meta-Process. I don't know if we can freely use that word, but I will act as if we can. When I explain to students the need for process design and we are talking about incident management or problem management, it's quite easy if you have an experienced audience, that they end arguing that it is impossible to formalize how do they solve the incidents. My answer to this situation (before I learnt about ACM from Charlie Betz and from Rob) was to explain them that what we can do is to define a meta-process, something like an envelope.

Let me explain: independently of what kind of service request you receive, you will need to register, assess, prioritize and classify it. You can standardize the steps needed to do this, you can define a process as BPM says here.

Then you arrive to the phase where you must "attend the request"; if it is what ITIL calls a "service request" (a standard) then you must follow the predefined steps to process the request (for example, if you are asked to increase mail quota, you follow specific steps to approve and execute the quota increase).

On the other hand, if you receive a non-standard request (an incident in ITIL words, a Case here) then... almost 100% of IT shops have defined a box in their process diagram that says "investigate & diagnosis" or "incident resolution". THAT is ACM. We have this box because we can not describe predefined steps to investigate, diagnose and solve an incident.

Then, once we have found and may be applied a solution, we continue with a standard process, usuaally a 2 steps closing model (solve and close).

So we have standard process for almost all the incident management, except for the important thing that is ACM, and this is what I call Meta-Process... the envelope of a case is an incident management process. And it happens exactly the same for Problem Management, where we can prepare an standard envelope, but the letter is handwritten and different each time.

The really big value that this thread is creating is that we are opening the "investigate & diagnose" or the "resolve incident" box and trying to find methods, techniques, models to apply here. This is really important because from a Lean point of view the only activities that adds customer value to an incident management process are diagnosis and solution... all the rest is NVA or NNVA (non value added or needed non value added), waste (from the customer point of view).

Well.. I hope this can add more light to this fascinating and really game-changer thread. Thanks Rob!

From the outside-in it remains a request for service

ianclayton — Sun, 05 Aug 2012 01:45:08 +0000

Roy

Accepted. There is a clear difference in the style and perhaps approach between a complaint/problem/issue/incident and the rest! But, from a customer perspective why do I care? Its a request for service. Sometimes, as a customer, I don't even know I have a problem sometimes. I've entered the Apple store numerous times with what seemed a simple question, only to uncover a potential issue resolved by a patch or update.

This is why I have always positioned an incident or whatever you want to call something that is out of the norm (not delivered or operating as expected) as a service request, type equals... it also vastly simplifies the provider side reporting, putting all causes for internal work effort in one handy container.

USMBOK addresses service request management

ianclayton — Sun, 05 Aug 2012 01:26:05 +0000

Skep

The USMBOk was mentioned earlier in this thread and as I'm sure you recall it is ALL about how service requests are managed - both those responded to by humans and those by automation (service transaction engine). As some have indicated, it makes no sense to separate incidents from requests and the USMBOK has always regarded the former as a type of request. If you check again you will see at least 8 types of request mentioned.

In other writings we explain how a request must be wrapped in a customer engagement strategy to help manage the 4Es of expectation, the service (request) encounter, service experience and emotional genie. As for your comment about Case Management and the USMBOK - if you are introducing customer dynamics, what the USMBOK terms the consumer scenario, you are starting to address matters (finally) from the outside-in.

Service requests require an associated consumer scenario plus optional customer experience/engagement management concepts. Case management is a mature discussion and much of its approach was considered when developing the USMBOK - and encapsulated in the scenario catalog concept. This allows the service provider and often the service support function to identify specific scenario, match them in the response catalog, and externalize the dynamic aspects of service request management to allow for a fixed, repeatable, and standard operating procedure backbone...

It also describes a service request 'pathway' comprised of both a consumer and provider (perspective) pathway, allowing for different routes, sets of interactions and moments of truth based upon variations in the consumer scenario.

I'm looking forward to exchanging views on all this at itSMF's LeadIT12 on the Gold Coast.

There is of course a

skeptic — Mon, 30 Jul 2012 20:50:23 +0000

There is of course a difference. Great q, I blogged the answer

Would you then agree...

Roy Atkinson — Mon, 30 Jul 2012 13:27:58 +0000

Rob - Would you agree that there's no difference between walking into a store and buying something (perhaps asking a clerk where the item is located), and returning an item that is broken or which doesn't fit?

incidents are requests

skeptic — Tue, 10 Jul 2012 12:31:00 +0000

The only grounds I can see for separating incidents and requests is where one adopts ITIL's wacko concept of an incident without a user (or even a service interruption). To me an incident is a failure or perceived failure to deliver the expected service levels to a user or users. and the sole purposes of incident management is to restore the service or get the user to agree it cannot be restored.Pure and simple

if one accepts that definition then an incident is clearly a request to restore service .

Lots of request classes have a unique workflow and lots of classes are unplanned. There is nothing special about incidents.

SR vs INC

Niels — Mon, 09 Jul 2012 21:47:26 +0000

To throw a little bit of oil on the Service request vs Incident fire, I do think there is a difference between the two that justify different processes (or different handling).

The key distinction I typically make is that Service Requests can and should be planned, and can sometimes even be forecasted (frequency or period). Service Requests that are similar, could be grouped for more efficient execution. E.g. some companies still assign network folders manually, instead of handling each request individually, these could be optimized saying that those activities are done twice a week (e.g. monday and thursday). Focus is on planned, efficienty and timely implementation.

Incidents occur ad-hoc and should always be resolved ASAP, as it is impacting the end-user from using an already existing service.

This nature makes it a candidate for separating them.

However, any approach is fine with me: My motto is 'to make a clear decision, communicate it, and ensure you act upon it'. Too often these decisions are not taken, or not implemented, leaving all layers in the organization confused and acting differently.

the topic

skeptic — Sat, 07 Jul 2012 02:02:24 +0000

I'm not sure what's proprietary about Tipu, given that it is in the public domain under a full-reuse commercial Creative Commons license.

I'm also not sure what this discussion of USMBOK content has to the application of Case Management to IT, which is the topic of this thread

Lessons from healthcare case management?

ianclayton — Fri, 06 Jul 2012 21:56:15 +0000

Just a quick comment on ACM - and its 'recent discovery' here. Its a good thing. I'd urge my fellow IT professionals reading this blog to check out other service provider 'best practice', especially healthcare, which has a long history of 'case management' thinking.

At the core of ACM thinking and use is the recognition that the responder to a situation - a 'case (?)' may not have all the information at hand at the outset, or even during a response. The responder, or agent, must be able to adapt to circumstances, interactions, and additional information, and leverage and extend existing knowledge.

The procedure used in the response must be able to be adapted to the specific conditions encountered, and therefore prevailing governance (who is allowed to do what and under what circumstances) is a critical factor.

It was my experience working with healthcare case managers, combined with the thinking of luminaries such as Graban, Shaw, and Bitner, that led to how the USMBOK addresses the key discussion of service support and service request management and how in each practitioner guide we discuss the consumer scenario and need to focus on how key interactions are handled.

For ACM to succeed it must respect the DNA of a service request response, which include both a consumer and provider view - pathways, as suggested in the latest Lean and customer experience management writings. Else it will provide yet another inside-out set of thinking and methods.

These are just the type of conversations and discussions the service management profession should be having to ensure we are aware of and exploiting the very best (proven) guidance we can. Trying to make ITIL fit, or to argue that one framework is superior to another is a total waste of everyone's time.

ACM is yet another example of why we can't stand still when using frameworks such as ITIL and COBIT. We have been told for years to 'adopt and adapt' any guidance to make sure it works for a given situation. ACM reminds us we need to take an 'adaptive service management' approach...

And... posting new finds in the archeological dig of concepts and methods helpful to service management is a valuable service. Thanks Charlie and Skep for finding, reminding and sharing.

Its not "my" outside-in...

ianclayton — Fri, 06 Jul 2012 21:31:18 +0000

Skep - you've had a copy of the 'proprietary' USMBOK in one form or another for a few years now. Its not alone in being the big 'P', count COBIT, ITIL, PRM-IT, ASL, even TIPU - its down to the author to decide how folks can access and use and at what cost.

The USMBOK approach to the humble service request has not changed since the first edition - an incident is one type of service request. It also lists seven other common types and emphasizes the discipline of 'service request management', linking a request to a service portal, service catalog, and more importantly a service request catalog.

The latest edition added the previous 'secret sauce' of outside-in thinking, completing the connection between a consumer scenario, the service request, its journey across the provider organization (pathway), moments of truth, workflow concepts, and 'cost of (service) request'.

Inside-out thinking focuses on the categorization and cataloging of requests. Outside-in thinking focuses on the cataloging of consumer scenarios and ensuring an appropriate response in the form of a service request pathway. If you are designing any of these common components of a service system without the scenario you are guessing - period.

The latest USMBOK also discusses in some detail the true role of service support (pillars of support) in enabling a customer engagement strategy exploiting social media, and how break/fix, helping hand, service recovery and complains and compliments elements are combined.... and how support can help design a better 'experience' and focus the provider efforts on aspects of the request response that has most effect on customer satisfaction.

By the way, its not my outside-in - wish I was that smart. Drucker, Normann, Levitt and Towers beat me to it and Patricia Seybold writes so much better than me on the topic! I prefer to say I am pioneering its application to the challenges of a service business and service provider organization - such as IT.

Let me know if you want to refresh your exe version of the USMBOK. See you at leadIT12.

Keeping costs in check by leveraging BPM methods for ACM

MG_deB — Sat, 23 Jun 2012 09:09:00 +0000

I can see some parallels between your blogpost and an article I read advising to use existing BPM tools to give form to Case Management (via Slideshare: http://www.slideshare.net/capgemini/case-management-managing-chaos-unstr...).
Especially when starting with the cut between Standard and Case it seems appropriate to use the tools that staff already know and use. They'll be able to get their heads around the notion of Standard versus Case without the burden of having to learn how to use a new tool. They'll get to adapt their existing tool for as long as it is useful. Only after modifying it to the breaking point should a new tool be implemented.
My guess is that many tools will be able to accommodate such constructs.

Service empathy

Mark Smalley — Sat, 23 Jun 2012 07:51:52 +0000

I like the standard versus case distinction and, although you recognize that "none of these categorisations should be overly visible to the user", would add that while a supplier has a process for dealing with standard requests, the poor old user often isn't aware of the fact that there's a standard solution for his/her needs. I (user) think I've got a case but you realize it's a standard request. In this situation I want to be treated differently than when I specifically ask for a standard solution. Therefore I'd add an optional pre-process that I've given a very concise name: 'Listen to the user, show that you're taking him/her seriously by pausing for a moment to think profoundly, then say "This will do the job mate"'.
Conversely, I might mistakenly ask for a standard solution while I actual need case-treatment. To ensure customer satisfaction, it's worthwhile applying judgement and assessing my level of competence then asking a couple of questions to verify that I'm on the right track. Preferably not leaving me with the impression that you think I'm an idiot. Which I may actually be. I might even be a case.
So there's a preliminary assessment/assurance/advice step. AAA, that's catchy...

not a new way of working

skeptic — Fri, 22 Jun 2012 22:58:07 +0000

It's not a new way of working but it formalises the non-process-driven "exceptions" into a methodology and defines rules around who and when.

Even before it gets escalated to Level 2, such a case is often handed to the more experienced level 1 analyst to nut out what to do with it, i.e. to develop the case approach.