Хотели навести порядок в бизнес-процессах, а получили дорогую форму для обращений

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

Меня зовут Станислав Гуляев, я руководитель группы систем управления услугами, процессами и активами в операторе ИТ-решений «ОБИТ». За годы работы с проектами внедрения систем управления ИТ-услугами (ITSM) я заметил одну закономерность: технические сложности редко становятся главной причиной неудачи проекта. Гораздо чаще причина лежит на поверхности — когда компания пытается автоматизировать процессы, которые не готовы к автоматизации. В материале я подробнее расскажу, зачем нужен ITSM, по каким признакам понять, готова ли компания к нему, и как попытки «подогнать систему под себя» могут увеличить бюджет проекта в десятки раз.

Для начала разберёмся с базовым понятием — услугой. Большинство людей сразу представят клининг, доставку, автосервис или химчистку. Но внутри бизнеса услуг гораздо больше, просто они редко воспринимаются именно в таком контексте. Замена клавиатуры сотруднику, выдача доступа к корпоративным ресурсам или оформление справки 2-НДФЛ — всё это тоже относится к услугам.

Услуга формируется, когда есть чёткое понимание:

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

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

В нашем примере сотрудник открывает каталог и выбирает услугу «Настройка удалённого рабочего стола». Перед отправкой заявки он видит:

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

Часто ITSM ошибочно воспринимают исключительно как инструмент для управления ИТ-подразделениями. На практике же сервисный подход намного шире — он объединяет работу всех внутренних подразделений (бухгалтерия, юристы и т.д.) и предоставляемые услуги для внешних заказчиков.

Пройдя через огонь, воду и десятки удачных и не очень проектов по внедрению ITSM я могу с уверенностью заявить: основная проблема большинства компаний — отсутствие описанных бизнес-процессов. А если процесс нигде не зафиксирован, на его автоматизацию потребуется потратить x10 ресурсов.

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

Если всё работает, зачем что-то менять? На самом деле ITSM нужна не только для удобства сотрудников, в первую очередь она помогает руководству в принятии управленческих и стратегических решений. Аналитика, собранная с ITSM, может дать ответы на такие вопросы:

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

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

Ответы оказались весьма показательными — формализованных процессов практически не было, а каталог услуг отсутствовал. При этом требования к будущей системе сводились к тому, что она должна работать примерно так же, как старая платформа, но с учётом множества накопившихся доработок и с учётом того, что клиент не готов менять внутренние бизнес-процессы под ITSM-практики, но в то же время ему нужны какие-то вещи, которые есть в ITSM-системах. Мы поняли, что нам нужна система, которая как пластилин, из которой мы сможем слепить то, что необходимо.

Важно понимать, что сами ITSM-системы тоже сильно отличаются между собой и подходят под разные задачи:

Исходя из предоставленных ответов нам нужен был именно третий вариант.

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

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

Если ТЗ описывает проект на верхнем уровне, то ЧТЗ декомпозирует его до частных составляющих и описаний:

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

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

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

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

Мы переписали его полностью, и теперь виджет позволяет:

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

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

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

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

Но! При хорошем раскладе ITSM-система становится не просто инструментом работы с обращениями, а механизмом анализа, контроля и оптимизации бизнеса, и именно в этом её настоящая ценность.