Добрый день!
Возник вопрос по выбору подходящей нотации описания бизнес процессов, которые будут реализовываться в некой бухгалтерской системе (не 1С).
В системе большинство взаимодействий пользователя сводится к работе с документами, и выполнению различных действий с ними, которые приводят к изменению их статусов.
Специфика в том, что хотелось бы иметь:

• общее описание процесса (на уровне организации)
  
• описание действий пользователя в системе
• описание ожидаемой реакции системы (изменение статусов документов)

Хорошо бы если бы они были немного разделены, но связаны между собой. Может быть стоило бы отделить только описание процесса на уровне организации от описания происходящего в системе.
Я выбрал один, на мой взгляд, достаточно показательный процесс среднего объёма и сложности - процесс оформления командировок. И описал его в текстово-табличном виде. Но такой вид не очень нагляден и полностью специфичен.
Хотелось бы увидеть пару вариантов описания данного процесса в различных нотациях и в различных исполнениях.
К сожалению, хотя моя квалификация не позволяет мне решить такую сложную задачу (пытался описать в EPC, но вышло как-то коряво), так что очень надеюсь на вашу помощь.

Вы знаете! Что-то я сомневаюсь, чтобы кто-то срочно схватился рисовать ваши диаграммы в разных нотациях. Своих дел полно. Еще рецензию на Ваши диаграммы - куда ни шло!

Плохих и хороших нотаций нет, мне кажется. Есть цели моделирования, привычки.

Сегодня такие задачки чаще всего моделируют на BPMN. Там все нужное есть.

Если цель описания - поддержка разработки ПО, то нужно подумать о преемственности моделей, чтобы потом разработчикам не пришлось начинать все сначала. В таком случае я бы использовал профиль бизнес-моделирования для UML.

Если Вы просто хотите формально задокументировать свои процессы, вообще думать не о чем: Ваша таблица вовсе не корявая, и если ее использовать только для изучения процесса, она вполне достаточна. Особенно, если у Вас нет навыков моделирования.
Я вот уже много лет в этой сфере работаю, у меня получается быстро. Трачу время не на моделирование, а на понимание проблем. А, если навыков нет и надобность зибзическая, лучше сэкономить время и деньги.

У меня на сайте (http://lnew.ucoz.ru) есть несколько статей под общим названием "Повышение производительности ..." Они, правда, для профессионалов. Но там есть пример моделирования бизнес-процесса и получения из него требований к системе.

Удачи!

Я немного не врубился, а как можно описывать действия пользователя в системе в отрыве от реакции? Можно-то можно, но какой смысл?

Если только для понимания бизнес процесса, то я делаю так: описываю в таблице как вы, и в диаграмме деятельности. На диаграмме вертикально обозначаю используемые системы (в вашем случае одна система, поэтому можно отделы, департаменты и т.д.), а горизонтально - пользователей.  

Я немного не врубился, а как можно описывать действия пользователя в системе в отрыве от реакции? Можно-то можно, но какой смысл?

Описан бизнес-процесс. Сотрудник - business actor. Бухгалтер и кассир - business worker. Документы - business entity. Стиль описания - "прозрачный ящик (в терминах Коберна).

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

Спасибо всем за ответы!
Посмотрел в сторону uml activity diagram (диаграммы деятельности). Профиль бизнес-моделирования сложновато.
Сейчас актуальность вопроса несколько уменьшилась, поэтому к этому вопросу я вернусь наверное попозже.
lnew, вам отдельное спасибо, зашёл на ваш сайт, почитал статьи - весьма познавательно.

Господа! А реально изобразить диаграмму по описанию процесса, представленного Sorro, в DFD. Я тут попытался и уткнулся в 3 проблемы:

1. Как отобразить на схеме DFD условие (из 3 по данным)?

2. нужно ли отображать на схеме данные из первого столбца таблицы (Внешние события)?

3. Нужно ли указывать на стрелках потоков данных все документа, изменившие свой статус (громоздко получается)?

Простите, а зачем?

Человеку надо отобразить бизнес-процесс, а не потоки данных.

Мне кажется, нужно способ представления выбирать исходя из цели моделирования, а не наоборот.

Так Sorro писал "...которые будут реализовываться в некой бухгалтерской системе...". И чтобы реализовать нужно накатать ТЗ для программеров. А разве не проще рисовать в DFD для представления того, как движутся данные?

Я приверженец UML.

DFD - это только один срез будущей системы. И если Вы захотите рисовать другие диаграммы для других "срезов", Вам придется все начинать сначала, м.б., на других инструментах.

UML - универсальный язык как по уровням абстракции (предприятие, бизнес, система ...), так и по способам представления информации (13 диаграмм, тесно связанных и представляющих одни и те же элементы с разных сторон). В UML нет DFD, но есть другие (различные) способы представления данных и их движения.

Выкладываю набросок, хоть он мне и не нравится.
Поясню, что нотация выбирается для последующего описания процессов в системе, то есть потом ими будут пользоваться специалисты по внедрению\сопровождению, тестировщики и сами пользователи. Сейчас по таким диаграммам разработчики должны будут спроектировать механизмы настройки потоков работ, т.е. разработать систему статусов документов и систему настройки прав доступа на документы.
Появились мысли, что и вправду можно оставить описание процесса в такой таблице - т.к. они будут нужны только для документирования и тестирования.
В свою очередь, по таким описаниям, с помощью системы разграничения прав доступа будет настраиваться права пользователей на выполнения различных действий с документами (права на просмотр, создание, проведение, выполнение других действий, и т.д.). Так же отдельно будут настраиваться правила перехода документов из одних состояний в другие (часть переходов должна происходить автоматически, часть переходов инициируется после выполнения действий над документами).

Вот что у меня получилось, судя по Вашему описанию

Спасибо! По моему, очень даже не плохо. Аккуратно и наглядно.

Коллеги,

Если Вы рисуете диаграмму деятельности из ЮМЛ, то объекты должны быть между действиями, а не отдельно:
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_activitydiagram.html

У Monarcha это скорее eEPC. За ссылку спасибо.