Как найти хорошего аутсорсера с помощью тендера. Готовый фреймворк проведения тендера

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

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

Мое мнение — аутсорсить можно все, кроме принятия решений.

Все таблицы, картинки и прочие файлы из статьи можно найти по ссылке https://bit.ly/2V686uQ.

Что нужно для успешного тендера?

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

Какие шаги необходимы для этого?

  1. Договоритесь внутри команды, кто и за что отвечает.
  2. Определите порядок и сроки проведения тендера.
  3. Обдумайте критерии оценки предложения и основания для принятия решения.
  4. Отправьте вендорам запрос на предложение, в котором есть:
    • постановка проблемы/задачи;
    • описание условий и порядка работы;
    • четкие указания на ожидаемый результат работы и требования к вендору;
    • обозначение необходимой документации от вендора; вопросы, ответы на которые должен дать вендор; установление ожидаемого срока получения предложения;
    • пригласите вендоров на тендер.

5. Общайтесь с ними во время тендера.

6. Подведите итоги.

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

Распределение ролей

Рекомендую выделить следующие роли:

  • Заказчик — тот, кто имеет определенную задачу, решить которую должен победитель тендера.
  • Менеджер — тот, кто проводит тендер.
  • Тендерный комитет — те, кто принимают решение о победителе.

При необходимости совмещать две или три роли может один человек. Однако каждая роль обязательна.

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

Кто и за что отвечает внутри команды?

Для наглядного распределения ответственностей рекомендую использовать RACI матрицу — инструмент визуализации “кто и за что отвечает”. Главные цели RACI матрицы: зафиксировать договоренности и найти зоны, за которые еще никто не отвечает.

Можете использовать приведенное ниже распределение ответственностей или сделать свое. Главное, чтобы все участники его поняли и приняли “на берегу”.

Обязательно проверяйте, что у задачи\процесса всегда только одна A.

Пример

Сроки и порядок проведения тендера

Порядок проведения тендера

Это универсальная модель проведения тендера. Используйте ее или видоизмените под свои потребности.

Сроки проведения тендера

Очень просто проверить, является ли ваше флоу проведения тендера лучше. В таблице ниже приведены средние сроки тендера, который проводит большая ИТ-компания. Если ваша последовательность действий сложнее или сроки исполнения больше (в сравнении с расчетами в таблице), значит, предложенный мною вариант лучше.

Запрос на предложение

  • RFI, Request For Information. Это самый простой вид запроса. Он нужен, чтобы узнать, чем занимается компания, откуда она и т.д.
  • RFQ, Request For Quotation. С помощью этого запроса вы сможете прояснить, на каких условиях и по каким ценам работают компании в данной нише “вообще”. Конкретизация вашей задачи в данном запросе не подразумевается.
  • RFP, Request for Proposal. Данный вид запроса предполагает подробное описание задачи и желаемых условий работы. От вендоров вы просите уже конкретное и подробное предложение.

RFP — самый объемный и сложный из всех типов запросов. Поэтому мы разберем именно его.

Ваш RFP должен состоять из следующих пунктов:

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

О проекте

Описание сроков и процесса проведения тендера

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

Главные цели вашего проекта

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

Сроки проекта и ключевые даты

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

Содержание работ

Кратко перечислите, какие типы работы и ответственностей вы ожидаете получить от вендора в вашем проекте. Пример плохой формулировки — “сделать сайт”. Хороший пример — развернутое описание всех деталей проекта:

  • составить и согласовать подробнее техническое задание;
  • сделать дизайн сайта и логотипа;
  • запустить сайт в работу;
  • предоставить инструкции по его использованию

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

Тут вы рассказываете о своих пожеланиях к результату. Отмечаете технические и функциональные требования, технологии и прочее. Фактически — это ТЗ. ТЗ — это важно. Не имея ясного представления о конечном результате выполненных работ, вы не сможете четко составить ТЗ. Как результат — вам не удастся получить желаемого. Без грамотного ТЗ исполнитель бесполезен.

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

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

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

Несколько примеров описания требований

О процессе совместной работы

Коммуникации

Расскажите о том, как часто во время работы вы хотите созваниваться, хотите ли вы использовать Skype или обычный телефон. В какой временной зоне ваши рабочие часы.

Процедура внесения изменений

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

Процедура и сроки приемки работ

Как вы будете принимать работу? Сколько для этого вам потребуется времени? По каким критериям станете определять, что работа выполнена в полном объеме и в соответствии с вашими требованиями?

Пакет поставки

Используйте такое определение, как “пакет поставки”. Пакет поставки — это не только “вот ваша программа, пользуйтесь!”. Это могут быть также инструкции по ее использованию, проверке, исходники дизайнов, кода и т.д. Отдельно рекомендую указывать пункт, обязывающий исполнителя во время всего процесса приемки быть на связи для прояснения любых вопросов с вашей стороны. Договоритесь, что приемку всех этапов работы вы сможете начать только после получения полного пакета поставки.

Оплата

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

Не привязывайтесь к “степени готовности” работы! Этот вариант выгоден вендору: он закрывает риски исполнителя, но не ваши.

Несколько примеров триггеров оплат

Требования к вендору

В этом пункте следует указать значимость для вас параметров, например:

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

Требования к предложению

Какую информацию и в каком виде вы ожидаете от вендора?

Я рекомендую запрашивать:

  • Портфолио с аналогичными проектами.
  • “Профессиональный портрет” (CV) команды вендора: навыки ключевых специалистов, задействованных в проекте.
  • Локацию команды.
  • Описание рисков, предполагаемых вендором, и способы управления ими.
  • Расшифровку оценки по пунктам.
  • Список технологий, которые вендор планирует использовать, а также аргументы в пользу именно этих технологий.

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

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

Расшифровка оценки

Расшифровка оценки ( breakdown structure, BDS) — это иерархическая декомпозиция необходимых работ по проекту с оценкой каждой работы. В самом простом варианте выглядит вот так:

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

Примеры:

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

Дополнительные материалы

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

NDA

Здесь обычно описывают, какие документы, как и кому нужно отправить, чтобы подписать с вами NDA.

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

Дополнительно

  • Укажите единицы измерения и валюту, в которой вендор должен прислать оценки. Например, какую оценку использовать? Стоимость часа в рублях или стоимость всего проекта в долларах США? Измерять в днях или в часах? Это упростит вам сравнение предложений и избавит от необходимости конвертировать и приводить все к одному знаменателю.
  • Не пишите о том, по каким критериям вы будете оценивать предложения. Не давайте повод вендорам манипулировать результатами! Не делитесь данными критериями даже при настойчивых уговорах со стороны вендора.
  • Выделяйте секции RFP в отдельные дополнения в конце документа. Обычно, RFP составляют несколько человек. Сроки и цели заполняет PM, технические требования один из программистов. Ваш запрос будут читать тоже несколько человек. Например, “технические требования” отдадут на изучение программистам. Информация о NDA, сроках тендера и т.д. IT-сотрудников будет только отвлекать. Я советую выделять описание требований в отдельное приложение в конце документа, а в запросе писать “Требования и описание….” также в конце документа. Так процессы составления и прочтения документов оптимизируются. Так проще вторично использовать данные документы.

Как оценивать предложения?

Критерии и их приоритетный порядок

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

Оценка предложений по критериям

Определите точное количество баллов для каждого критерия. Например, для вас важен критерий “опытная команда”. За что вы будете давать 4 балла, а за что 2? Если таких определений не назначить, не будет единой линейки оценивания. Это значительно снижает качество оценки предложений, делая ее менее объективной.

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

В шаблоне есть:

  • универсальный список вопросов для оценки;
  • матрица оценки с использованием баллов и весов.

Скачать фреймворк по ссылке

Почему нужно использовать 4 балла, а не 5 в оценке?

Если использовать 5 баллов, то в ситуации, когда трудно определиться, подсознательно всегда хочется поставить 3. Имеется в виду медиана ряда 1 2 3 4 5. Если ряд баллов состоит из 4 цифр, вы будете вынуждены поставить балл либо выше, либо ниже средней черты. А это привнесет больше конкретики в вашу оценку.

Как цифровые показатели оценивать в баллах?

Разберем на примере стоимости предложения, как разбить на 4 корзины (выставить баллы от 1 до 4). Вам прислали 5 предложений.

  • Предложение 1–120р
  • Предложение 2–30р
  • Предложение 3–150р
  • Предложение 4–90р
  • Предложение 5–70р

Шаг 1. Определим корзины и их границы

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

ШАГ = (Максимальная сумма — Минимальная сумма ) / Количество корзин (баллов)

ШАГ = (150–30) / 4 = 30

Шаг 2. Распределим предложения по корзинам

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

Работайте с теми, кто предлагает рыночную цену и реалистичные сроки выполнения работы!

Пригласить вендоров на тендер

Я советую приглашать 8–12 вендоров. При меньшем количестве участников трудно понять реальные рыночные условия. При большем — потратите много времени на менеджмент и коммуникации.

Что нужно написать в первом письме вендору?

  • Представиться.
  • Кратко обозначить цель вашего письма и тендера.
  • Тезисно перечислить ключевые даты тендера и проекта.
  • Рассказать, где можно подробно ознакомиться с информацией о тендере.
  • Узнать о согласии вендора принять участие в тендере.
  • Обозначить следующий шаг для заинтересовавшихся вендоров. .
  • ОПЦИОНАЛЬНО. Если вы не можете сразу поделиться подробностями проекта с вендорами, опишите кратко процедуру подписания NDA.

Пример

Привет, “Интеграл”, меня зовут Дмитрий Филатов, я менеджер компании “Рога и копыта”. Наша компания планирует сделать новый корпоративный сайт, и мы хотим найти вендора, который поможет нам в реализации этого проекта (дизайн, верстка, программирование).

Для поиска вендора мы планируем провести тендер. И этим письмом хотим пригласить вас принять участие в нем. Ваш сайт и контакты мы нашли во время холодного поиска в Google.

Тендер будет проводиться с 23 февраля по 18 марта включительно. С 18 по 25 марта мы будем выбирать победителя, уточнять детали предложений. 26 марта мы оповестим всех участников о результате тендера.

Начало работ по проекту мы запланировали на 28 марта. Более подробное описание дат, задач проекта, требований к предложению и т.д., вы можете найти в документах по ссылке — ссылка.

Вам интересно принять участие в нашем тендере? Будет здорово получить ответ с вашим решением в течении 2–3 дней.

Где брать контакты вендоров?

Кроме Google и “ поспрашивать у коллег” могу рекомендовать http://vendors.dimafilatov.ru — мой каталог вендоров для GameDev. Каталог веду я и систематически актуализирую. В основном, там малые и средние команды. Есть удобный поиск, выгрузка в Excel результатов поиска и статистика.

Можно ли работать с фрилансерами?

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

Фрилансометр по ссылке

Общение с вендорами во время тендера

Оценивайте не только предложение вендора, но и уровень его коммуникативной культуры. На одной ли он с вами волне? Рассмотрим несколько примеров.

Хорошие маркеры:

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

Плохие маркеры:

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

“А давайте созвонимся!”

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

Knowledge sharing между вендорами

Представим: один из вендоров задал вам вопрос, значимый для объективной оценки вашего проекта. Обязательно перешлите этот вопрос и ответ на него другим вендорам! Так вы обеспечите равные условия для всех вендоров.

Лог проведения тендера

Делайте краткий лог-статус общения с каждым вендором — “запрос отправлен”, “получили вопросы, обещали ответить 27-го”. У вас будет много коммуникаций. Так вы не потеряете важную информацию.

Пример простого лога

В общении с вендорами в почте всегда держите 1–2 коллег в копии. Если вы заболеете, это поможет им подхватить вашу работу. То же касается Skype и других видов связи. У коллег тоже должен быть доступ к логу.

Подведение итогов

Что писать победителю?

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

Short list и план Б

Тем, кто в вашем рейтинге занял 2-е и 3-е места, напишите, что они оказались в шаге от выигрыша. Уточните, заинтересованы ли они в сотрудничестве с вами в случае неудачного партнерства с победителем тендера.

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

Оповещение проигравших о результатах

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

Укажите сильные стороны предложения вендора. Напишите и о слабых сторонах предложения. Фактически, вы укажите на причины проигрыша. Спросите, не против ли вендор в будущем участвовать в ваших тендерах?

Пример письма:

Максим, привет.

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

Сильные стороны

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

— Отлично составлен план проекта, который выглядит реалистичнее других.

….

Зоны роста

— Вы предложили одну из самых высоких цен.

— В вашем портфолио нет релевантных проектов.

….

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

Используйте шаблоны для отправки типовых писем. Это сэкономит вам время и убережет от ошибок. Однако, прежде, чем отправлять сразу все письма, отправьте 2–3. Вполне вероятно, вы найдете ошибку в этих 2–3 письмах. Исправив ее в шаблоне, вы сможете смело делать рассылку на большее число адресатов.

Еще рекомендации по проведению тендера

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

Благодарность

Данный материал для вас разработал не я один. Существенная его часть — это результат работы профессионалов в области IT-технологий и тендерных процедур в данной сфере, моих замечательных бывших и нынешних коллег из разных компаний. Наибольший вклад внесли: Алексей Эйнор, Дмитрий Зеневич, Екатерина Вербий, Владимир Скрынько, Алексей Угольков, Сергей Бережной и Андрей Ланкин.

Спасибо тем, кто помогал с подготовкой материала: Сергею Евдокимову, Виктору Коротееву, Роману Жихареву.

Редактировать статью помогала Кристина Ваньжина (Telegram @Kristina_Vanzhina)