форма rfp что это такое

Образцы RFP или лучше один раз скачать, чем сто раз прочитать!
23.10.2017

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

Почему?

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

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

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

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

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

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

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

Источник

Что такое RFP и как его правильно написать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Что такое RFP и как создать его?

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

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

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

Процесс запроса RFP

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

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

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

В этих предложениях поставщики обычно включают следующие элементы:

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

Зачем нужен запрос предложения?

Давайте кратко рассмотрим эти два сценария:

Вариант №1: Потратьте время на поиск идеального поставщика самостоятельно.

Вариант № 2: Используйте RFP, чтобы привлечь потенциальных поставщиков.

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

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

Это не сложный процесс, но мы упоминали, что вам нужно повторить его для каждого перспективного реферала или поставщика, с которым вы сталкиваетесь? Представьте, сколько времени это займет!

Вот что делать не с помощью RFP

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

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

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

2. История вашей компании.

3. Цели вашего проекта.

5. Целевой график выполнения.

6. Возможные дорожные блоки.

7. Бюджетные ограничения.

8. Что вы ищете у потенциальных поставщиков.

Источник

Как правильно писать RFP на разработку ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Waterfall или Agile?

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

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

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

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

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

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

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