Образ результата, о котором я говорил в прошлой главе, уже весьма существенно повышает вероятность успешного внедрения изменений, особенно если сделан качественно и детально. Но есть еще один метод, который, к сожалению, используется не так часто, – прототипирование изменений.
Что же такое прототипирование? Это что-то среднее между созданием плана внедрения изменений и пилотным внедрением изменений на ограниченных участках или на ограниченную группу пользователей. Если говорить проще, то прототипирование – это такой процесс, в котором привлекаются ключевые участники процесса, подверженного изменениям, и одновременно моделируется работа нового процесса.
Прототипирование изменений является одним из самых эффективных методов снижения рисков неудачи и серьезных потерь при внедрении изменений. Несмотря на то, что создание прототипов требует определенных ресурсов и дополнительного времени, такой дополнительный шаг может ускорить изменения за счет снижения сопротивления и снижения вероятности отклонений от первоначального плана. Кроме того, использование прототипов позволяет найти потенциал для экономии времени или денег, а также предусмотреть дополнительные вложения именно в те направления, где выделенных ресурсов не хватает. Таким образом, расходование ресурсов на полномасштабную трансформацию становится более эффективным и целевым.
Кроме того, прототипирование позволяет повысить шанс на успех изменений за счет того, что дает возможность на старте с минимальными затратами протестировать удобство «интерфейса» ваших изменений, или удобство взаимодействия с новым процессом, который вы планируете внедрить в рамках работы с изменениями.
В данном контексте под интерфейсом я понимаю не только цифровой интерфейс и доступность кнопок на экране, но и организационный интерфейс, в который входят акты, регламенты и прочие организационные моменты.
Таким образом, чем проще этот интерфейс, чем интуитивнее он понятен, чем меньше там лишних шагов, тем меньше сопротивления он вызывает и тем меньше транзакционных издержек требуется на его внедрение. И использование сессий прототипирования изменений позволит на старте обкатать эти новые интерфейсы, проверить их удобство и работоспособность. Это позволит сократить разрыв между авторами изменений и сотрудниками, которые будут жить согласно этим изменениям, выявить риски и недочеты и нивелировать их на старте работы с изменениями. В противном случае, при неудобном и непонятном новом интерфейсе, ваши сотрудники просто не будут действовать согласно ожиданиям, если вообще смогут его понять и использовать.
В моем опыте была компания, которая запустила четырехчасовое обучение, после которого надо было сдать зачет, после изменения системы премирования менеджеров по продажам. Документ был настолько сложный и запутанный, что разобраться с ним можно было только после обучения длиной в 4 часа, можете себе представить? Это как раз пример того, что регламент не прогоняли через систему прототипирования и финальные пользователи не были включены в его создание.
Второй пример, которым я хочу поделиться, касается внедрения длинных процессов. Одна из компаний, с которой я работал, решила внедрить методологию квартального планирования и распространить ее на 75 филиалов. Суть идеи была в том, чтобы внедрить метод скользящего планирования и корректировки годовой стратегии на базе ежеквартального анализа цифр. Нас изначально позвали для разработки обучающей программы, чтобы обучить пилотные филиалы этому подходу, а затем внедрить его. Затея с треском провалилась.
Тогда мы взялись за прототипирование работы этого нового регламента и привлекли самых заинтересованных директоров к тестированию. В процессе прохождения по этапам обнаружилось, что до определенного пункта регламент был написан максимально подробно и понятно. Было ясно, откуда брать данные, как их трактовать и использовать. Однако затем все стопорилось на этапе, когда нужно было выбрать стратегию развития филиала из нескольких предложенных вариантов, спланированных на базе предварительно собранных данных. Во-первых, стратегии были указаны в отдельном огромном приложении, которое еще надо было найти и прочитать. А во-вторых, не было совершенно никакой информации о том, на базе каких данных надо делать выбор предпочтительной стратегии. Такой регламент привел к тому, что появился риск использования разных данных разными филиалами, а также риск разночтения стратегий, описанных в приложении.
Прототипирование показало, на каком этапе процесса возникает барьер, который сводит на нет деятельность филиалов на предыдущих шагах и не позволяет обеспечить требуемый уровень стандартизации. Без прототипа этот регламент так и оставался бы недееспособным до следующего обновления через два-три года, он порождал бы сопротивление и так и не решил бы задачу, ради которой его создавали.