Автор: Репин В.В.  Он пишет: "В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие.При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов. Для бизнес-аналитиков компаний тезисы, обсуждаемые в статье, - это серьезный повод задуматься, насколько эффективны используемые ими подходы к разработке графических схем процессов организации."    Оригинал: Описание бизнес-процессов: стремление к простоте

Видимо готовясь к Процессному  форуму  2010,  Репин В.В. здорово активизировался в части публикаций. Эта статья немного аналитическая, а еще парочка статей - про Business Studio: Построение системы процессов в среде Business Studio . http://www.businessstudio.ru/procedures/business/devprocess/, Описание и регламентация процессов управления в среде Business Studio http://www.businessstudio.ru/procedures/business/reglament

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

1) Каким образом создавать схемы и описания бизнес-процессов, которые бы позволяли получить общую картину. Я работал с документами, где солидные компании для не менее солидного заказчика делали подобные схемы по автоматизируемому участку. получалось 500 и более страниц документа. И что? На момент внедрения, и даже следующего подхода актуальность все равно непонятна, а общую картину - не получишь. Нужно искать другие формы.
2) Если идет описание локального фрагмента для использования в короткой перспективе, то принципиальным становится трудоемкость создания схем и внесения изменений.

К сожалению. на оба вопроса в статьях ответ отсутствует. Впрочем, в других материалах я его тоже не видел. Если кто знает - поделитесь ссылками.

P.S. А что в описаниях и диаграмах надо стремиться к простоте - это классика. Фаулер, UML distilled.

Автор: Репин В.В.  Он пишет: "В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие.При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов. Для бизнес-аналитиков компаний тезисы, обсуждаемые в статье, - это серьезный повод задуматься, насколько эффективны используемые ими подходы к разработке графических схем процессов организации."    Оригинал: Описание бизнес-процессов: стремление к простоте

Мы вот решили попробовать описывать процессы с помощью нотации BPMN.

Спорная статья.
Для начала во Введении ставиться цель: «Одной из важнейших целей формирования графических схем процессов является последующее их использование в регламентирующих документах организации». И уже в выводах предлагается «хорошая» схема из практики жизни авторы которой вообще стремились отказаться «от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т.п»
Заявленная цель и предлагаемый результат не совпадают. Зачем вообще ставить такие цели.

Во вторых, схем бизнес процессов может быть множество назначений, в том числе объяснение техническим специалистам как должна работать будущая система. Если же цель это только иллюстрация регламента работы сотрудника, то первичен именно регламент, а схема рисуется для наглядности и тут можно убрать все «шумы» в виде сущностей или деталей развилок, оставив только самое главное шаги процесса.

В третьих, схема из практики жизни вообще удивляет. Да возможно она легка для восприятия сотрудникам которые уже работают и без схемы знают процесс. По сути она представляет для них шпаргалку с отдельными важными моментами. Но я на 100 % уверен, что если ее получит новый сотрудник, он будет долго в ней разбираться и у него все равно будут вопросы, что же и как делать. Ее сложно понять без дополнительных комментариев. Получается, что текст, закрепленный в регламенте, на практике заменили разговором с более компетентным сотрудником.

Общий вывод из статьи у меня получился такой: Нужно рисовать так нам удобнее и как можно проще, т.к. 1) мы не можем объяснить рядовым сотрудникам, как читать наши схемы 2) мы сами плохо разбираемся в нотациях и специализированном ПО 3) рисовать нужно много и 4) у нас нет на это времени.