2. Когда Вы освоились с методологией, за плечами у Вас не менее 10 успешных проектов, проведите рефлексию с постоянными членами команды. Подумайте о том, какие инструменты при оптимизации процессов работали хорошо, а какие не очень, и почему. Подумайте как это можно исправить и потихоньку, очень осторожно тестируйте нововведения в методологию.
3. Не забывайте смотреть «по сторонам». Участвуйте в конференциях, читайте профильную литературу, перенимайте опыт конкурентов. Методология не стоит на месте и в общем и целом идет по пути повышения удобства. Например, сейчас семимильными шагами развиваются технологии process mining (дословно «добыча процессов их шахты»), которые позволяют получать модели процессов исходя из записей действий пользователей (логов) систем.
Могу сказать за себя, что спустя 15 лет не могу назвать ни одного «лишнего» инструмента, который можно было бы «выкинуть на свалку истории». Главное – уметь ими пользоваться.
3. «Нам нужен беспроигрышный вариант».
Универсальная пилюля; нечто, что поможет сделать сразу хорошо. Поразительно, но взрослые, состоявшиеся люди каждый раз надеются найти в том или ином подходе волшебную силу и жестоко разочаровываются, когда понимают, что сакрального знания не существует. Каждый инструмент лечит что-то одно, а для чего-то другого абсолютно бесполезен[14]. Лекарство от кашля не поможет от облысения, а капли от насморка бесполезны при изжоге.
При этом происходит одно из двух: либо все подходы объявляются ересью (изменениям выносится окончательное и бесповоротное «нет»), либо начинается поиск «Святого Грааля». В последнем случае претворение в жизнь очередного «чудесного средства» сопровождается сносом всех предыдущих достижений, даже весьма удачных. И каждый раз история начинается с начала.
Agile. В одночасье это слово стало символом надежды для одного учреждения. Оно имело богатый и успешный опыт оптимизации процессов как фронт-, так и бэк-офиса и решило, что пора расшевелить IT-отдел, в котором непонятно что творилось. Agile связана с разработкой ПО, так что этот шаг всем казался логичным. Потом решили заодно и в остальных подразделениях тоже внедрять Agile. Без какой-либо проработки, без системного взгляда на то, как инструменты быстрой разработки программ могут быть использованы при обслуживании клиентов – физических лиц в офисах.
Тут, правда, воспряли духом карьеристы (как явные, так и латентные). Многие проекты, которые еще вчера вообще никакого отношения не имели к Agile, сразу переименовали (нет, это не шутка и не фигура речи).
Целые толпы радостных сотрудников бродили по этажам, размахивая вымышленными флагами с непонятными словами Scrum, Бэклог и т. д.
Оставим за скобками тот факт, что организация имела подразделение по оптимизации процессов, которое в свое время, локально, правда, уже пробовало этот подход. Профессионалов с опытом преобразований в данной конкретной компании попросили посидеть в сторонке. А их мольбы о том, что автоматизировать сломанные процессы себе дороже, были отнесены на счет их слабого понимания мировых тенденций развития. Ну ладно, нет пророка в своем отечестве.
Дальше – больше. Год пытались все сделать сами, и… ничего не менялось. Совсем. Затем наняли стороннего консультанта, который… сразу попросил оптимизировать процессы, объясняя на простом примере, что нецелесообразно автоматизировать передачу 20 бумажек, которые не требуются по закону в рамках HR-цикла. Agile с этим справиться не мог[15], поэтому стали срочно искать наших героев – оптимизаторов из тех, кто еще не уволился.
Единственный совет, который здесь можно дать, прост как три рубля: «Не влюбляйтесь в инструменты».
А перед тем, как «закусив удила» начинать внедрять «волшебную пилюлю» налево и направо, изучите вопрос: почитайте, пройдите обучение, пообщайтесь с практиками, которые уже использовали так полюбившийся Вам подход. И обязательно заведите себе табличку для методологий с двумя колонками: «плюсы» и «минусы».
4. «Долой бюрократию!»
В представлении большинства людей проекты овеяны романтическим флером и рассматриваются скорее как интересное приключение, альтернатива серым будням. Можно даже рисовать рекламный буклет с призывом вступить в команду: что-то из серии «В проекте ты сможешь высказывать свои идеи, стоять рядом с флипчартом и пить кофе в окружении умных людей. И ничего не делать». Только в проекте требуется так же, как и при операционной деятельности, фиксировать прогресс, делать презентации, подготавливать отчетность и соблюдать определенные формальные требования. Безусловно, необходим баланс: не нужно вместо проведения встреч и мозговых штурмов сажать команду за компьютеры и проверять, кто из них печатает больше и быстрее, но обратная ситуация еще хуже.
Честно говоря, каждый раз вопрос: «Зачем нам готовить документацию по проекту?» – ставит меня в тупик. Допустим, Вы с командой подготовили карту эмпатии или, скажем, схему процесса. Вы же не собираетесь держать ее в уме? Даже если схема осталась на флипчарте, где гарантия что Спонсор или Вы сами поймете эти каракули пару дней спустя? А как возвращаться к схеме при обсуждениях? Таскать за собой по этажам рулоны листов? А если Вы используете инструменты, не предназначенные для чужих глаз? Например, матрицу анализа заинтересованных сторон[16]. Представьте себе, что будет, если «не поддерживающий» в соответствии с матрицей Зампред случайно зайдет в переговорную и увидит все своими глазами!
Один из самых курьезных моментов в моей практике был, когда команда, не удосужившись сделать документацию вовремя… потеряла проект.
Переговорная, где были все неоцифрованные материалы, по ошибке была отдана под важное мероприятие и все материалы, включая карту процесса, результаты замеров и т. д. были просто… утеряны.
Вывод прост. Необходимо фиксировать результаты, чтобы не остаться у разбитого корыта.
5. «Давайте придумаем решение за полдня».
В принципе это логичное продолжение предыдущего пункта. Зачем нужна методология и «танцы с бубнами», если можно придумать все за полдня. И не важно, что решение будет поверхностным, основанным не на цифрах и фактах, а на показушном энтузиазме. Не будет системы, не будет альтернатив (скорее всего, более продуманных и прибыльных). Будет лишь бездумная трата времени и сил.
Одно из правил формулирования проблем в проектах – строжайшее табу даже на намек потенциального решения. Если команда по итогам анализа Голоса Клиента пишет что-то из серии: «Из-за отсутствия станка с ЧПУ длительность процесса производства с момента поступления заготовки в цех металлообработки до момента поступления на склад готовых изделий в 2024 году увеличилась на 20 %…», то…
Дальше можно не продолжать. Во-первых, непонятно зачем вообще теперь запускать проект, отвлекать людей, проводить анализ, если решение и так уже есть. Купите станок с ЧПУ и будет Вам счастье… Это теперь не проблема, а задача…
Во-вторых, поверьте моему опыту, если Вы заранее пишете причину, значит Вы все для себя решили. Будет так, а не иначе. Даже если по итогам анализа рядом будет «лежать» простое, в 20 раз более эффективное решение, Вы его просто не заметите.
Самое смешное, что за полдня придумать ничего нельзя, нет анализа и понимания причин, поэтому копаете Вы неглубоко. Итог: решение «на скорую руку», которое держится на честном слове и, как правило, требует замены уже через месяц.
Заплатка не может быть несущей конструкцией.
Избежать подобных ситуаций просто.
1. Четко оценивайте риски. Перед тем как радостно бежать воплощать в жизнь очередную непроработанную идею, протестируйте ее, спросите у клиентов и экспертов, а так ли на самом деле она хороша. Не создадите ли Вы «пробоину» размером со слона дальше по процессу, заткнув здесь и сейчас трещину размером с комара?
2. Если Вам в жизни не хватает «креатива» займитесь… лепкой, живописью, да хоть художественным свистом (только не дома, а то денег не будет), но не пытайтесь заменить системный анализ набором шаблонных решений из серии «во всем виноват соседний отдел». Поверьте – не взлетит.
6. «Методология у нас никакая не работает, у нас менталитет другой».
Однажды на одном из сложных заседаний по проекту ответственный за бизнес вице-президент, который с самого начала наплевал на всю методологию, обвинил команду во всех смертных грехах. После этого Генеральный посмотрел на него и сказал: «Вам обязательно было самому убедиться, что нельзя совать руки в розетку? Почему Вы не верите в проверенный алгоритм усовершенствования, почему по старой привычке изобретаете третий путь? У меня для Вас новость: первые два уже определили, и они прекрасно работают».
Чего на моей памяти только не списывали на «культурные особенности»: вплоть до отказа от покупки автоматических кранов в туалеты для офиса.
Удивительно, но методы, которые были проверены в 20 местах на планете, от Сахалина до Индии, почему-то не должны работать у Вас на предприятии. И чем же позвольте узнать, Ваша организация так выделяется на фоне остальных?
Безусловно, нужно учитывать культурные особенности, но к инструментам «улучшайзинга» они имеют весьма опосредованное отношение. Почему? Если все упростить донельзя, то ответ будет следующим: все методологии по совершенствованию всего и вся имеют под собой одну основу – здравый смысл.
Все используемые в них инструменты не помогают Вам узнать что-то новое в профессиональном плане, то есть Вам не откроется новый язык программирования или новый тип личностного тестирования. Все, что Вы узнаете в процессе оптимизации или разработки, будет основано на Ваших знаниях.