Разбираем, как Dell Technologies превращает продажи оборудования в сервисы и регулярную выручку: портфель, поддержка, подписки, финмодели и партнеры.
«Превратить железо в сервис» — значит перестать продавать оборудование как разовую покупку и начать предлагать клиенту предсказуемый результат: вычисления, хранение данных, резервное копирование, восстановление, обновления и поддержку — в виде понятного пакета с регулярной оплатой. Для заказчика это выглядит не как поставка серверов или СХД, а как готовая услуга с измеримыми показателями, сроками реакции и ответственностью.
Корпоративным ИТ-командам важно не столько владение «коробками», сколько непрерывность процессов. Сервисная модель помогает:
В enterprise-сегменте ценность создается на горизонте нескольких лет: оборудование обновляется, нагрузки меняются, появляются требования по безопасности и соответствию. Доверие, прозрачные правила обслуживания и единый контур поддержки превращают поставщика в долгосрочного партнера — а повторные продажи возникают естественно: через расширение, модернизацию, продление услуг и новые уровни SLA.
Первыми в сервис обычно превращаются элементы, где проще описать результат и измерить качество:
Дальше разберем, как Dell Technologies и партнеры выстраивают переход от поставок к подписке, какие модели «инфраструктура как сервис» встречаются чаще всего и как оценить готовность компании к такому формату — без перегруза терминами.
Традиционные поставки инфраструктуры чаще всего выглядят как «проект под ключ»: заказчик формирует ТЗ, поставщик привозит оборудование, помогает внедрить — и на этом основная часть выручки фиксируется один раз. Дальше остаются гарантия, отдельные заявки в поддержку и, возможно, следующий проект через год-два.
Сервисная модель меняет логику: вместо продажи «железа» как результата продаётся доступ к нужной мощности и предсказуемый уровень сервиса. Для заказчика это способ быстрее масштабироваться и проще планировать бюджет, для поставщика — создать стабильный поток платежей и понятные точки роста.
В классическом сценарии цепочка обычно такая: проектирование → поставка → внедрение → закрытие проекта.
Выручка признаётся в момент поставки/ввода в эксплуатацию, а ключевой фокус команды — выполнить проект в срок и в рамках спецификации. После завершения проекта отношения нередко «остывают»: клиент обращается нерегулярно, а новые продажи часто зависят от следующего большого апгрейда.
В сервисной логике клиент платит регулярно — ежемесячно или ежеквартально — за потребление и управляемость. Сюда почти всегда входят:
Продажи становятся «живыми»: клиент может стартовать с базового уровня, а затем постепенно наращивать объём — без нового капитального проекта каждый раз.
Вместо разовой маржи на поставке появляются метрики, связанные с удержанием и ростом в существующей базе:
Сервисная модель приносит регулярность, но повышает ответственность:
По сути, поставщик становится не продавцом оборудования, а операционным партнёром. Это и есть главный сдвиг: от разовой сделки — к долгосрочным обязательствам и долгосрочной выручке.
Когда инфраструктура становится основой бизнес‑процессов, заказчик выбирает не «коробку», а предсказуемость на годы вперед. Поэтому в enterprise‑сегменте повторные продажи рождаются из отношений: доверия, совместного планирования и прозрачных правил взаимодействия.
Длинный горизонт появляется там, где контракт описывает не поставку, а результат и управление рисками. Чаще всего это:
В enterprise стоимость простоя измеряется не только деньгами, но и репутацией, штрафами, риском остановки цепочек поставок. Доверие строится вокруг вопросов: кто отвечает за доступность, как быстро восстанавливаемся, как измеряем качество. Здесь особенно важны понятные SLA, фактические показатели выполнения и честная коммуникация при инцидентах.
Когда вендор и заказчик регулярно синхронизируют планы развития — потребности в емкости, требования по безопасности, сроки вывода систем из эксплуатации — снижается желание «перепрыгнуть» к другому поставщику ради разовой скидки. Roadmap превращает закупки в управляемый жизненный цикл.
Регулярные QBR (ежеквартальные обзоры) помогают удерживать курс:
Так enterprise‑отношения превращают разовые сделки в устойчивую выручку — не за счет «привязки», а за счет управляемости и совместной ответственности за результат.
Когда у вендора есть не один «флагманский» продукт, а связанный портфель инфраструктуры — серверы, СХД, сети и HCI — из этого проще собрать решения под разные задачи бизнеса. Для заказчика это означает меньше разрозненных поставщиков и меньше «стыков» между компонентами, а для поставщика — больше сценариев, где можно предложить сервис, а не разовую поставку.
Один и тот же клиент может одновременно решать несколько задач: виртуализация, резервное копирование, VDI, высоконагруженные базы данных, периферийные площадки, DR-сайт. Если у вас в портфеле есть базовые «кирпичи» (compute, storage, network) и интегрированные платформы (HCI), то вы не продаёте «железку под проект», а собираете повторяемые сервисные конструкции: производительность как услуга, ёмкость как услуга, площадка как услуга.
Совместимость и единая архитектурная логика (общие подходы к управлению, мониторингу, обновлениям, совместимые линейки) помогают заказчику стандартизировать инфраструктуру. Стандартизация снижает операционные риски: проще обучать команду, проще масштабировать, меньше сюрпризов при росте.
Для сервисной модели это критично: если компоненты заранее «дружат», их легче упаковать в понятные уровни обслуживания и гарантии.
Когда поставщик закрывает больше частей ИТ-цепочки, клиенту удобнее расширять потребление в рамках одной логики: добавить узлы HCI, увеличить объём СХД, усилить сетевой слой, подключить резервное копирование или DR. Апсейл становится не отдельной «закупкой нового решения», а повышением уровня сервиса или расширением пакета.
Каталог сервисов обычно строится в несколько уровней:
Так «железо» перестаёт быть набором спецификаций и превращается в продуктовую витрину, где клиент выбирает не модель устройства, а результат и уровень поддержки.
Инфраструктура как сервис (IaaS в корпоративном смысле) — это когда заказчик получает не «поставку железа», а заранее описанный результат: вычислительные ресурсы, хранение, рабочие места или площадку на периферии — с понятными правилами потребления и поддержкой.
Ключевая логика здесь простая: платим за использование или готовность, а не за факт поставки оборудования. Это меняет разговор с «сколько стоит сервер» на «сколько стоит обеспечить 200 виртуальных машин с нужной производительностью и доступностью».
В типовой модели «оборудование + сервис» в одном договоре объединяются:
Важно: в «железо → сервис» основная ценность появляется не в коробках, а в том, что инфраструктура предсказуемо работает и масштабируется по понятным правилам.
Чтобы подписка была прозрачной, сервис описывают через измеримые «единицы»:
Первые пилотные проекты выбирают там, где легче посчитать эффект и быстрее показать стабильность:
Такой старт помогает быстро договориться о метриках потребления и SLA, а затем расширять каталог сервисов без «пересборки» модели каждый раз заново.
Покупка оборудования решает вопрос «что поставить в стойку», но не отвечает на ежедневные вопросы эксплуатации: кто следит за состоянием, вовремя обновляет, проверяет резервные копии и планирует рост емкости. Управляемые услуги закрывают именно эту «операционную яму» — и в этом месте для заказчика появляется ощутимая ценность, за которую удобно платить регулярно.
Обычно в пакет попадают практичные, повторяющиеся задачи:
Это не «опции ради галочки», а набор процессов, которые снижают риск простоя и снимают рутину с внутренней ИТ-команды.
Поддержка чаще всего реагирует на проблему: приняли заявку, диагностировали, помогли восстановить, при необходимости заменили компонент.
Управление работает проактивно: предотвращает инциденты, берет на себя регулярные регламенты и отвечает за согласованный результат (например, актуальные патчи и проверяемые бэкапы). Для заказчика это разница между «нам помогут, когда сломается» и «за нас следят, чтобы не сломалось».
SLA делает ожидания прозрачными и измеримыми. Типовые параметры:
Сервисная модель уменьшает непредвиденные затраты на авралы, штрафы за простои и переработки. ИТ-команда заказчика меньше тратит времени на «дежурный режим» и регламенты, а больше — на проекты, которые дают бизнесу эффект. В результате общая стоимость владения (TCO) становится более предсказуемой, а риски — управляемыми.
Разовая поставка оборудования заканчивается в день подписания актов. Сервисная модель начинается именно там: ценность смещается в управление жизненным циклом — от «купили и забыли» к предсказуемой работе, плановым изменениям и измеримому уровню сервиса.
Когда инфраструктура находится под наблюдением, поддержка перестает быть реактивной. Телеметрия (показатели состояния, загрузки, ошибок) помогает заранее увидеть деградацию компонентов и запланировать замену до инцидента.
Это превращает поддержку в регулярную услугу с понятными результатами для клиента: меньше простоев, меньше внеплановых выездов, меньше «пожаров» ночью. Для поставщика — повторяемые процессы, которые можно стандартизировать и включать в пакет подписки.
В сервисной модели обновления прошивок, расширение емкости, добавление узлов или лицензий — не чрезвычайное событие, а часть календаря. Клиент заранее понимает:
Так появляются регулярные точки контакта и основания для допродаж: не «замена всего», а пошаговые улучшения под потребность бизнеса.
Практично мыслить четырьмя этапами: планирование → внедрение → оптимизация → обновление. На каждом этапе есть своя услуга: дизайн и сайзинг, ввод в эксплуатацию, настройка и тюнинг, затем модернизация и вывод из эксплуатации.
Критично избегать абсолютных гарантий вроде «никогда не будет простоев». Вместо этого фиксируйте конкретику в SLA: время реакции и восстановления, окна обслуживания, исключения, зоны ответственности и измеримые метрики. Это защищает обе стороны и делает повторную выручку устойчивой.
Переход от разовой поставки «железа» к подписке меняет не только форму договора, но и финансовую логику. Вместо крупного платежа один раз появляются регулярные начисления, а значит — другой денежный поток и другие показатели здоровья бизнеса.
Сервисный контракт сглаживает выручку: деньги приходят ежемесячно или ежеквартально, что упрощает планирование закупок, найма и развития практики. Для заказчика это тоже понятнее: платежи становятся «операционными», а не «событийными» — без резких всплесков бюджета при обновлении инфраструктуры.
Есть нюанс: на старте сервисной модели обычно выше затраты (поддержка, мониторинг, запасы, выездные работы), а выручка «растягивается» во времени. Поэтому важно заранее понимать, когда подписка окупит вложения в запуск услуги.
CAPEX похож на покупку автомобиля: заплатили много сразу, дальше — отдельные расходы на обслуживание.
OPEX ближе к каршерингу или подписке на связь: платите регулярно и ожидаете, что сервис «просто работает», а обслуживание уже включено.
Самая частая ошибка — недооценить себестоимость сервиса и операционные процессы: труд инженеров, время реакции по SLA, стоимость запасных частей, лицензий, инструментов мониторинга и управления. Если это не заложено в цену и модель поддержки, подписка может приносить выручку, но не приносить прибыль.
Сервисная модель редко «взлетает» усилиями одного вендора: заказчикам нужна не только платформа, но и внедрение, настройка процессов, интеграция с текущей ИТ-средой и понятный операционный контур. Здесь ключевую роль играет партнерская экосистема — интеграторы и сервис-провайдеры, которые умеют превращать типовой набор технологий в работающий сервис под конкретную отрасль и требования.
Партнеры закрывают то, что сложно стандартизировать на уровне производителя: предпроектное обследование, миграции, интеграцию с системами мониторинга и ITSM, настройку резервного копирования, обучение команды заказчика. В отраслевых проектах они добавляют «упаковку» в виде регламентов, типовых архитектур и практик эксплуатации — например, для ритейла, производства или финансового сектора.
Чтобы сервисная модель масштабировалась без конфликтов, заранее фиксируют границы ответственности:
Экосистема позволяет быстрее тиражировать сервис: появляются типовые пакеты, единые подходы к SLA, предсказуемая стоимость внедрения и понятный «маршрут» от пилота к промышленной эксплуатации. Заказчик при этом получает выбор исполнителя и локальную экспертизу, а не «один путь для всех».
Удобный формат — базовый пакет + опции + услуги проекта:
Такое предложение легче покупать, масштабировать между филиалами и сравнивать по ценности, а не по «списку железа».
Переход к модели «железо → сервис» лучше начинать не с тотальной перестройки ИТ, а с 1–2 прикладных сценариев, где эффект измерим и виден быстро. Это снижает риски, помогает выстроить процессы и заранее понять, какие части инфраструктуры выгоднее покупать как сервис, а какие — оставить в собственности.
Хорошие кандидаты: резервное копирование как сервис, виртуальные рабочие места для отдельного подразделения, тестовые среды (dev/test), расширение хранилища под конкретный проект. Критерии выбора:
До подписания договора зафиксируйте контур ответственности: кто обеспечивает мониторинг, патчи, замену компонентов, управление емкостью, обновления, интеграцию с вашей службой поддержки.
Заранее разделите:
Спросите заранее:
Если эти пункты согласованы на старте, сервисная модель обычно воспринимается не как «подписка ради подписки», а как управляемый инструмент для скорости, предсказуемости и контроля затрат.
Когда модель уже определена на бумаге, часто не хватает «упаковки» в виде клиентского кабинета, формы заказа, калькулятора тарификации, черновика каталога услуг и шаблонов SLA/RACI.
Здесь может помочь TakProsto.AI — российская vibe-coding платформа, на которой такие внутренние веб‑приложения можно собрать из простого чата: например, портал каталога сервисов, заявки на расширение мощностей, экран отчетности по SLA или прототип биллинга. Полезны и встроенные механики вроде planning mode (чтобы сначала согласовать логику и роли), а также снапшоты и откат — чтобы безопасно тестировать изменения в сервисных сценариях. Важно, что TakProsto.AI работает на серверах в России и позволяет экспортировать исходники и развертывать приложение в вашем контуре.
Сервисная модель снимает часть операционной нагрузки с ИТ-команды, но добавляет новые точки контроля: ожидания по SLA, границы ответственности, требования безопасности и риски зависимости от поставщика. Хорошая новость — большинство проблем предотвращаются не «героизмом», а фиксацией правил игры.
Частая ошибка — воспринимать SLA как обещание «всё всегда работает». На практике SLA описывает измеряемые параметры (доступность, время реакции, время восстановления) и условия, при которых они применимы.
Чтобы избежать конфликтов, заранее договоритесь:
Подписка не должна означать «невозможно уйти». Минимальный набор мер:
В управляемых услугах важно контролировать не только инфраструктуру, но и доступ поставщика к ней. Зафиксируйте принципы:
Документы должны отвечать на вопрос «кто что делает и как меняется сервис».
Если вы уже строите сервисный подход, полезно сверить эти артефакты с текущими практиками поддержки и управления изменениями — это ускорит переход и уменьшит «серые зоны» в эксплуатации.
Переход от «железа» к сервисам — это не смена прайс-листа, а перестройка логики ценности для заказчика.
Модель «инфраструктура как сервис» чаще всего дает максимум эффекта, если у вас:
Пройдитесь по четырем вопросам — они обычно показывают, «взлетит» ли подписка и где будет сложнее всего:
Стандартизировано ли текущее железо и ПО? Если каждый объект «собран по-своему», сначала понадобится унификация.
Можно ли измерять потребление и качество? Нужны метрики (емкость, производительность, доступность) и прозрачная отчетность.
Есть ли сервисные процессы? Инциденты, изменения, управление конфигурациями, регулярные обновления — без этого SLA превращается в формальность.
Понятна ли финансовая модель? Что переезжает из CAPEX в OPEX, какие лимиты, как учитываются пики нагрузки, как считать TCO.
Соберите инвентаризацию инфраструктуры и превратите ее в черновик сервисного каталога: 5–10 типовых сервисов с понятным составом, границами ответственности и SLA. Затем выберите 1–2 пилотные площадки и проверьте модель на реальных сценариях.
Если нужна база для сравнения подходов, посмотрите материалы в /blog, а для ориентиров по структуре услуг и вариантам расчетов — /pricing.
Это переход от разовой продажи оборудования к продаже результата: вычислительных ресурсов, хранения, резервного копирования, восстановления, обновлений и поддержки по понятным правилам.
Клиент получает предсказуемые параметры (SLA, сроки реакции, ответственность), а поставщик — регулярные платежи и точки для расширения сервиса.
Потому что снижает барьер входа и делает затраты предсказуемыми:
В классической модели выручка фиксируется в момент поставки/ввода в эксплуатацию, а дальше — редкие обращения в поддержку.
В сервисной модели вы продаёте доступ к мощности + управление: регулярные платежи, измеримые SLA и постепенные расширения (добавили ёмкость/узлы/уровень сервиса — вырос чек).
Начните с того, где результат легко описать и измерить:
Эти зоны проще стандартизировать и привязать к SLA.
Чтобы подписка была прозрачной, нужны понятные единицы потребления, например:
Дополнительно зафиксируйте правила перерасхода, пороги и как считается биллинг.
SLA — это договорённость о измеримых параметрах, а не обещание «всё всегда работает». Обычно фиксируют:
Важно заранее определить источники данных: мониторинг, тикет-система, отчётность.
Поддержка чаще всего реагирует: приняли обращение, диагностировали, восстановили, при необходимости заменили компонент.
Управляемая услуга работает проактивно:
Это разный уровень ответственности — его лучше прямо прописать в каталоге услуг.
Они создают «длинный горизонт» за счёт совместного планирования и регулярных точек контакта.
Практика, которая хорошо работает:
Так повторные продажи возникают как расширение сервиса, а не как отдельная разовая закупка.
Ключевые метрики подписной модели:
Практический смысл: деньги зависят не от «сделки», а от качества сервиса и способности наращивать потребление у действующих заказчиков.
Минимальный набор мер, который стоит закрепить до старта:
Дополнительно помогает RACI-матрица: кто отвечает за инциденты, изменения, бэкапы и обновления.
