--- title: "Практический фреймворк продаж AWS традиционному энтерпрайзу" url: "https://kzsaleshub.com/aws-cloud-sales-framework/" type: "knowledge_article" category: "Облако" language: "ru" source: "KZSalesHub" published: "2026-05-14" last_updated: "2026-09-30" --- # Практический фреймворк продаж AWS традиционному энтерпрайзу Продажа облака компании с собственной инфраструктурой — не презентация, а сопровождение клиента через шесть этапов, где на каждом снимается конкретное возражение. Главная ошибка — говорить о технологии там, где нужно говорить о деньгах, сроках и рисках. Ниже разбор каждого шага и того, что на нём реально решается. ## Почему обычная схема здесь не работает Крупные компании в регионе до сих пор во многом опираются на собственные дата-центры. Для них переход в облако — не апгрейд, а смена модели: капитальные затраты превращаются в операционные, часть контроля уходит наружу, а служба безопасности получает новый класс вопросов, на которые у неё нет готовых ответов. Отсюда следствие, которое определяет всю тактику: вы продаёте не сервисы, а изменение способа работы. Такое решение принимает не технический директор в одиночку — его принимает группа, где у каждого свои критерии. И почти всегда есть тот, кому переход невыгоден лично: у него уже есть подрядчик, компетенция или бюджет, привязанный к текущей схеме. Поэтому фреймворк ниже устроен не как последовательность презентаций, а как последовательность снятых возражений — техническое, экономическое, организационное. ## Шаг 1. Начать с потребности, а не с продукта Первый разговор проваливается чаще всего одинаково: продавец приходит рассказать про облако. Клиент вежливо слушает и не покупает, потому что не услышал ничего про себя. Задача первого шага — найти инициативу, которая уже существует внутри компании. Не создать её, а найти. Формулировки, которые работают: дата-центр переполнен и на горизонте дорогая закупка; конкурент запускает новое быстрее; закончилась поддержка ключевой платформы; регулятор изменил требования; после аварии стало ясно, что резервирования нет. Зафиксируйте эту инициативу словами клиента и с цифрой. Не «ускорить вывод продуктов», а «сократить срок запуска нового сервиса с четырёх месяцев до шести недель». Дальше вы будете возвращаться к этой формулировке на каждом шаге, и она же станет критерием успеха. **Проверка, что первый шаг сделан.** Вы можете назвать: что именно болит, сколько это стоит компании в деньгах или времени, кто внутри компании страдает от этого больше всех и почему они не решили это раньше. Если хотя бы на один вопрос ответа нет, переходить ко второму шагу рано — вы будете предлагать решение задачи, которой нет. ## Шаг 2. Связать задачу с сервисами, а не наоборот На этом шаге ошибка обратная: продавец, разобравшись в потребности, вываливает список сервисов. Клиент видит незнакомые названия и делает вывод, что решение сложное. Правило простое: каждый сервис называется только после того, как названа задача, и сразу переводится в последствие для клиента. Не «данные реплицируются между зонами размещения», а «при отказе площадки сервис продолжит работать, и вы не попадёте в ситуацию прошлого года». Не «инстансы поднимаются за минуты», а «новая среда для тестирования появляется в тот же день, а не через квартал после закупки». Отдельно готовьтесь к техническим вопросам. Компания с собственной инфраструктурой спросит про безопасность, про то, где физически лежат данные, про интеграцию с тем, что остаётся у них. Уклончивый ответ здесь стоит дороже, чем честное «этого мы не знаем, выясню к пятнице». ## Шаг 3. Подключить архитектора В корпоративной сделке продавец в одиночку не проходит дальше третьей встречи. Нужен человек, который отвечает за техническую сторону и которому поверят инженеры заказчика. Что даёт совместная работа. Во-первых, доверие: клиент видит, что решение прорабатывается, а не подбирается по прайсу. Во-вторых, ранние ограничения — архитектор находит проблему с сетевой связностью или требованием к размещению данных на этапе обсуждения, а не на внедрении. В-третьих, артефакт: схема на одну страницу, написанная языком заказчика, которую он сможет показать своему руководству без вас. Здесь же обсуждаются неудобные вещи. Если у клиента есть требование хранить определённые данные внутри страны, об этом нужно говорить сразу и честно, показывая гибридные варианты. Попытка обойти вопрос молчанием заканчивается тем, что его поднимает служба безопасности за неделю до подписания. ## Шаг 4. Пилот с критериями, а не демонстрация Самая убедительная презентация проигрывает собственному опыту клиента. Но пилот работает, только если у него есть измеримые условия успеха, согласованные до начала. Как выбрать пилот. Берите одну задачу из числа приоритетных, ограничьте срок несколькими неделями и договоритесь, что считается успехом. Не «попробуем облако», а «переносим это приложение, оно выдерживает двукратную нагрузку, время отклика не хуже текущего, восстановление после имитации отказа занимает меньше получаса». Что даёт пилот помимо результата: клиент лично трогает облако и перестаёт его бояться; обе стороны находят проблемы заранее; появляются цифры, которые заказчик понесёт своему руководству. Последнее важнее всего — вы не убеждаете лицо, принимающее решение, вы вооружаете того, кто будет убеждать его вместо вас. **Ловушка бесконечного пилота.** Самый частый способ потерять корпоративную сделку — застрять в пилотах. Всё прошло успешно, все довольны, решение о полноценном переходе откладывается квартал за кварталом: меняется руководство, приоритеты, бюджеты. Лекарство одно и принимается заранее: до старта пилота письменно согласовать, что произойдёт при успехе — какой следующий этап, чей бюджет, к какой дате. Без этого пилот становится вечным. ## Шаг 5. Экономика: считаем владение, а не цену Техническая состоятельность доказана — остаётся вопрос денег. И здесь решает не сравнение цен, а сравнение стоимости владения. Начните с текущей картины и считайте всё: закупку и продление оборудования, электроэнергию и охлаждение, площадь, лицензии, поддержку, зарплаты тех, кто это обслуживает, стоимость простоев за прошлый год, вывод оборудования из эксплуатации. Скрытые статьи собственной инфраструктуры обычно оказываются больше очевидных, и заказчик сам этого не считал. Отдельная статья, которую почти никогда не учитывают, — дефицит квалифицированных людей. Найти и удержать инженера, который поддерживает сложную локальную инфраструктуру на должном уровне, в регионе сложно и дорого. Это реальный фактор, и он звучит убедительно, потому что каждый технический руководитель это уже пережил. Дальше покажите модель затрат в облаке честно: зарезервированные мощности для постоянной нагрузки, оплата по факту для переменной. Если в текущей схеме заказчик держит запас под пики, который простаивает одиннадцать месяцев в году, это и есть ваш главный аргумент. Хорошая практика — сравнительный расчёт на три-пять лет. Не забудьте показать строки, невыгодные для вас: расчёт, где всё складывается в вашу пользу, вызывает недоверие у любого финансового директора. И осторожно с типовыми процентами экономии. Заказанное AWS исследование даёт ориентир около трети экономии на инфраструктуре при переносе унаследованных приложений — но это средняя цифра по чужой выборке. В конкретном проекте она может быть другой, а иногда облако выходит дороже, и выигрыш лежит в скорости и гибкости, а не в прямой экономии. Об этом лучше сказать самому. ## Шаг 6. Сопровождение: сделка это начало Подписанный договор — не финал, а точка, где начинается настоящий риск. Проект, который не прижился, через год превращается в аргумент против вас на всём рынке. Что делать. Обеспечить переход в эксплуатацию: мониторинг, журналирование, резервное копирование, обученные люди на стороне клиента. Договориться о регулярном разборе результатов — раз в квартал, с цифрами по тем метрикам, которые вы зафиксировали на первом шаге. Искать следующую инициативу: первый успешный перенос открывает разговор о втором, и лучше начать его вы, чем конкурент. И отдельно — следить, чтобы счёт не рос сверх необходимого. Клиент, которому вы сами предложили оптимизацию и уменьшили его расход, становится источником рекомендаций. Клиент, обнаруживший неоправданный рост счёта самостоятельно, становится источником другого рода историй. ## Как это выглядит целиком | Шаг | Что снимаем | Признак, что можно идти дальше | | --- | --- | --- | | 1. Потребность | Непонимание, зачем это им | Инициатива названа словами клиента и с цифрой | | 2. Связка с сервисами | Ощущение сложности | Каждый сервис назван через последствие для бизнеса | | 3. Архитектор | Недоверие инженеров | Есть схема, которую заказчик покажет сам | | 4. Пилот | Страх неизвестности | Критерии выполнены, следующий этап согласован письменно | | 5. Экономика | Возражение по деньгам | Расчёт владения принят финансовой стороной | | 6. Сопровождение | Риск, что не приживётся | Прошёл первый квартальный разбор с цифрами | ## Про кейсы, на которые принято ссылаться Из публичных примеров промышленной трансформации хорошо работает история Volkswagen Group: концерн строит единую промышленную облачную платформу для своих производственных площадок — по данным официального кейса AWS, более ста двадцати заводов. Заявленные цели — рост производительности и сокращение операционных затрат заводов примерно на треть, а также экономия порядка миллиарда евро в цепочке поставок. Для разговора с промышленным заказчиком это сильный аргумент: если консервативнейшая отрасль доверила облаку критичную инфраструктуру, разговор о принципиальной невозможности закрыт. Важная оговорка о региональных кейсах. В обзорах и презентациях по Центральной Азии часто ссылаются на историю одного финтеха как на официальный кейс AWS с гибридной архитектурой, одобренной регулятором. При проверке в сентябре 2026 года найти этот кейс на сайте AWS не удалось — ссылка ведёт на общий раздел. Возможно, материал убрали, как это регулярно происходит со старыми кейсами. Практический вывод: перед тем как ссылаться на кейс в коммерческом предложении, откройте ссылку. Заказчик, который её откроет и не найдёт, сделает выводы не о кейсе, а о вас. ## Оговорка **О цифрах и датах.** Материал написан весной 2026 года, обновлён и сверен с официальными источниками в сентябре. Программы, цены и условия у облачных провайдеров меняются несколько раз в год — конкретные суммы и названия проверяйте по документации на момент вашей сделки. Утверждения о требованиях законодательства здесь даны как ориентир, а не как юридическая консультация: локализация данных регулируется по-разному в каждой стране региона, и формулировки требуют проверки юристом. ## Частые вопросы **С чего начать, если у клиента нет запроса на облако?** Не создавать запрос про облако. Искать существующую боль: дорогая закупка на горизонте, окончание поддержки, авария, требование регулятора. Облако появляется в разговоре как способ решения, а не как тема. **Что отвечать на вопрос о хранении данных внутри страны?** Честно и с вариантами. В большинстве стран региона требования касаются размещения основной базы персональных данных, а не запрещают облако как класс. Рабочая конструкция — гибридная: чувствительные данные локально, вычисления и аналитика в облаке. Конкретные формулировки согласуйте с юристом заказчика. **Как долго идёт такая сделка?** От полугода до двух лет в зависимости от размера и отрасли. Планировать быстрее — значит гарантированно разочароваться и себе, и руководству. **Обязательно ли делать пилот бесплатно?** Не обязательно, и часто вредно. Бесплатный пилот не получает внимания внутри компании заказчика. Символическая оплата резко повышает вовлечённость. **Что делать, если расчёт показал, что облако дороже?** Сказать об этом. Дальше разговор переходит на скорость, гибкость и снятие операционных рисков — и это честный разговор, который часто заканчивается сделкой. Попытка натянуть расчёт заканчивается разбирательством через год. Каждый шаг снимает одно конкретное возражение, и пропустить шаг нельзя — возражение вернётся позже и дороже. Самое опасное место — пятый шаг: там выигрывает не тот, у кого дешевле, а тот, кто честно посчитал владение целиком и показал невыгодные для себя строки. --- Источник: https://kzsaleshub.com/aws-cloud-sales-framework/