Можно и так, в принципе.
Теперь, давайте подумаем о пользе. ВИ - это что-то приносящее пользу актору.
Разве приносит пользу выбор заказа покупателя сам по себе?
Разве есть польза в оформлении накладной?
Да и вообще, разве менеджер выбирает товар? Ведь покупатель уже сделал это.
Везде фигурирует счет на оплату, а сама оплата нет. Раз мы моделируем жизнь нашего менеджера, то где же деньги?
По BPMN - счет на оплату делает поставщик. Почему внезапно на ДВИ эта деятельность отнесена к менеджеру?

Давайте подумаем, а какие же полезные действия, в хронологическом порядке, совершают наши акторы? Т.е. действительно полезные, ради которых вообще стоит отрывать зад от дивана:)

Покупатель:
1. Делает заказ
2. Платит за заказ
3. Получает заказ

Менеджер:
1. Оформляет заказ поставщику на основе заказа покупателя
2. Оплачивает заказ поставщику
3. Получает товар от поставщика
4. Выставляет счет покупателю
5. Выдает товар

Поставщик: Он явно пассивный актор, никих ВИ он не инициирует.

Если бы я по этим вводным делал ВИ, то получилось бы примерно вот как во вложении. Здесь конечно много условностей, но надеюсь ход мыслей, как использовать диаграмму вариантов использования, будет понятен:)

Ух ты, я вообще в восторге! Как отлично Вы изобразили диаграмму вариантов использования.
Нас счет оплаты, я немного упустил. В данном примере есть ещё, я так предполагаю, что может принести пользу или нет:
Приходный кассовый орден – служит для учета зачислений наличных денежных средств. То есть оплата от поставщика.
Расходный кассовый ордер – назначен для учета выплаты наличных денежных средств из операционной кассы компании. То есть для оплаты поставщику.
Или не стоит их использовать?

Давайте подумаем, а какие же полезные действия, в хронологическом порядке, совершают наши акторы?

Боюсь, что попытки мало-мальски приблизиться к реальности в рассматриваемом нами примере выведут далеко за рамки возможностей форума. Жизнедеятельность такой вот "перепродай-конторы" значительно богаче. Сценариев будет больше и они сами будут другие.

Просто для примера (из жизни):

• Поставщик не будет суетиться из-за заказа какого-то покупателя на два спичечных коробка. Он поставляет тонны. Соответственно, ему интересны консолидированные заказы.
• Отдел продаж (и снова здравствуйте!) не только консолидирует заказы от своих менеджеров, но и на основании аналитики продаж и прогнозов поддерживает определенный уровень остатков номенклатуры на своих собственных складах. Ну, или этим (прогнозами) занимается отдел маркетинга.
• Процесс начинает крутиться еще до того, как поступила оплата от покупателя (особенно если речь о безнале).
• Логистика розницы (компоновка, доставка) - страшная штука со своей пачкой сценариев.
• Менеджер редко выдает товар лично, если речь идет о доставке.

...

Ну а в целях тренировки в рисовании картинок - какая разница, есть ли в действующих лицах "отдел продаж" и кто вообще выполняет доставку заказа?

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


Совершенно непонятно, что такое план проекта и зачем он нужен. Также непонятно, как связаны "товар" и "выполнение работ". Организация продаёт товары или оказывает какие-то услуги? Или диаграммы вообще относятся к разным организациям? По диаграмме восстановить это невозможно, конечно. У вас на входе только эти диаграммы, или есть какая-то словесная постановка задачи с пояснениями?

Боюсь, что попытки мало-мальски приблизиться к реальности в рассматриваемом нами примере выведут далеко за рамки возможностей форума. Жизнедеятельность такой вот "перепродай-конторы" значительно богаче. Сценариев будет больше и они сами будут другие.

Меня больше интересует Жизнедеятельность менеджера и его документов.

Конечно в конторах, в зависимости от их масштабов, сценарий будет разный. И команда будет больше. Но мне ещё до таких контор далеко. Начинать с маленького, а дальше и больше. Там уже и по конкретней описать. Охота, примерно диаграммы научится рисовать и логически рассуждать.

Примеры очень интересны, особенно когда это из жизни. Почитал бы ещё!

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


Совершенно непонятно, что такое план проекта и зачем он нужен. Также непонятно, как связаны "товар" и "выполнение работ". Организация продаёт товары или оказывает какие-то услуги? Или диаграммы вообще относятся к разным организациям? По диаграмме восстановить это невозможно, конечно. У вас на входе только эти диаграммы, или есть какая-то словесная постановка задачи с пояснениями?

Спасибо за замечания.
Действительно, лучше заменить на "утверждение". И звучит конкретней и понятней.
За названием “Отдел продаж” стоят несколько сотрудников: Начальник отдела продаж, замначальника отдела продаж.
План проекта это согласованный документ, включающий результаты планирования. Отвечающий на вопросы: кто покупатель? Кто исполнитель? Какие Сроки, Расходы, Риски?
Выполнение работ – получение инструкций и выполнение поставленной задачи. То есть, доставки товара.
Организация занимает оптовой торговлей.
Основная моя задача (больше ни каких указаний):
1) автоматизация  деятельности менеджера, то есть создать АРМ менеджера по продажам.
2) построение модели BPMN и UML проектной деятельности менеджера в оптовой торговле.

Приходный кассовый орден – служит для учета зачислений наличных денежных средств. То есть оплата от поставщика.
Расходный кассовый ордер – назначен для учета выплаты наличных денежных средств из операционной кассы компании. То есть для оплаты поставщику.
Или не стоит их использовать?

Использовать их стоит, но не в визуальной модели, т.к. все эти документы не являются самоцелью варианта использования, а в текстовом описании варианта использования. Ведь вы же не думали что диаграмма вариантов использования состоит только из веселых человечков и овалов?

Вообще, для описания реальной бизнес-деятельности "как есть", если не брать уже упомянутый BPMN, я бы использовал IDEF0. Но это, конечно, только мое предпочтение. Раз вам дали задачу делать в UML - делайте в UML:)

Если цель стоит описать (а создавать его будут разработчики) АРМ менеджера по продажам средствами UML, я бы рекомендовал вам пойти следующим путем:
1. Перенесите имеющиеся BPMN схемы в диаграмму последовательности.
2. По этой схеме определите все активности в которых участвует менеджер.
3. Из кучи активностей выберете те, которые можно автоматизировать (например, окажется что с "выполнением поставленной задачи" все неоднозначно, а доставка вообще в пролете)
4. Постройте диаграмму ВИ с описаниями основных и альтернативных потоков
5. На основании ДВИ можно уже сделать диаграмму классов. Хотя это и не обязательно.

Боюсь, что попытки мало-мальски приблизиться к реальности в рассматриваемом нами примере выведут далеко за рамки возможностей форума. Жизнедеятельность такой вот "перепродай-конторы" значительно богаче. Сценариев будет больше и они сами будут другие.

Полностью согласен:)

Вообще, для описания реальной бизнес-деятельности "как есть", если не брать уже упомянутый BPMN, я бы использовал IDEF0. Но это, конечно, только мое предпочтение. Раз вам дали задачу делать в UML - делайте в UML:)

В начале я пробовал использовать IDEF. Вот что из этого получилось...

В начале я пробовал использовать IDEF. Вот что из этого получилось...

Понятно:)

Понятно:)

Может Ужасно? Ну естественно надеюсь на ваши советы и замечания!
А вот что получилось с Диаграммой последовательности!

Основная моя задача (больше ни каких указаний):
1) автоматизация  деятельности менеджера, то есть создать АРМ менеджера по продажам.
2) построение модели BPMN и UML проектной деятельности менеджера в оптовой торговле.

Прээлестно! Прээлестно! (с)

При такой постановке идеальным решением будет АРМ менеджера, состоящий из мебели, телефона, принтера и компа с экселем и вордом. Этого хватит.

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

*

В такой печальной ситуации полезно было бы добыть материалы по остальным автоматизированным процессам и средствам их автоматизации. И уже смотреть, куда там вставить менеджера и что добавить/изменить в тех процессах.

В такой печальной ситуации полезно было бы добыть материалы по остальным автоматизированным процессам и средствам их автоматизации. И уже смотреть, куда там вставить менеджера и что добавить/изменить в тех процессах.

Что именно и где добыть?

А вот что получилось с Диаграммой последовательности!

Вижу что с предложением использовать диаграмму последовательности я поторопился:)
Но тут, пожалуй, моя вина. Для всей предполагаемой системы, диаграмма последовательности будет выглядеть слишком громоздкой. Обычно такую диаграмму делают для каждого варианта использования отдельно.

Но тем не менее, обратите внимание на компоненты этой диаграммы. У вас получается что система состоит из кучи интерфейсов (кружок с палкой слева), которые сами себя заполняют и оплачивают. При этом нет ни одного класса-контролера, который управлял бы событиями и ни одной сущности, которая хранила бы внутренние данные.
Здесь на сайте есть небольшая библиотека, используйте ее как справочный материал по нотации.
http://www.uml2.ru/books/5.-%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5/UML/

Предлагаю вам последовать совету Леонида и определить текущее программное окружение менеджера, чтобы понять что можно автоматизировать.
Другими словами, например, если у него есть только комп с экселем, то перед тем как автоматизировать обработку заказа покупателя, надо подумать над тем, как этот самый заказ попадает сейчас к менеджеру. И т.д.

Но тем не менее, обратите внимание на компоненты этой диаграммы. У вас получается что система состоит из кучи интерфейсов (кружок с палкой слева), которые сами себя заполняют и оплачивают. При этом нет ни одного класса-контролера, который управлял бы событиями и ни одной сущности, которая хранила бы внутренние данные.
Здесь на сайте есть небольшая библиотека, используйте ее как справочный материал по нотации.
http://www.uml2.ru/books/5.-%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5/UML/

Предлагаю вам последовать совету Леонида и определить текущее программное окружение менеджера, чтобы понять что можно автоматизировать.
Другими словами, например, если у него есть только комп с экселем, то перед тем как автоматизировать обработку заказа покупателя, надо подумать над тем, как этот самый заказ попадает сейчас к менеджеру. И т.д.

Спасибо за ссылку. Взял от туда материал, обязательно прочту сегодня.
В данный момент читаю:
Крэг Ларман - Применение UML 2.0 и шаблонов проектирования.
Программное окружение менеджера: 1С предприятие 8.2.

Что именно и где добыть?

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

Альтернативный путь (относительно простой и дешевый) - найти архитектора и допросить с пристрастием.