Скачивая пробную версию или демо-ролик BPMS, имейте в виду, что когда дело дойдет до промышленной эксплуатации, система, которая в итоге получится, многими существенными чертами будет отличаться от исходной “коробочной” версии:
- Пользовательский портал - веб-интерфейс, позволяющий запускать процессы, работать со списком назначенных пользователю заданий, отображать формы, соответствующие этим заданиям, а также контролировать и администрировать процессы. В промышленной системе он будет отличаться, как минимум, по внешнему виду, а скорее всего, и по функциональности. Если повезет, вам удастся обойтись кастомизацией “коробочного” портала, но будьте готовы к тому, что на каком-то этапе вам придется переписать его “с нуля”. Или, как вариант, вообще уйти от отдельно стоящего портала BPM, а тесно интегрировать процессную функциональность с корпоративной системой. Причина - пользователи обычно не готовы согласиться с мнением BPM-поставщика или интегратора, что BPMS должна быть центром его, пользователя, вселенной.
- В частности, на каком-то этапе в вашей системе должна исчезнуть кнопка “запустить процесс”. С точки зрения пользователя, он не “запускает процессы”, а занимается конкретным делом: например, принимает поступивший заказ или составляет заявление на отпуск. Стартовать соответствующие процессы система должна автоматически.
- Будьте готовы к тому, что на каком-то этапе экранные формы к шагам процессов, которые можно сгенерировать средствами BPMS в несколько кликов мыши, перестанут удовлетворять с точки зрения функциональности, юзабилити и дизайна. В связи с этим полезно с самого начала представлять себе, как вы будете разрабатывать эти формы: в какой среде, какими инструментами, силами каких программистов, с какими трудозатратами. Важность этого пункта трудно переоценить: например, что толку от того, что схема процесса рисуется за два дня, если (условно) разработка экранных форм к нему потом займет два месяца? (При этом я нисколько не преуменьшаю важность средств быстрого прототипирования экранных интерфейсов - в контексте BPM они абсолютно необходимы и без них ни до какой промышленной системы дело вообще не дойдет.) Кстати, скорее всего вы захотите воспользоваться этим же инструментарием и для переписывания портала.
- Аналогично, на определенном этапе вам перестанет хватать штатных отчетов и средств мониторинга.
- Демо- и пилотные версии процессов обычно хранят все необходимые данные в атрибутах процесса, процессных переменных или операндах (разные системы используют разную терминологию). В промышленной системе в таком виде хранятся только относительно малозначащие данные, представляющие интерес только в момент исполнения процесса. Большая же часть данных уходит в традиционную базу данных, а в контексте процесса хранится только первичный ключ соответствующей записи. Например, в процессе согласования клиентского заказа на покупку информация о клиенте и о позициях заказа скорее всего будет хранится в базе данных, а идентификаторы клиента и заказа и дата контрольного звонка клиенту по поводу заказа останутся в атрибутах процесса. Причина, по которой необходимо действовать именно так, очевидна: данные, представляющие интерес после завершения экземпляра процесса, должны храниться так, чтобы до них можно было добраться независимо от экземпляра процесса. Это, кстати, означает не только отдельное хранение, но и отдельные, не связанные с процессной функциональностью, экранные формы для доступа к этим данным. Соответственно экранные формы к шагам процессов должны будут работать “на два фронта”: и с атрибутами экземпляра процесса через API движка BPMS, и с полями базы данных через API СУБД.
- Развивая предыдущий пункт, скорее всего для части долгосрочной информации (но обычно не для всей) уже есть место в какой-то из имеющихся у вас корпоративных систем. Соответственно, в атрибутах процесса будут храниться идентификаторы соответствующих бизнес-объектов, а формы к шагам бизнес-процессов должны будут уметь обращаться еще и к корпоративным системам. (Впрочем, последнее не является абсолютом - зачастую это оказывается очень трудоемким делом, что оправдывает компромисс в виде лишь частичной интеграции с корпоративными системами.)
- Аналогично, если в демо- или пилотной версии процесса связанные с ним документы (обычно файлы Word или Excel) хранятся в виде приложений к экземпляру процесса, то в какой-то момент вам придется подумать о чем-то более солидном. Причина та же самая: если документ представляет интерес после завершения экземпляра процесса, значит, храниться он должен независимо от экземпляров процесса и доступ к нему должен предоставляться также независимо от процессной функциональности. Некоторым облегчением является то, что вам не нужна для этого тяжеловесная система документооборота - ведь задачу собственно документооборота вы уже решили при помощи BPM, вам нужно только хранение документов с соответствующими интерфейсами (пользовательским и программным) и сервисом (поиск, архивация, разграничение доступа).
- В демо- или пилотной версии аутентификация и авторизация пользователей обычно делается через собственный, независимый каталог LDAP, базу данных или вообще статический список пользователей, хранящийся в XML-файле где-то на сервере. Понятно, что промышленная система должна работать с уже имеющимся у вас каталогом пользователей. Но неприятным сюрпризом зачастую оказывается то, как много усилий это требует. Начать с того, что таких каталогов зачастую оказывается несколько. Типичный пример: есть Active Directory, есть собственная система авторизации в унаследованной бухгалтерской системе и есть информация о пользователях удаленных подразделений и пользователях компаний-партнеров, которая хранится в базе данных. По мере развития проекта могут возникать дополнительные требования: учет планового отсутствия сотрудников, замещение обязанностей на время отсутствия, автоматическое перенаправление заданий и т.д. Известно, что для компании, в которой число пользователей превышает сотню, внедрение только Active Directory представляет собой нетривиальный проект, а тут мы сталкиваемся явно с более сложной задачей. В результате в проектах BPM трудоемкость, приходящаяся на решение вопросов авторизации и аутентификации, в некоторых проектах достигает 50%. Представьте себе на минуточку, что это произошло именно в вашем проекте, причем при планировании проекта вы эти сложности недооценили: в результате до 100% превышения сроков и бюджета!
- Для демонстрации и для пилотного проекта обычно выбирают не самый сложный бизнес-процесс. Это бы ладно - хуже то, что и технически реализуют один бизнес-процесс. Но в реальности даже процесс приема на работу технически реализуется как несколько взаимодействующих друг с другом процессов (достаточно заметить, что рассмотрение присланных резюме не связано напрямую с публикацией вакансии). Тем более это справедливо по отношению к сквозным процессам, представляющим наибольший интерес с точки зрения бизнеса (см. анти-паттерн “Оркестровка сквозного процесса” и паттерн “Внутренний заказ”). Соответственно, вам довольно скоро придется расширить объем используемой функциональности вашей BPM-системы - освоить не только оркестровку, но и хореографию. Современные BPM-системы с этим нормально справляются, но для системы класса workflow или документооборота, встроенного в вашу учетную или бухгалтерскую систему, это может стать камнем преткновения.
- Ну и наконец, промышленная система отличается от пилотной уровнем надежности, производительности, защищенности … но это стандартные требования, ничего относящегося именно к BPM в них нет.
Но не пугайтесь: ведь все перечисленное делается не враз, а постепенно, и все компании, преуспевшие в BPM (а любой вендор может предоставить десятки референсов), в итоге с этими проблемами справились. Однако представлять себе что ждет “за поворотом”, после успешного выполнения пилота, полезно, и стоит заранее задать соответствующие вопросы и себе самому, и своему поставщику.
Ох как Вы правы, на своей шкуре все пункты кроме 2,9 и 10 очень прочувствованы.
Хочется добавить еще к пункту 5 проблемы с временем отклика системы при большом объеме данных, т.к. данные форм хранятся в БД BPMS “как пришлось”, т.е. как генератор форм придумал, или вообще в виде XMLя, без индексов и.т.д. Кстати именно эта проблема с моей точки зрения делает промышленное внедрение BPM систем без доработок невыполнимым. Интерфейс убогий терпеть можно (работают же сейчас пользователи с интерфейсами аля 90е и не гундят), а вот если форма открывается больше минуты, на 30й секунде ген директор может потянуться к телефону 8),
Еще не написано (ну от части п.7), что полноценный BPM подразумевает под собой интеграцию систем над которыми он висит. Т.е. нужен MDM и синхронизация справочников и.т.д.
При этом, не очень бы хотелось чтобы сейчас производители BPM дальше двигались в сторону поиска решений тех проблем, которые описаны. Честнее было бы выделить те функции, которые есть сейчас у лидеров в отдельный продукт для бизнеса и позволять бизнесу запускать процессы в эксплуатацию в том виде, в котором они его отрисуют. И не обещать, что потом не придется платить 8), это может отпугнуть. Все описанные проблемы решаются грамотным применением уже существующих инструментов. Это будет дорого, но оно того стоит. Некоторые проблемы нельзя решить без BPM, как нельзя решить проблему хранения данных без СУБД и интеграции без систем гарантированной доставки сообщений и управления распределенными транзакциями.
Anatoly -
Another very well-thought out posting. I’d say you should put your “don’t be scared” disclaimer at the top so that people don’t give up as they read
Also, I’ll note that many companies are successful with only *some* of the changes you point out - for example, for some processes, the stock forms are good enough (usually, internal processes), for some processes the portal is “good enough”, and for some processes the data management baked into the BPM tooling is “good enough”. But, each process will stress a BPM platform in different ways, and push the boundaries on different parts of the solution. A good BPMS isn’t as good at forms design as a good forms designer… or as good at data management as a good OR mapper or the Spring framework… but BPM platforms should bring down the level of expertise required to get the basics working, and give you options to get more advanced as required by your process (or as required over time with your process). I think the magic of BPM is making all these myriad items play well together, making the whole greater than the sum of its parts - but that doesn’t mean you can’t upgrade some of the parts when you need to
Great food for thought -
Scott
Дима
Мне особенно импонирует последняя фраза. Абсолютно верно: к определенным проблемам без BPMS лучше даже не подступаться. Ну а то, что при этом возникают новые проблемы, так это всегда так: много знания - много печали, а с увеличением площади круга растет длина окружности
Good advice, Scott
But as Russian proverb says, “one beaten is worth two unbeatens”. Or rather “one warned” for this case.
And you are absolutely right - I put “at some point” everywhere having exactly this in mind. Good BPMS lets you catch the process and deliver the value to the business amazingly fast and this creates the BPM magic: it’s the unique atmosphere of early success giving the way to even bigger success etc. In such atmosphere any issue from the post isn’t a big deal.
Bravo, Anatoly.
This is an excellent overview of some problems originated in mixing of “BPM as software” (a.k.a. BPM suite) and “enterprise BPM system” (what is implemented within an enterprise to manage its business processes). See also — http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html
Sure that a modern BPM suite is necessary, but not sufficient for a good enterprise BPM system - “an aircraft carrier should never operate alone”.
In the absence of agreed reference models and proper standards, creating good enterprise BPM systems implies serious architecting efforts. Below I comment your list from the architectural point of view.
1. Your own enterprise “worklist” application has to be considered regardless of a BPM suite “web portal”. The users want to handle business processes in conjunction with their business objects, e.g. business cases.
2. Business events (receiving an order) are often already available somewhere in your enterprise systems. Just associate them with your processes.
3. Automatically generated forms are usually considered only for quick prototyping.
4. Existing reports are usually considered only for quick prototyping.
5. By definition, business objects as BPM artefacts have to be externalised. Dreaming to keep them within a BPM suite is wrong from the beginning.
6. Audit trails and KPI are other BPM artefacts — put them out of a BPM suite, by definition.
7. Documents are yet another BPM artefacts. Keep them out and do not forget about records management.
8. Handling of roles (also a BPM artefact) is usually difficult. I recommend to create a set of groups oriented to processes, e.g. process owner, activity workers, etc. and to populate these groups from available resources (processes are useful for that).
9. Agree - patterns and anti-patterns are necessary for constructions of complex processes (see my blog http://improving-bpm-systems.blogspot.com/ for some practical process patterns).
I think that any discussion about the architecture of enterprise BPM systems is step from the current vendor-centric BPM to customer-centric BPM.
Thanks,
AS
Thank you, Alexander
I always supported your point that BPMS-centric approach gives biased perspective and that wider architecture-centric view is essential.
Yet this sounds somehow abstract for many of us so practical illustration won’t hurt - hence my post.
Spot-on. I have annotated your comprehensive list in my post.
http://davethinkingaloud.blogspot.com/2009/10/demo-vs-production-bpm-based-systems.html
D
Немного откланясь от темы.
По каким критериям можно определить что перед нами система класса workflow не способная реализовать полностью задачи и возможности BPM?
1. Проприетарные нотация и язык. (Критерий не абсолютный - в некоторых BPMS тоже можно найти своеобычные языки. Но они хоть стараются реализовывать нотации, похожие на BPMN.)
2. Отсутствие средств межпроцессной коммуникации (запуск одним бизнес-процессом другого, посылка сигналов и сообщений между ними).
3. Устаревшая проприетарная платформа (читай - не J2EE и не .NET), не поддерживающая современные технологии и интерфейсы (те же вебсервисы, например), как вариант - являющаяся придатком прикладной корпоративной системы.
4. В демороликах сплошной документооборот. (Критерий неформальный, но полезный.)
Хватит?
1. Кто не BPMN тот против нас?
3. Об интерфейсах пускай голова болит у интеграторов. Для систем сделаных с учетом особенностей текущей ИС (вышеназванных корпоративных придатков) это не самый острый вопрос.
С остальным соглашусь.
Но это вы описываете рудиментарную наколеночную скрепленую соплями и 200мм гвоздями для понта сделанную ..
А если подойти с другой стороны?
Workflow сделанная из соображения что не только програмист должен видеть и понимать логику работы, прохождения документов и.т п. Тесно-интегрированнную с местной ИС, поэтому java-net-etc-ewb-services не актуальны. Запуск процессов присутсвует, Взаимодействие процессов тоже (не во всех точках процееса правда). Демок документооборота тоже нет:) Процесс отображается графом. Присутвует хореография процессов, насколько я ее понимаю. Програмист и аналитик (он же тех директор, он же..) работают над процессом совместно (точнее аналитик висит над плечом програмитса и выдает соображения как оно должно быть).
Так вот вы приходите в эту фирму с проектом внедрения BPM (как парадигмы управления, не конкретной системы)
Варианты действий
1) Отрвать все от ИС, переписать на web-сервисы, внедрить что-другое, поскольку все что было показно на BPMS не тянет.
2) С помощью местных ITишников выявляем места которых нехватает для BPM/
Вопрос в том где проходит грань между системой управленя потоком работ и системой упрвления бизнес-процессами?
Одну из таких граней я вижу в бизнес-аналитике который сам рулит процессами, но наверное есть и другие аспекты которых я еще не вижу.
Что-то вопрос получился очень длинный, но очень хотелось задать правильный контекст.
1. BPMN - это как SQL образца начала 90-х. Никто строго не придерживается, но все как-то пытаются соответствовать. И это правильно и хорошо.
3. Программу, следующую принципам объектно-ориентированного программирования, в принципе можно написать и на фортране. На C++ теоретически лучше, но бывают разные ситуации. То же и здесь: при желании можно сконструировать ситуацию, в которой теоретически “плохая” workflow-система “здесь и сейчас” будет лучше самой совершенной BPMS.
Да, вы правы, четвертым (а лучше первым) пунктом стоит добавить, что workflow - это, как правило, “автоматизация”, а BPM (и BPMS, как инструмент) - технология бизнес-трансформации. Сделали паузу, почувствовали разницу… BPM, не выходящий на уровень бизнеса, “заказчика заказчика”, цепочки создания ценности и тому подобных вещей - это не BPM. Но, опять-таки, если очень постараться, можно этих целей достичь и при помощи workflow-системы.
Пятым пунктом можно добавить интегральную характеристику - способность быстро менять бизнес-процесс, agility. Впрочем, формализовать этот критерий еще труднее, чем остальные.
И последнее: BPM (и SOA) - это не “оторвать и переписать”, а “сохранить и приумножить” - повысить эффективность использования уже имеющихся баз данных и корпоративных систем, подключив их к бизнес-процессам, затрагивающим на порядок больше сотрудников, чем только пользователей из бухгалтерии и финансов.