Service Portfolio and Service Catalog: Zombie Killers

I smell your abandoned Sharepoint site from here...

I read on CA on Service Management blog a funny post by Dave Wilt remarking how important is continuous Service Catalog and Service Portfolio management, and the need to keep them up to date to avoid what Dave Wilt calls “zombies” in our organizations: those IT assets or CIs no longer needed that wander around our datacenters. According to Dave’s definition of “zombie” in an organization:

Where are the zombies in your enterprise?  How about virtual machines that were quickly and easily spun up but are no longer needed or used?  SharePoint sites?  File shares, intranet pages, user desktop software?  User accounts? How about entire business or IT services?

Dave Wilt thinks of Service Catalog as a weapon to fight zombies, with a closed-loop approach on provisioning using a Service Catalog. One of the points he insists the most is “cost transparency”, that means: whether or not a formal chargeback model for IT services provisioning exists, users that request a service (and their managers) must be informed of the cost of delivering that service through time. It might be tough for some IT shops who are just starting to deal with their very first Service Catalog to think of setting up Financial Management, but I believe that, unlike IT jargon, money is a universal language that everyone in the company will understand.

Nobody wants to be expensive; nobody wants their department to top the Big Spenders list at their organization; so let them know how much a new virtual machine costs when someone asks you to spun up “3 or 4“. I don’t mean you should use bills to frighten away the beggars, but you must collaborate on making them become conscious about what they are asking and maybe rethink if they really need that many and that big.

It’s quite interesting to read the full post, just in case you need one more reason to be convinced that Service Catalog is the cornerstone of healthy IT Service Management.

You can read it here.

Root cause maps: aren’t they sexy???

Cause Map - ain't it hot???

The guys from ThinkReliability are offering an Excel template that can be used to track and document any problem investigation, including the tools needed to draw a root cause and process map -yes, in Excel. As they say:

Most people think of Excel as only an application for creating spreadsheets, but it’s an excellent tool for capturing each element of a complete root cause analysis. By changing the way details are documented, a facilitator can improve the entire investigation process. The drawing tools are simple, flexible and Excel is probably already on your computer.

I must add to that: you don’t even need Excel on your computer, you can use Google Docs -it’s free and a solid tool for work teams.

It’s not specifically addressed to deal with IT problems, but it’s not really that important; after all, IT problems are problems anyway. The main advantage to me of this template is it can be used to draw a cause map easily in a few clicks; on a tab you can find a lot of basic shapes (boxes and connectors), you copy them to the tab labelled “Cause map” and you’re done. Detailed instructions can be found in the template. Worth having a look at it.

You can download The Cause Mapping Template in Microsoft Excel here for free (no money and no registration required), and the list of advantages using MS Excel brings according to ThinkReliability.

PS: have a look at their blogs, plenty of useful examples on how to perform an RCA and its deliverables.

Send in the poka-yokes

While dabbling around with some Six Sigma papers this afternoon, I stumbled upon a funny term: poka-yoke. You can read about it here. A poka-yoke device is any mechanism that either prevents a mistake from being made or makes the mistake obvious at a glance, such as an USB connector which can be plugged one way only. It’s an error control mechanism oriented to avoid human mistakes when operating it.

There are plenty examples of poka-yoke devices and how to implement them on manufacturing chains and industrial processes, but I wonder: could they be useful on IT processes and procedures and how could they be implemented?

It’s important as many incidents raise in an organization due to human error; frequently, some RCA on those incidents conclude that an operator hit the wrong key or inserted the wrong tape on a drive… So, as to me poka-yokes look like a sound error-control mechanism, I’m looking for ideas on how to implement them on our IT Operation.