Нечастая практика: ручная инвентаризация ИТ-оборудования

Инвентаризация оборудования нужна для оценки стоимости ИТ-активов, организации процессов техподдержки, расчета стоимости услуг и для дальнейшей возможной оптимизации парка техники. Руководитель группы Управления ИТ-сервисов компании «Онланта» (ГК ЛАНИТ) Александр Сушко рассказывает, как компания «Онланта» провела инвентаризацию ИТ-активов для заказчика, имеющего 84 площадки в 83 регионах, включая Москву и Санкт-Петербург как отдельные территориальные единицы, и почему проведение ручной инвентаризации в этом кейсе оказалось единственным возможным решением.

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

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

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

Задача заказчика

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

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

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

Информация по учтенному у заказчика оборудованию была на 50-60 % неактуальна. Оборудование закупалось головным офисом и рассылалось по филиалам. Головной офис вел таблицу учета ушедшего оборудования в Excel. Филиалы же не предоставляли информацию о реальном состоянии оборудования обратно в головной офис. Каждый региональный филиал был обособленной единицей и вел хозяйственную деятельность самостоятельно. Заказчику требовалось актуализировать свои данные, чтобы понять, какие финансовые затраты по ремонту и закупке оборудования предстоят в будущем.

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

Ручную инвентаризацию мы решили проводить силами экспертов нашей компании и с помощью заказчика, который предоставил исходную информацию по технике. Для крупных филиалов (до 100 АРМ) инвентаризацию на месте проводил один инженер, в филиалах с численностью свыше 100 АРМ было выделено два специалиста. У руководителя группы технической поддержки «Онланты» всего находилось в подчинении около 90 человек.

Мы получили огромный поток данных в таблицах Excel от маленьких филиалов до главных офисов в Москве и Московской области. В каждой таблице содержалось от 20-30 до 200-300 позиций, и наши сотрудники проверяли информацию и вручную вносили корректировки. Через квартал мы проводили сверку повторно: выясняли, какое оборудование сломалось, отремонтировано или списано – эта работа также проводилась в ручном режиме. После создания процесса учета конфигурационных единиц и их изменений нам удалось перевести часть работ в автоматический режим. Мы связали учет конфигураций с нашей ITSM-системой заявок, и теперь, когда оборудование ломается, «библиотекарю» уходит заявка на изменение статуса данной техники.

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

Распределение оборудования на группы

Мы создали электронную таблицу с нужным количеством листов по группам.

 

 

Группы оборудования можно объединить или дробить в зависимости от ИТ-ландшафта заказчика.

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

 

Распределение конфигурационных единиц (КЕ) по группам (указывать название на английском из столбца «Категория КЕ»)

(Кликните на изображение для увеличения)

 

Статусы конфигурационных единиц (указывать название на английском из нижеперечисленных вариантов)

 

Идентификация оборудования

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

В результате у нас сформировалась примерно такая таблица для серверов и СХД. Для прочего оборудования из таблицы мы убирали колонки HDD.

 

 (Кликните на изображение для увеличения)

 

Инвентарный номер присваивается компанией, которая берет оборудование на обслуживание. Внутри компании он создается по определенным критериям.

Мы создали единый формат идентификатора с учетом следующих данных:

  1. Название компании.
  2. Регион (например, общегосударственный номер региона).
  3. Город (трехбуквенное обозначение на транслите, например, MSK, SPB и т. д.).
  4. Группа техники (например, servh – сервер физический, virt – сервер виртуальный и т. д.).
  5. Порядковый номер устройства (начинаем с 00001 и прибавляем по единице).

В итоге получили идентификационный номер – GOSORG-50-KLN-SERVH-00001.

Инструкция

Инструкция для проведения инвентаризации и маркировки оборудования в «правильных» ИT-компаниях либо уже существует в базе знаний, либо пишется под каждый проект адресно. Наша инструкция разрабатывалась с учетом базы знаний, которая уже существовала в компании. Этап выполнения инструкции занял полтора месяца. Этап сверки полученных данных проходил в течение двух месяцев. Этап уточнения информации с заказчиком занял также месяц. Следующая инвентаризация оборудования была проведена через квартал. Весь процесс инвентаризации занял два квартала. Спустя год после проведения очередной инвентаризации наши инженеры начали внедрять ПО для автоматического учета ИT-оборудования.

 

Пример отчета конфигурационных единиц

(Кликните на изображение для увеличения)

 

Шаблон регистрации или изменения статуса конфигурационных единиц

(Кликните на изображение для увеличения)

 

Шаблон таблицы инвентаризации и маркировки оборудования

(Кликните на изображение для увеличения)

 

Корректировка инструкции

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

Нам пришлось определить стандартные названия для оборудования, просить у инженеров уточнения, если модели оборудования были не прописаны. Например, была линейка серверов с двумя моделями разных поколений, сильно отличающихся по стоимости. Из-за этого возникала путаница с точной идентификацией оборудования. Мы столкнулись с человеческим фактором: иногда инженерам было просто «лень» уточнить модель и они вносили в таблицу данные, не уточняя конфигурацию. Была ситуация, когда один филиал долгое время не списывал свою технику. В итоге обнаружилось, что помимо серверной, часть оборудования хранилась в другом помещении. Это помещение оказалось полностью забито техникой от пола до потолка. Количество техники, которую нужно было инвентаризировать, увеличилось вдвое. 
  1. Одну и ту же модель оборудования указывали по-разному. В итоге мы получили больше видов техники, чем есть на самом деле. Для иллюстрации приведу пример из автомобильной индустрии. Существуют разные комплектации автомобилей: Nissan X-TRAIL XE, Nissan X-TRAIL XE+, Nissan X-TRAIL SE. При этом в таблице можно указать, например, Nissan X-TRAIL, а в другом случае Nissan X-TRAIL XE.
  2. Полное или частичное отсутствие идентификационных данных оборудования. С устройства при эксплуатации могли «слететь» все наклейки (если марка и модель не выгравированы на корпусе). Наклейки печатаются на обычном принтере или с помощью отдельных машинок для маркировки техники и печати этикеток – они недолговечны. Однако в серверах или в коммутационных устройствах, как правило, можно узнать марку и модель в командной строке. Также можно сравнить бухгалтерскую документацию с имеющимся оборудованием и идентифицировать технику «по остаточному принципу».

Идентификационные данные отсутствовали на некоторых «самосборных» ПК. Пришлось решить, как вообще их маркировать. Мы решили использовать марку и модель процессора. Например, системный блок на основе Intel Core i3-xxxx или системный блок на основе AMD Athlon 64 xxxx. Не имеет смысла перечислять все параметры ПК: если он уже установлен на рабочем месте и выполняет свои задачи, его характеристики не так важны.

По результатам внесли в инструкции соответствующие корректировки, добавили пункты про единообразие названий и отсутствие идентификационных данных. Затем поставили инженерам на местах задачу провести вторую, контрольную, инвентаризацию. Единообразие создается заказчиком. Если у заказчика «зоопарк», то все названия приводятся к единому стандарту, который либо согласовывается с Заказчиком, либо отдается полностью на усмотрение эксплуатирующей компании. Прямой контроль производит ответственное лицо: РП, РГ, старший инженер или библиотекарь CMDB.

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

Дальнейшая автоматизация инвентаризации оборудования

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

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

Сейчас учет оборудования происходит следующим образом. Например, возьмем сервер – к этой конфигурационной единице привязаны другие конфигурационные единицы: жесткий диск, процессор, оперативная память. При поломке у сервера одного из шести жёстких дисков мы обозначаем в системе ограниченную функциональность сервера, так как один жёсткий влияет на работоспособность сервера, но не останавливает ее. У жесткого диска в ITSM-системе меняется статус на «Поломка». Этот статус висит, пока деталь не отремонтируют (в данном случае заменят). В системе появляется заявка, она проходит этапы согласования: «Отправить в ремонт» или «Списать». Заявка уходит библиотекарю, он меняет статус в CMDB-системе (либо статус меняется автоматически при выполнении определенных действий в системе). Как только ремонт завершен или деталь заменена, инженер на месте закрывает заявку, указывает новый статус. Заявка обратно проходит те же самые периоды, библиотекарь меняет статус на «В работе», «Заменена».

 

(Кликните на изображение для увеличения)

 

Что в итоге

Заказчик получил полную картину состояния и качества своей ИТ-инфраструктуры: сейчас в нашей системе зарегистрировано свыше 14 700 конфигурационных единиц. Теперь заказчик может корректнее планировать бюджет на закупку новой техники и/или ремонты старой. Для центрального офиса появилась прозрачность работы филиалов в части закупки и эксплуатации оборудования. Мы получили возможность актуализировать перечень услуг по поддержке техники, а также предложить заказчику возможный «тюнинг», апгрейд и/или замену устаревшей техники.

Стоит отметить, что мы полагались на квалификацию и разумность инженеров на месте. Поэтому мы не исключаем, что ручная инвентаризация имеет некоторый процент погрешности - примерно 5 %. Данную погрешность можно снизить до 0,1 % после внедрения ПО для автоматического учета.

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

Автор: Александр Сушко, руководитель группы Управления ИТ-сервисов компании «Онланта» (ГК ЛАНИТ)

Автор: Александр Абрамов.

Тематики: Интеграция

Ключевые слова: ЛАНИТ