Отстраивать бизнес-процессы при помощи ERP-системы это только один возможный путь, во многих ситуациях не самый лучший. Гартнер, например, выделяет пять классов ПО, так или иначе нацеленных на управление бизнес-процессами (BPM, business process management). В вольном пересказе:
1) Системы управления заданиями, которые можно трактовать как легковесные средства управления Б-П. (Пример -- Outlook.)
2) Средства поддержания коллективной работы, обеспечивающие маршрутизацию и согласование документов (всякий документооборот).
3) Прикладные системы (ERP, CRM), включающие модуль BPM. Пример: SAP.
4) BPM-системы интеграционного типа (нацеленные на поддержание межсистемного взаимодействия). Сюда относится большинство BPEL-совместимых BPM-систем.
5) Так называемые "Pure Play" BPM-системы -- не привязанные к приложению, общего назначения.
Для поставленной задачи стоит обратить внимание на последний класс. Такие системы ставятся поверх прикладных систем и позволяют напрямую управлять бизнес процесессами. Этот подход активно развивается последние года три (на Западе), некоторые называют его самым впечатляющим прорывом в ИТ за последние 10 лет. По собственному опыту могу засвидетельствовать: подход очень эффективный, при очень скромных затратах сил и времени (а по сравнению с внедрением ERP так просто ничтожных) удается достичь значимых с точки зрения ЛПР успехов.

LSVЭТО ОЧЕРЕДНОЕ МАРКЕТИНГОВОЕ СЛОВОБЛУДИЕ, которое изливают с трибуны всяческие сейлсы, которые в жизни даже макроса в Екселе ни разу не написали...
Хорошая позиция: "чего я не знаю, того и знать не стоит"

Вы уж определитесь, уважаемый -- либо Вас действительно интересует "что и как", либо Вы заранее решили, что имеете дело с тупым сэйлом.

2 LSV

BPM - это не vaporware, а реально работающая вещь. Отвечаю. :) Как это работает можно посмотреть например тут . Если появятся конкретные вопросы, постараюсь на них ответить.

DogenНе совсем понял, каким образом на некую заранее неизвестную ERP-систему или систему документооборота можно сверху поставить... что, собственно, поставить?
Дык через адапторы. Например, есть такая вещь как JCA (java connection adapter) -- и для R/3 есть, и для OEBS. Это ж целый отдельный рынок -- адаптеры ко всему что шевелится :) Или через вебсервисы. Или напрямую к базе через JDBC (хотя это фуууу...) Это если BPM на java; в .NET те же вебсервисы и всякие DCOM. С 1С конечно беда, к нему стандартным способом толком не обратишься.
DogenХотим конкретики. Ссылки на пресс-релиз или публикацию в приличном издании будет достаточно.
Ну я прям в затруднении. Публикаций по теме BPM море. У нас и Открытые системы пишут, и журнал "Пищевик". К вам в Гондурас интернет провели уже? :) На том же сайте www.bpms.ru есть и книги, и статьи, и ссылки на ресурсы. Если хочется чего-то более авторитетного, можно начать со статьи BPM в wikipedia.
Я лично щупал руками две BPM системы (из разряда "Pure Play"): Fujitsu-Interstage и Oag Grove. По цене различаются сильно, а так сходства больше чем различий, идея в общем одна и та же.

LSVНо это всего лишь рисование
Распространенная ошибка. ЭТО НЕ РИСОВАНИЕ. В том смысле, что рисуется это не для человека (чтоб на стенку повесить). Эта схема аплоадится на BPM-сервер и он начинает ее ИСПОЛНЯТЬ: у одного пользователей в интерфейсе появляется возможность запустить бизнес-процесс по тому шаблону, который мы загрузили, у другого в результате этого в списке назначенных ему задач появится новая, связанная с запущенным процессом, по ходу на каких-то шагах будут дергаться какие-то интерфейсы каких-то нижележащих корпоративных приложений... Улавливаете разницу с Visio?

LSVтак понимаю, там и некий симулятор Б/П имееца
Симулятор там (в некоторых BPM-системах) тоже имеется, но он не для этого. Тут речь идет о BPM Engine, "движке".

LSVВы вживую такую интеграцию видели? С какой системой?
Какой-то базарный слегка тон: "а почем ваши груши поганенькие"

Коннектиться к R/3 через JCA не приходилось (дорого очень). С 1С, с еще одной отечественной системой, с самопальными разработками заказчика -- приходилось.

Проблемы, связанные с людьми, заведомо труднее решаются чем те, что связаны с байтами, программами или компьютерами. Это аксиома.

Но от инструмента (и программ, в частности) отчасти зависит, удастся ли их решить. Поэтому знать возможности технологий и учитывать их надо. Преимущество новой технологической волны, связанной с BPM, по отношению к "рисовалкам" (Aris, BPwin и им подобные), отвлекаясь от технических деталей, заключается в том, что они позволяют осуществлять как радикальные (в классическом духе реинжиниринга), так и постепенные преобразования бизнес-процессов. (ERP, кстати, тоже не слишком приспособлены к тому, чтобы перестраивать в них бизнес-процессы.)

И это важно. У каждого руководителя есть свой "коридор возможностей". И если он даже понимает, что надо "всех уволить", то не всегда это возможно (по крайней мере сразу). Как говорил И.В.Сталин, "других писателей у меня для вас нет". (Или он говорил "другого народа"? - не помню точно.)

Есть руководители, которые любят решать проблемы кавалерийской атакой, а есть -- те, что предпочитают "тихой сапой". И они не глупее первых, а мудрее уж точно. Теперь, с появлением BPM, есть что предложить и тем, и другим.

Что лучше -- сначала придумать (взять у кого-то готовые) правильные бизнес-процессы, а потом внедрить что-то компьютерное, или наоброт -- сначала взять под контроль существующие бизнес-процессы более-менее как есть, чтобы потом модернизировать их уже при помощи специализированного инструментария?

Еще 5 лет назад такой вопрос вообще не стоял, потому что не просматривался этот самый инструментарий. Теперь он есть, и авторитетные бизнес-консультанты стали агитировать за второй вариант.

LSVРеинжениринг Б/П задача главным образом организационная. Тут никакие програмки существенно не помогут, как не помогут учебники в освоении скрипки или рисования. Б/П возникает сначала в голове, затем выкладывается в виде вербального изложения, подкреплённого наглядными графическими рисунками (IDEF0, UML и т.д.). Успех этого Б/П определяется полнотой, стройностью и логичностью описания. Не важно в чём и как описали. Важно, что это понятно тем, кто будет по этому Б/П строить живую систему.

Прекрасное изложение концепции реинжиниринга. Но суть в том, что эта концепция к настоящему времени устарела и мы живем уже в эпоху "пост-реинжиниринга". По крайней мере, "есть такое мнение". В частности, оно изложено в книге "BPM: The Third Wave". 20-е годы = появление самого понятия процесса, 90-е годы = реиннжиниринг, 2000-е = BPM как третья волна.

LSVА вот как ф-руют BPM мне не ясно. Конектиться можно к таблицам и СОМ-свойствам/методам. Но что полезного мы из этого извлекаем ? Как можем на это повлиять ? Имитировать ф-л сложной системы на симуляторе ? Допустим. Но какой от этого выигрыш ? Это же огромная работа. Что именно мы выигрываем ?

Хорошо, приведу пример из своей практики. Есть бизнес-процесс под названием "Заключение договора снабжения". Включает в себя примерно 20 шагов: выбор поставщика, согласование текста, бюджетный контроль и еще всяко разное. Управленцев задействовано тоже примерно столько же. И одновременно в работе, опять-таки, порядка 20 договоров. Есть три автоматизированной системы: некое подобие ERP, плюс бухгалтерия, плюс еще собственная база в канцелярии. Результат: договора заключаются даже не неделямя, а месяцами. Постоянный поиск у кого сейчас договор, постоянные разборки.

Что дает внедрение BPM: самое главное -- она следит "на ком стрелка". Передает задание от одного исполнителя другому, когда первый сделал свою часть работы. Контролирует время и ябедничает начальнику если кто-то процесс задерживает (например, шлет SMS). Пост-фактум составляет отчеты -- например, сколько времени тратится на договор и кто тормозит. Мало? Не скажИте -- руководство мгновенно понимает что это то, что ему надо.

Схема сделана более-менее as-is, с исправлениями совсем уж явных несуразностей. Изменить ее -- без проблем, хоть каждый день. И желание такое возникает: все узкие места становятся наглядными и ясно где можно улучшить.

По поводу интеграции. Где-то бизнес-процесс лезет в систему, например, чтобы достать сспецификацию приобретаемого товара или справочник поставщиков. Но вот что примечательно: оказалось, что это не столь существенно с точки зрения пользователей. Мы-то привыкли, что все должно быть "автоматизировано". А пользователь, как оказалось, не переживает из-за того, что, например система просто велит ему ввести в бухгалтерскую программу такие-то данные, сама при этом туда не лазя. В конце концов, шагом бизнес-процесса может быть "выкопать яму". Мы что, и это будем пытаться из программы делать?! Нафиг надо -- когда выкопает пусть нажмет кнопку "Сделано".

Это конечно не значит что интеграция вовсе не нужна -- нужна, и дублирования надо избегать, и информацию оперативно выдергивать и показывать в удобном виде. Но воспроизводить функционал специализированных систем -- точно не надо!

Уффф. Умаялся писать. Надеюсь, хоть что-то смог прояснить.