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

Меня зовут Евгений Котухов, я эксперт по внедрению и оптимизации ITSM/ITAM решений, официальный технологический партнер SimpleOne с 10-летней экспертизой в автоматизации ИТ-процессов. Реализовал десятки ESM-проектов для компаний госсектора, энергетики, торговли и финансов. Специализируюсь на быстрых внедрениях полного цикла с запуском от 2 месяцев — от аудита процессов до рабочего решения, включая сложные интеграции с корпоративными системами.
Сразу оговорюсь: ITSM нужен не только для автоматизации и оптимизации процессов. Это приятное следствие внедрения, а не первопричина. И ответ на вопрос «зачем» для разных ролей разный.
Для первой и второй линии поддержки вопрос вообще не стоит. Это их инструмент, с которым они работают каждый день — тут всё на поверхности.
А вот зачем ITSM IT-директору? Тут уже не так очевидно.
Можно сказать, что у каждого своя цель. Кто-то ставит, потому что модно-молодёжно. Кто-то получит за это премию. Кто-то реально видит в этом эффективность. Личная мотивация, как правило, упирается в три вещи: деньги, власть или контроль, дарующий отсутствие головной боли из-за задач, за которые приходится нести ответственность без адекватной возможности их выполнять — без прав и полномочий, зато с негативными последствиями за их невыполнение. Обсудим именно последнюю мотивацию.
Ответственность без видимости

Без ITSM руководитель отвечает за то, что физически не может ни увидеть целиком, ни измерить, ни доказать. Пока системы нет — вся операционка живёт в почте, в личках, в коридорных разговорах и в головах нескольких ключевых людей. И из этого вырастает три состояния, которые на самом деле одно.
Первое — ИТ-директор управляет вслепую и узнаёт о проблемах последним. Не из метрики, а от разъярённого топа. Утром он не может ответить на вопросы: сколько прямо сейчас открыто критичных инцидентов, кто перегружен, успеваем ли мы выполнить модернизацию инфраструктуры. ИТ-директор отчитывается ощущениями, а спрашивают с него фактами, и в этом разрыве он живёт постоянно. Это хроническая боль для управленца: нести ответственность за то, чего не видишь.
Второе — ИТ-директор структурно беззащитен в разговоре с бизнесом. Работа ИТ невидима по своей природе: бизнес видит только сбои, не видит объёма выполненных запросов на обслуживание или предиктивно решённых проблем. Когда приходит время планирования бюджета или разбора полётов, ИТ опять оперирует ощущениями «мы много работаем» против ощущения бизнеса «опять всё тормозит». Эмоция от последнего падения критичных сервисов всегда громче любого объёма невидимого труда. Без данных ИТ-отдел — вечно виноватый, центр затрат, который оправдывается. ITSM превращает ИТ из виноватого в партнёра с доказательствами: вот объём работ, вот тренд, вот где реально болит. Разговор с бизнесом переходит из плоскости «верьте нам» в плоскость цифр, а на цифрах ИТ уже не проигрывает.
Третье — компания становится заложником людей, а не процессов. Знание о том, как всё устроено, история решений, контекст «почему сделали так» — всё это в головах. Уходит ключевой инженер, и вся работа стопорится. ITSM — это институциональная память, которая не увольняется и не уходит в отпуск.
Под всеми тремя состояниями лежит одна вещь, и это и есть ценность от ITSM: переход от управления на ощущениях к управлению на фактах. Пока системы нет, все стороны оперируют эмоциями и ощущениями. И в этой картине ощущений проигрывают все. Пользователь не знает, работают ли над его проблемой — он не думает «долго чинят», он думает «не знаю, чинят ли вообще». Руководитель не знает состояния своего хозяйства. Бизнес не знает, за что платит. ITSM убирает эту неопределённость на всех уровнях сразу.
Видимость — это ещё и рычаг влияния
Хаос растёт незаметно, и к нему привыкают, как лягушка в медленно нагревающейся воде. А пока он растёт, компания каждый день платит невидимый налог: люди переспрашивают статусы, дёргают друг друга, дублируют работу, эскалируют через личные связи, не знают, кто чем занят. Этого налога нет ни в одной строке бюджета, но он жрёт производительность тихо и постоянно.
Его не замечают ровно до того дня, когда уходит ключевой человек или бизнес задаёт вопрос, на который нечем ответить. ITSM этот налог обнуляет — и делает воду в кастрюле наконец видимой.

Теперь вернёмся к той самой мотивации, с которой начали, — нести ответственность без прав и полномочий. ITSM-система даёт директору не просто видимость, но и рычаг для управления.
Когда у ИТ на руках цифры — объём работы, нагрузка на команду, тренды по инцидентам, реальные сроки, — ИТ перестает просить и начинает обосновывать. «Дайте ещё двух инженеров» звучит как нытьё. «Вот данные: при текущей нагрузке мы выходим за SLA по критичным сервисам в N% случаев, нужно столько-то рук» — это сильный аргумент.
И вот тут цифры превращаются в полномочия. Когда ИТ может показать на дашборде, что команда уже работает за пределами нормы, а сроки срывает не разгильдяйство, а перегруз, — у ИТ появляется доказательный аргумент. Право обоснованно сказать «нет» новой задаче. Право показать, что вот это решение принимается не на стороне ИТ, и вернуть ответственность туда, где находятся полномочия.
Таким же образом ИТ может снизить нагрузку на отдел, исключив повторяющиеся проблемы. Без системы ITSM один и тот же инцидент прилетает в двадцатый раз, каждый раз его героически чинят за полчаса и каждый раз с нуля. Никто не видит, что это не двадцать инцидентов, а один, который никто не удосужился проанализировать и устранить корень проблемы.
Когда у ИТ есть история инцидентов, всё уже работает по-другому. Если видно, что инцидент повторяется системно и причина у него одна, — её можно закрыть раз и навсегда, а не латать по кругу. Это сдвиг от «реагируем» к «не допускаем». Команда уже не захлёбывается в потоке однотипных заявок, а разгребает рутину и идёт заниматься развитием.
А теперь умножьте это на всю компанию — ESM
Всё, что выше, — про ИТ. Но та же боль есть у любого подразделения, которое обрабатывает запросы людей: HR, АХО, юристы, бухгалтерия, закупки. Везде одно и то же — заявки в почте и мессенджерах, потерянные обращения, «я же тебе писал», ноль прозрачности и невозможность доказать загрузку персонала.
ESM (Enterprise Service Management) — это когда модель сервис-деска выходит за пределы ИТ на всю компанию. Что получает каждый? Правильно, контроль над ситуацией в своем отделе.
При этом если у вас платформа уже куплена и настроена под ИТ, подключить к ней HR и АХО — это инкремент, а не новый проект с нуля. Одна платформа вместо трёх разрозненных систем и пяти почтовых ящиков.
Зачем ESM ИТ-директору?
Пока ИТ-директор он отвечает только за ИТ, его и воспринимают узко — «те, кто чинит компы». Но когда на его платформе начинают работать HR, АХО, закупки и т.д., он становится владельцем сервисных процессов всей компании. Его логика — SLA, прозрачность, управление на фактах — выходит за пределы ИТ, и наведение порядка в чужих службах записывается уже на его счёт. Добавим бюджетный аргумент: платформу, которую раньше приходилось защищать как «расходы на ИТ», теперь окупает вся организация, и отстаивать её становится заметно легче.
Есть еще одно преимущество ESM для ИТ-директора, которое часто упускают. Если ИТ не заберёт сервисные процессы на свою платформу, это сделают сами службы. HR купит себе один инструмент, АХО другой, закупки третий. В итоге в компании вырастает зоопарк систем, которые между собой не дружат, а поддерживать их и интегрировать между собой всё равно придётся ИТ, только уже без прав, полномочий и без контроля. ESM — это возможность занять эту территорию первым и осознанно, а не разгребать последствия чужих покупок потом.
На этом моменте я бы предложил оценить ещё и перспективы на будущее. Сейчас все хотят ИИ-агентов: чтобы заявки классифицировались сами, чтобы система предсказывала сбои, чтобы рутину разгребал бот. Но любому такому помощнику нужно топливо — структурированная история того, что происходило, как решалось и чем закончилось. Взять её неоткуда, если всё жило в почте и в головах. ESM эту историю копит с первого дня. То есть внедрение сегодня — это не только порядок здесь и сейчас. Система станет фундаментом под всё, что придёт позже: автоматику, предиктив, ИИ. Кто наводит порядок в данных сейчас, через пару лет просто включит поверх них умные инструменты. Остальные будут собирать историю с нуля.
Риски всё равно есть

Чтобы не выглядело как продажа в одни ворота: ITSM и ESM легко превратить в свою противоположность.
Внедрённый криво инструмент, даёт не управление, а бюрократию: пять согласований там, где раньше решалось одним сообщением, и регламент ради регламента. Люди начинают ненавидеть систему — и правильно делают.
Вторая ловушка — арбузные метрики. Снаружи зелёные, внутри красные. SLA закрываются вовремя на бумаге, потому что команда научилась играть в систему: переоткрывает тикеты, переводит в «ожидание клиента», дробит одну задачу на пять. Когда метрика становится целью, она перестаёт быть метрикой. И директор снова управляет вслепую, только теперь с красивым дашбордом, который ему врёт. Лечится это не системой, а тем, как её внедрили: какие процессы зашили, что и зачем меряют, не превратили ли цифры в кнут. Инструмент даёт возможность видеть правду. Показывать её или рисовать — выбор уже человеческий.
Ещё один реальный риск перед внедрением — переоценить зрелость процессов. Если в компании нет базовой культуры работы с заявками, система не создаст её сама, она лишь автоматизирует бардак.
Если совсем коротко
ITSM и ESM помогают компаниям перестать терять деньги, заявки, знание, время на координацию и саму возможность доказать собственную ценность. А ИТ-руководитель наконец перестаёт управлять вслепую и получает не только видимость, но и рычаг для управленческих решений.
А теперь вопрос: какой процент вашей операционки прямо сейчас живёт в головах и переписках, а не в системе? И если завтра уйдёт ключевой человек — что встанет?
ссылка на оригинал статьи https://habr.com/ru/articles/1043554/