Регламенты писали вместе с системой, а не после неё

Что болело

В источнике не сказано. Кейс написан как перечень выполненных работ, и состояние «до» в нём не описано.

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

Что хотели получить

Три цели, названные в кейсе прямо:

1. Спроектировать процессы и создать регламенты управления инцидентами, проблемами и уровнем услуг.
2. Повысить квалификацию сотрудников компании.
3. Развернуть и запустить систему Service Desk.

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

Что сделали

Консалтинговая часть — проектирование процессов INCУправление инцидентами, PRBУправление проблемами и SLMУправление уровнем обслуживания с написанием регламентов под каждый. Техническая — развёртывание Service Desk «Итилиум» на нижегородской площадке, больше чем на 5000 пользователей.

Разбить работу на этапы по источнику нельзя: он их не приводит.

Ценность кейса — в самом порядке действий. Регламенты писали вместе с системой, а не после неё. Обратный ход выглядит быстрее и почти всегда даёт один и тот же результат: система настроена по умолчаниям поставщика, а регламент пишут через год под то, что уже сложилось, — и он описывает не порядок, а привычки.

Чем автоматизировали

Service Desk «Итилиум» на платформе «1С:Предприятие 8», разработчик — «Деснол Софт».

Включение продукта в единый реестр российских программ мы не проверяли: на сайте разработчика реестровая запись не указана. В паспорте проекта это поле стоит пустым намеренно — писать «российское» со слов вендора мы не будем.

Что получилось

Процессы описаны регламентами, система развёрнута, поддержка обучена. Цифр «до и после» в источнике нет: ни времени решения, ни доли повторных обращений, ни числа заявок.

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

Что не получилось и где было тяжело

В источнике нет.

Это не значит, что всё прошло гладко, — это значит, что раздел не писали. Кейс на сайте разработчика решает задачу продажи, и трудности в такой текст не попадают по определению.

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

Что отсюда забрать

1. Регламент и система собираются вместе. Порядок «сначала внедрим, потом опишем» даёт систему, настроенную по умолчаниям, и регламент, списанный с них же.
2. Обучение — до запуска, а не после. Тогда учат процессу и ролям, а не расположению кнопок.
3. Уровень услуг взяли сразу с инцидентами. SLMУправление уровнем обслуживания обычно откладывают, и тогда сроки решения оказываются взяты из головы, а не согласованы с заказчиком.
4. Вендорский кейс читайте как заявку, а не как отчёт. Здесь нет ни сроков, ни цифр, ни трудностей — три признака того, что текст писали не для того, чтобы его повторили.

На какую зрелость это тянет

Судя по описанию — третий уровень по практикам INCУправление инцидентами и PRBУправление проблемами: порядок описан регламентами и применяется. Выше подняться на этих данных нельзя: чтобы говорить об управляемом уровне, нужны показатели процесса, а их в источнике нет.