Last week I sat my exams for my ITIL Managers Certificate, and dare I say it, things are looking less cloudy these days. If I look at my interactions with customers, their requirements to acquire tools to automate processes/activities and become more efficient and effective, a lot of sign offs never happen due to business cases not stacking up/not being expressed in a way the business understands/needs, process issues, skill sets of staff to implement and maybe a history of unsuccessful projects in the past.
This has had me thinking whether we really understand what the business expects and needs from IT. IT departments used to be the place where the ‘geeks’ were, where they had the latest toys, deployed new versions of software because it was a new version, and I question how far away our thinking has come from there. I’m not sure IT understands that it is there to support business processes and deliver an outcome that the business needs in order to make more money. We need to get closer to the business, become part of their vital business functions and enable them to achieve the business outcome they desire. I come from a background in infrastructure and it’s very easy to become very siloed and focused on the task at hand, rather than taking a step back and understanding and listening to the business requirements. I found this course extremely useful, and it challenged my thinking in a number of areas.
There were a number of things that dawned on me as I participated in this course:
1. The Service Desk – This is the eyes and ears to our world, the customer and IT. Typically these people within IT are treated as second class citizens, they take a fair amount of heat for things they have little/no control over, and they are responsible for the ownership, communication, monitoring and tracking of incidents. What an interesting place to be! The experience customers have with the Service Desk typically shapes how customers feel about the service IT delivers – What an opportunity.
2. The roles of Incident management vs. Problem management. Incident Management is about restoration of service as quickly as possible. Problem Management is about looking for root cause and finding a fix etc. These roles can be at odds with one another, and shouldn’t be the same person for obvious reasons. There is a large need for proactive problem management by trend analysis and this is typically not done – the reality is that 20% of the issues in environments cause 80% of the pain… so why wouldn’t we dedicate staff on a regular basis to help reduce this?
3. Configuration Management – What a powerful place to be if you understand the configuration items in your environment, their relationships, the relationships to problem records etc. Getting a real understanding of what makes up a service in your environment, being able to monitor the whole service end to end rather than just a component of a service.
4. Change Management – the process of moving from one state to another, documenting why and how, back out plans, costs etc. Do we have appropriate people providing input into our Changes – i.e.: Business people, Technical People, our Customers, or does IT consider this to be their call? Do we understand and publish a forward schedule of change, plan and make sure this is acceptable with the business in terms of planned outage windows etc.
5. Release Management – Do we understand from the business what our windows of opportunity are to roll out new versions of software/services to minimise the impact on the business? We can reduce risks substantially by the appropriate regression testing, risk analysis and reviews of successful/unsuccessful releases and feeding that back into future projects/releases.
6. Service Level Management – Are we agreeing, monitoring and reporting on how we are tracking, do we have the right monitoring tools to be able to do this? – Are we continually improving the service we deliver to the business? Are we revisiting the Services Catalogue to make sure we are in line with the changing needs of the business? Do our underpinning contracts/OLAS support the services we are delivering to the business?
7. IT Financial Management – Do we really understand what we do deliver and what it costs to deliver these services? Do we deliver what the business really want us to deliver? Do we manage demand/supply of services via charging? Even if we don’t charge internally, do we raise awareness of the costs to the business and provide that information to business units on a regular basis?
8. Capacity Management – Do we understand the future projects/services of the business so we can plan appropriately for additional capacity? Do we have too much spare capacity and therefore waste resources and money? Do we do knee jerk buying and therefore not get the best value for money, do we buy today because it’s cheaper, and not deploy for a long time, and get a false economy of value vs. cost? Do we understand components that are under/over utilised; do we plan for upcoming projects as well as the current workload to make sure we get the performance and throughput necessary in the event of failure/additional demand?
9. Availability Management – Are our services there when the business needs it? How do we maximise this, as well as reduce the effect of it not being available by implementing efficient recovery processes/procedures/tools? Do we understand the business availability requirements and is there an availability plan?
10. IT Service Continuity Management – Does this really roll up to a business continuity plan? Can the business operate on manual processes, for how long? Do we test disaster recovery and do we understand what the business needs available in the event of disaster? How immediate does the business need these vital business functions online? Are we making the wrong assumptions and trying to drive this, rather than it being driven by the business?
The point I’m trying to make is that in order to move forward and become agile, we need to build much tighter relationship with the business, understand what they want to achieve and when they need to achieve it. We need to advise them of what is technically possible; everything has a cost, even if you choose to do nothing. We don’t want to be seen as a cost centre, we want and need to be the enabler!
net/net – Great value in this training – highly recommended.