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