Выкладываю свой доклад на конференции “Интеграция корпоративных прикладных систем (ICAS-2011)“
Общее впечатление от конференции: выше среднего. Идея совмещения в одном мероприятии BPM и интеграции вызывала у меня сильные сомнения, но оказался неправ. Много хороших докладов, содержательное обсуждение.
Последнее - самое главное. К сожалению, некоторые конференции представляют собой “междусобойчики” - если вычесть докладчиков и тех кого они привели с собой, то останется десятка полтора слушателей. Здесь ничего похожего не было, а была довольно большая (навскидку - сотни полторы посетителей), заинтересованная и профессиональная аудитория.
Так держать, ОСП!
Ссылки:
Анатолий, приветствую.
Помнится Вы говорили о том, что нецелесообразно CRM заменять BPMS. в этой презентации я насчитал по крайней мере 2 слайда где Вы предложили обратное……
Признаю, говорил.
Теоретически BPMS следует использовать для того, чтобы более эффективно использовать существующие корпоративные приложения, а не для того, чтобы их переписывать. И именно с этой позиции мы начинали работу в двух упомянутых проектах. Но по факту в обоих случаях выяснилось, что CRM реализует малую долю функциональности, а главное, что ее модель предметной области принципиально не соответствует бизнесу.
“Теоретически, никакой разницы между теорией и практикой нет. На практике, разница имеется.”
Грубо говоря, при настройке CRM-системы вы можете по-своему задать последовательность статусов, через которые проходит потенциальная сделка (т.н. “воронка продаж”). Но оказывается, по крайней мере в некоторых случаях, что сама модель смены статусов не способна описать состояние сделки. Модель конечного автомата (а речь идет о ней) не работает, когда 1) какие-то действия выполняются параллельно и/или 2) когда статус сделки многомерен.
Например, упомянутая в докладе компания, работающая в телекоме, готовит коммерческое предложение, охватывающее несколько инженерных объектов. Часть объектов может быть уже построена, а часть существовать только в планах, которые для начала нуждаются в проработке. Проработка объектов может запускаться синхронно, после получения определенного коммитмента от заказчика, а может асинхронно: заказчик еще только сделал запрос, но заказ этот настолько важен для нас, что мы идем на риск и тратим ресурсы на проработку сразу же - естественно, по решению высшего руководства. Более того, в некоторых случаях мы даже можем начать строительство, не дожидаясь заказа. И это асинхронное исполнение надо в дальнейшем координировать.
CRM системы (по крайней мере те, с которыми мне приходилось иметь дело) не способны работать с многопоточной логикой. Ну да, при соответствующих усилиях в них можно недостающую функциональность доработать. Но тут выясняется, что доработать учетную функциональность в BPMS и дешевле, и получается лучше, чем добавлять процессную функциональность к CRM. Потому что в BPMS есть средства быстрой разработки традиционных приложений, а в CRM адекватного процессного инструментария нет.
Так что да, правило остается прежним: не переписываем корпоративные системы с помощью BPM, а расширяем возможности и эффективность их применения.
Но правило это написано не для того, чтобы слепо ему следовать при любых обстоятельствах. Скорее, это направляющая нить. Можно отступать от правила при условии, что мы четко отдаем себе отчет почему и зачем мы это делаем в данном конкретном случае.
Анатолий, спасибо за познавательные слайды, особенно по кейсам (довольно редкая штука в презентациях по BPM(S)).
Вопрос по используемому в кейсах софту - если не секрет, какие системы использовали в качестве BPMS?
Андрей
Unify NXJ и BizAgi Xpress. В последнее время работаем в основном со вторым.