ITIL в небольшой компании: тикет-трекер вместо тетрадки

Год назад мы написали про SLA как договор с клиентом. Тогда это было скорее про обязательства на бумаге. С тех пор вопрос встал иначе: как вообще понять, выполняем мы эти обязательства или нет, если учёт ведётся в голове у дежурного инженера и частично в почте?

ITIL в России активно обсуждают последние пару лет - на конференциях, в журналах. Большие компании нанимают консультантов, покупают дорогие решения. Мы смотрели на это без особого энтузиазма: типичный клиент - производство или торговля на 50-200 человек, никакого бюджета на HP OpenView и полгода на внедрение. Но идея процессного подхода к ИТ-поддержке засела правильно. Решили разобраться, что из ITIL можно применить без бюрократии и корпоративного театра.

Начали с самого простого - тикет-трекера. Поставили небольшое open-source решение (в итоге выбрали OTRS), завели почтовый адрес для заявок, объяснили пользователям: «пишите сюда, когда что-то сломалось». Никаких категоризаций, SLA-таймеров и прочего - просто фиксация факта обращения.

Первый месяц показал неожиданное. Накопилось чуть больше восьмидесяти тикетов. Ничего не было настроено про отчёты, но даже поверхностный взгляд на список дал картину, которую раньше никто не видел. Треть всех обращений - один и тот же принтер в бухгалтерии. Он застревал, мял бумагу, иногда просто не печатал. Каждый раз инженер ехал, чистил, уходил. Без тикетов это воспринималось как «бухгалтерия опять звонит», а не как системная проблема с конкретным устройством. С тикетами стало очевидно: принтер давно окупил бы свою замену рабочим временем на выезды.

Именно это ITIL называет управлением проблемами - отделить инцидент (принтер не печатает сегодня) от проблемы (принтер не печатает каждую неделю по непонятной причине). Без единого места сбора инцидентов увидеть паттерн невозможно в принципе.

Что реально работает без бюрократии. Мы не внедряли ITIL как методологию - мы взяли из него три практики и приземлили их под реалии небольшой компании:

• Фиксация каждого обращения. Звонок, письмо, разговор в коридоре - всё идёт в тикет. Пользователю можно не объяснять ITIL; достаточно сказать, что без тикета мы не можем гарантировать очерёдность.
• Разделение инцидента и изменения. Если для решения инцидента нужно что-то менять в инфраструктуре - перенастроить, обновить, переставить - это отдельный тикет с согласованием. Мелкая правка в конфиге почтового сервера, которую раньше делали «по-быстрому», однажды положила входящую почту на полдня.
• Закрытие тикета с описанием решения. Не «починили», а что именно сделали. Через два месяца это уже маленькая база знаний по повторяющимся проблемам.

Про сопротивление. Пользователи звонят, потому что привыкли звонить. Переучить за неделю не получится. Мы сделали так: инженер, приняв звонок, сам заводит тикет и говорит: «Я записал, номер вашей заявки такой-то». Человеку это нравится - появляется ощущение, что его проблему взяли на контроль. Через месяц многие сами начали писать на почту.

Внутри команды тоже не всё гладко. Инженеры привыкли работать по устной договорённости - позвонил, сказал, сделал. Тикеты воспринимаются как лишняя работа. Помогло одно: когда директор увидел отчёт за месяц и спросил «а почему вот этот принтер упоминается двадцать пять раз?» - ценность учёта стала понятна без лекций про ITIL.

Что это даёт на практике. Аутсорсинговая поддержка без тикет-системы - это чёрный ящик и для клиента, и для нас. Теперь клиент видит, сколько его заявок закрыто за месяц и с каким временем реакции. Мы видим, где тратится больше всего времени. Разговор о приоритетах становится конкретным: вот данные, вот узкие места.

Никакого ITIL-сертификата у нас нет и не планируется. Но три принципа - записать, классифицировать, задокументировать решение - уже изменили то, как мы работаем. Принтер, кстати, заменили. Обращений из бухгалтерии стало в три раза меньше.