ITSM should be run like a business

RE: Service Management in Operations by Sue Conger, MaryAnne Winniford, and Lisa Erickson-Harris

Service Management in IT is now like any other service mangement in other business functions. It has not always been this way. ITSM now talks of things like SLAs where actual service levels are agreed not measuring details like dropped packets. SLM focuses now on the processes and services defined in the SLA. That is: what the services are and how they are used.

However, not all enterprise managers are aware of the benefits frameworks like ITIL can give them. Even if ITIL or MOF was partially implemented, greater efficiencies would result from it. Those efficiencies could result in less downtime from outages and increased productivity from those using the services. The result: a better business.

 ITSM textbook is a good height for trainer

Change is coming

RE: Mastering IT Change Management Step Two: Moving from Ignorant Anarchy to Informed Anarchy by Ken Dietal

In the past changes to IT services were made, and the only indication that a change had been made was at the coalface. These changes sometimes are disruptive to workers, so a call to helpdesk is understandable. Sometimes the helpdesk were not aware of the change either, so an incident report was logged and sent to the developers who said "yeah I know".

Modern change management has gone a long way to fuse these "islands of knowledge". We now have procedures to keep everyone in the loop. From submission to implementation, every stakeholder informed, even the reluctant ones. The process can be a little cumbersome, however, when emergency changes are needed. In these cases the two review steps are bypassed to expedite changes.

In conclusion, I praise the new changes. It removes some of the "yeah I know" exchanges between helpdesk and change implementer.

Help Desk Support

Re: You Want us to Support WHAT?!? Negotiation, Delivery, and Cultivation: The Gateway to Excellent Service Deployment. By Ryan Tucker and Nathan Carpenter

In the past Help Desks used to be something that was added after the deployment of a new service or just before. These days support starts from the conception of a new service. That's probably a good thing. Users can be involved in the development of the new service and suggest improvements. A user is then involved in the process and can might be less critical of a service they perceive as being imposed on them

Service Catalogues

Re: Developing a Service Catalogue for Higher Education Information Technology Services by Andrew H. Lyons.

The most important step the team made in developing this system was involving the customers and end users in the devopment process. They involved users of varying technical experience, asking them what they liked and disliked about the old site. This was important because it was a "cumbersome" experience using the old site. They reviewed the types of services by the need category type, without using a long description in the title so it was easier for the user to skim through. They had make a compromise between over-simplified language . They wanted to avoid grouping services by technology, and instead focused on the type of searches a user would commonly use.

I believe they developed this in the correct way. A user who is fustrated by the service catalogue might tend to ignore it, and all the useful self-help service instruction it gives. They will then call the IT department to fix something they might have fixed themselves.