Аудитория: ИТ-менеджер, ИТ-администратор, руководитель (через админа). Закрывает вопросы: №5 («почему I_eff = 0.66, кто посчитал?»), №6 («можно ли накрутить?»). Сценарий: S7 — руководитель не верит цифре эффективности.
В продукте две метрики эффективности, и обе считаются сервером из входов, а не вводятся и не «зашиты» готовыми:
- I_eff (Фаза 1) — эффективность по данным аудита (опрос + юридический риск + класс ПО).
Отвечает на вопрос «правильно ли мы вообще владеем этим ПО».
- I_eff_ops (Фаза 2) — операционная эффективность по логам активности. Отвечает на
вопрос «реально ли используются оплаченные лицензии».
Цифра не совпадает у разных арендаторов с разными входами — именно потому, что это расчёт, а не клон. Формулы продублированы один-в-один на сервере и во фронте (близнец-контракт) — «одна правда формул».
Функция i_eff_for_system(software_class, s_survey, k_legal_risk):
I_eff = (S_survey / 5) · (1 − K_legal_risk)| Вход | Что значит |
|---|---|
S_survey (0..5) | оценка из опроса владельцев: насколько ПО нужно/используется |
K_legal_risk (0/1) | 1 = просрочка/контрафакт/нет прав → обнуляет эффективность |
software_class | «Инфраструктурное» (антивирус/ОС/виртуализация) → 1.00 (критично, не опрашивается) |
Особые случаи (почему бывает 0.00):
K_legal_risk = 1→ 0.00 (юридическая проблема перевешивает всё).- Нет
S_survey(опрос не проведён, информационная лакуна) → 0.00. Это не «плохо
работает», а «нет данных» — лечится проведением опроса, а не спором с метрикой.
Функция i_eff_ops(...). Аддитивная формула CDTO:
I_eff_ops = (0.5 · K_lic + 0.5 · I_int_act) · K_hw_overhead · (1 − K_security_risk)| Множитель | Что значит | Откуда |
|---|---|---|
K_lic = min(1, U_act / U_paid) | доля оплаченных лицензий, что реально используются | из логов: активные пользователи / оплаченные места |
I_int_act | средняя интенсивность: доля отработанных дней от нормы у активных пользователей | из логов |
K_hw_overhead | поправка на накладные расходы среды (0..1) | явный вход сида (колонка hw_overhead) |
K_security_risk (0/1) | 1 = Shadow IT/риск → обнуляет эффективность | явный вход сида (колонка security_risk) |
Принцип честности: лог-производные (K_lic, I_int_act) считаются из реальной телеметрии activity_facts; средовые (K_hw_overhead, K_security_risk) — это явные входы (заданные в данных систем), а не «выведенные из воздуха». Их видно и можно объяснить.
Кто считается активным пользователем (is_active_user): ≥10 транзакций за месяц ИЛИ активен в ≥5 рабочих днях. U_paid = наблюдаемые места min(lic_count, 20) (телеметрии по всем лицензиям нет — это выборка, так и фреймится).
classify_efficiency(i_eff):
| Значение | Класс | Смысл |
|---|---|---|
≥ 0.75 | high | используется хорошо |
0.50 .. 0.75 | satisfactory | приемлемо, есть резерв |
< 0.50 | low | недоиспользование / проблема |
На примере живого стенда у artek: averageIEffOps = 0.6585, systemsCovered = 6. Чтобы обосновать конкретную систему, разложите её на множители (есть в payload /ops-efficiency):
- `K_lic` — сколько из оплаченных мест реально активны. Низкий → «платим за неиспользуемые
лицензии» (прямая экономия при сокращении).
- `I_int_act` — насколько интенсивно работают те, кто активен. Низкий → ПО открывают, но
почти не используют.
- `K_hw_overhead` — поправка среды (например, 0.85). Виден явно.
- `K_security_risk` — если 1, итог 0.00 независимо от остального (например, ПО попало
в Shadow IT). Это не «ошибка расчёта», а сигнал: сначала закрыть риск.
Ключевой аргумент против недоверия: метрика воспроизводима из сырых логов. Тест приёмки e2e заново агрегирует I_eff_ops из строк activity_facts и получает то же число — то есть цифра не «нарисована», её можно пересчитать из первички.
Да, наивную метрику можно накрутить, открыв окно программы на весь день. Поэтому есть adjusted-расчёт:
Ложная активность (is_false_activity_day): день с активной по минутам сессией (session_minutes ≥ 60), но почти без транзакций (tx_count < 2) — кандидат на накрутку (открытое окно/idle). Вadjusted-расчёте такой день не засчитывается активным.
В payload рядом с raw приходят iEffOpsAdjusted, uActAdjusted, filteredUserDays — видно, сколько «дней-пустышек» отфильтровано и как просела эффективность после очистки. Это прокси честного сигнала (WEF 4688/4689 + DLP Active Window). Демонстрируется на арендаторе РГГУ (геймеры на MS Office дают ~24 отфильтрованных юзеро-дня, adjusted < raw); artek оставлен «чистым» (raw == adjusted == 0.6585), чтобы базовый инвариант не сдвигался.
- `/efficiency` — таблица систем с
I_eff_ops, секция «Операционная эффективность»,
дельта-блок raw → adjusted.
- `/risks` — Shadow IT (что обнуляет
K_security_risk). - API:
GET /api/{tenant}/ops-efficiency—breakdown(high/satisfactory/low, среднее,
covered) + по системам с разложением на множители.
- 0.00 ≠ «сломалось». Чаще это
K_legal_risk=1,K_security_risk=1или отсутствие
S_survey/логов. Сначала смотрите вход, потом делайте вывод.
- `covered`/среднее зависят от наличия логов. Система без телеметрии не попадает в покрытие
— это вопрос подключения источника (статья 04), а не расчёта.
- Не сравнивайте арендаторов «в лоб». Разные входы (норма, парк, классы) → разные базы;
метрика осмысленна внутри арендатора и в динамике.
Связанные статьи: 04 — Механизм сбора · 02 — ПДн и Vault.