У семи нянек — сервер без ответственного

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

У семи нянек дитя без глазу. У российского бизнеса всё солиднее: нянек пять-семь, дитя — сервер, а глазу нет вообще ни у кого.

Каждая нянька при этом уверена, что справляется. Финансы знают, сколько дитя стоит. Закупки помнят, у кого его купили. ИБ выдала ему пропуск. ИТ иногда протирает пыль. Спросите любую — всё под контролем. Спросите, где дитя сейчас и что с ним — начнётся неловкая пауза.

По данным исследования SimpleOne (более 100 российских компаний), ответственность за ИТ-активы официально закреплена сразу за пятью-семью подразделениями.

Чаще всего называют ИТ-инфраструктуру — но и она берёт актив на себя только в 36% случаев. То есть в двух компаниях из трёх судьбу сервера решает финансист, закупщик, безопасник или просто тот, кто первым не успел отвернуться.

Оставшиеся почти две трети ответственности распределены между финансами, закупками, ИБ и бизнес-подразделениями, которые берут технику «по запросу». У актива нет одного ответственного — есть несколько, и доля каждого слишком мала, чтобы считать это владением. 

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

Кто на самом деле отвечает за активы

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

• Финансы: актив на балансе, амортизируем. Для нас это строка в реестре, а не железка в серверной.

• Закупки: договор закрыт, вопрос снят.

• ИБ: доступы настроены — правда, часть пользователей уже уволилась.

• ИТ: оборудование работает, вроде ничей. 

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

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

Вот что оказалось в списке: 

• Эксплуатация оборудования (выдача, перемещение, ремонт, инвентаризация) — 19%

• Учет использования ПО — 17%

• Дискаверинг и планирование закупок — по 13%

• Учет затрат на поддержание инфраструктуры — 13%

• Учет контрактных обязательств и планирование ИТ-бюджета — по 11%

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

Ещё показательнее другая цифра: 80% компаний оценивают зрелость своих ITAM-процессов на 1–3 из 5.

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

Почему это не чья-то вина

У закупок отличная система: сумма, срок, дата продления, менеджер вендора. Финдиректор спрашивает «сколько платим за лицензии Х» — ответ за две минуты.

А ИТ спрашивает: «этот договор ещё нужен, сервер под него используется?» — и тишина. Система про физическое состояние железа ничего не знает и знать не должна. У закупок просто нет повода этим интересоваться.

Так каждый отдел честно улучшает свой участок и проблемы не видит. Она живёт в стыке между системами — а стыком в компании не занимается никто. Данных, как правило, навалом. Просто они друг с другом не разговаривают.

«Назначьте ответственного» этот разрыв не закрывает

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

А узнать неоткуда. Актив списали в другой системе, доступ поменяли, сервер переехал — никто не сообщит. Остаётся ручная сверка. Которую делают не каждую неделю, а раз в квартал. Или на аудите. Или когда что-то упало.

Получается смешное: отдел назначили ответственным полгода назад, он честно делает свою работу — а этот конкретный сервер последний раз видел в отчёте два года назад. Между регламентом и реальностью просто нет канала, который обновляется сам.

Почему много ответственных — это ноль ответственных

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

Списанный сервер, за который продолжают платить

Сервер демонтировали или он просто простаивает. А договор поддержки на него живёт своей жизнью — закупки же не в курсе, что ИТ вывело железку из эксплуатации.

При парке в несколько сотен единиц такие «зомби-контракты» всплывают не сразу: обычно на годовом пересмотре бюджета.

Всё это время компания исправно платит за поддержку сервера, которого физически нет

Разрыв между балансом и физическим наличием

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

Причина простая: переезды, ремонты, увольнения и списания «по устной договорённости» в систему попадают не всегда. Каждое такое событие оставляет расхождение — и всплывает оно только на инвентаризации.

А дальше начинается детектив: кто, когда и куда перевёз актив, никто не помнит.

Ответ собирают руками по логам пяти систем, потому что одной карточки, где всё видно, просто нет. 

Невозврат при увольнении

Сотрудник уволился. Простой вопрос: всю ли технику он сдал?

При разрозненном учёте ответ ищут не часы, а дни. Кадры закрывают заявку по своему регламенту. ИТ сверяется со своим списком выдачи. Безопасность смотрит в журнал доступов. Три версии — и ни одна не сходится с другими автоматически.

Пока разбираются, ноутбук всё ещё у бывшего сотрудника, а доступ к корпоративным системам у него всё ещё открыт.

И это уже не про деньги, а про безопасность 

Пропущенное продление лицензий

Договор на лицензию лежит в почте у закупщика. ИТ его не видит — значит, для ИТ его как бы и нет.

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

Дальше — экстренная закупка по прайсу вместо планового продления по контракту

Ремонты без истории

Одну и ту же технику по очереди чинят три разных подрядчика через три разных заявки, и никто не видит, что это уже четвёртый ремонт одной и той же детали — история обслуживания разбита по заявкам, а не собрана по активу.

Дело не в том, что кто-то халтурит. Каждый отдел свою часть сделал. Цена возникает именно в стыках между их данными, и накопленная стоимость этих разрывов — то, ради чего дальше в этой статье имеет смысл говорить о едином реестре, а не об очередном регламенте. Часть учёта у каждой пятой компании до сих пор ведется в Excel, который никто не синхронизирует с остальными базами — и это тоже одна из причин, почему разрывы между отделами не закрываются сами.

К тому же выводу пришли и участники исследования — мы проводили его вместе с ГК Softline, «Инфосистемами Джет», «Системным Софтом» и ITGLOBAL.COM.

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

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

Что делать, если ответственность уже размазана

Разбираться с раздробленной ответственностью проще по шагам, чем через разовый пересмотр регламента, который забудут через полгода. Ниже — последовательность, которая ведет не к новой должности «владелец всех активов», а к рабочему источнику данных.

Начните с ревизии того, что уже фиксируется

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

Найдите точки, где данные расходятся или отсутствуют

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

Определите один источник правды для каждого типа данных

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

Сведите данные в единый реестр с полным жизненным циклом актива

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

Настройте автоматическое обновление статуса вместо ручной сверки

Как только карточка обновляется по факту действия — выдачи, ремонта, продления — вопрос «кто отвечает» решается по последнему событию в системе, а не по строке в регламенте, которую забыли обновить.

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

Здесь эту роль берут на себя специализированные ITAM-системы, например SimpleOne ITAM — они становятся источником, куда данные попадают из систем каждого отдела и остаются связанными между собой.

Резюме

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

***

Сколько подразделений вашей компании назовут себя ответственными за один и тот же сервер — и совпадут ли их ответы, если спросить каждого по отдельности?