Короткий путь от проектирования процессов к быстрому внедрению ITSM-системы

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

Подход к внедрению

Как правило, проекты внедрения строятся по принципу «давайте соберем требования, подготовим техзадание, разработаем по нему ИТ-систему, настроим, испытаем и начнем эксплуатировать». Такой подход требует значительных ресурсов и времени. При этом положительный результат не гарантирован, и по итогам проекта велика вероятность получить Конкорд и Берлинский аэропорт одновременно.

Проектный опыт показывает, что подход можно изменить и сместить акцент на эксплуатацию ИТ-системы. Подобный сценарий предполагает концентрацию усилий на том, чтобы сформировать компетенции по внедряемым процессам и запускаемой системе в целом.

В основе этого подхода лежит использование готовых процессов управления, которые поддерживаются внедряемым продуктом.

Считается, что на старте ИТ-система должна состоять из трех важных компонентов:

• программное обеспечение (ПО),
• регламентированные процессы,
• начальные данные и нормативно-справочная информация.

Отдельный аспект — наличие персонала, который обладает экспертизой по запускаемым процессам.

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

Адаптация под нужные требования

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

По сути, готовая процессная модель — это аккумулирование проектного опыта вендора, а инструмент автоматизации, в свою очередь, позволяет ее гибко адаптировать с помощью no-code технологий.

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

Вместе с тем всегда есть вариант отойти от использования типовой системы. Обратная сторона такого шага — установка обновлений продукта будет затруднена из-за самостоятельно внесенных клиентом изменений.

Разграничение зон ответственности

На старте проекта необходимо определить состав команды со стороны клиента. В нее входят:

• менеджеры каталога услуг,
• менеджеры процессов,
• менеджеры услуг.

Для этих специалистов потребуется провести курсы, погружающие в специфику автоматизируемых процессов.

Дальше менеджеры могут приступать к формированию каталога услуг в системе, получая консультации вендора по сложным вопросам.

А почему бы не ускорить процесс и составить каталог руками подрядчика? Ведь он знает, как сделать правильнее и быстрее. Вопрос отчасти риторический, т.к. такие риски клиенты стараются исключать и обеспечивают себе достаточный уровень знаний для последующей самостоятельной работы.

Каталог услуг можно подготовить с помощью подрядчика. Только что будет делать клиент после проекта, когда у специалистов компании не будет хватать компетенций на поддержку системы. Лучше, если у подрядчика есть типовой каталог услуг, который можно взять за основу, чтобы не начинать с чистого листа.

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

Изменение процессов

Если нужны изменения под задачи клиента, сначала ищем решение в процессах и возможностях продукта. Не исключено, что придется менять не запускаемые процессы, а привычки, которые складывались годами. Это самая сложная часть, т.к. приходится пройти всю гамму эмоций от отрицания до принятия изменений.

Но если изменения обусловлены объективными причинами, то регистрируем предложения об изменении и описываем сценарий, для поддержки которого оно требуется.

Следует отметить, что в проекте быстрого внедрения без проектирования и разработки все же не обойтись. Например, это касается специализированных интеграций. Кроме того, базовая интеграция с Active Directory для аутентификации и импорта учетных записей сотрудников может потребовать уточнения источников этих записей либо уникальных атрибутов из хранилища данных.

Индивидуальные настройки

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

Каталог услуг. Отдельная разработка не нужна. Необходимо понимание принципов маршрутизации и создания потока ценности (композитные запросы), расчета SLA, согласования запросов, формирования плановых работ, иерархической эскалации и т.п.

Интеграции. Поддерживаются прямые SQL-запросы в базу данных источника, XML, CSV, веб-сервисы, LDAP-каталоги.

Почтовые оповещения. Изменение текста, оформления, отключение неактуальных настроек. Для доработки шаблона потребуется знание HTML-верстки.

Центр компетенций

Подготовленные специалисты клиента, которые прошли запуск системы, образуют центр компетенций.

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

В обычном проекте внедрения подход другой. Там проводятся презентации, где обсуждается каждый процесс. Это приводит к тому, что перечень автоматизируемых процессов может меняться, а значит специалисты клиента увидят конкретную реализацию позже, а готовую систему еще позднее. И время, которое можно направить на погружение в процессы, уходит на обсуждение и проектирование. Негативный сценарий такого подхода — возврат к ранее предлагаемым вариантам или незначительные изменения.

Быстрое развертывание

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

Если сравнить быстрое развертывание и классический подход к внедрению, то они значительно отличаются уже после этапа инициации проекта.

При внедрении готового решения одновременно начинается подготовка стендов для установки ПО, настройка базовых интеграций, формирование центра компетенций и реализация дополнительных интеграций (если они есть).

Установка ПО и настройка базовых интеграций занимают две-три недели. Когда стенд готов, проводятся семинары по процессам и работе в системе. С третьей-четвертой недели после начала проекта специалисты начинают работать в инструменте автоматизации, и делают это еще полтора-два месяца до окончания запуска.

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

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

В итоге примерно с шестой недели начинается полноценная эксплуатация системы, а еще через две-четыре недели — промышленная эксплуатация и запуск новых услуг.

Часто ли встречаются «классические» проекты, в которых общая длительность плотной работы в системе больше полутора месяцев? Сколько длился такой проект до этой точки? И какова его стоимость?

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

Ссылка на источник