Оптимизатор бизнес-процессов 2.0. Лучшие инструменты повышения эффективности организаций, команд и систем - Александр Александрович Сорочан

Занавес.

7. Бездумное и вечное.

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

Одна девушка робко подняла руку и спросила: «Наверное, подумать?» «Точно, – отозвался я. – Вообще, в любом алгоритме предлагаю сначала подумать».

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

Если в диаграмме Вам нужен дополнительный, четвертый столбик, а на тренинге сказали, что их обычно три, нарисуйте его. Инструмент должен помогать в анализе, а не ограничивать его.

И уж тем более постарайтесь избегать ситуаций, подобных следующей.

Команда, с которой я работал как наставник, приступила к Фазе Анализа. Проект требовал статистической проверки влияния факторов на длительность доставки продукции.

Ребята проверили только один фактор – удаленность точки продаж от склада.

– Как Вы полагаете, влияет ли расстояние на время доставки, если не проводить анализ? – спросил я.

– Конечно, – последовал ответ.

– Тогда почему Вы проверили очевидный вариант, но не собрали данные и не проверили остальные, менее очевидные?

– А чего Вы к нам привязались? Нас учили, что в проекте должен быть как минимум один стат-тест. Мы его сделали. Нам сказали – мы и сделали.

И их нисколько не смущало, что все было сделано «для галочки».

8. Мы ничего не нашли, поэтому считаем себя правыми.

Действительно, зачем ходить к Заказчику и просить дополнительное время, зачем собирать новые данные, зачем перепроверять логику своих выводов? Можно просто сказать: «Мы ничего не нашли, поэтому решили так».

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

Разбираться в своей работе, а особенно изучать причины неудач, ошибок, низкой производительности, не любит никто. Так устроена наша психика. Это можно понять и простить. Но нежелание сделать несколько простых шагов, чтобы хотя бы разобраться в ситуации и облегчить жизнь в первую очередь себе и своей команде, понять гораздо сложнее.

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

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

Они, не особо стараясь, смотрели настройки пользователя со своей стороны и не находили аномалий, исходя из стандартных методов диагностики.

И только когда их, чуть ли не в приказном порядке, заставили встать на место пользователя, сделать заказ с его стороны, у команды открылись глаза, и она начала «копать».

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

9. У нас уже есть решение.

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

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

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

При этом всегда называется топ 4 причин низкой эффективности:

– Люди: плохие клиенты, непонятливые сотрудники, недостаток кадров, переизбыток кадров и т. д.

– Маленькие бюджеты: вот были бы у нас деньги, мы бы не заставляли клиентов 30 раз переписывать форму заявления. Вы серьезно?

– IT: во всем виноваты IT.

– Устаревшие регламенты или их несоблюдение. Второе, как правило, является следствием первого, только вот я так и не могу взять в толк, кто так отчаянно мешает их (регламенты) переписать?

Как показывает практика, в 90 % случаев это очевидные, но не относящиеся к реальности предположения. Проблемы чаще всего связаны с другими факторами, но для того, чтобы их найти, нужно постараться.

10. Наше дело – отчитаться.

Перед каждым докладом по результатам проектов я прошу участников рассказать, что они сделали (какие были проблемы, каковы их причины, как предлагается их устранить), а не то, что делалось.

И каждый раз слышу, что люди готовили паспорт проекта и план, затем собирали Голос и так далее… Вы не поверите, но я и сам могу рассказать, что делала команда: они же работают в соответствии с алгоритмами, которым их обучили.

И каждый раз оказывается, что решения не соответствуют проблемам, цели взяты как будто из другого проекта, а анализ проводился не затем, чтобы выявить причину, а чтобы «закидать» Заказчика цифрами.

Чаще всего процессы отображаются не так, как они происходят в жизни, а так, как написано в нормативных документах.

Спасение утопающих…

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

1. Наставник.

Сертификат Черного Пояса выдают только после обучения, успешного прохождения теста и успешной защиты проектов (да-да, Вы не ослышались, нескольких проектов). По меньшей мере с момента обучения до получения заветной «корочки» проходит два года. При условии, что кандидат старается и тратит на проекты все доступное время.

Странно ожидать, что человек, только прошедший обучение, может справиться со всеми трудностями сам. И ключевую роль в достижении результата играет помощь наставника.

Давайте сразу договоримся, что наставник – это не теоретик, не шаман, не руководитель, сделавший свой первый и единственный проект «в те далекие годы…». Наставник – специалист, сочетающий в себе единство теоретического и практического опыта постоянного «улучшайзинга».

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