Вместо вступления
Мы привыкли к идее, что изменения в организации необходимо проводить как "проекты". Но очень часто случается печальная ситуация, когда проект призван обеспечить изменение и даже запускает изменение, но потом это изменение затухает, глохнет. Обычно это объясняют тем, что проект управлялся плохо. И бросаются организовывать обучение управлению проектами или создавать проектный офис.
На самом деле проект здесь ни при чем. Заглохло изменение, потому что никто им не управлял. Более того, если вы работаете у стороннего заказчика, то управление изменениями – это не ваша прерогатива. Управление изменениями – это прерогатива заказчика, это его изменения. Но поскольку организациям редко приходится заниматься изменениями, они просто не умеют им управлять. И, значит, вам придется помогать заказчику и в этом.
Если вы не понимаете, как проходят изменения, тогда шансов, что ваш проект будет успешным, немного. В 3 случаях из 4 изменения проходят, как получается. И по статистике, 75% IT-проектов неуспешны. То есть они либо не попадают в график по времени, либо не попадают в бюджет, либо то, что делается, не соответствует техзаданию. А бывают и такие ситуации, когда все соответствует требованиям, но изменение никому не нужно.
Почему проекты не получаются? И, главное, каким образом они "не получаются"?
1. Изменения даже не начинаются.
Почему не происходят изменения, хотя текущее положение дел никого не устраивает? Например, потому что оно кого все-таки устраивает. Или кто-то боится, что станет хуже. Или кому-то непонятно, что именно надо менять. Еще есть люди, которые говорят, что все перемены ведут к худшему, и вообще что-то менять бессмысленно.
2. Изменение, вроде, началось, но застряло.
В чем это выражается? Например, в том, что начальство с одной стороны изменения подталкивает, а с другой – тормозит. Или вообще все сроки прошли, потихоньку что-то идет, деньги «вбухиваются», как в черную дыру. А бывает, что пока совещались и решали, что надо делать, оказалось, что делать надо абсолютно другое. Или очень много раз приходится все согласовывать и сдвинуться с мертвой точки невозможно.
3. Проект завершился, но все работает по-старому.
Самая печальная ситуация, когда, вроде бы, все получилось, ИТ работает, но ничего не изменилось. Почему это происходит? Во-первых, людям свойственно работать так, как они работали. Все новое – неудобно. Не важно, какие именно новшества, они все равно неудобны. И вообще все новое – это страшно! И все новое придумывают начальники, чтобы «заэксплуатировать» сотрудника и выжать из него все соки. Для этого автоматизация и есть…
Тем не менее, владельцы бизнеса декларируют, именно декларируют, что им нужны успешные изменения. Считается, что у успешных менеджеров руководители покупают успешные изменения.
И возникает вопрос, что такое успешное изменение, и что вообще мы считаем успехом проекта?
Каждый человек по-разному оценивает успех проекта. Но главное – как оценивает это тот, кто нас оценивает: владелец бизнеса, топ-менеджер. Если выяснить, что для них успех проекта, можно под эти требования подстроиться.
Часто говорят, что успех проекта или изменения – это достижение целей бизнеса. Возможно. Но у "бизнеса" нет своих целей. Бизнес - это люди. Цели - в головах людей. Узнать цели бизнеса – это очень непростая вещь. И если вы не являетесь собственником или хотя бы лицом, имеющим право голоса, то о целях бизнеса рассуждать вам будет очень сложно.
А знает ли топ-менеджер цели бизнеса? Что он считает успехом? Ведь бывает, что IT-директор подчиняется именно ему. А иногда – не самому главному топ-менеджеру, а финансовому или исполнительному директору. И тогда непонятно, что именно надо делать, если интересы непосредственного босса и верховного начальника отличаются.
Это вообще очень сложная вещь, понять, что нужно делать. Поэтому иногда получается, что даже когда мы ставим систему, она никому не нужна. Из-за такой ситуации ¾ пользователей не хвастаются проектами, даже если они успешны. Вроде что-то сделали, системы поставили и они работают, но успеха нет.
В целом, конечно, цель изменений – это устранение какой-то проблемы. Но далеко не всегда мы решаем ту проблему, которая декларирована. Например, в моей практике целый проект делался для того, чтобы поддержать вновь пришедшего директора. Нужен был успешный проект только для того, чтобы его приняли остальные топы. В этом смысле желательно зарубать такие проекты, которые, хотя бы в вашем представлении, не соответствуют целям бизнеса.
Подготовка к проекту
Мы привыкли счиатать, что проблема - это плохо. Увы, это "плохо" не для всех, иначе ее решили бы до нас. Она бы даже не возникла. Если проблема есть, значит она кому-то дает важное преимущество. Надо только понять, для кого эта проблема – преимущество.
Приведу пример из своей практики. Как-то я работал консультантом в одной стоматологической компании. В ней владелец, хотя тоже был стоматологом, своих подчиненных ни во что не ставил. В компании были очень жесткие законы и штрафы, а собственник бизнеса часто заявлял, что заменить одного из его стоматологов труда не составит, поскольку таких специалистов выпускают ежегодно в большом количестве. В итоге работники не чувствовали, что на них держится бизнес. Они чувствовали себя расходным материалом. Среди обязанностей стоматологов было не только лечить пациентов, но и продавать им сопутствующие средства, материалы, устройства. Врачи не отказывались, но продавать у них не получалось, не покупал никто. Им дали процент, чтобы увеличить продажи, потом еще увеличили возможную прибыль. Но что бы ни делалось, все становилось еще хуже.
Кому и что эта ситуация давало хорошего, нужного и ценного? Врачам. Они таким образом, возможно не осознавая этого, давали понять, что хотят лечить, а не стоять за прилавком и торговать. И восстанавливали самоуважение.
Понятно, что если бы эти врачи почувствовали к себе серьезное уважение, то порекомендовать своим пациентам зубную пасту, ирригатор или другую продукцию им было бы несложно. И 9 из 10 пациентов даже купили бы эти товары, несмотря на то, что в клинике они дороже.
Если бы владелец стоматологической компании это осознал, проблема бы рассосалась сама. Ничего не надо было бы для этого делать. Не понадобилась бы учетная система, чтобы учитывать, кто и что продает, не понадобилось бы контролировать разговоры, ничего не понадобилось.
Этим примером я хотел показать, что если есть проблема и она существует долго, значит, она кому-то нужна. И если организация ее решит, она что-то потеряет. Если удастся понять, что это такое и дать возможность организации получить эту же выгоду, например, уважение, другим способом, тогда проблема уйдет сама. И тогда можно будет хорошо сделать проект. И он имеет шансы на успех.
В традиционном менеджменте есть такое понятие, как модель Глейчера. Она показывает, как должны быть сделаны успешные изменения.
Если мы находимся в точке А (текущее состояние) и нам надо в точку В (желаемое), надо туда как-то пройти. На этом пути есть точка D. Она показывает первый малюсенький шаг. Исходя из формулы Глейчера, изменение успешно, если:
- уровень неудовлетворенности текущим положением достаточно высок
и/или
- есть четкое представление о желаемом состоянии
и/или
- первые шаги по изменению достаточно безопасны.
Если произведение уровня неудовлетворенности на представление и на безопасность первого шага меньше чем то, как люди воспринимают стоимость изменения, то есть шансы провести изменение успешно. При этом все эти вещи субъективные. Если, например, уровень удовлетворенности слишком маленький (людям и так хорошо), то надо сделать, чтобы людям стало плохо. Тогда они захотят что-то менять. Если они недостаточно хорошо представляют себе, куда надо идти, тогда надо сделать так, чтобы они представили себе возможные перспективы. А первый шажок, он должен быть очень безопасным.
Каким он может быть, расскажу на примере из собственной практики. В центре КЕЙ мне пришлось внедрять в IT-отделе новую систему управления. Но я не стал объяснять, какие красивые вещи мы получим от нее, как все будет круто. Я сделал маленький шажок: предложил посадить человека, который будет фиксировать все заявки и передавать их айтишнику. Тогда работник сможет работать только по заявкам, времени на саму работу останется больше, и специалистов никто не будет отвлекать. Кроме того, когда будет организована работа по заявкам, появится контроль, сделал айтишник свою работу или нет. И мы четко знаем, кто и сколько работает. А главное, когда работа выполнена, он нажимает на кнопочку, оператор понимает, что все готово и уведомляет об этом пользователя. Ведь, одна из существовавших проблем – отсутствие оперативной и полноценной информации. Получалось, айтишник все сделал, а пользователь об этом не знает. Или один работник знает, что проблема уже устранена, а другой – нет. И вот такой маленький первый шажок прошел, ведь это было очень просто – посадить оператора, который будет принимать заявки. А дальше понеслось: пошла стопроцентная фиксация заявок, постепенно начали разрабатывать и внедрять остальные этапы. В общем, понятно: первый шаг должен быть безопасным и очень небольшим.
Для успешного внедрения проекта важно понимать, кто в организации заинтересован в изменениях, а кто заинтересован их провалить. Как этого добиться, я рассказать сейчас просто не успею, но если вы этого не знаете, то шансов на успешный проект немного.
Например, вы ставите 1С в бухгалтерию, а там «баба Маня», которой полгода до пенсии. Она знает бухгалтерию и вдоль, и поперек, и по диагонали. Но компьютер она не то что не знает, она его боится и ненавидит. Насколько такой работник будет рад изменению? Конечно, она будет против. Но можно ее вызвать и сказать: «На вас вся надежда. Вы наша опора. Потому что налоговая требует эту «железку», а молодым специалистам доверять пока нельзя. Назначаем Вас главной по внедрению новой системы. Надо бы присмотреть за всеми этими работниками». Конечно, «баба Маня» ничем помочь не сможет, но она перестанет мешать. А если ей еще и премию небольшую пообещать за эффективное внедрение, то она будет первым заинтересованным в проекте лицом.
В принципе надо нарисовать поле сил: кто за, кто – против. И хорошо понять, почему кто-то за и почему кто-то против. И дальше можно с этим что-то делать. Кстати, в поле сил должно войти примерно 10 человек, которые на предприятии, действительно, что-то значат. Это поможет четко понимать, кто будет за изменение и кто будет против него.
Реализуем проект
В менеджменте есть стандартный цикл изменений. Сначала надо разморозить ситуацию, воспользовавшись формулой Глейчера, например, сделать, чтобы всем было плохо, провести какие-то мощные совещания и рассказать, как будет хорошо, когда мы будем «там».
Если не размораживать ситуацию, будет плохо. Помните, власти проводили монетизацию льгот, когда пенсионерам меняли лекарства на деньги, и народ вышел на улицы. Но важно не то, что сделали, а как – указом. В советское время такие вещи делали намного умнее. Сначала запускали серию газетных статей, в которых рассказывали, что деньги воруют и покупают не то, что надо. Потом пошли бы письма трудящихся, что лучше бы людям деньги дали. Позже выступил бы какой-то эксперт, который заявил бы, что нашим людям нельзя давать деньги, потому что они все пропьют. После достаточных обсуждений вышел бы гарант, и заступился за народ. Сказал бы, что российский человек – правильный, и он знает, как правильно делать. Затем в порядке исключения или в качестве эксперимента в какой-то области начали монетизацию льгот, а потом аккуратно ввели бы повсеместно. И люди были бы к этому готовы. Это и есть размораживание.
Если удается поменять поле сил так, что за изменение выступает больше людей, чем против, изменение начнет дрейфовать и, соответственно, приходит в точку 2 – туда, где и должно быть. Там надо его заморозить: новыми должностными инструкциями, KPI , чтобы у людей не было возможности вернуться к старому. Тогда будет шанс на успешный проект. Иначе все вернется туда, откуда началось.
Очень часто забывают про размораживание и про замораживание. Но оба этапа очень важны.
Вместо заключения
Все, о чем вы читали до сих пор, – входит в обычный курс менеджмента. Но сейчас я хочу поделиться тем, к чему пришел занимаясь организационной психологией и изучая коучинг. Этого нет в учебниках, поэтому доказать свои размышления ссылкой на учебник я не могу. Но вещи, о которых пойдет речь, можно прочувствовать «шкурой».
Есть такая идея, что когда владелец создает организацию, он создает ее для чего-то. Иногда он сам не осознает, для чего он ее создавал. Например, я пытался понять, для чего владелец фирмы, где я работал 18 лет, создавал ее. Некоторые говорят, что ради денег. Но это не так. Потому что сами по себе они не очень нужны. Что с ними можно сделать? Бумажки! Печку топить! В целом, они нужны, чтобы купить покой, власть, драйв, комфорт. По-разному бывает. Там, где я работал, компания создавалась в 90-х, и надо было поднимать семью и детей, покупать свое жилье, заработать на счастливую пенсию. Это хорошие принципы. Но организация с такими принципами должны быть обязательно очень большой, на всю страну? Нет. Более того, она не имеет права ею быть, потому что это опасно: организация растет, и одновременно повышаются риски. А значит, под угрозу ставятся и принципы, и мечты об обеспеченной старости.
А можно ли в такой организации пытаться проводить какие-то инновации? Нет. Ведь, счастливой старостью рисковать нельзя. Поэтому разговоры о том, как сильно вырастет бизнес после проекта, здесь бессмыслены. Перемен тут боятся.
Но если в такую компанию прийти и сказать, что в результате изменения снизятся определенные риски, то это услышат. Поэтому если вы понимаете, для чего на самом деле создавалась организация, у вас есть шансы провести успешное изменение. Если не понимаете, их нет.
Если организация создавалась для драйва, драйва будет много. Она будет то расти, то падать. Если создавалась для власти, то она будет большой. Владелец будет идти в традиционную власть, а потом возвращаться. Для чего ее создавали, для того она и будет.
Как я себе представляю само появление компании. Есть некий социум, какие-то люди. У них есть желания. Среди этих людей есть предприниматели – им вечно надо что-то «предпринимать». Они тоже чего-то хотят. Есть у них свои идеи, но дополнительно они ловят идеи социума. В итоге появляется идея бизнеса, своего рода продукт.
Например, если говорить о компании, где я работал, здесь был уловлен важный посыл социума в 90-х гг.: людям хотелось, чтобы в магазинах на полках было много продуктов, а продавцы всем улыбались. Если в целях создания организации больше от "желаний" социума, то бизнес успешен и социум платит за это деньги. Если компания появилась только от желания предпринимателя, бизнес умрет быстро.
Это ДНК называется лидирующим или ведущим принципом. Если вы хотите быть успешными в проектах и изменениях, надо понять, для чего создавалась организация. Тогда у вас есть шанс. Иначе шансов на успех нет.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.
