We recommend at a minimum some core understanding of the Service Lifecycle and the role the different processes play in modeling, planning, transitioning, supporting, and improving services BEFORE the tools training. Otherwise, people will "fill in the boxes" to "get the work done" without the right level of quality or value capture in their documentation. Ultimately you are at risk of reduce quality and service availability without this core understanding.
Friday, July 24, 2009
Certification training vs tools
A number of our customers are struggling with how to implement training programs to support their service management initiative. Many approach the training need from a tools point-of-view. In other words, train them on using the Change management tools, not on the process itself. While understanding how to effectively leverage and use your tools is critical, understanding the context of the work in supporting your services is the critical link. What are the proper triggers, inputs, and outputs of the process? What are the dependency relationships between your process activities and that of other processes? How does what is happening in your functional group impact other groups?
Subscribe to:
Post Comments (Atom)
A snippet of real-world ITIL. No one ever said it would be easy. I am currently on a consulting gig in Kuala Lumpur (from US) working with a global Company who multi-sourced (and also retained some) their IT delivery. Yowza! A typical penalty-driven SLA contract with requirements for suppliers to work together to achieve common SLAs where suppliers are customers and suppliers to each other. The Company had a decent integrated ITIL implementation before outsourcing. The good integration is slowly being disassembled to meet the contract with a more complex inter-supplier relationship being required to achieve the same results. In fact, one element in the current SLA is driving behavior that is not in the best interest of the Company! There are penalties associated with having Major Incidents that exceed a threshold. This is causing the suppliers to work hard to not declare a Major Incident or to delay the declaration. It is difficult to get rid of a Major Incident through the contractual process. Supplier A declares the Major Incident but the root cause MAY BE due to Supplier B but is not conclusive…so who owns the Major Incident? Therefore, why would Supplier A, who owns the symptoms, declare a Major Incident if it may end up causing a financial penalty even though they may not own the root cause? In this case the Company Business suffers since the incident is not treated with the due diligence by all suppliers necessary for rapid resolution. Many times these types of incidents are treated as Operational major incidents where appropriate resources are engaged but the visibility and final assessment are never taken…therefore the Business Impact ends up not being understood. What should happen? The IT Governance for the Company should discuss and implement a new SLA with the suppliers that will put the focus on the needs of the Company Business instead of counting technical events.
ReplyDelete