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