Получившая в последнее время довольно широкую известность концепция Business Process Management (BPM) явно предполагает под собой интеграцию. В то же время соверешенно неочевидно, о какой интеграции — содержательной или чисто информационной — в данном случае идет речь. Эти вопросы мы обсуждаем с  Владимиром Шевченко, региональным CIO швейцарского концерна ABB.

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

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

Отклик в пространстве практических внедрений у нас соответствующий. Я сам, когда работал в другой компании, наблюдал почти модельную ситуацию с развитием BPM-проекта, формально направленного на систематизацию работ по управлению подписанием контрактов. Заказчик имел вполне приличный бюджет, обладал свободой выбора в том, как его потратить, располагал грамотной ИТ-командой, и к тому же у него было время на реализацию проекта. Иными словами, можно было очень подробно разобраться с процессами, а после этого еще и заняться автоматизацией. При этом нельзя сказать, что всё было сделано абсолютно неправильно. С процессами вроде разбирались, но не до нужной глубины. Автоматизацию делали на основе SharePoint и в общем вполне грамотно. Она действительно дала эффект, но очень незначительный и совсем не тот, на который рассчитывали. И все эти, если угодно, хорошо начатые, но незаконченные ходы привели к закономерному результату. То, что было сделано, на практике не использовалось, и об этом постепенно забыли.

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

Однако представляется, что один важный нюанс применения BPM как раз состоит в том, что на основе соответствующего внедрения (имея в виду и ИТ-систему) можно увидеть имеющиеся неоптимальности и до­стигнуть той самой оптимизации процессов по существу…

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

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

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

А что все-таки вы могли бы сказать по сути автоматизации в контексте развития концепции BPM?

В этой сфере у BPM, если сравнить ее, скажем, с той же ERP, с которой я уже проводил параллели, есть, как мне думается, характерные особенности. Если с ERP-концепцией можно довольно однозначно сопоставить ИТ-инструментарий вполне определенной функциональной направленности, то в области BPM не так все очевидно. Да, существуют BPMS-системы, но автоматизацию вполне можно, а часто и целесообразно вести другими, более простыми сред­ствами. Я уже упоминал одно из них — весьма популярную в корпоративной автоматизации систему SharePoint. Точно так же вполне можно говорить об  уже очень давно существующем классе систем workflow, позволяющих решить многие задачи контроля и оптимизации бизнес-процессов, в том числе сложных. Все это лично мне приходилось применять на практике.

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

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

В этом смысле, как ни странно может показаться, я бы сравнил профессиональные системы BPMS с такими же профессиональными продуктами класса АСУТП. В данной области реальная трансформация процессов и их ИТ-поддержка на основе модификации графических моделей является сейчас обычной практикой. Однако всем ясно и то, что процесс цехового уровня в принципе отлажен и понятен технологам того или иного производства, как правило, в мельчайших деталях.

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

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

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

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

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

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

Я не совсем с этим согласен. Наверное, если при внедрении BPM сразу ставить масштабные цели, то сразу можно оправдать применение дорогих специализированных инструментов класса BPMS. И отчасти точка зрения о якобы необходимой нижней планке масштаба BPM-внедрения складывается как раз вследствие того, о чем я говорил выше. BPMS пытаются про­двигать сейчас довольно активно, и для того чтобы решать эту задачу, надо приводить в пример сложные сценарии их применения. А в реальной практике большинство ситуаций как раз довольно просты, да и зрелость бизнес-процессов, необ­ходимая для крупного развертывания технологий автоматизации, мало у кого достигнута.

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

Насколько важна в случае автоматизации сквозных процессов интеграция данных, или, иными словами, сущест­вование единого непротиворечивого информационного ресурса компании?

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

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

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