Как составить rfp

Данная статья предназначена вам, дорогие заказчики, будущие и настоящие, наши и не наши. Говорят, что правильно заданный вопрос — половина ответа. Правильно написаное задание заказчиком — залог хорошего и точного предложения от нас, разработчиков, а в итоге — хорошо сделанного проекта, в срок, в рамках бюджета и с высоким качеством. Такую первичную постановку задачи, предназначенную для отправки разработчику, называют запросом на предложение, или RFP (request for proposal).

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

Итак, перед вами поставлена задача — найти достойного подрядчика на разработку ПО. Чтобы найти самого лучшего, вы решаете подготовить и разослать по списку достойных компаний запрос на предложение, провести тендер, и в итоге сделать выбор. Вы открыли чистый лист в ворде и… С чего начать?

С чего начать?

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

Внятно сформулировать цели. При написании целей следует помнить две вещи:

1. Цель любой деятельности лежит вне рамок этой деятельности. То есть, цель разработки сайта — не продавать товар, а увеличить сервис для клиентов предоставлением еще одного коммуникационного канала. Цель разработки B2B-системы не создать ПО для взаимодействия с покупателями через сеть, а снизить издержки и увеличить обороты за счет автоматизации.
2. Цель должна быть измеримой. Цель может быть достижимо-конечной («увеличить продажи в 2016 году вдвое»), а может быть просто направлением (увеличивать продажи каждый год минимум вдвое). Но всегда важно, чтобы она была измеримой. Например, цель «обеспечить высокую лояльность покупателей к нашему бренду» странная — непонятно, что значит «высокую», может, она и сейчас ничего. А цель «Поднять уровень лояльности к бренду вдвое» более измеримая, хотя для ее оценки нужно сделать пару опросов — до внедрения и после.

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

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

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

Хорошо, если этот список станет чеклистом по прогрессу проекта в итоге. Не должно быть задач, которые никак не бьются с целями. Например, задача «Разработать мобильное приложение» может иметь цель «Увеличить конверсию с мобильного канала с 0,5% до 1%».

Совсем хорошо, если задачи получится сделать иерархическими. Например, можно разделить задачу «Разработать мобильное приложение» на «Разработать дизайн приложения», «Разработать приложение».

Где-то в этот момент можно придумать название проекта. Задачи есть, цели есть — обычно это уже не составляет труда. Лучше, если оно будет максимально информативным, но при этом коротким.

Далее я предположу, что вы точно знаете, что хотите от разрабатываемой системы или услуг разработчика (здесь и далее под разработчиком понимаем компанию-разработчика ПО, а не отдельного программиста). Давайте рассмотрим основные темы, связанные с конкретной постановкой задачи. О чем стоит помнить, формулируя требования?

Важные моменты по основному содержанию RFP

Разделять работы и услуги. Работы направлены на получение уникального результата. Как правило, перед выполнением работ исполнитель получает задание, а после выполнения — отчитывается. Услуги — регулярная, непрерывная деятельность. Услуги могут состоять из набора работ, но результатом оказания услуг обычно является прогресс. Заказчик оценивает прогресс, и решает продолжать с компанией тему с услугами или искать нового подрядчика. Для работ результатом является продукт.

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

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

Есть довольно простое разделение «обязанностей»: Техническое задание для технических требований к продукту, Устав и план работ — для требований к процессу создания продукта. Любую «хотелку» заказчика можно легко отнести либо к одному, либо к другому.

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

Разделять функциональные и нефункциональные требования. Разница между ними простая: нефункциональные требования — это требования к характеристикам системы, а не к ее функциям.

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

Выносить в отдельный раздел ограничения. Очень полезно выделять ограничения отдельно от требований. Порой это не очень очевидно. Например, использовать в качестве базы данных Oracle — требование или ограничение? Ответ простой: если оно не имеет «родительского» бизнес-требования, то ограничение. Иначе — требование. Бизнес-требование должно иметь такую же связку с целью. Например, требования к производительности, хоть и являются нефункциональными, могут иметь бизнес-требования.

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

«Что делать» и «как делать»

Запрос на предложения должен, конечно, предельно точно говорить о том, что ожидается от потенциального разработчика в качестве результата.

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

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

• Разработчик читает ваши документы с постановкой задачи, т.е. получает ответ на вопрос «что делать». Пропустим пока то, что на этом этапе уже теряется много информации о реальных ожиданиях заказчика.
• Разработчик прикидывает архитектуру и реализацию, т.е. отвечает для себя на вопрос «как делать». Обращаю внимание, что обычно этот этап никак не формализуется..
• Разработчик оценивает работы («за сколько»), которые ведут к результату («что делать») через придуманную им архитектуру и реализацию («как делать»). На этом этапе рождается смета.
• Разработчик направляет смету и план.. Остаток документа на 90% состоит из копипаста и стандартных слов. В лучшем случае немного пишет про выбранный подход.

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

Вам в лучшем случае удается сравнить только оценки сроков и стоимости («за сколько»). Хотя можно и нужно экспертно сравнивать реализации («как делать»), так почти никто не поступает.

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

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

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

Картинки и схемы в коммерческих и технических предложениях по большей части скопирована с других предложений. Самые ценные схемы — нарисованные на флипчарте прямо у вас на встрече. Самые ценные аргументы — в ответ на неожиданные вопросы.

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

Как сравнивать разные предложения? Выходит, что по одним и тем же требованиям («что делать») разные подрядчики выходят с разными реализациями («как делать»), причем придуманными и оцененными «на скорую руку». Для того, чтобы можно было сравнивать предложения различных подрядчиков по формальным криетриям, вы просите делать оценку трудозатрат (и/или стоимости) отдельных требований. Это встречается почти в каждом тендере.

Оценка отдельных требований

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

Например, пакетом работ может быть верстка шаблонов, отдельным пакетом — набор задач на форму обратной связи, отдельным пакетом — тестирование. А может быть по-другому: пакет работ — это задачи по программированию формы обратной связи, ее оформлению, и по ее тестированию.

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

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

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

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

Например, требования могут дублировать друг друга, могут предполагать общие задачи, а могут подразумевать задачи, которые заказчиком не были выделены в отдельные требования, а не делать их нельзя — не будет требуемого результата. В итоге сумма трудозатрат по вашим требованиям хоть и будет составлять оценку проекта подрядчиком, но будет «натянута» и «подогнана».

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

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

Как выбрать лучшего?

Универсального ответа на этот вопрос нет, но есть самый близкий к идеалу.

Два проекта вместо одного

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

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

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

Итак, мы выделяем в этом случае два проекта, выполняемых последовательно:

Проект №1. Проектирование

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

1. цели, задачи, бизнес-требования
2. функциональные требования
3. нефункциональные требования
4. сценарии использования системы
5. ограничения.

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

На этапе «Разработка технического проекта» выполняется разработка комплекта документов, отвечающих на вопрос «как делать»:

1. конкретные работы,
2. разбиение на пакеты работ,
3. используемое ПО,
4. предполагаемая серверная инфраструктура
5. методика тестирования (нагрузочного, интеграционного)
6. подходы к миграции данных
7. … и многое другое, зависящее от конкретного проекта

Типичным документом на этом этапе является документ «Технический проект»

Здесь же разрабатывается план работ и смета от подрядчика, выполняющего проект.

Проект №2. Реализация

.
Оценить этот этап более-менее точно можно, имея результат с этапа №1. В процессе разработки подход «как делать» почти точно изменится, поэтому нужно сразу планировать по итогам получение документации по архитектуре системы, которая будет иметь в основе «Технический проект», но с исправлениями и изменениями.

Управление стоимостью

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

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

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

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

… он будет особенно мотивирован работать хорошо, ему будет важно создать хорошее впечатление и сделать свою работу «на отлично.»

Конечно, у вас есть право не объявлять второй тендер, а продолжить работать с первой компанией и дальше, если все идет хорошо.

Waterfall или Agile?

Этот вопрос поднимается почти у каждого заказчика. Проектный подход («Waterfall») представляет собой прогнозируемый подход к разработке, когда сначала создается технический проект, план работ, а потом по этим эскизам выполняется работа. Итеративный подход («Agile») представляет собой много очень коротких простых по структуре проектов, длительностью в 2-3 недели. В итеративном подходе предполагается очень плотное участие заказчика в процессе, он буквально должен жить с командой, а в случае срыва сроков делить с ней риски. Проектный подход предполагает большую автономность для подрядчика — здесь есть риск узнать, что подрядчик оказывается неспособен сделать систему слишком поздно.

В интернете очень много информации по сравнению этих двух подходов, эта тема очень холиварная. Поэтому я не буду повторяться, просто поделюсь коротким советом:

Выбирайте Agile, если:

• вы лично и несколько ваших коллег готовы отдать 80%-100% своего времени проекту с полным погружением
• у вас достаточная компетенция и вы готовы погружаться в разработку вместе с технарями,
• вы готовы разделить риски за срыв сроков или за невысокое качество работы подрядчика с вами лично,
• и вам, и подрядчику понятно, что на данный момент нормально требования не собрать, потому что они еще не выдуманы до конца, а работать начинать надо, потому что рынок, бизнес, и все такое

Выбирайте Waterfall, если:

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

Функциональные требования

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

Очевидное и непроверяемое можно не писать. Это сэкономит время и вам, и нам. Например, не надо писать в требованиях, что интернет-магазин должен быть удобным и современным, а страницы загружаться быстро и легко.
Сгруппируйте требования в разделы по темам. Разбейте группы на подгруппы. Постарайтесь сделать структуру логичной и понятной, чтобы ей было удобно пользоваться.
Полнота. Постарайтесь сохранять достаточную для первичного документа глубину проработки требований.
Атомарность. Одно требование — одна идея..
Однозначность. Избегайте повторов и противоречий. Все работающие с ним должны понимать его одинаково.
Без жаргонизмов. Постарайтесь использовать общепринятую понятную широкой аудитории лексику.
Краткость Постарайтесь обойтись минимумом слов. Убрать все лишнее и оставить только самое главное.
Проверяемость. Представьте, что перед вами уже готовая система и вам нужно проставить галочки напротив своих же пунктов. Сможете ли вы проверить их?

Все объекты и всех пользователей где-нибудь соберите в одном месте и дайте им определения. В примере выше объекты «товар» и «список избранного» должны быть описаны.

Услуги

Услуги — это регулярные работы, выполняемые по заявкам или по расписанию. Услуги про процесс, про регулярную доставку измеримых результатов, в то время как проект предполагает один результат — продукт.

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

Предложение на услуги должно идти отдельно от предложения на выполнение проектных работ.

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

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

Формат документов

Для разработчика очень удобно, когда функциональные требования передаются как минимум в формате электронной таблицы, а прочие — нефункциональные, ограничения, цели, задачи, описание оформляются в виде документа Word или PDF. Электронные таблицы позволяют добавлять к требованиям вопросы и комментарии, статусы и трудозатраты, фильтровать и группировать требования. Да и если будет нужда, из электронной таблицы в формат Word переносить требования значительно проще, чем из неструктурированного текста в Excel.

В идеале формат таблицы с требованиями должен включать следующие колонки:

• Автор. Изначально везде вписано «заказчик». Если разработчик посчитает, что какие-то неявные требования указаны, он добавляет новые строки с автором «разработчик»
• Раздел. Удобно для фильтрации
• Подраздел. Удобно для фильтрации
• Уникальный номер требования. Удобно для формул Excel, типа СЧЁТ или СУММЕСЛИМН
• Текст требования. В свободном виде. Без картинок. Один абзац.
• Пакет работ, куда входит требование. Заполняется разработчиком.

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

• Название пакета работ
• Оценка пакета работ в ч/ч. Разрабочик вправе разбить оценку на виды работ (см ниже). Например, отдельно выделив часы менеджера, аналитика, разработчика, тестировщика.
• Число требований, вошедших в пакет (для контроля, может быть 0). По желанию. Высчитывается автоматически через формулы Excel «СЧЁТ».

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

Что намеренно не вошло в данную статью и почему

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

• Трассируемость требований: в идеале функицональные и нефунккциональные должны восходить к бизнес-требованиям, те — к задачам, а задачи — к целям. Выстроить систему, при которой у вас все будет так красиво без надлежащего опыта за плечами — очень непросто. Но если есть желание и возмжоность — лучше сразу организовывать требования в иерархию.
• Способы визуализации бизнес-процессов и отношений между объектами: во многом схема красноречивее многих слов. Для описания бизнес-процессов и отношений между данными есть стандарты UML/Aris/IDEFx, BPMN, ERD, диаграммы последовтельностей и др.

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

Заключение

Итак, суммируя все выше,

• В RFP:
  • Формулируйте измеримые бизнес-цели, зачем делается эта разработка
  • Формулируйте измеримые задачи, которые нужно сделать для достижения цели
  • Выносите отдельно запрос на услуги (поддержка, хостинг, SEO)
  • Выносите отдельно запрос на работы (создание продукта, документа, обучение)
  • По требованиям:
    • Выделяйте отдельно требования к процессу разработки
    • Выделяйте отдельно требований к процессу управления проектом
    • Выделяйте отдельно функциональные и нефункциональные требования
    • Выделяйте отдельно ограничения

  • Продумайте, как вы будете сравнивать предложения

• Выбор подрядчика
  • По возможности разбейте на два запроса на предложения, (1) проектирование и (2) реализация
  • Исходите из предположения, что подрядчики на эти разные фазы могут быть разные (хоть это и не очень хорошо — но лучше это предполагать)
  • Организовывайте устные технические защиты (презентации) предложений
  • Требуйте в проектирование включить смету и план-график на случай, если будет выбран этот же подрядчик

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

Алиев Рауф,
директор по e-commerce TEAMIDEA (разработка на SAP hybris)

Бет Мюлерн (Beth Mulhern) из компании Verizon и Кендалл Моррис (Kendall Morris) из Create Digital опубликовали весной 2012 года презентацию, в которой описали, как создать RFP для проекта в социальных медиа, что на каждом из этапов должны делать бренды и агентства-подрядчики.

Написание RFP — процесс, который можно разделить на 7 этапов.

Этап 1. Определение целей и задач

Бренду следует определить основные маркетинговые задачи и бизнес-цели, которых он хочет добиться. Агентству — определить те проблемы, которые необходимо решить для достижения целей и «болевые точки» (сложности, которые могут возникнуть на пути реализации проекта). И тем, и другим следует выбрать те социальные сети, которые помогут им в реализации поставленных задач.

Этап 2. Определение необходимых требований и условий

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

Этап 3. Определение сроков

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

Этап 4. Определение взаимоотношений и связей

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

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

Этап 5. Определение бюджета

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

Этап 6. Оценка различных вариантов воплощения

Бренд должен определить ключевые показатели, по которым будет оцениваться эффективность, и собрать команду тех, кто станет этим заниматься. Агентству следует убедиться в адекватности критериев оценки (например, наличии необходимых метрик для изучения эффективности).

Источник: Slideshare: How to Write an RFP for Social Media

Как мы писали, не следует пренебрегать составлением качественного RFP (запроса предложения). Он может быть простым – с одной закупаемой позицией товара или оборудования, а может представлять собой сложное описание этапов работы и планируемого результата, но RFP – запрос предложений должен быть качественно составлен.

Почему?

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

Как вы составите RFP, так на него и ответят. Если запрос неконкретный, то и предложения будут общими. Описание закупок в виде объявлений в RFP не проходят. Так на запрос «купим светильники» вы получите объемные прайс-листы, которые можно было скачать с сайта производителя и без запроса. А если вы опишите характеристики закупаемых светильников с указанием марки, мощности, количества и назначения, то вы уже получите полноценное коммерческое предложение.

Почему документ получается объёмный?

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

Вам это действительно нужно! Скачайте!

Возьмите себе образец RFP, заполните его на бланке компании и разместите на электронной площадке.

Вам понравится работать с этим документом, и вы удивитесь, какой будет результат!

       1. Общий образец RFP.

       2. Образец RFP на поставку товара (по описанию или спецификации).

       3. Образец RFP на производство строительно-монтажных работ с техническим заданием.

       4. Образец RFP на выполнение проектных работ.

       5. Образец RFP на оказание услуг.

Если вы не нашли свой идеальный бланк для RFP, то напишите об этом на электронную почту direct@rfp.ltd, и обязательно вам ответим!

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

Что такое запрос предложений?

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

Как написать запрос предложений, который получит отклик

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

1. Определите свой проект и потребности.

2. Напишите введение.

3. Объясните историю вашей компании и проекта.

4. Опишите требования к проекту.

5. Объясните, как продавцы должны реагировать.

6. Изложите критерии отбора.

7. Обратите внимание на свои сроки.

8. Вычитайте и пересмотрите свое RFP.

После того как вы составили RFP, вы можете разослать его и ждать ответа.

1. Определите ваш проект и потребности

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

2. Напишите введение

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

3. Объясните историю вашей компании и проекта

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

4. Опишите требования к вашему проекту

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

5. Объясните, как продавцы должны реагировать

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

6. Изложите критерии отбора

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

7. Обратите внимание на сроки

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

8. Перечитайте и пересмотрите ваше RFP

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

Советы по написанию RFP, на которое будет получен ответ

Следуйте этим советам, чтобы разработать RFP, на который ответят несколько подходящих поставщиков:

Используйте подзаголовки и пулевые точки

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

Напишите о том, что вы знаете, если это возможно

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

Быть подробным, но не предписывающим

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

Пример RFP

Используйте этот пример RFP, чтобы написать свой собственный запрос на предложение, который получит ответы от качественных поставщиков:

Запрос предложений: Новый веб-сайт компании для Robin’s Antiques
10 августа 2019 г
Выдано Robin’s Antiques
Представитель Robin’s Antiques: Робин Джонстон
Robin_johnston@robinsantiques.com
(277) 398-9834

Введение

Robin’s Antiques, розничный магазин по продаже антиквариата, нуждается в новом веб-сайте компании и принимает предложения по поиску квалифицированного источника для создания этого веб-сайта для нас. Наши цели для нашего нового веб-сайта следующие:

— *Увеличение наших онлайн-продаж*
— *Привлекать и расширять нашу клиентскую базу*
— *Повысить осведомленность о нашем магазине*
— *Представить более профессиональный, современный образ*

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

Фон

Наш антикварный бизнес был основан в 1989 году. С тех пор у нас появилась постоянная клиентская база на севере штата Нью-Йорк. Большинство наших клиентов в возрасте от 50 лет совершают покупки в магазине. Однако, поскольку все больше людей совершают покупки через Интернет, мы считаем, что есть прекрасная возможность расширить и увеличить нашу клиентскую базу за пределами нашего местного региона. Мы разработали наш первый веб-сайт в 2005 году, используя бесплатный онлайн шаблон. Она практически не изменилась и по сей день и сейчас выглядит очень устаревшей и нерафинированной. Он также не совместим с мобильными устройствами, как мы хотели бы видеть наш новый сайт.

Описание проекта

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

— *Страница, показывающая историю нашего магазина*
— *Контактная страница с номером телефона и адресом электронной почты, а также контактная форма в режиме онлайн*
— *Магазин электронной коммерции, принимающий основные кредитные карты и PayPal, который мы можем обновлять с помощью системы управления контентом, чтобы отразить наш текущий инвентарь*
— *Блог, который мы сможем обновлять с помощью системы управления контентом, чтобы держать наших клиентов в курсе новостей о нашем бизнесе и антиквариате*
— *Ссылки на наши профили в Facebook и Instagram*

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

— *Стратегия содержания и копирайтинг*
— *Визуальный дизайн*
— *Поисковая оптимизация*
— *Оптимизация мобильных устройств*
— *Фронт-энд и бэк-энд кодирование*
— *Доступность для пользователей с ограниченным зрением
— * Тестирование и обеспечение качества*
— * Обучение, которое поможет нам ознакомиться с системой управления контентом и процессом обновления сайта*

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

Рекомендации по предложению

Ваше предложение должно соответствовать приведенному ниже формату:

— Краткое резюме
— Справочная информация о вашем бизнесе
— Указать, почему мы должны выбрать именно вас, а не других поставщиков
— Отметьте релевантный опыт, который поможет вам выполнить наш проект
— Предлагаемые услуги или результаты
— Предоставьте карту сайта с указанием всех страниц сайта и их связей
— Укажите программное обеспечение и языки программирования, которые вы собираетесь использовать, и почему вы считаете их хорошим выбором
— Ценообразование
— Укажите фиксированную цену проекта с детализированной калькуляцией затрат. Также укажите количество часов, которое, по вашим ожиданиям, займет проект.
— Ссылки
— Укажите имя, контактные данные и URL-адреса веб-сайтов трех предыдущих клиентов.
— Любые условия работы с вами

Пожалуйста, отправьте ваше предложение в .в формате pdf по адресу Robin_johnston@robinsantiques.com до 25 августа 2019 г.

Критерии отбора

Robin’s Antiques будет оценивать предложения на основе следующих критериев:

— Соответствие требованиям, изложенным в данном запросе предложений
— Соответствующий прошлый опыт и результаты работы
— Образцы вашей работы
— Отзывы прошлых клиентов
— Указанная стоимость проекта

Robin’s Antiques оставляет за собой право заключить контракт с поставщиком, который представляет наилучшую ценность для бизнеса, как определено Robin’s Antiques.

RFP и сроки выполнения проекта

Хронология RFP и проекта Robin’s Antiques следующая:

Запрос на выпуск предложения
081019
_

Крайний срок подачи предложения
082519
_

Выбор поставщика
083119
_

Начинается создание нового сайта
090519
_

Завершение проекта
120119
_

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

Запрос предложений (RFP) является важным шагом в любом процессе закупок. Это документ покупателя для подрядчика, поставщика или поставщика услуг.

Приобретение неправильного поставщика может быть дорогостоящим. 61% директоров по закупкам (руководители по закупкам) считают, что риск увеличился. В RFP должна быть возможность фильтрации от нескольких участников торгов, чтобы оставались только высококвалифицированные.

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

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

Давай нырнем!

Что такое запрос предложений?

Хороший RFP — это документ, привлекающий всех поставщиков товаров или услуг. Это официальный документ, который содержит следующие компоненты:

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

Когда следует использовать RFP?

RFP — лучший способ получить множество предложений от потенциальных поставщиков для успеха проекта.

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

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

Вот несколько сценариев, которые могут побудить вас использовать RFP:

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

Почему организации создают RFP?

Организации используют запрос предложений (RFP) для покупки товаров, услуг или проектов. Наиболее распространенная причина, по которой организации используют RFP, — это экономия времени и денег.

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

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

Как работает процесс запроса предложений?

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

Шаги, которые необходимо предпринять для создания RFP:

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

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

Получение наилучшего предложения от поставщика жизненно важно для успеха вашего бизнеса!

Преимущества запроса предложений (RFP)

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

RFP упрощает оптимизацию процесса и сравнение предложений.

Запросы предложений предлагают некоторые преимущества как для покупателей, так и для поставщиков, в том числе следующие:

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

RFP, RFQ и RFI

RFP — это деловой документ, используемый компаниями для запроса предложений от поставщиков.

Запрос котировок (RFQ) — это документ, который предприятия используют для запроса котировок или цен.

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

Как написать запрос предложений?

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

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

Давайте рассмотрим некоторые важные элементы подробного запроса предложений:

• Имя: Отражает название вашей компании или организации
• Число: Включите номер при объявлении вашего RFP
• Кратко: Краткое описание RFP, справочная информация и т. д.
• Цели: Укажите задачи, цели проекта и критерии для проверки предложений поставщиков.
• ожидаемые результаты: Будьте как можно более конкретными при описании результатов вашего проекта
• График работы: Укажите факты и крайний срок проекта, включая представление, даты завершения и подписание условий контракта.
• Бюджет: Укажите целевой бюджет проекта
• Критерии оценки: Вы перечислите свои критерии оценки, лучшее и окончательное предложение 

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

Примеры и шаблоны RFP

Образец запроса предложений от госорганов ищите по этой ссылке СШААгентства международного развития (USAID). Запрос предложений на проект с бюджетом 23 миллиона долларов США на пять лет.

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

При написании шаблонов RFP используется следующий формальный процесс:

• Высшее руководство создает RFP.

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

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

Убедитесь, что у поставщиков достаточно места для ответов с вопросами и комментариями.

Вы хотите, чтобы они чувствовали себя комфортно, задавая вопросы, потому что они пытаются победить! 

Часто задаваемые вопросы о запросе предложений (RFP)

Что дальше

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

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

Работы С Нами Лилинсорсинг опытная команда, мы можем помочь вам пройти весь процесс с нуля. Так зачем ждать? Свяжитесь с нами сегодня, чтобы начать!