Просмотров: 448

Нужно начать  с общего сбора причастного к процессу персонала и объяснить им, что вы хотите сделать, почему вы этого хотите и чего рассчитываете добиться. Можно этим и пренебречь, но тогда возникнет несколько проблем. Не понимая причин изменений и ваших целей, сотрудники в любом случае придумают свои и будут в это верить. Насколько их и ваше видение совпадёт – большой вопрос. А если они решат, что всё задумывается для того, чтобы сделать им жизнь сложнее, могут и саботаж включить. 
С другой стороны, в процессе собрания у сотрудников возникнут резонные замечания или предложения. И тогда ваше усовершенствование может либо измениться, либо доработаться. Как бы то ни было, вы даёте людям возможность вовлечения в процесс. Если вы действительно внедрите те доработки, которые они выскажут, то и мотивация их будет выше. Разве это плохо?

После того, как всех собрали, обсудили, доработали, можно уже пробовать пилотный запуск процесса «на кошках». В идеале, если применимо, лучше взять реальную ситуацию из прошлого и отработать на ней процесс по-новому. «Тяжело в учении – легко в бою». Если сразу погружать сотрудников в «боевые» условия, велика вероятность различного рода несостыковок. Лучше потратить время на изучение регламентов и прогнать несколько учебных циклов процесса, поправляя ошибки, чем разгребать реальные проблемы в случае мгновенного внедрения нового процесса. Всё это выглядит достаточно очевидно, но на практике зачастую бывает, что начальство махнёт рукой и скажет – «фигня война, главное манёвры. Надо ввязаться в бой, там посмотрим». И смотрят потом на минусы на счету…Поэтому сначала запускаем тренировочные циклы до того момента, пока процесс не будет исполняться, как задумано. Ну и потом уже «масштабируемся», как сейчас модно говорить. То есть, выводим действие процесса в реальные условия.

Нужен взгляд со стороны, чтобы найти решение?

Спрашивайте напрямую или прочитайте мою статью по теме.