guest_20040621Можете привести пример "не чистого документооборота"? Что покупать-то нужно, по-Вашему?Производственное предприятие выполняет серийный заказ. Бизнес-процесс начинается от обращения покупателя, размещения заказа. Заканчивается доставкой на склад заказчика. Так называемый end-to-end бизнес-процесс. Этот процесс порождает великое множество документов, которые движутся абсолютно по разным траекториям как относительно друг друга, так и относительно процесса. Например, договор идет от продаж через юридические, финансовые и аналогичные службы, приходит в результате к заказчику. Но он не проходит, к примеру, через производство. Лимитка рождается в ОМТС (или как снабжение величают иначе), проходит через производство и уходит в бухгалтерию. Ну и т.п. В процессе таких бумаг целая куча. И ходят они и в прямом порядке, и в обратном, и с выходом на клиента, и чисто внутренние.
Т.е. траектория документооборота не совпадает с траекторией бизнес-процесса.
Предвижу второй вопрос: ценность. Если конечная цель состоит в том, чтобы разложить бумажки (документы) по нужным правильным папкам, то тогда документооборота вполне достаточно. Если же цель - стать ближе к клиенту, то клиенту до ваших папочек с бумагами фиолетово.
Это, знаете, как в расхожей шутке: "Основная задача нашего предприятия - отчитаться в налоговой инспекции".

guest_20040621Во-первых, в России бизнеса в принципе нет. Как класса. Во-вторых, где Вы видели руководителя, который бы навскидку смог объяснить разницу между двумя разными нотациями, например? Ну вот есть, скажем Workflow Server, RUNA WFE, uEngine BPM и еще небольшая тележка аналогичных пакетов, - и что, полагаете, кто-то из принимающих решения сможет элементарную методику сравнения сформулировать?Наверное, говорить за весь российский бизнес скопом несколько неосмотрительно... Есть, безусловно, и бизнес, есть и нормальные, адекватные руководители... Парадокс в том, что вот вроде и вник человек в тему, и правильные слова говорит... а потом выясняется, что понимание за словами слааааабенькое. Или просто у нас в россии не бизнесменов нет, просто у нас денег не хватает?

guest_20040621Откровенная чушь. OSS - не синоним "бесплатно" и "отсутствие поддержки". По моему скромному мнению, RedHat с ее open source продуктами загнется сильно позже, чем мелкомягкиеПопробуйте дать пользователю (не айтишнику) диск с "шапочкой" и попросите самостоятельно установить его на свой PC. Ну а может он по ходу и ядро сгенерит... Да, RedHat бесплатно, а админ - как договоритесь:) Это как струйный принтер за 1000 рублей.

MLightWJ,АБ...и все остальные гуру!!! Расскажите о практических решениях в BPM-системах.Хм... да вроде бы и рассказать не жалко, только как Вы себе это представляете в рамках форума? Типа, "вот знаете, было дело....".
Давайте я для начала Вам просто скажу, что есть реальные компании, получившие реальную положительную отдачу от внедрения BPM-систем. Некоторые из них присутствуют на этом форуме (если не в данный момент, то вообще). Если кто-то захочет поделиться СВОИМ опытом, то словечко замолвит. Ведь все равно вы не поверите словам "вот мы им поставили и они счастливы". Да и рекламой не хочется заниматься.
Если есть вопросы конкретные, прикладные - спрашивайте (можно открыть тему).

blindedКонечно клиентам фиолетово до налоговой,а налоговой до клиентов (не всегда). Вот только смржет ли ваша "пуля" сделать так чтобы и БП оптимизировался и документы в порядке. Ответ без программиста ни за что.Ой ли? Так уж и ни за что? Не отрицаю: некоторые вещи самостоятельно клиент сделать не сможет. Для этого существует техподдержка. Это разовые акции, за которые проще заплатить, чем держать штат. Но базовые фишки вполне в состоянии реализовать достаточно опытный пользователь. Обычно на практике так и происходит. Сначала софт попадает к аналитикам (поскольку программеры белы ручки о "попсовую прогу" марать гнушаются). Иногда сами руководители копают. И, надо сказать, очень даже успешно.

MLightВариант 1. Отдельные АСУ, DocFlow, BPM.
Нарисовали схемки на бумаге, перенесли в BPMS, запустили. Все работет, улучшаем БП, меняем схемки. Основная цель достигнута - менеждеры довольные. А пользователи не особо (часть документов в BPMS, часть лежит в DocFlow; данные вбиваем в BPMS, затем в АСУ).

Вариант 2. АСУ, DocFlow+BPM.
Нарисовали схемки на бумаге, перенесли в BPMS, запустили. Все работет, улучшаем БП, меняем схемки. Основная цель достигнута - менеждеры довольные. Пользователи частично (все документы лежат в одном месте; но данные вбиваем в BPMS, затем в АСУ).

Вариант 3. АСУ+BPM+DocFlow.
Есть базовые БП от поставщика системы. Все работет, улучшаем БП, меняем схемки. Основная цель достигнута - менеждеры довольные, пользователи тоже.

"Говорим BPM, а подразумеваем документооборот" - может быть есть в этом что-то, что необходимо предприятию т.е. Вариант 2.
Возможно нашим предприятиям повезет и им достанется Вариант 3. Почему? В некоторых сферах (например страхование, банки) есть проблемы с существующим качеством ПО и есть планы перехода на новые системы. Возможно они выбирут системы, где уже есть встроенный BPM.А что такого делает DocFlow, что не делает BPM?
И второй вопрос: а зачем надо вводить данные отдельно в АСУ и отдельно в BPMS? Чтобы рразвлечь пользователей? Или есть какой-то особый смысл, которого мне не постичь?

MLightДумаю, что во многих системах докуметооборота нет полноценного управления БП. И наоборот, например в Unify, нет докуметооборота.Почему Вы так решили? Чего именно из документооборота там нет? (я без шуток не понимаю). Просто: чего нельзя сделать?
MLight Потому, что интеграция между система очень сложная, а потому дорогостоящая вещь. Скорее всего при наличии отдельной BPMS не многие руководители пойдут на разработку интеграционных проектов, только для самы критических БП.Жизнь вообще сложная штука... Интеграция - она все же полегче:) Интеграция при помощи лично мне известных BPMS, особенно если есть доступ к телу (к базе данных) вещь абсолютно обычная и не требует от "многих руководителей" каких-то особых героических усилий.