Почему сотрудники возвращаются к старой системе после обучения

Обучение сотрудников новой системе почти всегда выглядит одинаково: несколько вебинаров, инструкции, сертификаты в конце. А потом проходит две недели, и руководитель проекта видит, что команда так и работает в Excel, пересылает документы по почте и не заходит в систему вообще. За несколько лет работы с внедрением цифровых платформ в строительстве я вижу одни и те же три ошибки, которые к этому приводят.

Первая ошибка — участники не понимают правила игры

Звучит просто, но на практике это самая частая причина провала. Сотрудники приходят на обучение и честно спрашивают: а что вы вообще за система, нам про это ничего не говорили, нам не давали распоряжения работать с этими данными. Люди не в контексте процесса — они не знают, какая у них роль, зачем их вообще собрали и к какому результату они должны прийти. Итог предсказуем — дезориентация, отсутствие мотивации дойти до конца обучения и, соответственно, никакой обратной связи в конце. Чтобы этого избежать, нужно сделать две вещи еще до старта: получить от руководства четкую и публичную установку, что сотрудники теперь участвуют в пилотном процессе, и на первой же встрече проговорить каждому, какая у него зона ответственности и что считается результатом.

Вторая ошибка — надежда, что процессы сами выстроятся во время обучения 

Это моя любимая ошибка, потому что она встречается почти у каждого клиента. Мы приходим, начинаем разбираться с текущими процессами компании и понимаем, что даже сейчас, без всякой цифровизации, люди не могут внятно объяснить, кто за что отвечает. А ведь нам еще предстоит построить новый процесс поверх старого, в котором и так путаница. Результат — на старте уходит огромное количество времени просто на то, чтобы разобраться, что происходит сейчас, вместо того чтобы проектировать новое. Сотрудники теряют фокус того, что вообще нужно менять, и до финального результата команда просто не доходит. Решение здесь только одно — ревизия текущих процессов и распределение зон ответственности должны случиться до начала обучения, а не во время него.

Третья ошибка — обучать всех и всему 

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

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

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

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