Инициативы Nasscom по стандартизации облачных RFP для госзакупок

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

Четыре точки пересборки

Предложения Nasscom сгруппированы по четырем сквозным блокам.

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

Скоуп и зоны ответственности. В RFP на разработку ПО должны быть явно зафиксированы функциональные требования, интеграции, зависимости, сроки согласований и этапы внедрения. Механизм change control с обоснованным продлением сроков при задержках со стороны заказчика или третьих лиц закрепляет взаимную подотчетность. Для облака — единообразное распределение shared-responsibility model по слоям: обязанности CSP, MSP и заказчика прописываются согласно модели доставки и зоне контроля каждой стороны.

Платежи и приемка. Сроки приемки, механизм deemed acceptance там, где это уместно, milestone-based платежи и своевременное закрытие бесспорных инвойсов снижают кассовый разрыв у подрядчика. Облачная часть отдельно подчеркивает прозрачность empanelled rates и понятный порядок пересмотра цен. Отклонения по SLA предлагается корректировать пропорционально, сохраняя рабочий cash flow у вендора.

Ответственность и remedies. Штрафы привязываются к конкретному виду нарушения с разумными notice и cure periods. Требуется явное разграничение indemnities, penalties, service credits и audit deductions, чтобы исключить двойное взыскание за один и тот же убыток и сохранить эффективные средства защиты у заказчика.

Применимость за пределами госсектора

Перечисленные принципы — рабочая опора для любого RFI, по которому сравниваются облачные провайдеры и подрядчики на разработку.

• Эквивалентность сертификатов. Требование одной конкретной сертификации сужает шорт-лист и сдвигает торг в сторону крупных игроков. Признание эквивалентных стандартов зрелости открывает более широкий и конкурентный рынок.
• Shared responsibility по слоям. Без явного распределения обязанностей по патч-менеджменту ОС, шифрованию данных и сетевой изоляции любой инцидент превращается в спор о виноватом. Этот блок лучше выносить в отдельное приложение к контракту.
• Пропорциональные SLA-кредиты. Бинарная схема «доступность ниже порога — весь месяц бесплатно» закладывается вендором в цену. Пропорциональные корректировки по конкретным метрикам (latency, error rate, time-to-resolve) точнее отражают влияние на бизнес.
• Change control и компенсация сроков. Заказчик, меняющий требования в середине релиза без компенсации по срокам, платит за это либо деньгами, либо качеством. Фиксация этой связки снимает половину будущих споров.
• Liability cap без двойного взыскания. Подрядчик закладывает риск в стоимость, если indemnities, penalties и service credits разнесены по документу лишь формально. Четкие лимиты и запрет на повторное взыскание за один инцидент удерживают цену в рыночном коридоре.

Что отслеживать

Конкретных дат принятия или публичных сроков в материале нет — это позиция ассоциации, а не решение регулятора. Дальше имеет смысл смотреть на публикацию финальных RFP от NeGD и на то, какие из четырех блоков перейдут в шаблоны в неизменном виде. Для команд, которые прямо сейчас готовят облачные контракты на 2026–2027 год, перечисленные принципы — готовый набор критериев для собственного RFI.