Ранее мы рассмотрели основные критерии, по которым производится выбор модели экономической оценки информационных систем, и сравнили основные группы моделей с точки зрения этих критериев.

Ранее мы рассмотрели основные критерии, по которым производится выбор модели экономической оценки информационных систем, и сравнили основные группы моделей с точки зрения этих критериев. Проанализируем подробнее модель TVO (Total Value of Opportunities, cовокупная ценность возможностей). Она относится к группе качественных моделей, наиболее полно отражающих экономический результат внедрения информационных систем. Далее, эта модель специально разработана для оценки ИТ-проектов. Несомненное ее достоинство — высокая гибкость, позволяющая приспособить ее к различному уровню управления в организации и к различной относительной значимости финансовых и нефинансовых факторов.

В модели TVO оценка ИТ-проекта ведется по пяти направлениям, или «столпам» (pillars): соответствие стратегии, воздействие на бизнес-процессы, непосредственная окупаемость, архитектура, риск.

Соответствие стратегии (Strategic Аlignment) — степень, в которой рассматриваемый ИТ-проект способствует достижению стратегических целей организации. Базовая схема анализа соответствия стратегии включает в себя оценку текущих значений показателей, описывающих стратегию, оценку их целевых значений с точки зрения стратегии и оценку их целевых значений в рассматриваемом проекте. Предполагается, что соответствующие показатели известны и надлежащим образом утверждены.

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

Воздействие на бизнес-процессы (Business Рrocesses Iimpact) — влияние ИТ-проекта на результативность и эффективность бизнес-процесса или процессов. Под результативностью мы понимаем предельные возможности данного процесса — время выполнения, процент качественной продукции, необходимый уровень запасов и т. д. Под эффективностью — соотношение результата и затрат: затраты на единицу продукции, выход продукции на единицу сырья, выработку на одного занятого и т. д. Эти две группы показателей связаны между собой, но не идентичны.

Приведем пример. Крупная российская компания — Заволжский моторный завод — в настоящее время переходит к модели организации производства JIT (Just in Time, точно в срок) [3]. В рамках этой программы удалось достичь:

  • сокращения страхового запаса на сборочном конвейере с трех дней до двух часов;
  • сокращения оборота средств предприятия с 14 до 8 дней;
  • повышения коэффициента использования оборудования с 0,4 до 0,75.

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

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

Интересные примеры перехода от натуральных измерителей результата к денежным приводятся в [4]. Рассмотрим лишь один из них — определение чистого дохода от снижения потерь из-за недостоверности данных и некачественного планирования доходов по продаже и сдаче в аренду ОС. Схема определения финансового результата приведена на рис. 1.

Итоговая оценка дохода строится как на данных финансового учета (статьи A-D), так и на оценочных величинах. Очень важно, чтобы оценочные величины и результаты расчета согласовывались с бизнес-заказчиком и финансовой службой организации, как это и было сделано в данном случае.

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

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

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

О соответствии ИТ-решения существующей архитектуре предприятия можно судить по следующим показателям:

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

В качестве примера приведем ICQ — хорошо известное средство коммуникации. Благодаря широкой известности, простоте и удобству использования, ICQ пользуется популярностью у бизнес-заказчиков. Вместе с тем серьезный недостаток

ICQ — отсутствие защиты передаваемых данных. Поэтому в тех случаях, когда требования к защите передаваемых данных значимы, ICQ должна быть отвергнута именно по архитектурным соображениям.

Наконец, риск — пятый и последний столп экономической оценки ИТ-проекта. Под риском здесь понимается вероятность наступления событий, неблагоприятных для достижения цели ИТ-проекта и/или соблюдения установленных сроков и бюджета. В случае ИТ-проектов эта вероятность весьма велика. Так, в [5] приводятся следующие данные по проектам внедрения ERP-систем:

  • 10% проектов не доводятся до конца;
  • около 30% проектов заканчиваются с превышением сроков и бюджета более чем на треть;
  • около 50% проектов завершаются без существенных превышений сроков и бюджета, но при этом не соответствуют ожиданиям заказчика;
  • около 5% проектов завершаются в срок, в рамках бюджета и при этом обеспечивают полную функциональность.

Таким образом, уровень риска ИТ-проекта — критически важная экономическая характеристика. Вот несколько факторов, оказывающих влияние на степень риска:

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

Приведем пример оценки риска для конкретного ИТ-проекта. Несколько лет тому назад для одного из банков была разработана система управленческой отчетности. Банк в тот момент не имел филиалов, соответствующим образом была спроектирована и система. К тому моменту, когда система была готова и проходила тестирование, руководство банка приняло решение о приобретении первого филиала. В результате система подверглась радикальной переделке, а сроки и бюджет проекта были значительно нарушены (на 120% сроки, на 150% — бюджет). В данном случае ключевым риском оказалась неполная информация об организационных рамках проекта.

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

TVO и другие модели оценки: преимущества

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

Более развитый управленческий учет, использующий, например, модель затрат по видам деятельности (Activities Based Costing, ABC), позволяет определять баллы на основании количественных показателей. Например, для бизнес-процесса в этом случае могут быть известны время выполнения, процент ошибок и т. д. В области архитектуры могут быть оценены уровень безопасности, соответствие стандартным платформам (например, процент стандартных решений среди использованных в проекте) и т. д. Количественную оценку получают и некоторые риски — масштаб проекта, длительность проекта, широта организационных рамок и др. Эти показатели оцениваются сравнительно легко и могут быть получены при любом уровне управленческого учета. Однако количественные оценки для одного-единственного «столпа» мало влияют на общую процедуру оценки.

В ряде случаев можно посчитать и непосредственную окупаемость, используя, например, подходы, изложенные в [4]. Переход от количественных показателей к балльным оценкам можно осуществлять на основе стандартных шкал. Скажем, для непосредственной окупаемости шкала может выглядеть так:

  • < 0% — 1 балл;
  • 0-5% — 2 балла;
  • 5-15% — 3 балла;
  • 15-30% — 4 балла;
  • свыше 30% — 5 баллов.

Аналогичные шкалы можно ввести и для других количественных показателей.

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

Таким образом, модель TVO можно применять при любом состоянии управленческого учета в организации. При минимальном развитии последнего она позволяет структурировать обсуждение целесообразности проекта. Более развитый управленческий учет, включающий в себя модель ABC и др., позволяет перейти от качественных оценок к количественным показателям. Наконец, модель BSC обеспечивает выбор самих показателей в строгом соответствии с целями компании.

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

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

Проблемы модели TVO

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

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

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

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

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

* * *

Итак, модель TVO учитывает все составляющие экономического результата ИТ-проекта:

  • соответствие стратегии;
  • воздействие на бизнес-процессы;
  • непосредственная окупаемость;
  • архитектура;
  • риск.

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

Кирилл Скрипкин — директор Департамента ИТ-планирования и взаимодействия с бизнесом в СУАЛ-ХОЛДИНГ (Сибирско-Уральская алюминиевая компания), k.skripkin@sual.com