От хаоса к системе: как повысить зрелость IT-службы вашей компании? (продолжение)

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

На связи снова Дмитрий Бессольцев – генеральный директор компании ALP ITSM, всем привет! В прошлой части материала я рассказал о ключевых факторах работы зрелой IT-службы, а сегодня поговорим уже о процессах оказания IT-услуг.

Как я уже упоминал, наладить IT-процессы сложнее всего. Представим, что IT-служба компании работает не лучшим образом, но руководство не хочет ее разгонять, решив вместо этого повысить ее зрелость. Что в этом случае делать? Пойдем от простого к сложному.

Процессы – то есть выполнение действий по алгоритму, регламенту – позволяют сделать услуги более качественными, предсказуемыми, измеримыми и повторяемыми. Если грамотный алгоритм позволил 5 раз подряд устранить сбой за 30 минут, с большой вероятностью и следующие 5 раз будет так же. Или хотя бы 4 раза, что тоже хорошо.

Процессы – следующий этап развития практик. Практику можно описать словами «обычно мы решаем такие задачи вот так». Процесс – «мы всегда решаем такие задачи вот так». Всегда – лучше, чем обычно. При условии, что процесс написан толково, имеет ответвления на случай непредвиденных ситуаций и используется в работе. Зрелые команды работают по процессам.

Принимать и выполнять запросы на обслуживание достаточно просто – это умеют делать в целом все IT-службы и специалисты. Например, нужно создать новый почтовый ящик, помочь пользователю сменить пароль, разблокировать учетную запись, установить новое рабочее место – не вопрос!

Как показывает практика, большинство IT-служб и специалистов умеют решать и инциденты: что-то сломалось – починили. Важно уловить суть базового процесса ITSM по управлению инцидентами: любой сбой должен решаться максимально быстро. И решение может быть как системным, так и обходным.

Обходные решения называют «костылями». Они помогают сотруднику продолжить свою работу в кратчайшие сроки после возникновения инцидента. Сломался принтер? Не ждем, когда его починят в сервисе, а переключаем сотрудника на соседний принтер.

Однако не все айтишники понимают, что нужно превратить эту практику в системный процесс. Это важно для повышения качества работы IT-службы. Эту функцию должен взять на себя IT-руководитель – посредник между бизнесом и IT-специалистами.

Чтобы превратить управление инцидентами и запросы на обслуживание в системный процесс, IT-руководителю нужно разработать регламент, который должен устраивать бизнес и соответствовать возможностям IT-службы.

Например, все инциденты должны регистрироваться в системе ServiceDesk. По каждому из них должны быть заполнены определенные поля: тема инцидента, кто обратился, как контактировать с человеком, описание инцидента, какой специалист взял на себя ответственность за его решение – то есть базовые вещи.

Потом нужно описать, как специалист будет решать инцидент. Если найти системное решение и «починить» в течение 15-ти минут не удается, то специалист ищет обходное решение. Примеры обходных решений можно также привести в регламенте, чтобы команда понимала, в каком направлении нужно думать.

Если решить задачу не получается, например, за 30 минут или за час, она эскалируется более квалифицированному специалисту. Или группе специалистов. Мы называем это переходом «на вторую линию поддержки».

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

Когда задача решается, специалист сообщает об этом пользователю и уточняет, действительно ли все работает. Если все ОК, этот инцидент закрывается. Система позволяет пользователю поставить оценку решению этого инцидента? Замечательно! Важное правило – если пользователь не подтвердил, что инцидент решен – считаем его нерешенным (назначается статус «ждем ответа от пользователя»).

С запросами на обслуживание ситуация аналогичная, даже чуть более простая. Разработать упрощенный регламент для выполнения запросов на обслуживание не составит труда.

Самое главное в выполнении регламента – занять строгую позицию, что теперь IT-служба будет действовать именно таким образом. При этом бизнесу нужно тоже привыкнуть к работе по регламенту. Например, если что-то сломалось, то нужно отправить заявку на устранение инцидента или заявку на обслуживание через соответствующую форму в ServiceDesk, позвонить по выделенному номеру телефона или написать на конкретный емейл (обычно helpdesk@ или support@).

Это как с единым номером 112: система обеспечивает вызов экстренных оперативных служб – тех, которые нужны, исходя из смысла обращения. Мы даже делали специальные настольные календари для своих клиентов, где был указан номер, куда нужно звонить в случае возникновения любого IT-вопроса.

Так мы делаем важную штуку, единую точку входа: сломалось – пиши или звони сюда. Такой расклад дисциплинирует не только IT-службу, но и сотрудников компании. Они тоже должны привыкнуть действовать по регламенту и процессу, если хотят получить решение. Одно дело — выловить айтишника в коридоре и попросить его настроить почту. Об этом он может забыть уже через 5 минут (и даже имеет право). А другое – создать заявку, которая зарегистрируется в системе и точно пойдет в работу.

Также отмечу, что регламент, который никогда не меняется – это мертвый регламент. Скорее всего, он давно устарел и все работают не так. Регламент должен развиваться, дорабатываться. Если какой-то момент не учли сразу – ничего страшного, документ нужно обновить, после чего оповестить об изменениях IT-команду и сотрудников компании. Большие изменения? Можно даже провести тренинг.

Главное, что нужно понимать: грамотно составленный регламент – один из первых важных шагов к зрелости IT-службы.

Проблема – это корневая, системная причина возникновения однотипных инцидентов. Например, периодически «отваливается» интернет. Можно перезагружать роутер (это решение инцидента). Но обновить прошивку на роутере, заменить кулер или сам роутер – после диагностики и установления точной причины – это уже системно, это решение проблемы.

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

Не нужно внедрять управление проблемами сразу. Чтобы подступиться к этому сложному процессу, IT-команде нужно 2-3 месяца поработать с процессом управления инцидентами. Привыкнуть действовать «по процессу», то есть с оглядкой на регламент.

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

Обычно не нужно придумывать ситуации – их хватает в любой компании. Это могут быть проблемы с работой серверов 1С, требующих постоянной перезагрузки, или сложности с восстановлением резервных копий.

Возможно, найдется определенный пул задач (особенно на стыке баз данных, 1С и Windows-сервера), который будет не под силу действующей IT-службе – ничего страшного. В этом случае можно привлечь компетенцию со стороны в виде сервисной IT-компании, это станет оптимальным решением.

Процесс управления проблемами тоже нужно описать в регламенте. Нужно обучить и назначить ответственного специалиста, который раз в месяц (или чаще) будет анализировать поступающие в систему ServiceDesk заявки и искать похожие между собой.

Такие заявки могут быть от одного пользователя или от разных, но со схожей темой. Если компания небольшая, то найти похожие заявки не составит труда – достаточно будет просто пробежаться по ним глазами. После этого нужно построить гипотезы и «раскопать», в чем заключается суть проблемы.

Если устранить проблему текущими ресурсами не получается, то нужно составить план устранения. Например, если на сервере недостаточно памяти для комфортной работы сотрудников, то компании нужно докупить оборудование. Дополнительная память должна решить проблему с «лагами».

Также можно попросить партнеров помочь с принятием решения. «Смотрите, у нас вот такой-то анамнез – это похоже на нехватку памяти, или проблема в чем-то другом?»

Главное, должна быть подтвержденная компетентным специалистом гипотеза, чтобы ее можно было реализовать. Как в маркетинге: чтобы привлечь клиентов, нужно тестировать разные гипотезы, и одна из них точно сработает. В IT похожая ситуация: устраняя проблему по одной из гипотез, нужно продолжать мониторить ситуацию и через какое-то время сделать чек. Если гипотеза оказалась верна и привела к решению проблемы (как в случае с дополнительной памятью на сервер) – отлично!

Нужно понимать, что в любой системе или процессе всегда есть одно или несколько «бутылочных горлышек» (по теории Голдратта), которые ограничивают общую производительность.

Когда вы устраняете одно «бутылочное горлышко», производительность системы может увеличиться, но это также может привести к образованию нового ограничения, о котором вы не знали ранее.

Подводя итог, нужно закрепить, что для грамотного управления проблемами понадобятся:

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

Как я уже говорил, IT-руководитель компании должен разработать процесс управления проблемами (и не только его) и управлять им. А для этого ему нужно понимать хотя бы основные принципы этого процесса.

В любом случае IT-руководителя нужно отправить на курсы ITIL и ITSM – не обязательно фундаментальные и глобальные. Даже после базовых курсов человек уже будет понимать основы процесса управления проблемами.

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

Знания и навыки, полученные в ходе обучения, увеличат эффективность работы команды. Это приведет к быстрому решению задач и улучшению качества работы. А еще (важный момент в управлении качеством) поможет минимизировать ошибки при выполнении задач, что снизит число рекламаций со стороны пользователей.

В следующей, третьей части статьи подробно расскажу о других важных процессах, включая управление регламентными работами и изменениями, мониторинг, SLA – не пропустите!