Тема 7. Управление финансированием и капиталовложениями в сфере информатизации (стр. 4 )

планирование (30); сбор данных (50); анализ (20); адаптация.

Зачастую 2 первых этапа объединяют в один. Ниже представлены основные действия в ходе проведения бенчмаркинга.

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

Рисунок 4- Процесс бенчмаркинга

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

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

Применительно к этапу планирования инвестиций в ИТ и оценки возможных выгод от их использования benchmarking мало что дает, так как предполагает сравнение собственных фактических данных с таковыми у целевых групп/компаний, но он ничего не говорит о том, как эти результаты достигались в каждом конкретном случае. Benchmarking подразумевает регулярную методическую работу по сбору и анализу данных, которые четко определены и систематизированы. Существует ряд значительных препятствий на пути практического использования данного подхода в российских условиях. Во-первых, прежде, чем сравнивать какие-либо показатели, компания должна определить их у себя, используя другие методики. Во-вторых, для целей сравнения компания должна иметь аналогичные и достоверные данные по другим компаниям (отраслям). Учитывая российскую специфику, такая практика представляется трудновыполнимой: вряд ли удастся достать достоверные показатели. И даже не по причине, что они тщательно оберегаются, а по причине того, что на данный (обозреваемый) момент времени их может просто не существовать в природе.

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

Метод IT Scorecard  (Система сбалансированных показателей для ИТ)

Его идея состоит в том, чтобы адаптировать подход BSC для ИТ-отдела. Партнер IT Performance Management Group (ITPMG) М. Биттерман в бытность свою консультантом в Gartner Group потратил 1,5 года, пытаясь продать систему оценки ИТ на основе BS своим клиентам. За это время удалось продать лишь одну. По словам Биттермана не все элементы BS применимы в случае оценки ИТ. Например, знание и рост. BS требует наличия «стратегической карты», но ИТ-организации, по большей части, хотят они того или нет, являются тактическими организациями. В результате ITPMG стала предлагать клиентам для оценки ИТ-решений собственную оценочную ведомость (ITPMG Scorecard). Биттерман заменил четыре «показателя» BS четырьмя соответствующими:

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

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

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

Вероятностные методы

Вероятностные методы оценки экономического эффекта от ИТ-проекта:

прикладная информационная экономика (Applied Information Economics) справедливая цена опционов (Real Options Valuation, ROV). EVS (обеспеченная экономическая стоимость) Статистические методы

Real Options Valuations (Метод справедливой цены опциона)

Подход к оценке финансовых опционов был разработан в 70-ых годах XX в. Ф. Блэком, М. Шоулзом и Р. Мертоном и получил название модели Блэка-Шоулза. Но, как и в случае с другими моделями, потребовалось время, прежде чем модель Блэка-Шоулза была адаптирована и стала применяться для оценки инвестиционных проектов, связанных с основной деятельностью. Метод сам по себе достаточно труден (за его разработку недавно была получена Нобелевская премия). Рассмотрим вариант, адаптированный к нуждам ИТ. К настоящему времени метод оценки реальных опционов завоевывает все большую популярность, оттесняя на задний план такие традиционные методики, как NPV, дерево решений.

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

Например, мы имеем два ИТ-проекта. У одного стоимость поддержки решения четко расписана по годам, зафиксирована в контракте на поддержку с поставщиком соответствующих услуг, и мы не можем ее уменьшить в ближайшие несколько лет. А у второго проекта нет зафиксированной стоимости поддержки, и есть вероятность, что через какое-то время он станет менее критичен для компании. Если так, то нам бы хотелось снизить затраты на его поддержку. Можно это сделать или нет? Это как раз и есть фактор управляемости, по которому и происходит оценка эффекта по методу ROV. Аналогично мы анализируем каждый ИТ-проект по четырем оставшимся параметрам. Естественно, у каждой компании свои критерий и шкала оценки степени влияния на эти параметры проекта. Здесь какие-то общие рекомендации дать невозможно.

Следует сказать, что основным преимуществом метода оценки реальных опционов по сравнению с традиционными методами является то, что он дает менеджерам возможность более гибко подходить к реализации проектов в зависимости от уровня риска. При этом данный подход объединяет в себе все прочие преимущества, присущие финансовым методам. Метод NPV требует сделать разовое решение по принципу «все или ничего» на основе первоначально установленного уровня риска (ставки дисконтирования). Но очевидно, что со временем меняются условия окружающей среды (процентная ставка, цены и пр.). В большинстве случаев невозможно предсказать, какими будут эти показатели через тот или иной промежуток времени (чем дальше в будущее мы будем заглядывать, тем ниже будет вероятность, что мы сделали правильную оценку). Метод оценки реальных опционов подходит к проблеме с другой стороны. Раз невозможно сразу определить с высокой степенью вероятности все необходимые показатели, следует принять эту неопределенность как данность и постараться уменьшить ее влияние на принимаемые решения.

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

AIE (Applied Information Economics ) - Метод прикладной информационной экономики

Эту модель предлагает компания HubbardRoss, LLC (разработчик методики Д. Хаббард). Как и ряд методик, специально разработанных для оценки инвестиций в ИТ, данная разработка является методикой «все в одном». Объединяя в себе традиционные финансовые методики, она дополняет их концепциями, заимствованными из экономической теории, статистики, теории информации, и ряда других дисциплин. По мнению консультантов Hubbard Ross такой подход позволяет учесть и оценить риски, связанные с тем или иным проектом, установить приоритеты среди проектов и количественно оценить их реальную экономическую выгоду (в данном случае консультанты стоят на позиции, что «измеримо все»).

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

Используя AIE, консультанты Hubbard Ross обещают определить действительную экономическую стоимость инвестиций в ИТ, улучшая точность расчетных показателей, полученных с использованием традиционных финансовых метрик. Это достигается за счет уменьшения неопределенности относительно: 1) затрат; 2) выгод (также нематериальных); 3) риска инвестиций.

Эксперты признают, что AIE одна из наиболее нагруженных расчетами методик. Кроме того, использование AIE (как и ряда других) осложняется тем, что она является ноу-хау консультационной компании, следовательно, компания, пожелавшая использовать AIE для оценки своих ИТ-проектов, должна обратиться к разработчику или компаниям, имеющим лицензию на право использования AIE.

EVS (Economic Value Sourced, обеспеченная экономическая стоимость)

Подход EVS для оценки и управления инвестициями в ИТ-проекты предлагает компания Meta Group.

Согласно идее, заложенной в модель EVS, существует только четыре способа, с помощью которых ИТ могут создавать дополнительную стоимость:

увеличение дохода; увеличение производительности; уменьшение временного цикла; уменьшение риска.

Можно сказать, что модель EVS, как и ряд других моделей, представляет собой надстройку к традиционным методикам, но для более корректной оценки она предполагает расчет стоимости рисков и времени. Это необходимо, чтобы понять вклад 3 и 4 пунктов, указанных выше. В этом модель EVS концептуально схожа с такими моделями, как модель оценки реальных опционов и AIE. Поэтому в нашей классификации она отнесена к «вероятностным» методикам.

Статистический метод

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

Таблица 2 - Среднестатистические мировые показатели эффекта от внедрения ИТ-систем

Показатель	Средние внедрения	Лучшие внедрения
Снижение количества задержек при поставках продукции заказчикам	90%	97%
Уменьшение неснижаемых остатков на складах материалов	30%	45%
Повышение оборачиваемости запасов	20%	30%
Сокращение НЗП	17%	25%
Повышение оборачиваемости средств в области реализации готовой продукции	12%	21%
Повышение производительности работников и оборудования	10%	17%
Снижение затрат на закупку материалов и комплектующих	4%	6%

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

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