Экономичная стратегия проектов по заказной разработке — различия между версиями

Версия 17:27, 27 апреля 2010

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

• «Экономичная стратегия проектов по заказной разработке»^[1]

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

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

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

Рис.1. «Рычаг» проекта по Д. Майстеру

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

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

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

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

Структура стоимости ИТ-проекта

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

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

Для трех типов ИТ-проектов в приведенной классификации структура цены будет существенно различной. Для проектов типа «процедуры» характерное соотношение между стоимостью прав и стоимостью оплачиваемых часов распределяется в диапазоне от 1:0 (оптимистическая оценка — достаточно только покупки лицензии) до 1:1 (пессимистическая оценка — потребуется внедрение).

Для проектов типа «седина» это соотношение колеблется от 1:1 (оптимистический вариант) до 1:5 (пессимистический — стоимость лицензии составит только 20 % от стоимости внедрения).

Для проектов типа «мозги» соотношение стоимости лицензии к стоимости оплачиваемых часов еще далее сдвигается от соотношения 1:5 до практически исчезающей суммы стоимости лицензии на фоне стоимости работ по внедрению.

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

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

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

Формируя проектную команду из определенного числа специалистов каждой категории, исполнитель формулирует свою ценовую политику и сообщает потенциальным заказчикам на рынке, какой тип проекта он готов выполнять (рис. 2). Например, если разработчик выставляет агрессивные (низкие) ставки для специалистов высокой квалификации, то он пытается расширить «рычаг» проекта и сделать его более процедурным. Устанавливая агрессивные ставки для специалистов низкой квалификации, разработчик уменьшает рычаг и сдвигает проект в область заказной разработки малотиражного или уникального ПО.

Рис.2. Ценовая политика исполнителя — влияние на «рычаг»

Для того, чтобы разобраться, на чем именно может экономить заказчик, остановимся подробнее на структуре цены ИТ-проекта с точки зрения исполнителя (рис. 3). На нижней шкале представлены традиционные компоненты цены: оплата труда сотрудников, накладные расходы, прибыль. Оплата труда, в свою очередь, складывается из оплачиваемых часов и часов на развитие. Эту вторую составляющую заказчики склонны не принимать во внимание, однако именно эти часы обеспечивают будущее не только компании-разработчику, но и тому программному продукту, который он поставит и внедрит у заказчика. Они складываются из обучения собственного персонала, развития собственных технологий, неоплачиваемой работы с клиентами и т. п. Пропорции цен на рис. 3 соответствуют проектам типа «мозги» и «седина».

Рис.3. Структура ценообразования компании-исполнителя

Обратим внимание на то, что расхожая, так сказать, «бытовая» точка зрения заказчика берет в расчет оценки стоимости оплачиваемого часа только собственно время, потраченное на работы в его проекте — отрезок Н1 на рисунке. Тогда как для разработчика фактическая (реальная) его стоимость — отрезок Н2 — включает все расходы, необходимые для того, чтобы его компания не просто выживала на рынке, но и поддерживала постоянный потенциал развития.

Выбор экономичной стратегии

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

Метод 1

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

Метод 2

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

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

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

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

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

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

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

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

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

Ссылки

1. ↑ Журнал Intelligent Enterprise (Корпоративные системы),№ 20, 31 октября 2005, стр.40-43.