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

Но увидеть возможность для улучшения ещё не означает рассказать о ней организации.

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

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

Возникает вполне рациональный вопрос: что получит сотрудник в результате?

Иногда успешное улучшение приводит не к признанию вклада и высвобождению времени, а просто к увеличению нагрузки. Если операция стала выполняться быстрее, освободившееся время сразу заполняют новыми задачами. Автор идеи может сделать вывод, что сообщать об экономии было невыгодно.

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

Иногда предложение воспринимается как критика действующего порядка или работы конкретного руководителя. В такой среде безопаснее продолжать привычный процесс, чем задавать вопрос: «Почему мы вообще это делаем?»

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

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

Поэтому призыва «Будьте инициативнее» недостаточно. Нужен понятный маршрут:

- куда направить наблюдение или идею; - кто поможет оценить эффект и риски; - можно ли выделить время на прототип или пилот; - кто примет решение по результатам проверки; - когда локальное решение перейдёт под ответственность ИТ; - как будет признан вклад автора.

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

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

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

Что в вашей практике сильнее мешает инициативам снизу: отсутствие времени, страх дополнительной ответственности, реакция руководителей или непонятная судьба предложенной идеи?