Оптимизатор бизнес-процессов 2.0. Лучшие инструменты повышения эффективности организаций, команд и систем - Александр Александрович Сорочан
Занавес.
7. Бездумное и вечное.
На одном из моих тренингов, когда я рассказывал про алгоритм планирования, я обратился к аудитории и попросил поделиться мнением, какой следующий шаг мне записать на флипчарте.
Одна девушка робко подняла руку и спросила: «Наверное, подумать?» «Точно, – отозвался я. – Вообще, в любом алгоритме предлагаю сначала подумать».
Как ни печально, отношение ко многим инструментам не соответствует вышеназванному принципу – для начала подумать. На тренингах люди пытаются все время записать или зазубрить сложные названия, хотя хороший тренер в первую очередь хочет, чтобы слушатели поняли суть.
Если в диаграмме Вам нужен дополнительный, четвертый столбик, а на тренинге сказали, что их обычно три, нарисуйте его. Инструмент должен помогать в анализе, а не ограничивать его.
И уж тем более постарайтесь избегать ситуаций, подобных следующей.
Команда, с которой я работал как наставник, приступила к Фазе Анализа. Проект требовал статистической проверки влияния факторов на длительность доставки продукции.
Ребята проверили только один фактор – удаленность точки продаж от склада.
– Как Вы полагаете, влияет ли расстояние на время доставки, если не проводить анализ? – спросил я.
– Конечно, – последовал ответ.
– Тогда почему Вы проверили очевидный вариант, но не собрали данные и не проверили остальные, менее очевидные?
– А чего Вы к нам привязались? Нас учили, что в проекте должен быть как минимум один стат-тест. Мы его сделали. Нам сказали – мы и сделали.
И их нисколько не смущало, что все было сделано «для галочки».
8. Мы ничего не нашли, поэтому считаем себя правыми.
Действительно, зачем ходить к Заказчику и просить дополнительное время, зачем собирать новые данные, зачем перепроверять логику своих выводов? Можно просто сказать: «Мы ничего не нашли, поэтому решили так».
В проекте по повышению эффективности, как в задаче по алгебре: нужно либо найти ответ, либо доказать, что решения не существует. В противном случае задача не решена.
Разбираться в своей работе, а особенно изучать причины неудач, ошибок, низкой производительности, не любит никто. Так устроена наша психика. Это можно понять и простить. Но нежелание сделать несколько простых шагов, чтобы хотя бы разобраться в ситуации и облегчить жизнь в первую очередь себе и своей команде, понять гораздо сложнее.
Я безумно люблю работать со службами поддержки. Если вдруг появляется ситуация, которая выходит за рамки стандартного набора ошибок, прописанных в скрипте, чаще всего… команда обвиняет клиентов в… некомпетентности и неумении понимать простейшие инструкции.
Команда одной из служб поддержки два месяца пыталась убедить всех, что описываемые пользователем ошибки не могут существовать в принципе.
Они, не особо стараясь, смотрели настройки пользователя со своей стороны и не находили аномалий, исходя из стандартных методов диагностики.
И только когда их, чуть ли не в приказном порядке, заставили встать на место пользователя, сделать заказ с его стороны, у команды открылись глаза, и она начала «копать».
Правда для этого пришлось поговорить со Спонсором проекта, повиниться и убедить ее выделить дополнительное время и людей на завершение проекта. Но в итоге команду ждал успех.
9. У нас уже есть решение.
Постоянные попытки продать уже имеющийся вариант мешают проекту и сбивают с толку экспертов. Зачем делать проект, если ответ уже есть? Показать, что идете в ногу со временем? Поддержать внутрикорпоративную моду? В любом случае это трата времени и сил.
В продолжение примера из предыдущего пункта. Да, бывают ситуации, когда Руководитель, курирующий проект, не дает дополнительных ресурсов, мотивируя это тем, что потрачено и так слишком много времени, а результаты нужны были вчера.
Но гораздо чаще происходит одно из двух: команда придумала решение, делает сбор данных и анализ только для вида, не желая знать о фактах, которые не вписываются в их картину мира, или же просто ждет, когда наставник сам назовет решение.
При этом всегда называется топ 4 причин низкой эффективности:
– Люди: плохие клиенты, непонятливые сотрудники, недостаток кадров, переизбыток кадров и т. д.
– Маленькие бюджеты: вот были бы у нас деньги, мы бы не заставляли клиентов 30 раз переписывать форму заявления. Вы серьезно?
– IT: во всем виноваты IT.
– Устаревшие регламенты или их несоблюдение. Второе, как правило, является следствием первого, только вот я так и не могу взять в толк, кто так отчаянно мешает их (регламенты) переписать?
Как показывает практика, в 90 % случаев это очевидные, но не относящиеся к реальности предположения. Проблемы чаще всего связаны с другими факторами, но для того, чтобы их найти, нужно постараться.
10. Наше дело – отчитаться.
Перед каждым докладом по результатам проектов я прошу участников рассказать, что они сделали (какие были проблемы, каковы их причины, как предлагается их устранить), а не то, что делалось.
И каждый раз слышу, что люди готовили паспорт проекта и план, затем собирали Голос и так далее… Вы не поверите, но я и сам могу рассказать, что делала команда: они же работают в соответствии с алгоритмами, которым их обучили.
И каждый раз оказывается, что решения не соответствуют проблемам, цели взяты как будто из другого проекта, а анализ проводился не затем, чтобы выявить причину, а чтобы «закидать» Заказчика цифрами.
Чаще всего процессы отображаются не так, как они происходят в жизни, а так, как написано в нормативных документах.
Спасение утопающих…
Скажу честно, очень многие из вышеназванных проблем полностью устраняются только с опытом, после многочисленных проектов, которые оптимизаторы вынесут на своих плечах. Тем не менее есть несколько действенных принципов и приемов, которые позволят командам набрать опыт как можно скорее.
1. Наставник.
Сертификат Черного Пояса выдают только после обучения, успешного прохождения теста и успешной защиты проектов (да-да, Вы не ослышались, нескольких проектов). По меньшей мере с момента обучения до получения заветной «корочки» проходит два года. При условии, что кандидат старается и тратит на проекты все доступное время.
Странно ожидать, что человек, только прошедший обучение, может справиться со всеми трудностями сам. И ключевую роль в достижении результата играет помощь наставника.
Давайте сразу договоримся, что наставник – это не теоретик, не шаман, не руководитель, сделавший свой первый и единственный проект «в те далекие годы…». Наставник – специалист, сочетающий в себе единство теоретического и практического опыта постоянного «улучшайзинга».
Задача наставника – помочь командам контролируемо наступать на грабли получать бесценный опыт. Другими словами, функция наставника – не делать ничего за команду проекта, давая им возможность учиться
