iscrafm WJBPMS - это вещь сначала для бизнеса. И пора привыкнуть к мысли, что ИТ - эти лишь "вспомогательное производство" бизнеса.
думаю что пора также привыкнуть к мысли, что сейчас ИТ на предприятиях играет далеко не роль "смотрящих за принтерами" :) . И вопрос: а кто(что) по Вашему является "основным производством" бизнеса?
Совершенно с Вами согласен. Но для того, чтобы бизнес и ИТ полноценно удовлетворяли друг друга, необходимо, чтобы ИТ-специалисты также немного "отвыкли" от мысли, что они лишь "смотрят за принтерами". ИТ-шникам нужно научиться мыслить категорями менеджмента, чтобы понимать или даже предугадывать потребности бизнеса. А не судить об IT-инструментариях, например, по языку, на котором они написаны, или лишь по удобству клацанпия мышкой (то есть по очень второстепенным и очень косвенным признакам). С точки зрения бизнеса получить 10 вагонов с товаром на 3 дня раньше может быть гораздо важнее, чем 100 лишних раз клацнуть мышкой... :)

АБТак и развитые корпоративные системы (ERP, CRM и прочие) умеют отслеживать и взаимосвязи между документами, и некоторое подобие бизнес-процессов. То есть как-то заменяют и BPM, и документооборот. Да и вообще вполне можно все на свете запихать в таблицы базы данных, а то и в плоские файлы. Но это все poorman's solutions. На мой взгляд, процесс - это самостоятельная сущность, без ущерба не сводимая ни к алгоритмам, ни к данным, ни к документам. Вот данные тоже можно в принципе не отделять от алгоритмов - но нет, мы понимаем, что лучше иметь отдельный класс системного программного обеспечения - DBMS. То же справедливо и по отношению к BPMS.Совершенно согласен. Главное отличие - в динамичности, в скорости и удобстве внесения изменений (между ERP и BPMS). Но между ECM и BPM в этом я отличий не вижу. Точнее, вижу... :)

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

Кроме того, ECM-система позволяет произвести логически связки между документами (например, накладная связана с оплатами по таким-то счетам, оплаты связаны с таким-то договором и т.д.) и на основе этих связок моментально выбрать, например, оплаты по интересующему договору или счету или счету-фактуре (можно нафантазировать всё что угодно). В BPM-системе документы связаны не напрямую, а косвенно посредством операций бизнес-процесса. Если они фигурируют в одном бизнес-процессе, нужно будет строить громоздкий запрос силами IT-специалиста, чтобы получить интересующую информацию. Если они фигурируют в разных БП, а связка происходит на их стыке и явно никак не зафиксирована, то получить ответ на интересующий вопрос может оказаться вообще невозможно. Выкрутиться, разумеется, можно вводом вспомогательных полей для связки... Но всё это - джига с бубном, которой я стараюсь избегать. :)

АБЯ считаю, родное применение ECM (можно я этот термин буду использовать вместо Docflow?) - это хранение документов. И это она делает заведомо лучше всех остальных, потому что для этого предназначена.Ну, хранит и ищет она документы, разумеется, лучше всех... :)

АБНо когда в нее пытаются запихнуть процессы, то получается так же плохонько, как при попытке в ERP запихнуть процесс или в BPM - документы.Я пытаюсь обнаружить эту самую "плохость", но как-то не получается. С удивлением для себя обнаружил, что некоторые ECM по возможностям использования в роли BPM превосходят некоторые BPM-системы.

АБКаждому овощу - свой фрукт! Структурированным данным - DBMS, документам - ECM, процессам - BPMS.Я себе представляю так... Если задачи стоят преимущественно интеграции приложений, то, конечно же, использовать для этих целей ECM неразумно. Если необходимо автоматизировать БП и получить возможность вносить в них изменения - БЕЗ автоматизации документооборота (трудно себе представить идеальную такую ситуацию), то годится как BPMS, так и ECM. Если нужно автоматизировать документооборот, то таки ECM. Если документооборот и БП, то мне больше импонирует ECM. Если и документооборот, и интеграция, и гибкость БП, то тут нужно смотреть и всматриваться в частности.

АБВы рассуждаете о некоторой идеальной ECM-системе, которая мутировала уже в полноценную human-to-human BPM, и состыкованную к тому же (додумываю для полного благолепия) с прилично реализованной system-to-system BPM от того же производителя.На текущий момент я ознакомился с возможностями ECM-систем Directum и Documentum. Я говорил не об идеальной системе, а о возможностях, которые есть в одной, другой или в обеих системах. Кстати, обе системы поддерживают версионность схемы БП. Весьма подробно изучил возможности Directum. В ней, кстати, так же как в Unify автоматом генерятся экранные формы. Могу отметить лишь одно ее слабое место по сравнению с Unify NXJ. WEB-интерфейс там какой-то есть, но совершенно убогий. Использование системы производится только с рабочих мест, где предварительно установлено WIN-приложение. Так что эта система годится для использования в локальной сети собственными сотрудниками, но плохо подходит для использования сотрудниками с разъездным характером работы и для взаимодействия с партнерами по бизнесу. Тут уже каждый решает сам, что для него важнее.

АБНо! Это ведь уже не ECM-система в привычном значении этого термина.Честно говоря, мне "по барабану", какими терминами какие системы называют. Я смотрю лишь на то, какие задачи лично я могу решить с их помощью. Может быть, указанные мною перечисленные две системы уже и не совсем корректно называть ECM. Может быть, правильнее их называть BPM + хранилище документов. Но сейчас их пока преимущественно используют как ECM и в очень малой степени как BPM. Собственно, примерно такая же ситуация и с "BPMS" BizTalk или Oracle BPEL. Обычно их используют как EAI, всего лишь. Ну просто не все знают, что пистолетом можно не только швырнуть в лоб противнику, но и выстрелить из него... :)

АБИ на одну такую систему с полноценным управлением бизнес-процессами придется с десяток ECM систем, к которым производитель наскоро прилепил красочный лэйбл "BPM inside". И с Вашей подачи люди будут попадаться на эту удочку.На всякий случай предупреждаю уважаемый ALL, чтобы меня не слушали, а думали своей головой, потому как всё сказанное - всего лишь мое IMHO (о чем, собственно, я уже предупреждал). :)

АБПоэтому если производитель ECM реализовал у себя BPM, то что можно сказать против? Равно как и против того, чтобы производитель BPM "в одном флаконе" поставлял и ECM?Ну, в общем-то, возразить нечего. Полностью согласен!

АБНа самом деле возразить есть что. Вы мечтаете получить все в одном флаконе: и BPM, и статистику с математикой, и еще много чего. Мне кажется, в этом стремлении есть некоторая инфантильность. "Вот дождусь когда наконец все будет вместе, и тогда уж... ого-го!" :) Боюсь, Вы так и будете ждать годами.Я сам это прекрасно понимаю. Отчасти поэтому у меня плохое настроение... :(

АБА результат - сегодня - кто будет давать, Пушкин? Вот Вы и выкинете в корзину результат, который можно получить сегодня, дожидаясь прекрасного завтра, и это будет вполне закономерно. (Да-да, это намек )Намек понял... :) Я-то с Вами согласен. Было бы здорово, чтобы руководство согласилось... А я обеими руками за то, что Вы говорите.

АБМне лично больше импонирует идея модульности. Применительно к рассматриваемой теме - не та BPM-система, которая пытается "заодно" быть ECM или скажем BRE, а та, в которой реализована модульна архитектура и имеются адаптеры, позволяющие состыковать ее с ECM системами третьих фирм (от лучших производителей).Ну, это уже из разряда личных предпочтений...

АБТочно так же мне не нравится идея ECM-системы или ERP-системы, которую производитель за уши дотягивают (когда удачно, когда нет) до уровня BPM.По поводу ERP соглашусь. Не получается их состыковать по-человечески. А вот в ECM, пмсм, как-то более удачно вписалась.

АБИ на закуску - еще одно возражение. Один из наших заказчиков хотел практически того же, что и Вы: гармоничной связки BPM + ECM. И он рассматривал в тендере систему "родом из документооборота", причем, подозреваю, как раз ту, что Вы имеете в виду. Так вот, заказчик от нее отказался, объяснив свой выбор так: "Да, нам понравилась их система, но не понравилось как они умеют с ними работать: в пилотном проекте у них, несмотря на все возможности BPM их системы, по факту получился все-таки документооборот."Мне показали реально работающий проект именно в роли BPM-системы. Попробовал, покрутил - работает! Сам сильно удивился. Более того, там еще и средства имитационного моделирования имеются. Целый день в системе ковырялся, потом неделю ходил в состоянии крайнего изумления.

АБТак что мало иметь BPM в продукте, надо иметь его еще и в культуре фирмы.ПМСМ, EAI гораздо меньше похожи на BPM, нежели изученные мною ECM. Это всего лишь мое личное мнение.

АБОй ли? В реляционной базе я знаю, что если понадобится, то я смогу построить sql join по 11 таблицам и получить выборку за приемлемое время. OLAP-система тоже попыхтит и выдаст требуемый нетривиальный результат за пристойное время.Оба варианта требуют построения запроса IT-специалистом. В ECM запрос может построить любой пользователь.

АБДа, тот же Unify не хвастается, что вы сможете эффективно строить запросы, связывая различные экземпляры процссов по значениям их атрибутов. Потому что это нафиг никому не нужно. Уж на что IBM тупой как мы тут только что выяснили :) а и тот четко говорит: держите в BPM не значения атрибутов (суммы там, количества, адреса-пароли-явки), а ссылки (ключи) на записи во внешней системе, из которой вы сможете все атрибуты извлечь при помощи веб-сервиса или каким-то более традиционным способом.В ECM ссылки на внешние источники тоже весьма живописно встраиваются.

АБВ прошлом своем посте я Вас убеждал не валить в одну кучу задачи BPM и ECM, а теперь вижу, что Вы и задачи учетных систем готовы замесить в ту же кучу для пущего аромата :)Нет, на это я пока не готов... :)

АБДа, но я подозреваю, что в исходном вопросе WJ имелась в виду не система класса "BPM+ECM в одном флаконе", а традиционный "чистый документооборот". Иначе не было бы повода задавать вопрос.Ну, если чистый, тогда конечно BPMS гораздо привлекательнее. Но тогда и обсуждение получается какое-то абстрактное. Где их найти, эти чистые ECM?

АБНе потянет ни ECM, ни BPMS запросов на связях атрибутов/полей, сколько-нибудь сравнимых с теми, которые исполняют СУБД в корпоративных системах. Т.е. Вы рискуете, получив привлекательные результаты на игрушечных примерах, в промышленной эксплуатации по-крупному влипнуть.Производительность не тестировал, честно признаюсь.

АБЧто-то не пойму: либо веб-интерфейс есть (пусть убогий), либо требуется клиент на каждое рабочее место. Разъясните пожалуйста. Но это достаточно серьезно. По крайней мере, в перечне потребностей наших потенциальных заказчиков взаимодействие с партнерами по бизнесу (и клиентами-"физиками" кстати тоже) присутствует почти всегда, взаимодействие с разъездными сотрудниками - примерно в половине случаев.WEB-интерфейс есть, но реально работать с ним можно лишь в БП, не имеющих никакого отношения к реальности. Проще считать, что его просто нет. Я уже сказал, что это один из наиболее существенных недостатков Directum.

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