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