Want To Improve Communication Between Business And IT? Use ITIL
I used to manage the equity trading technology for the French bank SG. It was a pretty big job, with business analysis and support teams in all the major equity trading locations around the world, as well as a development team over in India.
We had a bespoke system built in Lotus Notes to handle change and service requests from the business. As each bug or request was found, the business analysts would assess the importance of the change, along with the business people assessing the priority of their service requests.
So as each version of the trading platform was released to the users, a list of service requests soon built up. The problem was that to the business people, everything was a high priority. They always felt that the system should be more malleable. They never had any concept of how IT systems that are endlessly changed can also become unstable – even more difficult to manage in a globally connected bank trading system that has to operate across time-zones stretching from Japan to the USA.
At the time, we tried moving to an Agile methodology where the system was being updated with fewer changes, but on a much more frequent basis. It helped to give the business users the impression of constant progress, but it never helped with the fact that a service request that was not considered urgent might sit at the bottom of the list for months, or even a year, never touched because it is always replaced by more urgent requests.
By using ITIL my team could have improved this service desk considerably. Less important changes would no longer languish unloved, they would have been highlighted and alternative solutions or workarounds proposed. Even a less important request is still a request that needs to be addressed and the single-point-of-contact rules within ITIL help to avoid it getting lost between teams of business analysts, programmers, and project managers – all tied up trying to deal with urgent enquiries.
The real difference is that in my old company, the IT department controlled the process of listing and prioritising the service requests. Within ITIL, the focus of the change and service request process is always the business user. By adhering to the ITIL guidelines:
1. It would be the business user that asks for changes
2. The business user would be updated on progress without the need for status review meetings – it would be a function of how the IT team works
3. The business user could directly handle queries about their request – without ‘assumptions’ coming from the IT team
In this sense, ITIL is not just a conceptual list of service practices; it is a common sense package of processes that ensure the business user builds confidence in their IT team through open and transparent communication.
Nowadays it’s a pretty obvious question either to use ITIL or not. I would say more – today it’s a sort of fashion, especially in the banking and telco sectors.
Indeed, earlier banks had to request external consulting organizations to help them provide the reengineering and optimization of internal business processes. That was really expensive. Expensive and too long.
What ITIL offers today is the library of best practices, saying: “Now you don’t need to pay external consulting firms, just choose what suits your organization best, then customize it and use!” Sounds good, doesn’t it? 8)
However there is one small question – how to use it? How to use ITIL? Theoretically you may issue a lot of regulations, rules and procedures where it will be stated what everyone should and should not do. You may even print it out and hang it on the wall. But it doesn’t work. It could work in army but not in a bank.
In a bank people use various informational systems which direct their everyday activities. That is why now implementing and using ITIL means the deployment and utilization of various software. For instance IBM Tivoli Service Request Manager is designed to provide all the functionality required for Service Desk organization and includes such ITIL processes as Service Request Management, Incident Management, Problem Management and Service catalog provisioning. Deployment of Service Desk based on Tivoli Service Request Manager normally takes 6-9 months. Compare it with business processes reengineering projects that normally last for several years!