Оптимизатор бизнес-процессов 2.0. Лучшие инструменты повышения эффективности организаций, команд и систем - Александр Александрович Сорочан

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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