Затратные методы оценки ИТ системы Лебедева И.А.

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

Есть множество методов проведения такого анализа эффективности ИТ. Их можно условно разделить на три группы, различающиеся подходом к оценке проектов: классические методы оценки инвестиционных проектов, предполагающие определение таких показателей, как чистый приведенный доход (Net Present Value, NPV), внутренняя норма доходности (Internal Rate of Return, IRR), срок окупаемости (Payback), добавленная стоимость (Economic Value Added, EVA); метод реальных опционов (Real Option Valuation, ROV); затратные методы оценки, основным из которых является определение совокупной стоимости владения (Total Cost of Ownership, TCO) и его производные; комплексные методы оценки набора финансовых и нефинансовых показателей эффективности (Key Performance Indicators, KPI), например сбалансированная система показателей (Balanced Scorecard, BSC) Нортона и Каплана.

Методы каждой из групп обладают своими достоинствами и недостатками и имеют свои предпочтительные области применения. Суть затратных методов оценки состоит в определении совокупной стоимости владения (ТСО). К затратным методам оценки относят: котловой метод, метод функциональной точки, метод совокупной стоимости владения(ТСО). Рассмотрим каждый из методов подробнее.

Absorption Costing (Котловой метод) Основан на разнесении косвенных затрат по изготавливаемым продуктам. Он ровесник самого управленческого учета. Метод основан на определении соотношения объемов вложений в программное обеспечение, включая внедрение и сопровождение, с размерами предприятия и направлениями его бизнеса. Часто данное соотношение задается в виде максимально-допустимого объема вложений по отношению к годовому обороту компании, например не более 1% для небольших компаний и не более 3% для крупных. В России этот метод покрывает не менее 90% всех вычислений себестоимости. Методы разнесения общих затрат просты, но эмпиричны, поэтому неточны. Они оправданны лишь тогда, когда доля косвенных затрат в себестоимости невелика (10- 15%). Приведем зависимость структуры производственных и накладных расходов от уровня автоматизации производства.

Из приведенного выше рисунка видно, что с увеличением уровня автоматизации производства доля накладных расходов (постоянные издержки) в себестоимости изготавливаемой продукции значительно возрастает. Сегодня косвенные затраты в автоматизированных производствах составляют примерно 50-60%. Традиционные методы расчета затрат стали терять актуальность. С начала 1960-х годов изменения формы производства и ведения бизнеса привели к тому, что традиционный метод учета затрат стали называть «врагом номер один для производства» из-за их весьма сомнительной пользы.

Хотя «Котловой» метод и используется обычно для нужд налогового учета, но с точки зрения внутреннего управления неизбежно имеет серьезные недостатки, - это: недостаточно точная оценка издержек производства отдельного продукта; себестоимость не несет информацию для руководителей предприятия, необходимую для решения главного вопроса: «Что делать?».

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

Метод функциональной точки Анализ функциональных точек стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом (Alan Albrecht) в середине 70-х. Метод был впервые опубликован в 1979 году. Метод предназначен для оценки на основе логической модели объема программного продукта количеством функционала, востребованного заказчиком и поставляемого разработчиком. Несомненным достоинством метода является то, что измерения не зависят от технологической платформы, на которой будет разрабатываться продукт, и он обеспечивает единообразный подход к оценке всех проектов в компании.

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

При анализе методом функциональных точек надо выполнить следующую последовательность шагов (Рисунок 2 ): Определение типа оценки. Определение области оценки и границ продукта. Подсчет функциональных точек, связанных с данными. Подсчет функциональных точек, связанных с транзакциями. Определение суммарного количества не выровненных функциональных точек (UFP). Определение значения фактора выравнивания (FAV). Расчет количества выровненных функциональных точек (AFP).

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

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

Третий шаг. Границы продукта определяют: Что является «внешним» по отношению к оцениваемому продукту. Где располагается «граница системы», через которую проходят транзакции передаваемые или принимаемые продуктом, с точки зрения пользователя. Какие данные поддерживаются приложением, а какие внешние.

Подсчет функциональных точек Транзакция это элементарный неделимый замкнутый процесс, представляющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое. Определение суммарного количества не выровненных функциональных точек (UFP) Общий объем продукта в не выровненных функциональных точках (UFP) определяется путем суммирования по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ).

Определение значения фактора выравнивания (FAV) Помимо функциональных требований на продукт накладываются общесистемные требования, которые ограничивают разработчиков в выборе решения и увеличивают сложность разработки. Для учета этой сложности применяется фактор выравнивания (VAF). Значение фактора VAF зависит от 14 параметров, которые определяют системные характеристики продукта: 1. Обмен данными (0 продукт представляет собой автономное приложение; 5 продукт обменивается данными по более, чем одному телекоммуникационному протоколу). 2. Распределенная обработка данных (0 продукт не перемещает данные; 5 распределенная обработка данных выполняется несколькими компонентами системы). 3. Производительность (0 пользовательские требования по производительности не установлены; 5 время отклика сильно ограничено критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа. 4. Ограничения по аппаратным ресурсам (0 нет ограничений; 5 продукт целиком должен функционировать на определенном процессоре и не может быть распределен).

5.Транзакционная нагрузка (0 транзакций не много, без пиков; 5 число транзакций велико и неравномерно, требуются специальные решения и инструменты). 6.Интенсивность взаимодействия с пользователем (0 все транзакции обрабатываются в пакетном режиме; 5 более 30% транзакций интерактивные). 7.Эргономика (эффективность работы конечных пользователей) (0 нет специальных требований; 5 требования по эффективности очень жесткие). 8.Интенсивность изменения данных (ILF) пользователями (0 не требуются; 5 изменения интенсивные, жесткие требования по восстановлению). 9.Сложность обработки (0 обработка минимальна; 5 требования безопасности, логическая и математическая сложность, многопоточность). 10. Повторное использование (0 не требуется; 5 продукт разрабатывается как стандартный многоразовый компонент).

11. Удобство инсталляции (0 нет требований; 5 установка и обновление ПО производится автоматически). 12. Удобство администрирования (0 не требуется; 5 система автоматически самовосстанавливается). 13. Портируемость (0 продукт имеет только 1 инсталляцию на единственном процессоре; 5 система является распределенной и предполагает установку на различные «железо» и ОС). 14. Гибкость (0 не требуется; 5 гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме).

14 системных параметров (degree of influence, DI) оцениваются по шкале от 0 до 5. Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием: TDI = DI Расчет значения фактора выравнивания производится по формуле VAF = (TDI *0.01) Например, если, каждый из 14 системных параметров получил оценку 3, то их суммарный эффект составит TDI = 3 * 14 = 42. В этом случае значение фактора выравнивания будет: VAF = (42 * 0.01) = 1.07

Расчет количества выровненных функциональных точек (AFP) Дальнейшая оценка в выровненных функциональных точках зависит от типа оценки. Начальное оценка количества выровненных функциональных точек для программного приложения определяется по следующей формуле: AFP = UFP * VAF. Она учитывает только новую функциональность, которая реализуется в продукте. Проект разработки продукта оценивается в DFP (development functional point) по формуле: DFP = (UFP + CFP) * VAF, где CFP (conversion functional point) функциональные точки, подсчитанные для дополнительной функциональности, которая потребуется при установке продукта, например, миграции данных.

Проект доработки и совершенствования продукта оценивается в EFP (enhancement functional point) по формуле: EFP = (ADD + CHGA + CFP) * VAFA + (DEL* VAFB), где ADD функциональные точки для добавленной функциональности; CHGA функциональные точки для измененных функций, рассчитанные после модификации; VAFA величина фактора выравнивания рассчитанного после завершения проекта; DEL объем удаленной функциональности; VAFB величина фактора выравнивания рассчитанного до начала проекта. Суммарное влияние процедуры выравнивания лежит в пределах ±35% относительно объема рассчитанного в UFP.

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

Продолжение следует!