Ошибки, которые менеджеры зачастую совершают, приступая к реорганизации
|
| Дэн Коэн: «Чтобы ИТ-менеджер мог нормально общаться с другими сотрудниками, необходимо его активное участие в проекте» |
Так считают Джон Коттер и Дэн Коэн, опубликовавшие в издательстве Harvard Business School Press книгу «The Heart of Change: Real-Life Stories of How People Change Their Organizations» («Суть преобразований: истории из реальной жизни о том, как люди изменяют свои организации»). Книга, которая уже появилась на прилавках, построена в виде интервью с менеджерами высшего звена, представляющими более 100 компаний из самых разных стран мира.
В настоящее время Дэн Коэн — глава Deloitte Consulting. В интервью еженедельнику Computerworld он отметил ошибки, которые менеджеры зачастую совершают, приступая к реорганизации, а также порекомендовал последовательность действий, которой следует придерживаться, чтобы добиться успеха при проведении преобразований.
Что послужило основой для написания этой книги?
Модель, которую Джон Коттер предложил в 1996 году. Она предусматривала повышение оперативности, формирование руководящей команды, выработку общих взглядов, обсуждение закупок, наделение работников необходимыми полномочиями, организацию общего поступательного движения на базе мелких локальных достижений, сохранение требовательности к себе и другим и закрепление достигнутого ранее. Задумайтесь об этих восьми составляющих, и вас наверняка посетит мысль, откуда же взять столько сил, чтобы воплотить все это в жизнь?
Разница между успешными и неудачными преобразованиями заключается в том, что люди в преуспевающих организациях устраивают запоминающиеся встречи, помогают своим коллегам увидеть происходящее под другим углом, стараются привлечь их внимание к существующим задачам и предлагают способы их решения. Это глубокое, эмоциональное воздействие. Стремление пробудить душевное волнение и волю к проведению преобразований противопоставляется политике менее удачливых организаций, которые придерживаются аналитического подхода и оперируют исключительно цифрами.
А можно привести пример таких «запоминающихся» встреч?
Каждой компании хочется сократить количество поставщиков, с которыми она работает. Как-то раз руководство одной крупной производственной компании решило проанализировать, с какими поставщиками ей приходится иметь дело. Оказалось, что на ее заводах используется 424 разновидности перчаток, которые закупаются по совершенно разным ценам.
Группа участников проекта взяла по одной паре каждого вида, снабдив их ярлыками и информацией о цене и месте закупки. Потом все перчатки разложили на длинном столе и объяснили начальникам подразделений, к чему должна стремиться организация. Если сократить весь этот спектр до трех-четырех моделей, подходящих в подавляющем большинстве случаев, расходы на закупки сократятся на 80% и компания сэкономит миллионы. Вот о таком типе наглядных демонстраций я и веду речь.
А что скрывается за словами «не снижать требовательность»?
Приведу классический пример. Производственная компания потратила десятки миллионов долларов на два проекта предварительного внедрения системы SAP в зарубежных филиалах. Система зарекомендовала себя с самой лучшей стороны, и руководство приняло решение выделить 80 млн. долл. на реализацию аналогичного проекта в США. Все складывалось прекрасно, и создавалось впечатление, что и в Штатах все пойдет как по маслу. Но внезапно колеса сошли с рельсов. Дело в том, что среди участников проекта царило, как говорят, шапкозакидательское настроение, и все были уверены: стоящая перед ними задача яйца выеденного не стоит.
Директору информационной службы и нескольким ключевым менеджерам пришлось срочно искать ошибки, которые были допущены при настройке конфигурации, и заново тестировать программное обеспечение. Исполнительный директор подразделения был вынужден устраивать встречи практически с каждым клиентом, объясняя причины возникновения задержки.
Но наученный горьким опытом директор решил на этом не останавливаться. После того как все ошибки были устранены, он вызвал к себе начальников производственных отделов и потребовал разъяснить текущее положение дел с сырьем и продукцией, объяснить, почему складские запасы некоторых товаров превышают норму, с чем связаны перебои в выпуске других продуктов и т.д. Начальники отделов не смогли дать вразумительных ответов на эти вопросы. Как выяснилось, они не знали, как выводить на экран монитора оперативную информацию. После того как с ними были проведены необходимые занятия, ни один из вопросов не остался без ответа, поскольку все руководители приобрели навыки эффективного использования системы.
Вместо того чтобы ругать подчиненных за незнание системы, генеральный директор наглядно продемонстрировал, для чего ее надо изучать и какие преимущества в дальнейшем это сулит.
Какую самую серьезную ошибку руководитель информационной службы может сделать во время проведения преобразований?
Если преобразования важны и носят принципиальный характер, большинство менеджеров не хотят связываться с этим. Они полагают, что все изменения — не более, чем техническое решение. Они не хотят ничего слышать о скептицизме, не хотят считаться с нежеланием конечных пользователей переходить на новую систему.
Конечно, все согласны с тем, что изменения важны, но если вы посмотрите на команды, работающие над крупными проектами, нетрудно заметить, что на проведение организационных преобразований выделяются чисто символические ресурсы — один или два человека, которые зачастую решают незначительные задачи. Члены команды занимаются обычно чисто техническими вопросами, например, программным обеспечением для компьютеров. Их не интересует интенсивность сопротивления проекту. В конечном итоге вы внедряете модернизированную программу и внезапно обнаруживаете, что сотрудники просто не готовы к работе с ней, потому что они не прошли соответствующего обучения и не представляют, как изменились их функциональные обязанности. В конце концов реализация проекта приостанавливается, а вам приходится возвращаться назад и латать дыры.
Что должен предпринять ИТ-менеджер, для того чтобы предотвратить возникновение подобной ситуации?
Прежде всего, надо четко представлять себе цель проекта. Является ли программное обеспечение самостоятельной движущей силой или всего лишь инструментом? Большинство людей, наверное, согласятся с тем, что это — инструмент. А раз так, необходимо уделить особое внимание вопросам внедрения. Какие результаты должна получить организация и каковы способы достижения конечных целей? За реализацию проекта должны отвечать начальники основных подразделений, а не руководитель информационной службы. Его внедрение следует поручить бизнес-менеджеру, который будет следить за правильностью перехода на новые технологии и их эффективным использованием в организации.
Второй момент, о котором нельзя забывать ИТ-менеджеру, касается обучения и сроков его проведения. Обычно внесение любых изменений в конфигурацию сопровождается необходимым обучением. При компонентном тестировании и тестировании в режимах предельной нагрузки начинают выявляться нестыковки. Поскольку временной интервал между проведением тестирования и обучения, как правило, весьма невелик, обучающему персоналу необходимо дать срок, достаточный для полноценной подготовки людей. Именно здесь велика вероятность возникновения осложнений, и руководитель информационной службы должен постоянно контролировать ситуацию с обучением.