ITSM4U Диагностика 7 мин

Кто это уже делал и чем закончилось

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

Отрасль
Масштаб
Повод

Восемь процессов ITSM собрали на одной российской платформе за пять лет

Газпром нефть

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

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

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

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

Перенос обошёлся дорого: конвертация кода потребовала выбросить устаревшие DLL, изменить больше 11 000 файлов и заново разложить права доступа при миграции данных.

Открыть разбор →
Отрасль
ТЭК
Масштаб
Свыше 5000
Чем автоматизировали
BPMSoft Конструктор, ITSMbox для BPMSoft
Реестр РФ
да
Сроки
март 2019 — февраль 2024
Повод
Импортозамещение, Замена платформы

Источник: Карточка проекта в конкурсе «Проект года», Global CIO
проверен 2026-08-16
Разобран целиком

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

Консалтинговый центр «Группа ГАЗ»

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

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

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

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

Нет в источнике. Страница кейса написана как перечень работ: ни сроков, ни цифр «до и после», ни трудностей. Что пошло не так — из неё узнать нельзя.

Открыть разбор →
Отрасль
Промышленность
Масштаб
Свыше 5000
Чем автоматизировали
Service Desk «Итилиум»
Реестр РФ
да
Сроки
Нет в источнике
Повод
Первое внедрение с нуля

Источник: Кейс на сайте разработчика «Итилиум»
проверен 2026-08-16
Разобран целиком

Смена платформы, за которой пришлось пересобирать контур поддержки

«Вкусно — и точка»

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

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

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

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

Нет в источнике.

Открыть разбор →
Отрасль
Ритейл и e-commerce
Масштаб
Свыше 5000
Чем автоматизировали
SimpleOne ITSM
Реестр РФ
да
Сроки
май — октябрь 2023
Повод
Импортозамещение, Замена платформы

Источник: Карточка проекта в TAdviser
проверен 2026-08-16
Коротко

Процесс переписали, потому что изменилась оргструктура

Телекоммуникационная компания

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

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

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

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

Нет в источнике.

Открыть разбор →
Отрасль
Телеком
Масштаб
Свыше 5000
Чем автоматизировали
Заказное решение на BMC Remedy
Реестр РФ
нет, зарубежное
Сроки
эксплуатируется с начала 2016 года
Повод
Слияние и реорганизация

Источник: Описание проекта на сайте интегратора
проверен 2026-08-16
Коротко

Поддержка, у которой нет первой линии

Небольшие сервисные компании

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

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

В источнике не выделено отдельно.

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

В источнике не написано. Это не значит, что всё прошло гладко.

Открыть первоисточник ↗
Отрасль
Услуги
Масштаб
До 500
Чем автоматизировали
Okdesk
Реестр РФ
да
Сроки
Подборка историй — единого срока нет
Повод
Первое внедрение с нуля

Источник: Раздел клиентских историй у вендора
проверен 2026-08-16
Заготовка

Управление доступом заменили на отечественное за восемь месяцев

АШАН Ритейл Россия

IBM Tivoli Identity Manager заменили на отечественную платформу Avanpost. Восемь месяцев работы, около 25 000 пользователей. Система связана с SAP ERP, Microsoft Active Directory и почтой Яндекс 360; объединены создание учётных записей, оформление подрядчиков и администрирование доступа.

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

Публичных внедрений с названными сроком и охватом мало, поэтому сами цифры ценны: восемь месяцев на 25 000 пользователей — ориентир, с которым можно сверять собственные планы.

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

В источнике не написано. Это не значит, что всё прошло гладко.

Открыть первоисточник ↗
Отрасль
Ритейл
Масштаб
Свыше 5000
Чем автоматизировали
Avanpost IDM
Реестр РФ
да
Сроки
Нет в источнике
Повод
Импортозамещение, Замена платформы

Источник: Сообщение о проекте, Global CIO, 12 августа 2026
проверен 2026-08-17
Заготовка

Управление проблемами запустили как отдельную функцию, а не как процесс на бумаге

X5 Tech

Управление проблемами существовало с 2017 года, охватывало не больше 3 % инцидентов и держалось на двух менеджерах, у которых были и другие задачи. Данные о причинах жили в таблицах и блокнотах. Практику запустили заново: выделенные роли, единая команда аналитиков и комитет, который решает, что признать известной ошибкой.

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

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

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

Проект не завершён, и авторы говорят об этом прямо: покрытие ещё неполное, взаимодействие с управлением событиями не выстроено, оценка качества проблем ресурсозатратна. Инструмент проверки привязки инцидентов даёт корректность 80 % и более — то есть каждая пятая привязка может быть неверной, и это принято сознательно как рабочий уровень. Система автоматизации в статье не названа ни разу, поэтому перенести можно устройство работы, но не выбор инструмента.

Открыть разбор →
Отрасль
Розничная торговля
Масштаб
Свыше 5000
Чем автоматизировали
Собственная ITSM-система
Реестр РФ
не проверяли
Сроки
октябрь 2023 — продолжается
Повод
Повторяющиеся инциденты, Нельзя дальше расширять штат поддержки

Источник: «Problem Management или как превратить проблемы в возможности», блог X5 Tech на Хабре
проверен 2026-08-17
Разобран целиком

Доступность посчитали одним способом и подняли с 97,3% до 98,5%

Департамент информационных технологий города Москвы (ДИТ Москвы)

Городской портал mos.ru обслуживают 35 самостоятельных подразделений и 22 подрядчика, у каждого была своя система мониторинга, и о падении сервиса часто узнавали от пользователей раньше, чем от собственных систем. Зонтичный мониторинг связал 87 информационных систем в одну картину и завязал на неё расчёт доступности и SLA-отчётность.

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

Доступность здесь не разовый замер: она встроена в постоянный контур, где данные идут от 2600+ триггеров по 7000+ метрикам, а не собираются вручную под отчёт раз в месяц.

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

Кейс с сайта вендора: сравнение «было — стало» независимо не проверить, а слово «доступность» не расшифровано — по какой из трёх методик её считали (по инцидентам, по инфраструктуре или по синтетике), в тексте не сказано, хотя от выбора методики зависит сама цифра.

Открыть разбор →
Отрасль
Государственное управление
Масштаб
Свыше 5000
Чем автоматизировали
Monq
Реестр РФ
да
Сроки
Нет в источнике
Повод
Мониторинг разрозненных подрядчиков, Пользователи узнавали о сбое раньше службы поддержки

Источник: «ДИТ Москвы × Monq: кейс внедрения зонтичного мониторинга», сайт вендора
проверен 2026-08-31
Разобран целиком

Резервные каналы связи поставили под SLA-мониторинг раньше, чем они понадобились

Сбербанк России, Северо-Кавказский банк

На резервных междугородных каналах связи филиалов Северо-Кавказского банка поставили систему постоянного контроля качества: 171 зонд wiProbe следил больше чем за 160 каналами в семи республиках и краях региона и показывал, держит ли резерв нужные параметры ещё до того, как откажет основная линия.

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

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

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

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

Открыть разбор →
Отрасль
Финансы и банкинг
Масштаб
Свыше 5000
Чем автоматизировали
wiSLA (Wellink)
Реестр РФ
нет, зарубежное
Сроки
декабрь 2013 — октябрь 2015
Повод
Резервные каналы связи без контроля качества, Требование непрерывности обслуживания филиалов

Источник: Карточка проекта в конкурсе, Global CIO
проверен 2026-08-31
Разобран целиком

Надёжность выразили в минутах бюджета ошибок, а не только в процентах

Т-Банк

На масштабе 45 млн клиентов банк формализовал доступность через цепочку SLI → SLO → SLA и бюджет ошибок: для цели 99,99% за год это ровно 52 минуты 35 секунд простоя, которые можно потратить, не нарушив обещание. Инструменты — Sage вместо «зоопарка» разрозненного мониторинга и FineDog для учёта нарушений SLA — построены под этот расчёт, а не наоборот.

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

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

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

Статья объясняет методику и инструменты, но не приводит ни одной цифры «было — стало»: какой была доступность до перехода на эту модель и насколько выросла после — не сказано.

Открыть разбор →
Отрасль
Финансы и банкинг
Масштаб
Свыше 5000
Чем автоматизировали
Sage, FineDog
Реестр РФ
нет, зарубежное
Сроки
Нет в источнике
Повод
Рост масштаба до 45 млн клиентов, Разрозненные инструменты мониторинга

Источник: «Надёжность на масштабе в 45 млн клиентов — инструменты и практики», блог Т-Банка на Хабре
проверен 2026-08-31
Разобран целиком

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

Компанию называем, когда её назвал источник. Если в источнике заказчик не назван, в карточке стоит класс компании, а не выдуманное имя.