Головна » Авторские » Модели ценообразования и типы договоров в аутсорсинге IT услуг
Авторские Фінанси

Модели ценообразования и типы договоров в аутсорсинге IT услуг

Поділіться з друзями - підтримайте проект

Print Friendly, PDF & Email
 В последнее время аутсорсинг услуг вырос из довольно простой концепции до сложной совокупности различных вариантов и моделей. Определение стоимости таких услуг порой может вызывать некоторые сложности и непонимание со стороны заказчика.
 
Мировая практика выработала в этом вопросе три основные модели ценообразования, которые мы и рассмотрим ниже и сосредоточим свое внимание в частности на IT-сфере, где они особо широко используется.

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

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

В западной практике и у нас в последнее время принято различать следующие ценовые модели:

  1. Dedicated Team
  2. Time and material
  3. Fixed Price

Dedicated Team

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

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

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

Следует отметить, что роль аутсорсера услуг сводится к минимуму после формирования команды.

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

Сотрудничество по данной модели можно разделить на несколько этапов:

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

Когда следует выбирать этот вариант?

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

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

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

Преимущества данной модели

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

Но есть и минусы:

  • низкая эффективность для краткосрочных проектов;
  • дороже модели Time & Material и  Fixed Price;
  • выбор членов команды может занять некоторое время и отложить начало проекта, в то время как во время разработки при использовании модели Time & Material работа может начаться в течение ближайшего времени;
  • у выделенных членов команды меньше возможностей изучать новые методики вне своей области в проекте;
  • клиент должен играть активную роль в общении и переговорах и инвестировать много времени в управление.

Time and material (T&M) 

Что делать, если заранее неизвестно все детали проекта и невозможно предугадать все детали? Что делать если нет полного видения конечного продукта и его особенностей реализации, и если нет возможности разделить его на несколько более мелких этапов. Тут вам на помощь придет модель T&M, которая позволяет Вам больше контролировать прогресс развития и стоимость конечного продукта.

В некоторых случаях данный вариант может быть более эффективен чем обычная модель фиксированной цены (Fixed Price). Одним из самых больших преимуществ способа сотрудничества является приоритезация задач для проектов развития.
 
Каждый проект как правило разделяется на несколько отдельных задач (включая функционал, варианты использования, тесты и т. д.). Менеджер проекта предоставляет рекомендации по важности задач, уровню их сложности, способу их реализации и стоимости. В результате клиент может определить приоритет порядка выполнения этих задач и вариантов их использования в зависимости от их цены и релевантности для решения проекта. В этом случае прототип функционирующей системы может быть разработан быстрее, клиент может решить, когда и как реализовать более сложный и дорогой функционал.
 
Как понять, что вам подходит данная модель? Просто дайте ответы на следующие вопросы. Если на все вопросы вы можете ответить “да” – то такой вариант сотрудничества с разработчиком можно расматривать как реальный.
 
Итак:
  • Является ли концепция проекта довольно необработанной, чтобы точно оценить все детали?
  • Вам нужна большая гибкость в процессе развития?
  • Ваша идея связана с новыми технологиями, а не с полностью развитыми рынками?
  • Вы намерены обеспечить прямой контроль над проектом и предоставить своей команде конкретные материалы?

Положительные моменты:

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

Отрицательные моменты:

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

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

Для каких проектов подходит данный тип договоров:

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

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

Fixed price

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

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

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

Основные этапы работ по этой модели:

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

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

  • Фиксированный бюджет
  • Постоянный объем проекта
  • Установленный временной интервал
  • Возможный компромисс по качеству

Для каких проектов используются

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

Как понять, что вам подходит эта модель?

Если вы сомневаетесь, выбирать ли этот вариант просто ответьте на вопросы ниже и если вы можете на них ответить “да”, то это то, что вам нужно.

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

Среди плюсов данной модели можно выделить:

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

Но есть и минусы, а именно:

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

Выводы

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

 


Поділіться з друзями - підтримайте проект