Оптимизатор бизнес-процессов 2.0. Лучшие инструменты повышения эффективности организаций, команд и систем - Александр Александрович Сорочан
«Чебуреки, Чебоксары… Чебурашек нет» (из мультфильма «Чебурашка»)
Проблема, описанная в предыдущем разделе, как правило, имеет под собой скрытую причину, о которой мало кто задумывается. Все сложности выбора процессов упираются в тот факт, что никто в организации не знает:
1. Что такое процесс(ы).
2. Как работа компании на них делится? Из каких процессов состоит работа.
3. Какие у процессов характеристики, то есть что нужно измерять: время, количество брака и т. п.
4. Какие значения у характеристик (их еще называют метриками): сколько в часах и минутах проходит от заявки до получения продукта, как много деталей в партии бракованы и т. д.
На борьбу с подобной неграмотностью вступают «приспешники тьмы» (простите, бизнес-технологи), сторонники формального подхода к нотациям процессных моделей и архитектур.
Только не поймите меня неправильно. Сам подход несет в себе много рациональных зерен.
1. Управление процессами возможно, только если существует их перечень и понятно, как они стыкуются друг с другом.
2. Все в организации должны одинаково понимать, как исполняется тот или иной процесс. С этой целью нужно его описать, то есть представить в виде наглядной схемы с разъяснением.
Любые изменения логично начинать с вопроса: «А зачем нам это надо?»
3. Метрики должны соответствовать единым стандартам, чтобы их можно было легко считать и сравнить друг с другом.
4. Все процессы в организации следует представить в виде единой архитектурной модели, а за каждым процессом закрепить ответственных как за результат в целом, так и за каждый этап в отдельности.
Воплощенные в жизнь эти принципы – подарок для любого «оптимизатора», поскольку ему не приходится определять границы процесса в ходе проекта на свой страх и риск. Суровая реальность, как Вы уже догадались, отличается от мечты.
Во-первых, беда подавляющего числа бизнес-технологов – «махровый» академизм. Они готовы месяцами спорить об определениях и названиях.
Возьмем, к примеру, первый вопрос: «Что такое процесс?» Ничего сложного в этом понятии нет. Определение давно известно: процесс – совокупность повторяющихся действий (операций), выполняемых в определенной последовательности; преобразующих ресурсы (на входе) в конечный результат (на выходе). Казалось бы, все просто. В наличии должны быть:
1. Последовательность операций, например, на конвейере.
2. С помощью операций ресурсы (сырье, детали, учетные данные) должны перерабатываться в нечто новое (полуфабрикат, машину, баланс).
3. Результат должен повторяться, то есть одни и те же действия с одними и теми же ресурсами должны давать одинаковый продукт (каждый раз машина, а не самокат/велосипед/лом).
Тем не менее споры даже по такому поводу могут не стихать месяцами. Отдельное слово в формулировке будет камнем преткновения и останавливать всю дальнейшую работу. А терминов в теории BPM (Business Process Management) о-о-очень много.
Следующая претензия – стремление к идеалу. К сожалению, большая часть технологов не имеет практического опыта проектной деятельности вообще и управлению изменениями в частности. Но при этом каждый из них верит, что есть «правильная модель процессов», наличие которой является решающим фактором успеха. Суть заменяется формой. Как следствие, происходит одно из двух.
1. Технологи самостоятельно разрабатывают и согласовывают модель без учета мнения остальных. В итоге получается «сферический конь в вакууме», который прекрасно смотрится на бумаге, но не соответствует действительности ни на йоту, поэтому просто пылится в архивах.
2. Технологи привлекают «бизнес» и просят «нарисовать» процессы. Но технологам категорически не нравится то, что им приносят сотрудники других подразделений, так как не отягощенные процессным знанием они делают все не так, как им говорят. В результате технологи диктуют бизнесу, что нужно исправить, либо дорабатывают схемы процессов сами. Далее ситуация развивается по первому варианту.
Самое смешное в обоих случаях заключается в том, что чаще всего процессы отображаются не так, как они происходят в жизни, а так, как написано в нормативных документах. Поверьте, это две абсолютно разные реальности.
Вообще оторванность от жизни при определении процессов и их метрик – источник постоянных конфликтов между бизнесом и технологами. Иногда это принимает весьма курьезные формы.
В одной замечательной компании была группа технологов, которые решили определить, что является процессом, а что нет. Проблема, с их точки зрения, заключалась в том, что при «улучшайзинге» в одном проекте команда оптимизировала процесс в рамках одного подразделения, в другом – в масштабах всей организации в целом. Например, если взять производство велосипедов, сборка колеса может рассматриваться как самостоятельная последовательность действий, а может как подпроцесс – часть процесса по сборке велосипеда.
Взяв на вооружение логику, мы обнаружим, что проблема не стоит и выеденного яйца. Исходя из определения процесса, масштаб роли не играет. И безусловно, процессы уровня организации состоят из процессов уровня департамента, те – из деятельности отделов, и так далее. Я уже запутал Вас окончательно? Если нет, то сейчас будет вишенка на торте. Наши бравые технологи решили назвать процессом только ту деятельность, которая начинается на уровне компании, деятельность на уровне департаментов – этапами, а отдельные действия – операциями. Дальше все они делились на разные уровни и т. д. В общем, торжество формализма. При этом технологи начали рьяно бороться со всеми, кто просто делил процессы по уровням управления компаний, что было для всех проще (первый уровень – end-to-end-процессы, седьмой – уровень отделов). Путались все. Технологи тоже. На одной отчетной встрече руководитель отдела «кулибиных» (прозвище, которое и по сей день отравляет жизнь пяти сотрудникам, ответственным за каламбур в масштабах международной компании) семнадцать (!) раз ошибся в формулировках в течение получасового доклада.
В итоге люди тратили уйму времени, ничего не меняя, не принося никакой пользы, а лишь «кошмаря бизнес».
При этом решение лежит на поверхности: технологи должны четко разделить функционал с оптимизаторами и бизнес-аналитиками. Первые отвечают за стандарт моделирования процессов, отвечают за ПО, в котором хранятся модели процессов (репозиторий), правильное использование нотаций и обучают этому остальную организацию.
А оптимизаторы и бизнес-аналитики – за содержательное наполнение моделей, анализ и улучшение процессов.
Только так можно создать эффективно работающий процессный подход в организации.
Бенчмаркинг – прекрасный способ понять перспективы отрасли, почувствовать тенденцию развития, если копнуть поглубже.
Сначала целься – потом стреляй!
Кажется, что выбор процесса – патовая ситуация: сделаешь наобум – вручишь «черную метку» всем последующим изменениям; будешь действовать по-научному – можешь так и застыть в нерешительности, а изменения никогда не начнутся. На самом деле все достаточно просто. Вот несколько основных советов по
