Внедряя систему, мы хотим сделать жизнь бизнес-заказчика лучше, чем было. При этом неважно – внешний это клиент, который купил у нас проект, или внутренний заказчик.
Казалось бы, мы ведем людей из темного настоящего в светлое будущее. Люди должны радоваться и идти вместе с нами. Но почему-то так происходит не всегда.
Пока мы идем к точке назначения, мы проходим большое и интересное путешествие. Происходит много всего – срабатывает управление рисками, возникают какие-то неучтенные сложности, неучтенные требования, меняется заказчик.
Прийти к точке назначения нам глобально мешает:
-
неопределенность среды, в которой мы работаем – постоянно меняющиеся внешние и внутренние факторы;
-
и сопротивление тем изменениям, которые мы делаем – от рядовых пользователей, руководителей и организации в целом.
Если бы не было этих неопределенности и сопротивления, работа руководителя проекта, наверное, была бы либо не нужна, либо она была бы очень простой. Можно было бы с самого начала составить план работ, нарезать кучу задач, загрузить этот план в какую-нибудь замечательную систему, которая раздавала бы эти задачи по очереди исполнителям. Они бы их делали, и мы бы быстро пришли к концу проекта. Но так не получается.
Про неопределенность мы не будем говорить – это отдельная тема. А с сопротивлением попробуем разобраться.
Чем нам мешает сопротивление
Почему в проекте внедрения информационной системы возникает сопротивление изменениям?
Любой проект автоматизации бизнеса – это проект организационных изменений. Меняется все – процессы, подходы к работе, люди, перераспределяются обязанности внутри компании.
Управление проектом внедрения информационной системы – это управление проектом организационных изменений. Мы эти изменения в компанию вносим, а компания им сопротивляется.
Нам это, естественно, мешает. Было бы круто, если бы все, начиная от рядового пользователя и заканчивая любым руководителем, радостно делали то, что мы в проекте им поручаем. Но, к сожалению, начинается саботаж, появляется эффект «короткой памяти», когда говорят: «мне не рассказывали»; «я такое не говорил»; «я это говорил, просто не записали»; «я не то имел это ввиду». И любая мелочь раздувается до масштаба трагедии.
Люди любят стабильность, им нравится, когда ничего не меняется. И сами они тоже не хотят меняться.
Иногда я выступаю в роли руководителя проектного офиса и помогаю нашим РП-шникам разбирать ситуации в проектах – почему мы не двигаемся, почему веха переносится уже в пятый раз, а мы стоим на месте. И такое бывает очень часто – пользователи на проектах сопротивляются, и не хотят меняться.
Но на самом деле это не нормально. Скажите любому среднестатистическому сотруднику, что он будет работать на два часа меньше, а зарплату получать точно такую же. Будет ли он сопротивляться такому организационному изменению? Может быть, будут люди, которые скажут, что это подозрительно, но, скорее всего, они сопротивляться не будут. Они будут рады уходить на 2 часа раньше и заниматься своими делами.
Значит, не всем изменениям люди сопротивляются. Они сопротивляются чему-то конкретному. Чему же они сопротивляются?
Модель сопротивления
Многие, кто как-то связан с производством, автоматизацией производства, знают книгу Голдратта «Теория ограничения систем».
Но у него есть и другая книга, тоже о теории ограничений, которая называется «Я так и знал! Розничная торговля и теория ограничений» – он там в жанре бизнес-фикшна разбирает модель сопротивления.
Мне модель сопротивления Голдратта показалось забавной. Разберем ее.
-
На вершине горы есть горшочек с золотом. Чтобы его получить, нужно дойти до вершины. Но наша мотивация получить этот горшочек зависит от того, насколько большим он нам кажется снизу.
-
При этом на горе сидит страшный дракон, и по пути на вершину он будет нас кусать и жечь огнем – с ним надо будет сразиться. Принимая решение идти на вершину, мы сравниваем опасность в виде маленького дракона и размер горшка золота. Можно было бы назвать эти факторы как-то более серьезно, но пусть будет дракон и горшочек – так легче запомнить.
-
Но это еще не все факторы. Сейчас мы находимся в ситуации, где нас окружили крокодилы и кусают нас. Опасность этих крокодилов – это тоже фактор, который помогает принять решение двигаться к горшочку с золотом.
-
Кроме того, у нас в текущей ситуации еще есть русалка – она красивая и поет нам песни, не хочет нас отпускать.
Получается, что у нас есть четыре фактора:
-
размер горшка с золотом – насколько сильно мы хотим изменений, какую они нам пользу принесут;
-
дракон, с которым придется сразиться – насколько сложным будет путь к изменениям, к горшочку с золотом;
-
крокодилы, которые нас окружили – что в текущей ситуации плохого, что подталкивает нас идти за золотом;
-
и как мы относимся к русалке, которая поет нам песни – что в текущей ситуации хорошего, насколько она нас держит.
Когда человек решает, оставить все как есть или отправиться в опасное путешествие ради изменений к лучшему, он неосознанно взвешивает эти четыре фактора.
Неудачная автоматизация супермаркета
Расскажу конкретные кейсы. Начну с факапа, когда у нас ничего не получилось – видимо потому, что мы не поработали со всеми этими факторами.
Проект – автоматизация супермаркета. Огромное здание в несколько этажей, куча касс, широкий ассортимент товаров. Классический переход с УТ10 на УТ11: обследование, модель, реализация.
Все сделали, система готова, но заказчик сопротивляется ее запуску. Каждый раз, когда мы подходим к тому, что пора бы уже приступать к опытной эксплуатации, находятся новые замечания, идеи и предложения.
-
Сначала новое торговое оборудование приехало, на нем еще не тестировали – подключили, протестировали.
-
Потом ремонт в торговом зале – ремонт закончили.
-
Затем пользователи засомневались, нашли еще один модуль, который не тестировали – посмотрели, протестировали.
Но все равно никак дальше не двигаемся.
Все это время заказчик работал на старой УТ 10. У него были свои программисты в штате, они всю жизнь дорабатывали эту систему, там все было автоматизировано просто идеально.
Проект затеяли ради маркировки. У заказчика много товаров, подлежащих маркировке, и каждую новую маркировку приходилось делать вручную силами своего ИТ-отдела. Они брали типовую конфигурацию, вытаскивали из нее маркировки, впихивали в свою страшную УТ 10 и допиливали. И каждый раз все ждали, на что будет введена маркировка в следующий раз – на шины или на шубы…
А это был супер многопрофильный торговый центр, где продается все. Поэтому все маркировки, которые были, есть и будут, их касаются. Ради этого такой проект решили сделать.
Результат – не запустились, потонули в циклах согласования, откладывании на потом и сомнениях.
Закончилось все тем, что заказчик забрал эту систему себе. Сказал: «Я ее теперь своим программистам отдам, они допилят все, что надо. И мы потом запустимся сами».
Я считаю это неудачным кейсом – вроде мы не поругались, акты подписали, но проект не запустили. Клиент забрал систему себе, и непонятно, что он теперь с ней будет делать. Может, выбросил и не использует. А может, и использует – неизвестно.
Разобрать этот проект легко:
-
Русалками, которые удерживали заказчика и не пускали завершить проект по переходу, была существующая система. Она работала шикарно. Все было автоматизировано так, что пользователь вообще ни о чем не думал. Кассиру ничего не надо было делать, все работало само. Мечта!
-
А чем были крокодилы, которые кусали заказчика и двигали вперед? Это были маркировки, которые появлялись новые без конца.
-
А чем был горшочек с золотом, к которому заказчик хотел прийти? Заказчик хотел получить типовую обновляемую конфигурацию от 1С, в которой все маркировки будут работать из коробки. Вышел релиз, обновили, работает.
-
А к драконам, с которыми предстояло сразиться, относилось:
-
переобучение пользователей;
-
риск приостановки бизнеса (а там 24/7, супермаркеты работали круглосуточно);
-
отказ от огромного количества разных хитрых доработок, которые сделаны за годы работы;
-
нервы, которые предстоят при внедрении. Про нервы не знает только тот, кто никогда ничего не внедрял. Но заказчик у нас был умный, он уже внедрял и понимал, что предстоит «интересное» мероприятие.
-
Если посмотреть на все это, понятно, почему заказчик не решался – горшочек был для него такой крохотный, а крокодилы настолько маленькие, что ему не было смысла на гору лезть.
Нам правильнее было сразу отказаться от этого проекта, чтобы сохранить репутацию. Надо было сразу понять, что клиент не пойдет с нами до конца, и не браться за проект.
Удачная автоматизация салонов мебели
Теперь расскажу про удачный кейс.
Заказчик – сеть салонов элитной мебели из Испании и Италии. Свой импорт, все сами возят, шоурумы по всей Москве. С дизайнерами работают, дизайн проекты помогают разрабатывать.
Но автоматизировано все ужасно. Лоскутная автоматизация: что-то на СБИС, что-то в Excel, еще на чем-то. Собственник, он же генеральный директор, не имеет никаких оперативных инструментов управления. Он не только не может планировать какие-то финансы, он не знает, какие заказы у него на текущий момент предоплачены. Все эти данные у каких-то людей, их надо сначала собрать, как-то консолидировать.
Провели обследование, моделирование. И на этапе подготовки к запуску клиент стал притормаживать процесс – перестал отвечать на письма, отвечал только на часть вопросов, затягивал согласование.
Такое сопротивление возникает у многих компаний, когда мы подходим ближе к внедрению. До сих пор им было не страшно, им казалось, что все это развлечение: обследование, вопросики задают, картиночки показывают, систему демонстрируют. Но когда мы подходим к внедрению, становится страшно.
Но в результате кейс оказался успешный. Мы разобрали его по модели сопротивления:
-
Проект двигала вперед необходимость в управленческой отчетности и консолидированном учете – это был огромный горшочек с золотом.
-
Им нужно было начать считать свои деньги и управлять движением товаров, поскольку каждый стол стоил бешеных денег, и его потеря – существенный удар по компании. Это были глобальные крокодилы.
-
Но проект останавливала неготовность сотрудников этого конкретного клиента к работе в новой системе. У них сотрудниками была большая дружная семья, многие из которых работали в компании десятками лет. Большинство сотрудников – возрастные и 1С не видели никогда, потому что 1С в компании никогда не было. Собственник справедливо предполагал, что сейчас мы начнем их «ломать через колено», впихивать в них 1С, заставлять учиться, люди испугаются, начнут бунтовать, откажутся учиться и начнут разбегаться. А мышцы найма у компании не было – они никого не нанимали за последние 5 лет, просто не умели нанимать людей. Это и рождало страх, который тормозил проект.
Когда мы это поняли, мы выделили самого доброго, самого милого внедренца, какой только есть в компании. Мы выделили женщину.
-
Во-первых, она по возрасту была ближе к сотрудникам.
-
Во-вторых, она с пользователями работала как с детьми. Могла сесть с ними и несколько раз объяснять, рассказывать, пробовать, пока не получится. В общем, ангельское терпение.
Мы выделили этого человека на обучение сотрудников и на дальнейшую поддержку. И все взлетело.
Руководитель проекта со стороны заказчика поверил, что все хорошо, увидел, как все мягко, мило и по-доброму. И после того, как он поверил, что люди не разбегутся после попытки запуска новой системы, все двинулось дальше, все получилось.
Сейчас система запущена, находится в промышленной эксплуатации.
Как распознать сопротивление?
Когда мы сталкиваемся с сопротивлением, имеет смысл остановиться и подумать, что происходит – проанализировать эти четыре фактора и решить, как действовать дальше.
Можно выработать маркеры такого сопротивления. Я выписал несколько примеров:
-
Меня этому не учили. Ах, я листы обучения подписал? Наверное, я был в бреду. Ничего не помню.
-
Я-то уйду, а кто работать будет?
Такие фразы говорят, что люди не хотят меняться.
Есть еще цифры – план, вехи, бюджеты, трудозатраты. Анализируя цифры, тоже можно понять, на что обратить внимание.
-
Например, у нас внедрено управление по вехам – они расставлены равномерно внутри плана каждого этапа. Мы еженедельно проходим вехи. Если есть сдвиг одной и той же вехи несколько раз подряд, это маркер, что здесь какая-то проблема или с нашей стороны, или со стороны заказчика. Может быть, это сопротивление.
-
Также с трудозатратами. Если они резко повысились на каком-нибудь этапе приемки-сдачи – особенно, если вы каждого клиента лично знаете – скорее всего, вы увидите или услышите сопротивление.
-
А если вы следите за проектами в какой-то учетной системе и видите, что у вас есть план на сдачу в 40 часов, а он уже 140 часов, наверное, что-то с задачей не так. Надо опять-таки погрузиться и разобраться, что происходит.
Фреймворк преодоления сопротивления
У Голдратта есть 5 направляющих шагов для работы с ограничениями. А у меня свой фреймворк – 5 шагов преодоления сопротивления:
-
Шаг 1. Осознать, что сопротивление есть – про это был предыдущий слайд с маркерами сопротивления. Важно понять, что кто-то в компании сопротивляется.
-
Шаг 2. Понять, кто сопротивляется. Хорошо, если есть понятный человек – например, РП со стороны заказчика ближе к запуску испугался. Или главный бухгалтер вдруг появился где-нибудь в конце проекта и всех напугал. Нужно осознать, кто сопротивляется, чтобы понять, с кем работать.
-
Шаг 3. Честно зафиксировать как можно больше факторов из четырех групп (русалки, горшочки, драконы и крокодилы). Накидать много таких факторов.
-
Шаг 4. Русалок и драконов надо ослаблять.
-
Русалок можно еще тащить с собой. У нас были русалки – сотрудники предпенсионного возраста, которых заказчик боялся потерять по пути проекта. И мы не ослабляли этих русалок, не разгоняли, не увольняли, мы сделали так, чтобы их можно было взять с собой.
-
А с драконами надо работать. Например, проблему, которую видит наш сопротивленец, можно сделать поменьше. Если мы понимаем, чего он боится, можно проблему порезать, сделать меньше. А можно сделать так, чтобы проблема не воспринималась такой страшной, такой опасной.
-
-
Шаг 5. Крокодилов и горшочек усиливаем. Крокодилы и горшочек – не совсем серьезная терминология, но это бизнес-цели и цели проекта, ради которых все затевалось изначально.
-
Скорее всего, в уставе цели проекта зафиксированы, потому можно возвращать заказчика к целям. Когда у нас начинается проект, начинается пресейл, первое, что мы делаем, – мы выявляем цели, пытаемся понять, зачем бизнес решил «взбираться на гору». И мы возвращаем заказчика к целям, напоминаем, чего он хотел.
-
Бывает, что цели проекта поменялись, их надо актуализировать. Если мы не заметили, что цели изменились, возможно, это уже не сопротивление, просто заказчик уже идет в другую сторону, не туда, куда мы его ведем. Поэтому актуализируем цели.
-
Выводы
Сопротивление изменениям – это абсолютно нормально.
Но нежелание меняться – не какое-то свойство человеческой природы, оно не значит, что люди любят стабильность. Ничего подобного. Люди хотят меняться:
-
Если они видят выгоды этих изменений.
-
Если путь к этим изменениям выглядит не очень сложным.
-
Если их текущая ситуация такова, что здесь оставаться просто невозможно.
-
Если тут плохо, а там – хорошо, пойти на изменения легко.
Задача руководителей проектов со стороны заказчика и со стороны исполнителя и внутренних руководителей проектов – работать с этим сопротивлением. Про сопротивление нужно думать не как про данность, с которой ничего нельзя сделать, а как про набор факторов, влияющий на нас.
Книг, посвященных организационным изменениям, удивительно мало. Но эти три книги – про организационные изменения.
-
Первая – «Я так и знал. Розничная торговля и теория ограничений». Из нее как раз эта смешная модель с крокодилами, русалками и остальным.
-
Вторую – «Наш айсберг тает» найти сложно, в электронном виде более реально. Замечательная книга о пингвинах, у которых ломается айсберг. Они в это не верят, потому что не хотят организационных изменений. Они хотят остаться на айсберге и не верят в то, что с ним что-то происходит.
-
Последняя книга – «Менеджер трансформации».
Очень рекомендую все три книги. Они написаны легко, понятно, прикольно и содержат полезные концепты. Не зря прочитаете.
Вопросы и ответы
Вы сказали, что когда у человека все плохо, он хорошо идет на изменения. Но есть история про двух жаб, первую из которых бросают в кипяток – она выпрыгивает, потому что ей плохо. А вторую нагревают постепенно – она привыкает и думает, что ей хорошо. И если прийти к такой жабе и сказать, что нужно срочно спасаться, она скажет, что у нее все хорошо. Вопрос: как рассказывать людям, что им плохо?
Хороший вопрос. У нас были такие лягушки. Сначала их все устраивало в старой системе, а потом они привыкают и уже их все устраивает в новой системе.
Как им донести, что все плохо? Есть вариант посадить с ними такого человека, как в нашем кейсе. Чтобы он с ними каждый шаг разбирал, рассказывал им как маленьким деткам, как можно сделать так, чтобы все стало удобнее.
Надо вовлекать людей, как бы это банально не звучало. Еще можно самых сопротивляющихся втаскивать в проект на начальном этапе, даже если они ни на что не влияют, даже если они никаких решений не принимают. Начиная с момента, когда собственник компании говорит о решении внедрять новую систему. Чтобы они почувствовали себя соучастниками изменений, которые происходят в компании.
Пусть они присутствуют, вопросы задают, а вы будете им что-то показывать. Даже если они ничего не делают и не принимают никаких решений, все равно они почувствуют себя соавторами изменений.
Есть директивные проекты, которые спускаются сверху. И люди, которые работают в компании, в принципе не понимают, зачем им это нужно. И они не хотят отвечать на вопросы, не хотят внедрять ничего. Им это все не нужно. Вы с таким сталкивались?
Поскольку мы не инхаус, а внешний по отношению к компании подрядчик, мы стараемся не брать такие проекты.
У нас есть счастливая возможность отказаться. Мы можем отказаться от проекта, от клиента, если видим, что там никому ничего не нужно. Ситуация, когда кому-то не нужно, а кому-то нужно, – это нормальная ситуация. Но если вообще никому не нужно, мы не будем влезать в это безобразие.
Но если представить, что мы внутри и отказаться нельзя, то, наверное, единственное, что можно сделать, – это давить, пользоваться административной властью тех, кто этот проект сверху спустил. Если компания бюрократическая, есть кто-то, кто принял решение, надо требовать выделить руководителя, который обладает весом в подразделениях, задействованных в проекте.
У нас был такой большой бюрократический клиент, которому на верхнем уровне этот проект был все-таки нужен. И там все подписывали приказ о проекте. В этом приказе были отдельно описаны бонусы, которые руководитель проекта со стороны заказчика может выдавать наиболее задействованным на проекте сотрудникам. И были прописаны штрафы на тех сотрудников, которые сопротивляются.
Я такое видел один раз. Меня впечатлило.
Т.е. руководитель проекта, выделенный со стороны ИТ-службы, приказом генерального директора был наделен возможностью лишить квартальных и годовых премий сотрудников любого подразделения, если он считал, что этот сотрудник мешает проекту. А мог выделить бонус любому сотруднику.
Это жестоко, но хороший вариант, мне кажется. Проект шел как по маслу.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.
Приглашаем на конференции Инфостарта 2025 годаINFOSTART TEAMLEAD EVENT
Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров. INFOSTART A&PM EVENT (Анализ & Управление проектами)
Практическая конференция для аналитиков и руководителей проектов 1С. |