Бизнес-кейс модернизации серверов для бюджетной комиссии

Что комиссия хочет увидеть в бизнес-кейсе

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

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

Под «эффектом» в серверной теме обычно понимают три вещи:

• Деньги: снижение потерь от простоев, меньше затрат на аварийные работы и поддержку, предсказуемые расходы на 3-5 лет.
• Время: быстрее работают ключевые системы, меньше ожиданий у сотрудников и пользователей, быстрее закрываются инциденты.
• Риск: ниже вероятность остановки сервисов, проще проходить проверки и выдерживать рост нагрузки.

Сразу назовите, что именно вы считаете «модернизацией». Это может быть замена устаревших серверов, расширение мощностей, консолидация нескольких узлов в более компактную схему или переход к более управляемой архитектуре с унификацией.

Чтобы не утонуть в технических деталях, держите фокус на цифрах и проверяемых фактах:

• какие сервисы затрагиваются и сколько людей или подразделений зависят от них
• сколько часов простоя было и как вы считаете стоимость часа
• какие затраты на поддержку есть сейчас (часы, подрядчики, запчасти)
• что изменится после проекта и как это измерить
• какие допущения и ограничения вы принимаете, и что может пойти не так

Отдельным аргументом иногда становятся поставка и сопровождение: сроки, наличие запасных частей, формат реакции, география сервиса. Для комиссий это понятный язык риска, а не «маркетинг железа».

Структура документа: коротко и проверяемо

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

На первой странице оставьте только то, что влияет на выбор:

• цель и что именно меняется (например, обновляем 10 серверов, переносим 6 ключевых сервисов)
• текущая проблема в фактах (простой в часах, просадка производительности, рост инцидентов)
• два сценария: минимальный (закрыть риски) и целевой (получить эффект)
• итоговые цифры: CAPEX, OPEX, экономия, срок окупаемости
• эффект по годам на горизонте 3-5 лет (короткая таблица на несколько строк)

Дальше нужен развернутый расчет в приложении. Важно, чтобы там были не только формулы, но и откуда взялись числа.

В приложении обычно достаточно четырех блоков:

• расчеты и логика (что считали, какие формулы, что включили в TCO)
• допущения и источники данных (тикеты, мониторинг, зарплатные ставки, тарифы, SLA)
• риски и что будет, если допущения не сбудутся (например, эффект ниже на 20%)
• смета по сценариям и границы проекта (что входит, а что нет)

Если в решении участвует интегратор или производитель (поставка и внедрение «под ключ»), структура все равно должна держаться на цифрах и проверяемых исходных данных, а не на описании оборудования.

Собираем исходные данные без долгих обследований

Чтобы кейс прошел комиссию, важнее не «идеальная» точность, а понятные источники данных и простые допущения. Большую часть цифр реально собрать за 1-2 дня, если заранее договориться, где берете факты: журналы мониторинга, Service Desk, отчеты ИБ и бухгалтерия.

Начните со списка критичных сервисов. Обычно это бухгалтерия и бюджетирование, документооборот, ключевые регистры и базы, почта и совместная работа. Для каждого сервиса зафиксируйте владельца (кто отвечает за процесс) и «цену ошибки»: что останавливается при простое и что считается критичным с точки зрения сроков.

Дальше быстро определите, кто реально страдает от сбоев. Нужны не все сотрудники, а 3-5 подразделений, где сбой сразу превращается в задержки: бухгалтерия, закупки, архив или канцелярия, операционный блок, контакт-центр. Обычно хватает короткого интервью на 20 минут и одного примера «проваленного дня».

По метрикам берите то, что уже есть: количество инцидентов, длительность простоев, среднее время восстановления (MTTR), размер очереди заявок и время реакции. Даже если данные неполные, важно честно указать период (например, последние 6-12 месяцев) и источник.

Проверьте текущие расходы, которые часто «размазаны» по статьям. Удобно собрать их в несколько строк:

• внутренняя поддержка (часы админов, дежурства)
• запчасти и ремонты
• внешние подрядчики и выезды
• лицензии и продления
• штрафы или потери из-за сбоев (если фиксируются)

Простой ориентир: если по Service Desk видно 12 крупных инцидентов за год и средний MTTR 3 часа, это уже база для расчета эффекта. Остальное оформите как допущения и отметьте, что цифры будут уточнены на этапе проекта.

Как в цифрах посчитать эффект от снижения простоев

Комиссии важно, чтобы расчет был проверяемым: какие простои считаем, откуда взялись часы, как получилась стоимость часа. В расчетах удобно разделять простои по типам, потому что у них разная природа и разный эффект от обновления.

Часто достаточно четырех категорий:

• плановые остановки (обновления, регламентные работы)
• аварийные простои (отказы, перегрев, сбои дисков, питания)
• частичные простои (падает один сервис, остальные работают)
• деградации (все работает, но так медленно, что люди фактически ждут)

Базовая формула проста: потери = часы простоя x стоимость часа работы сервиса. Вопрос обычно не в формуле, а в честной оценке стоимости часа.

Стоимость часа можно собрать из 2-3 понятных компонентов: зарплатные затраты сотрудников, которые не могут работать; недополученный объем услуг (например, прием граждан, выдача справок, обработка заявок); штрафы или обязательства по SLA, если они есть. Если сервис влияет на несколько подразделений, лучше считать по самому пострадавшему процессу и явно указать, что это консервативно.

Скрытый простой от «медленной работы» удобно переводить в часы ожидания. Пример: 120 сотрудников теряют по 10 минут в день из-за тормозов учетной системы. Это 20 человеко-часов в день. Дальше умножаете на стоимость часа и на число рабочих дней.

Чтобы не спорить о допущениях, покажите диапазон:

• консервативно: берем только аварийные простои и минимальную стоимость часа
• реалистично: добавляем частичные простои и деградации, плюс недополученные услуги

Так комиссия видит не одну «магическую» цифру, а коридор эффекта и логику расчета.

Как оценить эффект от ускорения систем без сложной математики

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

Опирайтесь на несколько показателей: время отклика ключевой системы (учет, документооборот), длительность формирования отчетов, скорость пакетных операций (закрытие дня, выгрузки, расчеты) и доля «пиковых» часов, когда все «тормозит».

Простой расчет в деньги

Выберите 3-5 типовых операций, которые делают многие и часто. Замерьте «до» на текущей инфраструктуре и «после» на пилоте или тестовом стенде. Дальше переводите эффект:

• экономия времени в день = (время до - время после) x число операций x число пользователей
• экономия в год = экономия в день x рабочих дней
• денежный эффект = экономия часов x средняя стоимость часа сотрудника

Пример: отчет формируется 6 минут, станет 3 минуты. 40 сотрудников запускают его 2 раза в день. Экономия: 3 минуты x 80 запусков = 240 минут в день, то есть 4 часа. Умножаете на рабочие дни и стоимость часа (можно взять зарплату с начислениями или внутреннюю ставку).

Не обещайте «в 10 раз быстрее» без условий. Фиксируйте, что меняется вместе с серверами (хранилище, сеть, база данных), и где ускорение может не проявиться (узкое место в приложении, ограничения лицензий, внешний канал). Так расчет выглядит честно и проверяемо.

Поддержка и сопровождение: где обычно прячутся деньги

В серверных проектах комиссия часто видит только цену закупки, а основные потери сидят в поддержке. Их сложно заметить, потому что они растянуты во времени: мелкие заявки, выезды, срочные замены, ручные операции после сбоев.

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

Практичный способ посчитать экономию - оттолкнуться от количества инцидентов и трудозатрат на один инцидент. Например: сейчас 18 инцидентов в месяц, средняя трудоемкость 2,5 часа, участвуют два специалиста (1-я и 2-я линия), плюс один выезд раз в месяц. После унификации платформы вы прогнозируете 10 инцидентов в месяц и 1,5 часа на инцидент. Экономия в часах видна сразу, без сложной модели.

Для защиты удобно показать эффекты в нескольких строках:

• снижение инцидентов (шт/мес) и средней длительности устранения (ч)
• уменьшение выездов и срочных закупок «по факту поломки»
• унификация: меньше разных моделей и запчастей, проще обучение и регламенты
• высвобождение часов ИТ на задачи учреждения (без увеличения штата)

Отдельно зафиксируйте план ЗИП и поддержки: что хранится на месте (диски, блоки питания), что меняется по гарантии, какой срок реакции нужен. Если рассчитываете на 24/7 поддержку и сервисную сеть поставщика, это можно оформить как снижение риска длительных простоев и расходов на экстренные выезды. Главное - честно указать допущения: текущая статистика инцидентов, ожидаемый эффект от унификации и ограничения (например, «при сохранении текущей нагрузки и режима эксплуатации»).

TCO на 3-5 лет: простая модель расходов

Чтобы комиссия поверила цифрам, покажите не только цену покупки, а полную стоимость владения (TCO) на 3-5 лет. Такой горизонт проще защитить: он совпадает с типичным сроком обновления серверов и помогает увидеть расходы, которые «текут» каждый год, даже если CAPEX разовый.

Начните с двух корзин затрат и перечислите их простым языком, чтобы финансы и ИБ одинаково понимали, что именно вы считаете.

• CAPEX: серверы, СХД (если нужна), сетевое оборудование, стойки и ИБП, монтаж и пусконаладка
• OPEX: электричество и охлаждение, сервис и запчасти, продление гарантии, лицензии и подписки, работа подрядчиков или внутренней поддержки

Дальше сравнивайте сценарии «оставить как есть» против «модернизации». База (as-is) должна быть честной, иначе расчет легко «разобьют» вопросами.

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

Простой формат: берете 3 года, показываете сумму CAPEX в год 1, затем OPEX по годам, и итоговую разницу между сценариями.

Пошагово: как собрать бизнес-кейс за 5 рабочих дней

Делайте кейс как короткий проект на неделю: каждый день дает проверяемый результат, который можно показать и перепроверить.

План на 5 дней

• День 1: зафиксируйте проблему фактами. Соберите 3-5 подтверждений: инциденты из Service Desk, отчеты по SLA, письма пользователей, окна простоя, сроки восстановления. Нужны даты, длительность, затронутые системы.
• День 2: опишите 2-3 сценария обновления. Обычно хватает «минимум, чтобы снизить риски», «целевой на 3 года» и «поэтапно, если бюджет режут». Для каждого сценария запишите, что меняется: серверы, СХД, резервирование, поддержка.
• День 3: посчитайте эффекты по трем корзинам. Простои (сколько часов в год и цена часа), скорость (сколько людей ждут системы и сколько времени теряют), сопровождение (сколько стоит поддержка старого парка: выезды, запчасти, ночные работы).
• День 4: сведите все в одну таблицу. Инвестиции, ежегодная экономия, срок окупаемости, рядом допущения и риски. Если используете предложения вендоров или интеграторов, фиксируйте, что включено в цену.
• День 5: подготовьте защиту на 5-7 слайдов. Проблема, варианты, расчеты, риски, план внедрения, что нужно от комиссии.

Короткий пример допущения: «ERP простаивает 6 часов в квартал, в простое участвуют 80 сотрудников, средняя стоимость часа 4 000 тг». Комиссии проще принять расчет с понятной логикой, чем «точные» цифры без источников.

Пример сценария с понятными допущениями

Районная организация: 220 сотрудников, три ключевые системы. 1С и бухгалтерские сервисы, электронный документооборот, общий файловый ресурс (шаблоны, приказы, сканы). Пользователи жалуются на «подвисания», а ИТ-отдел тратит время на ручные перезапуски и восстановление после сбоев.

Исходные данные за прошлый год (берем из того, что уже есть): 8 аварийных простоев. Средняя длительность одного простоя - 2,5 часа, плюс около 1 часа «раскачки» после восстановления (очереди заданий, повторные операции). Итого 28 часов недоступности. Допущение по стоимости часа простоя: затраты времени пользователей плюс сверхурочные ИТ, консервативно 150 000-250 000 тенге/час (не «упущенная прибыль», а реально оплачиваемое время и срывы регламентов).

Сценарий модернизации: обновить серверы и привести платформу к одному стандарту (одинаковые версии ОС, типовые роли, единый мониторинг и резервное копирование). Цель не «ускорить все в 10 раз», а снизить аварийность и упростить поддержку.

Ожидаемый эффект (консервативно): 8 простоев в год превращаются в 2, средняя длительность - 1 час. Недоступность падает с 28 до 2 часов, экономия 26 часов. В деньгах: 3,9-6,5 млн тенге в год. Плюс снижение заявок в поддержку на 20-30% (фиксируем по Service Desk), что освобождает 0,2-0,4 ставки ИТ без найма.

Если общий бюджет модернизации 10-18 млн тенге (серверы, внедрение, перенос, тесты), срок окупаемости выходит в диапазоне 18-36 месяцев. Такой формат обычно воспринимается лучше: есть диапазон, допущения и проверяемые источники.

Чтобы комиссия «видела цифры», приложите:

• выгрузку инцидентов с датами и длительностью
• короткие замеры времени операций «до» (открытие отчета, проведение документа)
• статистику заявок в поддержку по категориям
• расчет стоимости часа простоя с формулой и источниками (ФОТ, количество пользователей)
• план работ и окна простоя на миграцию

Частые ошибки, из-за которых кейс не проходит

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

Первая проблема - слишком оптимистичные проценты по снижению простоев. Если вы пишете «минус 70%», укажите, откуда это берется: статистика инцидентов за прошлый год, журнал обращений, данные мониторинга. Без опоры лучше брать консервативный сценарий (например, 15-25%) и показать диапазон.

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

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

Четвертая - не учитывать риски: сроки поставок, совместимость со старым ПО, ограничения по лицензиям и требованиям безопасности. Это особенно критично, если есть привязка к конкретным версиям ОС, СУБД или виртуализации.

Пятая - отсутствие варианта «поэтапно». Если бюджет сокращают, кейс должен выживать: сначала ядро (критичные сервисы), потом менее важные узлы.

Проверьте себя по короткому списку:

• для ключевых процентов есть источник и консервативный сценарий
• CAPEX и OPEX разделены и подписаны понятными словами
• учтены миграция, тестирование, обучение и резерв времени
• риски поставки, совместимости и лицензий описаны с мерами снижения
• есть план поэтапного внедрения с эффектом на каждом шаге

Если работаете с локальными поставщиками и интеграторами, отдельно фиксируйте, как это влияет на сроки поставки, поддержку и требования закупочных процедур. Без обещаний, только проверяемые факты.

Риски и допущения: как оформить честно и убедительно

Комиссия обычно «ловит» не на цифрах, а на том, что в расчетах спрятаны невысказанные ожидания. Поэтому риски и допущения лучше писать коротко и сразу рядом указывать, что вы сделаете, чтобы риск не превратился в проблему.

Хорошее правило: каждый риск отвечает на вопрос «что может пойти не так?», а мера снижения - «что делаем заранее?». При переключении на новые серверы почти всегда будет короткий простой. Если вы это признаете и заранее планируете окно работ ночью или в выходной, это выглядит сильнее, чем обещание «без остановки».

Риски проекта и как их снизить

• Сроки поставки и внедрения. План с буфером и этапностью (сначала тестовый контур, потом продуктив), чтобы задержка одной части не срывала все.
• Миграция и простой при переключении. Пилот на одном сервисе, репетиция переключения, резервный план отката на старое оборудование.
• Совместимость и производительность. Проверка ключевых систем на тестовом сервере, согласованный набор метрик (время отклика, загрузка CPU, IOPS) и критерии «принимаем/не принимаем».
• Отказоустойчивость. Резервирование по питанию, дискам и сети, регулярные тесты восстановления, чтобы «есть резерв» подтверждался практикой.
• Кадровый фактор. Назначенный владелец миграции со стороны ИТ, понятный график работ и ответственность подрядчика за поддержку в первые недели.

Как фиксировать допущения, чтобы их приняли

Допущения лучше оформлять как список «мы считаем так, потому что иначе расчет будет другой». Указывайте источник и что изменится, если допущение не выполнится.

Примеры:

• стоимость часа простоя берется из внутренних данных (простой сотрудников, штрафы, регламенты). Если точных данных нет, используйте консервативную оценку и явно отметьте это
• прогноз нагрузки подтвержден планом подразделения. Если рост не случится, эффект будет ниже, но риски отказов все равно уменьшаются
• окно работ на переключение согласовано с бизнесом. Если окно сократят, вырастут затраты на подготовку и резерв

Если вы закладываете условия сервиса поставщика (реакция, наличие запасных частей, формат 24/7), вынесите это в допущения и проверьте, что все подтверждено документально.

Быстрый чек-лист перед подачей на бюджетную комиссию

Перед подачей: данные, расчеты, доказательства

Заранее соберите минимум, который можно быстро перепроверить:

• контур и критичность: перечень серверов и систем, владельцы сервисов, сколько пользователей, допустимое окно простоя, текущие требования к доступности
• факты по надежности: простои за 6-12 месяцев (из заявок или мониторинга), среднее время восстановления, основные причины (железо, питание, СХД, ОС, человеческий фактор)
• логика расчетов: базовый сценарий (как сейчас) и целевой (после обновления), единицы измерения (часы, тенге, FTE), без двойного учета
• полная стоимость владения: что включено в CAPEX и OPEX на 3-5 лет (поддержка, запасные части, лицензии, электроэнергия, место в стойке, выезды, обучение)
• приложения для проверяемости: спецификации и КП, план миграции с датами и ответственными, таблица допущений и рисков, согласование от владельцев ключевых систем

Если закупка зависит от требований по локальному содержанию или комплаенсу, приложите подтверждающие документы поставщика (статус отечественного производителя, сертификаты ISO, условия сервисной поддержки и покрытие по регионам). Это снимает часть вопросов еще до защиты.

На защите: что сказать и как отвечать

Три тезиса, которые обычно работают:

• мы покупаем не железо, а снижение простоев и рисков, с понятной ценой часа и подтвержденной статистикой
• вариант выбран потому, что дает лучший эффект на 3-5 лет по TCO и поддержке, а не потому что «мощнее»
• переход запланирован так, чтобы снизить риск внедрения (пилот, окно работ, откат, ответственность)

Три типовых вопроса и короткие ответы:

Почему сейчас? Есть измеримые сигналы: рост инцидентов, срок поддержки, дефицит запчастей, увеличение нагрузки.

Почему не продлить жизнь текущим? Это не закрывает ключевые риски и часто дороже из-за аварийных работ и простоев.

Что если эффект окажется меньше? В модели есть консервативный сценарий, а допущения вынесены отдельно и будут контролироваться по KPI после запуска.

Следующие шаги: как перейти от расчета к проекту

Когда цифры согласованы, комиссии важно увидеть, что вы понимаете путь от идеи до запуска. Переведите кейс в конкретный план: что покупаем, как переносим, кто отвечает, как меряем результат.

Зафиксируйте 2-3 варианта модернизации (точечная замена серверов, обновление кластера виртуализации, гибридный подход) и запросите коммерческие предложения. В запросе сразу укажите допущения из расчета (текущие простои, критичные сервисы, окно работ), чтобы сравнение было честным.

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

Если для вашей организации важны локальное производство и прозрачная цепочка поставок, это можно учитывать как фактор риска и сопровождения. Например, GSE.kz (gse.kz) - технологический производитель и системный интегратор в Казахстане, который выпускает компьютеры и серверы в РК и оказывает круглосуточную поддержку через сервисную сеть. Такие параметры удобно фиксировать в допущениях и подтверждать документами в составе закупки.

Пилот уместен, если спорят о производительности или совместимости. Выберите один сервис или небольшой контур и заранее определите критерии успеха:

• время отклика и время пакетных операций
• фактические простои при переносе
• нагрузка на поддержку (сколько инцидентов)
• требования к резервному копированию и восстановлению

Если нужен подрядчик, проверьте состав работ и SLA: какие работы входят (миграция, тесты, документация), кто отвечает за откат, какие сроки реакции на инциденты и как фиксируется выполнение.