Вроде у меня все улеглось про ДВИ, масштаб (scope) и актеров в голове, но тут опять двадцать пять.

Пробла в следующем:
1. Есть некий БВИ - "Получить отчетность"
2. Есть его сценарий/реализация:
«Клиент» связывается с сотрудником «БО Банка».
Сотрудник «БО (бэк-офиса) Банка» идентифицирует «Клиента» по его полному ФИО и ключевому слову.
«Клиент» запрашивает отчет за указанный период у сотрудника «БО Банка» по определенному Счету. Список предоставляемых отчетов следующий:
•   Состояние Счета
•   Открытые позиции
•   Закрытые позиции
•   Margin Call
•   Транзакции по Счету
Сотрудник «БО Банка» запрашивает у Системы данный отчет, получает и сохраняет его.
Сотрудник «БО Банка» отправляет отчет по электронной почте
«Клиент» получает запрошенный отчет.

Так вот, я думаю/думал, что на БДВИ надо показать только одного актера - Клиента. А уже сотрудника "БО Банка" - это бизнес вокер (bussines worker), и он появляется только при реализации данного БВИ.

Юрий говорит, что нужно на БДВИ показать и сотрудника "БО Банка", т.к. это уже маштаб/scope - Система, но с точки зрения Бизнеса. Т.е. мы написали уже как сотрудника "БО Банка" взаимодействует с Системой, для нужд Клиента.

Так вот хотелось бы услышать мнения согласных/не согласных. И четкое описание Юрия по данному вопросу.

Оригинальная автоматизация, не лечь не встать:)
Как насчет банального запроса этого отчета при помощи е-маила? не говоря уже о web энде для клиентов банка?

Думаю можно и так и так. Смотря на что упор делать:
1. Отчет этот делать сотрудник может те только клиенту, но и контролирующим органам, и др. лицам. По запросу все это делает, запрос идет не через систему а через самого оператора.
2. Клиент имеет право работать с системой, например получать отчет по запросу. Запрос временно или по причинам безопасности\бюджета делается через другого актера (служащего банка, оператора). Отправка е-маила автоматическая и входит в систему. Если нет, то тогда клиент никак не завязан на систему, связь имхо просто с сотрудником. А сотрудник (оператор) может работать с системой.
Хотя я так понимаю мы бизнес модель делаем? Возможно такой подход не применим, и он чисто системный.

Вобшем первый вариант:
актер работник банка + показать взаимодействие с клиентом, и другими внешними просителями информации.

Второй вариант: Клиент актер, оператора как bussines worker

Жду комментов:)

Ну данный вопрос родился в принципе из того, что нужно нарисовать две модели БП - "as is" и "to be".

Т.е. в первом посте был БП "as is".

Вот что стало с "to be":
«Клиент» заходит на Интернет сайт Банка
«Клиент» авторизируется на Интернет сайте Банка
«Клиент» выбирает нужный ему отчет за период по определенному Счету из предлагаемого списка:
•   Состояние Счета
•   Открытые позиции
•   Закрытые позиции
•   Margin Call
•   Транзакции по Счету
Интернет сайт Банка отображает выбранный отчет
«Клиент» печатает или сохраняет отображенный отчет

Просто с "to be" все понятно, тут нужно просто показать актера - Клиента и все.

Вопрос родился в контексте того, что если на БДВИ "as is" мы показываем только одного актера - Клиента, что с моей т.з. правильно, то БДВИ "as is" и "to be" не будут отличаться, а будет отличаться только реализация данных БВИ.

Вобшем первый вариант:
актер работник банка + показать взаимодействие с клиентом, и другими внешними просителями информации.

Второй вариант: Клиент актер, оператора как bussines worker

Жду комментов:)

Первый вариент - это Системный ВИ получается, т.к. это уже как непосредственно сотрудник работает с Системой, а что там с Клиентом происходит, нам до фене.

Второй я как раз и предлагаю, но BW (бизнес вокер) не показывается на БДВИ, а показывается на Д реализации БВИ

Ну так тогда простой вопрос, бизнес модель меняется при переходе с "as is" к "to be"?
Отсюда и ответ как рисовать:)

П.С. А я уж думал что мы жили живем и будем жить в каменном веке:) ну в том смысле что ваш "as is" будет разрабатываемой системой. Был немного в шоке:)

Ну так тогда простой вопрос, бизнес модель меняется при переходе с "as is" к "to be"?
Отсюда и ответ как рисовать:)

Не обязательно. Так же как модель может не поменяться при переходе от БМ к СМ, сама модель может не поменяться, а реализация может/должна поменяться.
Тут надо исходить от другого - как правильно показать актеров на БМВИ "as is".

П.С. А я уж думал что мы жили живем и будем жить в каменном веке:) ну в том смысле что ваш "as is" будет разрабатываемой системой. Был немного в шоке:)

Я так и понял, поэтому пояснил

Ну вообщем-то я в RUP дуб дубом, так что не претендую на правоту и т.п.

Не обязательно. Так же как модель может не поменяться при переходе от БМ к СМ, сама модель может не поменяться, а реализация может/должна поменяться.
Тут надо исходить от другого - как правильно показать актеров на БМВИ "as is".

Я о БМ и говорю. Сравните Бизнес Модель которую вы делаете с той которая была.
Что-то поменялось? Актеры поменялись? Как по мне так да.
Значит и рисовать их нужно соответствующе...

Я о БМ и говорю. Сравните Бизнес Модель которую вы делаете с той которая была.
Что-то поменялось? Актеры поменялись? Как по мне так да.
Значит и рисовать их нужно соответствующе...

Так в том то и дело, что по моему мнению в "as is" сотрудник - это не актер на БДВИ, а бизнес вокер, который на БДВИ не показывается.

Мое обоснование такое:
Для БМ масштаб/scope - это организация (или отдел организации, смотря что мы моделируем). Поэтому мы НЕ показывает на БДВИ тех лиц, которые работают внутри организации, а эти люди - это бизнес вокеры, которые, по РУП, показываются на Д реализации БВИ или просто в спецификации БВИ. На БДВИ показываются только актеры, которые являются ВНЕШНИМИ сущностями по отношению к организации.

Юрий Булуй (возьмем его, как эксперта в этой области) говорит, что можно так и так. Так вот хотелось понять точно когда так, а когда иначе, именно применительно к БВИ "as is"

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

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

А у тебя Саша - ну нет никакого реального модифицирования бизнес-модели. Она была одна
клиент обращается с запросом и получает отчет. Что тут меняется? Ничего...

А значит и нет никакого ту би,

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

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

Саша. RYP процесс утверждает, а UML полагает, что Бизнес-модель есть совокупность двух моделей модель бизнес-процессов(ВИ) и модель бизнес-объектов.
1-ая есть внешнее представление о системе, фактически желания других в использовании системы
2-ая есть реализация этих ВИ и является внутренним представлением системы, т.е. Ви реализуется через взаимодействие бизнес-актеров, бизнес-вокеров и бизнес-сущностей, который в свою очередь могу дополняться моделями взаимодействия. Вот

Ну в общем мы с тобой на одном мнении стоим:
1. Бизнес Диаграмма ВИ не изменилась при переходе от "as is" к "to be", т.е. на ней мы показывает одного актера (Клиента) и один ВИ ("Получить отчетность")
2. Изменилась только реализация БВИ "Получить отчетность"

очевидно, так и есть

Что я хотел сказать ...
1. Мы можем отобразить Клерка как эктора на диаграмме, в том случае, если он является secondary actor, т.е. при условии, что Клиент и Клерк взаимодействуют через scope. Такая ситуация возможна при условии существования, например, системы где в одном или нескольких шагах юзкейса "мяч" оказывается на стороне Клерка (т.е. долежен сделать какие-то телодвижения в рамках сценария(ев)), чтобы Клиент мог продолжить выполнение сценария. В общем виде -- когда происходит взаимодействие двух (или более) разных сущностей, посредством того что в scope, в рамках конкретной цели.
2. У Коберна есть такая вещь как идентификация internal actor ... но он эту тему у себя не развивает сильно, просто декларирует, что да ... есть. В тексте юзкейса он их явно выделяет (именует). Это IMHO некий аналог бизнес-вокера в RUP. На диаграмме он этого не показывает ... известно как он относится к UC диаграммам :-). Но это не secondary actor! Можно ли в таком случае показывать его на диаграмме. По-умолчанию -- нет, но допускаю возможность если показать сего с определенным стереотипом :-), это не запрещено, но IMHO изврат.
3. Если выбросить из головы Коберна с его white и black boxes, и бизнес доменом и системным доменом ..., то на диаграмме BUC, будет только Клерк, и все. Разницу в б/п можно показать только на activity диаграммах, либо на реализации юзкейса

Юра, при всем к тебе уважении, ну прочитай еще раз свой текст. Если честно, ты сам себе противоречишь. С одной стороны рассуждаешь о возможности присутствия на диаграмме Клерка в роли второстепенного члена, но не исполнителя. А в конце концов делаешь вывод: на диаграмме BUC будет только Клерк. Это как понимать? Неужели весь этот процесс затевается лишь для того, чтобы Клерк мог сделать свои телодвижения? Кто такой клерк? это работник банка, КАдры решают все! Согласен, но ... вспомним будущее.. вместо клерка сидит робот-человек, как тут?

Думаю все-таки надо разделять это, а не "класть яйца в одну корзину" (с).
Думаю второстепенные члены или роли, это все-таки не те кто исполняют ВИ, а те кто могут в нем участвовать опосредственно, или явно, но которые нам сейчас особо не важны. Но влияние которых учесть хотелось... Например в том же UC Формировать отчетность, можно предусмотреть доставку отчетов через курьера, где курьер сторонняя фирма.