Магазин у трассы, небольшой поселок. При разборе платежей наткнулся на счет — ремонт кассового оборудования. Позвонил директору: что случилось?
Объяснила спокойно. Касса не работала. Позвонила мастеру по объявлению. Он приехал, посмотрел — оказалось, нужна была обычная зарядка для ноутбука, который стоял рядом. Купила. Мастер подключил. Дал чек. Она приложила к авансовому отчету и провела по статье "ремонт оборудования".
Всё по правилам. Никто ничего плохого не сделал.
Именно в этом и была проблема.
Почему ИТ-бюджет был маленьким
На старте картина выглядела так: ИТ-бюджет по рыночным меркам был скромным. Его основу составлял ФОТ, что само по себе вызывало вопросы. При этом бюджет постоянно корректировался: что-то срочно нужно было купить, что-то возникало вне плана. 100% исполнения к текущей версии — каждый раз, но каждый раз к другой версии.
Когда у компании сотни ЦФО — магазины, склады, офисы — руководители на местах принимают операционные решения сами. Нужен компьютер новому сотруднику — покупают, проводят по своему ЦФО. Сломался принтер — вызывают мастера, проводят по статье "прочие расходы". На уровне одного объекта это нормальное решение. На уровне сотен объектов — это черный ящик без управляемости.
Берешь магазин с большими цифрами расходов, начинаешь смотреть по фактам — аналитика не совпадает с реальностью. Проверяешь второй — другая картина. В такой ситуации можно принять решение: "покупать мышки не по тысяче, а по пятьсот". Только проверить это невозможно. Завтра мышку проведут не по "прочим расходам", а по хозяйственным товарам или ремонту оборудования. И ты не узнаешь, как это повлияло — раньше покупали за тысячу одну мышку в год, теперь за пятьсот, но четыре раза.
ИТ-бюджет был мал не потому, что ИТ работало эффективно. А потому, что реальные ИТ-расходы компании жили в сотнях других строк.
Сразу оговорюсь об одном разграничении. В этой статье речь про операционный контур: лицензии, сервис, поддержку, ремонты, расходники и регулярные закупки. Инвестиционные статьи — CAPEX, стоимость открытия новых объектов, обновление инфраструктуры — это отдельная логика. Я сознательно вынес их за скобки. Там другие механики и другой разговор с собственником.
Откуда начали: шесть месяцев платежей
Задача звучала просто: понять, сколько компания платит за ИТ на самом деле.
Вместе с CFO разработали новую структуру статей. Ввели разделение ролей: бизнес оставался владельцем потребности и бюджета. ИТ становилось владельцем стандарта, технической спецификации и согласования закупки. CFO получал прозрачную структуру статей и контроль лимитов.
Мышки по-прежнему нужны магазину — потребность там. Но что купить, у кого, по какой цене и сколько — это теперь ИТ.
Дальше взяли платежи всех ЦФО за шесть месяцев и разнесли по новой структуре. Привели к годовому исчислению с учетом корректировок. Это и стало базой расчета: прежний сценарий — хаотичные покупки на местах, разрозненные вызовы, разные мастера, разные цены — против новой модели по каждой категории.
Первый месяц работы нового контроля: ИТ согласовывало все заявки до оплаты. Отсекли значительную часть платежей, которые не проходили проверку по потребности, стандарту или цене. Параллельно увидели проблемы, которые раньше не фиксировал ни один контур — они просто растворялись в прочих расходах.
Где появилась экономия
Когда видишь полную картину расходов, становится понятно, где именно уходят деньги. Работали последовательно по шести направлениям.
1. Видимость расходов
До изменений не было единого места, где можно было увидеть, сколько и за что компания платит в ИТ. Расходы жили в сотнях строк разных ЦФО под разными статьями.
Новая структура статей дала первое: всё стало в одном контуре. Стало видно, где расходы обоснованы, где — нет, и где есть системные проблемы, которые раньше просто не фиксировались.
Это не экономия сама по себе. Это условие, без которого никакая экономия невозможна. Нельзя управлять тем, что не видишь.
2. Стандартизация
Параллельно собрали конфигурации всех объектов. Каждый магазин, склад, офис — что стоит, какая модель, когда куплено.
Из этого появились утвержденные конфигурации: что должно быть на типовом объекте каждого формата. Это дало возможность планировать замены — не по факту поломки, а заранее.
По каждой категории определили расчетный норматив. Не гарантийный срок, а коэффициент, основанный на фактических заменах и условиях эксплуатации в сети. Так появился первый бюджет, который отражал реальность: в какой месяц, за что, на каком объекте и сколько предстоит заплатить.
Стандартизация дала и другой эффект: исчез зоопарк моделей. Меньше уникальных конфигураций — меньше аварийных ситуаций, меньше поиска редких запчастей, меньше мастеров, которые умеют работать только с одной маркой.
3. Централизация закупок
До изменений каждый объект решал вопросы сам. Результат предсказуем: никакого объема, никакой переговорной позиции, покупки по первой попавшейся цене.
После первого месяца видимости реальных расходов проверили гипотезу: централизованная закупка с доставкой курьером будет дешевле локальной? Оказалось — в 95% случаев да. Разница к цене локальной покупки составила около 30%.
Для оставшихся 5% выстроили другую схему. Нужна мышь, а курьер приедет через два дня. Сотрудник ИТ говорит директору: "Идите в такой-то магазин, там есть такая-то модель, стоит столько-то". Директор купил, принес чек именно на эту сумму и эту модель.
Часть объектов, где доставка дорогая или долгая, получили управляемый складской запас. Не стихийный, а рассчитанный по нормативу и критичности позиций.
Когда объем стал виден — появилась переговорная позиция. Раньше покупали мышку по полочной цене. Теперь говорили поставщику: в течение года нам нужно столько-то единиц — дайте цену.
4. Лицензии и договоры
Раньше лицензии покупались точечно, по факту потребности. Поставщик ставил цену по прайсу, никто не торговался — каждая покупка была маленькой и разовой.
Когда мы пришли с консолидированной потребностью на год, разговор изменился. Поставщик видит предсказуемый объем, может планировать работу, получать скидку от производителя. Для нас — цена объема вместо цены случайной покупки.
На тысячах точек лицензирования разница в цене за единицу превращается в десятки миллионов рублей в год. Конкретные цифры в рамках NDA, но порядок именно такой.
5. Сервисная модель
До изменений схема была простая: что-то сломалось — вызвали мастера. Один вопрос — один вызов. При среднем потоке два-три выезда в месяц на объект, плюс отсутствие профилактики, аварийная модель была не только дороже — она не решала причину, только симптом.
Перешли на абонентскую модель. Подрядчик приезжает раз в месяц и проводит полное обслуживание всего ИТ-парка магазина. Офис — раз в квартал. Склад — постоянный сотрудник в смену, плюс возможность вызвать усиление при форс-мажоре.
Абонентская модель дала три вещи: предсказуемый платеж, профилактику вместо реакции и один контрагент с понятным SLA вместо случайных мастеров по объявлению.
6. Поддержка и ФОТ
Экономия появилась не только в цене закупки. Она появилась в количестве обращений, аварийных выездов и ручной работы.
На старте — 5 специалистов технической поддержки на 100 магазинов. Люди были загружены, работы хватало.
Когда стандартизировали оборудование, ввели единое окно обращений, выстроили приоритеты по критичности и убрали целый класс проблем через профилактику — соотношение изменилось: 2 специалиста на 100 магазинов при том же уровне сервиса.
Это не потому, что люди стали работать быстрее. Исчезли обращения, которых раньше не должно было существовать: директор магазина ищет зарядку для ноутбука, кто-то покупает мышку в ближайшем супермаркете, мастер приезжает по третьему разу с одной и той же проблемой.
Задача директора магазина — продажи. Когда он тратит время на поиск мастера или разбирается с оборудованием — это не его работа. Это скрытые потери, которые не видны ни в одной строке ИТ-расходов.
Теперь задача директора одна: сообщить о проблеме. Решение, стандарт, поставщик и профилактика — зона ответственности ИТ.
Как считали эффект
Эффект считали не от ощущения "стало дешевле".
Взяли шесть месяцев фактических платежей по всем ЦФО, разнесли по новой структуре статей, экстраполировали на год. Это стало базой.
Дальше по каждой категории сравнили прежний сценарий с новой моделью:
- локальная покупка без стандарта против централизованной закупки по спецификации;
- аварийный вызов против абонентского обслуживания со средним потоком выездов;
- точечные лицензии против годового плана с объемной ценой;
- зоопарк оборудования против утвержденных конфигураций с нормативами замены;
- ручная поддержка без процессов против стандартизированного сервиса с SLA.
Так стало видно: где экономия разовая, где постоянная, а где речь не об экономии, а о снижении риска простоя.
Что получили:
OPEX операционного контура — лицензии, сервис, поддержка, ремонты, расходники — снизился на 40% относительно нормализованного run-rate прежней модели.
TCO типового ИТ-контура магазина — закупка, доставка, настройка, обслуживание, ремонт, замена, лицензии, поддержка и потери от простоев — снизился на 50% относительно прежнего сценария локальных закупок и аварийного обслуживания.
По отдельным программам — централизация закупок, лицензионные договоры, сервисная модель — совокупный эффект превысил 50 млн рублей в год.
Отдельная история — инвестиционные статьи: как принимать решения о CAPEX, как считать стоимость владения по жизненному циклу оборудования и как объяснять эти решения собственнику. Разберу в следующем материале.
Если ИТ-бюджет выглядит маленьким — это не всегда хороший знак. Иногда это значит: компания платит за ИТ, но не видит этого в одной строке.
Резать ИТ-бюджет линейкой — не экономия. Это перекладывание расходов из видимой строки в невидимые.
#cio #opex #tco #управление #итстратегия