Пожалуй, вопрос «Сколько это стоит?» – третий по популярности в нашей жизни, после «Что делать?» и «Кто виноват?». Мы задаем его чуть ли не каждый день (а бывает, и не раз на дню), он пронизывает всю нашу жизнь – и в быту на уровне «Почем рыбка?», и в профессиональной сфере на уровне «Сколько будет стоить реализация проекта по автоматизации системы управления…?». Как решать вопрос «Что делать?» – оставим философам, «Кто виноват?»» – следователям. А вот в тонкостях вопроса «Сколько стоит?», в его профессиональном смысле, в области ИТ- и бизнес-консалтинговых проектов, я попробую немного разобраться сам в рамках данной статьи – когда и почему этот вопрос возникает, как и  кому его задают, и стоит ли ждать простого и однозначного ответа?

Трудности перевода 

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

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

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

Просто – не значит правильно 

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

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

Такой способ формирования стоимости чаще всего называют «Time&Materials», «T&M», т.е. если дословно перевести с английского – оплата затраченных подрядчиком времени и материалов. В среде системных интеграторов – наиболее частых подрядчиков по консалтинговым проектам и проектам по автоматизации бизнес-процессов, такой подход называют также «оплата по таймшитам», или, коротко, «таймшиты» от английского «time sheet» - название отчетного документа о затраченном времени на оказание услуг. Данная схема может быть реализована как с установкой некоего лимита на максимальную стоимость услуг (это актуально, например, для компаний, закупочная политика которых не позволяет заключать договора с неопределенной ценой), так и без установки каких-либо лимитов. Общее всегда одно – взаиморасчеты с подрядчиком осуществляются по фактически затраченным часам на оказание услуг, а не по фиксированной, заранее определенной стоимости всего проекта или конкретных его частей, этапов.

Риск – благородное дело, а игра – стоит свеч 

Безусловно, использование схемы T&M несет в себе массу позитивных моментов для заказчика – и самый главный из них – возможность гибкого подхода к требованиям и, соответственно, функционалу будущего продукта или системы, в отличие от подхода к реализации по фиксированной стоимости.

При взаимодействии по фиксированной стоимости заказчики очень часто встречаются с вполне оправданным сопротивлением со стороны подрядчика в плане изменений той или иной функциональности. Объясняется это очень просто. Любой опытный подрядчик обязательно включит в фиксированный договор набор допущений и ограничений, исходя из которых он готов реализовать проект по заявленной стоимости. В зависимости от того, насколько зафиксированные ограничения стабильны и насколько они позволяют создать результат, удовлетворяющий заказчика, эти ограничения могут быть как просто неким «забором», за который не стоит заходить, так и самой настоящей «клеткой», которая будет мешать получить нужный результат в меняющихся окружающих условиях. В любом случае, когда требования начинают меняться, когда допущения и ограничения перестают работать из-за изменившихся потребностей, это уже плохо для фиксированной схемы. Даже если заказчик и подрядчик обговорят все детально и придут к консенсусу по расширению рамок и бюджета проекта – все равно плохо. Плохо потому, что сначала будет потрачено время на фазу «сопротивления», потом на глубокий анализ изменений требований, а потом – на формализацию договоренностей и изменение договорных условий. Схема T&M позволяет избежать негативного влияния этих моментов и вместо окольных путей идти сразу напрямик к желаемой функциональности, пусть она и отличается от того, как ее видели на старте проекта – ведь той самой «клетки» в виде фиксированных допущений и ограничений нет.

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

Мифы и реальность 

Почему же все проекты не реализуются по схеме T&M? Ведь в той или иной мере все проекты объемом от нескольких человеко-месяцев подвержены изменениям требований. Думаю, всему виной крайне низкий уровень общего доверия на отечественном рынке. Общаясь с коллегами из- за рубежа, я всегда удивлялся тому, что доля проектов по схеме T&M там существенно выше, более того, многие компании работают исключительно по такой схеме. Стоит, правда, отметить, что с каждым годом схема T&M становится популярнее и у нас.

Однако популяризации схемы препятствует ряд мифов. Самый распространенный миф – это мнение, будто подрядчики очень слабо мотивированы на эффективную работу и достижение результатов при такой схеме, мол, что может быть проще – выставлять часы заказчику и получать регулярно деньги. Но при этом всегда опускается тот факт, что заказчик как при фиксированной схеме не примет некачественных результатов, так и в схеме T&M вряд ли согласует 200 человеко-часов за создание формы ввода данных из 10 строк. Кроме того, серьезные проекты делают серьезные подрядчики – у других просто не хватает ресурсов, чтобы содержать компетентную и достаточно многочисленную команду. И эти серьезные подрядчики также серьезно подходят к вопросу своей репутации – им не нужны затянутые проекты с недовольными заказчиками. И дело тут не только в благородстве и чести. Ведь репутация – это один из лучших каналов продаж, и ничто так не ценно для заказчика, чем положительный отзыв на подрядчика от другого заказчика, особенно от конкурента.

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

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

Рекомендации по поиску панацеи 

Даже не думайте ее искать. Разумеется, нет единого рецепта на все случаи жизни. Не существует единственно правильной схемы, по которой должно быть организовано взаимодействие в плане взаиморасчетов после того, как заказчик задаст вопрос: «А сколько это стоит?». Если требования досконально известны, прозрачны и стабильны, то почему бы не зафиксировать стоимость? Вполне рабочий вариант, рабочая схема взаимодействия, проверенная временем – шаблоны тоже бывают хороши. Но в других случаях – если хочется иметь возможность гибко менять требования, корректировать функциональность, выполнять часть проекта собственными силами для взращивания центров компетенций, то лучшим вариантом будет использование «таймшитов». Ведь это хороший способ, отбросив шаблонные схемы с фиксацией стоимости и связанные с ними ограничения и допущения избыточных ограничений и допущений, получить отличный результат при существенной экономии за счет отсутствия платы за несбывшиеся риски. Или получить не то, что «было когда-то задумано», а то, что нужно «здесь и сейчас». И как по мне, то много лучше вместо времени, нервов и сил (читай – денег), потраченных на споры с подрядчиком о том, входит то-то и то-то в рамки проекта или нет, а также является ли то-то и то-то изменением требований и нарушением допущений, сконцентрироваться на том, чтобы удостовериться в достаточном уровне компетентности и квалификации проектной команды подрядчика, проверить понимание подрядчиком задач, которые стоят перед бизнесом, изучить опыт реализации подобных проектов на рынке, в том числе попытаться пообщаться напрямую с другими компаниями, которые уже пользовались услугами данного подрядчика. А найдя такого подрядчика, не пугаться в беседе о том «Сколько это стоит» слова «таймшиты», а использовать все позитивные возможности, которые дает эта схема, и использовать их по-максимуму, ведь вы хотите не так уж много – вам достаточно самого лучшего, не так ли?

Источник: GlobalCIO