Когда бизнес говорит, что ИТ-отдел неэффективен, это обычно видно не по отчетам, а по теневому ИТ — сервисам, таблицам и подпискам, которые подразделения заводят в обход ИТ-службы. Типовых причин четыре: нехватка бюджета (своего ИТ-бюджета у подразделения нет, а ждать общего долго), экономия времени (оплатить облачный сервис картой быстрее, чем пройти заявку), желание обойти правила (согласования, требования безопасности, закупочные процедуры) и недоверие к ИТ-отделу (опыт, что ИТ «не сделает» или «сделает через полгода»).
Содержание
- Мини-словарь: что именно называют неэффективностью
- Четыре причины обхода ИТ-отдела и что за ними стоит
- Как понять, что проблема в ИТ, а не в ожиданиях
- Что делать руководителю ИТ: план на квартал
- Чего не делать
- Безопасность: минимум, который нужен при легализации
- Если не получилось: симптомы и что проверить
- Выводы
- Где применяется / связь с практикой
- FAQ
Ниже — как отличить проблему ИТ-отдела от завышенных ожиданий, что стоит за каждой из четырех причин и какой план действий у руководителя ИТ на ближайший квартал. Оценка производительности самой команды разработки (метрики поставки, загрузка) — отдельная тема, здесь речь об отношениях ИТ и бизнеса.
Мини-словарь: что именно называют неэффективностью
Эти понятия часто смешивают, а лечатся они по-разному.
| Термин | Что это | Чем отличается |
|---|---|---|
| Теневое ИТ (shadow IT) | Системы и сервисы, которые используются без ведома или согласования ИТ-службы | Проблема не в самом сервисе, а в том, что никто не отвечает за данные, доступы и затраты |
| Согласованное бизнес-ИТ | Подразделение само выбирает и настраивает инструмент, но в рамках правил ИТ (учет, SSO, классы данных) | Та же скорость для бизнеса, но риски видны и управляемы |
| Неэффективность ИТ для бизнеса | ИТ не дает нужного результата в нужный срок и за понятные деньги | Может быть при сильной команде, если нет каталога услуг и приоритизации |
| Низкая производительность команды | Команда медленно и с дефектами выпускает изменения | Измеряется метриками поставки, а не жалобами пользователей |
Упрощение: граница между теневым и согласованным ИТ зависит от политики конкретной компании. Одна и та же доска задач в облаке может быть нормой в одной организации и нарушением в другой.
Четыре причины обхода ИТ-отдела и что за ними стоит
Каждая причина — это симптом конкретного разрыва в процессах ИТ. Если лечить симптом запретом, разрыв остается, и сервисы просто уходят глубже в тень.
| Причина | Как выглядит | Что сигнализирует | Что делать |
|---|---|---|---|
| Нехватка бюджета | Подписки оплачиваются корпоративной картой или через подотчет, «чтобы не заводить проект» | Бюджет ИТ не связан с потребностями подразделений, нет механизма малых закупок | Отдельный лимит на малые ИТ-закупки и прозрачная раскладка затрат по подразделениям |
| Экономия времени | Сервис подключили за вечер, заявка в ИТ висела бы неделями | Долгий цикл обработки запросов, нет стандартных услуг «из коробки» | Каталог услуг со сроками и быстрый путь для типовых запросов |
| Желание обойти правила | Данные выгружают в личные облака, доступы раздают по ссылке | Правила непонятны или непропорциональны риску | Классы данных с разными требованиями, объяснение «зачем» вместо общего запрета |
| Недоверие к ИТ-отделу | «ИТ все равно не сделает», решения принимают без ИТ | Обещания не выполнялись, нет прозрачного статуса и приоритетов | Короткие видимые результаты, открытый портфель проектов, регулярный разбор с бизнесом |
Нехватка бюджета
Часто денег в компании хватает, но они лежат не там. ИТ-бюджет формируется раз в год под крупные проекты, а подразделению нужен сервис за небольшую сумму прямо сейчас. Проще оплатить его в обход, чем ждать следующего цикла планирования.
Рабочий прием — showback: ИТ регулярно показывает каждому подразделению, сколько стоят его сервисы и лицензии, без внутреннего выставления счетов. Следующий шаг, chargeback, когда затраты реально списываются на бюджет подразделения, вводят только после того, как раскладка затрат стала понятной и ее не оспаривают.
Экономия времени
Если типовой запрос (новый доступ, новая доска задач, простая интеграция) обрабатывается неделями, пользователь выберет облачный сервис, который работает через пять минут. Здесь нужна не агитация, а измерение: сколько реально проходит от заявки до результата по типовым услугам.
Желание обойти правила
Правила обходят, когда они одинаковы для всего подряд. Если согласование доски для планирования отпуска идет тем же маршрутом, что и подключение системы с персональными данными клиентов, люди перестают воспринимать требования всерьез. Решение — разделить данные на классы и дать для низкого класса упрощенный путь.
Недоверие к ИТ-отделу
Это самая медленная причина: доверие восстанавливается выполненными обещаниями, а не презентациями. Помогает открытый портфель, где бизнес видит, что взято в работу, что отложено и почему. Отказ с объяснением доверие не разрушает, а молчание и сорванные сроки — разрушают.
Как понять, что проблема в ИТ, а не в ожиданиях
Жалобы на ИТ бывают и при нормальной работе, если бизнес ждет того, что не согласовывалось. Прежде чем что-то менять, соберите факты за последние 2-3 месяца:
- Реестр теневых сервисов. Выгрузка платежей по картам и авансовым отчетам с ключевыми словами (подписка, SaaS, облако), опрос руководителей подразделений, данные прокси или межсетевого экрана о популярных внешних сервисах.
- Срок обработки типовых запросов. Медиана и «хвост» (например, 90-й перцентиль) по каждому типу заявок. Среднее значение прячет заявки, которые висят месяцами.
- Доля повторных инцидентов. Если одни и те же сбои повторяются, пользователи перестают сообщать о них и ищут обходные пути.
- Прозрачность затрат. Может ли ИТ за день ответить, сколько стоит сервис для конкретного подразделения.
- Короткие интервью с 5-7 руководителями. Вопрос не «довольны ли вы ИТ», а «какой последний инструмент вы подключили без ИТ и почему».
Если сроки по типовым услугам разумные, реестр теневых сервисов короткий, а жалобы касаются проектов, которые никто не согласовывал, проблема скорее в управлении ожиданиями и приоритетами, чем в работе команды.
Что делать руководителю ИТ: план на квартал
Ниже — дорожная карта до конкретного артефакта: согласованного с бизнесом каталога услуг и реестра сервисов. Сроки ориентировочные и зависят от размера компании и того, сколько уже сделано.
- Недели 1-3: инвентаризация. Собрать реестр теневых сервисов по схеме выше. Для каждого: владелец в бизнесе, какие данные хранит, кто платит, есть ли альтернатива внутри компании.
- Недели 3-5: классы данных и риски. Разбить сервисы на три группы: оставить и легализовать, заменить внутренним решением, срочно закрыть (например, персональные данные в личных аккаунтах). Закрывать — только с планом переноса данных.
- Недели 4-8: каталог услуг. Описать 10-20 самых частых запросов: что входит, кто отвечает, целевой срок выполнения. Срок фиксировать как цель (SLO) и публиковать фактические значения, а не только обещание.
- Недели 6-10: быстрый путь. Для сервисов низкого класса риска — упрощенное согласование: проверочный список из нескольких пунктов (вход через корпоративную учетную запись, нет персональных данных, есть владелец) вместо общей заявки.
- Недели 8-12: прозрачный бюджет. Showback по подразделениям, отдельный лимит на малые закупки, общий портфель проектов с приоритетами, которые утверждает не только ИТ.
- Постоянно: ритм с бизнесом. Ежемесячный разбор с руководителями: что сделано, что отложено, какие теневые сервисы легализованы.
Итоговый артефакт квартала — каталог услуг с фактическими сроками, реестр сервисов с владельцами и первая раскладка затрат. По ним видно, стало ли меньше причин обходить ИТ.
Чего не делать
- Тотальный запрет. Блокировка популярных сервисов без альтернативы переводит их на личные устройства и мобильный интернет — риск становится невидимым.
- Наказание за найденные сервисы. После первого выговора инвентаризация перестает работать: о новых инструментах просто не будут рассказывать.
- Покупка «платформы» вместо процесса. Новая система заявок не сократит сроки, если заявки по-прежнему ждут согласования у одного человека.
- Микроменеджмент команды. Если причина в приоритетах и бюджете, контроль каждой задачи инженеров только снизит скорость.
Безопасность: минимум, который нужен при легализации
Легализация теневого сервиса не делает его автоматически безопасным. Базовый набор требований:
- вход через корпоративный единый вход (SSO) и многофакторную аутентификацию, чтобы при увольнении доступ отзывался централизованно;
- понятный владелец в бизнесе и ответственный в ИТ;
- проверка, какие данные попадают в сервис, и соответствие требованиям к их хранению (для персональных данных граждан РФ — в том числе требованиям 152-ФЗ: локализация записи и накопления данных в базах на территории РФ, а если зарубежный сервис получает такие данные — уведомление Роскомнадзора о трансграничной передаче до ее начала, это требование действует с 1 марта 2023 года);
- возможность выгрузить данные при отказе от сервиса;
- учет в реестре и пересмотр раз в год.
Это минимальный уровень, а не полная защита: для сервисов с чувствительными данными нужна отдельная оценка рисков с участием службы безопасности.
Если не получилось: симптомы и что проверить
| Симптом | Вероятная причина | Что делать |
|---|---|---|
| Каталог услуг есть, но заявки все равно идут в обход | Сроки в каталоге не выполняются или сам каталог никто не видит | Публиковать фактические сроки, встроить каталог в привычный канал (портал, мессенджер) |
| Реестр теневых сервисов растет после легализации | Быстрый путь сложнее, чем оплатить сервис самому | Сократить проверочный список, дать ответ по нему за 1-2 рабочих дня |
| Бизнес оспаривает раскладку затрат | Правила распределения непрозрачны | Вернуться к showback, согласовать методику с финансовой службой |
| Руководители не приходят на ежемесячный разбор | Встреча не влияет на решения | Выносить на встречу реальный выбор приоритетов, а не отчет о проделанной работе |
Выводы
- Жалоба «ИТ неэффективно» чаще всего проявляется через теневое ИТ, и его причины — нехватка бюджета, экономия времени, желание обойти правила и недоверие к ИТ-отделу.
- Каждая причина указывает на конкретный разрыв: бюджетный механизм, сроки типовых услуг, непропорциональные правила, невыполненные обещания.
- Начинать стоит с фактов: реестр теневых сервисов, медиана и хвост сроков по заявкам, прозрачность затрат.
- Работающий ответ — каталог услуг с фактическими сроками, быстрый путь для низкого риска и showback, а не запреты.
- Легализованный сервис требует минимального набора контроля: SSO, владелец, класс данных, выгрузка.
Где применяется / связь с практикой
Освойте тему на практике
Разговор с бизнесом о бюджете, каталоге услуг, портфеле проектов и рисках теневого ИТ — это повседневная работа руководителя ИТ-функции. Выстроить эти процессы системно, от ИТ-стратегии до управления затратами и командой, помогает курс Директор информационных технологий / CIO. Разобрать отдельные вопросы с практиками можно на открытых уроках Otus.
FAQ
Теневое ИТ — это всегда плохо?
Нет. Оно показывает, где ИТ-услуги не успевают за потребностями бизнеса, и часто подсказывает, какие инструменты стоит легализовать. Проблема в неучтенных данных, доступах и затратах, а не в инициативе сотрудников.
Что делать, если ИТ-отдел маленький и каталог из 20 услуг не потянуть?
Начать с 5-7 самых частых запросов и честных сроков по ним. Небольшой каталог, который выполняется, полезнее большого, который никто не соблюдает.
Кто должен отвечать за теневой сервис после легализации?
Два человека: владелец в бизнесе отвечает за то, зачем сервис нужен и какие данные в нем хранятся, ответственный в ИТ — за доступы, интеграции и соответствие требованиям.
