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

Необходимо также обратить внимание, что подходы к выбору реше­ния ИТ, разработанные в настоящей теме, применимы в равной мере к анализу затрат на ИТ-решения бизнес-проектов. Поскольку источни­ки доходов от использования сервисов ИТ рассматривались в предыду­щей теме, для упрощения исследования все вопросы анализа затрат изложены здесь.

ИТ - решение как вторичный объект затрат.

В теме 9.1.2 было показано преимущество сервисов ИТ перед инфор­мационными системами в качестве объектов затрат. Это преимущество следовало из того, что бизнес выдвигает требования к сервисам ИТ, а не к информационным системам. Соответственно, при выборе информа­ционной системы как объекта затрат взаимосвязь между требования­ми бизнеса к сервисам ИТ и затратами на инфраструктуру ИТ стано­вится ненаблюдаемой.

Таким образом, сервис ИТ как объект затрат имеет преимущество прежде всего с точки зрения взаимодействия ИС и бизнес-подразделения, включая руководство предприятия, обеспечи­вая прозрачность ИС в разрезе взаимосвязи затрат и результатов.

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

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

· привязка ССВ ИТ-решения к параметрам бизнес-сервисов разрешает проблемы, присущие показателю ССВ информационной системы;

· ССВ ИТ-решения не отменяет ССВ сервиса ИТ Последняя остается основным объектом затрат как во взаимоотношениях с бизнесом, так и внутри ИС — как итоговый показатель. ССВ информационной сис­темы как экономический показатель альтернативна ССВ сервиса ИТ;

· в расчете ССВ ИТ-решения используются параметры сервисов ИТ: доступность, уровень, фактическая величина простоев. Таким обра­зом, ИТ-решение предполагает наличие в учете сервиса ИТ как объ­екта затрат. Именно поэтому здесь и далее в курсе лекций ИТ-решение рас­сматривается как вторичный объект затрат;

· ССВ ИТ-решений не носит всеобъемлющего характера. Суммарная ССВ ИТ-решений всегда меньше суммарной ССВ сервисов ИТ. Раз­ницу составляют функции планирования и управления сервисами, не связанные непосредственно ни с какими информационными система­ми. К таким функциям, например, относится функция планирования сервисов.

Рассмотрим реализацию концепции ССВ ИТ-решения в практике управленческого учета ИС. Схема расчета приведена на рис. 9.7. В та­кой модели каждой функции присваиваются дополнительные атрибуты. Они показывают, для какой именно информационной системы или ком­понента информационной системы выполняется функция. В ITSM дан­ные об информационных системах и их элементах хранятся в базе дан­ных позиций конфигурации (БДПК). Поэтому при использовании модели бизнес-процессов ITSM и процесса управления конфигурациями для пе­рехода к расширенной ФСА-модели достаточен один-единственный ат­рибут — позиция (позиции) БДПК, для которой (которых) выполнена функция.

Рис. 9. 7 Расширенная модель ФСА – расчет ССВ ИТ-решения.

Учет информационных систем, «ответственных» за простой того или иного сервиса, ведется аналогично: в базе данных процесса управления добавляется новый атрибут — позиция конфигурации, сбой которой вы­звал простой.

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

Таким образом, при сравнительно незначительном усложнении учет­ных процедур ITSM возможна точная привязка всех действий по сопро­вождению и поддержке, а также простоев пользователей к позициям конфигурации, вызвавшим эти действия или простои. В итоге появляет­ся возможность относить действия и простои не только на сервисы ИТ, но и на определенные позиции конфигурации, с которыми действия (про­стои) связаны. Необходимо отметить, что БДПК в ITSM иерархична, так что простой определенного устройства легко связать с простоем систе­мы, в которую данное устройство входило как составная часть. На осно­вании этой информации можно рассчитать ССВ ИТ-решения по форму­ле, аналогичной (9.1):

                                                                        ,                                              (9.1.)

где  

Si — ССВ i-й позиции конфигурации;

a _ij — число единиц фактора использования j-й функции, потреблен­ных за период;

r _jk — число единиц фактора затрат k-го ресурса на единицу фактора использования j-й функции;

C^r_k — цена единицы к-го ресурса;

t _ivm — время простоя m-й категории v-ro сервиса, связанного с i-й позицией конфигурации, в часах за период;

I _vm — цена одного часа простоя m-й категории v-ro сервиса.

Таким образом, если в ИС предприятия внедрена ФСА-модель опре­деления ССВ сервисов, то включение в рассмотрение единственного но­вого атрибута — позиции конфигурации в БДПК — позволяет рассчитать ССВ ИТ-решения за произвольный период по формуле (9.1). Иерархи­ческое построение БДПК позволяет произвольным образом укрупнять и разукрупнять ИТ-решения в расчете ССВ от программно-аппаратных комплексов до отдельных устройств.

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

Для прогноза ССВ необходимо оценить также продолжительность жизнен­ного цикла ИТ-решения — его «время жизни» и затраты на протяжении этого жизненного цикла. Именно с такими параметрами связано появле­ние прогнозной составляющей в модели ССВ на рис. 9.7.

Анализ затрат на протяжении жизненного цикла ИТ-решения по­зволяет определить следующие составляющие затрат: затраты на при­обретение и внедрение, на сопровождение, на модернизацию. Наконец, знание длительности жизненного цикла позволит определить момент за­мены решения в будущем.

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

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

Понятие технологического предела ИТ – решения.

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

Рис. 9. 8 Технологический предел ИТ-решения.

Все известные на сегодняшний день технологии характеризуются S-образной, или логистической, формой технологической кривой. Левая ее ветвь именуется Р. Фостером кривой обучения, правая — кри­вой убывающей отдачи. Всякая S-образная кривая характеризуется тех­нологическим пределом — значением показателя результата, которое не может быть превышено в рамках данной технологии.

Рассмотрим некоторые типичные примеры технологических пределов для ИТ-решений:

· предел производительности центрального процессора;

· предельный объем оперативной памяти;

· предельный объем дискового пространства;

· предельная пропускная способность системной шины;

· предельная пропускная способность активного сетевого оборудова­ния и каналов связи;

· предельное число одновременно работающих пользователей СУБД или бизнес-приложения;

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

На практике основу прогноза перспективных потребностей бизнеса составляет портфель утвержденных бизнес-проектов. При более дли­тельных сроках прогнозирования (3—5 лет) данные портфеля проектов дополняются данными ИТ-стратегии предприятия.

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

ССВ жизненного цикла ИТ-решения.

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

· затраты на сопровождение и администрирование, оплаченные про­стои пользователей. Эти расходы взаимозависимы; как было показа­но в поде 9.2.2, они определяются на основе данных СУС, техни­ческих возможностей ИС и параметров самих ИТ-решений. Прогноз потребностей пользователей в типичных случаях слабо влияет на за­траты этой группы;

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

Рассмотрим эти две группы подробнее:

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

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

· по аналогии с подобными сервисами в других подразделениях;

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

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

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

Оценка затрат на сопровождение и администрирование произво­дится аналогично оценке потерь от простоев. Если рассматриваемое ИТ-решение относится к существующему сервису, то прогноз строится с учетом данных СУС. Для вновь создаваемых сервисов доступна при­ближенная оценка затрат, получаемая теми же способами, что и оценка потерь от оплачиваемых простоев.

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

· политикой поставщика в области цен на первоначальную конфигу­рацию оборудования и/или ПО, а также последующее наращивание этой конфигурации;

· графиком возрастания потребностей бизнес-сервисов в ресурсах ИТ;

· техническими рисками рассматриваемого решения.

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

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

Поддержка бизнес-проектов.

В этой теме будет рассмотрена необходимость выделения работ по развитию инфраструктуры ИТ в отдельные проекты. Далее будут опре­делены соответствующие проекты и методика отнесения затрат на сер­висы ИТ.

Централизация ресурсов ИТ и необходимость выделения работ по созданию инфраструктуры в отдельные проекты.

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

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

Однако это решение далеко не всегда самое экономичное. Его побоч­ный результат — распыление ресурсов ИТ. Через несколько лет ведения такой политики на предприятии оказывается множество недорогих ма­ломощных серверов, также недорогих, но и не масштабируемых СУБД, возможно — несколько совместно используемых операционных систем, например Windows NT и Linux. Это повышает себестоимость сервисов ИТ сразу по нескольким направлениям:

· себестоимость администрирования и сопровождения. Каждый из мно­жества серверов и каждую из множества СУБД необходимо админис­трировать. Соответственно объем работ по администрированию со временем неконтролируемо возрастает. Между тем администриро­вание — одна из основных статей затрат на инфраструктуру ИТ. Аналогично при распылении ресурсов ИТ возрастают затраты на со­провождение, по крайней мере вследствие роста числа одновременно работающих устройств и программ и, соответственно, числа отказов того и другого;

· проблемы совместимости. Распыление ресурсов ИТ затрудняет про­ведение технической политики. Оптимизация инфраструктуры ИТ под конкретные бизнес-приложения ведет к применению разнообразных платформ. Хотя такой подход повышает производительность отдельно взятого бизнес-приложения, потенциально он порождает проблемы совместимости при совместной работе разнородных платформ, обме­не данными между ними и т.д. При достаточной длительности распы­ления ресурсов ИТ (не менее 3—5 лет) эта потенциальная угроза реа­лизуется с вероятностью, близкой к 100%;

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

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

· трудности маневра ресурсами ИТ. Неустранимая неточность про­гноза потребностей тех или иных бизнес-сервисов в ресурсах ИТ (производительности, оперативной памяти, дисковом пространстве и т.д.) порождает необходимость в резервных мощностях ИТ-реше­ний.

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

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

Учет затрат на проекты поддержки и отнесение их на себестоимость бизнес – сервисов ИТ.

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

Для методологически корректного решения данной проблемы пред­лагается относить затраты на проекты развития, относящиеся к новым сервисам, на временные объекты затрат. Схема такого учета приведе­на на рис. 9.9.

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

Пока нам важно следующее. Вплоть до момента сдачи в эксплуата­цию нового сервиса затраты на бизнес-проект учитываются на времен­ном объекте затрат. Расходы на проект поддержки также учитываются на временном объекте затрат вплоть до момента сдачи в эксплуатацию нового ресурса ИТ. После того как один или несколько новых серви­сов и/или ресурсов сдается в эксплуатацию, затраты на бизнес-проект списывают на вновь создаваемый сервис (сервисы). Затраты на про­ект поддержки списывают на стоимость вновь создаваемых ресурсов ИТ (рис. 9.6). Далее затраты на бизнес-проект амортизируются в соответ­ствии с оценкой времени жизни вновь созданного бизнес-сервиса и ис­пользованных в нем ИТ-решений. Затраты на проект поддержки амор­тизируются в соответствии с оценкой времени жизни вновь созданного ресурса ИТ. Стоимость вновь созданного ресурса распределяется между поддерживаемыми этим ресурсом бизнес-сервисами, согласно ФСА-модели, пропорционально факторам затрат и факторам использования.

Рис. 9.9 Учет затрат по временным объектам затрат и их последующее списание на сервисы ИТ.

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

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

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

Рис. 9.10 Схема принятия решений по проекту поддержки.