Bad practices in service provision (1 of 2):

ITIL has become the de facto standard for implementation of good practices in service provision.. Nonetheless, there are still many examples of companies who operate without following the most basic recommendations.

Recently, I took part in a project in which the provider contracted for implementation proved to be disorganized and, surely as a result, inefficient.

The provider was going to make available a new corporate software and also take charge of its implementation. The goal was to get rid of multiple Excel spreadsheets and other disjointed systems (including documents on paper) in different departments, which would thus find their bureaucratic work simplified and could focus on tasks with greater value for the organization.

The implementation was delayed, and the system started production with partial implementation, which was being finished in parallel to actual use. If any system in use generates incidents, a system that is being used while implementation is being completed generates even more.

It was expected, perhaps because the provider markets Proactivanet and is an insider in the sector, that they would have some type of system for managing the incidents reported. Nevertheless, after consulting on the matter, the only thing that they could offer us was reporting of incidents by email (the contact channel for Service Desk), and there was no method for finding out about the incidents reported nor their status other than by asking. “Is there a website for monitoring incidents? No, we don’t have one”

Since there was no website (such as Proactivanet’s support portal) for monitoring the incidents, the operating procedure became very complicated, because email ceases to be a contact channel and becomes a record that is rather inadequate for agile and effective management.

One obvious drawback -surely the reader can come up with more- is that the users do not have any way of finding out the status of their incidents and, even worse, finding out which incidents are open. This obliges them to monitor open issues themselves using an Excel (or submerge themselves in their email inbox and combine this with all sorts of tagging and filing techniques).

The provider did have a system for managing incidents however, but was not using it for interacting with the users who reported them, since the system was only accessible to the provider’s own staff. Thanks to this system, it was at least possible to set up a weekly mailing of a report in Excel format that reached all users each week. This situation is far from optimal, but in the end it was possible to get a centralized, up-to-date overview of the incidents.

We must admit that it could have been worse, since we could have been in a situation where the provider’s staff were in the same boat as the users who report the incidents, handling management of incidents based on email inboxes.

One recommendation for this provider would be to consult an ITIL guide about the Incident Management process and the function of a Service Desk. Even applying only a couple of the good practices found in the guide would improve service quality noticeably.

In the second part of this article, I will offer another example of a good practice, in this case from ISO 9001, which was not followed in this project.

Best regards

José Luis Fernández