Как провести диагностику и систематизировать требования бизнеса, рассказывает руководитель направления компании-интегратора Ferrum IT Group Григорий Розов.
При внедрении ITSM (IT Service Management) принципиальное значение имеет не столько построение модели идеального процесса, сколько точное понимание проблем, с которыми столкнулась компания, и их оценка в денежном выражении.
Этап диагностики
Первое, что необходимо сделать при внедрении ITSM – исследовать имеющиеся процессы в организации и оценить зрелость компании с точки зрения объекта автоматизации. При этом первым сигналом, который может служить для осознания потребности в выстраивании процессов ITSM могут служить, казалось бы, весьма локальные проблемы. Например, сотрудники обнаружат, что сроки исполнения заявок постоянно растягиваются. Или, например, возникнет ситуация, при которой сотрудникам постоянно не хватает оборудования, хотя, казалось бы, все закупается в нужных объемах и согласно плану. Наконец, проблема может быть сформулирована как регулярное нарушение регламентных процедур, будь то обходы или ревизии при том, что применение штрафных мер не помогает.
При исследовании таких проблем можно обнаружить неочевидные причины сложившейся ситуации. В предложенном примере с закупкой оборудования моей командой было обнаружено, что хотя оборудование действительно закупается, но пользовались им те, кто осуществлял получение, а не те, кто создавал заявку. То есть одни эксперты на ежегодном бюджетном комитете сумели доказать целесообразность и необходимость получения оборудования, а пользовались им совершенно другие сотрудники – те, кто был ближе к закупкам. В итоге заявки на получение оборудования могут закрываться годами, с такими примерами сталкивался из собственного опыта.
Описание текущих процессов
В рамках одного из самых сложных этапов, который называется описанием процессов AS-IS (текущие процессы компании) нужно сформировать рабочие группы из каждого подразделения участника-процесса. Основная сложность состоит не в том, чтобы схематично нарисовать процесс, а в том, что собрать как можно больше деталей, характеризующих реальную ситуацию на предприятии и дающих ясное видение текущей картины. Дополнительно, этот этап затрудняется тем, что на уровне специалистов и инженеров никто не хочет ничего менять, предпочитая работать старыми способами. Доводы могут быть разные, например, предыдущая оптимизация существенно добавила нагрузки ввиду сокращения персонала или предыдущие консультанты не вникли в детали процессов и причины их работы именно в текущей форме, а выполнили поверхностную оценку.
Создание нового процесса
Целью следующего этапа TO BE является формулирование такого процесса (в рамках библиотеки знаний ITIL), в котором учтены все недостатки, выявленные на предыдущем этапе. При чём важно не только смоделировать процесс, но и понимать, какую пользу он принесет с точки зрения сокращения потерь. Под потерями я подразумеваю в первую очередь деньги. Почему потери проще всего выражать в деньгах? Потому что далеко не всегда инженер может объяснить финансисту, для чего требуются затраты на новое оборудование или ПО с точки зрения сокращения затрат предприятия. А значит и бюджетный комитет будет проходить проще, если «оцифровать» сокращение потерь в деньгах, так как затраты на консультантов тоже выполняются в деньгах. Тогда можно говорить о некой окупаемости затрат, иначе оптимизация не будет иметь смысла.
Хороший пример для иллюстрации: кейс о работе стойки регистрации в аэропорту. На первый взгляд казалось, что заявки выполняются, отчеты выглядят корректно. Но выборочная проверка выявила, что регламентные работы не выполняются, оборудование в некоторых местах выходит из строя, при этом скорость возврата в эксплуатацию низкая, так как часть людей ушла в отпуск, а ЗИПа на складе недостаточно или уже закончился к третьему кварталу. Нерегулярная работа стойки регистрации приводит к задержке посадки, которую уже легко измерить в денежном выражении. В приведенном примере не работал процесс управления конфигурациями (ввод/вывод оборудования/ЗИП в системе учета в эксплуатацию со склада), не был доработан инцидент-менеджент, хромало управление ресурсами в части обеспечения процесса людьми. Примеров многомиллионных потерь по причине халатного/некомпетентного расчёта материальных затрат на обеспечение человеческими ресурсами важного процесса достаточно. Дополнительно хочу отметить, что гнаться за полной автоматизацией...
