Решения принимаются в переписке
Договорённости о приоритетах, сроках и составе доработок живут в чатах и голосовых сообщениях. Через месяц никто не может восстановить, почему сделали именно так.
ИТ-управление и регламенты
Правила, по которым ИТ принимает решения
Определяем, кто владеет системами и данными, как формируется бюджет, по каким критериям проекты попадают в работу и какими метриками измеряется результат. Без этого ИТ остаётся набором личных договорённостей.
Или сразу: +7 (962) 368-39-51 Telegram
RACI
роли и зоны ответственности по системам
портфель
единая очередь и правила приоритизации
KPI
метрики ИТ для отчёта руководству
регламент
политики с владельцем и сроком пересмотра
Что происходит, когда управление ИТ не описано
Ниже — набор симптомов, которые почти всегда встречаются вместе. По отдельности каждый кажется мелочью, вместе они делают ИТ неуправляемым.
Теневые закупки и сервисы
Отделы покупают подписки и нанимают подрядчиков напрямую, минуя ИТ. Компания платит за дублирующие сервисы, а данные клиентов уходят на непроверенные площадки.
Бюджет ИТ непрозрачен
Известна общая сумма расходов, но не её структура: сколько уходит на поддержку существующего, сколько на развитие, какая доля приходится на подрядчиков, а какая на команду.
Очередь доработок без правил
Задачи попадают в разработку по громкости просьбы. Самый настойчивый руководитель получает результат, а стратегически важное изменение ждёт месяцами.
Нет соглашения об уровне сервиса
Пользователи не знают, за какое время решается их обращение и куда идти с проблемой. ИТ не знает, что считать срочным, и реагирует в порядке поступления.
Ответственность размыта между ИТ и подрядчиками
Часть систем ведёт внешняя команда, часть — внутренняя, и на стыке никто не отвечает за результат целиком. Инциденты закрываются взаимными ссылками на зону другого.
Что мы проектируем и внедряем
Четыре контура управления, которые связываются между собой: кто решает, что делаем, сколько это стоит и как измеряем результат.
Модель управления и роли
Описываем, кто владеет системами, данными и процессами, кто принимает решения и как они эскалируются. Фиксируем это матрицей ответственности, а не устными договорённостями.
- Владельцы систем, данных и бизнес-возможностей
- Матрица ответственности RACI по ключевым процессам
- Комитет по ИТ: состав, периодичность, решаемые вопросы
- Порядок эскалации спорных решений и конфликтов приоритетов
Портфель и приоритизация
Вводим единую очередь работ с прозрачными правилами: как инициатива попадает в портфель, какие данные нужны для оценки и по каким критериям сравнивается с другими.
- Единая форма заявки с обязательными полями: эффект, срок, стоимость
- Критерии приоритизации и их вес, согласованные с руководством
- Разделение бюджета на поддержку и развитие с целевой пропорцией
- Регулярный пересмотр портфеля и правила остановки проектов
Бюджет, TCO и закупки
Делаем расходы на ИТ разложимыми по системам, владельцам и типам затрат. Вводим порядок закупок, который закрывает теневые подписки и дублирующие сервисы.
- Структура бюджета: инфраструктура, лицензии, подрядчики, фонд оплаты, развитие
- Расчёт TCO по ключевым системам и стоимость владения на пользователя
- Регламент закупок и обязательное согласование ИТ для новых сервисов
- Инвентаризация подписок и выявление дублирующих расходов
Метрики, регламенты и SLA
Определяем, что и как измеряется, и оформляем правила работы так, чтобы ими можно было пользоваться без нас: коротко, с владельцем у каждого документа и сроком пересмотра.
- Набор метрик ИТ: доступность, время реакции и решения, доля срывов сроков
- Соглашение об уровне сервиса с категориями обращений и сроками
- Политики: доступ, резервное копирование, работа с инцидентами, изменения
- Каталог ИТ-услуг с описанием, владельцем и стоимостью
Как внедряется модель управления
Мы не пишем регламенты «в стол»: каждый документ проходит через реальные совещания и первый цикл работы.
-
01 2–3 недели
Диагностика зрелости
Оцениваем, как решения принимаются сегодня, кто владеет системами, как формируется бюджет. Разбираем инциденты и срывы сроков за последний год.
-
02 3–4 недели
Проектирование модели
Определяем роли, состав комитета, правила приоритизации и структуру бюджета. Согласуем с руководством и владельцами процессов.
-
03 3–4 недели
Регламенты и метрики
Оформляем политики, SLA, каталог услуг и набор метрик. Настраиваем сбор данных, чтобы отчётность формировалась без ручной работы.
-
04 1 квартал
Первый цикл и передача
Проводим первый полный цикл: заявки, приоритизация, комитет, отчёт по метрикам. Корректируем регламенты по факту и передаём владельцам.
Зачем нужен комитет по ИТ и как его не превратить в формальность
Комитет по ИТ — это регулярная встреча, на которой принимаются решения по портфелю: что берём в работу, что откладываем, что останавливаем. Без такого органа приоритеты определяются громкостью просьб, а конфликты между отделами разрешаются тем, кто первым дошёл до руководителя.
Чтобы комитет не стал формальностью, у него должны быть три свойства. Первое: постоянный состав с правом решения, а не только с правом совещательного голоса. Второе: единая форма заявки, заполненная до встречи, — на совещании не обсуждают то, что можно прочитать. Третье: зафиксированный протокол с решениями и ответственными, потому что через квартал память о причинах решения исчезает.
Как измерять ИТ, чтобы метрики не превратились в самоцель
Метрики ИТ делятся на три группы. Эксплуатационные показывают, как работают сервисы: доступность, время реакции на обращение, время решения, число повторных инцидентов. Метрики развития описывают поставку изменений: сколько инициатив доведено до результата, какова точность оценки трудозатрат, сколько времени проходит от заявки до запуска. Финансовые показывают стоимость: расходы на ИТ в выручке, доля поддержки в бюджете, стоимость владения на пользователя.
Опасность метрик в том, что люди начинают оптимизировать цифру, а не задачу. Если измерять только время решения обращений, сотрудники начнут закрывать тикеты, не решая проблему. Поэтому к каждой метрике нужен противовес: время решения — вместе с долей повторных обращений, число релизов — вместе с долей откатов и инцидентов после выкладки.
Теневые ИТ: как обнаружить и что с ними делать
Теневые ИТ — это сервисы и подписки, которыми отделы пользуются без ведома ИТ: онлайн-таблицы с клиентскими данными, конструкторы форм, внешние чат-боты, файловые хранилища, самодельные интеграции. Появляются они не из вредности, а потому что легальный путь кажется слишком долгим: заявка, оценка, очередь, сроки.
Бороться запретами бесполезно — сервисы уйдут глубже. Работает другая последовательность: сначала инвентаризация по выпискам и корпоративным картам, затем оценка риска каждого сервиса (где хранятся данные, кто имеет доступ, что будет при отключении), затем быстрый легальный путь для типовых задач — предварительно одобренные сервисы и упрощённый порядок согласования. Если легальный путь занимает два дня вместо двух месяцев, теневые ИТ исчезают сами.
Частые вопросы
Как раз для таких компаний модель управления особенно важна. Когда в ИТ три человека и три подрядчика, отсутствие правил приводит к тому, что каждый подрядчик ведёт свою систему по своим стандартам, а документация существует только у него. Мы делаем облегчённую модель: минимальный набор ролей, один регламент закупок и один регламент инцидентов.
Риск реальный, поэтому мы ограничиваем объём документов. В типовой модели получается один комитет, встречающийся раз в две недели, одна форма заявки, четыре политики и один отчёт по метрикам. Всё остальное либо не пишем, либо оставляем в виде чек-листа. Любой документ, которым не пользуются три месяца, считается лишним и удаляется.
Обычно сопротивление возникает там, где регламент воспринимается как контроль. Мы начинаем с процессов, которые команде самим мешают: непонятные приоритеты, внезапные срочные задачи, постоянные переключения. Когда сотрудники видят, что правила защищают их время, отношение меняется. Отдельно договариваемся о первом цикле в щадящем режиме, без немедленных санкций за отклонения.
Диагностика и проектирование занимают 5–7 недель, оформление регламентов и метрик — ещё 3–4 недели. Первый полный цикл работы по новым правилам — один квартал. То есть от старта до момента, когда модель работает самостоятельно, проходит примерно полгода. Часть эффекта видна раньше: структура бюджета и правила приоритизации начинают работать уже через два месяца.
IT-консалтинг: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Пора навести порядок в управлении ИТ?
Расскажите, сколько людей и подрядчиков задействовано в ИТ, — предложим формат работы.