Перед отпуском я написал несколько сообщений об управлении основными данными (master data management). И даже попытался в сообщении Master Data Management, EDA, ESB, SOA: собираем все вместе связать MDM с архитектурой предприятия и интеграцией приложений. Но, безусловно, тема намного глубже и требует еще множество дополнительных комментариев. Сегодняшний комментарий о связи MDM и BPM.
Во-первых, BPM – это своего рода «пятый элемент» MDM, о котором мало кто вспоминает. К основным данным обычно относят клиентов, сотрудников, продукты и активы. При этом, процессы продажи и предоставления клиентам продуктов силами сотрудников к активам, чаще всего, не относятся. Наверное, такое невнимание к процессам и привело к появлению отдельной дисциплины BPM, а так же дисциплины архитектура предприятия (enterprise architecture). Справедливости ради, надо сказать, что еще один вид основных данных – географические координаты и адреса, приобретает все большую значимость, но об этом я напишу отдельно.
Во-вторых, без основных данных BPM «повисает»… даже не в воздухе, а правильнее сказать в безвоздушном пространстве. В BPMN данные присутствуют настолько неявно, что в BPMS работа с данными становиться чуть ли не главной проблемой. Взять хотя бы задачу назначения задач на сотрудников для более-менее распределенной компании с более-менее сложной продуктовой линейкой.
И наконец, для большинства компаний значительная часть бизнес-процессов заключается в создание и сопровождение основных данных. Такие процессы надо сразу выделять в отдельные категории и связывать с предметными областями. Четыре + одно существительное: клиенты, продукты, активы, сотрудники и процессы – описывают большую часть того, чем занимается современная организация.
Почему BPM так плохо работает с данными?
Ведь, как вы справедливо заметили, часто данные меняются только в рамках процесса, а всеми остальными системами только читаются?
Т.е. запись данных идет только от BPMS.
Зачем нужна прокладка между BPMS и базой данных в виде некой учетной системы?
Михаил, я думаю это очень правильный вопрос. Я с удовольствием бы выслушать ответ на него от гуру BPM. У меня есть собственное суждение на эту тему, но боюсь, что оно носит слишком абстрактный характер. Не стоит винить разработчиков BPM. Они делают то, чему их учили. А учили их структурному программированию Дейкстры, принципу separation of concerns, т.е. разделению ПО на минимально-пересекающиеся по функционалу модули, вот они и родили “абстрагированные” от предметной области инструменты.
Такие слова, как ООП, рефакторинг, итерации не попадают в фокус внимания концепции BPM. Кстати, меня всегда удивляло то, что айтишники, повсеместно отрицая водопадную модель разработки ПО, продолжают верить в возможность описания бизнес-процессов в BPMN =)
Я общался с специалистами Pega Systems. Почему-то для одних процессов учетная система не нужна, для других – нужна.
Я попробовал понять в чем разница. Если данные используются в одном процессе (т.е. экземпляр данных полностью формируется в одной описанной цепочке действий и дальше не меняется) – то все ок, если данные могут меняться многими процессами – то все сложно.
Ситуация не слишком оптимистичная.
Полностью согласен с тем, что ситуация не слишком оптимистичная. Примеры, когда процесс работает с одним объектом, какого-либо одного класса, довольно, редки. Я уже приводил проблему назначения задач на людей. В самом простом случае нам надо учитывать навыки и региональную орг.структуру… лучше, когда можно распределять одних и тех же клиентов к конкретным менеджерам. Еще лучше, когда мы учитываем текущую нагрузку работника. Аналогичная ситуация со всеми исчерпываемыми активами (нет в гараже свободного седана – посылаем минивэн…). И такая ситуация во всех реальных задачах.
Боюсь, в моем блоге ответов на эти вопросы мы не найдем. Надо где-нибудь на LinkedIn-е поспрашивать
Зачем в LinkedIn-е? Поспрашиваем вживую…
Если что-то нарою – напишу.
У меня данный вопрос стоит исключительно в практической плоскости…
> айтишники, повсеместно отрицая водопадную модель разработки ПО, продолжают верить в возможность описания бизнес-процессов в BPMN
Не понял, какая связь?
> Такие слова, как ООП, рефакторинг, итерации не попадают в фокус внимания концепции BPM
Тоже непонятно откуда такое наблюдение. Известные мне специалисты по BPM скажут if it’s not agile it ain’t BPM!
Так что с концепцией все в порядке. С трактовкой ее продавцами из российских офисов крупных софтверных вендоров могут быть проблемы 😉
> Зачем нужна прокладка между BPMS и базой данных в виде некой учетной системы?
По чисто экономическим соображениям: учетная система – это коробочный продукт, а бизнес-процесс в BPMS – это заказная разработка.
Вы путаете мелкое с мягким. А именно описание процесса в некой системе и саму систему.
А так, и BPMS и учетная система может быть как коробочным продуктом, так и заказной разработкой (так же как и любое другое ПО)
Учетная система – это прикладное ПО. BPMS – это инфраструктурное ПО, аналогично DBMS. Первая содержит функциональность для конечного пользователя, второе – функциональность для разработчика, и требует заказной разработки, чтобы появился пользовательский функционал.
Насколько я понял BPMS содержит две части – моделирование и исполнение (имплементацию). Средства моделирования содержит функционал для аналитика, средства исполнения – для пользователя. Да, движок исполнения может иметь интерфейсы к другим системам, и, в этом смысле, содержит функционал для разработчика.
Хотя, если я правильно понял, во многих системах код генерится автоматически, и в этом есть отличительная особенность BPM 2.0 – http://bpms.ru/library/reviews/03/make-way-for-bpm-20-bruce-silver/index.html
Таким образом я бы не стал со 100% уверенностью утверждать, что BPMS – это только инфраструктурное ПО.
Михаил, если bpms.ru для Вас авторитетный источник, то поверьте мне как редактору этого портала – дело обстоит так, как я написал выше.
Хорошо. Пусть будет как вы говорите.
Но вся моя интуиция протестует против этой “учетной системы” – она явно лишняя в этой картинке.
Я понимаю, что аргумент слабый, интуиция – это только интуиция, но…
Ваша интуиция подсказывает то же, что и многим другим неофитам: “а давайте выбросим все унаследованные системы и сделаем все в BPMS, так правильнее!”. Но идея BPM (и SOA) – не переписывать все в -надцатый раз, а более эффективно распорядиться тем что у нас уже есть. Кто-нибудь когда-нибудь в конце концов перепишет эти системы, опираясь на платформу BPMS (и кое-что уже делается в этом направлении), но это занятие отдельное и небыстрое.
Про неофитов мы опустим, а вот про переписывать – это интересно.
Представьте, что переписывать нечего. Учетной системы нет. Перед вам выбор – покупать 2 системы или делать на базе BPMS? Тогда каким будет ваше решение?
Как мне кажется, надо для начала отделить “данные” (data) от “мастер-данных” (master data). Мне кажется, что Вы, Максим, в этой записи говорите об обычных данных. Собственно, и дискуссия под записью крутится именно в области того, “как нам правильно прицепить данные к процессам”.
В идеале, логика работы с данными (права доступа и отсылка собственно на местер-данные) должна управляться независимо от процесса. Это касается только данных, жизненный цикл которых не совпадает с временем жизни процесса. И эта логика не является зоной ответственности BPMS, хотя иногда и приходится за нее браться в проектах. Не имея четких методоллогических критериев – где заканчивается BPMS и начинается сугубо учетный функционал, скажу, что, когда я вижу задание на систему, более чем на 30% (плюс-минус) состоящее из требований к составу и механизмам работы именно с данными, я начинаю испытывать сомнения в том, что это задание может быть реализовано исключительно силами BPMS-системы и ее гениальных внедренцев.
Согласен. Точнее, может-то оно может, вопрос – какой ценой, и не превратится ли в результате BPM-проект в разработку очередной самопальной учетной системы.
Ну, сейчас при большом желании и неограниченных ресурсах можно на базе любой промышленной КИС сваять любой функционал. Можно вообще все на Vba написать из-под Офиса:) Целесообразность – это та линия, которая отделяет слово “делать” от слова “не делать”.
Мастер- же -данные – это вообще отдельная история. Это я вам как представитель вендора могу скАзать 🙂
А разве не вы придумали термин “process driven MDM”? 🙂
Ну, не лично я его придумал 🙂
Собственно, с основным посылом поста – что процессы – не менее важная часть описания деятельности организации, чем (мастер)-данные, я не спорю и всецело поддерживаю.
Олег, я согласен, что дискуссия развернулась, в основном, вокруг просто данных (транзакционных), но изначально я говорил именно о мастер данных. Может быть в телекоме граница не такая четкая, т.к. последние несколько лет активно развивается понятие “сервиса” – механизма связывающего классы, например продукты, с экземплярами, например конкретными инстансами оборудования, но BPMS-ам со справочниками бы разобраться.
Если мы сейчас добавим в процессы более сложные данные, например ресурс (под ресурсом здесь я подразумеваю что-то ограниченное, исчерпываемое, или же доступное в определенный временной интервал), то картинка усложнится неимоверно.
Картинка усложнится, если мы попытаемся управлять работой с этим типом данных, по привычке, “на коленке”. Если же четко понимать, что ресурс – объект с поведением, логика которого явно должна быть реализована снаружи BPMS, то вся сложность останется внутри этого объекта. Ну, это на первый взгляд, конечно.
Представьте, что учетной системы нет. Перед вами выбор – покупать коробочную или разрабатывать?
Мне представляется, для всех, кроме может быть самых крупных компаний, выбор очевиден – покупать. Эпоха самопальных разработок закончилась.
А на базе BPMS делать критические, наиболее значимые с точки зрения бизнеса процесса.
Ок, ясно. Спасибо.
Я понимаю вашу точку зрения, хотя и не согласен с ней.
Поживем – увидим)
Анатолий, мне жаль такие обсуждения скрывать в своем персональном блоге. Предлагаю перенести их на LinkedIn или в BPMS.Ru, т.к. аудитории там несравнимо больше.
Тема заслуживает заседания сообщества bpms.ru, но можно продолжить здесь, достаточно дать на bpms.ru анонс и ссылку.
А вот новость последнего часа: 23 ноября 2011 OSP-Con проводит форум “Интеграция корпоративных прикладных систем (ICAS-2011)”. Он будет включать короткую пленарную часть, за которой последуют три параллельных секции:
– интеграция на уровне бизнес-процессов
– интеграция данных и приложений
– интеграционные аспекты разработки и тестирования ПО
Организаторы пригласили меня выступить в качестве ключевого докладчика первой секции. По-моему подходящая площадка, чтобы продолжить разговор.
Ссылка:
http://www.ospcon.ru/event/integratsiya-korporativnykh-prikladnykh-sistem-icas-2011.html