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

Мне пришлось пройти все стадии от гнева («не буду я заявки заводить»), торга («ну сделай, я заявку потом заведу»), до принятия и понимания, насколько это классная система. Что все процессы можно описать и использовать систему не только для ИТ, но и для поддерживающих подразделений. Об этом и хочу рассказать в этой статье, пройдя по шагам от момента осознания необходимости в системе до перспектив внедрения.

Этап нулевой. Исключаем сюрпризы

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

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

Этап первый. Подбор системы

Ну всё. Мы решились и готовы внедрять, и на выходе нужна ITSM система, отвечающая нашим требованиям. На этапе выбора чаще всего коллаборация из нашей команды и заказчика приходит к трем вариантам – OTRS, VsDesk и SimpleOne, входящим в реестр отечественного ПО (что так важно в 2023 году, когда вендоры покинули рынок). Если упор идет на гибкость, вариацию модулей, интеграции, отчетность, настраиваемую ролевую модель, а в коробке есть преднастроенные процессы согласно ITIL, мы внедряем последнюю. Нередко ключевым параметром выбора становится то, что «Симплы» делают именно ESM-систему, и у вас появляется возможность единое окно по принципу Сервис Деска.

Этап второй. Подготовка и Q&A

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

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

Если же он не понимает их, наша задача – понять за него или подтолкнуть к решению, задавая правильные вопросы. Например: “Какую задачу мы решаем?”, “Какие проблемы клиент хочет решить, автоматизируя внутренние бизнес-процессы?”, “Какие проблемы возникают при работе в текущей информационной системе? (если, конечно, он её использует)”.

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

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

Этап третий. Формирование задач и аналитика проекта

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

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

Этап четвертый. Предельно четкое ТЗ и описание шагов

Для успешного завершения проекта всегда должно быть четко описанное ТЗ – в моей практике были случаи, где нечеткие формулировки или неполное описание приводило к плохим последствиям, а именно – недопониманию с заказчиком, увеличению сроков проекта и трудозатрат.

Вот обязательные пункты в ТЗ, которые необходимо включить, чтобы не сесть в лужу:

• CMDB (Configuration management database) — база данных управления конфигурацией, содержит информацию о составляющих ИТ-инфраструктуры;

• SLA или соглашение об уровне обслуживания, который заказчик ожидает от подрядчика. Прописываются метрики, по которым измеряется обслуживание, штрафы, если показатели не будут достигнуты, и т. д.;

• Организационная структура заказчика;

• Ролевая модель внутри оргструктуры;

• Инциденты на проектах со всевозможными сценариями их возникновения и развития;

• Запросы на обслуживание;

• Запросы на изменения.

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

Исторические данные, как правило, больше нужны нам при оценке трудозатрат и описании процессов. Заказчик же по опыту может обойтись и без них – достаточно данных за последние пару лет, а остальное можно смело не переносить.

Также клиенту могут понадобиться (а скорее всего они точно понадобятся) интеграции со сторонними сервисами. В этот список, как правило, входят:

• Active Directory,

• ПО для мониторинга, например Zabbix,

• мессенджер, например Telegram, либо соседняя информационная система.

По каждой интеграции нужно выяснить и описать основные требования, например объемы передаваемых данных и формат обмена данными. Есть ли специалисты по вышеуказанным системам в самой компании заказчика, или, если есть подобные специалисты со стороны интегратора, то предложить свои услуги. Как правило, в годных ITSM-системах есть уже готовые коробочные модули, REST API, и настроить нужную интеграцию не составит труда.

Полное и подробное описание вышеперечисленных пунктов в техническом задании дает нам понимание по фронту работ и возможным срокам реализации.

Этап пятый. Согласование ТЗ

Здесь, как и в сборе требований, важна роль аналитика и написанного им ТЗ. На этом этапе заказчику важно объяснить написанное, так как он может не понимать технических терминов и для чего вообще нужен тот или иной модуль.

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

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

Этап заключительный. Перспективы

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