Почему команда не работает в системе.

Коротко: «люди не хотят работать в системе» — почти всегда неверный диагноз. В девяти случаях из десяти система требует действий, которые не помогают сотруднику сделать его работу, или требует их дважды. Это лечится на этапе проектирования, а не регламентом и штрафами.

Пять причин.

1. Система не повторяет реальный процесс. В жизни заказ согласовывают с цехом до отправки КП, а в системе этого шага нет — значит, половина работы живёт мимо неё. Лечится картой процессов до разработки, а не после.

2. Двойной ввод. Данные набивают и в систему, и в привычную таблицу. Пока таблица жива, выиграет таблица: она быстрее. Убирать нужно не таблицу приказом, а причину, по которой она удобнее.

3. Нет выгоды для самого сотрудника. Если заполнение карточки нужно только для отчёта руководителю, его будут делать в последний день месяца и задним числом. Если из той же карточки автоматически собирается КП и ставится напоминание — её заполняют сразу.

4. Обучение «один раз и на всех». Полуторачасовая демонстрация всей системы забывается за неделю. Работает другое: короткое обучение по ролям и инструкция на одну страницу для каждой роли.

5. Нет владельца процесса. Когда за систему отвечает подрядчик, а не человек внутри компании, любое неудобство копится молча до момента, когда «всё плохо, вернёмся в таблицы».

Что сделать на этапе проектирования.

1. 01Опишите рабочий день каждой роли, а не функции системы. Экран должен открываться на том, что человек делает чаще всего.
2. 02Посчитайте клики на типовое действие. Если приём заявки занимает больше десяти — упрощайте, пока не станет меньше.
3. 03Сделайте обязательными только те поля, без которых заказ физически нельзя передать дальше. Остальные — по желанию.
4. 04Выдайте каждому экрану ответ на вопрос «что мне это даёт»: автоподстановка, готовый документ, напоминание, подсказка.
5. 05Назначьте владельца процесса со стороны компании до старта разработки, а не после запуска.

Что делать после запуска.

Первые две недели — не контроль, а наблюдение. Полезно смотреть три вещи: какие поля остаются пустыми, где сотрудники возвращаются в мессенджер и какие действия делают «в обход» через примечание. Каждый такой случай — не нарушение регламента, а баг проектирования.

Главное. Штраф за незаполненную карточку даёт заполненные карточки, а не работающий процесс. Поля начнут заполнять формально — и отчёты станут хуже, чем были без системы.

В наших проектах неделя «Внедряем» заканчивается не обучением, а списком правок по обратной связи от команды. Он и показывает, что система принята.