Книга: Оптимизатор бизнес-процессов. Лучшие инструменты управления для повышения эффективности
Назад: «А все-таки он существует»
Дальше: Методология методологии рознь

Глава 7

Это скучная-скучная методология

Знание – орудие, а не цель.

Л.Н. Толстой


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

«Ученье свет, а неученых – тьма»

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

Ответ очевиден: нюансы, детали, сложные манипуляции могут означать разницу между жизнью и смертью. То же самое можно отнести к пилотам, электромонтерам и т. д.

По какой-то непонятной причине мы не мыслим теми же категориями в бизнесе. Нет, безусловно, речь здесь не идет о жизни и смерти, вернее, о жизни или смерти людей. А вот о судьбе организации – вполне. Бухгалтер, не знающий несколько положений бухгалтерского учета, менеджер по работе с клиентами, не в полной мере знакомый с продуктами, юрист, смутно представляющий, как выглядит гражданский кодекс, могут нанести урон поистине циклопических размеров. Даже сотрудник HR может стоить вам миллионов упущенной прибыли, приняв на работу слабого кандидата или не рассмотрев кандидата перспективного.

Почему же в сфере управления изменениями мы видим столько пренебрежения к обучению и методологии как со стороны больших боссов, так и рядового персонала? И чем нам это грозит?

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



1. ВСЕ СЛИШКОМ ЛЕГКО И ПРОСТО.

Действительно, очень многие инструменты не идут ни в какое сравнение с квантовой механикой или теорией ракетной тяги. Более того, почти все свои тренинги я начинаю со слов, что Лин 6 Сигма, Agile, теория ограничений или PDCA в первую очередь про здравый смысл. Логика, логика и еще раз логика. Просто в отличие от знаний общих (обо всем и пряниках), все инструменты имеют практическую направленность и «смотрят» на проблему под определенным углом. Непонятно? Хорошо, давайте на примере.

В одном из своих проектов, когда я рассказывал об инструментах графического отображения процессов (проще говоря, схемах), один из слушателей, фыркнув на весь зал, сообщил, что как айтишник он давно владеет данным методом. Я попросил его продемонстрировать, как делать это правильно. Знаете ли, очень хотелось, чтобы человек, ни разу не делавший проект, научил меня, недалекого, всего с 40 проектами за спиной, уму-разуму.

ПОВЫШЕНИЕ ЭФФЕКТИВНОСТИ – НЕ ИГРУШКА И НЕ СПОСОБ САМОУТВЕРДИТЬСЯ ИЛИ ПОКРАСОВАТЬСЯ ПЕРЕД АКЦИОНЕРАМИ. ЭТО ДЕЙСТВУЮЩИЙ БИЗНЕС-ИНСТРУМЕНТ, НО РАБОТАТЬ В ПОЛНУЮ СИЛУ ОН МОЖЕТ ТОЛЬКО В ПРАВИЛЬНЫХ РУКАХ.

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

Легкость в понимании инструментов и простота их применения на практике не одно и то же. У всех инструментов есть нюансы, понимание которых приходит только с опытом.

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



2. МНОГО ЛИШНЕГО И НЕНУЖНОГО.

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

В цикле DMAIC методологии Лин 6 Сигма всего 5 фаз:

 определение проблемы, КПЭ и команды проекта,

 описание процесса и его измерение,

 анализ корневых причин проблемы,

 разработка и внедрение решений,

 контроль измененного процесса.

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

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

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

Затем настал день презентации проектов, завершенных в первом полугодии. Наши «потеряшки» в красивых вечерних платьях и смокингах вышли на сцену. Предварительно они направили смс Спонсору, что все тип-топ, и отключили мобильники. Включился проектор, пошла презентация и… разразился жуткий скандал.

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

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



3. НАМ НУЖЕН БЕСПРОИГРЫШНЫЙ ВАРИАНТ.

Универсальная пилюля; нечто, что поможет сделать сразу хорошо. Поразительно, но взрослые, состоявшиеся люди каждый раз надеются найти в том или ином подходе волшебную силу и жестоко разочаровываются, когда понимают, что сакрального знания не существует. Каждый инструмент лечит что-то одно, а для чего-то другого абсолютно бесполезен. При этом происходит одно из двух: либо все подходы объявляются ересью (изменениям выносится окончательное и бесповоротное «нет»), либо начинается поиск «Святого Грааля». В последнем случае претворение в жизнь очередного откровения сопровождается сносом всех предыдущих достижений, даже весьма удачных. И каждый раз история начинается с начала.

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

Тут, правда, воспряли духом карьеристы (как явные, так и латентные). Многие проекты, которые еще вчера вообще никакого отношения не имели к Agile, сразу переименовали (нет, это не шутка и не фигура речи).

Целые толпы радостных сотрудников бродили по этажам, размахивая вымышленными флагами с непонятными словами Scrum, Backlog и т. д.

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

Дальше – больше. Год пытались все сделать сами, и… ничего не менялось, совсем. Затем наняли стороннего консультанта, который… сразу попросил оптимизировать процессы, объясняя на простом примере, что нецелесообразно автоматизировать передачу 20 бумажек, которые не требуются по закону в рамках HR-цикла, Agile с этим справиться не мог, поэтому стали срочно искать наших героев – оптимизаторов из тех, кто еще не уволился.



4. ЗАЧЕМ ПЕРЕНОСИТЬ НА БУМАГУ.

В представлении большинства людей проекты овеяны романтическим флером и рассматриваются скорее как интересное приключение, альтернатива серым будням. Можно даже рисовать рекламный буклет с призывом вступить в команду: что-то из серии «В проекте ты сможешь высказывать свои идеи, стоять рядом с флипчартом и пить кофе в окружении умных людей. И ничего не делать». Только в проекте требуется так же, как и при операционной деятельности, фиксировать прогресс, делать презентации, подготавливать отчетность и соблюдать определенные формальные требования. Безусловно, необходим баланс: не нужно вместо проведения встреч и мозговых штурмов сажать команду за компьютеры и проверять, кто из них печатает больше и быстрее, но обратная ситуация еще хуже.

Честно говоря, каждый раз вопрос: «Зачем нам готовить документацию по проекту?» – ставит меня в тупик. Допустим, вы с командой подготовили карту эмпатии или, скажем, схему процесса. Вы же не собираетесь держать ее в уме? Даже если схема осталась на флипчарте, где гарантия что Спонсор или вы сами поймете эти каракули пару дней спустя? А как возвращаться к схеме при обсуждениях? Таскать за собой по этажам рулоны листов? А если вы используете инструменты, не предназначенные для чужих глаз? Например, матрицу анализа заинтересованных сторон. Представьте себе, что будет, если «не поддерживающий» в соответствии с матрицей Зампред случайно зайдет в переговорную и увидит все своими глазами!



5. ДАВАЙТЕ ПРИДУМАЕМ РЕШЕНИЕ ЗА ПОЛДНЯ.

В принципе это логичное продолжение предыдущего пункта. Зачем нужна методология и «танцы с бубнами», если можно придумать все за полдня. И не важно, что решение будет поверхностным, основанным не на цифрах и фактах, а на показушном «ура». Не будет системы, не будет альтернатив (скорее всего, более продуманных и прибыльных). Будет лишь бездумная трата времени и сил.



6. МЕТОДОЛОГИЯ У НАС НИКАКАЯ НЕ РАБОТАЕТ, У НАС МЕНТАЛИТЕТ ДРУГОЙ.

Однажды на одном из сложных заседаний по проекту ответственный за бизнес вице-президент, который с самого начала наплевал на всю методологию, обвинил команду во всех смертных грехах. После этого Генеральный посмотрел на него и сказал: «Вам обязательно было самому убедиться, что нельзя совать руки в розетку? Почему вы не верите в проверенный алгоритм усовершенствования, почему по старой привычке изобретаете третий путь? У меня для вас новость: первые два уже определили, и они прекрасно работают».

ГЛАВНЫЙ ИДЕОЛОГ ПРОИЗВОДСТВЕННОЙ СИСТЕМЫ «ТОЙОТЫ» ТАЙИТИ ОНО: «НИКТО НЕ ЗНАЕТ РАБОТУ НА КАЖДОМ ОТДЕЛЬНО ВЗЯТОМ УЧАСТКЕ ЛУЧШЕ, ЧЕМ ЛЮДИ, РАБОТАЮЩИЕ НА ДАННОМ УЧАСТКЕ».

Чего на моей памяти только не списывали на «культурные особенности»: вплоть до отказа от покупки автоматических кранов в туалеты для офиса.

Удивительно, но методы, которые были проверены в двадцати других странах, от Индии до Америки, почему-то не должны работать у нас. И чем же мы так выделяемся на фоне остальных?

Безусловно, нужно учитывать культурные особенности, но к инструментам «улучшайзинга» они имеют весьма опосредование отношение. Почему? Если все упростить донельзя, то ответ будет следующим: все методологии по совершенствованию всего и вся имеют под собой одну основу – здравый смысл.

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

Тогда почему же некоторым не удается то, что получается у всех? Производственная система и Лин, например, пришли к нам из Японии. Всем известно, какие трудолюбивые и исполнительные сотрудники там, у них. У нас все по-другому.

Вы удивитесь, но японцы не смогли применить знания «Тойоты» в банковской сфере, хотя пытались, и не раз. А у нас это получилось.

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

Но хватит ходить вокруг да около. Пора поговорить о пресловутых методологиях. Их слабых и сильных сторонах.

Назад: «А все-таки он существует»
Дальше: Методология методологии рознь