Как измерить принятие инструмента: почему число активных пользователей врёт
Отчёт о внедрении почти всегда начинается с числа активных пользователей. Оно приятно растёт в первый месяц, стабилизируется во второй и становится главным аргументом в разговоре об успехе проекта. При этом оно не отвечает на вопрос, ради которого внедрение затевалось.
Вход в систему не является работой в ней. Человек может открывать интерфейс ежедневно, смотреть на список задач и продолжать работать в переписке. В отчёте он — активный пользователь; в процессе его нет.
Принятие измеряется долей сценариев, полностью прошедших через инструмент, а не числом людей, которые в него заходят. Разница принципиальна: первая метрика падает при обходах и растёт только при реальном переходе, вторая растёт от любопытства и не падает почти никогда. Самоотчёты о частоте использования измеряют другую величину и с фактическим использованием связаны слабо.
Почему привычные метрики завышают картину
У каждой популярной метрики принятия есть свой механизм завышения, и все они действуют в одну сторону.
Число активных пользователей. Растёт от любопытства и от административного требования. Не различает человека, который провёл в системе рабочий день, и человека, который зашёл проверить, не появилось ли чего.
Число созданных записей. Растёт при дублировании: сотрудник создаёт запись для отчётности, а работает по-старому. Такая запись существует, но не отражает ни одного решения.
Опрос об удовлетворённости. Измеряет отношение, а не поведение. Люди отвечают вежливо, особенно когда опрос не анонимен, и отвечают о намерении, а не о факте.
Количество обращений в поддержку. Падает как при успешном внедрении, так и при отказе от инструмента. Без второй метрики отличить одно от другого невозможно.
| Метрика | Как завышает | Чем заменить |
|---|---|---|
| Активные пользователи | Считает вход как работу | Доля завершённых сценариев |
| Созданные записи | Считает дублирование как использование | Доля записей с заполненными обязательными полями |
| Удовлетворённость | Измеряет отношение вместо поведения | Доля работы, прошедшей мимо инструмента |
| Обращения в поддержку | Падает и при успехе, и при отказе | Та же доля обходов |
Третий столбец — весь набор, который нужен. Три метрики вместо четырёх, и все три падают при обходе, чего ни одна из привычных не делает.
Почему нельзя спрашивать людей, пользуются ли они системой
Соблазн заменить измерение опросом велик: опрос дешевле логов и не требует интеграции. Методологически это давно разобрано.
Самоотчётное использование системы и объективно зафиксированное в логах — это два разных конструкта, коррелирующих между собой слабо. Опираться на субъективные самоотчёты при оценке принятия системы методологически ненадёжно.
Здесь нужна честность: полный текст статьи закрыт подпиской, и я читал страницу метаданных с рефератом, а не саму работу. Точных коэффициентов корреляции поэтому не привожу. Вывод, который беру, — качественный и подтверждается практикой: величина, которую человек называет в опросе, и величина, которую показывает система, — разные, и путать их нельзя.
Что считать завершённым сценарием
Понятие завершённого сценария заимствовано из практики тестирования интерфейсов, где оно формализовано как основная метрика.
Доля успешно завершённых целевых задач ставится как ключевая, итоговая метрика взаимодействия с продуктом: если пользователь не смог довести задачу до конца, остальные показатели вторичны.
Это методическое руководство по лабораторному тестированию на выборках в четыре-пять человек, а не крупное измерение принятия в промышленной эксплуатации; перенос понятия на производственные данные я делаю по аналогии и это оговариваю. Ценность в определении: сценарий либо завершён, либо нет, промежуточных состояний нет. Именно бинарность делает метрику устойчивой к интерпретациям.
Сколько стоит неиспользуемое
Экономическая сторона вопроса измеряется отдельно, и цифры растут.
Доля непроизводительных расходов на облачные подписки выросла на 10 процентных пунктов год к году, а 59% опрошенных специалистов отметили рост таких трат именно на AI-инструменты.
Отчёт спонсирован поставщиком инструментов управления ИТ-активами — коммерческий интерес показать проблему острой присутствует, а полная методика расчёта закрыта формой; доля именно неиспользуемых лицензий на открытых страницах не раскрыта, там динамика расходов. Использую как индикатор направления: формальное покрытие лицензиями растёт быстрее, чем фактическое использование, и разрыв увеличивается.
Как построить измерение принятия
Прежде чем разбирать третью метрику, стоит сказать о первой: её определение — это управленческое решение, а не техническая настройка. Сценарий «обработка заявки» может считаться завершённым в момент, когда заявка закрыта в системе, а может — когда клиент получил ответ и это зафиксировано. Первое определение даёт красивую картину, второе — полезную. Выбор между ними делается один раз и определяет, что будет обсуждаться на каждой планёрке следующего года.
Вторая метрика — доля записей с заполненными обязательными полями — нужна как страховка от подмены. Без неё легко получить высокую долю завершённых сценариев за счёт того, что записи создаются формально: статус меняется, а содержание остаётся пустым. Две метрики вместе устойчивы к такой подмене, потому что закрыть сценарий формально можно, а заполнить обязательные поля осмысленными значениями — заметно труднее.
Третья метрика самая неудобная и самая ценная. Считается она не в самом инструменте, а по следам обхода: сколько документов создано вне системы, сколько решений принято в переписке, сколько задач появилось в другом месте. Точное значение получить трудно, но динамика доступна и её достаточно.
Первую метрику стоит определить до запуска, вместе с определением того, что считается завершённым сценарием. Задним числом это определение всегда подстраивается под полученные данные — о наблюдаемости процесса и замере «до» я писал отдельно.
Четыре шага к честному отчёту о внедрении
Определите завершённый сценарий до запуска
Одно предложение, бинарный признак. После запуска определение подстроится под данные.
Уберите активных пользователей из отчёта
Не дополните, а замените. Пока метрика в отчёте, обсуждать будут её.
Найдите следы обхода
Документы, письма, задачи вне системы. Достаточно динамики, точное значение не нужно.
Не спрашивайте людей о частоте использования
Самоотчёт и логи измеряют разное. Спрашивайте о том, что мешает, — это опрос даёт честно.
Метрика принятия, которая не может упасть, ничего не измеряет. Проверьте свою: при каком поведении сотрудников она снизится?
Вопросы, которые задают чаще всего
Как измерить adoption корпоративной системы?
По доле сценариев, полностью прошедших через систему, а не по числу активных пользователей. Сценарий считается завершённым, если все его шаги оставили след в системе: создание, изменение статуса, решение, результат. Дополняют картину две метрики — доля записей с заполненными обязательными полями и доля работы, прошедшей мимо инструмента.
Почему число активных пользователей — плохая метрика?
Потому что она не различает вход в систему и работу в ней и почти никогда не падает: она растёт от любопытства, от административного требования и от того, что интерфейс открыт в фоновой вкладке. Метрика, которая не может снизиться при отказе людей пользоваться инструментом, не измеряет принятие — она измеряет наличие доступа.
Можно ли оценить принятие опросом?
Не частоту использования — самоотчёт и объективные логи давно показано измеряют разные величины и связаны слабо. Опрос хорошо работает для другого вопроса: что мешает пользоваться. Здесь ответы конкретны и проверяемы, а результат сразу превращается в список исправлений, тогда как самооценка частоты не даёт ни того, ни другого.
Как считать долю работы, прошедшей мимо системы?
По следам в других каналах: документы, созданные вне системы, решения, принятые в переписке, задачи, заведённые в другом месте. Точное значение получить сложно, и оно не нужно — достаточно динамики за несколько месяцев. Рост этой доли при формально высоких показателях использования означает, что инструмент принят как отчётный, а не как рабочий.
Набор из трёх метрик принятия и способ поиска следов обхода — авторское обобщение практики внедрений CRM в трёх компаниях (digital-агентство, сезонное производство корпоративных подарков, платформа онлайн-записи) и практики сбора статистики по менеджерам в собственных продуктах Alego.Digital. Количественных замеров доли обходов в момент этих внедрений не велось, поэтому внутренних числовых метрик в статье не приводится. Все цифры взяты из внешних источников с указанными методами.
- Straub D., Limayem M., Karahanna-Evaristo E. Measuring System Usage: Implications for IS Theory Testing. Management Science, 41(8), 1995. ideas.repec.org
- Nielsen J., Budiu R. Success Rate: The Simplest Usability Metric. Nielsen Norman Group, 2001, ред. 2021. nngroup.com
- Flexera. 2026 State of ITAM Report, июнь 2026 (опрос 512 специалистов). flexera.com