Idwell on Service Management

Thoughts on how to design and implement IT Service Management

Author Archives: Paul Leenards

Paul Leenards


by Leave a comment

ITIL3 Principles

Based on the core books I’ve tried to distill some basic principles for ITIL3. Principles that you can apply to your IT service Organization and that will help you to make this organization more in line with ITIL3 (and therefor hopefully more useful to the business). These are the principles:

  • Agency principle: service providers work for the business on a contract and provide services that are useful (utility) and usable (warranty) to the business within the boundaries of laws and regulations
  • Balance Principle: there should be a balance between the Internal IT view versus the external Business View
  • Service Measurement principle: all aspects of service delivery should be continual measured and reported
  • System Principle: all aspects of service delivery should be encapsulated in the design of service provision (holistic Design).
  • IT Service Lifecycle Principle: service delivery is a continuous process of design, implement, operate and improve.
  • Knowledge Management Principle: ensure that the right information and knowledge is provided to the right people on the right time

    • I’m pretty sure this is not a complete list. I’ve tried to keep it short and to the point. Any suggestion for improvement is welcome. As long as it is a principle that will help an IT organization improve it services and is in line with the ITIL3 Framework.

    Paul Leenards


    by Leave a comment

    Business IT Intergration Maturity Model

    The Business IT Integration Maturity Model is first introduced in the summer of 2006. It was created to use in a discussion with an IT department to define the level of organizational maturity needed (based on Nolan’s Maturity Model). The BITI Maturity Model defines the needed organizational maturity of the IT department in relation to the view of the Business on the strategic importance of IT. The view of the Business can be seen as a level of maturity for the business itself.
    The basic assumption is that the maturity of the IT department should not be greater than the view of the Business on the need for IT. If the Business is looking towards IT as a commodity, then the IT department should have a customer focus (maturity level).

     

     

     

    Paul Leenards


    by Leave a comment

    ITIL3 is a teenager

    I like analogies. They are useful to explain a complex thought in a different way and help to gain understanding. This morning I’ve started to write the text for a factsheet we want to publish on ITIL3 in relation to ITIL2. And I was considering an analogy. Since maturity is a concept we like to work with (hence http://www.itmaturity.com) I toyed with that idea. I realized that ITIL3 is like a teenager. It has grown up since the previous versions (1, the baby, and 2, the child), but it isn’t mature yet. Although it likes to think otherwise. It has found it can now use new possibilities and functions that were already there in potential. And it hasn’t yet used the full potential.

    As a teenager ITIL3 has pimpels and is a little too corpulent. That might have been caused by the hamburgers it is eating lately. It is very concerned with pocket money to buy the latest gadgets and fashionable loud music. ITIL3 is both attractive and repelling. Pretty to look at, but the nonsense it is uttering…. oh, please! The rebellious side is well developed and irritating. Its enthusiastic approach to life(cycles) is contagious. It lacks social skills and experience. It thinks that structures are the way forward.

    You can tell that I both have a like and a dislike of ITIL3. Looking at the framework from one perspective, it offers a lot for the IT organization. From the other perspective there is still a lot to improve. I’m curious if there are other analogies to be made. Or this analogy to be improved.

    Paul Leenards


    by Leave a comment

    IT Industry Standards

    Last week I had an interesting discussion during the ITSMF e-Symposium on Service Automation. In the America Session the question was asked if the IT industry is not too young to have a best practice framework like ITIL. You could argue that there hasn’t been enough experience within the IT community to have best (or good) practices defined as such. Although I can understand the perspective, in comparison to for instance Finance the IT industry is quite young, I do not agree with the conclusion: As long as there is a constant study on the best practices in IT there is a place for IT Industry Standards. After a while these Standards will stabilize and become more common knowledge. The recent addition to the ITIL set of Continual Service Improvement is exactly what you need to establish these Industry Standards.

    What is needed is an Academic forum for the studies of IT Service Management where the IT Industry Standards can be further developed. At the moment there is this ongoing discussion on all kind of platforms between Vendors and Users on what is the best standard. And with this discussion acquisitions of bias are always close: vendors want to sell their products and services and users want simple and cheap solutions in a box. A more independent platform is needed and Universities can play an important role here. There are already some Universities that are getting involved, hopefully the number will increase.

    Paul Leenards


    by Leave a comment

    Alerts and Incidents

    When I read the Event Management Process chapter in the Service Operations book I had a feeling of approval. Finally, they are getting it. But then I was confronted with the Incident Definition and I realized that they still didn’t get it. Let me explain.

    The definition of an incident, according to the glossary, is: “A unplanned interruption to an IT service or reduction in the quality of an IT Service”. That part I’m 100% in agreement with. But the definition continues: “Failure of an configuration item that has not yet effected Service is also an incident. For example Failure of one disk from a mirror set”. A failure of one disk from a mirror set clearly will not be an interruption of an IT Service and will also no lead to a reduction in the quality of the IT Service. There will only be an higher risk of an interruption when the other disk fails. So in the definition for incident they added an extra exception. Making a clear definition debatable. BTW since when is an hard disk of a mirror set an configuration item?

    OK, you need to address the disk failure and some administrator should look into this. There should be a workorder created: replace hard disk in mirror set and check if the mirror is restored. Incident Management should be only about solving service interruptions urgently. That is why we’ve taken out the non-urgent requests. And that is why in the Event Management process there is the notion of the Alert (p. 41 of the Service Operations book). “The purpose of the alert is to ensure that the person with the skill appropriate to deal with the event is notified”. Interesting enough there is no definition for Alert in the glossary.

    The nice aspect of Alert is that you can use it to schedule corrective actions, taking the urgency and subsequent rushing out of the equation. The next day an operator with sufficient skills, documented workinstructions and access rights takes the work order list and replaces the hard disk. Without being rushed, without interrupting the service and within a reasonable time (within 24 hours). If you would have followed the book you would have created an incident with a low priority, thus low on the list, and somewhere between 4 hours and 4 days the hard disk might have been replaced. Since Incident Management is always dealing with new incidents with a possible higher impact you would never know for sure that these low impact incidents will be performed in time. Plus you have to explain to your customer the higher number of incidents that they can not relate to, since they have not experienced the service interruption (since there wasn’t any).

    Paul Leenards


    by Leave a comment

    ITIL Foundation

    I’ve just experienced the beta version of the ITIL foundations with the slidedeck provided by APMG. I don’t think that the people of APMG truly understand the ITIL practice and what is important to explain to the participants.

    First the text on the slides are not always very consistent with the actual books. That is not necessary bad, if it wasn’t the case that most time the text in the books are better. They should have stayed closer to the books. For instance on the objectives on Service Transition they have expanded on the objectives as mentioned in the book, making them more confusing.

    Second, a lot of slides are inconsistent in itself. We’ve encoutered several different definitions for function, for instance. Some slides are only meaningless lists of roles. They will confuse the poor participants to this foundation course to the point that they will probably have given up learning anything.

    Looking into the example exam-questions we’ve learned that a good reader with a knack for the English language will probably pass, where someone following the ITIL foundations course APMG style will probably not.

    Piece of Advice. If you want to follow the ITIL foundations course, find a training organization that will not use the official APMG slidedeck but their own. They will still help you pass the exam, and you will actually learn something on top of it.

    Paul Leenards


    by Leave a comment

    Silo’s are doomed

    Today we had a discussion on Servicedesk and Incident Management and how we could improve the efficiency. The incident manager of our client is dealing with the internal hierarchy and has found that he has insufficient authority to escalate in case an incident has to be solved by staff from multiple departments. Both his service management system and the IT organization can not deal with this situation. A solution would be to minimize the number of solution groups and have an incident manager would has also hierarchical responsibility over the support staff (all of them). That will mean no more Server management departments, network management departments, SAP solution teams, etc. No more silo’s. In a whitepaper on the ISCO model of Gartner from some years ago they predicted the future of these silo’s: they were doomed. From Servicedesk/Support efficiency perspective I can not agree more with them.