IgniteITSM

Working on moving most of my ITSM/ITIL related items here.

Finding Low Hanging Value within the ITIL Framework

I have written a few posts on our ‘ITIL Lite’ implementation, or more accurately, ‘ITSM Lite’.  We have looked at the ITIL framework and broken out the pieces that provide immediate value while avoiding creating something so ‘big’ that it is unwieldy for a medium sized organization.  Here are some thoughts on minimal implementations. 

INCIDENT MANAGEMENT

This one is fairly obvious.  Open items need to be captured somewhere for resolution.  The value is clear – if we don’t capture this information somewhere items fall through the cracks, fingers are pointed, etc. 

SERVICE REQUEST MANAGEMENT

Similar to above, however, I feel that Service Requests are an extension and expression of the value IT brings to the organization.  I would much rather say we had 1,125 Incidents and 1,500 Service Requests last month than say we had 2,625 IT issues.  Issues are often perceived as 'things are always broke'.  I have written previously in regard to how you might split Incidents and Service Requests using a single multi-tiered Category field.  This is valuable if you are using a lightweight tool or simply do not want to add complexity by introducing 'one more field'.  Multiple related Incidents become Problems; multiple related Service Requests identify areas for process improvement and/or automation.  Volumes provide a metric to measure cost of existing mechanisms vs. cost of improvement.  Easy examples - How many password resets per month justify the cost of a self-service product?  How many requests for Application X justify virtualized packaging and automated provisioning? 

PROBLEM

To me the immediate value in Problem is an attempt to eliminate an age old challenge – the “I will just do this for now and come back and fix it later” mentality.  Great – you have successfully resolved an Incident, however, you have identified a Problem and made a mental note.  Capturing this Problem provides for future accountability and identification to other staff members.  Value proposition #2 is that any known workarounds are documented and accessible by others with no need to receive the information by word of mouth alone.  This populates your Knowledge system - next.

 KNOWLEDGE

Knowledge is Power.  Doh.  This is a no brainer.  A good tool that makes standard documents, Incident History, and Problem History searchable is indispensable.  

CHANGE MANAGEMENT

I don’t have metrics on this one but I can tell you that without a doubt the following three things have occurred:

Our downtimes have been reduced dramatically.

Our collaboration and communication have increased.  Folks are in the loop and know what to expect.

Finger pointing is reduced and staff accountability is at an all-time high.

CONFIGURATION MANAGEMENT

Or as many have pointed out - Asset Management.  Pick your spots.  In most cases my thoughts are Servers/Network Infrastructure ONLY.  The clear Change history is extremely valuable and can instantly be referenced in the event of a downtime.  An Inventory/Management TOOL is nice for desktops, however, tracking CMDB type Changes on these devices simply cannot be justified in a smaller environment.

Enjoy.  I welcome any comments.

Mobile Device Virtualization

Jack Madden speaks here:

http://www.brianmadden.com/blogs/jackmadden/archive/2012/11/28/is-apple-ruining-everything-for-mobile-virtualization-or-are-they-saving-us-from-it.aspx

I'm sure this is a good article, however, I didn't even have to read it.

NOBODY.  WANTS.  THIS.

We don't want no frankenphones.

A Sample Service Catalog

Attached.  Enjoy.  There is some 'bridging' language included.  This allowed staff to make the transition from the standard 'Application Name' language to the 'Service Name'.

Deciphering Next Generation Application Delivery

Disclaimer - I work in a Healthcare environment.  This whole notion of the 'Post PC Era', while intriguing, is not happening any time soon.  Traditional Windows Applications are going to have a very long tail in our environment.  This said - everyone seems to want to turn Windows Applications into something they are not:

Applications that run smoothly and offer UIs geared for iPad and Android tablets and phones.
Applications presented in a sleek tiled format mimicking the modern day 'AppStore'.
Applications that are instantly downloadable and/or remotely provisioned.
Applications that are browser accessible.

Add to this the fact that we, today, have the following available in the marketplace:

Applications that run smoothly and offer UIs geared for iPad and Android tablets and phones.
Applications presented in a sleek tiled format mimicking the modern day 'AppStore'.
Applications that are instantly downloadable and/or remotely provisioned.
Applications that are browser accessible.

Right - things get a little blurry.

So how do we unify this into a single usable environment that can be accessed from any device from any location in a consistent manner?

Published Applications?  Published Desktops?  VDI?  All of these fill a specific niche but have their shortcomings.

Maybe we can use something like VMware Horizon or Citrix Excalibur to present a slick single point of entry into anything - Windows Applications, HTML5 Applications, Published Applications, Virtualized Applications, VDI Instances...  We can run this on top of Windows 7, eliminate the 'Windows Experience' and delivery true Application Access Nirvana.

Or we can just make these all attractive Windows 8 tiles and avoid spending a fortune on overlaying technology.  But this does not address our iPad and Android users...  Ah - deliver the Windows 8 desktop via VDI to the users who did not want a Windows 8 tablet...

This whole thing is one of the hardest items I've had the pleasure of trying to wrap my head around.  How do we best develop a go-forward strategy in a rapidly developing environment?

A year ago VMware seemed to be the answer - but AppBlast seems to be vaporware and Horizon just isn't 'pretty'.  Currently Citrix seems to have a more robust portfolio and possibly some advantages in regard to our other partners (Cisco?).  Windows 8 is new, unproven, and only addresses a small piece of the puzzle.

What now?

Visible Ops and ITIL: What Not To Do

Today I looked to procure an additional copy of Visible Ops, “The Yellow Book”, for a coworker.  I stumbled upon a rather recent article at ZDNet that can be found here:  http://www.zdnet.com/visible-ops-will-old-it-habits-scupper-its-chances-7000004867/.

The summary is stated as, “With ITIL and change management, the Visible Ops framework promises a new approach to creating an efficient IT operational model. But its chance of success is open to doubt without changes to the way IT is procured, designed, configured, validated and implemented.”

I was rather surprised by the author’s perceived shortcomings in regard to the Visible Ops / ITIL Framework.  Some of the reader comments were not much better.  Let’s take a look.

The author states, “That distinction was never more apparent than in the almost pointless weekly change advisory board meetings. While the processes themselves were painfully bureaucratic and often a diversion from operational work, the meetings themselves were just strange.

With barely anyone in attendance, the board would ask for a justification for each change, with a response of "approve" or "rejected" even though it was clear they had little or no grasp of the technical explanation or implication provided.”

Why the hell would you allow your change advisory board to be scarcely attended and lacking the participation of the folks capable of properly evaluating the change requests raised?  Without a true CMDB, which few organizations actually possess, the only folks capable of properly evaluating these changes have all the organizational knowledge within their collective skulls.  Don’t blame ITIL for your organization’s inability to properly manage the attendance and content of these meetings.

Or let’s try this one.  The author goes on to state, “Then there was the security and risk-compliance chap who'd lock himself in his room, glued to his Tripwire dashboard spying on any unapproved changes. So imagine his amazement when I introduced him to VMware and vMotion.”

So, ummm, right.  Technology progressed.  Your organization failed to progress with it by eliminating virtualization workload shifts from the activities requiring change control/change documentation.  What does this have to do with ITIL?  So the answer is no, you really shouldn’t have to raise a change to allow vMotion to do its job – your process was simply hosed and you almost sound amused to have been part of the problem rather than a contributor to the solution.

Last but not least there is this gem.  “Several years later, as a technical consultant my impression of the effectiveness of the change advisory board failed to improve. Late one night at a customer's datacentre, I'd pointed out that they had cabled up the wrong ports and that this would require a change to be raised.

"No need for that" replied the SAN architect, "I'm one of the board members". He then proceeded to pull out and swap the FC cables to his production hosts with a big grin on his face. Several minutes later his phone rang, to which he replied, "It's OK, I've resolved it. There was a power failure on some servers." Then he turned to me with a wink and said, "There you go. Sorted. Lubbly jubbly."”

This person should be coached immediately.  If this was not a first time offense a termination would be the appropriate response.  This is reckless behavior and should not be tolerated.

Well let’s not leave the readers off the hook here.  Someone named ammohunt responded with the following (edited four spelling errors), “Where the change control piece of ITIL breaks down is determine what is a maintenance task and what constitutes a change in our case we felt the better judgment should have been left up to us; the technical folks. Management disagree and decided that they would decide this...It got to the point where my manager was insisting that i create a change control for editing a host file. At first i started implementing tier 0; as in Null change controls..i.e. what management doesn't know won't hurt them which quickly earned me the cowboy label. Eventually the best solution was to give up on the company and seek gainful employment at a company with sane process; many others did the same.”

Well I am sorry, ammohunt, while your technical guidance should be considered when vetting which changes require proper approval/documentation you are not steering the ship here.  I recently witnessed a significant downtime to an EHR system as the result of, well, editing a hosts file.  Glad to hear you found gainful employment elsewhere - your previous employer likely gets some additional sleep knowing that current employees to do not share the cowboy mentality.

Getting out of the Weeds

Seems like numerous times a year I find myself in the VDI vs. Published Apps quandary.  The only way to dig out is reminding myself that these tools simply exist to delivery legacy technology.  It is our vendors that need to roll up their sleeves and properly deliver in either a natively mobile or industry standard browser based fashion.  Hurry it up and thanks in advance.