Наверх

Насколько BPM-решение вписывается в общую ECM-стратегию компании?

Время чтения: 8 минут
5
Насколько BPM-решение вписывается в  общую ECM-стратегию компании?

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

Билл Чеймберз,

консультант независимой консалтинговой фирмы Doculabs, специализирующейся на помощи организациям в разработке и реализации ECM-стратегий.

Многие люди все еще считают, что управление бизнес-процессами (BPM) и управление корпоративными информационными ресурсами (ECM) – две абсолютно разные технологии.

Действительно, степень зрелости этих технологий отличается. Что касается ECM-систем, то они уже настолько «созрели», что масса организаций уже давно использует ECM-технологии в качестве сетевого сервиса для многочисленных приложений. Напротив, BPM, как отдельная технология, выделилась сравнительно недавно, каких-то 3-4 года назад, и только лишь сейчас BPM-системы становятся составной частью корпоративной стратегии использования приложений для управления процессами. Другое существенное различие заключается в том, что ECM традиционно имела дело только с неструктурированными данными (т.е., графические изображения, документы Word и электронные сообщения, хранящиеся на разных ресурсах внутри организации), в то время как BPM-система была изначально предназначена для обработки структурированных данных, хранящихся в системах отслеживания операционной деятельности компании и совершенных сделок.

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

Не является секретом, что системы управления документами (предшественники современных ECM-систем) уже давно имеют в своем составе workflow и компоненты управления процессами. Ведущие производители ECM-систем, такие как IBM и FileNet, являются поставщиками workflow-технологий столько же, сколько они существуют как поставщики технологии управления контентом. Эти и другие поставщики ECM-систем не перестают расширять функциональность своих workflow-продуктов и в настоящий момент предлагают такие же полнофункциональные BPM-решения, как и множество специализированных поставщиков BPM-систем.

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

Определение требований к системе

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

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

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

Определение отдельных ECM/BPM приложений

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

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

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

Построение архитектурной схемы ECM/BPM-решения

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

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

Управление ECM/BPM

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

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

Будущее ECM и BPM-решений

Как мы видим, две тенденции в области ECM и BPM будут определять, насколько удачно BPM «впишется» в вашу ECM-стратегию как ее составная часть. Первая тенденция: BPM-функционал будет включаться крупными поставщиками комплексных решений, такие как IBM, Microsoft, BEA, EMC, Oracle и TIBCO в состав базовых компонент  предлагаемой IT-инфраструктуры (наряду с ECM, серверами, хранилищами и сетевыми сервисами).

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

Перевод компании DIRECTUM.

Источник: AIIM (BPM: How Does it Fit Into An ECM Strategy?)

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 5

Хорошая статья для специалистов. Как правильно было сказано в статье, заказчики не заморачиваются мыслями о том, каким словом из трех букв (ECM, BPM, CRM, ERP) называется система, которая решает их потребности. Зато специалисты, жонглируя этими аббревиатурами (а часто еще одним трехбуквенным словом SOA) как фокусники, могут запросто вывести формулу корпоративного счастья практически для любого заказчика.

Как раз недавно был участником разговоров, где обсуждались вопросы взаимоотношений различных корпоративных приложений. Если говорить об интеграции, то стоит, наверно, выделить интеграцию на уровне данных, на уровне интерфейсов и процессную интеграцию. Последняя как раз осуществляется с помощью BPM-приложений. Идея использования BPM-функционала ECM-системы для организации работы организации (human workflow, работа со структурированными данными, интеграция различных приложений) появилась, наверно, вместе с выделением ECM-систем в отдельный класс и уже имеет своих стойких приверженцев. Думаю, для небольшой организации, бизнес-процессы которой завязаны главным образом на документы, так оно и есть. ECM-система, как самая функциональная, или же просто единственная информационная система, является основой информационной инфраструктуры организации. Если же мы говорим о крупном промышленном предприятии, где скелетом информационной системы предприятия является  ERP-система, то там роль ECM-системы скорее сервисная. Производители промышленных систем так видят картину взаимодействия систем: EPR-приложение при помощи своего workflow вызывает отдельный сервис ECM-системы, например «согласование договора», а вся необходимая информация по тому же договору изначально вводится и хранится в ERP-системе. Само же управление бизнес-процессами может осуществляться при помощи BPM-функционала ERP-системы или, как вариант, CRM-системы. Для более тяжелых случаев (сквозные бизнес-процессы, интеграция целого «зоопарка» информационных систем, преобразование данных) придется использовать такие серьезные решения, как корпоративные сервисные шины, интеграционные брокеры, сервисы гарантированной доставки сообщений. В общем как всегда, гарантированного рецепта счастья не существует J

Многие пользователи ECM систем даже и не представляют, что могут работать в среде объектной модели, как со структурированной, так и не структурированной информацией одновременно. Так в Documentum хранище построено по семантической модели данных, есть база данных, где лежит репозитарий описания объектов. Внешняя таблица просто описывается как внешний объект и обрабатывается как объект. Вопрос в том. что многие просто не знают как работать с внешними таблицами, описанными в репозитарии. Семантическая модель в ECM  - объектно - реляционная и поддержавает все реляционные операции. Интегрируя BPM в ECM, производителм закрывают функционал WF, используя потенциал XML/XSLT, через WSDL или другие стандарты. Все стандарты ESM построены на этом. Посмотрите программы BOOST AERO в аэро космической отрасли. Кто понимает, тот увидит путь, по которму надо идти. 
Максим Галимов 15 ноября 2007
Александр, несколько слов в ответ.

Многие пользователи ECM систем даже и не представляют, что могут работать в среде объектной модели, как со структурированной, так и не структурированной информацией одновременно.

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

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

Все-таки у каждого класса систем свои задачи.

Интегрируя BPM в ECM, производителм закрывают функционал WF, используя потенциал XML/XSLT, через WSDL или другие стандарты.

Боюсь, мне не слишком понятна эта фраза. Используя XML/XSLT, WSDL, BPEL и подобные стандарты сопряжения, взаимодействия и обмена информацией, обычно открывают функционал Workflow, а не закрывают его. ))

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

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

Консерватором можно быть в любой сфере.

Ответы одоcложные, т.к. большие сервер журнала не пропускает, его сносит от переключения регистра.  Если WF дополнить фугкциями BPM, то это уже не будет WF.

Чтобы прокомментировать, или зарегистрируйтесь