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

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

  1. TCO учитывает только затратную часть инвестиций и не рассматривает их «полезное действие», то есть доходную часть или возврат на инвестиции (Return On Investment, ROI). В таком случае «незаслуженное» преимущество получают малозатратные решения, которые на практике малофункциональны и не всегда полезны.
  2. При расчетах TCO зачастую учитываются стандартные статьи бюджета без оценки возможных проектных рисков. С одной стороны, это нередко приводит к заключению контрактов с подрядчиками, стремящимися экономить на квалификации проектировщиков и технических специалистов. С другой – возникает риск принять решение в пользу разработки, а не приобретения готового программного продукта, соответствующего не только текущим, но и перспективным потребностям заказчика.
  3. Сложно получать достоверные значения по некоторым статьям затрат при расчетах TCO. Бухгалтерский учет изначально ориентирован на детализацию внешних расчетов без детализации расходов внутри организации. В этом случае обычно учитываются только затраты на приобретение и поддержку системы – без полного учета внутренних затрат. В результате преимущество также получают решения с низкой начальной стоимостью и ограниченной практической пригодностью.

Важное значение имеет выбор периода, в течение которого необходимо обеспечить минимизацию значения TCO. Меры по снижению TCO сводятся к поиску оптимального соотношения начальных и повременных затрат. Как правило, высокие начальные затраты оправдываются за счет снижения повременных затрат. Чем больше выбранный временной интервал, тем значительнее в TCO доля повременных затрат и тем большая сумма начальных затрат может быть обоснована. Иллюстрация соотношений величины TCO в разных временных интервалах для трех гипотетических вариантов реализации приведена на рис. 1.

Рис. 1. Варианты изменения TCO во времени

Для коротких временных интервалов [0 – Т1] предпочтительным представляется решение с наименьшими начальными затратами S1. Для среднего по времени периода [Т1 – Т2] наиболее выгодным является промежуточный вариант с умеренными начальными затратами S2. Однако для интервала [Т2 – Б?·] вариант с наибольшими начальными затратами S3 оказывается самым выгодным ввиду снижения повременных затрат (по сравнению с первыми двумя вариантами).

Нет смысла рассчитывать TCO системы управления в отрыве от обюектов управления, поскольку основной целью внедрения СУ ИТ обычно является снижение затрат на функционирование обюектов управления. Следовательно, расчет действительно совокупной стоимости владения должен выполняться для комплекса «система управления + обюекты управления». Следует подчеркнуть, что такой расчет требует серьезных трудозатрат квалифицированных специалистов.

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

  • эффективность – соответствие функциональным требованиям к СУ ИТ;
  • предсказуемость – минимум факторов риска при внедрении и эксплуатации;
  • рациональность – минимальная величина TCO, рассчитанная для комплекса «система управления + обюекты управления».

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

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

Соответствие требованиям к рациональности заключается в расчете величин TCO для сравниваемых вариантов СУ ИТ с учетом следующих допущений:

  • TCO рассчитывается на предполагаемый срок морального устаревания СУ ИТ (на три года);
  • если вклад некоторых показателей затрат заведомо незначителен или приблизительно одинаков для всех вариантов СУ ИТ, то они, по согласованию с заказчиком, не рассчитываются как не влияющие на выбор.

Для информационных систем, к которым относятся и СУ ИТ, обычно учитываются следующие группы затрат:

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

В некоторых случаях рекомендуется расчет и других затрат [1], являющихся следствием сбоев:

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

В процессе расчета оставшихся факторов затрат между ними имеется достаточно сильная зависимость (Рис. 2).

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

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

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

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

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

Удобство и скорость выполнения управляющих (в том числе диагностирующих) воздействий легко оценивать с помощью приведенной в [3] методики GOMS (Goals, Objects, Methods, and Selection rules). Возможные ошибки персонала, как показано в [4], обычно связаны с модальностью интерфейса – неоднозначностью результата отработки управляющим приложением команды (жеста) оператора, который определяется неизвестным оператору внутренним состоянием системы. Например, при попытке управляющего воздействия на один обюект управления фактическое воздействие оказывается и на другой обюект, так как оба они физически размещаются на одном сервере, а в качестве единственного параметра запуска приложения, выполняющего управляющее воздействие, используется одинаковый для этих обюектов сетевой адрес сервера.

Рассчитанные значения длительности решения задач второй группы будут в дальнейшем использоваться при сравнении стоимости простоя обюектов управления для различных вариантов реализации системы управления. Время t решения одной задачи из второй группы будет равно сумме времени отработки управляющим приложением команды (жеста) оператора, времени считывания и анализа результатов выполнения. Общая почасовая трудоемкость решения задач второй группы T = N*t, где N – количество возникающих за 1 час задач этой группы, а t – время решения одной такой задачи. Выразив полученную трудоемкость T в часах и разделив ее на допустимый коэффициент загрузки одного сотрудника (<1), можно рассчитать требуемую численность эксплуатирующего персонала. Если режим работы персонала отличается от 5 дней в неделю по 8 часов в день, то необходимо применить повышающий коэффициент с учетом сменности (при семидневке по 24 часа в сутки он будет превышать 4). Далее на основании рассчитанных значений численности персонала и требований со стороны обюектов управления для каждого варианта реализации СУ ИТ можно рассчитать стоимость приобретаемых или разрабатываемых программ и оборудования, а также затраты на их внедрение.

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

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

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

  1. Нарушена работа пользователей и сервисов, потеряна часть данных.
  2. Нарушена работа пользователей и сервисов, данные не утеряны.
  3. Нарушена работа пользователей, сервисы и данные не затронуты.
  4. Работа в целом не нарушена, но есть снижение производительности.
  5. Работа и производительность не нарушены.

Для каждого типа сбоя существует своя модель расчета.

Литература
  1. M. Liotine. Mission-Critical Network Planning. Norwood: Artech House. 2003.
  2. Дж. Пирс. Символы, сигналы, шумы: закономерности и процессы передачи информации. б- М.: Мир, 1967.
  3. Wayne Gray, Bonnie John, Michael Atwood. Project Ernestine: Validating a GOMS Analysis for Predicting and Explaining Real-World Task Performance. Human-Computer Interaction, 8:3, 1993.
  4. Д. Раскин. Интерфейс: новые направления в проектировании компьютерных систем. б- СПб.: Символ-Плюс, 2004.
  5. Г. Н. Калянов. Теория и практика реорганизации бизнес-процессов. б- Серия «Реинжиниринг бизнеса». б- М.: Синтег, 2000.

Игорь Щетинин (shchetinin@i-teco.ru) – руководитель отдела технического проектирования компании «Ай-Теко» (Москва).

Несущественные затраты

Некоторыми статьями расходов, весьма трудоемкими для расчетов, но не влияющими на выбор, удается пренебречь. Это, например:

  • совокупные затраты на нахождение оборудования системы управления в одной серверной комнате с оборудованием обюектов управления будут приблизительно одинаковыми для всех вариантов;
  • стоимость самоподдержки и взаимной поддержки пользователей обычно относится к вопросам использования обюектов управления, которые в данное время исправны и не требуют вмешательства со стороны СУ ИТ и ее операторов.

Феномен снижения TCO

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

Рассмотрим сервер c 128 Мбайт оперативной памяти и балансовой стоимостью 2000 долл. Проект предусматривает установку управляющего приложения (агента), занимающего 16 Мбайт оперативной памяти сервера. Если оперативная память является наиболее загруженным ресурсом, то при расчетах TCO можно принять стоимость 1 Мбайта памяти устройства 2000/128 = 16 долл., а стоимость потребляемого ресурса – 256 долл. Если же установить на сервер дополнительный модуль памяти на 128 Мбайт за 30 долл., то стоимость занимаемого ресурса составит примерно 130 долл., а с учетом затрат на модуль памяти – 160 долл.

Несколько советов

Можно выявить следующие особенности применения методики расчета TCO для систем управления ИТ-инфраструктурой:

  • несмотря на важность показателя TCO, в том числе как одного из возможных требований аудита, хочется предостеречь от его использования в качестве критерия сравнения информационных систем;
  • для сравнения информационных систем рекомендуется использовать комплексный критерий, включающий в себя TCO как одну из составных частей;
  • в случае применения СУ ИТ рекомендуем выполнять комплексный расчет TCO для совокупности «система управления + обюекты управления»;
  • трудоемкость расчета TCO для СУ ИТ может быть существенно снижена, если выполнить расчет удобства и скорости работы персонала СУ ИТ, а также (без ущерба для точности сравнения) отказаться от расчетов несущественных или одинаковых для всех вариантов реализации СУ ИТ затрат;
  • в некоторых случаях можно снизить TCO путем дополнительных затрат на модернизацию обюектов управления.

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