Экономичная стратегия проектов по заказной разработке

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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