ИТ-активы: фундамент, на котором держится бизнес
Когда говорят про управление компанией, обычно вспоминают стратегию, продажи, отчёты. Но редко кто задумывается: а на чём всё это держится?
Собственник смотрит на EBIT и EBITDA. Один показатель учитывает амортизацию активов, другой - нет. И да, собственнику важно видеть оба: чтобы понимать реальную прибыль и операционную эффективность. Но в обоих случаях он видит эти цифры через экран ноутбука. Менеджер принимает решение, глядя в монитор, который тянет данные с сервера в ЦОДе. Разработчик деплоит код на ту же инфраструктуру.
Каждое действие в компании, так или иначе, проходит через ИТ-актив.
Но чтобы активами управлять, их нужно сначала учесть. И тут начинается самое интересное. Активы - это не просто "железки". Из активов рождаются конфигурационные единицы (КЕ) - управляемые объекты, из которых состоит ИТ-инфраструктура. А из КЕ строится CMDB - база данных конфигураций, центральное хранилище, где видны все связи между компонентами. Без учёта активов нет КЕ. Без КЕ нет CMDB. Без CMDB ты не видишь, как устроен продукт. А если не видишь, как устроен продукт - ты не можешь управлять его доступностью, планировать изменения или анализировать инциденты. А без всего этого - не достигнешь бизнес-показателей: ни EBIT, ни EBITDA, ни ROI. Потому что все они считаются на основе данных, которые проходят через твою инфраструктуру. Поэтому управление ИТ-активами - это не про "поставить галочку". Это про фундамент, на котором держится весь бизнес.
В своей практике я не раз строил такие системы - от крупных промышленных холдингов до государственных проектов. И везде правило одно: без порядка в активах не будет порядка в управлении.
За порядком в этой системе стоят конкретные люди. В регламенте, который мы разработали, прописаны чёткие роли: кто отвечает за приёмку, кто за учёт, кто за выдачу, а кто за контроль. Это не просто "кто-то там что-то делает". Это слаженный механизм, где у каждого своя зона ответственности. И когда он работает - активы не теряются, инвентаризация не пугает, а бизнес видит реальную картину.
Прилагаю жизненный цикл ИТ-актива, который я проектировал в одном из проектов:
Общая схема процесса Это скелет всей системы. Видно, как активы проходят путь от поступления до выбытия.
Приёмка и принятие к учёту Всё начинается с приёмки. Если на этом этапе ошибка — она поедет дальше по всей цепочке Приёмка ИТ-активов Проверяем: "А то ли нам привезли?". Если нет - отправляем назад. Принятие к учёту ИТ-активов Актив зарегистрирован. Теперь он существует для системы. Маркировка ИТ-активов Каждый актив получает уникальный идентификатор. Теперь он не просто "железка", а управляемая единица.
Группа процессов Эксплуатация Дальше актив начинает работать. Его выдают, перемещают, ремонтируют, инвентаризируют. Выдача ИТ-активов Кому выдали? Где он? Ответственный - понятен; Перемещение ИТ-активов Актив переехал в другой отдел? Система это видит; Ремонт ИТ-активов Актив в ремонте - он не потерян, он на обслуживании; Инвентаризация ИТ-активов Сверка того, что есть в учёте, с тем, что лежит в стойках. Расхождения - не ошибка, а сигнал: либо мы что-то потеряли, либо кто-то не записал;
Выбытие ИТ-активов Списание с правильным оформлением, чтобы не платить налоги за то, чего уже нет.
Вот так выглядит полный жизненный цикл ИТ-актива. И именно с него начинается управление, прозрачность и, в конечном счёте, деньги бизнеса. #ИТактивы #ITAM #CMDB #управлениеИТ #ITSM #учетактивов #жизненныйцикл #инвентаризация #цифроваятрансформация #ИТинфраструктура #управлениеактивами #бизнес #эффективность #CIO #руководительИТ #методология #процессы #ГосТех #регламенты #порядок #финансы #EBIT #EBITDA #ROI
· 15.07
Хорошо, что вы уводите разговор от «железа» к активам, но я бы ещё разделял доступность сервиса и стоимость простоя - иначе легко оптимизировать загрузку серверов и потерять деньги. У вас есть простой способ связать это с SLO и инцидентами?
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответить
0
коммент удалён
· 15.07
Да, связываем. Мы привязывали доступность к SLO через Error Budget. Это лимит недоступности, который мы закладываем, исходя из цены минуты простоя. Инцидент становится критическим не по времени, а по доле сожжённого бюджета. Чем ближе к порогу - тем выше приоритет и быстрее реакция.
По сути, мы управляем не железом, а деньгами. Я как раз писал об этом в посте про расчёт доступности для ГосТех https://set.ki/post/UVFNE5i
Там выбор методики напрямую влиял на то, получит команда премию или заплатит штраф.
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответить
0
ответ удалён