Суть. Новый вендор в портфеле разбирается не по прайсу и не по презентации, а по шести слоям: какая идея лежит в основе продукта, как устроена архитектура, как вендор зарабатывает через партнёров, какие компетенции требуются, кому это подходит и где решение честно не работает. Слои изучаются в этом порядке — иначе продавец знает названия продуктов и не может объяснить, зачем они.
Шесть слоёв
| Слой | Главный вопрос | Где искать ответ |
|---|---|---|
| Логика | Какую проблему вендор решает принципиально иначе, чем остальные | История компании и первый продукт: он объясняет всё последующее |
| Архитектура | Что является ядром и как остальное к нему присоединяется | Схема эталонного решения, а не список продуктов |
| Партнёрская модель | На чём зарабатывает партнёр и что защищает его сделку | Условия программы: уровни, регистрация сделок, фонды |
| Компетенции | Какой минимум обязателен, чтобы вообще участвовать | Сертификации и требования уровней программы |
| Сегменты | У кого болит именно то, что вендор лечит лучше всех | Референсные отрасли и типовые сценарии |
| Границы | Где решение проигрывает и что честно сказать заказчику | Сравнения, отзывы инженеров, свой опыт внедрений |
Как этим пользоваться
Слой логики важнее остальных. Почти у каждого вендора есть одна исходная идея: «всё в одной платформе», «лучшее в своём классе», «управление из облака», «открытость и совместимость». Из неё выводятся и архитектура, и типичные возражения, и то, с кем вендор конкурирует. Продавец, который понял идею, отвечает на новый вопрос без подсказки; продавец, который выучил продукты, — нет.
Архитектуру учат через один сценарий. Не пытаться охватить весь портфель. Взять один типовой запрос — защита удалённых сотрудников, обновление сети филиалов, консолидация серверов — и пройти его целиком: что ставится, что настраивается, что лицензируется, кто внедряет и сколько это занимает.
Границы выясняют до первой сделки. Вопрос инженеру: «в каких случаях вы бы это не предлагали». Ответ на него стоит дороже любого маркетингового материала и снимает половину будущих проблем на внедрении.
План на неделю
- День 1: базовый курс вендора и его же обзорный документ по архитектуре
- День 2: один эталонный проект целиком, с составом спецификации
- День 3: условия партнёрской программы и правила регистрации сделок
- День 4: разговор с инженером, который внедрял, — про границы и типичные ошибки
- День 5: собрать свою таблицу сегментов и три вопроса для первой встречи
Где ломается
Учат прайс. Через месяц он меняется, а понимание не появляется.
Пропускают слой границ. Продавец обещает то, что решение не делает, и теряет доверие уже на пилоте.
Изучают вендора, не изучая сегмент. Знание продукта без понимания, кому он нужен, даёт хорошие демонстрации и пустую воронку.
Что отмечать по каждому вендору
| Поле | Зачем |
|---|---|
| Роль в портфеле | Основной, дополняющий, нишевый или защитный — от этого зависит объём вложений |
| Уровень авторизации | Что даёт текущий статус и что требуется для следующего |
| Экономика | Скидка, бонусы за результат, стоимость сертификации и стендов |
| Компетенции | Сколько людей сертифицировано, кто заменяет ключевого инженера |
| Пересечения | С какими другими вендорами конкурирует внутри вашего же портфеля |
| Зависимость | Доля выручки: выше трети — стратегический риск |
Как читать карту
- Найти дублирование: два вендора закрывают одну задачу, но ресурс делится пополам и ни одна компетенция не доходит до уровня, за который платят.
- Найти дыры: задача, о которой регулярно спрашивают клиенты, а закрывать нечем.
- Найти вендоров без движения: статус есть, сделок за год нет — авторизация стоит денег и внимания.
- Проверить концентрацию: если один вендор даёт больше трети выручки, нужен план на случай изменения его политики.
Правило пересмотра
Карта пересматривается раз в год и обязательно при трёх событиях: смена условий у вендора, уход ключевого сертифицированного инженера, появление у вендора собственного прямого канала на вашем рынке. Каждое из них меняет экономику быстрее, чем годовой цикл планирования.