Портал №1 по управлению цифровыми
и информационными технологиями

CMDB: как начать доверять финансовой информации?

Опубликовано 1 ноября 2015
Рубрики: Обо всём на свете
Комментарии

Принятие_решения_2Каждый проект по внедрению процесса управления активами и конфигурациями по-своему индивидуален. В каждом проекте формируются какие-то свои ключевые задачи и особым образом расставляются приоритеты. Построенные технические решения учитывают какую-то определённую специфику заказчика.

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

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

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

Помимо собственно организационно-технического решения, построенного вокруг ITSM-системы, необходимы инструменты, позволяющие осуществлять сверку финансовой информации, поступающей из других систем учёта. Например, некие "сверочные" отчёты. Причём, автоматизация такой сверки может оказаться затруднительной, если имеют место договоры в валюте, отличной от национальной. Необходимо также регламентировать в ролевой модели процесса структуру ответственности за обеспечение консистентности финансовой информации.

В общем, вопрос крайне интересный. Консистентность финансовой информации в CMDB даёт нам возможность заложить надёжный фундамент для построения, в дальнейшем, подробной финансовой модели услуг.

Поэтому очень хотелось бы услышать о вашем опыте, уважаемые коллеги! Поделитесь, пожалуйста, своими идеями и опытом – как же начать доверять финансовой информации в CMDB?

Комментариев: 7

  • Алексей Юсов

    В правильно заданном вопросе содержится более половины ответа ))

    какие сложности возникают на пути к финансовой модели услуг, базой для которой является, конечно же, грамотно построенная CMDB и обслуживающий её комплекс процессов

    Да особо не каких, если CMDB и комплекс процессов построены не то чтобы даже очень грамотно, а просто построены средне, и они работают.

    А далее всё просто. У нас есть связка  Услуга – КЕ. Посколько все приходные документы на ИТ-КЕ проходят через ИТ, нет проблем заводить сразу с данными о стоимости и периоде амортизации. Лицензии по этой же схеме.

    Все затраты на поддержку по Услугам можно посчитать из Инцидентов и Запросов.

    Не вижу проблем сделать регламентный отчёт с расчётом амортизационной стоимости КЕ и стомости затрат на поддержку по Услуге на базе связей.

    Проблемы начинаются тогда, когда Заказчик начинает хотеть видеть разрезы стоимости услуг по подразделениям. А данных по потреблению услуг нельзя посчитать. Но и это решается не запредельными трудами.

    • А далее всё просто. У нас есть связка  Услуга — КЕ. Посколько все приходные документы на ИТ-КЕ проходят через ИТ, нет проблем заводить сразу с данными о стоимости и периоде амортизации. Лицензии по этой же схеме.

      Все затраты на поддержку по Услугам можно посчитать из Инцидентов и Запросов.

      Идеологически – да, все просто. Но дьявол-то в мелочах, а мелочей здесь достаточно:

      1. необходим учет использования расходных материалов и комплектующих, ведь их стоимость относится на ту или иную КЕ не в момент заведения приходных документов. Аналогично требуется учет использования лицензий на ПО;

      2. связи услуги-КЕ в реальной архитектуре всегда многоуровневые, поэтому расчет получается многоступенчатым, например по МВЗ;

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

      4. для учета в ТСО стоимости персонала потребуется операционный каталог и ФСУ.

      Проблемы начинаются тогда, когда Заказчик начинает хотеть видеть разрезы стоимости услуг по подразделениям

      А без разрезов (различных – не только по потребителям услуг, но и, например, филиалам, видам затрат и так далее) этот расчет вообще не очень нужен, поскольку ИТОГО действительно есть всегда (в бухгалтерской системе). Но расчет нужен не сам по себе, а как основа для управления затратами, которое возможно постольку, поскольку вы видите эти зараты в разрезах, получаете возможность сравнивать, аналилизровать.

      В итоге "все просто" на практике превращается во "все довольно непросто".

  • Алексей Юсов

    читать – да особо *никаких*. И редактировать нельзя. А нельзя же так оставить)))

  • Сергей

    Вопрос в том, что считать затратами, которые нужно учитывать. Из перечисленного списка

    закупочная стоимость;

    стоимость сопровождения, привязанная к периоду;

    затраты на негарантийные ремонты;

    затраты на расходные материалы и комплектующие;

    затраты на лицензии ПО.

    У нас три выделенных пункта попадают первоначально в CMDB и только потом в бухгалтерскую систему, так что затраты сразу есть. Аналогично можно учитывать затраты на ремонты – нет ничего сложного в том, чтобы привязать счета за ремонты к активам/КЕ. Но пока такой задачи не стояло. На фоне остальных затрат это копейки. 

    Самое интересное, это стоимость сопровождения. Что считать стоимостью и что есть сопровождение? На первый взгляд, все упирается в учет рабочего времени в привязе к КЕ. Другой вопрос – зачем это делать? Бизнес интересует только ИТОГО. В детали никто не хочет вникать.

    • Алексей Юсов

      Самое интересное, это стоимость сопровождения. Что считать стоимостью и что есть сопровождение? На первый взгляд, все упирается в учет рабочего времени в привязе к КЕ. Другой вопрос — зачем это делать? Бизнес интересует только ИТОГО. В детали никто не хочет вникать.

      Если не считать "детали", то "ИТОГО" будет взять неоткуда.

       

      • Сергей

        Весьма спорное утверждение.

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

        • Алексей Юсов

          ИТОГО есть всегда.

          Весьма спорное утверждение )) Смотря что под этим понимать.

           


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM