Четыре вопроса управления ИТ-активами

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

• Зачем?
• Что?
• Кто?
• Как?

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

Не верите? Попробую вас убедить.

Это главный вопрос и отвечать на него приходится не только при подготовке проекта, но и на всём его протяжении, а также и в дальнейшем, в процессе анализа результатов ежедневной операционной деятельности. Первый из этих "Зачем?" следует адресовать процессу в целом. Действительно, а для чего нам нужен процесс управления активами?

Изначально для фиксации результатов инвентаризации наши предки использовали знаковую, узловую и цветовую запись. Сегодня же мы обладаем мощными информационными системами, позволяющими, помимо собственно учёта, строить всевозможные аналитические отчёты, которые жизненно необходимы всё для тех же целей – для рационального ведения хозяйственной деятельности. Как и много веков назад, двигателем развития технологий является не что иное, как бизнес! Поэтому неслучайно, говоря об информационных технологиях, снова и снова мы повторяем, как мантру: "Цели бизнеса определяют цели ИТ". И именно поэтому, отвечая на вопрос "Зачем?" применительно к процессу управления ИТ-активами, следует, в первую очередь, разобраться, для принятия каких управленческих решений необходима информация об ИТ-активах. Чтобы это понять, крайне важно вовлечь в проект руководителей "правильного" уровня ответственности. Вполне возможно, что "уверенность в себе", о которой упоминал Франц Кафка, для каждого из них будет иметь какое-то вполне определённое содержание.

Желаете конкретный пример? Пожалуйста! Чтобы не оперировать абстрактными понятиями, в рамках данной статьи мы будем разбирать "живой" пример внедрения управления ИТ-активами. А именно, недавно реализованный нашей командой проект, упомянутый в начале статьи.

Заказчиком проекта выступала выделенная ИТ-организация в составе государственной структуры.

Кратко перечислим наиболее существенные области, в которых "бизнесу" требовалось принимать управленческие решения относительно ИТ-активов:

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

Соответственно, целью проекта было обеспечить все эти "Зачем?" ресурсами в виде формализованных процессов и показателей, распределённых ролей, поддерживающих технологий.

Детальный анализ перечисленных областей позволил сформировать подробный перечень требований "бизнеса" к организации управления ИТ-активами. Далее перечислены наиболее существенные:

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

Только получив подобные сведения, можно переходить к ответу на следующий существенный вопрос управления ИТ-активами. Ещё раз подчеркну, что вопрос "Зачем?" является основополагающим, то есть определяющим всю нашу с вами дальнейшую деятельность в рамках проекта (вспоминаем про SMART-цели).

Этот вопрос достаточно многогранен. Применительно к нашему процессу полная версия вопроса в зависимости от контекста может звучать как "Что делать?" или "Что учитывать/регистрировать?".

Первый из них достаточно подробно описан в различных методических источниках. Однако трактовки процесса в этих источниках различаются. Например, библиотека ITIL предлагает нам целый комплекс процессов, объединённых под общим названием, но сфокусированных преимущественно на управлении конфигурациями (с точки зрения конфигураций ИТ-услуг и связей между их компонентами), а не материальными ИТ-активами. Библиотека COBIT5, в свою очередь, рассматривает два отдельных процесса – управление активами и управление конфигурациями. И, конечно, нельзя забывать о библиотеке компании IAITAM, доступной далеко не всем и представляющей собой наиболее полный комплекс процессов управления всеми возможными видами ИТ-активов.

Обилие методик и подходов может вызвать у неподготовленного человека желание отказаться от столь сложной затеи. Но не стоит пугаться сложных моделей! Их задача – показать нам с вами, какие деятельности должны выполняться в идеальной картине мира, то есть внедряемого процесса! А наша задача – выбрать из них те, которые для нас действительно важны и обеспечивают достижение сформулированных бизнес-целей. Как? Очень просто – ответив на вопрос "Зачем?"!

В упомянутом ранее проекте задачу проектирования процесса (ответа на вопрос "Что делать?") удалось решить с помощью библиотеки COBIT5. В ней, во-первых, процессы управления активами и конфигурациями отделены друг от друга, что обеспечивает необходимый фокус при проектировании. Во-вторых, для каждого процесса определены ключевые виды деятельности, задачи, входы и выходы, метрики, матрицы ролей. Рассмотрим предлагаемую COBIT5 модель более подробно.

Согласно COBIT5, процесс управления ИТ-активами включает следующие виды деятельности:

• идентификация и учёт активов;
• управление критическими активами;
• управление жизненным циклом активов;
• оптимизация активов;
• управление лицензиями ПО.

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

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

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

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

Информация о необходимости осуществления закупки может поступать в процесс несколькими способами, например:

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

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

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

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

К таким задачам относятся:

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

Теперь вернёмся ко второй формулировке вопроса "Что?", а именно "Что учитывать/регистрировать?".

Какая информация и о каких ИТ-активах должна учитываться и накапливаться – вопрос весьма острый. "Никто не обнимет необъятного", как сказал вымышленный писатель Козьма Петрович Прутков. Одним из "камней преткновения" является необходимость учёта рабочих станций. Чтобы разобраться с этим, нужно опять-таки ответить себе на вопрос "Зачем?". В вышеупомянутом проекте ответ был прост и очевиден. Вспоминаем пункты из перечня бизнес-потребностей про необходимость подробного материального учёта и, одновременно, ограничение охвата обслуживания. Не располагая информацией о том, где и кем эксплуатируются те или иные рабочие станции, мы не смогли бы эти требования выполнить. Соответственно ответ звучал, как "да, будем учитывать". Столь подробный учёт привёл к появлению в базе конфигураций порядка 15 тысяч позиций. В более крупных структурах число позиций может быть ещё больше. Но, как говорится, цель оправдывает средства. По каждой единице оборудования ИТ-организация теперь располагает полной информацией о её характеристиках, производителе, пользователе, а также может легко идентифицировать оборудование, которое не находится на обслуживании.

Рассмотрим другой пример – организацию со свои "родным" ИТ-департаментом. В данном случае может оказаться, что для целей учёта рабочих станций достаточно информации в бухгалтерской системе. А для ИТ-департамента намного более ценной является информация о "железе", задействованном в предоставлении ИТ-услуг. В таком случае учёт рабочих станций в базе конфигураций, скорее всего, несёт больше трудностей, чем пользы. А основной акцент в проекте будет на управление конфигурациями ИТ-услуг, а не на управление ИТ-активами.

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

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

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

Крайне важно также правильно выбрать сотрудника на роль менеджера процесса. Например, назначение на эту роль функциональных руководителей слишком высокого ранга таит в себе серьёзные опасности. Такой руководитель, как может оказаться, слишком загружен другими делами, чтобы полноценно участвовать в проектировании процесса и определении функциональных требований к системе автоматизации. В таком случае эта задача de facto делегируется подчинённым, которые были изначально приглашены в качестве экспертов по узкому кругу вопросов, и которые, скорее всего, не обладают необходимой широтой видения. В результате выработанное решение не будет учитывать всех существенных аспектов деятельности организации, не будет отвечать потребностям всех заинтересованных сторон. А это значительный шаг на пути к провалу всего проекта. В дальнейшем подобный руководитель также может оказаться не в состоянии полноценно управлять процессом в силу своей загруженности. А без заботливого пастуха участники процесса могут начать "щипать траву" в обход регламента, не по инструкции. К чему это приведёт – объяснять, я думаю, не надо. Вывод: при выборе кандидата на роль менеджера процесса внимательно проанализируйте, действительно ли у него есть объективная возможность исполнять данную роль.

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

Резюме к рассматриваемому вопросу следующее – проектируя каждый шаг процесса, не забудьте спросить себя: "А кто это будет делать?". И выберите тех, кто действительно способен и достаточно мотивирован.

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

Иногда на этот вопрос пытаются ответить первым. В результате о первых трёх либо вообще забывают (это, конечно, не про нас с вами), либо не уделяют им должного внимания до тех пор, пока недостаточная их проработка не даёт о себе знать.

В рамках данного пункта мы снова вернёмся к рассматриваемому проекту и кратко пройдёмся по некоторым аспектам технического решения в части задач, сформулированных при ответе на вопрос "Зачем?".

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

Данные требования объединены в один пункт не случайно. Планирование закупок оборудования осуществляется не только на базе заявок на закупку от пользователей. Важным аспектом является "проактивное" планирование, которое осуществляется на основе информации об истечении сроков гарантии и полезного использования. Сроки полезного использования – типовые, наследуются из категории оборудования.

Обеспечение закупок и ввода в эксплуатацию только оборудования, внесённого в перечень допустимого

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

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

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

Контроль охвата обслуживания (исключение обслуживания стороннего оборудования)

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

Наличие инструментария для проведения инвентаризаций на удалённых объектах

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

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

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

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

А что помогает окрепнуть вашему чувству уверенности, когда речь идёт об управлении ИТ-активами?