Почему системами не пользуются и как это предотвратить

Система сдана. Технически всё работает — сервер в порядке, ошибок нет, отчёты выглядят красиво.

Через три месяца вы заходите в цех и видите: кладовщик по-прежнему пишет в журнал. Продавец уточняет остаток по телефону. Бухгалтер в конце месяца вносит всё вручную.

Система есть. Ею никто не пользуется.

Это самый дорогой и самый частый исход. И он почти никогда не связан с техническими причинами.

Пять реальных причин

1. Для сотрудника нет выгоды

Система строится для руководства: отчёты, контроль, показатели. Для кладовщика это дополнительная работа — теперь нужно вносить и в журнал, и в экран.

Если система не облегчает работу сотрудника, ею не будут пользоваться. Это не саботаж, а логика.

2. Страх контроля

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

Теперь всё остаётся в записи. Люди боятся не системы, а прозрачности.

3. Не вовлекли в процесс

Систему спускают сверху. Сотрудник однажды видит новый экран, и его обязывают в нём работать.

Его мнения не спросили, реальные условия работы не учли. В результате интерфейс удобен в офисе и неудобен в цеху.

4. У системы нет владельца

Проект завершён, команда ушла. Возник вопрос — к кому обращаться? Пришёл новый сотрудник — кто его обучит? Изменился процесс — кто обновит систему?

Система без владельца постепенно устаревает, и через год её бросают.

5. Старый способ остался открытым

Журнал лежит на месте. Файл Excel по-прежнему работает. Заказы продолжают приниматься в группе Telegram.

Когда есть два пути, люди выбирают знакомый. Это естественно.

Три этапа: что и когда делать

Принятие начинается не в день запуска. Оно начинается до проекта и продолжается после него.

До проекта: три обязательных шага

1. Назначьте владельца системы.

Это не обязательно человек из IT — наоборот, лучше тот, кто хорошо знает процесс. Главный бухгалтер, начальник производства или операционный директор.

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

2. Выберите одного-двух представителей от каждого отдела.

Эти люди участвуют в проекте: тестируют интерфейс, дают обратную связь, присутствуют на демо. Потом они обучают коллег.

Важно: выбирайте не самого опытного, а самого уважаемого сотрудника. Люди учатся не у назначенного преподавателя, а у коллеги, которому доверяют.

3. Объявите правила заранее.

Что меняется, что остаётся, как считаются опоздания, будут ли удержания в первый месяц. Скажите это до включения системы, а не после.

Неопределённость — главный источник сопротивления. Люди боятся не изменений, а неизвестности.

В ходе проекта: тестируйте в правильном месте

Система, спроектированная из офиса, в цеху не работает.

Условия цеха другие: перчатки, пыль, недостаток света, спешка. На складе тоже иначе — человек передвигается, у него в руках товар.

Проводите каждое демо на рабочем месте. Пусть представитель протестирует терминал в реальных условиях. Часто именно тогда выясняется, что кнопки мелкие, полей много, а процесс длинный.

В ходе проекта такие правки дёшевы. После запуска — дороги.

При запуске: четыре правила

• Месяц параллельной работы — старый способ не закрывается сразу
• Никаких удержаний в первый месяц — данные собираются, но последствий нет
• Обучение малыми группами и на рабочем месте, а не в большом зале
• Ответ на вопрос в течение дня — при задержке человек возвращается к старому

Четвёртое упускают чаще всего. Сотрудник задал вопрос и три дня ждал ответа — больше он не спросит и вернётся к журналу.

В первый месяц вопросов много, и они должны получать быстрый ответ. Это временная нагрузка, но именно она решает судьбу системы.

Когда закрывать старый способ

Момент деликатный. Закроете рано — работа встанет. Закроете поздно — не закроете никогда.

Рабочий порядок:

На третий месяц журнал физически убирается, а файл Excel уходит в архив. Выглядит жёстко, но без этого две системы годами живут параллельно.

Как измерить принятие

На вопрос «работает ли система» нужен точный ответ. Четыре показателя:

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

Проверить просто: зайдите в цех и посмотрите.

Чья это работа

Скажем прямо: принятие — не только задача команды разработки.

Что делает команда: адаптирует интерфейс под реальные условия, работает с представителями, обучает, быстро отвечает на вопросы, находится рядом в первый месяц.

Что делает руководство: назначает владельца, объявляет правила, закрывает старый способ и само пользуется системой.

Последнее неожиданно важно. Если руководитель спрашивает цифру не в системе, а у бухгалтера, сотрудники понимают это мгновенно — и тоже не пользуются.

Итог

Работать технически и работать в бизнесе — две разные вещи. Первое зона ответственности команды, второе — совместная работа.

Практические шаги:

1. До проекта назначьте владельца системы, и пусть это войдёт в его обязанности
2. Подключите к проекту одного-двух уважаемых сотрудников из каждого отдела
3. Объявите правила заранее, а не после включения системы
4. В первый месяц не применяйте удержания и отвечайте на вопросы за день
5. На третий месяц физически закройте старый способ
6. Раз в квартал заходите в цех и смотрите, нет ли там журнала