Автор: Дмитрий Никитин, руководитель Управления поддержки пользователей и Регионального ИТ-центра (Волгоград), Страховой Дом ВСК
Когда ломается система продаж, первый вопрос от бизнеса часто звучит так: «Когда уже ИТ все наладят» или «Почему опять не работает?». Но редко кто задаётся другим — более фундаментальным — вопросом: из чего состоит стабильность цифрового контура?
В реальности, если ИТ не работает — бизнес останавливается. Но в восприятии большинства сотрудников/менеджеров/агентов, ИТ по-прежнему выступает как вспомогательная функция, а не как ядро операционного процесса.
Отвечая на опросы, топы компаний часто не могут оценить вклад ИТ в продажи. Но правда в том, что, если ИТ не работает — продажи не идут. Исследование Forrester (2024) показывает, что только 29 % руководителей считают, что их IT‑инициативы действительно перекликаются с бизнес-целями.
Это подтверждает и внутренняя диагностика, проведённая нами через анкетирование бизнес-заказчиков. Вот что мы увидели:
Руководители отделов не могут объяснить, как конкретно ИТ влияет на их KPI — будь то выручка, скорость обработки заявок, снижение времени на клиента;
Запросы на улучшения исходят не из стабильности системы, а из желания «выпустить новый продукт» — даже если уже выпущенное трещит по швам;
Часть анкет была заполнена с ошибками или содержала только однотипные шаблонные ответы: «нужно больше новых функций», «дайте нам доступ к данным», «ИТ тормозит процессы»
Честно сказать, многие из ИТ так же не понимают влияния их работы бизнес, что ещё раз подтверждает отсутствие прозрачности процесса или может не желание понимать? Отсутствие культуры взаимодействия?
О чём вышесказанное нам говорит?
Симбиоз, а не соседство: новая точка сборки ИТ и бизнеса
Важно сменить мышление с ИТ обслуживает бизнес на ИТ — неотъемлемая часть бизнес-механизма. Вот несколько реальных наблюдений, которые стали тревожными звоночками:
Запросы на новые продукты вместо доработки базовой системы. В результате бизнес не получает устойчивого результата, а ИТ завязает в приоритизации, не решая корневые проблемы;
Перекладывание ответственности. Если не работает, не хотят разбираться в причинах и первым делом «назначают виновного»;
Стагнация на полной удалёнке. Без осознанной сервисной культуры и межфункциональной связи удаленные команды начинают деградировать, особенно если изначально не было сформировано доверие и прозрачная система задач
Запросы на новые продукты вместо доработки стабильности системы и устранения проблем
Главное, чтобы система работала - не работает система, нет продаж и не важно сколько было в PI реализовано новых продуктов, если их не продать.
Идем дальше по цепочке, репутационные риски, а именно, при запуске продукта рассчитывают сколько он прибыли принесет, но почему нет расчета, а что будет если:
Система не будет работать, сколько потеряем возможных продаж;
Агент, увидев, что не может продать у нас, пойдет в другое место и больше не будет заходить в наше приложение в приоритете или вовсе.
Исходя из описанного выше, стабилизация должна выполнятся не остаточными ресурсами, а находиться на уровне с вводом продуктов, а иногда и выше в зависимости от эффекта.
Перекладывание ответственности
Бизнес и ИТ не видят всей цепочки от первой строчки кода до продажи и соответственно не понимаю влияния каждого из процессов. Между разработчиком и менеджером по продажам лежит целый мир: системы хранения, микросервисы, поезда, разработка, эксплуатация, служба поддержки, мониторинг. Если один компонент даёт сбой — например, система возвращает ошибку 500 — клиент уходит. Но система не может сломаться сама, где же причина? Что же делать?
Разработчик нажал не ту кнопку при запуске релиза?
Бизнес не так поставил задачу, и её реализация повлияла на работу системы?
Агент не так заполнил поле и получил ошибку?
Причин может быть много, но, по моему мнению, отсутствие у бизнеса понимания важности ИТ и не желание задаться вопросом «а точно ли система не работает из-за ИТ, возможно это мы не так поставили задачу или некорректно объяснили агентам, как работать или отказываемся слушать и приоритезируем доработки на запуск продукта, а не стабилизацию системы, не думая, что если система не работает, то и продаж нет»
В данном разделе хочется так упомянуть не только перекладывание со стороны бизнеса, но и внутри ИТ и от чего необходимо уходить.
Есть система, у системы есть ответственные, если система не работает, то не нужно перекладывать ответственность с себя на других, да другая система могла повлиять или повлияла на работу системы в твоей ЗО, но виноват в этом и ты сам т.к. ты владелец, твоя система не работает у агентов и соответственно ты и должен хороводить устранение проблемы, а не говорить «это они меня уронили, пусть они и разбираются».
Стагнация на удалёнке: когда нет культуры сервиса и связности
Удалёнка в ИТ — это уже не новость. С 2020 года многие ИТ-команды обжились в Skype и Zoom, научились жить без офиса. Но за первым успехом пришёл второй виток вызова: как не впасть в стагнацию, если ты сидишь в квартире, а твой коллега — за 2000 км?
На старте пандемии ИТ показал бизнесу скорость и адаптивность. Буквально за недели запускались цифровые каналы, переносились инфраструктуры, перекраивались процессы. Однако уже через полгода-год стала прослеживаться новая проблема: команды на удалёнке начинают терять тонус, мотивацию и качество сервиса.
Почему? Дело не в удалёнке как таковой. Дело в отсутствии сервисной культуры и слабой связности внутри ИТ и между ИТ и бизнесом.
Вот как это выглядит на практике:
Инфраструктура работает, тикеты закрываются, но никто не анализирует причины повторяющихся заявок;
Встречи идут по расписанию, но команда не понимает, кто и зачем использует результат её работы;
Разработчики "отпиливают" фичи по ТЗ, но не вовлечены в жизненный цикл продукта и не слышат обратную связь от пользователей.
Саппорт продолжает быть “пожарной командой”, а не источником системного анализа сбоев и паттернов.
Со временем это приводит к тому, что:
ИТ блок перестаёт развиваться, довольствуясь формальным выполнением KPI;
Межкомандные границы усиливаются: “это не наша зона ответственности”, “мы не трогаем чужое”;
У сотрудников теряется ощущение смысла и сопричастности. Сервис подменяется тикетом.
Результат: замедление команд, рост текучки, выгорание, падение доверия между ИТ и бизнесом.
Одним из лучших вариантов работы в текущей тенденции, я вижу гибридный формат работы. Как, по моему мнению, стоит преподносить:
Остаемся в рынке, по сравнению с другими компаниями, даже если ЗП где-то уступает;
Возможность удаленку преподносить как бонус от компании;
Выход в офис минимум 1-2 раза в неделю, позволит оживить где-то застоявшеюся работу и очень продуктивно поштурмить с коллегами, зарядится эмоциями;
Необходимо, что бы руководители выступали и пропагандировали выход в офис, а также умели управлять удаленными командами т.к. это одно из самого сложного – найти менеджера/лида умеющего управлять и контролировать удалённую работу, иначе ваш путь 5х2 в офис.
Сервис — это не KPI, это способ мышления
Когда ИТ-команду оценивают по количеству закрытых тикетов, метрика становится самоцелью. Но вот в чём парадокс: чем выше выработка, тем больше ощущение, что «всё работает» — хотя на деле система может хронически болеть.
Простой пример. Закрываем заявки, но не решаем проблему:
В одной из внутренних служб тикеты закрывались в срок, SLA соблюдался. Но бизнес продолжал писать одни и те же обращения: «зависает фильтр», «данные не грузятся», «отчет ломается». Когда провели разбор, выяснилось: 28% заявок — повторы с неустранённой первопричиной. Сотрудники решали каждый запрос по инструкции, не задавая себе вопрос: зачем вообще пришла эта заявка?
Такое поведение — результат мышления «я здесь, чтобы закрывать тикеты». Это мышление исполнителя, а не владельца сервиса. И пока оно доминирует, невозможно выйти на уровень зрелого взаимодействия между ИТ и бизнесом.
Сервисное мышление начинается с простой привычки — не останавливаться на первом решении. Увидели повторяющийся тикет? Значит, перед вами не задача, а симптом.
Не работает выгрузка → почему?
Проблема в данных → откуда они приходят?
Источники из АДАПТа → что с их схемой?
И так далее.
Внедрять такое мышление стоит сверху вниз: через лидов, архитекторов, менеджеров — как элемент культуры, а не инициативу снизу.
Другой опасный миф в ИТ-командах — «это не моя зона ответственности, пусть разбираются другие». Это реакция, понятная в условиях выгорания и перегрузки. Но она разрушительна для сервиса.
Что важно понять:
Ответственность — это то, за что ты обязан отвечать.
Влияние — это то, на что ты можешь повлиять.
В зрелых ИТ-командах эти зоны не противопоставляют. Если к тебе пришёл запрос, и ты видишь, что причина — на смежной подсистеме, ты не отсылаешь тикет «в никуда», а помогаешь добраться до корня — с передачей контекста, гипотезой, логами и предложением обсудить. Потому что, если проблема не решится — всё равно проиграет команда в целом.
Чтобы перейти от тушения пожаров к созданию устойчивых ИТ-продуктов, нужно внедрить сервисное мышление на всех уровнях. Это значит:
Подразделения должны воспринимать себя не как исполнителей, а как партнеров, предоставляющих цифровой сервис;
Умение задавать вопрос зачем пришла заявка важнее, чем просто быстрое закрытие;
Надо разделять зону ответственности и зону влияния. Даже если проблема не «в нашей зоне», нам важно помочь коллеге разобраться и передать данные дальше по цепочке.
Когда ИТ-команда перестаёт думать лишь о своих метриках, а начинает видеть сервис глазами конечного пользователя (внутреннего или внешнего), между ИТ и бизнесом возникает не «барьер запрос–ответ», а мост доверия. Вместо формальной передачи тикета с пометкой «не в нашей зоне» появляется готовность совместно:
Проводить мини-воркшопы на стыке ИТ и заказчика — где в режиме «живого диалога» разбирают одну-две повторяющиеся проблемы и придумывают не «патч», а архитектурную доработку, устраняющую корень;
Привязывать задачи ИТ к бизнес-результатам: перед каждым новым запуском фичи команда оценивает не только нагрузку на инфраструктуру, но и ожидаемое влияние на задержку клиента, процент успешных транзакций или скорость обработки заказа.
Это убирает из сессий статус «ИТ нам что-то должно», и переводит их в категорию «мы вместе решаем важную для компании задачу».
К тому же, сервисное мышление рождает сквозные KPI: например, вместо «среднее время закрытия тикета» вводят «долю бизнес-сценариев без сбоев». Такие метрики автоматически втягивают обе стороны — ИТ и бизнес — в единую игровую зону:
ИТ отвечает не за скорость починки, а за «постоянную работоспособность» ключевых сценариев (регистрация, оплата, отчёты).
Бизнес понимает, что качественный релиз — это не только новое «красивое» окно, но и отсутствие пост-релизных срывов продаж или отказов клиентов.
В результате каждый sprint-план получает новую меру успеха: не просто сколько фич внедрили, а сколько бизнес-целей достигли без инцидентов.
Сервис — это способ думать. Видеть не заявку в системе, а пользователя с проблемой на том конце, который просит помощи и хочет, чтобы его проблема не повторялось. Пока ответственные не мыслят в этих координатах, никакие метрики и процессы не вытащат её из режима «пожарных».
Буду рад диалогу и обмену опытом: делитесь своим опытом и мнением и пишите комментарии!