Фактор времени и экономическая эффективность

Программа конференции

Введение

Каждый IT-менеджер в ходе своей работы сталкивается со множеством ситуаций выбора между различными подходами к решению проблем предприятия. Среди них:

• Выбор объема и направления автоматизации
• Выбор между адаптацией готовой системы и построением системы на заказ
• Выбор между внедрением системы силами собственной организации и внешними консультантами

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

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

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

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

                                                                                                                               (1)

где

Э — экономический эффект;

Д — интегральный результат внедрения системы;

З — интегральные затраты на разработку, внедрение и эксплуатацию системы

Интегральные затраты на систему могут быть полностью известны только после завершения проекта. В любой момент до завершения проекта интегральные затраты могут быть только оценены. Соответственно, в любой момент проекта

  приведенные к начальному моменту проекта интегральные затраты могут быть оценены как

                                                                                (2)

где

  — оценка интегральных затрат проекта в момент

;

E — норма дисконтирования;

  — дисконтированная сумма фактических интегральных затрат проекта к моменту

;

T — период жизненного цикла системы;

— оценка интегральных затрат на проект в периоде t;

Аналогично, в любой момент проекта

, приведенный к начальному моменту проекта интегральный результат проекта можно представить как

,                                               (3)

где

  — оценка интегрального результата проекта в момент

;

E — норма дисконтирования;

  — дисконтированная сумма фактического интегрального результата проекта к моменту

;

T — период жизненного цикла системы;

— плановые результаты проекта в периоде t;

— оценка потерь, связанных с эксплуатационными рисками системы в периоде t.

В начальный момент времени в формулах (2) и (3)

, так что (1) вырождается в

                                                                          (4)

Правильно применяя дисконтирование к распределению финансовых ресурсов по стадиям жизненного цикла ПО и вариантам их реализации можно получить значимые и иногда парадоксальные ответы на вышеперечисленные вопросы.

Пример 1. Как тестировать?

Применим вышеизложенное, например, к выбору способа тестирования программного обеспечения. Этот пример, как и остальные в данном докладе, несколько условен, но одновременно и очень жизненен, поскольку достаточно точно отражает один из проектов, которым доводилось руководить докладчику в 1997-1998 годах. Пусть разрабатывается заказной проект стоимостью С со сроком разработки T=12 месяцев, командой разработчиков N=12 человек со средними затратами на человека S. Перед менеджером проекта стоит вопрос: создать группу тестирования из NT=N/4 человек (с затратами в Q=1,5 раза меньше, чем у программистов) и исправлять ошибки по ходу разработки (вариант А), или поручить тестирование программистам, а не найденные ими ошибки найти и исправить на стадии опытной эксплуатации (вариант Б)? Пусть программисты тратят на дополнительное тестирование ТП=1/5 своего времени, а эффективность их тестирования такая же. Из–за затрат времени на тестирование программистами разработка завершится пропорционально позже. Предположим, что разработка оплачивается заказчиком на f=30% после опытной эксплуатации. При каких нормах дисконтирования какой способ тестирования эффективен?

При дальнейшем рассмотрении исключим затраты и эффекты, не относящиеся непосредственно к нашему предмету.

Интегральные дисконтированные затраты в варианте А составят

Приведенный к начальному моменту проекта интегральный результат в варианте А

В варианте Б во время проекта программистами на тестирование затрачивается доля ТП их времени, поэтому длительность проекта составит Т/(1-ТП).

Интегральные дисконтированные затраты в варианте Б составят

Приведенный к начальному моменту проекта интегральный результат в варианте Б

Разница между эффектами проекта в случаях А и Б составит

Зафиксируем все параметры формулы, кроме чисто экономических – E и

  (отношение стоимости последнего этапа к фонду зарплаты разработчиков), и построим график, разделяющий в этих координатах области эффективности вариантов А и Б:

                                (5)

Рисунок 1 ­– Области предпочтения вариантов А и B, ТП=0.2

Из графика парадоксальный вывод: упорядоченное тестирование (вариант А) выгодно, если норма дисконтирования (часто принимаемая равной ставке рефинансирования Центробанка) меньше (для данного проекта) примерно 87 процентов годовых, почти независимо от фонда зарплаты. Качественно данная картина сохраняется для любого проекта.

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

Например, проект, о котором идет речь, выполнялся с мая 1997 по июнь 1998 года. Посмотрим на таблицу ставок рефинансирования ЦБ РФ:

Таблица 1 – Ставки рефинансирования ЦБ РФ  и НБУ

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

Вывод приложим не только к странам типа России и Украины. Интернет-бум 1998-2000 года также принес с собой относительно высокую реальную цену денег, с приоритетом раннего выхода на рынок.  Результат – невиданное доселе количество сырых продуктов и IT–услуг, выпущенное на рынок в этот период.

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

Построим график зависимости

  от E при ТП = 1/20 (см. Рисунок 2):

Рисунок 2 – Области предпочтения вариантов А и B, ТП=0.05

Обратите внимание на масштаб по оси

! При всех разумных размерах фонда заработной платы необходимо тестирование. Из рисунка следующая мораль:

Мораль 2: тестирование всегда необходимо. Однако, если проект уже убыточен, то нет смысла нанимать новых людей.

Мораль 3: Если за завершение проекта выплачивается лишь малая часть его стоимости, тестировать смысла нет.

Пример 2. Как внедрять?

Рассмотрим аналогичный пример на стороне заказчика. Пусть надо внедрить, например, CRM-систему стоимостью C в банке. Выбор состоит между внедрением системы силами собственной организации (вариант 2) и внедрением системы внешними консультантами (вариант 1). Пусть для внедрения требуется N = 4 человека на TI = 4 месяца. Пусть ожидается, что система будет приносить в среднем Iв течение T = 48 месяцев с момента принятия решения о внедрении. При использовании консультантов придется платить по SK = 4000 US$ за человекомесяц. Предположим, что оплата производится по половине в начале и в конце проекта. Стоимость собственных специалистов, с учетом налогового бремени и накладных расходов, составляет QS = 0.5 стоимости консультантов. Предположим, что эффективность собственных специалистов будет в KE = 1.5 раза меньше, чем у консультантов. При внедрении собственными силами персонал надо нанимать. На это уйдет ТН = 2 месяца, а агентству придется заплатить HF= 1/10 годовой зарплаты нанимаемых специалистов. После того, как проект по внедрению закончен, эти люди еще ТУ = 3 месяца промаются, и уйдут от скуки в другое место.

Опуская общую для обоих вариантов составляющую (в частности, стоимость самой системы), получаем дисконтированные затраты в варианте 1

а в варианте 2

Приведенный к начальному моменту проекта интегральный результат в варианте 1

,

в варианте 2

Разница между эффектами проекта в случаях 1 и 2 составит

Зафиксируем все параметры формулы, кроме чисто экономических – E и

  (отношение ежемесячного экономического эффекта к фонду оплаты консультантов), и выразим одно через другое:

С другой стороны экономический эффект внедрения силами консультантов определяется соотношением

Принимая для простоты

, получаем

,

откуда

Построим оба графика на одном рисунке:

Рисунок 3  – Области предпочтения вариантов 1 и 2 и область эффективности системы

На рисунке квадратиками заштрихована область эффективности внедрения системы, розовым цветом окрашена область предпочтения варианта 2, зеленым – область предпочтения варианта 1. Из анализа графиков получаем следующие выводы:

Мораль 4. Если заказчик и так знает, что и как ему делать, консультанты не нужны. Значимость консультантов – в привнесении знания, что и как следует делать.

Мораль 5. Чем стабильнее экономика, тем выгодней использование консультантов.

Мораль 6. Чем ниже стоимость продукта по отношению к стоимости услуги, тем выгоднее использование консультантов.

Как пример к последней морали приведу себя. Компания «Лаборатория НТР» распространяет ядро CRM-системы для малого и среднего бизнеса NTR Bcom бесплатно, в открытых кодах.

Версия для печати