Эффективность информационных технологий

Определение типа предприятия

Перед тем как приступить к расчету, необходимо определить профиль предприятия. По классификации Interpose таких профилей насчитывается семнадцать. Кроме того, каждый профиль имеет три градации - малое предприятие, среднее и крупное. Например, среднее предприятие в финансовой отрасли имеет около 50 серверов и 2000 рабочих мест.

Типы предприятий

1. Банки.

2. Предприятия связи.

3. Производители вычислительной техники и электроники.

4. Дистрибьюторские компании.

5. Образовательные учреждения.

6. Предприятия энергетической промышленности.

7. Финансовые предприятия.

8. Правительственные учреждения.

9. Страховые фирмы.

10. Юридические фирмы.

11. Прочие производители.

12. Маркетинговые организации.

13. Медицинские организации.

14. Фирмы розничной торговли.

15. Сервисные организации.

16. Транспортные организации.

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

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

Анкетирование и анализ рабочих мест

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

Анкета, заполняемая администратором (табл. 6.1):

Оборудование	Всего	Куплено	Взято в аренду
Серверы	50	50	0
Клиентские места	3,120	3,120	0
Принтеры	613	613	0
Сетевые компоненты	212	180	32
Общее число устройств	3995	3963	32
Пользователей	2894

Кроме общих данных, собирается более детальная информация по оборудованию.

· Серверы: куплены или арендованы, их количество по категориям (серверы Windows NT, NetWare, Интернет/интранет-серверы, серверы уровня предприятия).

· Рабочие места: общее количество по клиентской ОС (DOS, Windows, Sun UNIX, UNIX, OS/2, MacOS, NC/тощие клиенты, терминалы. (К этому списку добавились палмтопы и хандхелды. Которые начали всерьез восприниматься как рабочее место, хотя и хилое).

· Принтеры: цветные, черно-белые.

· Сетевые компоненты: концентраторы, маршрутизаторы, мосты, коммутаторы, устройства хранения информации.

Средние по отрасли показатели (табл. 6. 2).

	Среднее по отрасли (С), ед.	Фактически на предприятии (Ф), ед.	Ф-С, ед.	Разница, %
Клиентских мест на каждого пользователя	1	1	0	0
Пользователей на каждый сервер	25	58	33	132
Пользователей на каждый принтер	15	5	- 10	- 69
Пользователей на FTE (Full Time Equivalent) каждого сетевого администратора	40	48	8	20
Пользователей на FTE службы поддержки	86	193	107	125

Сбор и анализ информации о прямых и косвенных расходах

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

Аппаратура и программное обеспечение

· Аппаратура

· Стоимость оборудования (приводится полная стоимость оборудования без учета амортизации).

· Амортизация оборудования (амортизационный срок берется в зависимости от типа техники).

· Апгрейд (включает все обновления и изменения в аппаратной конфигурации, как-то: замена жестких дисков, установка дополнительных устройств, например, компакт-дисков. В отдельную подкатегорию сведены процессорные апгрейды).

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

· Устройства хранения информации (различные массивы, Jukebox и т. д.).

· Периферия (принтеры, сканеры, плоттеры и т. д.).

· Сетевое оборудование (концентраторы, коммутаторы, сетевые карты [кроме встроенных в клиентские компьютеры], маршрутизаторы, мосты и т. д.).

· Программное обеспечение

· Операционные системы.

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

· Обслуживающие программы, в просторечии утилиты (диагностические, отладочные, программы-дефрагментаторы, криптографические, антивирусные и прочие).

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

Платежи

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

Управление

· Управление сетью

· Диагностирование и ремонт (сервис уровня 3).

· Управление и планирование трафика. Оптимизация производительности (выполняется системным администратором и включает в себя выявление узких мест в сети и принятие соответствующих мер).

· Администрирование пользователей (добавление, удаление, изменение прав).

· Поддержка операционных систем.

· Текущие регламентные работы (профилактика).

· Сервис уровня 2.

· Прочие работы по управлению сетью.

· Управление системой

· Изучение и планирование развития системы.

· Определение стоимости и закупка оборудования.

· Лицензирование и дистрибуция программного обеспечения.

· Управление имуществом (оборудованием).

· Управление приложениями.

· Контроль за секретностью и защита от вирусов.

· Конфигурирование и перенастройка оборудования.

· Установка оборудования.

· Прочие вопросы управления системой.

· Управление устройствами хранения данных

· Управление дисками и файлами.

· Планирование емкости устройств хранения данных.

· Управление доступом к данным.

· Архивирование и резервное копирование.

· Прогнозирование неисправностей и восстановление.

· Управление репозиторием.

· Остальные виды управления.

· Поддержка

· Оперативная работа.

· Помощь административного персонала.

· Нерегулярное обучение (административный состав).

· Поддержка производителя.

· Поддержка, осуществляемая сторонними организациями (аутсорсинг).

· Обучение административного персонала.

· Обучение конечного пользователя.

· Затраты на передвижения.

· Закупки.

· Прочие расходы на оперативную работу.

· Контракты на поставку.

· Контракты на поддержку.

· Учебные курсы и сертификация.

· Поддержка уровня 1 (ответы на вопросы пользователя, справки).

В табл. 6.3 приведены средние показатели по поддержке пользователя.

Средние показатели по поддержке пользователей (Табл.6.3.)

Типичные показатели поддержки пользователя	Среднее по промышленности
Среднее число вызовов каждый месяц (для приведенного выше числа пользователей)	11825
Среднее время задержки на каждый вызов, мин.	2,0
Средний процент вызовов, оказавшихся ложными	11%
Средняя продолжительность каждого вызова, мин.	9,0
Среднее время решения проблемы пользователя, мин.	15,9

Несомненный интерес представляет и десять причин наиболее частых вызовов административного персонала:

· Не могу печатать.

· Конфликты или несоответствие DLL.

· Забытый пароль.

· Проблемы с входом в систему.

· Проблемы с электронной почтой.

· Проблемы с удаленным доступом.

· Вопросы типа "как сделать:"

· Зависание или крах системы.

· Аппаратный сбой. Необходимость восстановления стертого файла.

Разработка

· Расходы на проектирование и разработку.

· Тестирование.

· Документация.

· Коммуникации

Расходы на конечного пользователя

· Ежегодные затраты административного персонала на конечного пользователя.

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

· Поддержка другими пользователями и самоподдержка.

· Внеплановое обучение (конечный пользователь).

· Разработка и написание скриптов конечным пользователем.

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

· Среднее время, затраченное на соединение, при использовании переносного компьютера.

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

· Техническая поддержка

· Среднее время вызовов сервисной службы за месяц (в минутах).

· Время простоя (в минутах).

· Средний процент ложных вызовов.

· Средняя продолжительность каждого вызова.

· Среднее время, в течение которого проблема разрешается сервисной службой (в часах).

· Средний процент вопросов, решенных после первого вызова.

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

· Типичный вид деятельности, прерванный на время оказания поддержки.

· Работа над другими заданиями, не относящимися к прямому выполнению служебных обязанностей.

· Время, затраченное на ожидание помощи.

· Чтение руководств и онлайновой справочной системы.

· Поддержка совместной работы.

· Среднее время, затраченное на чтение руководств и онлайновой справочной системы.

· Среднее время, затраченное на помощь коллегам.

· Среднее время, затраченное в месяц на futz-фактор.

· Простои

· Запланированные простои (в часах).

· Расходы на запланированные простои (в у. е.).

· Незапланированные простои (в часах).

· Расходы на незапланированные простои (в у. е.).

Расчет стоимости

Самое интересное начинается после того, как рутинный сбор исходных данных проведен, они введены в программу подсчета совокупной стоимости владения, и программа выполнила расчеты и выдала некий результат. После этого необходимо провести сравнение полученной информации со средними показателями по промышленности и определить критические моменты в затратах. Причем считается ССВ не только для одного пользователя, но и для серверов, коммуникационных устройств, принтеров. Естественно, что и Gartner Group, и Interpose имеют перечень рекомендаций по снижению стоимости владения техникой, которые приведены ниже.

6.2 Факторы, влияющие на величину совокупной стоимости владения

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

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

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

· Мобильные работники, часто находящиеся в поездках. Обычно работают с очень хрупкой и дорогой техникой. Требования к сервисному обслуживанию, поддержке и оборудованию также высоки. Стоимость времени простоя максимальна.

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

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

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

· Мобильные пользователи высокой пользовательской квалификации - 6,8%.

· Стационарные работники высокой пользовательской квалификации - 34,6%.

· Мобильные пользователи средней и низкой пользовательской квалификации - 4,4%.

· Остальные - стационарные работники средней и низкой квалификации.

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

Увеличение стоимости владения:

Человеческий фактор, вернее, действия конечного пользователя.

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

Ненормативные конфигурации PC.

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

Информация и приложения, жестко привязанные к определенным автоматизированным рабочим местам.

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

Увеличение числа мобильных пользователей.

Согласно данным Forrester Research, 82% от общего числа PC составляют стандартные настольные PC, подключенные к сети. Число же мобильных пользователей, по данным той же Forrester, составит к концу 1998 года 31% от всех PC, с увеличением их числа до 63% к 2000 году. К сожалению, имеющиеся ныне средства взаимодействия мобильного пользователя с информационной средой, как и удаленный доступ и диагностирование со стороны администратора, далеки от совершенства, что является не последней причиной более высокой (на 36%) стоимости владения по сравнению с настольными компьютерами. Появление же мобильных устройств и программного обеспечения для решения перечисленных проблем ожидается не ранее второй половины 1999 года, по данным все той же Forrester Research.

Риск неверного инвестирования в информационные технологии.

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

Риски, исходящие от производителя оборудования и программного обеспечения

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

Слишком расплывчатые требования к проектируемой информационной системе, неадекватное макетирование и тестирование рабочей модели.

Это проблемы из категории, между прочим, весьма популярной в России: "Заказчик не знает, чего хочет, а исполнитель не знает, чего не может".

Слишком высокие нормы выработки, установленные на одного сотрудника.

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

Слабая защита информационной системы.

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

Неэффективная система восстановления частичной работоспособности системы в форс-мажорных ситуациях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.3 Учет затрат по видам деятельности в процессах модели ITSM

Понятия ЗВД-модели в процессах ITSM

Представление основных понятий ЗВД в процессах ITSM показано на рис. 6.1.

Рис. 6.1. Основные понятия модели ЗВД в процессах модели ITSM

В качестве объекта затрат в процессах ITSM выступает ИТ-услуга. Видами деятельности модели ЗВД выступают процессы модели ITSM и их отдельные составляющие. Например, в функции Help Desk можно выделить три вида деятельности: регистрацию и классификацию инцидента, контроль разрешения инцидента и закрытие инцидента. В процессе управления проблемами можно выделить два вида деятельности: управление проблемами и управление известными ошибками и т. д. Общий подход к выделению видов деятельности -- группировка работ, исходя из критерия результата и по возможности близких трудозатрат. Формализация процессов ИТ-службы в ходе внедрения модели ITSM значительно облегчает эту работу.

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

В качестве факторов затрат ЗВД-модели выступают человеко-часы (трудозатраты), штуки (например, картриджи принтеров или запчасти), гигабайты (дисковое пространство) и т. д., их определение и расчет слабо зависят от наличия в организации процессов ITSM.

Построение ЗВД-модели ИТ-услуги

Построение ЗВД-модели ИТ-услуги начинается с определения объектов затрат, что требует наличия в организации каталога ИТ-услуг. Каждая позиция каталога становится отдельным объектом затрат.

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

Каждому виду деятельности назначается свой натуральный измеритель -- фактор использования. Примеры факторов использования приведены в таблице. Под обращением понимается любой запрос пользователя на Help Desk, допустимый в рамках процесса управления инцидентами, -- звонок по телефону, письмо, отправленное через электронную почту, web-форма и т. д. Под нарядом на работу понимается выданное задание в рамках процесса. Например, в рамках процесса управления инцидентами нарядом на работу может быть устранение инцидента на рабочей станции пользователя или, в рамках регламентных работ -- наряд на работу по администрированию и т. д. Аналогичная работа проводится для ресурсов: их каталогизируют, им назначаются факторы затрат и они соотносятся с видами деятельности. .

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

Для упрощения учета в организации можно ввести единую шкалу из 3-5 групп простоев в порядке возрастания важности для бизнеса. Отнесение простоя к той или иной группе определяется описанными выше факторами.

Рис. 6. 2. Построение ЗВД-модели затрат на ИТ-услугу

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

Модель, возникающая в результате всех перечисленных действий, приведена на рис. 2. Ее правая часть, описывающая виды деятельности и ресурсы, -- классическая ЗВД-модель, определяющая затраты на приобретение и сопровождение ИТ-услуги. Левая часть представляет собой модель простоев по степени их важности для бизнеса и определяет потери от простоев.

Сбор количественных данных для ЗВД-модели

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

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

Инструмент учета затрат первой группы -- наряд на работу. Это бумажный или, чаще, электронный документ, описывающий определенную работу, ее исполнителя, время начала и завершения работы и произведенные материальные затраты (расходные материалы, запчасти и т. д.), если таковые имели место. Такие наряды учитывают все работы по сопровождению сервисов -- диагностику и устранение инцидентов, разрешение проблем и известных ошибок, реализацию изменений и регламентные работы. Если работа связана с затратой каких-либо материалов, при отпуске материала фиксируется номер наряда на работу, для который он был отпущен. В результате наряд на работу фиксирует трудозатраты в человеко-часах и число единиц потраченных материалов в разбивке по отдельным позициям. Это позволяет в дальнейшем суммировать данные о трудовых и материальных затратах по отдельным работам, видам работ, ИТ-услугам и т. д. Большой объем нарядов на работу требует использования автоматизированных систем, таких как Open View, Altiris, Remedy и другие.

Затраты второй группы учитываются не по отдельным транзакциям, а по сводной статистике загрузки за расчетный период, обычно за месяц. Для расчетного периода анализируется средняя и пиковая загрузка единицы оборудования, ПО, канала связи. Если мощность единицы оборудования определяется несколькими показателями (например, для сервера это производительность процессора, объем оперативной памяти, дисковое пространство и др.), то среди них выбирается «узкое место» -- показатель, по которому мощности устройства наиболее близки к исчерпанию. Он и становится фактором затрат соответствующего ресурса. Такая статистика слишком объемна для того, чтобы ее можно было получить и проанализировать вручную, для этого используются такие средства, как Altiris, LANdesk, System Management Server и т. д.

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

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

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

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

Расчет затрат на ИТ-услуги в ЗВД-модели

Вышеперечисленные данные позволяют рассчитать затраты на ИТ-услуги посредством следующих шагов.

1. Расчет цены единицы фактора затрат ресурса. Цена ресурса очень редко соответствует цене фактора затрат этого ресурса, так что последнюю надо рассчитывать отдельно. Например, для выяснения трудозатрат месячная заработная плата и связанные с ней затраты на сотрудника пересчитываются в цену человеко-часа этого сотрудника. Для сервера покупная цена пересчитывается в цену (например) одного гигабайта памяти в год. Для канала связи затраты приводятся к ценам единиц тарификации -- абонентской плате, плате за мегабайт трафика и т. д.

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

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

4. Расчет затрат на ИТ-услугу. Затраты на ИТ-услугу определяются суммированием затрат по видам деятельности, рассчитанных в п. 2, и потерь от простоев, рассчитанных в п. 3. Полученная величина полностью соответствует методическому подходу TCO, поэтому может быть названа TCO ИТ-услуги.

5. Расчет затрат на единицу измерения объекта затрат (удельных затрат). Для каждой ИТ-услуги необходимо также выбрать единицу измерения. Чаще всего это число пользователей услуги, но возможны и другие -- число транзакций (бухгалтерская или ERP-система), сообщений (электронная почта), форм (система сбора и консолидация отчетности) и т. д. Критерий выбора такого измерителя -- максимально тесная связь с затратами ресурсов, что позволяет в дальнейшем использовать его для планирования затрат. Для расчета удельных затрат необходимо поделить сумму затрат на ИТ-услугу на число единиц измерения затрат. Последнее известно из данных систем управления процессами ИТ-службы (число пользователей) либо из данных систем мониторинга (число сообщений, форм, транзакций и т. д.)

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

Использование данных ЗВД-модели ИТ-услуги в управлении затратами

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

Во-вторых, ЗВД-модель дает исходные данные для расчета влияния повышения качества ИТ-услуги на требования к ресурсам для ее сопровождения и, соответственно, на затраты ИТ-службы. В частности, при расширении согласованного времени обслуживания услуги электронной почты с 8*5 до 24*7, дополнительные требования к ресурсам рассчитываются следующим образом. В ресурсы включается дополнительная смена Help Desk. Далее, по таблице видов деятельности и привязке ресурсов к видам деятельности выясняется, какие специалисты необходимы для сопровождения электронной почты. Уточняется, какие виды деятельности могут осуществляться удаленно, для остальных устанавливается посменное дежурство инженеров. Сумма затрат на посменное дежурство операторов и инженеров составит дополнительные затраты.

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

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

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

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

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

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

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

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