Ценообразование проектов автоматизации

Меня зовут Кирилл Чебанов. Я являюсь руководителем проектов компании «СофтБаланс» и работаю там с 2020 года.

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

На основании своего опыта расскажу, на какие критерии стоит обращать внимание обеим сторонам при оценке проекта. И что влияет на стоимость проектов в целом.

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

Актуальность ценообразования

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

У нас был интересный кейс по вопросу «а можно подешевле?». К нам пришел заказчик, который хотел внедрить 1С:Документооборот. Нам дали некоторые вводные, мы посчитали коммерческое предложение. На что заказчик спросил: почему так дорого? Наша реакция: в смысле дорого?

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

Ключевые вехи формирования и изменения стоимости проекта

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

Предпродажа. На этом этапе все пообщались, познакомились, дали некое первое оценочное предложение стоимости всего проекта.

Завершение обследования. Это первая ключевая веха. Только после этого этапа стороны однозначно могут зафиксировать, что будет делаться на проекте, потому что только в этот момент выясняются реальные подробности. Как пример, у нас был проект, где заказчик сказал: «У нас есть две базы, нам нужно внедрить вместо них одну ERP, там нужны продажи, закупки и склад». А когда обследовали, выяснилось, что нужно и производство, и регконтур, и МСФО, а баз на самом деле пять.

Завершение моделирования. На этом этапе происходит смысловое уточнение стоимости проекта. После моделирования формируется реальный список доработок. До этого этапа он был примерный.

Подготовка к запуску: интеграции, обучение, инструкции. Здесь вопрос скорее понимания объема этого этапа от каждой из сторон, потому что подрядчики вкладывают в этап «Инструкции» смысл: «Мы учим роль работать». А заказчик думает: «Мы думали, вы нас всему научите, чтобы мы и бюджетирование могли спланировать». Этапы плохо стандартизированы и нормализованы по объему, поэтому их конкретное наполнение уточняется перед запуском этапа.

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

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

Есть 4 варианта ведения проекта:

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

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

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

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

Ключевые факторы: как формат договора и его условия влияют на стоимость договора

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

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

Сроки согласования результатов работ. Чем больше сроки согласования работ и простои команды, тем дороже будет проект.

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

Этап предпродажи

На этапе предпродажи цели у заказчика и подрядчика общие, различаются только итоговые ожидания:

• Все хотят познакомиться с командой, понять уровень компетенций, опыт, навыки.

• Согласовать цели и задачи проекта

• Согласовать функциональные требования к проекту

• Согласовать сроки проекта

А итоговые цели находятся в противоречии:

• Итоговая цель заказчика: получить наиболее выгодное предложение – максимум результата за минимум денег.

• Итоговая цель подрядчика: заработать – предоставить наиболее рентабельное предложение.

Но по факту и подрядчику, и заказчику нужен проект – в этом общая цель.

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

• Подрядчик тоже имеет свои издержки и ценность проекта.

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

На что стоит обратить внимание подрядчику на этапе предпродажи

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

• Полнота требований к проекту. Наличие внятно сформулированных целей и рамок проекта

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

• Договороспособность. Намерение сторон договориться. Понятно, что заказчик всегда прав, но проекты по автоматизации – это про диалог, про способность слышать, слушать и договариваться. Если заказчик занимает позицию «я плачу деньги, я прав, и никак иначе», договориться будет сложнее.

• Порядок проведения работ. Требования по формату проведения работ, требования к результатам.

• Порядок оплаты и актирования. Финансовый аспект проекта.

На что стоит обратить внимание заказчику на этапе предпродажи

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

• Опыт подрядчика. Наличие в портфолио заказчика подобных проектов.

• Детальность оценки. Качество и детальность работы подрядчика с оценкой.

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

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

• Команда проекта. Релевантность и достаточность предлагаемой команды.

Важный момент: Если заказчик рассчитывает именно на ту команду, портфолио которой ему предоставили, важно выдерживать темп этапа предпродажи. Потому что когда после утверждения команды уходит 3-5 месяцев на согласование стоимости и условий договора, сотрудники не будут все это время простаивать. И часто бывает, что на проект выделяют другую команду, которая свободна. Про это важно помнить, этим важно управлять. Поэтому заказчику нужно задать вопрос: будет ли с ним работать согласованная команда или нет? И подрядчику тоже важно предупреждать заказчика о таких изменениях.

Итоги по этапу предпродажи. Что важно помнить

• Опыт и команда проекта. Наличие опыта у команды подрядчика. Наличие команды проекта у заказчика.

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

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

• Требования к проекту. Сформулированные цели проекта.

Первая оценка проекта – самый важный этап, самая большая неопределенность

Варианты формирования цены проекта:

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

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

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

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

Из чего состоит цена проекта

• Себестоимость работы команды. Затраты на содержание команды на период выполнения работ проекта с учетом общих расходов.

• Прибыль

• Резервы. Заложенные исходно активности, которые не имеют обозначенной темы на момент начала работ.

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

Мы разделяем риски и резервы, потому что они отличаются по своей сути возникновения.

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

Риски могут возникнуть именно из-за плохого управления на проекте либо из-за внешних факторов.

Себестоимость интегратора

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

В свою себестоимость мы закладываем:

• Накладные расходы. Часть общих расходов компании, переложенная на одного специалиста.

• Стоимость управления проектом. Стоимость участия в проекте менеджера проекта, технического руководителя проекта – всех тех сотрудников, которые напрямую не пишут документы, не работают руками, но участвуют в проекте. Их время тоже стоит денег. Эта стоимость переносится на проект.

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

• Время простоя специалистов. Этот пункт заказчикам обычно максимально неочевиден – это стоимость времени, которое специалисты не будут работать в ожидании работы по вашему проекту. Люди зарезервированы, но они стоят и ждут.

• Специфическое оборудование. Бывает, что подрядчику для работы нужно купить специфическое оборудование или программное обеспечение, которое может понадобиться только на этом проекте. Это будет включено в стоимость. Лучше отдельно выделять это в коммерческом предложении – если у заказчика есть нужное оборудование, он может предложить воспользоваться им на время проекта.

Простой команды проекта в условиях кадрового дефицита – очень острая тема!

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

Я классифицировал простой на четыре категории:

• Простой специалистов внутри проекта. Задействованные специалисты простаивают в ожидании обратной связи, информации от заказчика или следующей коммуникации. Это разумный простой, который зависит от качества управления – его можно уменьшить за счет повышения интенсивности работы на проекте. Такой простой возникает из-за того, что у нас на проекте не один человек – у сотрудников разные точки коммуникации с заказчиком. Бывает, что они друг на друга завязаны – пока мы ждем одного, второй стоит.

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

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

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

Торги: за счет чего можно оптимизировать стоимость проекта и попробовать выиграть

• Отказ от части документов или работ. Потенциальная экономия – 5-10% бюджета. Мы можем что-то не писать. Яркий пример – отчет об обследовании. От него можно отказаться, ограничившись набором протоколов встреч и просто сводным списком требований.

• Передача части работ заказчику. Здесь в первую очередь речь идет про подготовку базы к запуску, ее наполнение НСИ и обучение пользователей. Мы можем обучить только узкую группу специалистов, а дальше они уже тиражируют свои знания на всех сотрудников компании. Потенциальная экономия – до 15% бюджета.

• Изменение параметров договора. Можно изменить порядок оплаты, порядок актирования, уменьшить штрафы. Потенциальная экономия – 2-3% бюджета.

• Изменение рамок проекта. Потенциальная экономия – не ограничена.

• Обучение команды заказчика. Это не совсем про торги, но имеет отношение к оптимизации стоимости. Бывает, что заказчик вообще не знает продукт, и нам приходится на предпроектном обследовании тратить время на то, чтобы показать ему стандартную функциональность. И на моделировании мы не просто показываем наши предложения по реализации процесса заказчика, но и объясняем, как работает система в целом, и почему мы из всех возможностей выбрали именно такую. Лучше отправить заказчика на обучение в обычный учебный центр – это позволит ему сэкономить время и бюджет на отдельных этапах проекта. После этого и этап обучения на проекте будет проще – люди будут уже понимать, как им работать с системой в целом. Экономия на этапе моделирования – 3-4%. Экономия на этапе обучения – до 10%.

Жизненный цикл проекта и изменение стоимости

Уточнение стоимости проекта

В течение жизненного цикла проекта его стоимость несколько раз уточняется.

• После обследования происходит изменение стоимости по результатам уточнения потребностей проекта и его реального периметра.

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

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

• Перед переносом данных и ОПЭ – изменение стоимости происходит в результате уточнения объема переносимых данных, уточнения ответственных за перенос. Часто срок переноса данных изменяется, потому что большая проблема – договориться, кто занимается нормализацией данных на проекте. Обычно у заказчика нет нужного объема ресурсов, чтобы это сделать, но ему нужны хорошие качественные данные. И конечно, они хотят, чтобы данных в системе было много, они были полные и исчерпывающие. Здесь нужно договариваться – часто на этот этап привлекаются наши специалисты в режиме Time&Material. То же самое касается уточнения стоимости в результате увеличения длительности и количества участников на этапе ОПЭ.

Управление общей стоимостью проекта: как сохранить первоначальный согласованный бюджет

Общие рекомендации по сохранению бюджета проекта:

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

• На начальном этапе согласуйте итоги работ. Чем точнее стороны понимают, кто от кого что ждет, тем меньше меняется стоимость.

• Уделять больше внимания первым этапам – обследование и моделирование. Классическая история – на обучении выясняется, что есть такой-то процесс, а о нем до этого никто не упоминал. Начинаем переобследовать и перемоделировать.

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

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

• Готовность к изменениям инструментов. Например, заказчик и сотрудники привыкли к каким-то формам, документам, АРМам, и они хотят и дальше работать с ними. Но в системе есть инструментарий, который решает их задачу, но выглядит иначе, чем они привыкли. Лучше переучивать сотрудников работать с типовой функциональностью системы и не принимать возражения «мы привыкли по-другому». Иначе бюджет будет расти, а ценность проекта не будет меняться.

Детали, которые часто не учитывают на проектах

О чем часто забывают, и что выясняется уже практически на этапе запуска:

• Отчеты. Часто бывает, что заказчик забывал предоставить какую-то форму, а мы не спросили – вроде, всего хватало, а потом оказалось, что нужно что-то еще. Такие доработки обычно не оказывают заметного влияния на общую стоимость проекта.

• Печатные формы. Забытые специфические ПФ со специфической информацией могут привести к корректировке модели. У заказчиков есть свои клиенты со специфическими требованиями на печатные формы. И про это заказчик вспоминает обычно уже перед запуском. Подрядчику нужно про это помнить и запрашивать эту информацию сразу же на этапе предпродажи.

• АРМы для упрощения работы. Дорогие и тяжело прогнозируемые работы.

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

• Техническое обучение персонала. Заранее решить, какими силами будет обслуживаться ПП. Не часто, но бывает, что ИТ-служба заказчика не умеет работать с 1С, и их тоже нужно обучит.

Резюмируем…

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

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

• Результаты и ожидания проекта. Зафиксируйте ожидаемые результаты каждой активности проекта и их формат.

Вопросы от зрителей

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

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

Аналитику нужно задавать только четкие и конкретные вопросы, а не давать анализировать весь спектр вопросов по проекту целиком.

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

Оценку в основном делает РП, а аналитик должен выступать только как помощник.

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

В случае с фиксированной ценой объем работ будет заложен минимальный, риски – максимальные.

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

А если все равно в итоге не попали в цену?

Такое бывает. Но здесь мы возвращаемся к пункту – способность договариваться. Здесь можно либо вынести какие-то работы за рамки фиксы, но заказчик не всегда на это идет. Либо можно упростить какие-то работы.

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

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

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

Скорее, увеличение стоимости этапа из-за простоя команды возможно, когда подписан поэтапный договор – обследование, моделирование, ТЗ, разработка. Мы видим, как заказчик себя ведет и закладываем риски на следующий этап. Это наш внутренний учет, текущий этап не пересчитывается.

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

В первую очередь, в договоре у нас есть оговорка: в течение какого срока команда возвращается к проекту.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.