Читать книгу: «Оптимизатор бизнес-процессов 2.0. Лучшие инструменты повышения эффективности организаций, команд и систем», страница 3

Глава 3
Хочу все и сразу

Стоит Винни-Пух, жует булочку.

Мимо идет Пятачок.

– Винни, Винни, дай булочку!

– Это не булочка, Пятачок, это пирожок!

– Ну дай пирожок!

– Это не пирожок, это рогалик!

– Ну поделись рогаликом!

– Слушай, Пятачок, ты сначала определись, что ты хочешь, а потом проси.

Профессиональный анекдот

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

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

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

1. Определение списка процессов/продуктов для оптимизации, создания и автоматизации.

2. Создание мастер-данных и/или инфраструктуры сбора данных.

3. Обеспечение поддержки менеджмента на всех уровнях.

4. Подбор руководителей проектов и их обучение.

5. Подбор команд проектов по улучшению, то есть тех, кто будет делать все, что указано в первом пункте, и их обучение.

6. Широкая коммуникационная кампания, которая объясняет всем (да-да, всем, и стажерам, и клиентам, и кладовщику в том числе), что, когда и в какие сроки будет происходить.

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

Куда бежать?

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

– Лин 6 Сигма и теория ограничений занимаются улучшением существующих процессов бизнеса.

– Дизайн по Лин 6 Сигма (DfLSS) разрабатывает новые процессы для перспективных продуктов и услуг.

– Agile-разработка/доработка программного обеспечения и создание продуктов тоже требует обращаться к процессам, поскольку:

● Программа должна выполнять последовательность неких операций, то есть исполнять некий процесс.

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

● Бессмысленно автоматизировать неоптимальные процедуры, только увеличивая беспорядок в деятельности фирмы.

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

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

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

В 2023 году я проводил обучение. Аудитория как-то сразу показалась мне какой-то «уставшей», что ли. Но при этом меня удивило, что они очень быстро и качественно готовили учебные проекты. При этом часть инструментов явно была притянута за уши. Я заподозрил неладное и стал разбираться.

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

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

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

А команды так и продолжали ходить и показывать одни и те же презентации пилотных проектов на всех конференциях и тренингах.

● «Сделаем все и сразу». Здесь хотелось бы рассказать одну историю, записанную со слов ее непосредственного участника, для удобства назовем его Сергей.

В 2012 году внедрение изменений в одном крупном российском предприятии возглавил менеджер с международным опытом (Сергей собственной персоной), который более 20 лет занимался оптимизацией процессов по методологии Лин 6 Сигма по всему миру. Он должен был кардинально улучшить работу по изменениям, придав ей второе дыхание. Сергей подошел к проблеме в высшей степени профессионально, проведя за первый месяц всестороннюю диагностику, оценив как достижения, так и проблемы, после чего подготовил три плана. Каждый план делал акцент на различных процессах и требовал разных времени и ресурсов: первый предлагал сделать упор на управленческих процедурах с постепенным переходом на «бэк» как основной источник ненужной бюрократии. Второй – на пяти наиболее проблемных крупных сквозных (end-to-end)¹ процессах. Третий предлагал довести до ума то, что было сделано ранее, особенно в части IT. Каждый план был рассчитан на год, полтора и полгода соответственно. Захватив все выкладки, Сергей направился на рандеву с Главным. На встрече он емко рассказал обо всех трех планах, подчеркнув, что для каждого будут использованы разные инструменты, обрисовал результаты по каждому из них, разъяснил, как учел все ограничения по ресурсам. Главный благосклонно слушал его 15 минут, потом остановил и сказал:

– Сделайте и первое, и второе, и третье. На все даю 30 дней.

– Но это невозможно. Я сейчас объясню…

– Неинтересно. Я сказал – сделайте.

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

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

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

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

Удалось ли в итоге добиться успехов? Да. Более того, результаты в бухгалтерии были даже на определенном этапе лучше, чем в рознице. Но не знаю, справился бы я или нет без опыта во «фронте».

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

«Чебуреки, Чебоксары… Чебурашек нет» (из мультфильма «Чебурашка»)

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

1. Что такое процесс(ы).

2. Как работа компании на них делится? Из каких процессов состоит работа.

3. Какие у процессов характеристики, то есть что нужно измерять: время, количество брака и т. п.

4. Какие значения у характеристик (их еще называют метриками): сколько в часах и минутах проходит от заявки до получения продукта, как много деталей в партии бракованы и т. д.

На борьбу с подобной неграмотностью вступают «приспешники тьмы» (простите, бизнес-технологи), сторонники формального подхода к нотациям процессных моделей и архитектур.

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

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

2. Все в организации должны одинаково понимать, как исполняется тот или иной процесс. С этой целью нужно его описать, то есть представить в виде наглядной схемы с разъяснением.

Любые изменения логично начинать с вопроса: «А зачем нам это надо?»

3. Метрики должны соответствовать единым стандартам, чтобы их можно было легко считать и сравнить друг с другом.

4. Все процессы в организации следует представить в виде единой архитектурной модели, а за каждым процессом закрепить ответственных как за результат в целом, так и за каждый этап в отдельности.

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

Во-первых, беда подавляющего числа бизнес-технологов – «махровый» академизм. Они готовы месяцами спорить об определениях и названиях.

Возьмем, к примеру, первый вопрос: «Что такое процесс?» Ничего сложного в этом понятии нет. Определение давно известно: процесс – совокупность повторяющихся действий (операций), выполняемых в определенной последовательности; преобразующих ресурсы (на входе) в конечный результат (на выходе). Казалось бы, все просто. В наличии должны быть:

1. Последовательность операций, например, на конвейере.

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

3. Результат должен повторяться, то есть одни и те же действия с одними и теми же ресурсами должны давать одинаковый продукт (каждый раз машина, а не самокат/велосипед/лом).

Тем не менее споры даже по такому поводу могут не стихать месяцами. Отдельное слово в формулировке будет камнем преткновения и останавливать всю дальнейшую работу. А терминов в теории BPM (Business Process Management) о-о-очень много.

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

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

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

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

Вообще оторванность от жизни при определении процессов и их метрик – источник постоянных конфликтов между бизнесом и технологами. Иногда это принимает весьма курьезные формы.

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

Взяв на вооружение логику, мы обнаружим, что проблема не стоит и выеденного яйца. Исходя из определения процесса, масштаб роли не играет. И безусловно, процессы уровня организации состоят из процессов уровня департамента, те – из деятельности отделов, и так далее. Я уже запутал Вас окончательно? Если нет, то сейчас будет вишенка на торте. Наши бравые технологи решили назвать процессом только ту деятельность, которая начинается на уровне компании, деятельность на уровне департаментов – этапами, а отдельные действия – операциями. Дальше все они делились на разные уровни и т. д. В общем, торжество формализма. При этом технологи начали рьяно бороться со всеми, кто просто делил процессы по уровням управления компаний, что было для всех проще (первый уровень – end-to-end-процессы, седьмой – уровень отделов). Путались все. Технологи тоже. На одной отчетной встрече руководитель отдела «кулибиных» (прозвище, которое и по сей день отравляет жизнь пяти сотрудникам, ответственным за каламбур в масштабах международной компании) семнадцать (!) раз ошибся в формулировках в течение получасового доклада.

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

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

А оптимизаторы и бизнес-аналитики – за содержательное наполнение моделей, анализ и улучшение процессов.

Только так можно создать эффективно работающий процессный подход в организации.

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

Сначала целься – потом стреляй!

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

1. Главное – не что, а когда. Вам придется заниматься всеми или большинством процессов. Смиритесь с этим. Иначе не следует даже начинать изменения. Но кто говорит, что нужно делать все и сразу? Двигаться нужно постепенно, начиная с понятных и заканчивая сложными непрозрачными процессами. Запутано? Давайте разберемся. Понятные – не значит легкие или с очевидным решением. Сложный процесс обладает следующими характеристиками:

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

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

Можно выделить еще несколько характеристик, но этих двух достаточно, чтобы понять разницу между процессами разной сложности. Понятный процесс в свою очередь:

● Прозрачный. Мы знаем, кто в нем задействован и какие приблизительно задачи выполняет. Или можем это узнать в разумные сроки. Думаете, все процессы такие? Я тоже так думал, пока не погрузился в процесс оформления и выхода на работу в одной организации. Проект был не мой, я изучал документацию и опрашивал очевидцев. Сначала на встречу пришли три человека: из отдела кадров, безопасности и техподдержки, а через месяц в переговорной не было места для сотрудников одиннадцати подразделений (!), каждый из которых отвечал за свою крохотную «закорючку».

● Способный быть измеренным. Заметьте, имеется в виду не измеримый процесс (по которому мы в принципе способны собрать данные). Речь идет о том, что процесс протекает достаточно регулярно – как минимум несколько раз в неделю – в разных местах и не требует специальных допусков. В идеале, если данные по процессу можно собирать через записи и отчеты компьютера (не путать с отчетами, составленными людьми на компьютерах: в них… много творчества).

● Тестируемый. Можно протестировать изменения, внесенные в процесс, и получить обратную связь в разумные сроки.

Итак, следует начинать с понятных процессов.

2. Непосредственно выбор процесса для оптимизации основан на уравновешивании двух составляющих: Голоса Бизнеса и Голоса Клиента. Голос Клиента – все пожелания клиента, включая исследование предпочтений, жалобы, результаты фокус-групп и т. д. Для внутренних процессов используется Голос Сотрудника, то есть под клиентом понимается сотрудник, являющийся клиентом/потребителем результата, создаваемого внутри организации (например, командировки, IT поддержка и т. д.). Голос Бизнеса – пожелания руководителей или собственников бизнеса по прибыльности процесса, стоимости единицы продукции, соблюдению требований законодательства и т. д.³ Ничего не напоминает? Практически то же самое мы делали, когда определяли цель «улучшайзинга» в масштабах организации.

Нам необходимо определить критерии по каждому из Голосов и «прогнать» процессы по данным критериям. Те процессы, которые будут понятными и при этом будут проседать в части обоих Голосов, то есть по ним будет максимальное несоответствие между ожиданиями Клиентов/Бизнеса и реальностью, будут, как любят говорить оптимизаторы, находиться в «красной зоне». Как Вы уже догадались, подобные процессы – первые на очереди при оптимизации.

3. А как же быть с моделью процесса? Все просто. Вам не нужно досконально понимать, как выглядит процесс, чтобы начать с ним работать. Вам нужно только приблизительно представлять его масштаб, то есть понимать начало, конец и основные стадии⁴. В ходе оптимизации Вы будете исследовать процесс, отображать графически, измерять его и т. д. На финише проекта Вы гораздо лучше будете понимать всю суть деятельности. И вот тут и должна проявиться ценность подхода BPM.

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

● Вы определяете принципы построения модели и основные ее понятия.

● Оптимизируете/разрабатываете процесс.

● Берете схему, подготовленную в ходе проекта, со всеми метриками и примечаниями.

● Используете ее как основу для архитектуры, объединяя процессы.

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

Таким образом Вы собираете пазл, который сами же и формируете, не занимаясь теоретизированием.

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

Если Вы затрудняетесь или не хотите рисковать при выборе процесса, то хороший выход из этой ситуации – проведение экспресс-диагностики.

Это процедура, которая длится от одной до четырех недель в зависимости от масштаба компании и состоит из:

● Наблюдения и изучения ключевых процессов компании.

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

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

Правда, для этого, он должен быть достаточно компетентен.

И последнее

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