Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


Вход в систему

Забыли пароль?


     
Необъявленная война

Целая волна обсуждений возникла на разных сайтах. Началом ее послужило появление в блоге Адама Дина заметки 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 компетенции, то, по мнению автора, всякая война имеет свои издержки. И со временем эта компетенция либо будет утеряна, либо деградирует.

Видимо тема действительно созрела, потому что обсуждение продолжилось здесь и здесь.

Основные направления дискуссии можно обозначить так:

  1. Что общего у ECM и BPMS и в чем принципиальная разница?
  2. Что лучше – «два в одном» или интеграция?
  3. Должен ли Case Management быть частью ECM, частью BPMS или у него своя особая роль?
  4. Мнения из разряда «разное».

К точкам пересечения 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 он резонно отвечает:

  1.  И что, Appian известен как поставщик BPM или ECM?
  2. Почему продукт Appian называется Appian BPM Suite, почему не BPCM Suite или как-то еще с привязкой к контенту?
  3. И самое главное, если заказчик будет искать чисто ECM систему, то сможет ли Appian продать им Appian BPM Suite?

К тому же, ECM и BPM – это еще не предел мечтаний, и полный список может выглядеть как … и CRM, и Business Rules, и портал, и т.д…

Обобщая, что нужно пользователю – исполнителю процесса?

  • Возможность выполнять действия в рамках процесса, следуя простой и понятной логике приложения.
  • Возможность доступа ко всем документам, необходимым пользователю в контексте процесса.
  • Гарантированная сохранность и доставка любых данных и документов.
  • Единый интерфейс.

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

А вы что обо всем этом думаете?

=WJ

Комментарии
#1 Анатолий Белайчук, 14.07.2010 14:50

Что мы думаем? Мы думаем, что это 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.

#2 Максим Смирнов, 14.07.2010 18:36

А тема понемногу раскручивается :-)
Отличный обзор. Позволил себе сослаться на него в своем блоге wp.me/pRljZ-68

#3 Валерий Лопатин, 16.07.2010 12:00

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

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

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

Однако автоматизация BPM пошла по двум разным направлениям: системы ECM сконцентрировались на объектно-центрированном представлении, а BPMS - на субъектно-центрированном. Хотя, по моему мнению, именно BPMS должны были интегрировать в себя функционал ECM.

Что касается управления слабоструктурированными процессами, то естественно эта проблема актуальна для обоих представлений процесса. Но так как автоматизация процессов изначально осуществлялась по разному в зависимости от представления, механизм управления слабоструктурированными процессами по разному был реализован в ECM и BPMS.

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

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


(*) В.А.Лопатин. Система управления бизнес-процессами. Управление в кредитной организации. № 6, 2008 год.

#4 Юлия Вагнер, 16.07.2010 17:43

Валерий, не соглашусь с Вами.
Приведу следующий пример (без подробностей): процесс заключения некоего рамочного договора (субъекты совершают действия) При положительном результате возникает объект под названием "договор" и инициируется процесс, условно называемый "жизненный цикл договора" (ЖЦ). Этот процесс ЖЦ отслеживает состояние объекта "договор" (заключен, требует продления, продлен, расторгнут), инициируя в определенные моменты времени действия (продлить договор). Это все выполняется в BPMS, что называется "без дураков". А вот сам документ "Договор № ... от ..." - это один из атрибутов процесса, такой же, как Контрагент, Дата и проч. Только некоторые атрибуты хранятся в СУБД, а другие (как Договор) требуют более чуткого отношения к версионности, доступам и проч. Это хотя и можно реализовать при помощи "молотка и какой-то матери" в BPMS, но это кустарщина, поскольку профессионально это делает ECM-система.
И вот каждый из классов - и BPMS, и ECM - отлично справляются со своими задачами. А как раз попытки скрещивания порождают гибриды, которые не могут одинаково хорошо делать и то, и другое. Так что пока рано придумывать новое - нужно просто научиться пользоваться тем, что есть.

#5 Валерий Лопатин, 16.07.2010 20:11

То есть, если потребителю нужна одна система, а не две - это проблема потребителя. И пусть смирится с тем, что BPMS профессионально делает одно (и не собирается переучиваться), а ECM - другое. Хотя и та, и другая система функционируют в рамках управления бизнес-процессами организации, то есть - в рамках BPM.

#6 Анатолий Белайчук, 17.07.2010 02:12

Валерий

Не одна и не две, гораздо больше: СУБД, сервер приложений, java-машина, операционная система, средства виртуализации...

Мир сложен.

#7 Валерий Лопатин, 17.07.2010 12:10

Понимаю ваше раздражение, но вообще-то я говорил про потребителя, а не про системного администратора. Или вы не делаете разницы между BPMS и ECM с одной стороны и "СУБД, сервер приложений, java-машина, операционная система, средства виртуализации..." с другой?

#8 Анатолий Белайчук, 17.07.2010 13:38

Совершенно верно, принципиальной разницы между DBMS и BPMS я не вижу ни с точки зрения администратора, ни с точки зрения пользователя. Пользователю до лампы какие именно xMS спрятаны внутри, он не оперирует такими понятиями, как "добавить запись в таблицу БД" или "запустить бизнес-процесс".

С точки зрения аналитика и разработчика разница есть, но принципиальной я ее тоже бы не назвал.

#9 Валерий Лопатин, 18.07.2010 13:59

Боюсь, что с точки зрения потребителя (или, как вы любите говорить, "бизнеса")- разница принципиальная.

Потребитель оперирует понятием "функционал". Он покупает конкретную систему класса BPMS или ЕСМ с вполне определенным функционалом. На основе какой СУБД построена система, включает ли она сервер приложений, построена ли она на JVM или Eclipse - потребителю не важно. Для него важно - может ли он решить с помощью системы свои задачи.

Еще раз: потребитель не покупает "СУБД, сервер приложений, java-машина, операционная система, средства виртуализации...", он покупает систему с конкретным функционалом. И он знает (от своего айтишника и от вендора, который сто раз повторил аббревиатуру), систему какого класса он покупает: ERP, BPMS, ECM или др.

Кроме того, потребитель думает о завтрашнем дне и ему нужна гибкая система, которая позволит ему быстро перенастраивать бизнес-процессы. Сегодня он скорее купит BPMS, а не ERP (в классическом понимании данной аббревиатуры), потому что вендоры позиционируют эту систему как более гибкую. И опять же он думает о функционале, и ничего не знает о "СУБД, сервер приложений, java-машина, операционная система, средства виртуализации...".

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

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

#10 Анатолий Белайчук, 18.07.2010 16:31

Валерий

В BPMS, как и в DBMS, и в ECM, нет прикладного функционала. (Вы ведь говорите о прикладном функционале, не о системном, я правильно понял?). Это платформы, на которых можно создать (разработать) тот или иной функционал.

В ERP/CRM, напротив, есть конкретный прикладной функционал. (Пусть и предполагающий некоторую кастомизацию, т.е. в конечном итоге ту же разработку.)

Поэтому пользователь ну никак не сможет купить "конкретную систему класса BPMS или ECM с вполне определенным функционалом". Он может купить только прикладную систему, построенную на основе BPMS/DBMS/ECM - одной из перечисленных компонент или всех вместе. (А также, к примеру, на основе ESB или MDM.)

Вы считаете иначе?

Отдельно понравилось "Сегодня он скорее купит BPMS, а не ERP". Хотелось бы, чтобы Вы были правы...

#11 Валерий Лопатин, 18.07.2010 19:19

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

Совершенно очевидно, что функционал, который приобретает потребитель при покупке BPMS, несколько отличается от функционала ERP. Но это плата за гибкость.

А если вендор продает BPMS-пустышку, то между вендором и потребителем вклинивается посредник, который из BPMS-пустышки делает BPMS-продукт. И не важно, как этот посредник называется: компания "АБВ" или ИТ-департамент компании потребителя.

Что касается ERP, то вендоры показывают чудеса гибкости (не в пример вендорам BPMS). Взять хотя бы SAP, который уже два года назад (если верить рекламе) строился на основе SOA. Учитывая, что workflow у него был и раньше, не удивлюсь, если они интегрируют в себя и BPMS и ECM.

#12 Юлия Вагнер, 19.07.2010 13:13

Валерий,
а Вам не кажется странным, что те же вендоры из "большой тройки" не разрабатывают BPM-функционал внутри себя, а покупают готовые BPM-системы, и интегрируют их со своими продуктами? (И, кстати, довольно мудро поступают.) Разница в том, что, покупая ERP и BPMS самостоятельно, вы можете выбирать и то и другое исходя из собственных потребностей/возможностей. А когда за вас это делает вендор - вы лишаетесь права выбора.
По поводу выбора между ERP и BPMS - вопрос весьма спорный. Выбрать-то он может и выберет BPMS, только в отсутствии ERP или другой учетной системы, потребитель очень быстро (как правило, еще до того, как начнет пользоваться именно BPM-функционалом) столкнется с проблемой хранения и обработки данных, и вынужден будет разрабатывать недостающую функциональность имеющимися средствами (в нашем случае - скорее всего средствами той же BPMS). В итоге - получит традиционную разработку. Это все равно, что предложить бизнес-пользователю выбирать между СУБД и сервером приложений. В условиях выбора ERP или BPMS, я бы выбрала и то, и другое.
Вот вопрос, почему потребителю не интересно, что он покупает "СУБД, сервер приложений, java-машину, операционную систему, средства виртуализации..", но при этом интересно "систему какого класса он покупает: ERP, BPMS, ECM или др."? Потому что во втором случае он эти буквы знает? По большому счету, потребителю интересна функциональность "А, Б, В...". А в какой системе она реализована - это уже вопрос техники. Потребитель (в смысле бизнес-пользователя) - это не системный архитектор, и взваливать на него проблему выбора ERP, CRM, BPMS, ECM, MDM и т.д. - не правильно.

#13 Валерий Лопатин, 24.07.2010 13:15

Юлия,

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

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

#14 Анатолий Белайчук, 25.07.2010 09:38

Валерий

Никак не пойму - о каких "BPMS-продуктах" Вы говорите? Приведите пожалуйста пример.

#15 Валерий Лопатин, 25.07.2010 12:21

Анатолий,

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

Насколько я знаю, такие системы уже функционируют у многих организаций.

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

#16 Анатолий Белайчук, 26.07.2010 16:03

И все-таки, приведите пожалуйста пример хотя бы одного BPMS-продукта, предлагаемого каким-либо вендором.

"Под BPMS-продуктом я понимаю систему, с помощью которой можно... наращивать возможности BPMS-продукта". Спасибо за разъяснение smile

Складывается впечатление, что "BPMS-продукт" в Вашей терминологии - это система процессного управления, которое создает у себя предприятие при помощи "BPMS-пустышки".

Предлагаемая Вами терминология, мягко говоря, небесспорна.

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

#17 Валерий Лопатин, 27.07.2010 00:13

Анатолий,

По поводу того, как появляется BPMS-продукт: выше я достаточно подробно изложил свою позицию.

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

Что касается терминов: очень не хотелось бы спорить по их поводу, тем более, что это не термины, а так - попытка объяснить что-то по существу. Считайте, что попытка не удалась.

#18 Анатолий Белайчук, 27.07.2010 00:44

Жаль, что так и не удалось получить от Вас примера "BPMS-продукта".

#19 Юлия Вагнер, 27.07.2010 12:13

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

А что из перечисленного включает "продукт"? И что сверх того?

На мой взгляд, это действительно важный вопрос, поскольку отсутствие четкого представления о том, что такое BPM-система, создает слишком много мути из различных трехбуквенных аббревиатур, которые многие пытаются затолкать в ту же корзинку. Типа "какая же это BPMS, если в ней нет ECM (CRM, ERP, и далее, в зависимости от насыщенности лексикона)!"

#20 Валерий Лопатин, 30.08.2010 19:25

Юлия,
Сегодня читал на 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.

#21 Юлия Вагнер, 31.08.2010 13:32

Мы называем это решением или кейсом (case). Все-таки application - это приложение, а не продукт. Продукт подразумевает некую законченность, что ли. Хотя... не факт. Я поняла, что Вы имеете в виду. А как Вы это называете - это уж второе дело - лишь бы Вас понимали те, к кому это относитсяsmile

#22 Анатолий Белайчук, 31.08.2010 14:53

На мой взгляд, слово "продукт" подразумевает тиражируемость. Поэтому BPMS Suite - типичный продукт, а BPM application - нет, ведь BPM, по определению, вещь заказная.

Для того чтобы добавить комментарий, вам нужно войти в систему или зарегистрироваться

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | Версия для печати