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

Авторы: Лисин Николай, Грациано Егор

Грабли будут позже (с)

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

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

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

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

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

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

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

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

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

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

Неприемлема ситуация, когда Заказчик указывает исполнителям «Вы спроектируйте систему, (моделируйте, напишите ТЗ, запрограммируйте), вот вам месяц на все про все, а мы потом посмотрим – будем принимать, что Вы сделали». Практика показывает, что в этом случае Заказчик часто сталкивается с неожиданным результатом: он видел итоги работ по-другому. А все потому, что не было непрерывных коммуникаций с подрядчиком в процессе выполнения им работ, непрерывных корректировок и поправок в ходе работ.

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

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