В 1990–е годы одной из ведущих мировых тенденций в управлении ИС стал переход к аутсорсингу, то есть передаче сопровождения инфраструктуры ИТ предприятия или отдельных ее звеньев внешнему поставщику услуг (аутсорсинга – внешний источник, англ.). Суть проблемы в том, что услуги внешнего поставщика по сравнению с использованием собственной ИС часто позволяют снизить ССВ инфраструктуры ИТ на предприятии. В настоящее время эта тенденция широко обсуждается и в России.
В частности, одна из крупнейших российских нефтяных компаний – ЮКОС – выделила свою ИС в отдельную компанию («Сибинтек»), передав ей в эксплуатацию информационные системы на условиях аутсорсинга. Рассмотрим проблему аутсорсинга в России в терминах ССВ сервиса ИТ.
Одна из важнейших проблем российского бизнеса в целом и управления ИС в частности – низкий уровень формализации бизнес–процессов.
В области управления ИС это ведет к отсутствию спецификаций (во всяком случае, детализированных) требований бизнеса к сервисам ИТ. Отсутствие детальных спецификаций, как правило, сохраняется и в договоре аутсорсинга. Это влечет за собой следующие проблемы при исполнении договора:
– требования к сервисам «де–юре» и «де–факто» на предприятии различаются, требования «де–факто» оказываются значительно выше;
– предприятие после заключения договора аутсорсинга начинает повышать требования к доступности и уровню сервиса, подтягивая их до существовавших фактических стандартов;
– предприятие–аутсорсер воспринимает эти требования как увеличение объемов работ, соответственно повышаются расходы у предприятия, потребляющего его услуги.
Рассмотрим такое развитие событий с точки зрения ССВ систем и сервисов ИТ. В отсутствие спецификаций сервисов ИТ договор аутсорсинга заключается на сопровождение информационных систем. При этом режим сопровождения определяется формальными требованиями к обслуживанию, которые, как уже отмечалось, обычно сильно занижены относительно фактического уровня. В результате следующее из договора аутсорсинга снижение ССВ фактически планируется для ситуации снижения доступности и уровня сервиса от фактически существующих требований к менее жестким требованиям, закрепленным формально.
Восстановление первоначального уровня сервиса ведет к дополнительным затратам, не учтенным договором аутсорсинга.
Таким образом, при заключении договора аутсорсинга вопрос детальной спецификации сопровождаемых сервисов в договоре приобретает принципиальное значение не только для экономического анализа ситуации, но и для эффективного взаимодействия обоих предприятий – поставщика и получателя услуг аутсорсинга.
Сравнительный анализ использования в качестве объектов затрат при расчете ССВ информационных систем и сервисов ИТ показывает преимущество последних по ряду причин:
1) В решении задач оценки экономической эффективности инфраструктуры ИТ и деятельности ИС по ее эксплуатации (бенчмаркинг, оценка достаточности службы поддержки) игнорирование параметров сервисов ИТ ведет к смешению повышенных бизнес–требований к инфраструктуре ИТ, с одной стороны, и неэффективности инфраструктуры ИТ или ИС – с другой. ССВ информационной системы не позволяет выделить повышение ССВ, связанное с первой и второй группой факторов.
2) В решении задач выбора информационной системы (собственно выбора информационной системы, выбора между закупкой и разработкой) игнорирование параметров сервисов ИТ ведет к усредненным оценкам стоимости простоя и технической поддержки, тем самым не позволяя учесть различия требований к характеристикам информационной системы в различных условиях ее эксплуатации'.
3) При анализе вариантов полного или частичного аутсорсинга сопровождения информационных систем использование в оценке и управлении ССВ информационной системы не фокусирует внимание менеджеров на параметрах сервисов, зависящих от информационных систем, которые передаются в аутсорсинг. В результате оценка ССВ и заключенный договор аутсорсинга, особенно в условиях России, ориентируются на формальные, а не на фактически существующие (обычно более высокие) требования к уровню и доступности сервиса. Попытка восстановить режим обслуживания, существовавший до заключения договора аутсорсинга, приводит к конфликтам поставщиков и потребителей данных услуг и повышению затрат на аутсорсинг.
4) В области бюджетирования ИС использование сервисов в качестве объектов затрат позволяет непосредственно связать выгоды, Сказанное относится только к оценкам ССВ со стороны производителей оборудования и ПО. Ниже будет показано, что ССВ информационной системы, построенная на основе внутренних оценок предприятия, которые учитывают фактические затраты на техническую поддержку и потери от простоев пользователей, существующие на данном предприятии, может иметь экономический смысл.
5) Для каждого вида деятельности определяются обеспечивающие его ресурсы, а для каждого ресурса – фактор затрат ресурса (натуральный показатель, характеризующий затраты k–го ресурса на единицу фактора интенсивности использования j–го вида деятельности). Как и в предыдущих случаях, необходима однородность фактора затрат ресурса.
6) В затратах, составляющих ССВ, присутствуют затраты, не связанные с использованием каких–либо ресурсов, – потери от простоя сервиса. Эти потери на этапе построения модели определяются в единицах натурального измерителя внешнего сервиса (одна проводка, один отчет, одно задание печати). На данном этапе определяются критические величины потерь от простоев, для которых в дальнейшем будут установлены различные денежные оценки. Например, если не введены одна–две проводки – это «рядовой» простой; если не введены 100 проводок – «чрезвычайный простой», имеющий другую денежную оценку.
7) Определяются количественные отношения между натуральными измерителями внешних сервисов, факторов интенсивности использования видов деятельности и факторов затрат ресурсов. Изданном этапе устанавливаются qi. – число потребляемых за период единиц i–го ресурса, аij – число единиц фактора интенсивности использования j–го вида деятельности, потребляемых на единицу i–го объекта затрат, rjk. – число единиц фактора затрат k–го ресурса, потребляемых на единицу фактора интенсивности использования j–го вида деятельности. Результатом выполнения шагов 1 –5 является построение модели сервиса – совокупности натуральных измерителей, определяющих количественные соотношения внешних сервисов, видов деятельности (функций) и ресурсов. Эта стадия анализа представлена на рис. 7.11 в строке «описание».
8) Определяется стоимость фактора затрат ресурсов в денежном измерении. Цена ресурса редко бывает связана непосредственно с единицей фактора затрат. Например, цена серверного оборудования устанавливается в расчете на единицу оборудования, тогда как фактор затрат, как правило, – это единица загрузки процессора, дискового пространства или оперативной памяти в зависимости от того, что именно полагается критическим ресурсом[11]. Притом факторы затрат должны быть скорректированы на период времени, за который оценивается величина ССВ. Допустим, ССВ рассчитывается в годовом исчислении, а сервер служит пять лет. В этом случае на год приходится 1/5 часть цены сервера. Далее, если фактором затрат служит процент загрузки, годовые затраты на сервер делятся на 100%.
9) Определяется стоимость сервиса. При известной цене единицы фактора затрат каждого ресурса цена единицы фактора интенсивности использования вида деятельности рассчитывается по формуле:
, (7.2)
где: 
– цена единицы фактора интенсивности использования j–го ресурса;
– число единиц фактора затрат k–го ресурса, потребляемых на единицу фактора интенсивности использования j–го вида деятельности;
– цена единицы фактора затрат k–го ресурса.
С учетом формулы (7.1) получаем для единицы измерения внешнего сервиса:
, (7.3)
где: 
– цена единицы измерения i–го внешнего сервиса;
– число единиц фактора затрат–то вида деятельности, потребляемых на единицу j–го внешнего сервиса.
Наконец, с учетом потерь от простоев сервиса и его потребления за единицу времени получаем ССВ сервиса в рассматриваемом периоде:
, (7.4)
где: 
– ССВ i–го сервиса;
– число единиц i–го сервиса, потребленных за период;
– время простоя m–й категории i–го сервиса;
– цена простоя m–й категории i–го сервиса.
Рис. 7.11 Расчет себестоимости сервиса.
Таким образом, шаги 6–7 позволяют определить ССВ сервиса ИТ на основе модели сервиса, построенной в рамках шагов 1–5. Итак, шаги 1–7 позволяют определить себестоимость сервисов ИТ.
7.11 Факторы затрат, факторы интенсивности использования и исходные данные для расчета ССВ сервиса ИТ.
В данном разделе будут рассмотрены параметры модели ФСА для основных видов деятельности ИС – факторы затрат, факторы интенсивности использования видов деятельности. В последующих разделах мы обсудим методы получения исходных данных, необходимых для расчета ССВ сервисов ИТ на основе модели ФСА. Все шаги ФСА будут проведены для модели бизнес–процессов ITSМ.
Мы не стремимся построить здесь законченную и готовую к использованию ФСА–модель сервисов ИТ Построение такой модели требует большого объема данных, специфичных для каждого отдельного предприятия. В настоящем разделе речь идет лишь о методах построения подобной модели: даются рекомендации по выбору ключевых экономических параметров – видов деятельности, факторов затрат и факторов интенсивности использования. Виды деятельности будут определены исходя из модели ITSМ. В ФСА–модель включаются только такие виды деятельности, которые непосредственно связаны с разработкой или сопровождением сервиса. Те же, которые не могут быть связаны с тем или иным сервисом, скажем разработка стратегии развития ИТ или анализ потребностей бизнеса, в данном примере относятся к накладным расходам. Затраты на такие виды деятельности при необходимости распределяются по сервисам в соответствии с условными критериями.
Наш анализ мы начнем с определения видов деятельности и факторов интенсивности их использования для стандартных процессов ITSМ. Рассмотрим процессы ITSМ по порядку в соответствии с разделом 7.3.2.
В блоке процессов интеграции с бизнесом любая деятельность в рамках процесса анализа потребностей бизнеса и процесса разработки стратегии развития ИТ относится к нескольким сервисам одновременно. Действительно, сфера деятельности процесса анализа потребностей бизнеса – определение оптимальных направлений для приложения усилий ИТ по разработке новых сервисов. Сфера деятельности процесса разработки стратегии развития ИТ – определение, согласование и утверждение таких направлений. Направление в общем случае понимается шире, чем сервис ИТ, – обычно как пакет из нескольких сервисов ИТ. В результате данная деятельность связана с сервисами ИТ отношением «многие ко многим» и не может быть распределена по ним естественным образом.
Процесс управления клиентами может быть рассмотрен как начальная стадия разработки сервиса, поскольку на этом этапе создается запрос на планирование сервиса, то есть задача бизнес–пользователя формализуется в виде одного или нескольких планируемых сервисов. На этом основании мы выделяем в особый вид деятельности формулирование проблем бизнес–пользователей. За фактор интенсивности такого вида деятельности будет принят запрос на планирование сервиса.
Для блока процессов планирования сервисов основная деятельность обработка запроса на планирование сервиса. В этом случае все процессы блока – планирование сервисов, управление качеством сервиса, управление доступностью, управление безопасностью, управление пропускной способностью, управление затратами – последовательно обрабатывают запрос на спецификацию сервиса в соответствии со своей компетенцией. Результатом является обработанная спецификация на создание сервиса, которая и становится фактором интенсивности для данного вида деятельности. Кроме этого, для процесса планирования имеется дополнительный вид деятельности: обработка запроса на планирование сервиса от процесса управления клиентами (фактор затрат – обработанный запрос на планирование сервиса), на базе которого при необходимости создается запрос на спецификацию сервиса. Наконец, в рамках процесса управления качеством сервиса помимо обработки запросов при изменении объема бюджета или иных ресурсов производится согласование ресурсов и уровня сервиса. Фактор интенсивности данного вида деятельности – пересмотр бюджета.
Для процесса разработки и тестирования сервисов единственный существенный вид деятельности – разработка и тестирование новых сервисов. Поскольку сервис разрабатывается на основе спецификации, фактором интенсивности является обработанная спецификация сервиса. Для процесса передачи сервиса в промышленную эксплуатацию основная деятельность – передача сервиса. Фактором интенсивности считается акт приема–передачи, подписанный разработчиками и службой эксплуатации.
В управлении инцидентами присутствуют два вида деятельности. Прием пользовательских запросов и их первичная диагностика производятся в рамках регистрации запросов пользователей. Фактором интенсивности этого вида деятельности является запрос пользователя. Второй вид деятельности – устранение инцидента. Фактором интенсивности этого вида деятельности считается исполненный наряд на работу, выданный в процессе регистрации запроса.
В управлении проблемами можно выделить три вида деятельности. Первый – диагностика проблемы, осуществляемая в обязательном порядке. Фактором интенсивности этого вида деятельности являются наряды на работу, полученные от процесса управления инцидентами.
Следующий вид деятельности (см. рис. 7.5) – разрешение проблемы путем изменения. Фактор интенсивности данного процесса – запрос на изменение, в обязательном порядке формируемый после выполнения изменения. Наконец, последним видом деятельности в данном процессе будет разработка обходных путей для решения проблем. Фактор интенсивности данного вида деятельности – документированный обходной путь.
В управлении операциями выделяются два вида деятельности. Первый – регламентные работы, такие как резервное копирование, управление очередями принтеров и тому подобные периодические операции. Фактор интенсивности этого вида деятельности – позиция графика регламентных работ. Второй вид – исполнение запросов на изменение, выданных другими процессами. Фактор интенсивности этого вида деятельности – обработанный запрос на изменение.
В управлении изменениями единственный вид деятельности – утверждение запросов на изменение. Фактор интенсивности этого вида деятельности – обработанный запрос на изменение. Наконец, в управлении конфигурациями выделяются два вида деятельности. Фактор интенсивности, сопоставленный ведению базы данных позиций конфигурации, изменение позиции конфигурации. Управление активами предполагает использование в качестве фактора интенсивности операции управления активами (закупки, реализации, перемещения и т.д).
Легко заметить, что перечисленные факторы интенсивности в большинстве своем неоднородны. Один и тот же фактор интенсивности, будь то наряд на работу в управлении инцидентами или спецификация сервиса в процессах блока планирования, может представлять совершенно разные объемы работы, а, следовательно, и затрат. На практике эта проблема разрешается категорированием факторов интенсивности. Двух–трех уровней сложности, как правило, достаточно для описания реально существующих различий.
Результаты анализа сведены в табл. 7.3.
Таблица 7.3 Пример видов деятельности и факторов интенсивности в ФСА–модели сервисов ИТ.
Процесс
Вид деятельности
Планирование сервисов
Управление качеством сервиса
Управление инцидентами
Управление проблемами
Окончание таблицы 7.3.
| Управление операциями | Регламентные работы, например резервное копирование | Операция регламентных работ |
| Обработка запросов на изменение, выданных прочими процессами | Запрос на изменение | |
| Управление изменениями | Утверждение запросов на изменение, выданных прочими процессами | Запрос на изменение |
| Управление конфигурациями | Ведение базы данных позиций конфигурации | Изменение БДПК |
| Управление активами | Операция управления актинами |
Следующий шаг функционально–стоимостного анализа состоит в определении используемых ресурсов и их факторов затрат (табл. 7.4).
Основной ресурс ИС – персонал службы ИТ (при аутсорсинге рассматриваемого сервиса речь идет о персонале предприятия–аутсорсера). Как показывает практика, это одновременно и самый дорогой ресурс. Типовой фактор затрат этого ресурса – рабочее время.
Для серверов может использоваться несколько альтернативных факторов затрат: процент нагрузки процессора, процент занимаемой оперативной памяти, процент занимаемого дискового пространства и т.д. По соображениям единственности фактора затрат выбирается только одна из альтернатив. Естественным образом в качестве последней выбирается наиболее ограниченный ресурс. Для прочих видов оборудования неоднозначность, как правило, отсутствует. Так, для запоминающего устройства обычно избирается занятое дисковое пространство (устройство прямого доступа) либо время работы устройства (устройство последовательного доступа). Для активного сетевого оборудования и каналов связи фактором затрат считается занятая емкость канала. Наконец, для запасных частей и расходных материалов в качестве факторов затрат выступают количественные единицы измерения (например, штуки).
Таблица 7.4 Ресурсы и факторы затрат в модели сервиса ИТ.
| Ресурс | Фактор затрат |
| Персонал ИС | Рабочее время |
| Сервер, ПК | Процент нагрузки процессора |
| Процент занятой оперативной памяти | |
| Процент занятого дискового пространства | |
| Запоминающее устройство | Процент занятой емкости памяти |
| Время работы | |
| Активное сетевое оборудование | Процент пропускной способности |
| Канал связи | Процент пропускной способности |
| Прикладное программное обеспечение | Процент лицензий |
| Процент одновременных соединений | |
| Процент занятых ресурсов аппаратных средств или системного ПО | |
| Системное программное обеспечение | Процент занятых системных ресурсов |
| Канал связи | Процент загрузки |
| Трафик и иные факторы ценообразования | |
| Запасные части и расходные материалы | Штуки и иные единицы измерения |
Окончание таблицы 7.4.
| Услуга связи | Трафик |
| Время работы и иные измерители | |
| Внешняя услуга | Рабочее время |
| Прочие факторы ценообразования |
По–иному определяются факторы затрат для программного обеспечения. Для системного ПО таковыми являются его занятые ресурсы. При Наличии в системе нескольких ресурсов наиболее ограниченный из них выступает в качестве фактора затрат. За естественный фактор затрат для прикладного программного обеспечения принимаются пользовательские лицензии или одновременно работающие пользователи, в зависимости от лицензионной политики поставщика ПО.
Если различные сервисы выполняются на одних и тех же рабочих местах (соответственно, используют одни и те же лицензии), фактором затрат можно посчитать занятые данным сервисом ресурсы операционной системы или аппаратного обеспечения.
Наконец, рассмотрим факторы затрат внешних услуг. Услуги связи и телекоммуникаций могут измеряться как трафиком, так и иными натуральными измерителями в соответствии с тарифной политикой пользователя, например временем занятия линии связи. Услуги консалтинга и аутсорсинга измеряются, как правило, затраченным рабочим временем консультанта (аутсорсера). Вместе с тем, согласно тарифной политике поставщика, в качестве фактора затрат могут выступать и иные измерители: вызов специалиста, выполненная работа определенного вида и т.д.
Таким образом, в настоящем разделе мы описали основные виды деятельности и ресурсы, задействованные в процессе оказания услуг (сервисов) ИТ. Для видов деятельности описаны факторы интенсивности, для ресурсов – факторы затрат. В следующих разделах мы рассмотрим источники количественных данных по вышеперечисленным факторам.
7.11.1 Источники данных для определения себестоимости сервисов ИТ методом ФСА.
В настоящем разделе мы рассмотрим процессы ITSМ, в рамках которых собираются данные, необходимые для расчета ССВ сервиса ИТ методом ФСА. Необходимо отметить, что речь пойдет лишь о получении данных в условиях работающей модели ФСА. Внедрение расчета себестоимости сервиса ИТ по модели ФСА не отличается принципиально от внедрения любой другой ФСА–модели и будет рассмотрено нами в специально посвященном ей разделе. В данном же разделе мы ограничимся рассмотрением процессов ITSM, где наблюдаются установленные нами ранее факторы интенсивности использования видов деятельности и факторы затрат ресурсов.
В решении этой задачи мы будем опираться на принципы, утвердившиеся в современных моделях организации бизнес–процессов:
– данные (в настоящем разделе – информация о затратах) фиксируются в месте их возникновения;
– сходные работы, выполняемые на смежных участках, объединяются в общий бизнес–процесс;
– совмещается ответственность за выполнение работы и отражение ее результата в управленческом учете.
В соответствии с этими принципами и будут определяться точки наблюдения за факторами затрат и факторами интенсивности использования. Рассмотрим эти точки.
Процесс планирования сервиса в модели ITSМ является точкой ответственности за подготовку детальной спецификации нового сервиса. Эта спецификация разрабатывается на основании запроса процесса управления клиентами. В процессах блока планирования сервисов спецификация поочередно рассматривается с точки зрения пропускной способности (управление пропускной способностью), безопасности (управление безопасностью), устойчивостью (управление устойчивостью), соответствия наличным ресурсам (управление качеством сервиса). Координация процессов блока планирования по согласованию спецификации сервиса входит в компетенцию процесса планирования.
Как следствие, именно в рамках процесса планирования сервиса фиксируются все фазы прохождения спецификации вплоть до передачи на утверждение в рамках процесса управления изменениями. На основании вышеизложенных принципов процесс планирования сервисов должен фиксировать участие прочих процессов в подготовке спецификации, то есть отражать:
– формулирование проблем бизнес–пользователей;
– обработку запросов на планирование сервисов;
– планирование новых сервисов;
– согласование объема ресурсов при создании или тиражировании сервиса;
– обработку запросов на планирование сервисов.
Процесс управления изменениями в модели ITSМ является точкой ответственности за разрешение внесения изменений в конфигурацию информационных систем предприятия. Как следствие, в этом процессе фиксируются все запросы на изменения и результаты исполнения этих запросов. В учете затрат на сервис ИТ это означает регистрацию следующих операций:
– согласования уровня сервиса при пересмотре объема ресурсов (бюджета), выделенного ИС;
– сверки разработанного ИТ–решения со спецификацией в ходе разработки и тестирования сервиса;
– приемки ИТ–решения в ходе запуска сервиса в промышленную эксплуатацию;
– учета внесенных изменений в процессе управления проблемами (разрешения проблемы путем изменения);
– в процессе управления операциями – обработки запросов на изменения, выданных прочими процессами;
– утверждения запросов на изменение, выданных прочими процессами собственно в процессе управления изменениями.
Процесс управления конфигурациями в модели ITSМ является точкой ответственности за отражения фактического состояния активов в области ИТ. Соответственно, данный процесс в контексте учета затрат отвечает за отражение:
– ведения базы данных позиций конфигурации – каждое изменение позиций конфигурации фиксируется в учете произведенных работ;
– операций по управлению активами (закупок, модернизации, перемещения, списания) – аналогично позициям конфигурации.
Одновременно в процессе ведения базы данных позиций конфигурации фиксируется в качестве значений факторов затрат использование оборудования, ПО и прочих позиций конфигурации в тех или иных сервисах ИТ. Конкретный перечень учитываемых факторов затрат ресурсов приведен в табл. 7.6.
Процесс управления инцидентами в модели ITSМ является точкой ответственности за устранение инцидентов. С учетом того, что устранение проблем, как правило, ведется на основании запросов процесса управления инцидентами, деятельность по управлению проблемами также отражается в этом процессе. Речь идет о следующих видах деятельности:
– регистрации запросов пользователей;
– разрешении инцидентов;
– диагностике проблем;
– разработке обходного пути.
Кроме этого, в рамках процесса управления инцидентами фиксируются простои пользователей, а также затраты запасных частей и расходных материалов в процессе устранения инцидентов.
Далее, в рамках процесса управления операциями отражаются действия персонала ИС по ведению регламентных работ. Распределение времени сотрудников ИС осуществляется руководителями соответствующих подразделений ИС. Наконец, затраты по внешним услугам – услугам связи, телекоммуникаций, консалтинга, обучения и т.д. – фиксируются непосредственно в рамках процесса управления затратами.
Итак, что же представляет собой рассмотренное нами отражение операций? Прежде всего, это количественный учет документов, рассматриваемых в нашей модели как факторы интенсивности деятельности (табл. 7.3). При наличии категорий сложности документы учитываются в соответствии с их категориями. Далее, имеет место учет простоя пользователя с указанием категории простоя. Количество затраченных ресурсов по каждому фактору затрат ресурсов фиксируется руководителями подразделений (люди), процессом управления конфигурациями (инфраструктура ИТ), процессом управления затратами (внешние услуги). На основании всей совокупности перечисленных данных в рамках процесса управления затратами определяется себестоимость сервисов ИТ. Источники данных о затратах по видам деятельности и ресурсам в процессе оказания услуг ИТ представлены в сводных таблицах (табл. 7.5, 7.6).
Таблица 7.5 Источники данных о затратах по видам деятельности.
| Наименование вида деятельности | Фактор затрат | Процесс – источник данных |
| 1. | 2. | 3. |
| Формулирование проблем бизнес– пользователей | Запрос на планирование сервиса | Планирование сервисов |
| Обработка запросов на планирование сервисов | Запрос на планирование сервиса | Планирование сервисов |
| Планирование новых сервисов | Запрос на спецификацию сервиса | Планирование сервисов |
| Согласование объема ресурсов при создании или тиражировании сервиса | Запрос на спецификацию сервиса | Планирование сервисов |
| Согласование уровня сервиса при пересмотре объема ресурсов | Защита бюджета ИС | Управление изменениями |
| Разработка и тестирование сервиса | Спецификация сервиса | Управление изменениями |
| Запуск сервиса в промышленную эксплуатацию | Протокол приема сервиса в эксплуатацию | Управление изменениями |
| Обработка запросов на планирование сервисов | Запрос на спецификацию сервиса | Планирование сервисов |
| Регистрация запросов пользователей | Обращение в службу | Управление инцидентами |
| Разрешение инцидента | Наряд на работу | Управление инцидентами |
| Диагностика проблемы | Проблема/инцидент | Управление инцидентами |
| Разрешение проблемы путем изменения | Запрос на изменение | Управление изменениями |
| Разработка обходного пути | Обходной путь | Управление инцидентами |
| Регламентные работы, например резервное копирование | Операция регламентных работ | Управление операциями |
| Обработка запросов на изменение, выданных прочими процессами | Запрос на изменение | Управление изменениями |
| Утверждение запросов на изменение, выданных прочими процессами | Запрос на изменение | Управление изменениями |
| Ведение базы данных позиций конфигурации | Изменение БДПК | Управление конфигурациями |
| Управление активами | Операция управления активами | Управление конфигурациями |
Таблица 7.6 Источники данных о затратах по ресурсам.
| Ресурс | Фактор затрат | Наблюдение |
| Персонал ИС | Рабочее время | Руководители подразделений |
| Сервер, ПК | Процент нагрузки процессора | Управление конфигурациями |
| Процент занятой оперативной памяти | Управление конфигурациями | |
| Процент занятого дискового пространства | Управление конфигурациями | |
| Запоминающее устройство | Процент занятой емкости памяти | Управление конфигурациями |
| Время работы | Управление конфигурациями | |
| Активное сетевое оборудование | Процент пропускной способности | Управление конфигурациями |
| Прикладное программное обеспечение | Процент лицензий | Управление конфигурациями |
| Процент одновременных соединений | Управление конфигурациями | |
| Процент занятых ресурсов аппаратных средств или системного ПО | Управление конфигурациями | |
| Системное программное обеспечение | Процент занятых системных ресурсов | Управление конфигурациями |
| Канал связи | Процент пропускной способности | Управление конфигурациями |
| Трафик и иные факторы ценообразования | Управление конфигурациями | |
| Запасные части и расходные материалы | Штуки и иные единицы измерения | Управление инцидентами |
| Услуга связи | Трафик | Управление затратами |
| Время работы и иные измерители | Управление затратами | |
| Внешняя услуга | Рабочее время | Управление затратами |
| Прочие факторы ценообразования | Управление затратами |
В настоящем разделе показано, каким образом совместное использование фундаментальных моделей экономического анализа ИТ – модели бизнес–процессов ITSМ и модели учета затрат ССВ – обеспечивает наличие всеохватных и непротиворечивых данных по затратам ИС.
Такой результат достигается за счет применения понятия совокупной стоимости владения сервисом ИТ – совокупности затрат предприятия, связанных с разработкой, реализацией и сопровождением сервиса ИТ.
Сложные взаимосвязи сервисов ИТ с ресурсами ИС (персоналом, аппаратными и программными средствами, внешними услугами) предполагают использование средств функционально–стоимостного моделирования деятельности по оказанию сервисов ИТ.
Функционально–стоимостной анализ (ФСА).
На сегодняшний день модель функционально–стоимостного анализа (ФСА) является наиболее развитым способом учета затрат. В этом качестве она уже была использована в предыдущем разделе для определения себестоимости сервиса ИТ. Между тем при оценке эффективности ИТ функционально–стоимостной анализ применяется в гораздо более общем контексте. Внедрение информационных технологий зачастую изменяет бизнес–процессы предприятия. При большой доле накладных расходов в себестоимости, типичной для современного предприятия, это не может не сказаться на общих затратах. Количественная оценка такого изменения определяется именно моделью ФСА.
Основы модели ФСА.
Функционально–стоимостной анализ (ФСА) был разработан в США на рубеже 1970–х – 1980–х годов и пришел на смену методу прямых затрат.
Основная причина устаревания последнего состояла в резком снижении удельного веса затрат на сырье, материалы и заработную плату производственных рабочих в себестоимости продукции, происшедшем после энергетического кризиса 1973 года.
Здесь необходимо сделать небольшое отступление. Метод прямых затрат, разработанный в США в 1920–е годы, нацелен на возможно более полную привязку себестоимости к объему выпускаемой продукции.
Для этого используется понятие прямых затрат, то есть затрат производственных ресурсов, непосредственно относимых на выпуск тех или иных продуктов, – сырья, материалов, части заработной платы, части электроэнергии и т.д. Отнесение осуществляется путем непосредственного учета затрат ресурсов в натуральной форме на единицу продукции (также в натуральной форме). При умножении натуральных затрат на цены ресурсов получается собственно себестоимость единицы продукции. Тем самым обеспечиваются исходные данные для относительной оценки величины отдельных статей затрат (приемлемые – избыточные), а следовательно и для управления ими.
Вместе с тем не все затраты могут быть непосредственно отнесены на объем выпускаемой продукции. Прежде всего, исключение составляют сбытовые и управленческие затраты (в западной классификации – Sales, General and Administrative Expenses, SGA), а также ряд иных общехозяйственных статей расходов, например оплата электроэнергии на освещение зданий. Общее свойство таких затрат в том, что затраты ресурсов невозможно распределить по выпускаемым продуктам (в терминах реляционной модели данных – отношение «многие ко многим»). Как следствие, в данной ситуации не могут быть рассчитаны количественные, а значит и стоимостные соотношения. Совокупность подобных расходов именуется в методе прямых затрат косвенными затратами и детализируется исключительно по статьям расходов, без отнесения на продукцию.
Таким образом, метод прямых затрат не предоставляет данных для управления косвенными затратами. В рамках развития данного метода разрабатывались различные методики отнесения косвенных затрат на продукт (по объему продаж, по прямым затратам, по числу занятых и т.д.). Обычно эти методики применялись в том или ином сочетании, однако принцип условного отнесения затрат на продукт в противовес непосредственному отнесению прямых затрат оставался неизменным.
Невозможность управления косвенными затратами была несущественным недостатком в 1920–е – 1950–е гг., когда косвенные затраты составляли незначительную долю в себестоимости продукции. Однако после энергетического кризиса были предприняты масштабные меры по экономии сырья, материалов и электроэнергии, а также повышению производительности труда. Эти меры привели к снижению в себестоимости доли прямых затрат и соответственному росту доли затрат косвенных (рис. 7.12). В результате управление косвенными затратами стало центральной проблемой методологии управленческого учета в 1970–е–1980–е гг.
Рис. 7.12 Соотношение прямых и косвенных затрат.
Дата: 2019-03-05, просмотров: 308.
