Here’s the problem my organization has been recently facing; we’ve been needing to take down our electronic medical record system (EMR) for a few minutes to fix a Problem, but the established downtime window is over a week away. So during this time while waiting to implement the fix we’ve been needing to spend several hours in labor on the work-around. Since this is a hospital the users pretty much live and die by the EMR, so taking it down, even for a few minutes, is a big deal with getting permission from the key business leaders, sending communications and the general coordination of the activities. The other caveat is that we would also prefer to use the maintenance windows for the CI’s that are allowed to be changed and nothing else (a brief background – we have two EMR downtime windows a month, one for the general I.T. infrastructure and the other for application changes). So how do we stay flexible with putting in Changes while not racking up the costs of just working around our Problems? My idea: Work with business leadership to allow a preplanned fifteen minute downtime each week for fixes. This doesn’t mean we just take the system down every week, but if we do require the extra time our users will know by a specific date and they’ll know exactly when it will happen as well as being aware that it’s something serious enough that leadership would allow the downtime. Obviously there would have to be governance around the plan to make sure it’s not abused, but this would also mean that we can eliminate a lot of the headache of an unplanned down-time by not having to track down business leadership for approvals, using an approved communication plan and giving the I.T. department more flexibility with being able to put in fixes to resolve Problems.
I just read this post from the ITIL Wizard (http://www.itskeptic.org/node/1861) and first I have to say, I love the humor when it comes to all the acronyms (or are they abbreviations?). The article does touch on a very common theme I notice in my own work place and that’s the escalation of Requests through Incidents. So the article is more related to Changes and Incidents and here I’m comparing Requests to Incidents, but aren’t Requests just low risk, preauthorized Changes with established processes anyway? A common point of confusion at my place of work is when it comes to change in security privileges. Since this is a hospital someone not having the proper security rights means they can’t do their job, and in a hospital that can be a very serious issue and it’s this seriousness that causes the Request to be put into an Incident. Another common scenario is when a Request isn’t fully completed before the Request Record is closed. This usually results in the user contacting the Service Desk, an Incident being created and then someone else going to finish the work that should have been completed before the Request was even closed. So why are these extraneous Incidents opened? I can pretty much sum it up with the simple idea that if we’re using two processes to complete something that in theory should only require one, then the processes aren’t built to meet the needs of the business. To keep it simple; extra work means we’re inefficient. Hmmm……
It’s been about a year now since the new director with ITIL experience started here and as I think back to the different road maps and plans for changes I realize that this organization moves at a very, very, very slow pace. So slow that often it doesn’t even feel like much progress has been made in the initiatives to improve Change Management or to help reduce Incidents by pushing for more Problem Management. I think it’s even been over a year and a half since I sat down with our CIO and went through all the benefits of Event Management and how great it would be to proactively monitor our environment. The point of this post isn’t to rant about the difficulties in implementing ITIL but rather the difficult realization that changes can only be made at the fastest possible pace that the environment allows. The director I work for is fantastically influential and has great leadership skills with getting people to see the benefit in ITIL, but not even the greatest of leaders can inspire everyone to jump on the race car of change; sometimes the best you can do is get people to reluctantly clamor onto the snail of change and hope that evolution turns that snail into a cheetah. Either way my lesson learned from the past year is to set the pace for what the environment can handle. Too slow and the only thing left to feel will be frustration. Too fast and there will be way too much resistance to make any progress. It’s a fine line and apparently the successful ITIL practitioners are those that know how to delicately keep their balance while walking along it.
Just about everywhere I turn there’s some kind of discussion or article about “Changing the Culture.” From one of the latest IT Skeptic’s posts (http://www.itskeptic.org/node/54) there’s a reference to a survey completed by Gartner that shows the number one hurdle of implementing ITIL is due to having to change the culture. Don’t believe me? Here it is:
If you read the blog post you’ll find that the IT Skeptic isn’t confident in the data, but I’m willing to bet that the part about culture is correct. So when it comes to implementing ITIL, ITSM, DevOps, MOF, Six Sigma, LEAN, CMMI or any of the dozens of process improvement methodologies, it’s apparent that there’s an enormous task of just changing the way people think about how they function in the I.T. environment and how this impacts the value to the business. This is probably why a lot of process improvement initiatives fail; it’s easy to change processes and technologies, but how do you change people? I can definitely agree that the culture shock of ITIL is difficult for some people to comprehend since I’m fighting it right now in my organization, but it must be possible since other companies have succeeded.
Comments