Как сравнить коммерческие предложения на GPU-сервер без скрытых различий

Представьте, что на один проект пришли три коммерческих предложения:

Offer A — 15,8 млн ₽
Offer B — 16,4 млн ₽
Offer C — 17,1 млн ₽

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

Но в первом предложении могут отсутствовать optics и монтаж, во втором — использоваться другая установленная конфигурация RAM, а в третьем — быть включены доставка, commissioning и расширенная поддержка.

Пока эти различия не раскрыты, итоговые суммы описывают разный объём поставки.

Поэтому рабочая последовательность выглядит так:

Same Requirement → Quote Revision → Installed BOM → Accessories & Software → Services → Warranty / Support / RMA → Delivery & Commercial Terms → Close Critical UNKNOWN → Comparable Procurement Scope → Compare Price.

Главный принцип:

Сначала убедитесь, что поставщики отвечали на одну версию требований

До разбора цены зафиксируйте baseline specification.

Не просто:

«ТЗ на GPU-сервер».

А конкретно:

Requirement ID / Revision / Date.

Например:

GPU-TZ-04 / rev.3 / 18.09.2026

В baseline могут входить:

Если Offer A подготовлен по rev.2, а Offer B уже учитывает rev.3, headline totals нельзя считать прямым сравнением.

Главная формула:

Фиксируйте не только номер КП, но и его revision

Одно коммерческое предложение может пройти несколько уточнений.

Например:

• Quote 125 rev.1;

• Quote 125 rev.2;

• Quote 125 rev.3.

Если цена взята из rev.3, а спецификация — из rev.1, сравнительная таблица уже содержит ошибку.

Поэтому начинайте с Quote Identity Block.

Если применяются Incoterms, дополнительно фиксируйте:

rule + version + named place, а при необходимости — согласованную точку внутри named place.

Условия Incoterms определяют момент delivery и переход риска по-разному. Например, для DPU delivery происходит после разгрузки в согласованном месте назначения. Поэтому нельзя вводить один универсальный момент «поставки» для всех сделок.

Не начинайте сравнение с итоговой суммы

Первая ошибка — открыть строку:

«Итого»

и выбрать минимальное значение.

Временно уберите цену из таблицы и сначала сравните:

• что фактически входит в hardware;

• какие accessories включены;

• какое software entitlement предоставляется;

• какие работы выполняются;

• какая модель warranty/support/RMA действует;

• где заканчивается логистическая ответственность;

• какие пункты пока неизвестны.

Только после этого возвращайтесь к цене.

Сравнивайте quoted configuration, а не возможности платформы

Vendor documentation часто показывает широкий диапазон поддерживаемых configuration.

Например, документация Dell PowerEdge XE9680 отдельно задаёт поддерживаемые объёмы RAM и ограничения в зависимости от GPU. Это характеристика возможностей платформы, а не подтверждение того, сколько памяти установлено в конкретном заказе.

Поэтому нельзя переносить:

supports up to 4 TB RAM

в сравнительную таблицу как:

installed RAM = 4 TB.

Главная граница:

Platform Capability ≠ Quoted Installed Configuration.

И ещё одна:

Technical manual подтверждает, что configuration допустима.

Quote/BOM подтверждает, что именно её предлагают поставить.

Exact SKU важнее маркетингового названия

Строка:

GPU Server 8×H200

может быть недостаточно точной.

Проверяйте:

• OEM/platform;

• exact system SKU;

• revision;

• exact GPU SKU;

• GPU execution;

• GPU count;

• installed memory;

• CPU;

• storage;

• network.

Практика Start Server для технического сравнения уже использует exact BOM и отдельно разводит installed configuration и supported maximum.

Поэтому:

Same Marketing Name ≠ Same SKU.

Hardware Alignment Table

Приведите предложения к одинаковым строкам.

Цель таблицы — не посчитать общий score, а обнаружить различия.

Четыре рабочих статуса

Удобно использовать внутреннюю классификацию Start Server. Это рабочий инструмент статьи, а не отраслевой стандарт.

MATCH

Предложение выполняет requirement, и сравниваемая строка понятна.

DIFFERENCE

Данные двух предложений различаются, но оба варианта раскрыты.

Например:

• другой объём SSD;

• другой NIC;

• другая warranty model.

Разница сама по себе не означает проблему.

UNKNOWN

Информации недостаточно.

Например:

optics — не указаны.

BLOCK / REQUIREMENT NOT MET

Предложение в текущем виде явно не выполняет обязательное требование.

Например:

обязательны 8 GPU, а quoted configuration содержит 4 без согласованной альтернативы.

Главные правила:

DIFFERENCE ≠ BLOCK.

Пустая строка означает UNKNOWN

Если в КП ничего не сказано про rails, нельзя автоматически считать:

rails входят.

Правильный статус:

Rails: UNKNOWN.

Но и обратный вывод:

rails отсутствуют

из пустого поля тоже не следует.

Поэтому:

Blank Field ≠ Included.

Blank Field ≠ Not Included.

Лучший следующий шаг:

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

• письменное подтверждение;

• обновлённую спецификацию;

• revised BOM/quote.

Закрывать нужно прежде всего Critical UNKNOWN

Не любой неизвестный пункт одинаково важен.

Например, отсутствие декоративного описания упаковки и отсутствие exact GPU SKU — разные уровни риска.

Критическим становится UNKNOWN, способный изменить:

• выполнение обязательного requirement;

• итоговый scope;

• цену;

• срок;

• гарантийную или сервисную ответственность;

• возможность приёмки.

До закрытия таких UNKNOWN делать окончательный price comparison рано.

Accessories могут менять реальную стоимость проекта

Для установки GPU-сервера могут понадобиться:

• rails;

• power cords;

• PDU cables;

• optics;

• DAC/AOC;

• transceivers;

• mounting hardware.

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

Но если он требуется по вашему ТЗ, он должен появиться в Comparison Sheet.

Пример:

Offer A

Server — 15 млн ₽
Rails — included
Optics — included

Offer B

Server — 14,6 млн ₽
Rails — UNKNOWN
Optics — not included

Пока UNKNOWN не закрыт, нельзя заключить:

Сетевую комплектность лучше раскрывать отдельно

Строка:

2×400GbE

может не показывать полного scope.

Для procurement comparison полезно определить:

• exact NIC;

• количество ports;

• optics;

• DAC/AOC;

• cables;

• что находится на другой стороне соединения;

• какие позиции входят в quote.

SS-044 не проектирует сеть.

Она отвечает только на вопрос:

Software installed и software entitlement — разные вещи

Наличие ПО на установленной системе ещё не доказывает, что в поставку входят:

• лицензия;

• subscription;

• updates;

• vendor support;

• нужный срок entitlement.

Enterprise support у NVIDIA, например, связан с конкретными active support contracts и support levels; перечень services может включать hardware/software support, portal access, RMA и дополнительные onsite capabilities.

Поэтому:

Software Installed ≠ License / Support Entitlement.

В таблице полезно разделить:

После hardware выровняйте included services

Два одинаково сконфигурированных сервера могут иметь разный procurement scope.

Для services удобно использовать:

«Тестирование включено» недостаточно

Само слово:

testing

не раскрывает scope.

Полезно спросить:

• что именно тестируется;

• каким workload;

• какие criteria;

• передаётся ли report/log.

При этом данная статья не должна требовать универсально:

• конкретную длительность burn-in;

• конкретный benchmark;

• один набор acceptance tests.

В этой статье достаточно поля:

Validation и Acceptance в этой статье — рабочие термины

Для ясности используем:

Supplier Validation — предварительная проверка системы до передачи заказчику.

Acceptance — согласованная процедура подтверждения поставки заказчиком.

В реальном договоре эти термины могут называться иначе или иметь другое юридическое значение.

Поэтому в procurement documents всегда используйте фактические определения сторон.

Warranty, Support и RMA нужно разделять

Строка:

Warranty: 3 years

недостаточна для понимания эксплуатационной модели.

Даже у одного производителя warranty period и coverage зависят от product line и региона, а support services могут иметь отдельные уровни и опции. NVIDIA, например, отдельно описывает enterprise support, Advanced RMA, onsite engineer и business-critical support.

Нормализуйте:

Одинаковые «3 года» не означают одинаковый service scope

Один вариант может означать:

• parts warranty;

другой:

• hardware + software enterprise support;

третий:

• onsite capability;

четвёртый:

• гарантию интегратора с собственной escalation model.

Поэтому:

Same Warranty Duration ≠ Same Warranty Terms.

Не нужно заранее предполагать, что:

• warranty всегда включает определённые services;

• support всегда покупается отдельно;

• first line всегда поставщик или OEM.

Проверяется exact product/support SKU и конкретное КП.

First-line support owner фиксируйте явно

Практический вопрос:

кому заказчик обращается первым при incident?

В зависимости от сделки это может быть:

• reseller;

• интегратор;

• OEM;

• отдельный service partner.

Например, NVIDIA по большинству warranty claims рекомендует первоначально обращаться к локальному distributor/reseller.

Поэтому в Quote Alignment Matrix полезны отдельные строки:

Warranty Provider

First-Line Support Owner

Escalation Path

RMA Owner

Advanced RMA, onsite и standard warranty — разные capabilities

Не выводите:

есть 3-летняя гарантия → есть advance replacement.

Или:

есть support → есть onsite engineer.

NVIDIA отдельно перечисляет Advanced RMA, onsite engineer, onsite spares и Business-Critical Support как конкретные enterprise-support capabilities и опции.

Delivery нужно сравнивать по milestones конкретной сделки

Слишком грубая схема:

Ship Date ≠ Delivery Date

может оказаться юридически неточной, потому что момент contractual delivery зависит от согласованных trade/delivery terms.

Правильнее разделить возможные этапы:

Availability

↓

Reservation

↓

Ready to Ship

↓

Shipment

↓

Contractual Delivery Point

↓

Arrival / Unloading — если это отдельный milestone

↓

Installation / Commissioning

↓

Ready for Acceptance

↓

Acceptance

Какие именно milestones существуют, определяется вашим КП, договором и project schedule.

Если используются Incoterms, фиксируйте rule и named place

Запись:

DAP

сама по себе недостаточно полна.

Полезно фиксировать:

DAP [named place], Incoterms 2020

или другое реально согласованное правило.

Разные Incoterms rules по-разному определяют delivery, risk и обязанности по unloading. Например, DPU предусматривает delivery после unloading в named place.

Статья не должна становиться юридическим руководством по Incoterms.

Её правило проще:

Ready-for-Acceptance — это проектный milestone

В рамках статьи под ним удобно понимать состояние, когда:

• оборудование прибыло;

• необходимые installation/commissioning работы выполнены;

• система готова к согласованной процедуре acceptance.

Но такой milestone не появляется автоматически в любой сделке.

Если он важен проекту, его нужно явно определить в:

• ТЗ;

• КП;

• договоре;

• project schedule.

«В наличии» не равно подтверждённому сроку проекта

Фраза:

в наличии

может использоваться по-разному.

Вместо самостоятельной интерпретации попросите подтвердить:

• exact PN;

• количество;

• location;

• reservation status;

• ready-to-ship date.

Поэтому:

У доставки должна быть понятная граница

«Доставка включена» может означать разные scopes:

• до терминала;

• до объекта;

• до ЦОД;

• с unloading;

• с переносом в server room;

• с rack installation.

Для сравнения важно не название услуги, а конечная граница ответственности.

Налоговую базу нужно привести к одинаковому виду

Не сравнивайте напрямую:

цену с налогами

и:

цену без налогов.

Проверьте условия конкретной сделки:

• tax treatment;

• обязательные charges;

• включённую delivery;

• что именно находится в total.

Не нужно хардкодить в evergreen-статью конкретную налоговую ставку.

Точное налоговое treatment берётся из датированного КП/договора и при необходимости проверяется финансовой или юридической функцией заказчика.

Главная формула:

Валюта и validity тоже являются условиями предложения

Фиксируйте:

• quoted currency;

• механизм пересчёта, если указан;

• validity period;

• условие изменения цены.

Не прогнозируйте курс самостоятельно.

Сравнивайте реальные conditions датированных quotes.

Payment Terms — отдельное измерение, а не автоматическая надбавка к цене

Например:

• 100% advance;

• 30/70;

• payment after delivery.

Это разные commercial conditions.

Но без отдельной финансовой модели нельзя корректно сказать:

Offer A нужно увеличить на X ₽ из-за предоплаты.

Поэтому:

Payment Terms = Comparison Dimension.

Но не автоматически:

Payment Terms = Price Adjustment.

Проверьте допустимость substitutions

Одно КП может фиксировать:

exact PN.

Другое:

допускается equivalent replacement.

Нужно знать:

• какие строки можно заменить;

• кто согласует;

• какие equivalence criteria используются;

• требуется ли revised BOM;

• нужна ли повторная validation.

Quoted BOM и Delivered BOM нужно связать процедурой

Даже если quote содержит точную configuration, закупочный пакет должен отвечать:

• разрешены ли substitutions;

• кто их approves;

• какой документ фиксирует final configuration;

• когда предоставляется as-built BOM.

Поэтому:

Quote Alignment Matrix

Главный practical asset статьи.

Quote Gap Register

UNKNOWN лучше вынести в отдельный список.

В результате вместо общего:

«уточните коммерческое предложение»

поставщик получает конкретный список gaps.

Не ранжируйте предложения, пока открыты Critical UNKNOWN

Представим:

Offer A

15,5 млн ₽
12 критических строк UNKNOWN.

Offer B

16 млн ₽
обязательный scope полностью раскрыт.

Правильный промежуточный вывод:

Scope Offer A ещё недостаточно определён для финального price comparison.

Не:

Offer A выгоднее.

Не подставляйте собственную рыночную цену вместо ответа поставщика

Если installation не указан, не нужно самостоятельно добавлять:

«обычно монтаж стоит 150 тыс. ₽».

Это уже analyst assumption, а не данные supplier quote.

Основной workflow:

UNKNOWN → Written Clarification.

Если отдельный scenario estimate всё же нужен, помечайте его явно:

Analyst Estimate / Assumption

и не смешивайте с quoted price.

Required Base и Optional Add-ons разделяйте

Дополнительные позиции могут включать:

• extended support;

• spare GPU;

• onsite services;

• дополнительные diagnostics;

• training.

Они могут быть полезны, но не должны автоматически увеличивать сравниваемую baseline price.

Разделите:

REQUIRED BASE

и

OPTIONAL ADD-ONS.

Только после нормализации считайте Comparable Procurement Cost

Условная структура:

Required Hardware

Required Accessories

Required Software / Entitlements

Required Services

Delivery / Installation

Applicable Charges Explicitly Identified for the Transaction

=

Comparable Procurement Scope / Cost.

Это не TCO.

Главная граница:

Comparable Procurement Cost ≠ TCO.

TCO дополнительно может учитывать electricity, персонал, ЦОД, downtime, дальнейший support, upgrade и другие lifecycle costs.

Учебный пример

Используем только условные значения.

Requirement

• один GPU-сервер;

• mandatory delivery;

• rack installation;

• минимум один год warranty.

Offer A

Hardware — 10 условных единиц
Delivery — included
Rack installation — included
Warranty — 1 year

Offer B

Hardware — 9,5
Delivery — +0,3
Rack installation — UNKNOWN
Warranty — 3 years

Можно ли заключить:

Offer B дешевле на 0,2?

Нет.

У него неизвестна обязательная строка installation.

Промежуточный результат:

Offer A — mandatory scope known.

После письменного clarification уже можно сравнить totals.

Нормализация не означает, что дешёвое предложение обязательно хуже

После проверки вполне может оказаться:

• BOM одинаков;

• required services одинаковы;

• warranty scope сопоставим;

• delivery terms сопоставимы;

• critical UNKNOWN закрыты;

и Offer A действительно стоит меньше.

Это нормальный результат.

Задача процедуры — не доказать скрытый риск у дешёвого предложения.

Задача:

сравнить одинаковые обязательства.

Более высокая цена тоже ничего не доказывает сама по себе

Обратная ошибка:

Offer B дороже, значит предложение качественнее.

Цена сама по себе не подтверждает:

• более полную комплектацию;

• более высокий support level;

• более быстрый срок;

• лучшее testing;

• более подходящую архитектуру.

Эти поля проверяются отдельно.

Готовый Request for Clarification

После заполнения Quote Gap Register можно отправить поставщику один структурированный запрос:

Просим подтвердить или уточнить условия КП №___, revision ___ от ___.

Необходимо уточнить:

1. exact PN и количество GPU;

2. установленный объём и population RAM;

3. состав storage;

4. exact NIC и включённые optics/cables;

5. rails и силовые кабели;

6. software licenses и срок support entitlement;

7. scope предварительного testing и предоставляемый evidence;

8. delivery boundary и применимый milestone;

9. installation/commissioning scope;

10. warranty provider, first-line support и RMA owner;

11. tax basis, currency и validity;

12. допустимые substitutions.

Финальный Quote Comparison Gate

До сравнения цены пройдите проверки.

REQUIREMENT

Все поставщики отвечают на одну requirement revision?

QUOTE

Используются актуальные revisions всех КП?

HARDWARE

Installed BOM сопоставлена по exact SKU и количеству?

ACCESSORIES

Обязательные cables, rails, optics и другие required accessories учтены?

SOFTWARE

Licenses и support entitlements раскрыты?

SERVICES

Integration, validation, installation и commissioning scope понятны?

WARRANTY

Warranty, support и RMA разложены на отдельные поля?

DELIVERY

Delivery boundary и milestones определены условиями конкретной сделки?

COMMERCIAL

Currency, tax basis, payment и validity известны?

SUBSTITUTIONS

Понятно, какие изменения допускаются и как согласуются?

UNKNOWN

Все critical UNKNOWN закрыты письменно?

Если да:

COMPARE PRICE.

Если нет:

Что передать Start Server для полного предложения

Для нового КП лучше передать не только:

«нужен сервер с 8 GPU».

Полезнее приложить:

Requirement

• exact workload;

• required GPU/count;

• RAM;

• storage;

• network;

• topology constraints.

Software

• OS;

• runtime;

• licenses;

• support requirements.

Services

• delivery;

• rack installation;

• setup;

• validation;

• acceptance support.

Commercial

• destination;

• required project date;

• warranty/support requirements;

• procurement constraints.

Главное

Коммерческое предложение на GPU-сервер нельзя корректно сравнивать только по строке «Итого».

Рабочая последовательность:

Requirement Revision

→ Quote Revision

→ Installed Hardware

→ Accessories

→ Software Entitlements

→ Included Services

→ Warranty / Support / RMA

→ Delivery Terms & Milestones

→ Commercial Conditions

→ Substitutions

→ MATCH / DIFFERENCE / UNKNOWN / REQUIREMENT NOT MET

→ Close Critical UNKNOWN

→ Comparable Procurement Scope

→ Compare Price.

Ключевые правила:

Different Requirement Baseline ≠ Comparable Quotes.

Same Marketing Name ≠ Same SKU.

Platform Capability ≠ Quoted Installed Configuration.

Supported Option ≠ Quoted Option.

Blank Field ≠ Included.

Blank Field ≠ Not Included.

DIFFERENCE ≠ BLOCK.

UNKNOWN ≠ PASS.

Software Installed ≠ License / Support Entitlement.

Same Warranty Duration ≠ Same Warranty Terms.

Availability Label ≠ Confirmed Project Delivery Milestone.

Price Including Tax ≠ Price Excluding Tax.

Quoted BOM ≠ Automatically Delivered BOM.

Commercial Performance Claim ≠ Verified Benchmark Evidence.

Comparable Procurement Cost ≠ TCO.

Главный procurement question не:

«Какое КП имеет самую низкую сумму?»

А:

«Какова цена одинакового обязательного scope при одинаково понятных условиях?»

Только после ответа на этот вопрос totals действительно становятся сопоставимыми.

Если в коммерческих предложениях различается technical architecture, qualification или responsibility, это нужно отдельно проверить по SS-017. Performance claims нормализуются по SS-043. А согласованный BOM, services и acceptance scope затем становятся входными данными для SS-045 — фактической приёмки поставленного сервера.

CTA: Получить предложение с полной спецификацией.