Запрос предложения агентству (Agency RFP Template)

• Дать один и тот же brief всем участникам.
• Запросить named team, а не только agency credentials.
• Разделить mandatory requirements и preferences.
• Заранее опубликовать evaluation criteria.
• Не просить бесплатно разработать полноценную стратегию как условие участия.

RFP не заменяет SOW. Победивший подход нужно перевести в конкретный scope, deliverables, SLA, roles и acceptance criteria.

Используйте шаблон для повторяемых процессов, значимых бюджетов, vendor relationships и решений, где важны ответственность и воспроизводимость. Для редкой низкорисковой задачи не нужно создавать тяжёлую бюрократию. Формализация оправдана, когда она уменьшает число ошибок, ускоряет handoffs или снижает зависимость от знания одного человека.

• Определите scope документа: какой процесс, команда, поставщик или тип решения он регулирует и где его границы.
• Назначьте одного accountable owner, даже если исполнителей и согласующих несколько. Без owner документ почти всегда устаревает.
• Зафиксируйте минимальные правила исполнения: входы, выходы, сроки, критерии качества, исключения и escalation.
• Версионируйте изменения и указывайте дату следующего review. Для критичных процессов храните историю, а не перезаписывайте контекст.
• Проверяйте документ на практике: если команда обходит его в реальной работе, нужно улучшать процесс или шаблон, а не требовать формального заполнения.

Три агентства получают один и тот же RFP с одинаковым pricing format и scoring criteria. Это позволяет сравнивать подход, команду и economics, а не презентационное мастерство.

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

• Scope и границы документа понятны.
• Есть accountable owner.
• Описаны сроки, критерии качества и исключения.
• Есть version и дата review.
• Документ реально используется в процессе, а не хранится формально.

Установите регулярный review и внеплановый пересмотр после инцидента, major launch, смены поставщика, реорганизации или изменения системы. Архивируйте старые версии, если документ влияет на контроль и ответственность.

Как понять, что документ слишком сложный?

Если команда создаёт параллельные таблицы и обходные процессы, это сигнал сократить поля или изменить workflow.

Кто утверждает изменения?

Accountable owner процесса. Для критичных документов могут потребоваться Finance, Legal, Security или руководитель функции.

Нужно ли хранить историю версий?

Да, если документ влияет на деньги, риски, договорённости или ответственность. Для лёгких рабочих чек-листов достаточно краткого change log.

• Agency SOW
• Vendor Scorecard
• Budget Model

• Agency Selection
• Agency Commercial Models
• Vendor Risk Management