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

Будь то система планирования, управленческого учета и IFRS отчетности, мотивации или принятия инвестиционных решений – позиция, что существует идеальный подход, который можно прописать одним махом в ERP, после которого все заработает – слишком наивная. В реальности каждый раз срабатывает наоборот. Сначала ставишь процесс, затем пишешь стандарт.

Почему так получается? Почему нельзя взять и разом поменять правила?

По опыту есть как минимум три причины:
– Неверие менеджмента и сопротивление персонала.
– Нестыкуемость стандарта с заведенным порядком.
– Санкции и последствия за принятие ответственности.
Для наглядности разберем на трех последовательных примерах.

Раз. “Если сейчас оно так работает, значит так надо!”

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

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

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

Два. “Вот вы хотите фондировать эти проекты, а в бюджете деньги есть?”

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

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

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

Три. “А если не сработает, деньги потратим, а кто отвечать будет?”

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

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

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

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

Что с этим делать?

Просто реализовывать изменения. Сделать в виде собственной инициативы менеджера/подразделения. Обкатать несколько раз. И только потом описывать стандартом удавшийся рабочий процесс, доказавший успех.

Итого, работает подход – сначала ищем работающий процесс, обкатываем до стабильной работы и потом пишем стандарт. Парадокс, потому что в таком случае, если удастся, то вернешься со щитом. А не удастся, то и щит отберут.

Еще на эту тематику из toolkits можно прочитать:
«Принципы».
«Процедуры».
«Компетенции».
«Приказ».
«Проект».
«Навсегда».

На прошлой неделе опубликовали T: Успеть читать одну книгу в неделю.

В планах дальнейших публикаций практик управления на уровне СЕО и СЕО-1:
— Три ультранетворкера.
— Где брать информацию.
— Страх как (де)мотиватор.
— Успех из коммуникаций.
— Теория графов и выгоды общения.
— Как взглянуть на календарь иначе.
— Что сказать новому сотруднику в первый день.
— Первейшая цель управленческого учета в бизнесе.
— Integrity / честность / целостность как ценность в работе.