Тендерный переполох

 

 

 

Влад Березин, РМР

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

 

 

Cовершенно не важно, в каком бизнесе работает ваша компания. Так же не важно, какой проект вы планируете запустить сейчас, завтра или через год. Рано или поздно каждой компании, и вам, как спонсору проекта, приходится сталкиваться с пониманием, что, возможно, вместо самостоятельного производства товаров или услуг, проще и выгоднее купить их у профессионалов. Это – своеобразная гарантия качества, страховка от рисков, которые вы не хотите контролировать, экономия времени и денег. Бывает и так, что для ответа на проектные риски нет другой альтернативы. Например, если ваша компания занимается продажей продуктов питания, а проект требует строительства здания, то вряд ли вы будете строить его сами…

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

 

Зачем и что покупать (планирование)?

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

• «ЧТО» (именно необходимо купить)?
• «У КОГО» (покупать это «что-то»)?
• «СКОЛЬКО» (это «что-то» стоит)?

И на не совсем очевидные, связанные с предстоящим выбором наиболее устраивающих организацию товаров (услуг) из предложенных рынком.:

• «КТО» (в организации будет выбирать)?
• «КАКИМ» (процедурам при этом следовать)?
• «ЕСТЬ ЛИ» (критерии и документы, на основании которых будут закупаться товары или услуги?

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

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

Например, в рамках решения стратегической цели организация решила внедрить у себя комплексную ERP систему, для управления финансами, закупками и продажами…

 

Кто в организации будет проводить тендер?

Состав группы людей, специально выделенных для проведения тендера по выбору оптимального ERP продукта, а также поставщика услуг по его внедрению (тендерный комитет), естественно, варьируется от одной компании к другой и зависит от ее общей и организационной политики в управлении проектами. Важное правило (!) – в комитете должны быть представлены все подразделения компании, чьи интересы затрагивает проект. Тендер – это ролевая игра в реальном времени, где каждый представитель защищает свои интересы и имеет поле ответственности. Например:

• Спонсор проекта (Директор компании) – является формальным заказчиком работ. Формально финансирует проект, формально принимает работы и результаты проекта. Также часто служит арбитром при решении спорных ситуаций в случае конфликтов из-за ресурсов, между подразделениями, а также между ключевыми ограничениями проекта.

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

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

• Руководители функциональных подразделений (отдел продаж, отдел закупок, отдел IT) – оценивают применимость предложений поставщиков к потребностям подразделений в рамках проекта.

• Секретарь проекта – сотрудник организации, который будет готовить документы в рамках тендера.

 

Приведенный состав тендерного комитета для проекта внедрения ERP системы является оптимальным и по количеству и по качеству, поскольку подобран так, что профессиональные знания каждого внесут конкретный вклад в единое понимание того,  

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

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

Документарная подготовка к тендеру (как начать?)

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

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

Если контракт на поставку программного продукта, как правило, является довольно, стандартным у всех поставщиков ERP систем и изменен быть не может, то с контрактом на внедрение (на предоставление услуг) ситуация сложнее.

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

Таким образом, основой элемент, непосредственно связанный с контрактом на поставку программного обеспечения - это требования к его функциональности (т.е. то, что должна «уметь делать» ERP система), оформленные в виде спецификации. Вновь коротко, но формально,спецификация – это документ, описывающий потребность потребителя в конкретных услугах, которые должен будет предоставить поставщик, чтобы ERP система (планируемая или уже приобретенная), начала функционировать  в соответствии с такими потребностями. Спецификация является неотъемлемой частью документов поставки, отправляемых потенциальным поставщикам для получения от них тендерных предложений.

В Таблице 1 представлены «полярные» типы контрактов (Фиксированная стоимость (ФС) и Повременная оплата (ПО)) и ассоциированные с ними риски. Кроме них можно выбрать «промежуточные» варианты, т.е. такие контракты, которые содержат элементы и ПО и ФС.

Таблица 1. Типы контрактов на поставку услуг

Тип контракта	Достоинства	Недостатки	Основной риск
ФС	Покупателю проще управлять контрактом Поставщик сильно мотивирован к выполнению работ Покупатель знает стоимость проекта в его начале	Большой финансовый риск для поставщика Переоцененная стоимость работ вследствие демпфирования рисков поставщиком Риск для покупателя не закончить проект из-за остановки проекта поставщиком в случае переоценки им своих возможностей при планировании	Поставщик
ПО	Выгоден для поставщика Проще управлять изменениями Работы выполняются качественно	Покупатель не знает стоимость проекта в его начале Риск конфликтов при увеличении стоимости	Покупатель

 

Чтобы принимать решение, какой тип контракта подойдет вам, необходимо оценить множество факторов, включая:

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

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

Итак, с типом спецификации на работы напрямую связан тип вашего будущего контракта, т.е. можно сказать, что от того, какую спецификацию вы сможете подготовить, такой тип контракта вам и предложит поставщик. А от типа контракта и спецификации зависит, что именно вы собираетесь купить – абсолютно понятную услугу (фактически – товар) или экспертизу поставщика. Чем меньше знаний вы имеете о том, как функционирует ERP система и как организуется проект по ее внедрению, тем, естественно, больше вам придется полагаться на поставщика и, соответственно, именно он будет диктовать правила игры. В этом случае вы покупаете экспертизу. Если вы в состоянии сами детально определить, что и в какой последовательности должно выполняться в рамках проекта, а также в соответствии с какой методологией и документами, то вы сами сможете диктовать условия выполнения проекта.

По степени детализации все спецификации можно разделить на три типа: 

• Характеристики – описывают, что конечный продукт проекта должен из себя представлять. Наименее детализированный, но и наименее трудоемкий документ. Рекомендуемый тип контракта – ПО
• Функциональные – описывают конечный результат или цель, а также (возможно) общие характеристики конечного продукта. Такая спецификация относится к документам средней степени детализации. Рекомендуемый тип контракта – ПО, однако в данном случае применимы «промежуточные» типы контрактов
• Дизайн – детально описывают объем работ, который должен быть выполнен в рамках проекта. Такой документ - наиболее трудоемкий, однако приготовив спецификацию типа «дизайн», вы вправе рассчитывать на контракт с фиксированной стоимостью.

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

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

В случае, если спецификация готовится членами тендерного комитета, то все участники и здесь играют ответственные роли, причем в определенном порядке (рисунок 1):

1. Руководитель проекта готовит, а Спонсор проекта утверждает формат спецификации
2. Каждый представитель функционального подразделения готовит часть спецификации, относящуюся к зоне его ответственности
3. Руководитель проекта просматривает части единого документа на предмет их соответствия принятому формату. В случае необходимости вносятся корректировки.
4. Секретарь проекта сводит части спецификации в единый документ для обсуждения на совещании тендерного комитета. 
5. Спонсор проекта утверждает спецификацию, если она полна и не содержит противоречий

Рисунок 1. Процесс подготовки спецификации.

Планирование переговоров

Спецификации представляют собой основную часть всех документов, условно называемых  «Документы обеспечения поставки», или попросту – запроса будущим партнерам. Эти документы отправляются потенциальным поставщикам для подготовки ими своих предложений. Тендерный комитет определяет, какой тип документов, из возможных, будет предъявляться потенциальным поставщикам (Таблица 2):

Таблица 2. Типы документов обеспечения поставки и ассоциированные с ними типы контрактов и спецификаций

Тип документа	Описание	Тип контракта	Тип спецификации
RFP (Request For Proposal) – запрос на предложение	запрашивает от поставщика цену, экспертизу, кем, как будут выполняться работы	ПО	функциональные
RFB (Request For Bid) – запрос на цену	запрашивает от поставщика цену за все работы	ФС	дизайн
RFQ (Request For Quotation) –запрос на расценки	запрашивает от поставщика стоимость ресурсов в единицу времени	ПО	характеристики, функциональные, дизайн