Особенности ценообразования на сложных ИТ-проектах

Заказчики часто требуют фиксированный бюджет от исполнителей до начала ИТ-проекта. Эта логика понятна. Заказчику нужно “заложить” бюджет на очередной год, а также понимать в какие деньги ему обойдется система. Но поставим себя на место исполнителей – мы сталкиваемся с ситуацией “фиксированный бюджет за нефиксированный результат при неизвестных условиях работы”…

Требования к системе формируются зачастую на уровне “Система должна планировать и диспетчировать”. Что именно под этим подразумевается, не уточняется. Неизвестно какое будет содействие Заказчика и какую часть работ он сможет взять на себя – реально, а не по обещаниям. Но уже идет разговор о фиксированном бюджете.

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

Итак, по статистике, 95% Заказчиков желают узнать точный бюджет сложного и длительного (1-2 года) проекта автоматизации до начала работ, и склонны далее ориентироваться на него. Если бюджет превышается, то проект считается неудачным, и это ведет к потенциальному конфликту между заказчиком и исполнителем. Заказчик не хочет доплачивать, исполнитель не желает продолжать нерентабельный, убыточный для него проект.

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

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

Расчет сметы для выполнения проектов автоматизации – задача более сложная и формализации практически не поддающаяся. Возможны лишь экспертные оценки.

Согласно статистике, бюджет не выдерживается для 80% ERP-проектов автоматизации.

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

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

Если демпингование происходит по тарифной ставке консультантов за час, то это более приемлемый вариант. Но надо понимать, что стоять с секундомером рядом с консультантами пока они оказывают свои услуги – навряд ли кто будет, а нормативов на работы консультантов и программистов (например 10 строк кода за 5 мин, 5 консультаций за час) :) не существует. Кроме того чем ниже в результате торга опущена тарифная ставка, тем менее квалифицированные консультанты будут предоставлены исполнителем. А ведь от опыта и знаний консультантов успех проекта зависит кардинально!

Есть честные компании, которые оптимистический прогноз по бюджету сразу умножают на 3, и нечестные которые этого не делают. В результате честные компании неконкурентоспособны по ценам. Они не умеют продавать проекты :).

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

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

Например:

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

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

Иногда в договорах определяется коридор изменения бюджета. Например устанавливается фиксированная стоимость проекта плюс-минус 30%. Но на самом деле, такая договоренность не более чем фикция – договорной бюджет будет фактически равен верхней границе коридора.

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

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

Решения:

А) Если надо фиксировать бюджет:

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

Б) Если надо фиксировать результат:

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

И в том, и в другом случае удобно использовать технологию Agile/Scrum, как наиболее цивилизованный способ взаимодействия сторон.

Читать об Agile/Scrum>>>

Статья “Как не прогадать со стоимостью ИТ-проекта”>>>

[evc_social_likes]