Примечание редакции. Материал основан на реальном внедрении системы учёта иностранных сотрудников на предприятии. Данные заказчика обезличены: нас интересует не компания, а закономерность — почему рядом с внедрённой системой продолжает жить Excel. Та же логика применима к складу, производству и ERP: если процесс не перешёл в систему, проект формально «закрыт», а фактически — нет.
Система установлена. Обмен настроен. Данные передаются. Пользователи получили доступ. Инструкции подготовлены.
Формально проект можно закрывать.
Проходит неделя — и выясняется, что часть реального процесса продолжает существовать где-то рядом с информационной системой. В Excel. В Word. В локальных файлах. В ручных операциях.
И тогда появляется привычный вопрос: почему сотрудники не пользуются системой?
Мы тоже начали именно с него. И довольно быстро поняли: вопрос поставлен неправильно.
Кейс: система, которую сначала не хотели, а затем очень просили
На предприятии ведётся работа с иностранными сотрудниками. Ошибки в учёте документов здесь имеют не абстрактные последствия: некорректное отражение информации, пропущенные действия, риски, связанные со сроками документов и миграционным учётом. В отдельных случаях последствия становились критическими.
После одного серьёзного инцидента потребность в специализированной системе стала очевидной самим пользователям. До этого предложение внедрить её не получило достаточной поддержки. После инцидента сотрудники начали регулярно спрашивать о внедрении — и демонстрировали готовность ею пользоваться.
Позже решение внедрили: настроен обмен с 1С, автоматизирована передача данных, реализованы контроль документов и сроков, предусмотрены печатные формы.
Можно было ожидать, что после столь выраженного запроса пользователи быстро перейдут на новый процесс. Этого не произошло.
Первая ошибка: мы начали считать входы
Первоначальная формулировка проблемы выглядела логично: сотрудники редко заходят в систему. Значит, первой метрикой должна стать частота использования — количество входов, число активных пользователей, дни активности, время работы в системе.
Но это плохой способ оценивать внедрение. Пользователь может ежедневно открывать программу и не выполнять ни одного полезного действия. И наоборот: хорошо автоматизированная система иногда требует минимального участия человека.
Количество входов отвечает только на вопрос: «Пользователь открывал программу?» Оно не отвечает на главный: «Работает ли бизнес-процесс через систему?» Это принципиально разные вопросы.
Правильная формулировка проблемы
После уточнения фактической ситуации исходная гипотеза изменилась. Ключевые действия, ради которых система внедрялась, продолжают частично выполняться вне неё:
- документы не всегда вносятся в систему;
- сроки действия документов заполняются не полностью;
- для подготовки отдельных бланков по-прежнему используются Word и Excel;
- данные сотрудника повторно вводятся вручную, вместо того чтобы формировать документ на основании данных системы.
В одном из Excel-шаблонов данные заполняются даже посимвольно: отдельными буквами в отдельных ячейках. При этом пользователи характеризуют такой способ работы как удобный.
Именно здесь меняется предмет анализа:
Не «почему сотрудники не входят в программу?», а «какая доля реального бизнес-процесса выполняется в целевой системе?»
Excel — это не отсутствие системы. Это конкурирующая система
При внедрении корпоративного ПО часто предполагают, что новое решение конкурирует с отсутствием автоматизации. На практике это редко так.
У пользователя уже существует рабочий контур: Excel → Word → ручной ввод → печать → локальные проверки. Он может быть медленным, избыточным, рискованным и зависимым от конкретного сотрудника. Но для пользователя он знаком.
Новое корпоративное приложение конкурирует не с пустотой. Оно конкурирует с привычкой. Иногда — с целой системой сложившихся ролей и отношений.
«Так удобнее» не всегда означает «так быстрее»
Когда сотрудник утверждает, что ручное заполнение Excel удобнее автоматического формирования документа, первая реакция внедренца предсказуема: «Как это вообще может быть удобнее?»
Но для анализа такой вопрос мало полезен. Слово «удобно» может означать совершенно разные вещи:
- я знаю этот способ;
- я контролирую каждый шаг;
- я боюсь ошибиться в новой системе;
- мне не объяснили новый процесс;
- мне незачем менять привычку;
- существующий способ позволяет обходить часть контроля;
- новый процесс меняет мою роль.
Пока эти причины не проверены — всё перечисленное только гипотезы. И здесь особенно важно не подменять исследование психологическими объяснениями.
Связка с инструментом IDS
Пять рабочих гипотез совпадают с матрицей H1–H5
- H1 — нет мотивации менять процесс
- H2 — Excel / Word удобнее ERP
- H3 — нет доверия к данным
- H4 — нет организационного контроля
- H5 — функции системы не совпали с процессом
Скачать матрицу гипотез H1–H5 — бесплатное расширение для ERP / УТ / УНФ: метрики по живой базе для совещания.
У бизнеса и пользователя могут быть совершенно разные мотивы
Система внедрялась ради конкретной ценности для компании: снижение рисков нарушения миграционного законодательства, контроль сроков документов, меньше ошибок, меньше ручных операций, прозрачность процесса.
Но это ценность для бизнеса. Она не обязана автоматически становиться ценностью для конкретного сотрудника. Если последствия ошибки несёт прежде всего собственник, а исполнитель не ощущает связи между качеством своей работы и последствиями, организационная мотивация может существенно отличаться от продуктовой.
Есть и более сложная гипотеза. В организациях, где ценность сотрудника связывают с постоянной загруженностью и способностью «героически» решать проблемы, автоматизация может восприниматься не как помощь, а как угроза сложившейся роли. Если статус строится вокруг «смотрите, какую сложную работу я выполняю», сообщение «теперь эту операцию можно выполнить автоматически» может звучать совсем не как улучшение. Но и это должно быть проверено, а не принято на веру.
Где заканчивается проблема пользователя и начинается проблема управления
Есть соблазн назвать происходящее саботажем. Иногда это определение действительно справедливо. Но само по себе оно почти ничего не решает.
Гораздо полезнее задать другой вопрос: что произойдёт в организации, если обязательное действие в корпоративной системе просто не будет выполнено?
Если ответ — «ничего», то перед нами уже не только проблема пользователя. Это проблема конструкции самого процесса управления.
Корпоративная система может содержать отличную автоматизацию, но оставаться факультативным инструментом, если: нет владельца процесса; не определены обязательные действия; отсутствуют контрольные точки; альтернативный процесс официально не запрещён; невыполнение целевого процесса не становится видимым.
Технология не заменяет управленческое решение.
Какие метрики действительно показывают внедрение
Если отказаться от количества входов как главного показателя, появляется другая система измерений.
1. Полнота данных. Доля сотрудников с полным комплектом документов в системе, доля документов с заполненными сроками действия, количество документов без обязательных реквизитов, количество просроченных документов. Это характеристики качества самого информационного контура.
2. Выполнение целевых действий. Нужно измерять не присутствие пользователя, а события: создан документ, изменён документ, заполнен срок, скорректирован срок, выполнена проверка, сформирован бланк, напечатан документ. Так появляется ответ на вопрос: «Что пользователь действительно делает в системе?»
3. Доля процесса внутри системы. Одна из самых важных метрик: какая часть фактических операций выполняется в целевой системе, а какая остаётся во внешнем контуре. Например, для печатных форм — количество бланков, сформированных системой, к общему количеству подготовленных бланков.
Здесь возникает техническая сложность: система хорошо знает, что произошло внутри неё, но не знает, что пользователь сделал в Excel. Поэтому внешний процесс нельзя автоматически посчитать по отсутствию события в 1С — потребуются дополнительные источники данных или сверка с итоговым количеством бизнес-операций.
Самая интересная метрика — невыполненное действие
Обычная аналитика хорошо считает события: пользователь нажал, документ создан, отчёт сформирован. Для управленческой системы не менее важен другой класс событий: что должно было произойти, но не произошло?
Например: у сотрудника должен быть документ, но записи нет; документ требует срок действия, но срок не заполнен; срок уже истёк; новый документ появился, но не был обработан за нормативное время; обязательная проверка не выполнена.
Это уже не аналитика кликов. Это аналитика исполнения процесса. И для корпоративных информационных систем она зачастую значительно ценнее DAU, WAU и количества входов.
От журнала действий — к наблюдаемому процессу
Следующий шаг в нашем кейсе — автоматический механизм регистрации продуктовых событий. Необходимо фиксировать: кто (пользователь), когда (дата и время), что сделал (тип бизнес-события), с каким объектом (сотрудник, документ, организация), какой результат (создание, изменение, заполнение, печать, проверка).
Отдельный контрольный контур должен выявлять отсутствующие обязательные действия. Тогда архитектура выглядит так:
Это не система наблюдения за тем, сколько времени сотрудник провёл перед экраном. Это механизм наблюдаемости бизнес-процесса.
И здесь возникает важная этическая граница
Когда в проекте много сопротивления и накопленных конфликтов, аналитика легко превращается в оружие. Появляется желание доказать: «Вот, мы же говорили, что пользователи ничего не делают». Это плохая цель — в этот момент аналитик начинает искать подтверждения собственной позиции.
Правильная задача совсем другая: сделать процесс настолько наблюдаемым, чтобы спор о фактах потерял смысл.
Не «они саботируют», а «из необходимого объёма документов такая доля отражена в системе». Не «они всё делают вручную», а «через встроенный механизм за период сформировано столько-то документов». Факт не отменяет необходимости интерпретации — но он резко улучшает качество разговора.
А если данные покажут, что проблема вообще не в сотрудниках?
Это тоже возможный результат. Аналитика может обнаружить, что: функция используется редко, потому что действительно неудобна; часть обязательных данных невозможно корректно получить; процесс предполагает действия, которых нет в реальной работе; Excel закрывает сценарий, отсутствующий в системе; автоматизация увеличила количество шагов вместо их сокращения.
Тогда разработчику придётся признать: проблема в продукте. Это нормальный результат исследования. Потому что цель продуктовой аналитики — не доказать правоту автора системы. Цель — уменьшить неопределённость.
Данные не принимают решения. Они уменьшают пространство для иллюзий
В работе над этим кейсом мы пришли к формулировке, которая хорошо описывает границы аналитики:
Статистика не говорит, что будет. Она говорит, что происходило в наблюдаемых данных.
Это защищает от двух крайностей. Первая: «цифры знают всё». Нет — ни одна метрика не описывает организацию целиком. Вторая: «все эти цифры ничего не значат». Тоже нет — без наблюдений остаются ощущения, воспоминания, позиции участников конфликта и наиболее убедительные рассказы.
Данные не заменяют профессиональный опыт, понимание людей, знание контекста и управленческое решение. Но они дают ещё одну опору. И иногда именно её не хватает.
Инженерный вывод IDS №004
Настоящее внедрение начинается тогда, когда целевой бизнес-процесс действительно переходит в новую систему.
Вопрос «сколько человек вошло в программу?» почти ничего не говорит о результате проекта. Гораздо важнее спросить: какие обязательные действия должны происходить в системе? Какая их доля действительно происходит? Что должно было произойти, но не произошло? Где существует альтернативный процесс — и почему организация позволяет ему существовать?
Вопрос для руководителя
Какая доля реального бизнес-процесса в вашей компании выполняется в целевой системе — а какая продолжает жить в Excel, Word и головах сотрудников?
Что проверить у себя
Чек-лист после «успешного» внедрения
- Какие обязательные действия должны выполняться в системе?
- Какая их доля реально выполняется в ней?
- Где рядом с системой живут Excel и Word?
- Что происходит, если обязательное действие не выполнено?
- Какие решения система принимает вместо человека — а какие он всё ещё принимает вручную?
- Какие «невыполненные действия» вы можете увидеть сегодня?
Проверить гипотезы на своей базе
Скачайте матрицу гипотез H1–H5 — бесплатное расширение 1С: метрики по документам ERP / УТ / УНФ для совещания, почему процесс уходит в Excel. Или разберём ваш процесс внедрения: какая доля реально перешла в систему — до того, как проект закроют «по документам».
