Список факторов, которые помогают снизить ССВ.

Факторы, влияющие на уменьшение стоимости владения:

· Наличие автоматического управления рабочими местами и программы инвентаризации системы.

· Наличие встроенной диагностики вирусов на клиентских местах и серверах.

· Поддержка любой системой средств сетевого управления.

· Наличие централизованной службы помощи, располагающей базой знаний по возможным проблемам.

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

· Встроенная система обнаружения ошибок, предназначенная для отслеживания и предупреждения незапланированных простоев.

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

· Стандартизированные аппаратные и программные компоненты рабочих мест (минимально 80% от общего числа пользователей).

· Имеется система защиты жизненно важных данных и план максимально быстрого их восстановления.

· Централизованная закупка идентичных моделей техники одного производителя.

· Система мониторинга и отслеживания изменений конфигурации рабочих мест.

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

· Регулярно исследуются затратные компоненты стоимости владения и определяются критические пункты в инвестиционной программе.

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

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

· Наличие мотивации у административного персонала для предоставления высокого уровня сервиса.

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

Например, Пол Страссманн сообщил, что, анализируя ССВ для одной из компьютерных компаний, он получил следующие не слишком утешительные данные. Среднее время простоя рабочих мест пользователей - 1,6 часа в месяц. Суммарное время при добавлении серверов и сетевого оборудования возросло до неприличной цифры в 2,8 часа в месяц. И это при том, что рекомендованная величина составляет всего 0,8 часа в месяц, а предельно допустимая - 3,2 часа.

Вопросы:

1. Перечислите расширения и модификации модели ССВ.

2. ССВ информационной инфраструк­туры предприятия.

3. Как классифицируются рабочие места предприятия в модели ССВ?

4. Назовите особенности применения модели ССВ в условиях России.

5. В чем заключается проблема выбора объекта затрат в модели ССВ?

Лекция 7: Качественные методы оценки эффективности ИТ

Цель лекции:

Изучение особенностей основных качественных методов оценки эффективности ИТ

Рассматриваемые вопросы:

TVO

CBA

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