Цифровая трансформация Service Desk глазами PM

Экскурс в прошлое

Я работаю в компании ICL Services уже больше 4 лет, и начинал с позиции специалиста технической поддержки на крупном проекте. Сейчас я руковожу группой ITSM в направлении Service Desk – у меня сосредоточены компетенции по развертыванию и настройке ITSM-систем, управлению IT-процессами (Incident, Change, Problem Management). По факту, без преувеличения могу сказать: в моей группе работают самые скилловые люди в области SD.

Особенность большой компании, которую я обнаружил, поработав в ней примерно полгода с момента трудоустройства, следующая: люди редко делились своими наработками. Не потому, что жадные, а просто им глубоко лень было объяснять коллегам, в чем выгода. Ведь, как оно зачастую бывает, по большей части здесь все были технарями с давно устоявшимися отношениями.

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

Но эти наработки оставались индивидуальными и не шарились на всю команду проекта, не говоря уже о каких-либо внедрениях на похожих проектах. Как сказал мой руководитель, мы всегда изобретали свой велосипед самостоятельно – и был по делу прав. Разумеется, тут был и человеческий фактор: например, был и кто-то опытнее, и ему не с руки использовать наработки «молодняка». И особая классика – «а вот с ним у нас личный конфликт, я не буду применять инструменты, которые он применяет».

Удачно для меня, и в целом для всего нашего отдела, внедрялись и обкатывались новые подходы к процессам. Тонны документации, вой со стороны пользователей и групп поддержки – все как обычно. Мне удалось протащить улучшения, которые я видел, но самое важное – удалось вовлечь почти всех ребят в совместную работу над сервисом. Ведь вы знаете, на что способна команда, которая объединилась против проблемы? У проблемы не остается шансов. Заказчик ввел новый показатель – процент ошибок при заполнении заявок. На старте он был около 10% на команду, то есть около 200 заявок имели как мелкие ошибки, так и существенные.

Линейный и проектный руководители говорили: «невозможно уменьшить процент ошибок еще больше – люди есть люди, и они всегда будут ошибаться». Мы растиражировали веб-приложение, которое написал наш ведущий спец, расставили точки контроля и регулярно снимали информацию по этим показателям, отрабатывали специфичные случаи: когда ITSM-система сама подставляет нужные поля из Active Directory, на что обратить внимание. Результат не заставил себя ждать – за полгода мы довели % ошибок в месяц до критично низкого уровня 0-0.6% на команду.

И примерно в этот момент моей карьеры я понял две вещи:

• 1. Я хочу работать в крутой команде, и ее цельный результат работы намного лучше, чем тот, что может сделать даже самый гениальный сотрудник. Это решение позже точно приведет меня в менеджмент.
• 2. Я хочу объединять наработки талантливых, крутых ребят в единую систему, которая лучше, надежнее, быстрее, чем та, что была у вас до этого.

 

О старте проекта и его результатах и продуктах читайте далее на Хабре.