Найти в Дзене
Евгений Седегов

ИТ можно сокращать.

ИТ можно сокращать.
Нельзя сокращать его вслепую. Когда в компании режут ИТ-затраты без смены модели, экономия почти всегда фальшивая: расходы не исчезают, а переезжают в другую корзину и там становятся ещё больше. У меня был показательный кейс. Собственник пообщался с другими владельцами бизнеса, увидел у них более низкий ИТ-бюджет и поставил своему ИТ-директору задачу:
«У других цифры ниже. Делай так же». Директор пошёл и просто срезал расходы. Очень быстро бизнес получил не экономию, а потери: больше простоев, ниже управляемость, дороже ошибки, медленнее изменения. Когда я потом обсуждал с ним эту ситуацию, спросил прямо:
«Ты же понимал, что будут проблемы. Зачем ты это сделал?»
Ответ был почти идеальный в своей слабости:
«Так сказал собственник». И вот здесь для CEO и собственника начинается главное. Если ИТ-руководитель просто режет бюджет по команде, не меняет модель работы, не считает последствия и не управляет ими, это не управление стоимостью функции. Это механическое ухудшен

ИТ можно сокращать.
Нельзя сокращать его вслепую.

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

У меня был показательный кейс.

Собственник пообщался с другими владельцами бизнеса, увидел у них более низкий ИТ-бюджет и поставил своему ИТ-директору задачу:
«У других цифры ниже. Делай так же».

Директор пошёл и просто срезал расходы.

Очень быстро бизнес получил не экономию, а потери: больше простоев, ниже управляемость, дороже ошибки, медленнее изменения.

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

И вот здесь для CEO и собственника начинается главное.

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

Почему нельзя просто «срезать ИТ до нужной цифры»?

Потому что бюджет становится меньше, а ожидания бизнеса нет.
Кассы должны работать.
Склады отгружать.
Поддержка отвечать.
Критичные системы восстанавливаться в срок.

То есть нагрузка та же, цена ошибки та же, а ресурсов меньше.

Расходы не исчезают.
Их просто перекладывают в другую корзину.
И там они часто становятся ещё больше: потерянная выручка, простои, дорогие аварии, ручное тушение проблем, выгорание сильных людей, замедление изменений и потеря управляемости.

Поэтому для собственника и CEO правильный вопрос не «где порезать бюджет?», а «как уменьшить стоимость функции, не разрушив бизнес?»

Нормальный подход всегда последовательный.

Первое: не трогать критические сервисы.
Если касса должна восстанавливаться за час, это нельзя резать ради красивой цифры в бюджете.

Второе: всё некритичное переводить во временно более дешёвую модель.
Например, часть обслуживания рабочих мест временно перевести с абонентской схемы на инцидентную там, где бизнес реально может это пережить.

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

Четвёртое: по каждому решению считать не только экономию, но и последствия для бизнеса: что будет со скоростью изменений, ценой ошибки, управляемостью и стоимостью функции.

Пятое: сделать это прозрачным для CEO и собственника.
Что сократили.
Что не трогали.
Какие риски приняли.
Что изменится во времени реакции, восстановлении и объёме сервиса.

Если этой прозрачности нет, бизнесу продают иллюзию экономии.
На бумаге ИТ стало дешевле.
В реальности расходы просто переложили в другую корзину и там они стали ещё больше.

Сильный CIO снижает затраты не через срезание по живому, а через redesign модели: убирает хаос, дублирование, ненужную сложность и расходы без ценности для бизнеса.

#CIO #CDTO #ITDirector #УправлениеИТ #СнижениеЗатрат #OPEX #SLA #CEO #Управляемость