В крупных корпорациях IT-служба одновременно обслуживает несчётное количество заявок и заказов от самых разных подразделений. Стоит ли говорить, что каждое обращение к IT практически всегда помечено высокой важностью и срочностью. Задача IT — организовать этот поток, направить его в управляемое русло. Сделать это можно только путём расстановки приоритетов.
Простой и очень жизненный пример наглядно иллюстрирует будни IT-службы. Бизнес-подразделение срочно желает изменить процесс реализации. Необходимость обосновывается колоссальным экономическим эффектом, а отказ может обернуться потерей прибыли. Одновременно с этим финансовая служба сдаёт квартальный или годовой отёт. Заморозить работу системы на время внесения обновления — значит не сдать вовремя финансовую отчётность. А это уже влечёт за собой большие штрафы и санкции. Очевиден конфликт интересов.
Игра по правилам
Поставить процесс на рабочие рельсы, избежать конфликта интересов, сократить количество обиженных коллег помогут только прозрачные и чёткие правила игры.
На заре развития IT в ТЕХНОНИКОЛЬ IT-специалисты сами регулировали очередь заявок по принципу «кто первый, того и тапки». Казалось бы, принцип понятен, прозрачен. Но опыт показал — совсем не эффективен. Компания получила огромное число заявок, суммарная трудоёмкость которых составляла тысячи человеко-часов, и такое же количество жалоб на то, что важные заявки ждут своей очереди, пока выполняются второстепенные.
«Продвинутые» IТ-разработчики нашли свой способ приоритизации: из общего пула задач желающие больше сделать выбирали самые простые и быстро реализуемые заявки, а самые любознательные и ориентированные на личное развитие — самые интересные или головоломные. Всем хорош этот подход, кроме того, что не имеет отношения к интересам и прибыли корпорации.
Поэтому на следующем витке развития было решено ввести механизм принудительной эскалации заявок. По решению высшего руководства или экспертов, какая-то важная заявка могла пройти без очереди. Однако и этот подход на поверку оказался совсем не рациональным. Непонятно было, как найти экспертов, способных объективно определять очерёдность, как избежать договорённостей между заказчиками и экспертами по внеочередному продвижению заявок. Вопросов было больше, чем ответов. Сам процесс перестал быть прозрачным.
И когда ситуация с количеством заявок неумолимо приблизилась к катастрофической, нашлось и решение. IT-служба — это исполнитель, она не может заниматься расстановкой приоритетов и целей.
Системный подход
Прежде чем систематизировать поток заявок, нужно было понять причины такого большого их объёма. Для этого все заявки разделили на две большие группы:
1) инциденты — проблемы, которые возникают в операционном режиме;
2) доработки систем и процессов.
Очевидно, что первая группа проблем требует безотлагательного решения. А вот анализ второй принёс несколько неожиданных открытий:
• Львиную долю обращений из этой группы составляли короткие заявки трудоёмкостью до 10 человеко-часов (это вместе с тестированием, документированием, исправлением, сборкой), которые вполне можно было отрабатывать очень оперативно.
• Около 30% заявок устарели и вообще не нужны заказчикам, потребность в них исчезла, но заявители просто забыли об этом сообщить IT-специалистам.
• Оказалось, что многие бизнес-заказчики увидели в IT-системах очень удобный инструментарий для тестирования своих новых гипотез. Для конкретного руководителя или специалиста IТ-служба представляется условно бесплатной. После реализации эксперимента бизнес оценивал его эффективность и принимал решение, двигаться дальше или нет. При этом окупаемость подобных задач никто не считал.
Такой подробный анализ показал, что IT-служба треть своего времени работает, что называется, «в корзину».
Повышаем эффективность
Вслед за анализом последовали и решительные действия. Для начала сформировали отдельную очередь заявок с небольшой трудоёмкостью исполнения. Тем самым удалось повысить удовлетворённость заказчиков, которые раньше ожидали решения своей проблемы месяцами.
Второй шаг потребовал использования административного ресурса и был зафиксирован на уровне генерального директора ТЕХНОНИКОЛЬ: все тренировки и манипуляции с новыми или изменёнными процессами должны впредь проводиться без привлечения автоматизации.
Только после того, как вручную выстроенный процесс стабильно проработает не менее трёх месяцев и покажет себя эффективным, можно будет подавать заявку на доработку сложной и дорогой системы.
Третий шаг был ещё более серьезным и потребовал полной реорганизации процесса разработки. Вначале согласовали основные принципы:
• приоритеты заявок определяются бизнес-заказчиками и владельцами процессов;
• в разработку должны попадать только заявки, реально необходимые бизнесу;
• ресурс IТ-разработки ограничен, и значительное увеличение затрат на изменения системы возможно только из бюджета заказчика.
В итоге сформировали несколько очередей:
• доработки для финансовой службы;
• доработки для ОКСа;
• доработки по транспортной логистике;
• доработки для бизнес-единиц (включающие доработки централизованных систем для производственных площадок) и т. д.
Для каждой из очередей был определён «владелец очереди», который проводил анализ поступающих заявок и принимал решение о приоритете той или иной заявки. Он также мог приостанавливать разработку заявки, менять приоритеты в динамике, объединять заявки, вносить свои предложения и идеи.
Также для каждой из очередей был определён гарантированный ресурс в человеко-часах в месяц. Бизнес-заказчик, которому не хватало выделенного ресурса, мог за свой счёт увеличить ресурс для своей очереди путём привлечения проверенных аутсорсинговых компаний.
IT-дирекция гарантировала, что все заявки, попавшие в ресурсный пул, будут выполнены в обещанные сроки. Если IT-служба не справлялась, то исправляла ошибки за свой счёт.
Итоги перемен
Результаты не заставили себя ждать. Эффект был заметен по нескольким направлениям:
• Система стала саморегулируемой. Заявки, имеющие низкий приоритет и не включённые владельцем очереди в пул разработки на месяц, автоматически не попадали в работу, и работа по ним даже не начиналась.
• Приоритеты заявок стали устанавливать и динамически изменять представители бизнеса, способные правильно и взвешенно оценить нужность той или иной разработки.
• Повысилась прозрачность системы. Каждый месяц бизнес-заказчики имели возможность повлиять на приоритеты своих заявок. Доказали важность и необходимость — заявка попала в пул разработки и гарантированно будет выполнена.
Данная система проработала в компании не менее двух лет, тактические задачи успешно решила, показала себя достаточно эффективной. Да и конфликтов стало заметно меньше.