четверг, 9 января 2014 г.

Управление изменениями в бизнесе



В последнее время у меня выработалась стойкая аллергия на фразы вроде "реорганизация", "повышение эффективности" и прочие модные лозунги. Ясное дело - изменения необходимы. Окружающая среда как река, и мы гребем против течения. Перестанем грести - унесет. Ключевой вопрос тем не менее - что именно и как менять? Так вот - слишком часто необходимость "реорганизаций" преувеличена и за ней скрывается непонимание реальных проблем. Кроме того сам подход подразумевает наличие четкого плана действий,  и что мы достоверно знаем к какому результату приведут наши действия. А это очень часто не так :-)

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

На мой взгляд здесь есть два аспекта.




Какие конкретно проблемы решаем?


"Одна из основных ошибок менеджмента в современных бизнес организациях заключается в поиске правильных ответов, в то время, когда следует все свое внимание уделить поиску правильных вопросов"
Питер Друкер

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


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



Тактика частых ошибок и фокус на быстрой обратной связи


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

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

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

Так же и не в ИТ проектах.


P.S.

Это не значит впрочем, что нужно ограничивать и отфутболивать какие-то изменения еще на первом этапе. Нужно часто и много экспериментировать и почаще ошибаться. Нужно поощрять инициативу и изменения.

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

Комментариев нет:

Отправить комментарий