Unify NXJ и BizAgi Xpress. В последнее время работаем в основном со вторым.

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

“Теоретически, никакой разницы между теорией и практикой нет. На практике, разница имеется.”

Грубо говоря, при настройке CRM-системы вы можете по-своему задать последовательность статусов, через которые проходит потенциальная сделка (т.н. “воронка продаж”). Но оказывается, по крайней мере в некоторых случаях, что сама модель смены статусов не способна описать состояние сделки. Модель конечного автомата (а речь идет о ней) не работает, когда 1) какие-то действия выполняются параллельно и/или 2) когда статус сделки многомерен.

Например, упомянутая в докладе компания, работающая в телекоме, готовит коммерческое предложение, охватывающее несколько инженерных объектов. Часть объектов может быть уже построена, а часть существовать только в планах, которые для начала нуждаются в проработке. Проработка объектов может запускаться синхронно, после получения определенного коммитмента от заказчика, а может асинхронно: заказчик еще только сделал запрос, но заказ этот настолько важен для нас, что мы идем на риск и тратим ресурсы на проработку сразу же - естественно, по решению высшего руководства. Более того, в некоторых случаях мы даже можем начать строительство, не дожидаясь заказа. И это асинхронное исполнение надо в дальнейшем координировать.

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

Так что да, правило остается прежним: не переписываем корпоративные системы с помощью BPM, а расширяем возможности и эффективность их применения.

Но правило это написано не для того, чтобы слепо ему следовать при любых обстоятельствах. Скорее, это направляющая нить. Можно отступать от правила при условии, что мы четко отдаем себе отчет почему и зачем мы это делаем в данном конкретном случае.