Пишем RFP правильно

Некогда работая в компании-интеграторе предоставляющей услуги по проектированию систем обеспечения информационной безопасности, весь упор при подготовке новых контрактов для потенциальных клиентов я делал на технико-коммерческое предложение (ТКП). Однако, порой что бы грамотно подготовить ТКП необходимо получить исходные данные - понять то что хочет клиент, и если у компании соответствующие компетенции позволяющие выполнить его запрос. Примером таких данных может послужить  Request for Proposal или в русскоязычном варианте запрос предложения.

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

Введение 

Request for Proposal (далее, RFP) или в русскоязычном варианте Запрос предложения представляет собой документированный запрос потенциального клиента, заинтересованного в приобретении каких-либо товаров или услуг. 

Классически RFP создаётся компанией собирающейся продвигать свои услуги для для потенциальных клиентов\подрядчиков в тендерных или аукционных процессах.

Есть и другое схожее определение, RFP - это заявка на оказание определенной услуги или создание проекта, которую создаёт заказчик для проведения конкурса. В ней отражают процесс достижения целей, которые хочет достичь заказчик, KPI, критерии к участникам тендера и ряд других важных показателей.

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

При составлении RFP к нему могут идти приложения, к примеру спецификация.

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

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

Все участники конкурса\тендера возвращают свои предложение в установленную дату и время. Потенциальным клиентом данные предложения используются, чтобы оценить пригодность подавшего как поставщика, продавца или партнера. По предложениям так же часто могут вестись обсуждения (часто разъясняются технические детали или отмечаются ошибки в предложении). В некоторых случаях, всех или только выбранных претендентов могут пригласить участвовать в последующих предложениях, или могут попросить представить своё лучшее техническое и финансовое предложение, обычно называемое Лучшим и Конечным Предложением (англ. Best and Final Offer BAFO).

Поэтапное написание RFP

И так, давайте приступим к написанию RFP. С чего же начать? Этот вопрос мучает наверное каждого кто хоть раз садился это делать. Ниже попытаемся сформулировтаь наиболее общий алгоритм действия при подготовке RFP.

1. Сформулируйте цель и задачи

На первом этапе необходимо буквально в   двух-трех предложениях описать желаемый результат. Далее дополнить написанное исходя из задач, требований, и ограничений налагаемых на проект.  Помним. что цель должна быть реально достижимой  и измеримой. Это классическая модель SMART, о которой мы уже как то писали ранее.

И конечно, же приступаем к задачам. Это те этапы, которые позволяют нам достигнуть цели за определенное количество шагов. Необходимо конкретно сформулировать задачи. Принято указывать задачи в виде списка, т.к. «Сделать…» , «Разработать…», «Протестировать…», 

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

2. Сформулировать требования и условия

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

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

А теперь об ограничениях. Рекомендовано выносить их в отдельный раздел. Очень полезно выделять ограничения отдельно от требований.  Например, использовать в проекте в качестве базы данных MS SQL Server или серверов на базе RISC -  это требование или ограничение? Нужно поразмыслить, так  если оно не заложено в архитектуру, то ограничение. В ном же случае - это требование. В ограничения попадает, например, и стоимость аппаратного обеспечения, на котором достигаются нужные параметры по производительности или надежности. 

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

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

В RFP прописываются и другие особенности и условия выполнения контракта, если таковые имеются.

3. Определите порядок взаимодействия между сторонами

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

Заключение

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

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

В заключение можно отметить, что правильно сформулированный  и выполненный запрос - половина успеха в получении правильного ответа! Так что, потратьте чуть больше времени на RFP, соберите в нем все что вам нужно для принятия решения и результат обязательно будет!