Анализ зрелости ITAM в РФ: почему 80% компаний не справляются с учетом активов

Зрелость как следствие архитектуры

Только 18% опрошенных используют выделенные ITAM-системы; 42% не применяют никаких стандартов, а среди применяющих доминирует ITIL 4 (38%). Базовые приоритеты — учёт оборудования (30%), планирование закупок (21%) и контроль лицензий (20%). Эксперты исследования прямо указывают корневую причину: один и тот же актив фигурирует в бухгалтерии, Service Desk и локальных таблицах с расхождениями, и определить его владельца однозначно невозможно. Это классический случай нескольких систем-источников без консистентной репликации — задача, которую в инфраструктурном коде привыкли решать через единый реестр и идемпотентную синхронизацию, а в ITAM по-прежнему справляются вручную.

Схематично проблему «трёх реестров» можно свести к минимальному примеру несогласованности:

```sql

-- Один и тот же ноутбук, три источника, три версии правды

SELECT * FROM accounting.assets WHERE inventory_no = 'NB-00421';

-- assigned_to: 'Отдел маркетинга', location: '—'

SELECT * FROM servicedesk.assets WHERE inventory_no = 'NB-00421';

-- assigned_to: 'Иванов И.И.', location: 'Москва, офис Б'

SELECT * FROM excel_upload.assets WHERE inventory_no = 'NB-00421';

-- assigned_to: '—', location: 'СПб, склад'

```

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

Что это меняет для разработчика

Из исследования следует несколько практичных выводов. Во-первых, интеграционный слой ITAM ↔ ITSM ↔ ERP ↔ мониторинг — это ближайшая зона роста: компании будут уходить от разрозненных учёток к API-ориентированной связке, а значит, вырастет спрос на инженеров, способных проектировать такие контуры. Во-вторых, фокус смещается с физического оборудования на облачные ресурсы, SaaS-подписки и лицензии — то есть на сущности, которые живут в биллинговых API вендоров и требуют регулярной сверки. В-третьих, эксперты ожидают, что расчёт TCO станет стандартом обоснования ИТ-бюджетов, а внедрение ИИ будет использоваться для прогнозирования закупок и выявления аномалий — прямой запрос на data-pipeline и модели anomaly detection поверх событийного потока от ITAM.

Минимальный шаг, который можно сделать уже сейчас, — зафиксировать в инфраструктурном коде канонический идентификатор актива и запретить дрейф источников:

```python

# pseudo: канонический asset_id и запрет на дрейф

def upsert_asset(source: str, payload: dict) -> None:

asset_id = payload["inventory_no"]

if not asset_id:

raise ValueError("inventory_no is mandatory")

canonical = canonical_store.get(asset_id) or {}

if canonical.get("frozen_by") and canonical["frozen_by"]!= source:

raise ConflictError(

f"asset {asset_id} is frozen by {canonical['frozen_by']}, "

f"source {source} cannot mutate"

)

canonical_store.merge(asset_id, payload, source=source)

emit_event("asset.updated", asset_id=asset_id, source=source)

```

Что отслеживать

• Расширение доли выделенных ITAM-систем и закрепление ITIL 4 как фактического стандарта.

• Появление открытых API и коннекторов у российских ITAM-вендоров к отечественным ERP и Service Desk.

• Регуляторные требования к лицензионному соответствию — они прямо повлияют на приоритет проектов по учёту ПО.

• Первые внедрения ИИ-модулей прогнозирования закупок и обнаружения аномалий в составе ITAM-платформ.

Среди болей, зафиксированных опросом, лидируют несвоевременное обслуживание и поломки оборудования (22%), срывы сроков из-за долгих согласований на выдачу и перемещение техники (20%) и неустановленные потери оборудования (19%). Каждый из этих пунктов — про отсутствие единого источника правды, и именно эту инженерную задачу рынок будет решать в первую очередь.