Когда один интегратор обходится дешевле реселлеров?

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

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

Скидка не отвечает на вопрос о цене сопровождения

Сравнивать коммерческие предложения только по итоговой сумме лицензий неправильно, потому что эта сумма не включает работу заказчика и потери на стыках. У одного реселлера может быть лучшая цена Microsoft, у второго Oracle, у третьего SAP. На закупочном комитете такая таблица выглядит убедительно. Через полгода выясняется, что финансовый отдел сверяет три формата счетов, ИТ-служба ведет три набора прав, а служба закупок трижды согласует почти одинаковые документы.

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

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

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

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

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

Полную стоимость надо считать отдельной моделью

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

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

Полезная форма расчета выглядит так:

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

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

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

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

Календарь продлений должен управлять решениями, а не напоминаниями

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

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

Машиночитаемый фрагмент реестра можно хранить рядом с системой заявок:

contract: SAP-prod-01
business_owner: finance
technical_owner: erp-team
renewal_date: 2027-03-31
decision_deadline: 2026-12-15
quantity_change_deadline: 2027-01-31
evidence_folder: contracts/SAP-prod-01
dependencies:
  - oracle-db-prod
  - microsoft-identity
status: usage-review

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

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

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

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

Лицензионная проверка начинается с доказательств прав

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

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

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

Oracle License Management Services называет LMS органом Oracle, который может подтверждать лицензионные требования для программ Oracle. Это не означает, что заказчику стоит ждать официальной проверки. Архитектурные изменения, виртуализация, перенос нагрузки и новые способы доступа надо оценивать до внедрения, фиксируя письменное обоснование и версию примененных условий.

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

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

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

Эскалация ломается на границе договоров

Сложный инцидент редко уважает структуру закупки. Пользователь не входит в систему SAP, журнал показывает ошибку базы Oracle, а идентификация зависит от службы Microsoft. Каждый компонент может работать в пределах своей документации, пока бизнес-процесс стоит.

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

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

1. Одна заявка заказчика получает общий идентификатор, приоритет и описание влияния.
2. Координатор собирает временную шкалу, версии, изменения и доказательства из всех контуров.
3. Поставщики не закрывают свои заявки, пока общий координатор не подтвердит обход или причину.
4. Спор о виновной стороне не останавливает диагностику и сохранение журналов.
5. После восстановления координатор выпускает единый разбор с действиями и владельцами.

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

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

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

Матрица ответственности должна пережить конфликт

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

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

Проверьте матрицу четырьмя неудобными ситуациями. Кто отвечает, если реселлер не предупредил об окне уменьшения? Кто исправляет заказ с неверной метрикой? Кто оплачивает срочную дозакупку, вызванную ошибочной рекомендацией? Кто представляет согласованную позицию, если два вендора трактуют совместную архитектуру по-разному? Если ответ зависит от «обсудим по факту», договор оставляет самый дорогой риск заказчику.

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

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

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

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

Отдельные реселлеры выгодны при зрелой внутренней функции

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

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

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

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

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

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

Переход нельзя начинать с переноса заказов

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

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

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

До переключения проверьте четыре результата:

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

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

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

Выбор закрепляют условия выхода и проверяемые показатели

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

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

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

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

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

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

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