9.1.1. Экономическое обоснование для движения к процессно-ориентированной модели

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

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

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

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

Хотя на первый взгляд такая работа потребует больших усилий, с ней можно справиться, если прибегнуть к помощи BPMS (см. главу 10 «Технологии BPM»). К тому же, чтобы начать следовать процессному подходу, менеджеру проекта и проектной команде нет необходимости идентифицировать и подробно описывать все процессы компании. Идя от конца к началу, отталкиваясь от поставки продукции и услуг, можно быстро описать процессы верхнего уровня и их взаимодействие друг с другом. Но надо отказаться от привычного образа мыслей и от стремления к совершенству и к стопроцентной правоте во всем, что вы делаете.

Суть BPM заключается в итерационной и эволюционной оптимизации. Подход BPM не в том, чтобы потратить много времени на анализ и перепроектирование, стремясь сразу охватить все 100 %. Он предполагает, что вы быстро выполняете первое приближение к истине, затем обнаруживаете в процессе ошибки и разрывы и начинаете новую итерацию. При таком подходе процесс постоянно эволюционирует, изменения проходят быстро и серьезные проблемы исправляются в первую очередь. В результате график отдачи во времени сдвигается влево – самый большой эффект достигается уже на ранних этапах проекта.

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

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

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

Проверка выявит возможные нарушения в работе вниз по потоку и дополнительные требования к подразделениям выше по потоку работ. Эта дополнительная информация расширит кругозор команды и позволит избежать решений, которые навредят другим подразделениям или приведут к серьезным перебоям в работе.

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

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