Как атаки на ЦОДы меняют enterprise‑продажи и выбор IT‑поставщиков

5 атак на дата‑центры за 11 дней: под удар попали ЦОДы Яндекса, Сбера и VK. На фоне дефицита мощностей и роста стоимости размещения крупный бизнес вынужден оценивать новые инфраструктурные риски. Разберемся, что будет с enterprise‑продажами, если сбои продолжатся, какие IT‑проекты сохранят бюджеты и почему одного хорошего SLA уже может оказаться недостаточно для победы в крупной сделке.

Представьте вполне обычную enterprise‑сделку. IT‑директор согласовал требования. Техническая команда провела испытания. Финансовый директор утвердил бюджет. Закупки выбрали поставщика. Осталось подписать договор и приступить к внедрению. Но внезапно выясняется, что дата‑центр, в котором заказчик собирался разместить новую инфраструктуру, не может предоставить нужный объем мощностей в согласованный срок.

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

Причем у первоначального поставщика все может быть в порядке: продукт хороший, цена согласована, технические требования выполнены. Проблема возникла за пределами его решения. Для корпоративных IT‑продаж это неприятная, но важная особенность: сделка зависит не только от продукта, но и от инфраструктуры, на которой этот продукт должен работать.

В октябре 2 026 года этот вопрос перестал быть исключительно гипотетическим. За последние три недели октября под атаки БПЛА попали дата‑центры Яндекса, Сбера и VK — в Сасово, Калуге и Владимире, Саратовской и Ленинградской областях. Часть сервисов продолжают работать штатно, а работа другой части площадок остановлена и Яндекс официально признал, что оценить сроки восстановления оборудования сложно.

На этом фоне я изучил отраслевые исследования рынка и обсудил ситуацию с Евгением Загоруйко, представителем ЦОД Safeharbor, который занимается коммерческой инфраструктурой ЦОДов. По его словам, на момент интервью в доступной его команде инфраструктуре оставалось порядка 70 свободных стойко‑мест. При этом компании продолжают искать площадки для размещения и резервирования оборудования.

1. Проблема возникла до атак, инфраструктурных мощностей уже не хватало

Чтобы понять возможные последствия, сначала разберемся с состоянием рынка.

По данным NF Group, опубликованным «Ведомостями» 2 октября 2 026 года, в Московском регионе на текущий год первоначально планировался ввод 199 МВт мощностей коммерческих ЦОДов. Однако ожидаемый фактический ввод составляет около 65,7 МВт. Получается, примерно 67% заявленных мощностей переносятся на более поздние сроки. Более того, около 80% предложения, заявленного на 2 027 год — это проекты, которые должны были заработать раньше.

Причины не ограничиваются строительными задержками. Современному ЦОДу необходимы электрические мощности, системы охлаждения, инженерная инфраструктура, телекоммуникационные подключения и оборудование. Отсутствие любого критичного компонента может задержать ввод объекта.

С тарифами ситуация тоже непростая

Согласно исследованию iKS‑Consulting и 3 data, во II квартале 2 026 года средняя стоимость аренды стойки мощностью 5 кВт в московском коммерческом ЦОДе выросла до 170,8 тыс. рублей в месяц. Это на 15,7% больше, чем годом ранее.

В Санкт‑Петербурге рост составил 31,3%, до 138 тыс. рублей. При этом речь о средней стоимости конкретной категории размещения. Для стоек высокой мощности, площадок с дополнительными услугами и индивидуальных инфраструктурных конфигураций условия могут существенно отличаться.

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

Допустим, компании необходимо разместить 100 стоек с нагрузкой 10 кВт каждая. Это уже 1 МВт IT‑нагрузки без учета дополнительного энергопотребления инженерных систем. Но найти сто физических шкафов недостаточно. Необходимо обеспечить требуемое питание, охлаждение, сетевые подключения, резервирование и возможность расширения. Поэтому предложение оператора, у которого есть свободные места, не обязательно удовлетворит требования заказчика.

Дополнительную сложность создает рост плотности вычислений. По оценке РТК‑ЦОД, приведенной «Коммерсантом», для ряда конфигураций GPU‑оборудования востребованы стойки на 15–20 кВт, тогда как традиционные машинные залы часто проектировались под 5–8 кВт на стойку. Инфраструктуру приходится переконфигурировать, а ее физическая вместимость при этом может сокращаться.

Теперь представим, что на рынок одновременно выходят несколько крупных заказчиков с потребностью срочно разместить дополнительное оборудование. У них могут быть деньги, утвержденные бюджеты и готовые технические задания. Но подходящего предложения все равно нет. И здесь меняется сама логика enterprise‑переговоров: наличие свободных ресурсов и возможность гарантировать срок запуска становятся не менее важными, чем цена.

2. Почему компания не может просто переехать в другой ЦОД

Когда предприятие теряет доступ к инфраструктуре или решает сменить площадку, проблема выглядит обманчиво простой. Нужно найти другой дата‑центр и перенести туда оборудование.

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

Затем — организовать каналы связи, подготовить сетевую конфигурацию, проверить зависимости приложений, синхронизировать данные и спланировать переключение.

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

• Если серверы повреждены или полностью недоступны, придется восстанавливать не только данные, но и вычислительную среду.

Евгений Загоруйко в интервью оценил сроки поставки отдельных серверных конфигураций в три‑четыре месяца. Это не универсальная цифра: все зависит от оборудования, его доступности и поставщика. Но важен сам механизм. Даже если заказчику удалось найти свободный ЦОД, у него может не оказаться серверов, сетевого оборудования или лицензий, необходимых для запуска приложений.

Отсюда принципиальное различие между резервным копированием и аварийным восстановлением. Резервное копирование создает дополнительные экземпляры данных, пригодность которых необходимо проверять. Disaster Recovery охватывает восстановление IT‑сервисов, включая приложения, вычислительные ресурсы, сети и необходимые зависимости. 

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

• RPO (Recovery Point Objective) — максимально допустимый интервал между последней пригодной для восстановления точкой данных и моментом сбоя. Он определяет, какой объем последних изменений компания готова потенциально потерять.

• RTO (Recovery Time Objective) — максимально допустимое время восстановления сервиса.

Предположим, для системы обработки заказов установлен RTO в четыре часа, а фактический процесс восстановления из резервной копии занимает двое суток. Сама по себе резервная копия может быть исправной. Но архитектура восстановления не соответствует требованиям бизнеса. Чтобы сократить время восстановления, возможно, потребуется постоянно готовая резервная инфраструктура, репликация данных, подготовленная сеть и автоматизация переключения. А это уже другая стоимость решения.

Почему нельзя просто вынести все в регионы

На первый взгляд проблему доступности мощностей можно решить переносом инфраструктуры за пределы Москвы. Но у enterprise‑компаний есть еще одно ограничение: старые приложения и архитектуры, которые не проектировались для распределенной работы.

В интервью Евгений обратил внимание на legacy‑системы, чувствительные к сетевой задержке. Представим приложение, которое выполняет множество последовательных запросов к базе данных. Допустим, перенос базы данных увеличил RTT между приложением и БД на 10 мс. Если одна операция выполняет 20 последовательных запросов, каждый из которых требует отдельного сетевого обмена, дополнительное время ожидания может составить около 200 мс. Для отдельной операции это может показаться небольшим значением. Но при высокой нагрузке и большом количестве зависимых запросов последствия становятся заметнее.

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

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

3. Что произойдет с enterprise‑продажами, если сбои продолжатся

Я бы не стал прогнозировать одномоментную остановку всего корпоративного IT‑рынка. Гораздо вероятнее неоднородная реакция. Одни проекты получат дополнительный приоритет. Другие продолжатся по прежнему графику. Третьи могут быть отложены, потому что заказчик направит ресурсы на восстановление и устойчивость инфраструктуры.

Причем для понимания будущих продаж необходимо учитывать сразу три сценария:

Сценарий первый: локальные инциденты

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

Сценарий второй: повторяющиеся инфраструктурные сбои

Если нарушения работы ЦОДов станут повторяться, больше компаний может перейти от проверки существующих резервов к инвестициям в независимые инфраструктурные контуры. В таком случае меняется структура спроса. Появляются дополнительные проекты, связанные с резервным размещением, модернизацией приложений, сетевой архитектурой и управлением восстановлением. Но одновременно увеличивается конкуренция за IT‑бюджеты.

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

Сценарий третий: длительные масштабные ограничения

Наиболее сложная ситуация возникнет, если инфраструктурные сбои совпадут с дефицитом доступных мощностей, оборудования и финансирования. В таком сценарии заказчики могут сокращать или переносить проекты, не связанные напрямую с критичными бизнес‑процессами. Особенно уязвимыми окажутся инициативы, для которых сложно обосновать измеримый финансовый результат.

При этом инфраструктурные проекты необязательно получат неограниченное финансирование. Рост потребности в резервировании может столкнуться с физической невозможностью быстро предоставить необходимые ресурсы. Именно поэтому потенциальный спрос и реальные продажи могут двигаться в разных направлениях.

Предприятие хочет построить резервный контур. Но у оператора нет мощности, у поставщика оборудования длинный срок поставки, а у интегратора — нет доступной команды. Потребность есть, выручки по проекту пока нет.

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

4. Как изменится воронка enterprise‑продаж

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

Рассмотрим этапы стандартного enterprise‑процесса:

Квалификация: недостаточно узнать бюджет и полномочия

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

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

• где планируется размещение решения;

• есть ли доступные вычислительные и сетевые ресурсы;

• кто отвечает за инфраструктурную часть;

• существует ли резервная площадка;

• зависит ли запуск от поставок оборудования или ввода нового ЦОДа.

Это не означает, что каждый менеджер должен превращаться в системного архитектора. Но продавец, который игнорирует инфраструктурные зависимости, рискует получить красивый прогноз в CRM и неприятный сюрприз перед подписанием договора.

Пресейл: архитектурная экспертиза становится частью коммерческого предложения

На этапе технического обследования заказчика могут заинтересовать вопросы, которые раньше оставались на стороне внутренней IT‑команды. Как продукт поведет себя при недоступности основной площадки? Возможна ли работа в нескольких зонах доступности? Как организуется восстановление данных? Можно ли развернуть решение в резервной инфраструктуре?

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

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

Конечно, заявлять такие показатели можно только при наличии соответствующей архитектуры и результатов тестирования.

Финансовое согласование: решение конкурирует за общий бюджет

Допустим, предприятие одновременно рассматривает внедрение CRM и создание резервного контура для критичных приложений. Оба проекта полезны. Но последствия отказа от них различаются:

• Если компания отложит часть новой функциональности CRM, она может потерять потенциальный эффект от автоматизации.

• Если не обеспечит восстановление системы обработки заказов, она принимает риск остановки существующего бизнеса.

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

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

Заключение договора: важнее становятся обязательства и зависимости

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

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

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

Внедрение: подписанный контракт еще не означает быстрый запуск

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

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

5. Как атаки на ЦОДы меняют критерии выбора IT‑поставщиков

Теперь посмотрим на ситуацию со стороны заказчика. Повреждение дата‑центра само по себе не означает, что все enterprise‑компании немедленно поменяют закупочные стандарты. Однако оно наглядно показывает, что высокая доступность отдельного оборудования или площадки еще не гарантирует непрерывность бизнес‑сервиса. Поэтому при оценке поставщиков могут усиливаться пять критериев.

Реальная отказоустойчивость вместо формального SLA

SLA описывает согласованные характеристики услуги и обязательства поставщика. Но SLA в 99,9% не означает, что система будет работать при любом сценарии повреждения инфраструктуры.

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

Для сравнения: 99,9% доступности соответствует примерно 8 часам 46 минутам допустимой недоступности за год при непрерывном измерении на таком интервале.Для одних систем это приемлемо. Для других — нет. Поэтому заказчику важно оценивать не только заявленную доступность, но и архитектуру резервирования, зависимость от внешних сервисов и процедуры восстановления.

Проверяемые RTO и RPO

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

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

Независимость инфраструктурных площадок

Размещение систем в двух ЦОДах не гарантирует их независимости. Площадки могут использовать общие каналы связи, зависеть от одного внешнего сервиса, общей системы управления или единой точки отказа.

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

Гарантированные сроки и возможность масштабирования

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

Для проектов с большим количеством оборудования эти параметры способны определять сроки всей программы внедрения.

Экономика полного жизненного цикла

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

6. Что это означает для разных категорий поставщиков

Новые требования к устойчивости потенциально затрагивают не только операторов ЦОДов. Посмотрим, какие вопросы могут чаще возникать при закупке разных технологических продуктов.

При этом не стоит смешивать физическую защищенность дата‑центра и кибербезопасность. 

Например, EDR не предотвращает физическое повреждение инфраструктурной площадки. А наличие нескольких антивирусных решений не заменяет полноценный план аварийного восстановления. Задачи разные, хотя при разработке общей стратегии устойчивости они могут пересекаться.

Пример: два SaaS‑поставщика, одна закупка

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

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

Критерий выбора меняется не потому, что дорогая система автоматически лучше. А потому, что компания начинает сравнивать стоимость решения со стоимостью последствий его недоступности.

7. Почему цена перестает быть главным аргументом 

Возьмем условную модель размещения инфраструктуры. Предприятие арендует 100 стоек по 170,8 тыс. рублей в месяц — средней стоимости размещения стойки мощностью 5 кВт в Москве по данным за II квартал 2 026 года. Базовые расходы составят 204,96 млн рублей в год.

За пять лет, без изменения тарифа, получится 1,0248 млрд рублей. Разумеется, это лишь арифметическая иллюстрация: в реальном контракте крупного клиента условия могут отличаться, а полная стоимость размещения зависит от состава услуг.

Теперь допустим, что дополнительное резервирование увеличивает ежегодные расходы на 15 млн рублей.

Дорого? Ответ зависит от того, какие последствия отказа предотвращает эта архитектура.

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

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

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

8. Кто получит новые возможности, а кто столкнется с давлением на продажи

Рассмотрим возможное перераспределение спроса. Потенциально дополнительный интерес могут получить поставщики Backup и Disaster Recovery, облачных мощностей, решений для репликации, инфраструктурного ПО, сетевых систем и услуг миграции.

Системным интеграторам могут потребоваться новые компетенции в модернизации legacy‑приложений и проектировании географически распределенной архитектуры. Региональные ЦОДы способны стать частью резервной инфраструктуры крупного бизнеса, если располагают подходящими ресурсами и обеспечивают необходимую независимость площадок.

Но далеко не все сегменты получат равномерный рост.

По данным исследования КРОК 2 026 года, в котором участвовали 200 IT‑директоров крупных компаний:

• 67% рассматривают TCO и окупаемость как ключевой аргумент выбора IT‑решений;

• 68% планируют отказаться от премиальной поддержки вендоров в пользу собственного сервиса;

• 57% намерены сократить привлечение подрядчиков на сопровождение;

• 41% рассматривают перенос обновления DWH и BI на 2 027 год;

• 34% планируют экономить на лицензировании за счет Open Source‑альтернатив.

Это результаты опроса о планах и приоритетах, а не статистика фактически отмененных контрактов. Но они показывают важную тенденцию: предприятия уже стали внимательнее к экономике IT‑решений.

Ситуация с инфраструктурой может усилить существующий отбор проектов. Для Backup и DR это потенциальный источник спроса. Для ERP, CRM, BI и других корпоративных платформ — дополнительный повод обосновывать финансовую результативность.

Для вендоров инфраструктурного ПО — возможность предложить более эффективное использование ограниченных вычислительных ресурсов. Однако увеличение потребности в технологии не гарантирует соответствующего роста выручки поставщиков.

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

9. Что коммерческим командам стоит изменить уже сейчас

Если инфраструктурные риски становятся значимым фактором корпоративных закупок, enterprise‑продавцам имеет смысл пересмотреть несколько привычных подходов.

Проверить инфраструктурные зависимости сделок

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

Сегментировать аккаунты по инфраструктурным событиям

Публичные сообщения о строительстве новых площадок, модернизации IT‑ландшафта, миграции в облако и организации резервирования могут стать сигналами для Account‑Based Marketing. Но сигнал должен запускать исследование потребностей, а не автоматическую продажу. Сама по себе новость о строительстве ЦОДа еще ничего не говорит о наличии утвержденного бюджета на конкретный продукт.

Пересмотреть коммерческую аргументацию

Вместо перечня возможностей продукта необходимо яснее показывать его вклад в бизнес‑процесс. Что произойдет, если систему не внедрить? Какие расходы она сокращает? Как влияет на критичные операции? Какими цифрами подтвержден эффект? Для инфраструктурных решений важны показатели восстановления, доступности и эксплуатации. Для прикладного ПО — экономия времени, снижение затрат, производительность и влияние на выручку.

Подключать архитекторов раньше

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

Уточнить прогноз продаж

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

10. Что будет дальше 

Было бы слишком просто сделать вывод, что инфраструктурные сбои приведут к сокращению всех корпоративных IT‑продаж. Так же ошибочно ожидать, что необходимость резервирования обеспечит рост всем поставщикам инфраструктуры.

Рынок неоднороден

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

Проекты с менее очевидным эффектом будут конкурировать за финансирование в других условиях. Но многое зависит от отрасли, состояния конкретного заказчика, способности увеличить бюджет и доступности инженерных ресурсов.

• Если сбои останутся локальными, изменение закупочных приоритетов может быть ограниченным.

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

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

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

Инфраструктурные кризисы довольно возвращают IT к фундаментальным вопросам

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

• Для IT‑директоров это инженерные и управленческие задачи.

• Для финансовых директоров — вопрос распределения капитала.

• Для коммерческих команд — изменение структуры спроса, квалификации сделок, аргументации и прогнозирования.

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

Поэтому главный конкурент enterprise‑поставщика сегодня — не только соседний вендор. Теперь это и резервный ЦОД, и миграция критичной системы и инфраструктурный проект, который руководство решило профинансировать первым.

В конечном счете enterprise покупает не серверы, лицензии и стойки. Он финансирует способность бизнеса работать. И выигрывать в сделках будут те, кто сможет доказать свой вклад в эту способность.