Анализ требований бизнеса перед внедрением ITSM: выявление проблем
shutterstock.com/ru/g/dizain
При внедрении ITSM (IT Service Management) принципиальное значение имеет не столько построение модели идеального процесса, сколько точное понимание проблем, с которыми столкнулась компания, и их оценка в денежном выражении.
Этап диагностики
Первое, что необходимо сделать при внедрении ITSM – исследовать имеющиеся процессы в организации и оценить зрелость компании с точки зрения объекта автоматизации. При этом первым сигналом, который может служить для осознания потребности в выстраивании процессов ITSM могут служить, казалось бы, весьма локальные проблемы. Например, сотрудники обнаружат, что сроки исполнения заявок постоянно растягиваются. Или, например, возникнет ситуация, при которой сотрудникам постоянно не хватает оборудования, хотя, казалось бы, все закупается в нужных объемах и согласно плану. Наконец, проблема может быть сформулирована как регулярное нарушение регламентных процедур, будь то обходы или ревизии при том, что применение штрафных мер не помогает.
При исследовании таких проблем можно обнаружить неочевидные причины сложившейся ситуации. В предложенном примере с закупкой оборудования моей командой было обнаружено, что хотя оборудование действительно закупается, но пользовались им те, кто осуществлял получение, а не те, кто создавал заявку. То есть одни эксперты на ежегодном бюджетном комитете сумели доказать целесообразность и необходимость получения оборудования, а пользовались им совершенно другие сотрудники – те, кто был ближе к закупкам. В итоге заявки на получение оборудования могут закрываться годами, с такими примерами сталкивался из собственного опыта.
Описание текущих процессов
В рамках одного из самых сложных этапов, который называется описанием процессов AS-IS (текущие процессы компании) нужно сформировать рабочие группы из каждого подразделения участника-процесса. Основная сложность состоит не в том, чтобы схематично нарисовать процесс, а в том, что собрать как можно больше деталей, характеризующих реальную ситуацию на предприятии и дающих ясное видение текущей картины. Дополнительно, этот этап затрудняется тем, что на уровне специалистов и инженеров никто не хочет ничего менять, предпочитая работать старыми способами. Доводы могут быть разные, например, предыдущая оптимизация существенно добавила нагрузки ввиду сокращения персонала или предыдущие консультанты не вникли в детали процессов и причины их работы именно в текущей форме, а выполнили поверхностную оценку.
Создание нового процесса
Целью следующего этапа TO BE является формулирование такого процесса (в рамках библиотеки знаний ITIL), в котором учтены все недостатки, выявленные на предыдущем этапе. При чём важно не только смоделировать процесс, но и понимать, какую пользу он принесет с точки зрения сокращения потерь. Под потерями я подразумеваю в первую очередь деньги. Почему потери проще всего выражать в деньгах? Потому что далеко не всегда инженер может объяснить финансисту, для чего требуются затраты на новое оборудование или ПО с точки зрения сокращения затрат предприятия. А значит и бюджетный комитет будет проходить проще, если «оцифровать» сокращение потерь в деньгах, так как затраты на консультантов тоже выполняются в деньгах. Тогда можно говорить о некой окупаемости затрат, иначе оптимизация не будет иметь смысла.
Хороший пример для иллюстрации: кейс о работе стойки регистрации в аэропорту. На первый взгляд казалось, что заявки выполняются, отчеты выглядят корректно. Но выборочная проверка выявила, что регламентные работы не выполняются, оборудование в некоторых местах выходит из строя, при этом скорость возврата в эксплуатацию низкая, так как часть людей ушла в отпуск, а ЗИПа на складе недостаточно или уже закончился к третьему кварталу. Нерегулярная работа стойки регистрации приводит к задержке посадки, которую уже легко измерить в денежном выражении. В приведенном примере не работал процесс управления конфигурациями (ввод/вывод оборудования/ЗИП в системе учета в эксплуатацию со склада), не был доработан инцидент-менеджент, хромало управление ресурсами в части обеспечения процесса людьми. Примеров многомиллионных потерь по причине халатного/некомпетентного расчёта материальных затрат на обеспечение человеческими ресурсами важного процесса достаточно. Дополнительно хочу отметить, что гнаться за полной автоматизацией не нужно. На этапе формирования процесса TO BE важно учитывать реальные возможности. Ведь если реальный уровень зрелости ИТ-процессов низкий, то нужно определить разумные границы проекта автоматизации данной итерации, не пытаясь построить сразу всё, что доступно в библиотеке знаний ITIL.
Что ещё важно для внедрения ITSM
После определения требований, которые должны быть зафиксированы в описании процесса наступает черёд выбора решения согласно процессам TO BE, внедрение в тестовую среду и после проведения 2-3 циклов тестирования внедрение в опытную и промышленную эксплуатацию.
Отмечу, что даже после внедрения в промышленную эксплуатацию, через некоторое время следует начать повторное обследование и доработку процессов. Для этого в компании должна быть сформирована экспертная группа, которая привлекала и будет привлекать внешних консультантов, а контролировать ход разработки/модернизации процессов ITSM.
Чтобы экспертная группа реально влияла на изменение процессов предприятия, она должна быть подчинена CIO, а CEO и CIO должны быть заинтересованы в будущих изменениях. Без поддержки со стороны высшего руководства принципиально оптимизировать процессы ITSM будет либо слишком долго, либо вообще невозможно.
Опубликовано 27.04.2024
