BPM без бизнеса

Управленческая дисциплина Business Process Management изначально подразумевала под собой основу в виде методологии управления, однако постепенно этот термин стал использоваться шире, охватив технологическую область, что снизило интерес к нему со стороны бизнеса. В результате, появившийся было у бизнеса шанс получить источник повышения конкурентного преимущества, подкрепленный современными средствами автоматизации, грозит превратиться в призрака с приклеившимся ярлыком «серебряная пуля», а передовое ПО, которое вполне может претендовать на звание революционного, - в очередного «питомца» в ИТ зоопарке.

В начале 90-х годов идея, что любой деятельностью эффективней управлять, если управлять ею как процессом, легко проникла в сознание бизнес-сообщества и, действительно, бизнес всегда мыслил категориями процессов, а термин «управление бизнес-процессами» только оформил де-юре сложившееся де-факто представление. Однако для претворения идеи в жизнь необходима была методическая основа, которая и появилась в виде концепции реинжиниринга бизнес-процессов. Руководствуясь лозунгом Майкла Хаммера: «Реинжиниринг: не автоматизируйте, уничтожайте!», энтузиасты ринулись на функциональную пирамиду, с твердым намерением уличить подход «as-is» в недостатках, раскрыть глаза на открывающиеся в связи с грядущими переменами возможности подхода «to-be» и построить настоящий процессный рай. На практике оказалось, что as-is, как таковой, мало кого интересует, а описание to-be – это не болоее чем увлекательный процесс погони за собственным хвостом: пока одно описали, другое изменилось, и так до бесконечности. В результате, до процессного рая попросту не доходили руки.

Осознав бесперспективность такой работы, тот же Хаммер пересмотрел свои идеи и предложил менее радикальный, но более действенный способ перехода к процессному управлению, положив в его основу идею постоянного усовершенствования. Этот подход и был назван Business Process Management. Волна BPM могла бы не стать такой мощной, если бы не совпала с появлением нового класса программного обеспечения – BPMS (Business Process Management Suite), превращающего схемы процессов в исполняемый код. Именно это позволило не только изложить, но и реализовать идею постоянного усовершенствования -- процессы компании описываются и автоматизируются в системе BPMS в том виде, в котором они реализованы в жизни, а после этого, основываясь на результатах анализа статистики поведения процессов, процессы постепенно совершенствуются.

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

Уровень процессной зрелости определяется многими факторами. Наиболее распространенной шкалой зрелости принято считать шестиуровневую модель зрелости Gartner BPM Maturity Model, однако, для условий России, зрелость предприятий которой невысока, по мнению Анатолия Белайчука, достаточно использовать адаптированный трехуровневый вариант: уровень 1 — это описание и моделирование процессов, уровень 2 — управление отдельными бизнес-процессами и уровень 3 — управление сетью сквозных бизнес-процессов. Нулевой уровень — отсутствие процессности — можно считать точкой начала координат (см. рисунок). Большинство российских компаний сегодня находятся на первом или, в лучшем случае, в начале второго уровня.

Рисунок. Модель зрелости BPM

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

Увлечение автоматизацией не позволяет организации подняться выше второго уровня зрелости.

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

Полноценный второй уровень зрелости – это, на сегодняшний день, результат, добиться которого удалось пока немногим компаний. Большинство предприятий, которые «приняли курс на BPM», находятся на стадии автоматизации единичных процессов, и для них сейчас актуальны проблемы больше технологического, нежели методологического характера. Однако успехи в автоматизации бизнес-процессов создают ощущение легкой победы, когда повышение производительности на рабочих местах (особенно там, где раньше все работы выполнялись вручную) приводит к повышению производительности всей цепочки и дает основание полагать, что BPM «работает». Но является ли наличие системы BPMS залогом успешного BPM? 

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

Первоначально появление систем BPMS было воспринято как реальный шанс сократить разрыв между бизнесом и ИТ – в BPMS графическое представление схем процессов без программирования переводится в код. Если придерживаться положения, что моделирование процессов – это прерогатива бизнеса, то можно сказать, что BPMS является переводчиком с языка бизнеса на язык ИТ. Отсутствие необходимости написания программного кода на этапе прототипирования не только существенно сокращает время создания работоспособного процесса, но и позволяет вносить изменения в уже существующие процессы без ущерба производительности. Таким образом реализуется еще одно требование современного менеджмента – разработка в условиях меняющихся требований. Реальная возможность в короткие сроки внедрять и изменять процессы делает системы BPMS интересными для бизнеса.

Для ИТ BPMS интересны, в первую очередь, благодаря их интеграционным возможностям. Эти системы легко вписываются в ИТ архитектуру организации, позволяя использовать наследуемые приложения и корпоративные системы в едином процессном пространстве. Но и сам принцип построения BPMS, основанный на совместном использовании модели для аналитической работы и разработки пользовательских приложений, не может не вызывать интереса ИТ. Наличие работающего прототипа – это, по сути, ТЗ, написанное в терминах машинного кода. Отсутствие необходимости домысливать содержательную часть процесса, разбираться в тонкостях бизнес-логики и заботиться о полноте передаваемой информации позволяет сосредоточиться исключительно на оптимизации пользовательских интерфейсов, интеграции с внешними приложениями – словом, на задачах, которые целиком находятся в области компетенции ИТ. При этом вся разработка ведется в фоновом режиме, в то время как процесс уже находится в эксплуатации.

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

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

Внедрение системы BPMS – это проект, но проект с другими целями. Результат оценивается по таким показателям как надежность, скорость, устойчивость. Не являясь напрямую бизнес-целями, эти цели не становятся, тем не менее, менее значимыми (также как не становится менее значимой цель бухгалтера вовремя сдать квартальную отчетность). Но для того, чтобы понять разницу между двумя проектами – BPM и внедрение BPMS – достаточно признать, что эти цели разные.

В числе целей автоматизации может (и, вероятнее всего, будет) присутствовать такая цель, как повышение производительности процесса. Добиться этого можно путем создания эргономичных пользовательских интерфейсов, за счет интеграции нескольких систем или источников данных, за счет ускорения передачи заданий, документов и т.д. В том числе и за счет покупки нового сервера или другого оборудования. Но можно ли утверждать, что покупка нового сервера стала интеллектуальным прорывом, который позволил выделиться на фоне конкурентов или выйти на рынок с новым предложением? Или покупка нового программного обеспечения была основной целью управления? Уделяя пристальное внимание автоматизации вообще не стоит, тем не менее, отдавать проект BPM целиком в руки ИТ.

Для многих это очевидно, но, несмотря на это управление процессами постепенно переползает в ИТ-департаменты. Наиболее распространенные сценарии могут выглядеть следующим образом:

1. Методология может получить техническое поражение еще до начала проекта. Потенциально у BPM есть две точки входа в организацию – «от бизнеса» и «от ИТ». В случае, когда точкой входа является ИТ, посылом изначально является BPMS, и проект, если он состоится, будет нацелен на автоматизацию, а не бизнес-цели.

2. Сползание в технологическую плоскость может начаться тогда, когда организация достигает уровня 2, на котором автоматизация процессов становится необходимостью. В этот момент встает вопрос выбора программного обеспечения, что является областью компетенции ИТ. Понятно, что при выборе ПО организация стремится получить как можно большую функциональность, и задача ИТ на этом этапе – продемонстрировать бизнесу все потенциальные возможности BPMS. Но на сегодняшний день уровень развития систем BPMS настолько высок, что у не специалистов в области ИТ, возникает ощущение, что работать с подобными системами могут только специалисты ИТ. Возникает противоречие: потенциальный бизнес-пользователь поручает ИТ-специалистам найти систему с максимально возможным набором возможностей и, в итоге, выбирает танк там, где хватило бы обычного внедорожника, после чего приходит к выводу, что управлять этим танком может только специально обученный человек (ИТ-специалист). Иными словами, системы BPMS давят бизнес своим функционалом. Бизнес делегирует право на свою часть работы, а вместе с ней и управление процессами в отдел ИТ.

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

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

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

Авторский вариант статьи, опубликованной в журнале "Открытые системы" - №2, 2012 г.
Адрес размещения на www.osp.ru

Источник: ФИНЭКСПЕРТ (Finexpert)