Типы бизнес моделей

А какие они вообще бывают? Вот такие:

• Попроектная работа с фиксированной ценой (Fixed Price).
• Попроектная работа с повременной оплатой (Time and Material, Time and Expenses).
• Сдача групп разработчиков внаем (Body Leasing, Offshore Data Center).
• Расширение ИТ отдела заказчика оффшорными ресурсами (Staff Augmentation).
• BOT (это латинские буквы :).

Fixed Price - Модель с фиксированной ценой

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

1. Жестко зафиксировать объем работ. Любые изменения функциональности проекта должны вести к пересмотру времени и стоимости проекта, и это должно быть записано в контракте.
2. Максимально подробно описать критерии и сроки (!) приемки работ в контракте.
3. Описать в контракте способ решения спорных вопросов. Как вариант могу предложить создание комиссии, состоящей из равного количества сотрудников обеих компаний, у которой есть право принятия решения. Этот пункт, как минимум, дает вам возможность вести переговоры с клиентом в спорных случаях. Если его не будет, то клиент может отказаться от переговоров, сославшись на "industry standards" или еще на что то эфемерное и неосязаемое, и послать вас "на галеры" (т.е. предоставить вам возможность насладиться неоплачиваемой работой до устранения причины конфликта).
4. Разбейте работы на максимально мелкие, но логически обоснованные этапы, и приложите к контракту график приемки и оплаты этих этапов. На последний этап оставьте не более 5% - 10% от стоимости всего контракта, так как есть сложившаяся практика не оплачивать последний инвойс, если нет необходимости продолжать с вами работу.

Time and Material - Повременная оплата

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

Клиент обратился в компанию "Keyboard Geniuses" (далее KG) с запросом на разработку online игры для детской аудитории в UK. KG не имела опыта в данном направлении, но один из студентов имел небольшой опыт работы с Action Script, а один из топ менеджеров когда то имел отношение к игровой индустрии, хорошо знал английский язык и умел убеждать. В итоге через неделю у клиента был красивый ответ на RFP, полный графиков, картинок и всего прочего, что так греет "западную" душу. Клиент был расположен к менеджеру и согласился на повременную оплату. Объем работ был довольно большим и требовал команды из трех разработчиков, тестера и менеджера.

После подписания контракта KG поставили студента ведущим разработчиком и начали поиск остальных членов команды. Оказалось, что быстро найти качественных девелоперов не удается, а сроки уже жмут, и в помощь студенту дали cвободного на данный момент PHP девелопера, никогда не работавшего с Flash и Action Script. На начальное обучение у этого девелопера ушла неделя, потом пошло практическое обучение на живом проекте. Ну и так далее и тому подобное. В итоге срок сдачи подкрался незаметно, потом так же незаметно исчез в прошлом, а KG все еще занималось разработкой. Клиент потерял кучу денег, продукт не получил, и больше ни с кем не подписывает контрактов на ТМ, работая только с фиксированной ценой и оплатой после поставки

В общем все, кто работает в ИТ, могут сами вспомнить аналогичные ситуации. А тем, кто скажет, что у него такого никогда не было, я отвечу: расскажите это своей девушке. Вот она вам точно поверит!

Правильный подход к ТМ модели:

• сделайте несколько оценок: пессимистичную, оптимистичную и реалистичную.
• выкиньте оптимистичную оценку и дайте клиенту 2 оценки: реалистичную и пессимистичную. Опишите риски, влияющие на время разработки.
• внесите в контракт оценку в виде диапазона между реалистичной и оптимистичной оценкой. Разница в 20% обычно нормально воспринимается клиентом, если риски не надуманны и доходчиво объяснены.
• можно обсудить премию за выполнение контракта в пределах реалистичной оценки. Это будет хорошим мотивирующим фактором для команды.
• зафиксируйте объем функциональности, на который вы делали оценку. Если объем меняется, то оценка и время пересматривается. Не ставьте молодых и неопытных разработчиков на сложные задачи, если у вас нет "наставника молодежи", отвечающего за качество и скорость их работы.

Таким образом, вы получаете определенный оплаченный запас по времени, а клиент получает "почти" фиксированную цену и ощущение контроля за происходящим. Не забываем про оптимистичную оценку, редко, но все же удается вложиться в это время, и заработать немного больше денег. Если вы не смогли уложится в 20% запаса, то надо садиться и разбираться с проблемами в вашей компании. Возможно, имеет смысл несколько освежить личный состав и оптимизировать рабочие процессы.

Body leasing, etc. - Сдача групп разработчиков внаем

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

Стойте, не убегайте, я ведь еще не закончил!!! :)  Для тех, кто вернулся и решил узнать где же тут "ложка дегтя", продолжу. "Ложка дегтя" лежит прямо перед вами: клиенты невнимательно читают контракты! А те, кто читает внимательно, все равно не могут и не хотят понять стремление поставщика услуг снять с себя ответственность за свою работу. Поэтому ответственность всегда лежит на вас, даже если вам удалось написать в контракте обратное. Но отставим шутки в сторону.

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

1. Заказчик дает вам спецификацию на группу сотрудников, которая включает в себя описание предыдущего опыта кандидатов, коммуникационных и личностных характеристик, владение иностранными языками, владение конкретными технологиями и инструментами.
2. Вы обсуждаете с заказчиком состав группы: сколько разработчиков, уровень разработчиков (SE, SSE, LSE), количество тестеров, загрузку ПМа.
3. Собираете эту группу в оговоренные сроки, организуете рабочие места, технику, интернет, прочее.
4. Группа приступает к работе,а вы к выставлению счетов.

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

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

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

Что важно для клиента, подписавшего контракт на Staff augmentation (body leasing, Offshore Data Center, Offshore Development Team, etc, etc, etc…):

• Зафиксированная цена на группу сотрудников на как можно более длительный срок.
• Цена должна быть значительно ниже чем при проектной работе, так как вы, как поставщик услуг, действительно не несете почти никаких рисков.
• Возможность контролировать и влиять на процессы и результаты работы своей группы.
• Минимальная текучка кадров в группе.
• Возможность лично отбирать людей себе в группу
• Отсутствие языковых барьеров. Если вы предложили клиенту гениев, которые говорят только по русски (такие еще встречаются в наше время) то никакой пользы он из них не извлечет. Работа через переводчика увеличивает вашу себестоимость и снижает количество эффективно передаваемой информации.
• Возможность в любой момент лично приехать и посмотреть как идут дела, пригласить к себе в офис сотрудников своей группы. Кстати, иногда наличие прямых авиаперелетов является серьезным фактором в принятии решения о том, куда, в какую страну и город клиент согласится аутсорсить.
• Информационная безопасность. Работая с удаленной командой, клиент зачастую передает ей большое количество в той или иной мере конфиденциальной информации и хочет, что бы эта информация, не была доступна никому за пределами его группы.

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

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

Теперь о том, что нужно для того, чтобы правильно организовать работу:

• Во первых, нужен заказчик, которому действительно нужно "расширение" его собственного ИТ штата за счет вашей группы. У такого заказчика, соответственно, должен быть свой штат ИТ сотрудников, большой, неограниченный во времени объем работы для вашей группы, а также очень позитивное отношение к работе с аутсорсинговым партнером. Все остальное: процессы, инфраструктура, умение работать с оффшорным подразделением, дело важное но наживное.
• Во вторых, нужен project enabler, человек, который возьмет на себя ответственность за качественный "запуск" сотрудничества с клиентом. Под качественным запуском я понимаю: выяснение состояния дел в компании клиента и ее ИТ отдела; выяснения потребностей клиента (зачем ему оффшорная группа?); обсуждения с руководством компании (вами) стратегии сотрудничества с клиентом; составление спецификации на группу людей; руководство и сдача пилотного проекта; "продажа" клиенту идеи выделенной оффшорной группы; разработка и описание процессов совместной работы с клиентом; обсуждение необходимого инструментария; участие в подборе сотрудников в группу; супервайзинг группы с постепенным выходом и передачей полномочий руководителю этой группы с вашей стороны. Полного выхода из такой группы не бывает, в течении всей "жизни" группы ее надо супервайзить, это показывает клиенту, что вам небезразличен результат работы группы, уменьшает фактор риска в "тонких" местах такого сотрудничества: проблемы связанные с различием менталитетов у них и у нас, ошибки в коммуникации, правильность решений руководителя группы, соблюдение описанных процессов, все что угодно. Короче: мы в ответственности за тех, кого приручили...
• В третьих, нужно ваше личное участие. Вы устанавливаете долгосрочное сотрудничество, клиенту важно знать, что за человек руководит организацией в которую он собрался вложить деньги. Вам так же важно знать, что за человек ваш клиент. Теплые личные отношения всегда скорее помогают чем мешают ведению бизнеса. Искренне интересуйтесь своими клиентами, делайте им мелкие приятные уступки, поздавляйте с днем рожденья, интересуйтесь их детьми.
• В четвертых, нужен сильный отдел кадров и рекрутинга. Без него вы не сможете быстро и качественно искать людей. Не скупитесь на рекрутеров и менеджеров по персоналу.
• В пятых, нужно проверить и перепроверить что за бизнес у вашего клиента. Очень часто клиент с радостью соглашается купить оффшорную группу разработчиков, так как это значительно дешевле работы по модели Time&Material (20% - 25%), хотя на деле ему нужна именно проектная группа. Меньшую цену клиент воспринимает как скидку за объем (у него може быть "длинный" проект) и ждет от вас "проектной" ответственности. Как правило, такое непонимание является следствием ошибки на стадии продажи и может привести к серьезному конфликту с клиентом через 6 - 12 месяцев. Поехали дальше.

BOT - Build, Operate, Transfer

Эта модель означает, что вы заключаете контракт, согласно которому обязуетесь зарегистрировать компанию, арендовать офис, набрать сотрудников, запустить все необходимые процессы и, через определенное время, передать компанию заказчику. При этом вы можете оставаться совладельцем, можете остаться при своей должности в этой компании, можете просто получить деньги и заняться чем нибудь еще. Выгоды налицо - вы создаете компанию под уже существующий бизнес вашего клиента за деньги вашего клиента. Если хорошо составите контракт, то сможете получить определенную самостоятельность в бизнес операциях после передачи компании заказчику, главное, чтобы они укладывались в рамки бизнеса вашего заказчика. Заказчик (согласно мнению ряда западных консультантов) получает в свое распоряжение так называемый captive offshore development subsidiary что дает ему:

• Бо́льшую экономию
• Бо́льший контроль за операциями
• Меньшую текучку кадров

И знаете что? Многие верят в эту сказку!

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

• http://www.expresscomputeronline.com/20061016/technology02.shtml
• http://whitepapers.techrepublic.com.com/abstract.aspx?docid=153503

Ключевые слова для поиска информации:  BOT IT, captive development center .