Вот такой вопрос возник:
Какие диаграммы, по методологии UML, лучше всего использовать для описания бизнес-процессов? Чтобы описать процесс с достаточной степенью подробности даже для каких-нибудь крупных предприятий. Хотелось бы определить именно необходимый минимум диаграмм, а так же степень взаимосвязанности и взаимозависимоти друг от друга.

Ну понятно, что фундаментальные
1. диграмма ВИ, она хорошо подточена под бизнес... без нее не обойтись для описания БП высокого уровня иерархии
2. ДК, тоже считаю обязательным...
А что еще? Возможно диаграмма состояний...

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

Для описания БП можно использовать как подход декларируемый RUP -- BUC/BA models, так и модификации, которые предложены различными авторами, вплоть до введения ими собственных стереотипов. В любом случае, описание бизнеса тоже сводится к описанию статической и диниамической составляющей. Статика - это те же BUC диаграммы и различные вариции на тему диаграмм классов. Динамика это activity/sequence/collaboration.

Тут есть один момент -- он связан в частности с тем, что нужно четко понимать какую цель мы преследуем, когда хотим заняться описанием бизнес-процессов, и подбирвать соответстующие средства для этого. Например, если цель сделать автоматизацию БП, в сфере где БП нам известны, то не факт, что имеет смысл делать полномасштабное описание бизнеса, а может только некоторые общие вещи или наоборот -- отдельные детали. Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.

Если рассматривать RUP и RR, то при построении диаграмм вариантов использования есть два средства уточнения или детализирования процесса - это в первую очередь диаграммы деятельности и диаграммы состояний. В большей части используют диаграммы деятельности, которые по существу могут заменяться сценарным описанием либо дополняться им. При этом ДД могут быть несколько на основной поток и на альтернативные действия. Как используются ДС на бизнес уровне, не очень ясно - мало видел примеров.

Далее  каждый ВИ может связываться с диаграммой бизнес-объектов, описывающей реализацию. Реализация обычно описывается через диаграммы последовательности и диаграммы взаимодействия, что в общем одно и тоже. При этом каждая операция в данном контексте - есть событие возникающее в ходе реализации ВИ.

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

Спасибо за посты!
Ну вот передо мной лежит книга "RUP - это легко" (Кролл, Кратчен), должен подметить, что на
примерах бизнес-моделей прохалтурили...

Т.е. с учетом сказанного к такому выводу можно прийти:
Чтобы описать с некоторой минимальной степенью подробности бизнес-процесс, используем:
1. Статика
Бизнес расширения диаграммы вариантов использования + расширения для бизнес-систем диаграммы классов
2. Динамика
Детализируем процессы при помощи диаграммы деятельности

Стоп стоп стоп.
Диаграммы последовательности - это тоже динамика. Что есть динамическая система, система изменяющая свое состояние, т.е. имеющее не одно состояние. Когда мы фиксриуем статику (ДВИ или ДК) мы фиксируем устойчивые связи. Когда мы используем ДП, ДВ, ДС, ДД - все это уже поведенческие модели.
Т.е. ДВИ и ДБО показывают разметку, а все остальное, как используя эту разметку из пункта А попасть в пункт Б - варианты будут разные, потому требуют оценки с позиции результативности, ресурсоемкости и эффективности.

Думаю не ошибусь сильно:  ДВИ и ДБО дают контекст, в котором нам предстоит работать, задает фазовое пространство. Остальные диаграммы дают описание возможных траекторий. Одна из которых должна быть определена. Чем хорошо UML и некий процесс, он задает правила использования. Так же как скажем определение отношения: декартовое призведение множеств. Но это все варианты, но семантически часть из них незначимы и невозможны...

Вот такой вопрос возник:
Какие диаграммы, по методологии UML, лучше всего использовать для описания бизнес-процессов?

А почему именно UML, это что, самоцель?

Ну понятно, что фундаментальные
1. диграмма ВИ, она хорошо подточена под бизнес...

Это в каком смысле?

2Galogen
Да-да, это все, в принципе, понятно и вполне логично! Хотя я немного склонялся к мысли, что для описания объектно-ориентированных систем и бизнес-процессов должны быть более значительные различия именно в идейной методологии...

2Денис
Да нет никакой цели, только в качестве самообразования... Дело в том, что описание БП по методологии ARIS, даже описание БП  в excel в виде перечисления последовательности действий и тп, вполне представляю, даже немного приходилось делать, а вот по UML с трудом... никогда не видел, поэтому и интересно.  Что касается вопроса о том какую из методологий лучше использовать, уж не знаю, склоняюсь больше к Арису

Keen_G, между тем с помощью UML при введении стереотипов, и картинок, можно легко сделать бизнес-процессы. И даже такие как в ARIS.
Рисовалка и есть рисовалка, важно мне кажется не как изобразить, а можно ли рутину переложить на плече компа и получать либо полуготовый код, либо вполне работающее приложение, либо .. А зачем изучают бизнес процессы??? Ась???

Правда из разговора с коллегами-форумчанами, понял, что мне эти БП вроде и не к чему, и связываться с ними тоже вроде как странно:-))

[quote autor=Galogen]между тем с помощью UML при введении стереотипов, и картинок, можно легко сделать бизнес-процессы. И даже такие как в ARIS.[/quote]
Несомненно! ну а толку то :-))
Galogen, есть идеи о том как организовать автоматическое (машинное) построение БП? Очень интересно, но с трудом даже представляю как это может выглядеть... Мегареволюционная идея...

А зачем изучают бизнес процессы???

Сейчас по проекту в довольно крупной организации сижу... И частенько ситуации бывают, когда надо узнать непосредственные обязанности экономистов, бухгалтеров и тд. (Потому что если спрашивать лично человека, то окажется, что у него вообще практически нет обязанностей) А БП выложены на портале, спокойненько смотрю: ага, экономист, делает то и то и то....

Keen_G! Гусь свинье не товарищ. Гусь это, конечно, ты, я свинья. Т.е. ты летаешь высоко, сталкиваешься с насущными проблемами. А я? А я каждую задачу высасываю из пальца. Прадва я не очень понимаю зачем усложнять сложное. Т.е. к примеру - разве студенту не посилам понять, хотя бы поверхностно, бизнес-процессы скажем в магазине, или в некотором упрощенном производстве.

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

А когда я говорил про автоматизации рутины, я имел в виду - что инструмент берет на себя проверку логики, органичений, соответствия правилам и т.п. И конечно я впервую голову рассуждаю не о ВЫСОКОМ БИЗНЕС_УРОВНЕ, где находится пласт бизнес аналитиков, а уже более приземленный, где сидит пласт системных аналитиков, специалистов в области программирования, ИТ, баз данных и т.п.

Это называется разделение труда. Правда системных аналитиков как я понимаю мы тоже не готовим

А когда я говорил про автоматизации рутины, я имел в виду - что инструмент берет на себя проверку логики, органичений, соответствия правилам и т.п.

Думаю, разработчик такой системы озолотится!!! Идея, конечно, классная... Но, на мой взгляд, самые главные проблемы будут даже не в сложности самой системы, способной так "читать" БП, а в универсальности! Ведь понятное дело, что БП европейских организаций сильно отличаются от российских...  Да что говорить о странах, даже в пределах организаций да и то...

Вот интересный факт наблюдаю... Сегодня купил известную книжку от "Г. Буча и его друзей" Язык UML. Руковдство пользователя. Так там язык не позиционируется как средство для описания бизнес-процессов (только для ПО), даже все бизнес-расширения опущены.

Ага, мне кажется, тут есть два разных подхода к осмылсению этого вопроса:
1. Бизнес-процесс - как объект исследования управления
2. Бизнес-процесс - как объект подлежащий автоматизации
Мне думается - одно дополняет другое, но не обязательно затрагивает. Т.е. если стоит проблема автоматизации некоего БП, то это не значит, что я должен провести скурпулезный анализ этого БП во всех его проявлениях и рисках. Если такая нужда имеется - то ею занимается специалист-предметник. А если нет, то я просто строю системную модель БП как ИТ-специалист, прототипирую его, а дальше в итерационной процедуре приближаюсь к истине.
Но это же много проще.
Как найти корень уравнения: используем метод Ньютона(касательных). Большое значение имеет выбор начального приближения - это делает бизнес-аналитик, а я как ИТ-специалист, предлагаю процедуру последовательного приближения к истинному значению. Однако заметь никогда его не достигаю, достигаю лишь с определенной точностью.
Потому и в данном случае, что принять за начало, а что за конец процесса? На какой стадии, в каком месте, с какой точки зрения? Все это будет определятся целью и задачей.
Ну хорошо моделируем мы деятельность кладовщика - ну кто мешает сделать timetable его работы по приемке этого товара, посмотреть все операции? Никто, а что будет подлежать автоматизации? Если весь цикл разгрузки-погрузки, например с ипользованием робототизированной системы - это одно, а если учетных функций - т.е. документирование фактов хозяйственной операции - помоему другое совсем.

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

Какие диаграммы, по методологии UML, лучше всего использовать для описания бизнес-процессов?

IMHO для описания бизнес-процессов лучше не использовать никаких UML-диаграмм. Если всё же очень хочется - activity и sequence/collaboration. Любимой class diagram там делать нечего: сложна не столько структура, сколько процесс. Диаграмма вариантов использования не показывает условий ветвления, синхронизаций, передаваемых объектов, используемых ресурсов, временных факторов, событийной основы...

Есть ARIS вообще и eEPC в частности. IMHO лучше применять его (можно применять методологию и нотацию, а в качестве инструмента - хоть Visio).

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

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

интересная мысль. А может у тебя есть некий примерчик для визуализации сказанного?

Очень грубый пример БП:
1) Событие: пришёл заказ от клиента
2) Оператор бэк-офиса: проверить платёжеспособность и отправляет заказ поставщику; вход - невалидированный заказ, выход - валидированный заказ
3) Поставщик: выполнить заказ и доставить на склад; вход - валидированный заказ, выход - заказанный продукт, ресурс - склад
4) Оператор склада: учесть доставку заказанного продукта, передать складскую накладную оператору бэк-офиса; вход - заказанный продкут, выход - складская накладная
5) Оператор бэк-офиса: выписать счёт и счёт-фактуру, заказать доставку доставщику; вход - складская накладная, выход - счёт, счёт-фактура, заказ доставки
6) Доставщик доставляет заказ, клиент подтверждает доставку. Вход - заказанный продукт, заказ доставки, счёт, счёт-фактура. Выход - подписанный счёт-фактура. Ресурс - склад.
7) Клиент оплачивает счёт. Вход - счёт, выход - оплаченный счёт, платёж.

ERP-систему не внедряем, делаем АСУ склада. К большей части шагов бизнес-процесса наша система не будет иметь никакого отношения, что-то неявное и не слишком важное с точки зрения бизнес-процессов - уточним. И вообще, "контроль" нам неважен, а важен "информационный поток".
Поэтому из соответствующих шагов произойдут следующие варианты использования:
(2)=> Оператор бэк-офиса планирует доставку на склад
(3)=> Оператор склада учитывает доставку заказанного продукта; Оператор склада создаёт складскую накладную
(5)=> Оператор бэк-офиса планирует вывоз заказанного продукта со склада
(6)=> Оператор склада учитывает вывоз заказанного продукта со склада