Фокус на процессах

Дорогой ИТ-сервисов

Начнем с организационной стороны вопроса, вспомнив, казалось бы, далекую от интеграции тему деятельности ИТ-департамента. В третьей версии ITIL появились акценты на таких понятиях, как каталог сервисов и управление их жизненным циклом, благодаря чему сервисный подход как таковой оказался сформулирован куда более четко. Конечно, по тем или иным причинам не для всех компаний ITIL сегодня актуален, и уж тем более если речь идет о новой версии этого стандарта. Однако нельзя не признать, что в отношении подходов к ИТ-управлению на перспективу данная спецификация является законодателем мод. Далее определенный опыт экономической оценки функционирования ИТ-подразделения в различных ситуациях все более рельефно оформляется в виде лучших практик, также очень часто связанных с сервисным подходом. Речь здесь, например, может идти о так называемых разделяемых сервисах (shared services).

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

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

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

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

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

Процессный подход меняет требования

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

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

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

Еще одно следствие процессного подхода в автоматизации можно напрямую связать с применением так называемого ориентированного на события (event driven) подхода к управлению. Дело в том, что в условиях среды, меняющейся по определению более динамично, чем при автоматизации единственного предприятия, мы сталкиваемся с необходимостью «живого» обсуждения ситуации и возможности «вручную» вмешиваться в процесс.

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

Почему BPM?

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

Вместе с тем многие из отмеченных выше проблем (во многом связанные именно с процессным управлением, но не только) оставались. В этой ситуации внимание постепенно переключается на системы класса Business Process Management, о которых сейчас много говорят.

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

Здесь также уместно сказать и о классификации BPM-систем, сделанной в свое время компанией Fоrrester Research и до сих пор, пожалуй, наиболее популярной. Речь идет о так называемой интеграционно-центрической (Integration centric BPM — IC BPM), а также ориентированной на взаимодействие персонала компании (Human centric BPM — HC BPM) моделях BPM-систем. По мнению все той же Forrester, первая категория систем «растет» со стороны производителей платформ интеграции корпоративных приложений и отчасти производителей ERP-систем (см. рис.). Среди таковых выделяются гранды софтверного направления ИТ-индустрии (например, IBM, SAP, Oracle, Software AG и некоторые другие).

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

В итоге благодаря BPM к сегодняшнему дню мы имеем ситуацию, при которой:

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

Три составные части

Будем опираться опять-таки на представленную диаграмму. Она позволяет заметить, что, решая многие вопросы интеграции систем, концепция BPM развивается так, что накрывает собой сразу два направления. Они, в свою очередь, традиционно играли главенствующую роль в автоматизации бизнеса, хотя при этом существовали в значительной степени параллельно. Речь идет об управлении структурированной и неструктурированной информацией, и поэтому связка трех продуктов класса ERP, Enterprise Content Management (ECM) и Business Process Management (BPM) на сегодняшний день является, пожалуй, наиболее функционально полной, охватывая все возможные задачи современного предприятия. Подобные связки уже реализуются на практике в виде тесно увязанной технической (равно, впрочем, как и маркетинговой) политики разных поставщиков в отношении развиваемых ими систем. Например, один из самых заметных альянсов — сотрудничество SAP с компанией OpenText, где последняя выступает в качестве производителя ПО класса ECM, а SAP соответственно как компания, предоставляющая не только ERP, но и BPM-функционал посредством платформы NetWeaver. Есть также прецедент тесного сотрудничества одного из столпов BPM-рынка компании Lombardi с компаний Infor.

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