Как оценить ИТ-услуги? Поработать или заработать

Перед каждой компанией, и ИТ тут не исключение, стоит проблема ценообразования. Когда мы говорим об ИТ-услугах, одним из важнейших вопросов является определение оптимальных ставок. Можно проиграть тендер и остаться ни с чем, а можно выиграть и потерять еще больше. Основываясь на 20-летнем опыте работы в отрасли, эксперт компании GlowByte Юлий Гольдберг выделяет значимые аспекты, которые важны при принятии решения о ставках и которые, по его мнению, учитываются далеко не всегда. 

По роду деятельности мне приходилось иметь дело с большим списком разнообразных ИТ-услуг и форм взаимодействия заказчиков и подрядчиков, в частности заниматься вопросами ценообразования на ИТ-услуги, определением/изменением ставок, согласованием их с клиентами компании. 

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

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

Фикс или T&M 

Когда мы говорим о ставках — тарифах на работу специалистов, важно учитывать, что существует два принципиально разных подхода к расчету стоимости услуг для клиента. Первый — Fixed Price, фиксированная цена за проект (или какой-то его этап) под ключ. Второй — Time & Materials (T&M), когда стоимость рассчитывается на основе объема трудозатрат, потраченных на оказание услуги. 

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

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

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

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

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

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

Себестоимость 

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

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

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

Понятно, что для того, чтобы правильно учитывать себестоимость при расчете ставки для клиента, требуется уметь ее корректно посчитать. Сейчас не те времена, чтобы клиент покупал ресурсы втридорога. Конкуренция практически во всех областях ИТ-услуг высокая, и клиенту не требуется много усилий, чтобы получить как минимум несколько (а иногда и несколько десятков) релевантных предложений от подрядчиков, которые могут предоставить специалистов нужной квалификации и с нужным опытом. 

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

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

Хотя риски простоев по своей вине в аутстаф-контрактах берет на себя заказчик, он точно не возьмет на себя простои по вине исполнителя, больничные, отпуска и пр. Платить подрядчику он будет только за те часы или дни, которые реально отработаны. 

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

Как посчитать

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

На мой взгляд, 220 дней, отработанных и принятых клиентом за год при примерно 250 рабочих днях, — отличная реализация. Конечно, бывают уникумы, которые могут достичь и 260 дней, работая без отпусков и беря по выходным задачи на переработки, но таких героев не так много, зато много людей, которые сами болеют или вынуждены сидеть с заболевшими детьми, у которых реализация опускается ниже 200 или даже 190 дней в году, а расходы на них при этом не уменьшаются. 

Поэтому для себестоимости при расчете ставки, если нет четкой статистики, можно взять 200-210 дней реализации в год (1600-1680 часов), и делить все годовые затраты на сотрудника на это число, чтобы получить дневную себестоимость человека. 

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

Выводы 

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