Автор: Дмитрий Никитин, руководитель Управления поддержки пользователей и Регионального ИТ-центра (Волгоград), Страховой Дом ВСК

Когда ломается система продаж, первый вопрос от бизнеса часто звучит так: «Когда уже ИТ все наладят» или «Почему опять не работает?». Но редко кто задаётся другим — более фундаментальным — вопросом: из чего состоит стабильность цифрового контура?

В реальности, если ИТ не работает — бизнес останавливается. Но в восприятии большинства сотрудников/менеджеров/агентов, ИТ по-прежнему выступает как вспомогательная функция, а не как ядро операционного процесса.

Отвечая на опросы, топы компаний часто не могут оценить вклад ИТ в продажи. Но правда в том, что, если ИТ не работает — продажи не идут. Исследование Forrester (2024) показывает, что только 29 % руководителей считают, что их IT‑инициативы действительно перекликаются с бизнес-целями.

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

• Руководители отделов не могут объяснить, как конкретно ИТ влияет на их KPI — будь то выручка, скорость обработки заявок, снижение времени на клиента;

• Запросы на улучшения исходят не из стабильности системы, а из желания «выпустить новый продукт» — даже если уже выпущенное трещит по швам;

• Часть анкет была заполнена с ошибками или содержала только однотипные шаблонные ответы: «нужно больше новых функций», «дайте нам доступ к данным», «ИТ тормозит процессы»

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

О чём вышесказанное нам говорит?

Симбиоз, а не соседство: новая точка сборки ИТ и бизнеса

Важно сменить мышление с ИТ обслуживает бизнес на ИТ — неотъемлемая часть бизнес-механизма. Вот несколько реальных наблюдений, которые стали тревожными звоночками:

1. Запросы на новые продукты вместо доработки базовой системы. В результате бизнес не получает устойчивого результата, а ИТ завязает в приоритизации, не решая корневые проблемы;

2. Перекладывание ответственности. Если не работает, не хотят разбираться в причинах и первым делом «назначают виновного»;

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

Запросы на новые продукты вместо доработки стабильности системы и устранения проблем

Главное, чтобы система работала -  не работает система, нет продаж и не важно сколько было в PI реализовано новых продуктов, если их не продать.

Идем дальше по цепочке, репутационные риски, а именно, при запуске продукта рассчитывают сколько он прибыли принесет, но почему нет расчета, а что будет если:

• Система не будет работать, сколько потеряем возможных продаж;

• Агент, увидев, что не может продать у нас, пойдет в другое место и больше не будет заходить в наше приложение в приоритете или вовсе.

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

Перекладывание ответственности

Бизнес и ИТ не видят всей цепочки от первой строчки кода до продажи и соответственно не понимаю влияния каждого из процессов. Между разработчиком и менеджером по продажам лежит целый мир: системы хранения, микросервисы, поезда, разработка, эксплуатация, служба поддержки, мониторинг. Если один компонент даёт сбой — например, система возвращает ошибку 500 — клиент уходит. Но система не может сломаться сама, где же причина? Что же делать?

• Разработчик нажал не ту кнопку при запуске релиза?

• Бизнес не так поставил задачу, и её реализация повлияла на работу системы?

• Агент не так заполнил поле и получил ошибку?

Причин может быть много, но, по моему мнению, отсутствие у бизнеса понимания важности ИТ и не желание задаться вопросом «а точно ли система не работает из-за ИТ, возможно это мы не так поставили задачу или некорректно объяснили агентам, как работать или отказываемся слушать и приоритезируем доработки на запуск продукта, а не стабилизацию системы, не думая, что если система не работает, то и продаж нет»

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

Есть система, у системы есть ответственные, если система не работает, то не нужно перекладывать ответственность с себя на других, да другая система могла повлиять или повлияла на работу системы в твоей ЗО, но виноват в этом и ты сам т.к. ты владелец, твоя система не работает у агентов и соответственно ты и должен хороводить устранение проблемы, а не говорить «это они меня уронили, пусть они и разбираются».

Стагнация на удалёнке: когда нет культуры сервиса и связности

Удалёнка в ИТ — это уже не новость. С 2020 года многие ИТ-команды обжились в Skype и Zoom, научились жить без офиса. Но за первым успехом пришёл второй виток вызова: как не впасть в стагнацию, если ты сидишь в квартире, а твой коллега — за 2000 км?

На старте пандемии ИТ показал бизнесу скорость и адаптивность. Буквально за недели запускались цифровые каналы, переносились инфраструктуры, перекраивались процессы. Однако уже через полгода-год стала прослеживаться новая проблема: команды на удалёнке начинают терять тонус, мотивацию и качество сервиса.

Почему? Дело не в удалёнке как таковой. Дело в отсутствии сервисной культуры и слабой связности внутри ИТ и между ИТ и бизнесом.

Вот как это выглядит на практике:

• Инфраструктура работает, тикеты закрываются, но никто не анализирует причины повторяющихся заявок;

• Встречи идут по расписанию, но команда не понимает, кто и зачем использует результат её работы;

• Разработчики "отпиливают" фичи по ТЗ, но не вовлечены в жизненный цикл продукта и не слышат обратную связь от пользователей.

• Саппорт продолжает быть “пожарной командой”, а не источником системного анализа сбоев и паттернов.

Со временем это приводит к тому, что:

• ИТ блок перестаёт развиваться, довольствуясь формальным выполнением KPI;

• Межкомандные границы усиливаются: “это не наша зона ответственности”, “мы не трогаем чужое”;

• У сотрудников теряется ощущение смысла и сопричастности. Сервис подменяется тикетом.

Результат: замедление команд, рост текучки, выгорание, падение доверия между ИТ и бизнесом.

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

• Остаемся в рынке, по сравнению с другими компаниями, даже если ЗП где-то уступает;

• Возможность удаленку преподносить как бонус от компании;

• Выход в офис минимум 1-2 раза в неделю, позволит оживить где-то застоявшеюся работу и очень продуктивно поштурмить с коллегами, зарядится эмоциями;

• Необходимо, что бы руководители выступали и пропагандировали выход в офис, а также умели управлять удаленными командами т.к. это одно из самого сложного – найти менеджера/лида умеющего управлять и контролировать удалённую работу, иначе ваш путь 5х2 в офис.

Сервис — это не KPI, это способ мышления

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

Простой пример. Закрываем заявки, но не решаем проблему:

В одной из внутренних служб тикеты закрывались в срок, SLA соблюдался. Но бизнес продолжал писать одни и те же обращения: «зависает фильтр», «данные не грузятся», «отчет ломается». Когда провели разбор, выяснилось: 28% заявок — повторы с неустранённой первопричиной. Сотрудники решали каждый запрос по инструкции, не задавая себе вопрос: зачем вообще пришла эта заявка?

Такое поведение — результат мышления «я здесь, чтобы закрывать тикеты». Это мышление исполнителя, а не владельца сервиса. И пока оно доминирует, невозможно выйти на уровень зрелого взаимодействия между ИТ и бизнесом.

Сервисное мышление начинается с простой привычки — не останавливаться на первом решении. Увидели повторяющийся тикет? Значит, перед вами не задача, а симптом.

• Не работает выгрузка → почему?

• Проблема в данных → откуда они приходят?

• Источники из АДАПТа → что с их схемой?

И так далее.

Внедрять такое мышление стоит сверху вниз: через лидов, архитекторов, менеджеров — как элемент культуры, а не инициативу снизу.

Другой опасный миф в ИТ-командах — «это не моя зона ответственности, пусть разбираются другие». Это реакция, понятная в условиях выгорания и перегрузки. Но она разрушительна для сервиса.

Что важно понять:

• Ответственность — это то, за что ты обязан отвечать.

• Влияние — это то, на что ты можешь повлиять.

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

Чтобы перейти от тушения пожаров к созданию устойчивых ИТ-продуктов, нужно внедрить сервисное мышление на всех уровнях. Это значит:

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

• Умение задавать вопрос зачем пришла заявка важнее, чем просто быстрое закрытие;

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

Когда ИТ-команда перестаёт думать лишь о своих метриках, а начинает видеть сервис глазами конечного пользователя (внутреннего или внешнего), между ИТ и бизнесом возникает не «барьер запрос–ответ», а мост доверия. Вместо формальной передачи тикета с пометкой «не в нашей зоне» появляется готовность совместно:

1. Проводить мини-воркшопы на стыке ИТ и заказчика — где в режиме «живого диалога» разбирают одну-две повторяющиеся проблемы и придумывают не «патч», а архитектурную доработку, устраняющую корень;

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

Это убирает из сессий статус «ИТ нам что-то должно», и переводит их в категорию «мы вместе решаем важную для компании задачу».

К тому же, сервисное мышление рождает сквозные KPI: например, вместо «среднее время закрытия тикета» вводят «долю бизнес-сценариев без сбоев». Такие метрики автоматически втягивают обе стороны — ИТ и бизнес — в единую игровую зону:

• ИТ отвечает не за скорость починки, а за «постоянную работоспособность» ключевых сценариев (регистрация, оплата, отчёты).

• Бизнес понимает, что качественный релиз — это не только новое «красивое» окно, но и отсутствие пост-релизных срывов продаж или отказов клиентов.

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

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

Буду рад диалогу и обмену опытом: делитесь своим опытом и мнением и пишите комментарии!