- •Е.А. Калиберда е.П. Яхина анализ эффективности информационных систем
- •Предисловие
- •Введение
- •Экономические методы оценки эффективности ис
- •1.1. Финансовые методы оценки эффективности
- •Статические методы оценки Метод окупаемости
- •Метод «затраты - прибыль»
- •Динамические методы оценки Метод чистой текущей стоимости (npv)
- •Метод индекса рентабельности (pi)
- •Метод внутренней нормы доходности (irr)
- •1.2. Затратные методы оценки эффективности ис
- •Совокупная стоимость владения
- •Невидимые затраты
- •Неконтролируемые затраты
- •Первоначальные затраты
- •1.3. Комплексные методы оценки эффективности ис Система сбалансированных показателей (Balanced Scorecard)
- •1.4. Пример расчета затрат на информационную систему
- •2. Элементы теории вероятности
- •2.1. Формулы комбинаторики
- •2.2. Случайная величина
- •Свойства математического ожидания
- •Математическое ожидание числа появления события в независимых испытаниях
- •2.3. Биноминальное распределение
- •2.4. Распределение Пуассона
- •2.5. Экспоненциальное распределение
- •2.6. Простейший поток событий
- •3. Качество и эффективность информационных систем Методы оценки качества
- •3.1. Показатели качества программного изделия
- •Количественные показатели функциональных возможностей программного изделия
- •Количественные показатели эффективности программного изделия
- •Количественная оценка безопасности информационной системы
- •3. 2. Основные понятия теории надёжности
- •Определение надёжности программного изделия
- •Основные количественные показатели надёжности
- •3.3. Примеры оценки основных показателей качества
- •4. Тестировапние программных проодуктов Понятие тестирования
- •Роль тестирования в процессе разработки программ
- •4.1. Различные подходы к тестированию (черный ящик, белый ящик)
- •4.2. Смежные вопросы тестирования
- •Заключение
- •Библиографический список
- •ПриложенИя
- •Работы, выполняемые разработчиками постановки задачи
- •Работы, выполняемые разработчиками постановки задачи
- •Работы, выполняемые разработчиками постановки задачи
Невидимые затраты
«Невидимость» данных категорий затрат не означает, что эти затраты не входят в общую сумму затрат организации. Однако в традиционных системах учета данные затраты учитываются в составе затрат на рабочую силу. Затраты рабочего времени в организации включают в себя непроизводительные затраты, которые мы и рассмотрим. Роль управленческого учета по отношению к ним состоит в том, чтобы вскрыть зависимость части затрат на рабочую силу от параметров информационных систем организации и уровня работы службы ИС.
Потери от простоев пользователей — потери для организации, связанные с простоем пользователя вследствие перерыва того или иного сервиса ИТ. Неработоспособность сервиса всегда связана с неисправностью той или иной информационной системы
Простой может быть плановым, т.е. связанным с регламентными работами по обновлению оборудования и версии ПО, переносу данных и т.д.
Также простой может быть внеплановым в связи с каким-либо инцидентом, т.е. внеплановым нарушением сервиса.
В обоих случаях потери возникают вследствие неспособности сотрудника выполнять свои обязанности в период отсутствия некоторого сервиса ИТ.
Простой обычно измеряется в единицах рабочего времени, потерянного пользователями, например в часах. Потери от простоя пользователей составляют в среднем 16% общей величины затрат на ИС.
Простои могут очень различаться как по времени, так и по значимости для организации.
Скажем, простой, связанный с отсутствием тонера в принтере, обычно непродолжителен. Напротив, простои, связанные с потерей данных пользователя, обычно весьма длительны. В наиболее сложном случае пользователь оказывается вынужденным восстанавливать данные заново. Столь же сильно отличаются простои по последствиям для бизнеса.
Например, простой бухгалтерской системы в обычном режиме работы бухгалтерии несопоставим' по своим последствиям с простоем той же самой бухгалтерской системы в период подготовки баланса организации.
Другой пример: 30 простоев веб-сайта в пределах 1—2 минут в течение одного месяца едва ли будет заметны пользователями, тогда как однократный простой того же целого сайта в течение месяца длительностью 1 час является серьезным инцидентом.
Таким образом, «цена» одного и того же времени простоя пинается в зависимости как от длительности простоя, так и от других факторов.
Для того чтобы зафиксировать эту неравнозначность в управленческом учете, вводятся категории простоев, учащающиеся по значимости простоя. Категория рассматривается в учете как признак, присваиваемый каждому простою зависимости от значимости простоя для организации. Категория обычно присваивается в момент закрытия инцидента.
Теперь рассмотрим следующую категорию затрат — потери от самоподдержки.
Самоподдержка означает, что пользователь самостоятельно разрешает инциденты с информационными системами на своем рабочем месте, не прибегая к помощи службы ИС. При этом пользователь не выполняет своих непосредственных обязанностей, т.е. с точки зрения бизнес-процесса простаивает.
Поэтому первая составляющая затрат на самоподдержку — потери от простоя, описанные выше.
Вторая составляющая затрат, связанных с самоподдержкой, — нарушение правил и политик, принятых в службе ИС. Пользователь, не осведомленный о стандартах службы эксплуатации, самостоятельно меняет параметры подключения к локальной сети, электронной почты, печати и т.д. Это осложняет деятельность сотрудников службы ИС по диагностике и устранению инцидентов, что, в свою очередь, ведет к дополнительным затратам службы ИС.
Можно предположить, что самоподдержка сокращает затраты службы ИС по сопровождению пользователей. Однако эта экономия кажущаяся.
Во-первых, профессиональный сотрудник службы ИС выполнит работы по сопровождению быстрее и с меньшим количеством ошибок, т.е. самоподдержка есть прежде всего непроизводительная затрата труда.
Во-вторых, самоподдержка скрывает от руководства службы ИС и организации в целом проблемы сопровождения пользователей. Это поощряет недофинансирование службы ИС и дальнейший рост самоподдержки.
В-третьих, одним из важнейших источников данных для службы ИС является статистика инцидентов. Самоподдержка препятствует накоплению такой статистики, поскольку пользователь, устранив инцидент самостоятельно, едва ли поставит в известность службу ИС.
Т.е., любые действия по самоподдержке необходимо рассматривать как чистый проигрыш организации.
Точно так же необходимо рассматривать потери от взаимоподдержки.
В этом случае инцидент, возникший у одного пользователя, разрешается не сотрудником службы ИС, а другим пользователем. Эта ситуация близка к самоподдержке, но в этом случае теряется рабочее время двух пользователей одновременно: один пользователь простаивает, второй вместо исполнения своих непосредственных обязанностей разрешает инцидент, возникший у первого.
Общие затраты складываются из потерь от простоя двух пользователей и риска возможных дополнительных затрат службы сопровождения. Это делает взаимоподдержку наиболее дорогостоящей категорией невидимых затрат.
Ликвидация самоподдержки и взаимоподдержки позволяет сделать потери от простоев видимыми. Для этого в структуре службы ИС создается отдельное подразделение — Service Desk. Помимо прочих функций, Service Desk фиксирует момент поступления запроса пользователя как момент возникновения инцидента. Окончанием простоя считается момент закрытия инцидента, т.е. возобновления сервиса в требуемом объеме и качестве. Разность между этими двумя моментами и составляет время простоя пользователя.
Борьбу с самоподдержкой и взаимоподдержкой целесообразно вести посредством дисциплинарных мер. Весьма действенно, если руководство организации на всех уровнях принимает в качестве оправдания только те простои сервисов ИТ, которые зарегистрированы в соответствующем подразделении службы ИС (Service Desk).
С точки зрения управленческого учета фиксации времени простоя недостаточно. Необходимы данные, позволяющие уменьшить это время, — данные о том, какое именно оборудование или программное обеспечение явилось причиной простоя.
Для этого Service Desk фиксирует код позиции конфигурации, породившей простой. Код позиции конфигурации фиксируется в момент закрытия инцидента, когда причина сбоя, как правило, уже ясна. В процессе управления проблемами код позиции конфигурации может быть изменен.
Таким образом, управленческий учет невидимых затрат призван решить две задачи.
Во-первых, выделить данные категории затрат из общей суммы накладных расходов и расходов на рабочую силу в составе накладных расходов. Эта задача решается фиксацией времени простоя на основании данных Service Desk.
Во-вторых, соотнести простой с конкретной единицей конфигурации, вызвавшей простой. Эта задача решается внесением в базу данных Service Desk кода позиции конфигурации, явившейся причиной инцидента. Источниками этих данных являются процесс управления инцидентами и процесс управления проблемами.