Закупки и вендоры
Зачем эта функция в ОМВИ
Решение build / reuse / buy почти всегда содержит «buy»: внешний LLM, облачная платформа, вендорский ИИ-сервис. Закупки и вендор-менеджмент превращают этот выбор в управляемый договор, а не в стихийную подписку с корпоративной карты. Особенно это важно для экономики затрат: стоимость инференса и токенов растёт незаметно, и без контроля закупок ИИ-портфель быстро становится дорогим и непрозрачным.
Функция работает в связке с архитектурой (что покупаем и почему именно это), ИБ и юристами (на каких условиях по данным и правам) и финансами (сколько это стоит и как контролировать).
Где подключается
| Этап ОМВИ | Роль закупок и вендор-менеджмента |
|---|---|
| Выбор продукта (build/buy) | Квалифицирует поставщиков, собирает условия и цены |
| Перед пилотом | Оформляет договор/подписку с учётом требований ИБ и юристов |
| Деливери / прод | Фиксирует SLA, поддержку, модель ценообразования |
| На поддержке | Контролирует расходы, пересматривает контракты, управляет зависимостью |
Что функция получает на вход
- Требования к решению и архитектурный выбор (что именно покупаем).
- Заключения ИБ и юристов по обработке данных и правам.
- Прогноз потребления (объём запросов, токенов, пользователей) для оценки стоимости.
Что функция отдаёт на выход
- Договор с условиями по данным, правам, SLA и поддержке.
- Согласованную модель ценообразования и потолок расходов.
- План управления зависимостью: стратегия выхода, снижение vendor lock-in.
Ключевые артефакты стыка
- Карточка вендора — условия, риски, SLA, права на данные.
- Модель стоимости решения — прогноз затрат на инференс/лицензии и потолки.
- План снижения lock-in — альтернативы и стратегия выхода.
Антипаттерны
- Теневые подписки. Команды покупают ИИ-сервисы мимо закупок — нет контроля прав, данных и расходов.
- Затраты без потолка. Потребление токенов/инференса растёт без лимитов и алертов.
- Жёсткий lock-in. Архитектура завязана на одного вендора без стратегии выхода.