Вообще в этой области можно выделить три подхода. Первый: аналитики рисуют блок-схемы бизнес-процессов в ARIS, IDEF или просто блок-схемой в Word и передают ее ИТ-специалистам в качестве задания на разработку. Увы, Ваше мнение "все прекрасно справляются" разделяют не все. Этот подход раз за разом приводит к одному и тому же: автоматизации не до конца понятых либо явно неоптимальных процессов. Когда через полгода-год-два (в зависимости от масштаба проекта) разработчики сдают систему, то выясняется, что либо аналитики имели в виду не то, что разработчики прочли в ТЗ, либо сам процесс поменялся, например, под влиянием измения бизнес-среды. Осознав эту проблему, светлые умы стали искать способ как сократить цикл разработки с месяцев до хотя бы недель и как уменьшить пропасть между представлениями аналитиков и разработчиков. То, что они придумали, они назвали BPM.

Второй подход - тот, что Вы описываете: нарисовал в системе 1 - экспортировал в систему 2 - там запустил на исполнение. Так работает ARIS в связке с SAP и с Oracle BPEL. У этого подхода есть серьезный недостаток: он работает только в одну сторону. Дело в том, что в системе 2 процесс неизбежно подвергается детализации и доработке. И как следствие, если аналитик теперь изменил схему процесса в системе 1, то непонятно как это изменение "скрестить" с изменениями, произведенными в системе 2. (Это так называемая проблема "round-trip" в BPM-системах, подробнее о ней можно прочесть на bpms.ru ). В результате, как и при первом подходе, кооперация и взаимопонимание между бизнесом и ИТ находятся на низком уровне.

И третий подход - BPM в полном смысле: одна и та же модель доступна и аналитикам, и разработчикам, и ее же исполняет "движок". Без всякого импорта-экспорта. От детальных объяснений как это работает, что такое "движок" и как он "исполняет" бизнес-процессы позвольте уклониться - скачайте тот же Unify NXJ или BEA AquaLogic BPM , выполните их tutorial и сами во всем разберетесь.

Примеры успешной реализации подходов 2 и 3 есть, но в основном это истории, расказанные вендорами. Много общих слов о бизнес-преимуществах, мало о технической реализации и практически невозможно найти схему реального бизнес-процесса - их просто никто не раскрывает, справедливо считая своим ноу-хау.