Тема 3.5. Качественные методы оценки эффективности ИТ

TVO

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

Более развитый управленческий учет, использующий, например, модель затрат по видам деятельности (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 не является обязательным, так что последняя свободна от ограничений, присущих этим моделям.