Канбан в ИТ-обслуживании

В этой статье мы поделимся нашим опытом использования системы Канбан в ИТ-обслуживании. У каждой компании рано или поздно появляется проблема несвоевременного выполнения задач ИТ-отделом, это может быть как внутренний отдел, так и отдел, работающий с внешними клиентами (подразумевается что тикет-система в компании уже внедрена и используется, иначе менеджмент задач использовать не получится).

Для решения такой проблемы придуманы различные методологии управления ИТ-обслуживанием, например, наиболее известная в России – ITIL. Но у всех этих систем есть существенный недостаток – они очень сложные во внедрении. Например, для решения типовой проблемы длительного выполнения задач в ITIL нужно внедрить как минимум 2 процесса: управления инцидентами и проблемами. А для их внедрения нужно сначала разработать портфель услуг и желательно базу конфигурационных единиц (CMDB). Получается сложно и долго. Поэтому мы решили поискать решение проще и остановились на Канбане.

Термин Канбан имеет дословный перевод: «Кан» значит видимый, визуальный, и «бан» значит карточка или доска.

Ниже приводим таблицу (см. Таблица 1) сравнения двух методологий. Очевидно, что ITIL – более мощная система, но и более сложная, поэтому в некоторых случаях достаточно внедрить Канбан.

Канбан – это элемент знаменитой производственной системы концерна Тойота, разработанный Тайити Оно. Один из базовых принципов этой системы, подходящий для нашей деятельности – это бережливое производство и минимизация складских запасов. Все товары должны быть доставлены к конвееру точно в срок. Запасов быть не должно. Любые запасы – это потери. Например, представьте, что на заводе для сборки автомобилей заготавливаются большие запасы комплектующих. Скорость расходования тех или иных комплектующих зачастую точно не известна и когда нужно будет заказать новые детали – менеджер по закупкам не знает, поэтому заказывает все с «запасом», чтобы из-за его ошибки не остановился конвейер. Если же применяется Канбан то на определенном участке конвейера определяется предельно допустимое количество запчастей. Например, 10 штук. Как только их остается 5 штук, идет запрос на поставку новой партии в 10 штук, так как известно что время их изготовления и поставки составит ровно столько, сколько нужно времени, чтобы израсходовать оставшиеся запчасти. Как только последняя комплектующая установлена, приходит новая партия в 10 штук. И цикл повторяется. Если так работает весь завод и все участки конвейера сборки, то нет необходимости держать большие склады – как следствие уменьшаются издержки и повышается порядок.

Обмен заказами в Канбан происходит с помощью карточек (см. пример на Рисунке 1). В нашим случае под складскими запасами подразумеваются задачи от пользователей. Следовательно, наша цель – не допустить затоваривание этими «задачами».

На возможность применения Канбана в ИТ мы наткнулись на примере использования этой методики при разработке программного обеспечения. Получалось все логично и просто. Поэтому мы решили применить эту идею в ИТ-обслуживании. Все задачи мы разделили на несколько групп (см. Рисунок 2):

• Новые. Это новые задачи, которые еще не приняты в работу.
• Принятые. Это задачи, которые сейчас исполняются.
• На контроле. Это выполненные задачи, которые ждут подтверждения выполнения заказчиком.

Рисунок 2 – Система Канбан в ИТ-обслуживании от EFSOL

Для каждой группы мы вводим максимально возможное количество задач в этом статусе. Этот предел устанавливается эмпирически, исходя из того, какое количество задач может одновременно выполнять ИТ-инженер. Как только достигается предельное количество задач в группе, то блокируется возможность добавить в нее новую задачу. Сначала надо закрыть какую-то текущую, чтобы заняться новой.

Что дала такая система:

1. Во-первых, она позволила избавиться от систематической затянутости задач – каждая «зависшая» задача уменьшает допустимый лимит.

2. Во-вторых, она позволяет руководителю отдела оценивать загрузку инженера и перераспределять оперативные задачи если у какого-либо сотрудника возникла сложная задача и у него образовалась очередь из новых задач.

3. В-третьих, Канбан стимулирует исполнителя не накапливать задачи, а своевременно их выполнять. Именно стимулирует, а не заставляет. Весь принцип производственной системы Тойота построен на сознательности сотрудников. Если человек старается постоянно обойти, обмануть систему, то с таким сотрудником надо расставаться.

4. В-четвертых, система позволяет руководителю отдела аргументированно оценить загруженность отдела и понять, что надо либо брать нового сотрудника, либо кардинально менять алгоритмы обработки задач.

5. В-пятых, в нашем случае система Канбан заставила инженеров общаться с клиентами, чтобы сдать им задачи со статусом «на контроле», которые ранее игнорировались. Сотрудники просто переводили задачу в статус «на контроле» и считали свою работу выполненной.

В качестве основного недостатка применения Канбана для управления ИТ-задачами можно выделить невозможность учитывать приоритетность задач. Де-факто все задачи рассматриваются как задачи одинаковой срочности и расстановка приоритетов выполнения лежит полностью на исполнителе. У себя мы применяем 2 приоритета задач: срочная и нормальная, но в самом Канбане они равнозначны. Срочные задачи, связанные с критическими сбоями, мы пускаем в обход системы, но их совсем немного.

Делая вывод, можно отметить, что применение Канбана в ИТ-сфере возможно и по сравнению с другими системами внедрение его очень простое. Принципы этой системы легко воспринимается исполнителями, как следствие, не требуется долгого привыкания и адаптации. Если вам нужно быстро внедрить систему управления задачами, решающую основные проблемы ИТ обслуживания – Канбан является хорошим вариантом.