| Все о системах управления |  |
| Почитать |
| Поговорить |
| Побродить |
| Завершить |
|
|
||||
|
Необъявленная война
|
|||||
Целая волна обсуждений возникла на разных сайтах. Началом ее послужило появление в блоге Адама Дина заметки BPM and ECM – The War Begins , в которой он высказывает свое мнение о том, что ситуация, сложившаяся на рыке BPMS и ECM систем, провоцирует войну, и что в недалеком будущем произойдет их полное слияние.
Адам видит три отличия, которые, по его мнению, представляют интерес с точки зрения «захвата позиций» - это Case Management, Records and Documents Management и ECM компетенция:
- Case Management – традиционно часть ECM, поскольку ситуационное поведение в большей мере свойственно документам. Но многие BPM-вендоры уже включают Case Management в свои решения. В контексте BPM Case Management относится лишь к некоторым экземплярам процессов, поэтому Адам предлагает говорить не о ECM, а об ACM. (Правда, расшифровки он не дает. Предположу, что это Advanced Case Management.)
- Records and Documents Management – управление записями и документами –однозначно поле ECM. Но и тут BPM-вендоры либо пытаются реализовать эту функциональность внутри BPM-систем, либо интегрируют BPM-системы с системами ECM.
- Касается ECM компетенции, то, по мнению автора, всякая война имеет свои издержки. И со временем эта компетенция либо будет утеряна, либо деградирует.
Видимо тема действительно созрела, потому что обсуждение продолжилось здесь и здесь.
Основные направления дискуссии можно обозначить так:
- Что общего у ECM и BPMS и в чем принципиальная разница?
- Что лучше – «два в одном» или интеграция?
- Должен ли Case Management быть частью ECM, частью BPMS или у него своя особая роль?
- Мнения из разряда «разное».
К точкам пересечения BPMS и ECM единогласно отнесли workflow функциональность, которая присутствует в обоих случаях, но в случае ECM – это document centric workflow, а в случае BPM (по выражению одного из участников дискуссии) – integration centric workflow.
Современные BPM-системы в какой-то мере обязаны своим происхождением «document workflow», но не более того. То, что сейчас ECM вендоры притягивают BPM функциональность и наоборот – привело к тому, что существует некоторое количество ECM-систем с плохой BPM функциональностью, и некоторое количество BPM-систем со слабым ECM. Об этом пишет в своем ответе Сэнди Кимсли. BPM вендорам необходимо реализовать не просто хранение, но и поддержку версионности, разграничения доступа и т.д. А ECM вендорам придется поддерживать ad hoc процессы. И сейчас заказчиков больше волнует вопрос, смогут ли они интегрировать свои ECM системы с BPMS.
А вот темная лошадка в этом случае – это Case management, который с одной стороны фокусируется именно на контенте, но с другой – требует более продвинутую BPM функциональность.
Учитывая, что в последнее время идея обязательного присутствия Case Management в функциональности BPM-систем уже сама по себе вызвала массу горячих споров, неудивительно, что больная мозоль тут же дала о себе знать. Адам, к примеру, считает, что Case Management должен быть реализован скорее в ECM, нежели в BPM, поскольку он больше проявляется в управлении данными и документами. Хотя на деле происходит обратное, и многие BPM вендоры уже включают Case Management в состав своих предложений. Чем больше BPM и ECM стремятся реализовать схожую функциональность, тем больше уверенность автора в том, что их скорое слияние неизбежно.
Но с утверждением, что Case Management – это дело ECM, согласны не все. К примеру, один из участников обсуждения считает, что потребность в Case Management возникает в разных родах деятельности – в организациях, чья деятельность связана с большим потоком документов, в процессно-ориентированных организациях, у тех, кто активно использует CRM. В зависимости от этого и возникает потребность в подобной функциональности без привязки к тому или иному типу софта. Поэтому гораздо интереснее иметь такое решение в области Case Management, которое можно проинтегрировать с любым из перечисленных типов.
Кейт Свенсон, хотя и считает, что ACM ближе к ECM, чем к BPM (звучит как шифровкаJ), все же напоминает, что BPM – это не технология, а управленческая методология, которая может (теоретически) обходиться без специальных средств, так же, впрочем, как и ECM можно организовать при помощи книжных шкафов, а Case management – при помощи папок.
Кстати, что кому ближе – тоже вопрос. По мнению Кейта, это не ACM – часть ECM, а наоборот, ECM – это просто довольно значительный кусок ACM. Возникновение ситуации (кейса) чаще всего подтверждается документами либо другими артефактами. Но сама ситуация артефактом не является, так же, как и не является артефактом, скажем, цель. Это, скорее, проект, который во многих случаях может выполняться согласно траектории движения документов, и логично использовать для целей управления именно ECM-систему.
Что же касается автоматизированных систем, Кейт считает, что так как современные ECM системы действительно включают в себя некоторую BPM функциональность, то действительно можно использовать их и для управления процессами, хотя, по-хорошему, BPM нужно реализовывать в специально для этого предназначенной системе.
Мнения о том, нужно ли слияние BPMS и ECM, также неоднозначны. В пример приводилось то, что Appian уже несколько лет продает комплексную BPM/ECM систему. И что это замечательно, удобно, не нужно думать об интеграции, о разных API, что существенно снижает стоимость владения…
Но не все с этим согласны. Рашид Хан отвечает, что вообще не согласен с тем, что ECM и BPMS должны и будут объединяться. На пример с Appian он резонно отвечает:
- И что, Appian известен как поставщик BPM или ECM?
- Почему продукт Appian называется Appian BPM Suite, почему не BPCM Suite или как-то еще с привязкой к контенту?
- И самое главное, если заказчик будет искать чисто ECM систему, то сможет ли Appian продать им Appian BPM Suite?
К тому же, ECM и BPM – это еще не предел мечтаний, и полный список может выглядеть как … и CRM, и Business Rules, и портал, и т.д…
Обобщая, что нужно пользователю – исполнителю процесса?
- Возможность выполнять действия в рамках процесса, следуя простой и понятной логике приложения.
- Возможность доступа ко всем документам, необходимым пользователю в контексте процесса.
- Гарантированная сохранность и доставка любых данных и документов.
- Единый интерфейс.
Должен ли он задумываться о том, исполняются ли данные требования в рамках одной системы или это достигается путем интеграции различных систем? Кому нужны все эти разговоры об одной или нескольких системах?
А вы что обо всем этом думаете?
=WJ
Что мы думаем? Мы думаем, что это FAQ. Вот и на неконференции в июне это стало одной из четырех обсуждавшихся тем. Некоторую свежесть этому вопросу придал только ввод в обращение новой таблетки под названием ACM.
По существу: когда-то очень давно Вирт написал революционную книгу под названием "Алгоритмы и струкутуры данных". Почему революционную? Потому что до этого (вы будете смеяться) существовали только алгоритмы. Постепенно (даже очень постепенно) данные завоевывали себе место под солнцем: в виде секций языка COBOL, в виде специальным образом организованных файлов на мейнфрейме и т.п. Когда же наконец пришло полное понимание того, что данные - сущность, вообще говоря, независимая от алгоритмов их обработки, со своими собственными правилами организации и жизненным циклом - то одновременно появилась и потребность в специальном классе программного обеспечения под названием DBMS.
С процессами происходит ровно то же самое, только с задержкой примерно в 20 лет. Кое-кто, правда, и сейчас пытается утверждать, что процессы - это ересь, и "настоящие программы не пишут при помощи квадратиков и стрелок", но все же среди специалистов преобладающим стало мнение о том, что процессы - сущность несводимая ни к данным, ни к алгоритмам. Соответственно, возникла потребность в специальном классе программного обеспечения, которое назвали BPMS.
Аналогично, ECM предназначен для работы с неструктурированным контентом, который несводим к структурированным данным.
Из перечисленной троицы DBMS технология наиболее зрелая, поэтому никому уже не приходит в голову управляться с данными (хранить, искать, извлекать, трансформировать) "заодно". Но ведь и это было! Я помню, как отечественные производители бухгалтерских программ писали в рекламе: "Приобретая наш продукт, в дополнение к бухгалтерскому учету и отчетности вы получите базу данных, которую сможете использовать для произвольных задач."
ECM и BPMS такой зрелостью похвастаться не могут, поэтому тут пока прокатывают ублюдочные решения типа:
- все данные процесса хранятся в атрибутах (вместо DBMS)
- документы процесса храняться в папке на сервере BPMS (вместо ECM)
- поле "состояние" таблицы базы данных моделирует бизнес-процесс (вместо BPMS)
- движение документа в ECM моделирует бизнес-процесс (вместо BPMS)
Я думаю (точнее, надеюсь), все это пройдет со временем. Посмотрим на рынок DBMS: три вендора, стандартные интерфейсы - зачем что-то изобретать? Так же будет и с остальными углами треугольника: контент (с индексацией, версионностью, разграничением доступа) - это задача ECM. Но, пожалуйста, без встроенного workflow. Процессы (с графическими моделями, agile разработкой) - это BPMS. Список это можно продолжить: бизнес-правила, сервисная шина, human task management...
Но пока мы не дожили до всеобщей гармонии, будет продолжаться борьба между "best of breed" и "single vendor". Поднятая тема BPMS vs. ECM - один из фронтов этой борьбы. Вендоры пытаются осчастливить заказчиков мега-предложением "все в одном", и иногда это срабатывает.
Но чем дальше, тем реже: концепция "best of breed" выигрывает бой за неявкой противника. В самом деле, ну можно ли всерьез говорить о "single vendor" применительно к куче продуктов, последовательно приобретенных большим вендором в результате поглощений? Если продукты многократно перекрывают друг друга по функциональности (сколько у IBM BPM-продуктов?) и для их интеграции (да что интеграции - для выбора подходящего продукта) требуется неслабый консалтинг от вендора, то по сути это уже никакой не "single vendor".
Что касается ACM, то тут я бы не спешил с выводами и прогнозами. Пыль стоит столбом, ничего не разглядеть. С одной стороны, некоторые ищут в ACM очередную панацею, не выучив урок BPM. Они пытаются решать кросс-функциональные задачи с помощью однопоточного workflow, из этого ничего не получается (и не может получиться), в результате они бросают BPM и хватаются за ACM - а на самом деле они просто не умеют его (BPM) готовить! На каком-то уровне абстракции любой процесс превращается в кейс (на неконференции мы разбирали несколько примеров), и BPM тут может быть полезным.
С другой стороны, ACM сильно пересекается с project management (MS Project) и collaboration (Google Wave). На какие домены эта аморфная область в итоге поделится - будем посмотреть. А пока я лично скорее буду комбинировать, скажем, традиционную (но качественную) BPMS с тем же Google Wave, чем искать патентованное ACM-решение. Те ACM-решения, которые я видел, были просто слабыми BPMS.
А тема понемногу раскручивается :-)
Отличный обзор. Позволил себе сослаться на него в своем блоге wp.me/pRljZ-68
Если исходить из того, что процесс - это совокупность взаимосвязанных действий субъектов процесса и обсусловленных этими действиями изменений состояний объектов процесса(*), то любой процесс изначально имеет два представления: субъектно-центрированное (как последовательность действий субъектов над объектами) и объектно-центрированное (как последовательность изменений состояний объектов за счет действий субъектов).
Естественно, когда мы говорим о последовательностях, имеются ввиду наборы всех возможных последовательностей, которые описываются логически-временными схемами шаблонов бизнес-процессов.
BPM, как система управления, в качестве объекта управления имеет совокупность взаимосвязанных процессов организации. В связи с этим, она должна управлять не только последовательностями действий субъектов, но и последовательностями состояний объектов.
Однако автоматизация BPM пошла по двум разным направлениям: системы ECM сконцентрировались на объектно-центрированном представлении, а BPMS - на субъектно-центрированном. Хотя, по моему мнению, именно BPMS должны были интегрировать в себя функционал ECM.
Что касается управления слабоструктурированными процессами, то естественно эта проблема актуальна для обоих представлений процесса. Но так как автоматизация процессов изначально осуществлялась по разному в зависимости от представления, механизм управления слабоструктурированными процессами по разному был реализован в ECM и BPMS.
Насколько я понимаю, отсутствие единной системы для автоматизации BPM уже не устраивает потребителей, в связи с чем вендоры озаботились сведением двух представлений в одну систему. И тут выяснилось, что подходы к автоматизации слабоструктурированных процессов в обеих типах систем сильно отличаются.
Есть предложение: вместо придумывания новых аббревиатур, озаботиться вопросом, какой из подходов лучше и нельзя ли их скрестить. Хотя, похоже, ни тот, ни другой не решают проблему в полном объеме и придется придумывать что-то новое.
(*) В.А.Лопатин. Система управления бизнес-процессами. Управление в кредитной организации. № 6, 2008 год.
Валерий, не соглашусь с Вами.
Приведу следующий пример (без подробностей): процесс заключения некоего рамочного договора (субъекты совершают действия) При положительном результате возникает объект под названием "договор" и инициируется процесс, условно называемый "жизненный цикл договора" (ЖЦ). Этот процесс ЖЦ отслеживает состояние объекта "договор" (заключен, требует продления, продлен, расторгнут), инициируя в определенные моменты времени действия (продлить договор). Это все выполняется в BPMS, что называется "без дураков". А вот сам документ "Договор № ... от ..." - это один из атрибутов процесса, такой же, как Контрагент, Дата и проч. Только некоторые атрибуты хранятся в СУБД, а другие (как Договор) требуют более чуткого отношения к версионности, доступам и проч. Это хотя и можно реализовать при помощи "молотка и какой-то матери" в BPMS, но это кустарщина, поскольку профессионально это делает ECM-система.
И вот каждый из классов - и BPMS, и ECM - отлично справляются со своими задачами. А как раз попытки скрещивания порождают гибриды, которые не могут одинаково хорошо делать и то, и другое. Так что пока рано придумывать новое - нужно просто научиться пользоваться тем, что есть.
То есть, если потребителю нужна одна система, а не две - это проблема потребителя. И пусть смирится с тем, что BPMS профессионально делает одно (и не собирается переучиваться), а ECM - другое. Хотя и та, и другая система функционируют в рамках управления бизнес-процессами организации, то есть - в рамках BPM.
Валерий
Не одна и не две, гораздо больше: СУБД, сервер приложений, java-машина, операционная система, средства виртуализации...
Мир сложен.
Понимаю ваше раздражение, но вообще-то я говорил про потребителя, а не про системного администратора. Или вы не делаете разницы между BPMS и ECM с одной стороны и "СУБД, сервер приложений, java-машина, операционная система, средства виртуализации..." с другой?
Совершенно верно, принципиальной разницы между DBMS и BPMS я не вижу ни с точки зрения администратора, ни с точки зрения пользователя. Пользователю до лампы какие именно xMS спрятаны внутри, он не оперирует такими понятиями, как "добавить запись в таблицу БД" или "запустить бизнес-процесс".
С точки зрения аналитика и разработчика разница есть, но принципиальной я ее тоже бы не назвал.
Боюсь, что с точки зрения потребителя (или, как вы любите говорить, "бизнеса")- разница принципиальная.
Потребитель оперирует понятием "функционал". Он покупает конкретную систему класса BPMS или ЕСМ с вполне определенным функционалом. На основе какой СУБД построена система, включает ли она сервер приложений, построена ли она на JVM или Eclipse - потребителю не важно. Для него важно - может ли он решить с помощью системы свои задачи.
Еще раз: потребитель не покупает "СУБД, сервер приложений, java-машина, операционная система, средства виртуализации...", он покупает систему с конкретным функционалом. И он знает (от своего айтишника и от вендора, который сто раз повторил аббревиатуру), систему какого класса он покупает: ERP, BPMS, ECM или др.
Кроме того, потребитель думает о завтрашнем дне и ему нужна гибкая система, которая позволит ему быстро перенастраивать бизнес-процессы. Сегодня он скорее купит BPMS, а не ERP (в классическом понимании данной аббревиатуры), потому что вендоры позиционируют эту систему как более гибкую. И опять же он думает о функционале, и ничего не знает о "СУБД, сервер приложений, java-машина, операционная система, средства виртуализации...".
А еще он думает, что сегодня он не может купить одну систему с нужным функционалом, и ему придется покупать и BPMS, и ECM.
А потом ему придется постоянно скакать из BPMS в ECM и обратно. А потом у него будут проблемы со сводной отчетностью. А потом ...
И, при прочих равных условиях, ему не важно, как будет интегрирован функционал единой BPMS-ECM системы: путем создания абсолютно новой системы или путем интеграции двух имеющихся систем с помощью какой-то интеграционной платформы.
Валерий
В BPMS, как и в DBMS, и в ECM, нет прикладного функционала. (Вы ведь говорите о прикладном функционале, не о системном, я правильно понял?). Это платформы, на которых можно создать (разработать) тот или иной функционал.
В ERP/CRM, напротив, есть конкретный прикладной функционал. (Пусть и предполагающий некоторую кастомизацию, т.е. в конечном итоге ту же разработку.)
Поэтому пользователь ну никак не сможет купить "конкретную систему класса BPMS или ECM с вполне определенным функционалом". Он может купить только прикладную систему, построенную на основе BPMS/DBMS/ECM - одной из перечисленных компонент или всех вместе. (А также, к примеру, на основе ESB или MDM.)
Вы считаете иначе?
Отдельно понравилось "Сегодня он скорее купит BPMS, а не ERP". Хотелось бы, чтобы Вы были правы...
Насколько я понимаю, вендоры продвигают BPMS, которые включают некоторый набор сервисов, из которых можно конструировать бизнес-процессы. Именно этот набор сервисов, а также потенциально возможных бизнес-процессов являются для потребителя тем функционалом, о котором я говорю.
Совершенно очевидно, что функционал, который приобретает потребитель при покупке BPMS, несколько отличается от функционала ERP. Но это плата за гибкость.
А если вендор продает BPMS-пустышку, то между вендором и потребителем вклинивается посредник, который из BPMS-пустышки делает BPMS-продукт. И не важно, как этот посредник называется: компания "АБВ" или ИТ-департамент компании потребителя.
Что касается ERP, то вендоры показывают чудеса гибкости (не в пример вендорам BPMS). Взять хотя бы SAP, который уже два года назад (если верить рекламе) строился на основе SOA. Учитывая, что workflow у него был и раньше, не удивлюсь, если они интегрируют в себя и BPMS и ECM.
Валерий,
а Вам не кажется странным, что те же вендоры из "большой тройки" не разрабатывают BPM-функционал внутри себя, а покупают готовые BPM-системы, и интегрируют их со своими продуктами? (И, кстати, довольно мудро поступают.) Разница в том, что, покупая ERP и BPMS самостоятельно, вы можете выбирать и то и другое исходя из собственных потребностей/возможностей. А когда за вас это делает вендор - вы лишаетесь права выбора.
По поводу выбора между ERP и BPMS - вопрос весьма спорный. Выбрать-то он может и выберет BPMS, только в отсутствии ERP или другой учетной системы, потребитель очень быстро (как правило, еще до того, как начнет пользоваться именно BPM-функционалом) столкнется с проблемой хранения и обработки данных, и вынужден будет разрабатывать недостающую функциональность имеющимися средствами (в нашем случае - скорее всего средствами той же BPMS). В итоге - получит традиционную разработку. Это все равно, что предложить бизнес-пользователю выбирать между СУБД и сервером приложений. В условиях выбора ERP или BPMS, я бы выбрала и то, и другое.
Вот вопрос, почему потребителю не интересно, что он покупает "СУБД, сервер приложений, java-машину, операционную систему, средства виртуализации..", но при этом интересно "систему какого класса он покупает: ERP, BPMS, ECM или др."? Потому что во втором случае он эти буквы знает? По большому счету, потребителю интересна функциональность "А, Б, В...". А в какой системе она реализована - это уже вопрос техники. Потребитель (в смысле бизнес-пользователя) - это не системный архитектор, и взваливать на него проблему выбора ERP, CRM, BPMS, ECM, MDM и т.д. - не правильно.
Юлия,
На мой взгляд, покупка вендорами готовых BPMS систем - это одна из моделей бизнеса, причем, достаточно эффективная. Тем более, что имея наработки в виде ERP, им относительно легко создавать продвинутые наборы сервисов для конструирования бизнес-процессов в рамках BPMS. По мне так это интеграция прикладного функционала ERP в прикладной функционал BPMS. Но некоторым удобно рассматривать это несколько иначе, как новую продвинутую форму ERP, созданную путем интеграции системного функционала BPMS в ERP.
По-поводу выбора между ERP и BPMS - потребителю конечно выгодно покупать более гибкую систему. Но одновременно ему необходимо решать текущие задачи, причем желательно не так задорого. Вот он и маневрирует между классическими ERP, продвитутыми ERP с функциями BPMS, BPMS-пустышками (если у него есть возможность наполнить их прикладным функционалом), BPMS-продуктами (с развитым набором прикладных сервисов, в том числе, для работы с данными) и т.д.
Валерий
Никак не пойму - о каких "BPMS-продуктах" Вы говорите? Приведите пожалуйста пример.
Анатолий,
Под BPMS-продуктом я понимаю систему, с помощью которой можно:
а) выполнять текущие бизнес-процессы организации, т.е. разворачивать экземпляры бизнес-процессов по текущим шаблонам бизнес-процессов, в которых действия субъектов бизнес-процессов связаны с использованием тех или иных сервисов, являющихся неотъемлемой частью BPMS-продукта и функционирующих на принципах SOA;
б) гибко изменять бизнес-процессы организации, точнее, шаблоны бизнес-процессов, в пределах текущих возможностей BPMS-продукта, т.е. в пределах существующего набора сервисов;
в) наращивать возможности BPMS-продукта, т.е. расширять набор сервисов.
Насколько я знаю, такие системы уже функционируют у многих организаций.
Кстати, на языке BPMS-продуктов мне пришлось говорить только на этом сайте, когда вы разделили прикладной и системный функционал и высказали утверждение, что в BPMS есть только системный функционал.
И все-таки, приведите пожалуйста пример хотя бы одного BPMS-продукта, предлагаемого каким-либо вендором.
"Под BPMS-продуктом я понимаю систему, с помощью которой можно... наращивать возможности BPMS-продукта". Спасибо за разъяснение
Складывается впечатление, что "BPMS-продукт" в Вашей терминологии - это система процессного управления, которое создает у себя предприятие при помощи "BPMS-пустышки".
Предлагаемая Вами терминология, мягко говоря, небесспорна.
Обычно "продуктом" называют то, что предлагает производитель софта. А то, что при помощи софта создает предприятие собственными силами и/или с привлечением внешних консультантов, можно назвать, например "BPM-системой предприятия". К такому варианту мы с Александром Самариным пришли в результате обсуждения этих двух аспектов.
Анатолий,
По поводу того, как появляется BPMS-продукт: выше я достаточно подробно изложил свою позицию.
По поводу "спасибо": с помощью функционала системы можно наращивать возможности самой системы. Многие системы на это способны, особенно компьютерные. Так что благодарности не принимаю.
Что касается терминов: очень не хотелось бы спорить по их поводу, тем более, что это не термины, а так - попытка объяснить что-то по существу. Считайте, что попытка не удалась.
Жаль, что так и не удалось получить от Вас примера "BPMS-продукта".
Валерий,
меня тоже смутило наличие двух сущностей - BPM-пустышка и BPM-продукт. Но как раз больше заинтриговала BPM-пустышка.
Что по-вашему включает "пустышка"?
- графический редактор - да/нет?
- движок - да/нет?
- портал - да/нет?
- средства интеграции - да/нет?
- средства мониторинга (необходимый минимум) - да/нет?
А что из перечисленного включает "продукт"? И что сверх того?
На мой взгляд, это действительно важный вопрос, поскольку отсутствие четкого представления о том, что такое BPM-система, создает слишком много мути из различных трехбуквенных аббревиатур, которые многие пытаются затолкать в ту же корзинку. Типа "какая же это BPMS, если в ней нет ECM (CRM, ERP, и далее, в зависимости от насыщенности лексикона)!"
Юлия,
Сегодня читал на BPTrends отчет The state of Business Process Management 2010, где в appendix есть некоторые определения. В том числе: "BPM Suites are tools that one uses to create BPM application" и т.д. и т.п. Вспомнил про bpms.ru. Так что, ссылаясь на Хармона, могу уточнить свои ad hoc термины: BPM-пустышка = BPM Suite, а BPM-продукт = BPM Application.
Мы называем это решением или кейсом (case). Все-таки application - это приложение, а не продукт. Продукт подразумевает некую законченность, что ли. Хотя... не факт. Я поняла, что Вы имеете в виду. А как Вы это называете - это уж второе дело - лишь бы Вас понимали те, к кому это относится
На мой взгляд, слово "продукт" подразумевает тиражируемость. Поэтому BPMS Suite - типичный продукт, а BPM application - нет, ведь BPM, по определению, вещь заказная.