Как технически безупречный запрос на серверную завернули на финкомитете — и что я изменил, чтобы бюджет всё‑таки дали.
Мой профиль — строить ИТ‑подразделения, которые из банальной поддержки превращаются в подразделение, с которым считаются при принятии бизнес‑решений. А если точнее — приходить туда, где от ИТ остались руины, и за полгода собирать направление и команду заново, в рамках жёстких ограничений. Вот одна история из практики, которая многому меня научила.
Придя в компанию, я обнаружил стандартную для промышленности картину: всё серверное оборудование — end of life. Построено на старых технологиях, сервисы задыхаются, объёмы не тянут. Запасных частей и расходников для быстрого восстановления нет — при отказе инфраструктура встанет надолго.
Подошёл финансовый комитет. Я начал готовить материалы. Прошлая команда уже заложила бюджет — но после анализа оборудования выяснилось, что нужно в десять раз больше. Задача казалась почти невыполнимой.
И я не пошёл по типовому маршруту, принятому в компании. Я пошёл в язык фактов и цифр — тот самый, который ценят финансисты и генеральные директора, принимающие решения о деньгах.
Я не переделывал презентацию. Я поменял язык
Вот как звучал каждый пункт до и после.
Было: «Упадут 1С, почта и файловое хранилище, и мы не сможем их восстановить».
Стало — три отдельных удара:
Вероятность отказа почтовой системы — около 70% по статистике отказов оборудования этого типа и текущему состоянию железа. Это невозможность отправлять финансовую отчётность — вплоть до срыва финансирования на следующий год.
Отказ 1С — это несданная налоговая отчётность. А это уже прямые штрафы.
Потеря файлового хранилища — остановка планирования ремонтов и закупки запчастей. Рост затрат по этой статье до 30%.
Разница не в содержании. Оборудование то же. Разница в том, что в первом варианте я говорил про свою боль — «сервисы упадут». Во втором — про его боль: отчётность, штрафы, деньги, план.
«А ты уверен, что упадёт?»
Это вопрос, который руководитель задаёт всегда. И на него у меня был ответ, а не страх.
Мы своими силами развернули сбор заявок и фиксацию отказов оборудования в service desk. Начали копить статистику. Динамика отказов росла — и на временной шкале стало видно, когда мы дойдём до точки невозврата. Не «я думаю, что рискованно», а «вот дата, после которой — авария».
Подход к фиксации использовали простой. По каждой заявке отмечали:
тип заявки: отказ, обслуживание, проблема; — перечень оборудования, к которому относится отказ; — вид отказа и с чем связан: аппаратный, программный, интеграционный.
Дальше — просто прослеживаем частоту и строим графики на реальных данных. Точка, где кривая упирается в потолок, — твой дедлайн. Теперь это не мой страх, а факт на графике.
Главное — учесть все обращения до появления системы, и письменные, и телефонные. Пришлось поднимать их вручную, чтобы статистика для комитета была честной. Копили полтора месяца до заседания. А через год, когда обращения стабилизировались, ручной труд специалистов исключили полностью.
И ещё одно, что сняло главный вопрос комитета: систему сбора статистики мы сделали сами и бесплатно. Я пришёл не просить денег на всякий случай — я пришёл с доказательством, что уже выжал из имеющегося максимум и упёрся в предел, который деньгами не обойти.
Чем закончилось
Я не получил того, что просил. Бюджет увеличили не в десять раз, а в восемь.
Но этого уже хватило, чтобы закрыть критичные сервисы и снять первичные риски. А главное произошло не с бюджетом. С этого момента генеральный директор перестал видеть во мне руководителя технической поддержки. Он увидел руководителя ИТ‑блока, который работает на его бизнес: не играется в модные технологии, а считает затраты, оценивает риски и сначала выжимает максимум из внутренних ресурсов.
Это и есть переход, ради которого стоит менять язык. Ты перестаёшь быть «айтишником, который вечно что‑то просит», и становишься человеком, к которому идут за решениями.
Наверх надо идти не с правильным решением. Наверх надо идти с ответом на вопрос, который руководитель задаст первым: «а что будет, если не сделаем — и во сколько это обойдётся».
А у вас были сложности с защитой бюджета на ИТ? На каком вопросе всё ломалось — расскажите в комментариях, разберём.
Пишу про IT на производстве без прикрас — канал в профиле.
Комментарии (28)
ShIV03
26.07.2026 07:24всё правильно.
добавлю, для разнообразия:
Вариант N1. меня, финдиректор быстро научил "Всегда начинай с 'Чего просишь'. 'Зачем' - я и без тебя знаю" (но расчеты - ценил). И так было принято на всем производстве.
Вариант N2. (ох, сколько мне позже от федеральных служб попадало, с их бюрократией - заставляли переписывать, мотивируя) "Никто - начало не смотрит, сразу - за последний абзац". Аналогичное было, и отношение к "Сколько просишь" - обе стороны знали, что принципиально "не совпадает" со "сколечко дадим" - "просить - надо часто".
Dhwtj
26.07.2026 07:24Динамика отказов росла
Почему?
Бизнес быстро менялся не обеспечив рост?
Цифра в 10 раз сильно сомнительна. Обычно, бизнес сам чувствует когда жжет под жопой.
Особенно, если как тут попытка обосновать рост failure rate на основе исторических данных.
Короче, статья нафантазирована чуть более чем полностью
CratosArt Автор
26.07.2026 07:24Все просто, старое оборудование сыпалось. Когда в штате было 50 человек и завод находился на этапе стройки, оно справлялась со своей задачей. А после запуска штат активных пользователей вырос до 550, за очень короткий промежуток времени. Появилась своя операционная деятельность.
Но с вашим мнением я конечно же спорить не собираюсь, ваше право так думать. Но я бы хотел немного обмена опытом, если есть возможность, как вы поступали бы?
Dhwtj
26.07.2026 07:24как вы поступали бы?
Я бы попытался совместно найти обоснованное решение, вместо "кричи о надвигающейся катастрофе, требуй втрое больше нужного, всё равно урежут"
Оборудование не потянет нагрузку? Не услышал такого.
Вырастет failure rate? Вряд-ли в 10 раз, оно скачком не растёт.
Вырастет failure cost в связи с ростом объёмов бизнеса? Вот это может быть, исходя из ваших слов
Но вот это всё равно фантазии:
Вероятность отказа почтовой системы — около 70%
kpmy
26.07.2026 07:24Маркс описывает капитал как самовозрастающую стоимость, для которой весь материальный мир — лишь средство. Индифферентность к реальности здесь — не злой умысел, а встроенная логика: система игнорирует любые сигналы, не угрожающие непосредственно накоплению, и реагирует только тогда, когда воспроизводство стоимости оказывается под ударом.
CratosArt Автор
26.07.2026 07:24Все было придумано уже до нас, нам остается только использовать эти знания.
Ava256
26.07.2026 07:24Сегодня дали денег, завтра ,скажут, что денег нет, но вы держитесь…ИТ-бюджет должен планироваться так же как все остальное.Если этого нет, то в самый ответственный момент денег не дадут, а отвечать за простой будет ИТ-директор или администратор.
CratosArt Автор
26.07.2026 07:24Ну перекладывать ответственность на администратора как-то совсем странно.
000-Vladimir-000
26.07.2026 07:24Есть какая-нибудь нормативка, методика или т.п. документ, по которому можно рассчитывать риски для ИТ-подразделений?
Ava256
26.07.2026 07:24Нет такой нормативки. Вам нужно оценить потери бизнеса от отказа или снижения уровня ИТ-сервисов.После этого оценить вероятность таких потерь. Вот вам и риски. Сколько компания потеряет в день от отказа почты или интернета или 1С? Оценивать такие потери надо вместе с гендиректором.
CratosArt Автор
26.07.2026 07:24А зачем на предприятии директор по ИТ и финансовый директор, если Ген., для оценки нужен?
Можно ведь через юнит экономику посчитать или экспертную оценку на основе синтетики взять.
CratosArt Автор
26.07.2026 07:24Воообще, я склоняюсь к тому направлению, что наше ИТ это такое же оборудование и основная сложность это просчитать стоимость простоя той или иной системы. Поэтому я бы использовал стандартные риски из подходов ТОиР, если нужно могу подсказать чем пользуюсь.
CratosArt Автор
26.07.2026 07:24
Я в своей работе использую данную нормативку. Добавлю: сами по себе стандарты — это рамка, а не ответ. Самое сложное начинается, когда переносишь риски отказа оборудования на конкретную ИТ-систему и считаешь стоимость простоя в деньгах. Вот тут общей нормативки уже мало — нужна привязка к конкретному предприятию и его процессам. Если интересно, могу как-нибудь разобрать на живом примере, как это считается на практике.
EgorSharin
26.07.2026 07:24Потрясающе!
Вы вывели смысл фразы "разводка лохов" на качественно новый уровень: Вы развели лохов для их же пользы.
Я написал это в шутливом тоне, но - искренне, уважаю.
Другая аналогия: Вы общались с заказчиком, как с малым ребёнком: он слишком глуп, чтобы понимать, что ему реально нужно, и слишком истеричен, чтобы с ним можно было говорить как со взрослым. Вы просто опустились до его уровня и объяснили ему так, как он сможет понять.
Это очень круто.
AbuQA
26.07.2026 07:24Всё начиналось так хорошо, были верные мысли, но затем пошел мусорный текст, сгенерированный нейросетью.
Увеличение бюджета в 10 раз? Допустим, на ваш отдел выделено 20 миллионов рублей в год (одна команда разработки из пяти человек плюс расходы на оборудование). Вы действительно просите 200 миллионов под предлогом, что «1С может упасть»? Это абсолютно необоснованно. Компания скорее перейдёт на бумажный документооборот, чем решится на десятикратный рост расходов. В 2026 году мировая экономика в кризисе: команды сокращают, кибератаки стали рядовым явлением, проекты урезают. Если вы придёте к руководству с жалобами и сметой, завышенной в 10 раз, вы просто потеряете доверие к собственной экспертизе. Тем более когда речь идет о 1с. Эти ребята предоставляют готовые решения за смешные деньги.
CratosArt Автор
26.07.2026 07:24Не соглашусь по некоторым пунктам:
События были в 2022 году.
Это было не завышение сметы, а обоснование замены оборудования.
Решения 1С мне нравятся, но что бы заставить работать их из коробки нужно вложить кратно больше денег чем они стоят. Например ERP стоимость лицензий 800 тысяч рублей, а среднее внедрение на предприятии 1000 человек 132 млн рублей. Мало кто готов менять бизнес процессы под 1С, все меняют 1С под свои не очень здоровые процессы.
За мнение спасибо!
Lightxaoc
26.07.2026 07:24С таким подходом ПМ становится похож на брокера рисковых инвестиций. С точки зрения денег наверное верно, брокеру тоже важен объем и количество сделок, но профессионал внутри, если имеет свое мнение всё-таки должен влиять на выбор по максимуму. Но это уже дело каждого. Именно так наверняка и будет работать ИИ ПМ))). Пора приучать понемногу, холодный расчет рисков и бюджетов.
Advisory
26.07.2026 07:24Поделюсь своим лайфхаком. На новом месте работы, на первом заседании бюджетного комитета, мне практически все зарезали. На второе заседание я просто распределил те же самые цифры по департаментам и отделам: это закупщикам, это экономистам, это бухгалтерии, это кладовщикам, это охране труда и т.д., а эта капелюшечка «нам — айтишникам». Называя подразделение добавлял, что «пользователей столько, их нагрузка и потребности такие-то». Кому режем? И каждый (!) руководитель департамента, чьих подчиненых я назвал, стал сам (!) сражаться за «мой» бюджет! Свою боль они лучше меня знают. Клянусь, чес-слово, так и было :-)
Sosnin
26.07.2026 07:24Помнится была история с недалёким руководством: "как сделать, чтобы работало?" - говорю "дайте 50 - возьмем нормальную железку" - не-ее-е, это дорого, бери за 10, через год поговорим ... через полгода деградация - авария, закуп, восстановление - а всё это деньги, нервы, время и кстати закуп опять "подешевле" ... через полгода деградация ...
уволился, контора ушла на аутсорс - им сразу сказали "нехер мозги делать - платите 100/мес (аренда, кроме услуг)" - и неожиданно согласились :)
правда дальше пошло то же самое отношение, но уже по другим проблемам.CratosArt Автор
26.07.2026 07:24Заметил, что часто начинается все хорошо, а потом начинает деградировать в компаниях. Руководство быстро привыкает к хорошей жизни, но в этом больше вина ИТ руководителей.
Wesha
Ну и я моим так же говорю: «Кто платит, тот и заказывает музыку. Поэтому за ваши деньги с радостью реализую даже самую идиотскую идею.»
Иногда приходится реализовывать. Но обычно до этого не доходит — мыслительный аппарат таки включается.
CratosArt Автор
Ну с уровнем накопленного опыта , я все более и более спокойно отношусь к идиотским идеям, иногда выбираю наиболее идиотскую и реализую, что бы показать по ней отрицательную эффективность.
Wesha
Вооооот, Вы постигли Дзен!