|
Персональные инструменты |
|||
|
|
Экономичная стратегия проектов по заказной разработкеМатериал из CustisWikiВладимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».
Существуют различные типы проектов внедрения информационных систем и, соответственно, различная структура цены для каждого из них. И выбор оптимальной стратегии проектной работы, с одной стороны, экономит ресурсы заказчика, а с другой, обеспечивает развитие инновационных навыков компании-исполнителя. В книге известного консультанта в области управления Дэвида Майстера «Управление фирмой, оказывающей профессиональные услуги» приводится классификация, которой, на наш взгляд, вполне удовлетворяет и все разнообразие ИТ-проектов. В терминологии автора книги, это проекты типа «мозги», «седина» и «процедуры». Для того, чтобы объяснить логику подобного разделения необходимо ввести понятие «рычаг» проекта. В каждом ИТ-проекте задействуются исполнители различной квалификации. Состав проектной команды можно образно представить в виде треугольника, вершина которого — наиболее квалифицированные кадры фирмы-исполнителя, а основание — менее квалифицированный персонал. В терминологии Д. Майстера, «рычаг» проекта — это соотношение вовлеченного в работу старшего, среднего и младшего персонала фирмы-исполнителя. Для каждого из перечисленных типов проектов будет характерен свой тип «рычага» — один из видов треугольника, приведенных на рис. 1.
«Мозги» — это проекты, которые находятся на переднем фронте творчества и инноваций, по сути, это новые решения новых проблем. Проектные группы, которые работают в этой нише, позиционируют себя как «самые умные» и строятся по типу «остроугольного треугольника». В составе такой команды, как правило, несколько ведущих сотрудников компании, обладающих высокой квалификацией для решения нестандартных задач, и относительно мало младшего персонала, выполняющего небольшой объем рутинных операций — «рычаг» проекта невелик. Проекты типа «седина» — это оказание достаточно индивидуализированных услуг, которые однако базируются на основе знания и опыта в известной бизнес-практике. Лозунг такой команды: «мы имеем большой опыт в данной области, чтобы решать сложные задачи». Для такой команды характерно меньшее количество высококлассных специалистов — работа первопроходцев в данной предметной области уже кем-то выполнена. Типовой работы в таких проектах больше, соответственно и группа младшего персонала шире, чем в проектах типа «мозги». «Процедуры» — это решение известных (стандартных) задач типовыми способами. Поскольку в таких проектах используются хорошо обкатанные процедуры решения, лозунг проектной команды в данном случае: «мы знаем как решить вашу задачу и решим ее эффективно». Основная рабочая сила — младший персонал, выполняющий типовые операции-процедуры. Понятие «рычага» — ключевое для анализа экономики проектов и, соответственно, управление разными типами проектов и ценообразование в них совершенно различны. Структура стоимости ИТ-проектаПосмотрим, из каких сумм складывается стоимость ИТ-проекта. Без учета стоимости инфраструктуры компании-разработчика (примерно одинаковой для всех), она состоит из:
Для трех типов ИТ-проектов в приведенной классификации структура цены будет существенно различной. Для проектов типа «процедуры» характерное соотношение между стоимостью прав и стоимостью оплачиваемых часов распределяется в диапазоне от 1:0 (оптимистическая оценка — достаточно только покупки лицензии) до 1:1 (пессимистическая оценка — потребуется внедрение). Для проектов типа «седина» это соотношение колеблется от 1:1 (оптимистический вариант) до 1:5 (пессимистический — стоимость лицензии составит только 20 % от стоимости внедрения). Для проектов типа «мозги» соотношение стоимости лицензии к стоимости оплачиваемых часов еще далее сдвигается от соотношения 1:5 до практически исчезающей суммы стоимости лицензии на фоне стоимости работ по внедрению. Итак, при внедрении тиражных систем стоимость проекта может целиком состоять из стоимости лицензии — покупается «коробка». При внедрении малотиражного или уникального ПО доля стоимости лицензии уменьшается и основные расходы заказчика приходятся на консалтинг, внедрение, обучение (так называемые «оплачиваемые часы»). Очевидно, что заказная разработка ПО выполняется, как правило, для уникальных или малотиражных задач и относится к проектам первого и второго типа, для которых стоимость оплаченных часов существенно (в разы) превышает стоимость прав (лицензий). Таким образом, проектная стратегия заказчика, которая позволит существенно сократить стоимость проекта — это взять на себя как можно больше оплачиваемых часов. Рассмотрим подробнее, как складывается стоимость тех самых оплачиваемых часов, которые составляют львиную долю стоимости заказного ИТ-проекта по внедрению уникальных или малотиражных решений. Правила ценообразования внутри компании-исполнителя таковы, что диапазон стоимости оплаченного человека/часа обычно плавно изменяется от максимальных ставок для высококвалифицированного персонала до минимальных — для младших специалистов. Продавая проект заказчику, исполнитель упрощает схему тарификации, оставляя 2-3 категории исполнителей и соответственно 2-3 градации цены для оплачиваемых работ. Формируя проектную команду из определенного числа специалистов каждой категории, исполнитель формулирует свою ценовую политику и сообщает потенциальным заказчикам на рынке, какой тип проекта он готов выполнять (рис. 2). Например, если разработчик выставляет агрессивные (низкие) ставки для специалистов высокой квалификации, то он пытается расширить «рычаг» проекта и сделать его более процедурным. Устанавливая агрессивные ставки для специалистов низкой квалификации, разработчик уменьшает рычаг и сдвигает проект в область заказной разработки малотиражного или уникального ПО.
Для того, чтобы разобраться, на чем именно может экономить заказчик, остановимся подробнее на структуре цены ИТ-проекта с точки зрения исполнителя (рис. 3). На нижней шкале представлены традиционные компоненты цены: оплата труда сотрудников, накладные расходы, прибыль. Оплата труда, в свою очередь, складывается из оплачиваемых часов и часов на развитие. Эту вторую составляющую заказчики склонны не принимать во внимание, однако именно эти часы обеспечивают будущее не только компании-разработчику, но и тому программному продукту, который он поставит и внедрит у заказчика. Они складываются из обучения собственного персонала, развития собственных технологий, неоплачиваемой работы с клиентами и т. п. Пропорции цен на рис. 3 соответствуют проектам типа «мозги» и «седина».
Обратим внимание на то, что расхожая, так сказать, «бытовая» точка зрения заказчика берет в расчет оценки стоимости оплачиваемого часа только собственно время, потраченное на работы в его проекте — отрезок Н1 на рисунке. Тогда как для разработчика фактическая (реальная) его стоимость — отрезок Н2 — включает все расходы, необходимые для того, чтобы его компания не просто выживала на рынке, но и поддерживала постоянный потенциал развития. Выбор экономичной стратегииТеперь, опираясь на реальную структуру цены ИТ-проекта для компании-исполнителя, мы сможем точнее сформулировать экономичную стратегию ведения ИТ-проекта для компании-заказчика. Каким образом заказчик может взять на себя наибольшее количество оплачиваемых часов?
Рассмотрим метод создания «двойника». Заказчик берется за амбициозную задачу создать у себя проектную группу, отбирающую у исполнителя часть оплачиваемых работ и выдающую «на гора» новый интеллектуальный ИТ-продукт так же эффективно, как работающая на рынке проектная группа исполнителя. При этом проектная группа заказчика неизбежно останется вовлечена в текущий производственный процесс. Как показывает опыт, экономия в таких случаях оказывается весьма незначительной, если не вовсе мнимой. Даже если из бюджета ИТ-проекта удалено все, кроме непосредственных нужд заказчика, в соответствии с реалиями рынка труда ИТ-специалистов, фонд оплаты труда собственной высококвалифицированной проектной группы увеличится настолько, что не сможет существенно компенсировать уменьшения накладных расходов. В лучшем случае, экономия заказчика составит некоторую долю от прибыли, на которую рассчитывал исполнитель в конце проекта. Необходимо также отметить, что проектная группа типа «мозги» или «седина» требует совершенно иного типа управления, чем обычная операционная деятельность в производственных компаниях. В первом случае это демократичный стиль управления инновационными разработками, во втором —командный иерархический стиль руководства. Разница в стилях в рамках одной производственной структуры неизбежно приведет к тому, что высококлассными дорогостоящими специалистами будут «затыкаться» дыры в текущей оперативной деятельности: эффективность пострадает. Обратимся к методу «симбиоза». Он характеризуется тем, что заказчик создает у себя специальную группу для выполнения «процедурных» работ в проекте. Такая группа, как правило, хорошо вписывается в общую структуру управления предприятием и принимает на себя значительную долю работ по внедрению и обучению, то есть оплачиваемых часов «процедурного» типа. Прежде чем обсуждать достоинства проектной модели типа «симбиоз», представим как распределяются проекты разных типов по времени и по различным бизнес-практикам. В первый год-два все проекты автоматизации в новой предметной области будут относиться к типу «мозги». Со временем появляются проекты типа «седина» и только лет через пять — проекты типа «процедуры». Как правило, реальные сроки смены характерных для рынка типов проектов зависят от конкретной бизнес-области и совпадают со сроком жизни одной информационной системы — от начала ее разработки до морального устаревания. При этом проектная команда фирмы-разработчика может сама эволюционировать во времени и в практике освоения новых бизнес-областей. На наш взгляд, ИТ-компания имеет два альтернативных сценария развития. Первый состоит в смене типов проектов в рамках одной бизнес-практики, что потребует каждые 5-6 лет менять тип управления в компании. Второй, более амбициозный, состоит в регулярном освоении новых бизнес-практик при выполнении проектов одного, характерного для компании типа. Как правило, фирмы, специализирующиеся на создании заказного ПО, выбирают именно такой сценарий развития, двигаясь от одной бизнес-практики к другой и выполняя уникальные или малотиражные проекты типа «мозги» и «седина». Вернемся к проектным командам типа «симбиоз» и оценим их с точки зрения интересов сторон. В таком проекте заказчик формирует у себя проектную группу процедурного типа и берет на себя значительный объем оплачиваемых часов, сняв их с исполнителя. Как мы уже писали, проектная группа процедурного типа хорошо вписывается в обычную схему управления предприятием. И, что немаловажно, такая схема распределения работ полностью совпадает с интересами исполнителя, который боится увязнуть в рутине, разрабатывая уникальные или малотиражные системы. Естественно, что в этой схеме передача технологий и обучение специалистов заказчика технологиям разработчика — это необходимое условие успешного завершения проекта и условие долгой жизни информационной системы. В этой передаче кровно заинтересованы обе стороны, поскольку именно так они сохраняют взаимовыгодное разделение труда в проекте. Заказчику передаются технологии ведения проекта. Чтобы обеспечить развитие системы силами самого заказчика, его сотрудники обучаются технологиям описания предметной области в терминах формальной модели, лежащей в основе разработки. По тем же причинам разработчик заинтересован и в передаче заказчику базовых технологий. Реализуется все это в процессе совместного ведения проекта по адаптации системы, в процессе обучения и благодаря поставке заказчику всей документации вплоть до программ обучения персонала. Ссылки
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||