Итак, в чем именно проявляется различие в полноте учета ССВ при сравнении информационной системы и сервиса ИТ как объектов затрат?

Рассмотрим последовательно основные характеристики сервиса ИТ.

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

1) Система используется в основном для получения бухгалтерской отчетности.

2) Система используется в основном для управления материальными и/или финансовыми потоками предприятия.

Отметим, что в обоих случаях речь идет об «успешном внедрении» система сдана в эксплуатацию, цели проекта достигнуты. Более того, вполне можно допустить, что число лицензий ЕRP–системы одинаково, стоимость серверного оборудования и клиентских рабочих мест примерно одного порядка, равно как и затраты на консалтинг при внедрении системы. Таким образом, в примере все составляющие ССВ равны, за исключением затрат на техническую поддержку и потерь от оплачиваемых простоев пользователей. Уровень дисциплины пользователей для простоты сравнения можно предположить одинаковым, а значит, дополнительные потери от самоподдержки и взаимоподдержки пользователей также будут совпадать. Однако различие в–содержании сервисов ведет к существенному различию в величине ССВ. Основная причина – различие в цене простоя и затрат на снижение простоя. Под последними мы будем понимать затраты на техническую поддержку, а также затраты на технические и программные решения, снижающие вероятность простоя.

В рассмотренных выше ситуациях 1 и 2 имеет место качественное различие в ценности системы для бизнеса. Бухгалтерский учет при всей его ценности не оказывает непосредственного воздействия на ход операций предприятия. В отличие от него, планирование закупок является частью цепи создания стоимости предприятия, а эффективность такого планирования непосредственно влияет на соответствующие затраты. Таким образом, мы можем с уверенностью предположить существенные различия в цене простоя ЕRP–системы в первом и во втором случае (грубая количественная оценка такого различия будет приведена ниже).

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

Коль скоро цена простоя в примере измерима и известна, рациональный менеджмент требует установления затрат на снижение простоя пользователей в соответствии с ней. В идеале (рис. 7.7) среднее время простоя системы за месяц (t0) должно быть таким, что предельный выигрыш от сокращения простоев в денежном измерении (в точке (t0, L0) должен быть равен предельным затратам на такое сокращение (в точке 10,С0). Если предельные затраты на снижение простоя не равны предельному выигрышу от такого снижения, то, увеличив или уменьшив время простоя, мы придем к меньшей величине затрат, что делает найденную точку заведомо неоптимальной. Предположив в оптимальной точке равенство предельных затрат, вернемся к нашему примеру. Сравнение равновесия для высокой и низкой оценки простоев приведено на рис. 7.8.

Как видно из схемы, при более высокой оценке простоев изменятся и сама оценка простоев (в точке t1, L1 по сравнению с точкой t0, L0), и затраты на их снижение (в точке t1, С1, по сравнению с точкой t0, С0). Следовательно, ССВ в общем случае изменится. К примеру, возможна парадоксальная ситуация, когда ССВ информационной системы оказывается выше только оттого, что ЕRP–система внедрена более глубоко и более успешно! Таким образом, в нашем примере различие ССВ двух ЕRP–систем обусловливается исключительно различным содержанием построенных на их основе сервисов и проистекающим отсюда различием в оценке бизнесом времени простоя этих сервисов.

Рис. 7.7 Равновесие потерь от простоев пользователей и затрат на их снижение.

Рис. 7.8 Пример: изменение равновесия при изменении оценки потерь от простоев пользователей.

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

Тем не менее при учете равнозначности терминов «потери от простоя» – «затраты на снижение времени простоя» это не что иное как затраты на снижения времени простоя сервиса.

Насколько отмеченные явления значимы в расчете ССВ информационной системы? Согласно методике расчета ССВ фирмы Dе11, затраты на администрирование, техническую поддержку и потери от оплачиваемых простоев в совокупности составляют 60% общей величины ССВ. Таким образом, затраты, испытывающие воздействие рассмотренных нами факторов, составляют более половины общей величины ССВ.

Теперь поговорим о разбросе оценок. Не располагая статистикой поданному вопросу, можно сделать лишь предварительные замечания в отношении ЕRР–систем. Если ЕRР–система используется в основном для получения бухгалтерской отчетности, то при сбое системы отчетность, как правило, может быть получена иными способами, например при помощи электронных таблиц[9]. В этом случае разумной оценкой цены простоя является средняя заработная плата сотрудников бухгалтерии. Она составляет ничтожно малую величину – десятые или сотые доли процента от оборота предприятия за время простоя системы.

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

Доступность сервиса. Одна и та же информационная система может эксплуатироваться в разных режимах. Если ИС поддерживает сервис круглосуточно без выходных (в режиме 24x7 – 24 часа в сутки 7 дней в неделю), затраты на техническую поддержку будут в полтора–два раза выше, чем в течение рабочего времени по рабочим дням (в режиме 8x5 – 8 часов в сутки, 5 дней в неделю). Допустим, для поддержки системы электронной почты в режиме 8x5 достаточно двух человек – одного дежурного специалиста ИС и одного помощника дежурного специалиста. Предположим, что по требованию бизнеса ИС перешла к поддержке электронной почты в режиме 24x7, причем дежурный специалист ИС присутствует на рабочем месте круглосуточно, а помощник дежурного специалиста – только в рабочее время по рабочим дням. В этом случае нормальный режим работы дежурного специалиста – «сутки через трое», а это значит, что вместо двух человек должны работать пятеро (четыре дежурных специалиста и один помощник дежурного специалиста). Тем самым затраты на техническую поддержку возрастают минимум в 2,5 раза – при условии равенства зарплат дежурного специалиста и помощника, хотя зарплата дежурного специалиста обычно выше.

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

– создание и управление складом запасных частей и расходных материалов;

– развитие ИТ–инфраструктуры – совершенствование структурированной кабельной сети, создание системы гарантированного электропитания и т.д.;

– внедрение специальных аппаратных средств повышения отказоустойчивости: дисковых массивов, кластерных решений и т.д.;

– внедрение средств удаленного управления сетью, серверами и клиентскими рабочими местами;

– включение оговорок об уровне сервиса в договоры с внешними поставщиками услуг, что также может привести к росту затрат на соответствующие услуги.

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

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

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

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

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