Особенность внедрения новых процессов на предприятии

[hedgeov]

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

Запись сделана с помощью приложения LiveJournal для Android.

Comments

[hedgeov.livejournal.com]

Давай, рассказывай :-)
Я представлял так: у команды скорость работы (ну или производительность) X. При внедрении нового процесса она упадет примерно втрое (X/3). Это надо бы принять во внимание до того как согласуешь сроки с заказчиком. А если видно, что с новым процессом команда все равно не успевает, мне кажется надо двигать сроки, но не отказываться от следования процессу. Или это неверно?
Ну а про санкции при отклонении от нового процесса — а как иначе выводить людей из старой зоны комфорта и упихивать в новую? Добровольно им и сейчас хорошо.

[helgaolga.livejournal.com]

Главное - правильное планирование. Сопротивление новому это нормальное свойство человеков, которое нужно учитывать, давая время на адаптацию или усиливая команду временными проектными ресурсами. То есть надо предусматривать не возможность сдвига сроков (это вообще нонсенс кроме некоторого contingency), а доп время или ресурсы. Причем сразу надо планировать каким образом будет проходить адаптация, так что это не просто доп время, а конкретные действия как часть плана.

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

Вообще в последних двух моих проектах мы делали вот что. В первом мы снизили kpi на время проекта, так как люди были незаменимы. Плюс провели "маркетинг" новой системы и после запуска все их результаты смотрели только в ней. Тестирование было на маленькой группе из тех, кто любит новое (она всегда есть такая группа).

В другом проекте мы наняли доп ресурсы для тестирования и на подхвате. Кроме того, внедренцы сопровождали первые три цикла работы в новой системе (sap). Там при первой попытке внедрения народ массово сбежал, в основном из-за перегруза в проекте и работы в новой системе. В нашем проекте гораздо мягче все прошло. Всегда надо учитывать, что на первые циклы работы в новом процессе требуется БОЛЬШЕ времени и сил, за это надо поощрять, а не наказывать.

[helgaolga.livejournal.com]

А если ПМ уже нафакапил с планированием сроков, то сдвиг сроков это одно из решений. Вариантов обычно три: двигать сроки, вливать деньги (на пооектные ресурсы или премии), добавлять ресурсы. Это решает sponsor, то есть главный заказчик (а не ПМ на стороне заказчика). При этом сдвиг сроков это не просто дубинка, чтобы заставить работать по-новому. Это надо копаться и совместно планировать действия. Обычно это означает, что либо система тупо неудобна, либо плохо обучили новому, либо в новом процессе роли не расставили. Последние два чаще всего.

[hedgeov.livejournal.com]

А что делать, если по общему мнению коллектива "и сейчас хорошо, а директор самодур"?

[helgaolga.livejournal.com]

Все то же самое. Хотя, кому делать?
Это нормальное сопротивление изменениям, всегда найдутся те, кто с любопытством поддержит, большинство, которому просто лень меняться и те, кто до последнего будет сопротивляться. Надо максимально включать в проект первых и давать им возможность говорить. Банально, плакатики расклеивать по стенам с фото и текстом от них на тему "как мне понравилось тестировать новую ШТУКУ (систему, процесс, кнопочку, ...)

А директору - лучше делать свою работу директора.

[http://users.livejournal.com/__kirill__/]

В этом случае никакой дубиной дела не исправишь, и вариантов тут два:

1. Таки прав коллектив.

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