Уважаемые аналитики. Бизнес-аналитики, системные аналитики. Опытные аналитики и только начинающие. Срочно, просто срочно требуется внятная консультация.

Многие меня на форуме знают. Я не новичок в целом. Но все равно пока не могу "сшить" одно с другим. Прежде чем задать вопрос некоторые мыли по поводу понимания самого процесса RUP и использования ООАП.

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

Бизнес-моделирования какрезультат должно привести к построению как минимум двух моделей: модели бизнес-вариантов использования и модели бизнес-объектов. Модель бизнес-объектов - задает, определяет статическую структуру бизнес-систему, модель вариантов использования - поведение системы. Бизнес варианты-использования обычно сводят до уровня пользователя такой бизнес-системы: внешние действующие лица, ради которых собственно и работает бизнес, производит некоторую ценность. Внешние действующие лица часто являются участниками, инициаторами, источниками и потребителями бизнес-процессов системы. Очевидно у бизнес-системы могут быть один или несколько основных бизнес-процессов, куча вспомогательных. Каждый такой бизнес-процесс, выделенный и очерченный в ходе анализа, является отличным кандидатом на подсистему в будущей системе, которую мы захотим построить. естественно IT-специалиста в первую очередь интересует информационная составляющая таких процессов.
Бизнес-вариант использования может быть детализирован диаграммой деятельности или диаграммой последовательности. Отдельная деятельность может стать хорошим кандидатом на системный вариант использования.
Т.е. в RUP на мой взгляд прослеживается такой переход от БМ к модели системной:
1.Внешнее действующее лицо трансформируется либо в основное действующее лицо(пользователя системы) либо становится третьестепенным(закулисным)либо становится классом-сущностью системы
2.Бизнес-вариант использования становится подсистемой системы или остается вариантом использования системы
3.Деятельность может стать отдельным вариантом использования системы
4. Бизнес-имсполнитель превращается в основное действующее лицо системы(пользователя системы) или превращается в управляющую автоматическую структуру.
Это, конечно , рекомендации, а не руководства к действию. Но в целом мне кажется вполне логичным

Однако-таки есть червячок сомнение, этакая вольная интерпетация того, чего может я не понимаю на самом деле.

Хотелось бы предложить некоторую практическую задачу, для анализа и устранения ошибок.

Задача чисто вымышленная.
Предположим мы с вами организовали небольшой бизнес: скажем маленькое студентческое кафе (такое я видел в Португалии в их техническом универститете): 10 столиков, а то и того меньше, по 4 человека за столик. Относительно разнообразное меню: закуски, вторые блюда, первые блюда, выпечка, десерты, напитки. Пусть для простоты и опрделенности сделаем как это было в Португалии: каждый день кафе анонсирует пять блюд: обычно это рыба в сочетании с разным гарниром и 1-2 блюда с мясом: - это основные блюда. Есть еще супы, но они не анонсируются.
Естественно у нас есть повар с помощниками, кассир, директор, бухгалтер, закупщик продуктов. Это роли. Штат значение не имеет.
Основным бизнес-процессом будет обслуживание клиента, нужно также организовать закупку свежих продуктов, приготовить блюда, решать разные оргвопросы.

Какие проблемы возникают и зачем нам строить информационную систему? Ну скажем нужно знать какова средняя интенсивность обслуживания, какое количество продуктов требуется на день, какова выручка, что следует сдлеать чтобы увеличивать прибыль и поддерживать качество обедов и обслуживания. Очевидно для ответа на эти и другие вопросы нам нужна информация. Чобы получить ее нужна ежедневная регистрация данных: сколько каких продуктов купили, сколько народу посетило кафе, какие блюда пользуются спросом, какие цены выставлять, и т.п.

Начинаем строить контекст, используя инструментраий UML.

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

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

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

БП1: Накормить клиента
1. Клиент изучает меню.
2. Клиент выбирает блюда.
3. Продавец-официант выдает заказанные блюда
4. Кассир расчитывает сумму и выбивает чек
5. Клиент расплачивается разрешенным способом(наличными или кредитной картой)
6. Клиент есть свой обед
7. Клиент относит посуду.

БП3: Закупить продукты (доставит продукты??)
1. повар планирует меню следующего дня
2. Повар составляет реестр необходимых продуктов
3. Закупщик закупает продукты у поставщика(в магазине, оптовой базе)
4. Поставщик выдает накладную (счет-фактуру)
5. Закупщик доставляет продукты в кафе
6. Бухгалтер оформляет поступление продуктов

Останавлюсь пока на этом, поскольку чувствую что-то не совсем так....

Однако скажем посел построения БМ - я перейду к системе:
Очевидно - пользователями будут кассир, бухгалтер, повар, закупщик??
а варианты использования будем рассматриватьс точки зрения уже их:
Кассир: рассчитать клиента
Повар: составить реестр продуктов, составить меню
Закупщик: составить заказ
Бухгалтер: Оприходывать продукты, Рассчитать арендную плату, что-то еще?
Директор: провести инвентаризацию....

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

Развитие идеи. Сегодня сидел со воей коллегой 4 часа. Интенсивно обсуждали вопрос моделирования и вот к чему пришли. Прошу судить, делать замечания, ругать и хвалить...

Итак, рассматривается бизнес: Студенческое кафе.
Попытаюсь описать возможные функции. Поскольку бизнес придуманный, то естественно вводятся определенные ограничения


1. Обслужить посетителя. Участники: посетитель, официант, кассир, уборщик
Посетитель садится на свободное место, изучает меню. Официант принимает заказ, идет на кухню, получает заказ, приносит заказ и квитанцию заказа. Посетитель ест, по завершению трапезы идет к кассиру и дает ему квитанцию заказа(список заказаных блюд). Кассир подсчитывает сумму, принимает деньги посетителя, выдает сдачу и чек. Уборщик убирает посуду, протерает стол.

2. Составить меню. Участники: Повар
Повар составляет меню блюд. Блюда деляться на первые, вторые, салаты, десерт, напитки, выпечка.

3. Составить калькуляцию блюд. Участники: менеджер.
На основании меню, менеджер составляет калькуляцию каждого блюда.

4. Анализировать потребности в продуктах. Участники: менеджер.
Используя калькуляцию блюд, зная средние потребности в продуктах менеждер составляет заказ на закупку продуктов.

5. Закупать продукты. Участники: Закупщик, оптовая база, столовая.
Закупщик на основании заказа на продукты закупает продукты и полуфабрикаты в оптовой базе. Получает деньги у бухгалтера на закупку продуктов. Оптовая база выдает продукты, составляет счет-фактуру (или другой документ). Закупщик доставляет продукты в кафе. Сгружает продукты, отдает бухгалтеру накладную на закупленные продукты.
Выпечка закупается в столовой, с которой есть договор.
Доставку осуществляет закупщик транспортом кафе.

6. Готовить блюда (кухня). Участник: Повар, Помощники повара.
Повар с помощниками согласно меню, калькуляции блюд и средней потребности готовит блюда (первые, вторые, салаты, десерты, горячие напитки(чай, кофе))

7. Предоставлять отчеты и выплаты. Менеджер,Бухгалтер
Менеджер составляет отчеты руководству вуза (где располагается кафе), в налоговые органы.
Бухгалтер рассчитывает выручку, начисляет налоги, фиксирует затраты, начисляет и выплачивает зарплату, выдает деньги на закупку.

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

Вот что получается:

Обслужить посетителя - думаю тут довольно ясно прописан основной ход действия.
Я ограничиваюсь тем, что кафе ориентировано на несложные, но качественные блюда. Количество посадочных мест скажем 5 столиков по 4 человека. Средняя продолжительность пребывания полчаса.
В обслуживание можно добавить отдельным ВИ - скажем обеспечивать торжественные заказы: свадьбы, вечеринки
но думаю для нашего студенческого кафе можно и не рассматривать, если полагать, что кафе располагетсяв учебном корпусе (тут лекции идут а в кафе гулянка:)) Тем более, что горячительные напитки мы исключаем

Закупать продукты - возможно имеет смысл разбить на
Закупать продукты в оптовой базе (закупается все, кроме выпечки) Закупка производится скажем для простоты в одной оптовой базе.
Закупать выпечку - закупается в столовой

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

Не стал рассматривать деятельность по рекламе, улучшению имиджа кафе, дизайн и прочее.

Решением может быть например - автоматизация регистрации, выполнения и оплаты заказа (скажем проблема более быстрого рассчета посетителей, проблема ухода посетителей без оплаты)
Можно напридумывать что-то типа:
Официант принимает заказа. Вводит заказ на терминале. Получает фишку с кодом. Приносит заказ и фишку посетителю. Посетитель отобедав, идет к кассиру, подает фишку. Кассир кидает фишку в некое устройство. устройство считывает код, отображает заказа клиента с подчетом итоговой суммы. Клиент расплачивается, получает чек и сдачу. Кассир закрывате заказ - делает его проведенным

Дома хорошенько подумаю. А пока ремарка, чистое IMHO.
1) Важно понимать, что бизнес-процессы связаны между собой.
Например, прямая связь закупка продуктов - обслуживание посетителя: предоставляет продукты, обратная связь - предоставляет материалы для корректировки и планирования.
Обслуживание потребителя и закупка продуктов предоставляют материалы для расчёта налоговых выплат и средства для их произведения.
2) Владельцы процессов всегда пересекаются, иначе нет основания объединять варианты использования в одни рамки системы (в данном случае - не IT-системы, а системы гораздо важнее - производственной!). Посетителя обслуживает столовая. У оптовой базы материалы также обслуживает столовая. Столовая платит налоги, администрация ВУЗа выступает гарантом. (Кстати, что раньше по логике вещей? Порядок важен.)
3) Отчёты и выплаты по налоговому учёту и закупка продуктов - обеспечивающие БП.

Не думай сразу про автоматизацию: вся IT является мелочью по сравнению с получением прибавочной стоимости, её получали до IT и будут производить после .

Попробуй сделать что-нибудь невымышленное. Умозрительный эксперимент - это хорошо, но его результаты нельзя проверить. Чем часами ломать копья - расспроси лучше знакомого официанта или повара о том, как всё устроено.

Попробуй сделать что-нибудь невымышленное. Умозрительный эксперимент - это хорошо, но его результаты нельзя проверить. Чем часами ломать копья - расспроси лучше знакомого официанта или повара о том, как всё устроено.

Спасибо Саша. Очень хорошо обсказал по взаимосвязи. Я ее конечно вижу и чувствую. UML такую свзяь явно не дает. Долой UML - все верно. Бери то, что лучше отражает семантику.
Однако стоп, вся идея состоит вот в чем.

Я хочу дать некие темы для организации бизнеса и только. Пусть народ сам подумает, придумает. Хотите узнать лучше - иди к знакомому официанту (кстати ну нет у меня знакомых официантов), однако многие из нас не раз бывали в столовых, кафе, закусочных, ресторанах. Не важно. пусть придумают то, что придумали. и действуют в рамках придуманного.
Если я дам им свою придуманную задачу - будет кавардак, дать реальную задачу - невозможно в рамках курса. Можно только индивидуально на курсовой, дипломе, когда человек действительно будет что-то делать не для вымышленной истории. А тут игра.
Цель не придумать супер-пупер корректный бизнес, который в реальности принесет прибыль, будет доходным и прочее. Просто пусть придумают хоть что-то. Думаю команда из 5-7 человек, основываясь на совем опыте, опыте друзей, знакомых и прочая, могут что-то придумать, что-то понятное им. Моя задача держаться в рамках этого придуманного, не вылезти в дикую фантазию.
В целом мы в какой-то степени делаем что-то наоборот, ну и что, пусть появится опыт.
Когда я постил первый пост - был в ужасе о каши в голове. Сейчас немного прояснилось после 4-часовой дискусии, мозгового штурма. Мы никакю идею не откидывали, все клали в кучу.
Например: наше кафе будет само готовить или брать готовые блюда в столовой, ресторане, магазине, а потом просто их расскладывать, подогревать и т.п. Пожалуйста рассмотрим и выберим тот вариант, что нам по душе.
Как обслуживание идет? Просто выбираемна выдаче блюда, ставим на поднос, расплачиваемся, кушаем. Или как описал я? А может совершенно по другому? Не важно - ты придумал, ты и обоснуй, даже вернее не обоснуй, а держишь в этих рамках. Раз уж придумал, что оплачиваешь после, так и в товей модели не должно быть противного.

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

У меня нет цели рассказыать все о РУП процессе или пройти с ними весь UML в тонкостях. Нет у меня ресурсов времени на это, потому довольствуюсь малым. Мы пока не проектируем, мы пока уясняем, а что нам нужно: концепция + часть логики.

У них уже есть некоторый опыт моделирвания втехнологии SADT, пусть сравнят.

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

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

Хотя в лекциях хочу рассказать сути БП их видах и прочее. если у тебя есть материальчик в доступной и четкой (без лишней воды) форме, дай буду просто признателен..

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

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

Я таки-надеюсь выбить для вуза лицензию на EA, там ведь есть бизнес-процессы. Думаю то, что ты написал лучше описывать с помощью eEPC (так вроде пишется). Но мне надо изучить это самому - а потом лезть в омут:-))
Может мне удасться гармонично связать в будущем Теорию информационных процессов и систем с курсом ОО моделирование  и лекции, и практику.

В любом случае, ответственность за мной. Ни с кем из вас я ее разделить не смогу, стыдно будет мне одному. Но и это не важно, главное дать знания, пусть 5 %. Уже хорошо. А главное конечно понять самому...

Не думай сразу про автоматизацию: вся IT является мелочью по сравнению с получением прибавочной стоимости, её получали до IT и будут производить после

Конечно, ты прав. Сегодня IT, завтра телепатия или магия. Все преходяще.
Но повторю, я не ЭКОНОМИСТ, я не учу ЧТО ТАКОЕ БИЗНЕС, конечно приходится это учитывать, но лишь в контексте как раз вот этой самой IT.

Если по сути то все вроде нормально.

Есть несколько ремарок:
1. ВИ "Обслужить посетителя", должен называться подругому, т.к. название ВИ должно нести хоть какую-то цель его актеру. Н-р, можно назвать - "Покушать" или как-то еще.
2. Все процессы, которые ты указал, можно показать на ДВИ реализации, т.е., н-р, ВИ "Покушать" реализиуется с помощью ВИР "Приготовить пищу", "Сделать меню" и т.д.
3. Связи м/у ВИ, т.е. м/у БП, можно указать в Бизнес Правилах.

З.Ы. Народ опять же будет спрашивать: а цель какая у тя при моделировании БП? Я думаю тут можно ограничиться двумя: очертить границы системы и понять контекст работы производста. Возможно, есть и более лучшие способы описать БП, чем это делать с помощью ЮМЛ, но Эдуард, хочет выстроить полную цепочку моделирования именно с помощью ЮМЛ.

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

Далее есть-таки одна книга, которая довольно хорошо дает свЯзь всех моментов моделирования и проектирования. Потому я в некоторой степени руковдствуюсь ею. Однако к сожаления и в этой книги очень важные детали на мой взгляд скрыты. Например в книге говорится что на основании анализа нами выделено около 30-40 прецедентов, после их изучения мы некоторые отбросили, другие заменили, третьи не соотвествуют нашей задаче, в результате оставили только во эти, что показаны на диаграмме.

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

Далее идет более детальное представление. И опять в терминах скорее цели не пациента.

Почему? Я думаю потому как пациент - третьестепенное лицо, возможный триггер, имеющий интерес.

Хотя именно по этому я и задал в посте вопросы, связанные с этим моделированием.

Это исключительно ответ на первый пост. Остальное надо обдумать... так что, наверное, продолжение следует...
У меня постоянно складывается впечатление, что за проблему бкрутся не с той стороны.

Сережа! Именно, потому и спрашиваю. Знал бы прикуп,жил бы в Сочи(с). :-)

Теперь от том, что ты написал! Великолепно - просто замечательная постановка вопросов. Буду брать на вооружение. Пошла конкретная помощь практикующего аналитика.

Теперь оправдания: Взять готовый бизнес - дело неперспективное. Потому я и предлагаю студентам в течение 2 недель в группе из нескольких человек придумать этот бизнес самим.

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

После этого мы выясняем детали всех имеющихся в модели сценариев и там выясняется, что нужна ежедневная регистрация данных и т.д. и т.п
Только после этого в моей модели появятся ВИ "Обслужить клиента", а может и вовсе не появится.
Они там появятся исключительно по ниточкам, пришедшим от основных проблем "Унать ЧТОТОТАМ"

Сережа, но есть же очевидные вещи. Кафе - это СМО, сегодня густо, завтра пусто.

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

Сергей, я понимаю лишь то, что мы друг друга не понимаем и вероятно никогда не поймем. Мотивации нет, нет совместных проектов.
Я обращаюсь с конкретной просьбой, вопросом, советом. А мне в ответ ушат слов - понять, которые не всегда возможно. Ты порой пишешь, вероятно держа в голове, кучу всяких понятных тебе понятий, но я их не знаю.
Исходи из того, что перед тобой ученик, студент.

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

2 Boatman,

Ну предположим, что проблемы все мы выснили и поняли, что надо провести БМ части БП, которые описал Эдуард. Просто если еще студента начать грузить проблемами, да еще их выяснять, он никогда задание не сделает.

Кстати, есть хорошая книга, которая как раз рассказывает как докапаться до корневой проблемы, перейти от проблем к БМ, от БМ к СМ, от СМ к требованиям и т.д. и т.п., но она на англ. языке:
http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=64

При придумывании бизнеса, допустим, маркетинговую и балансовую часть бизнес-плана мы опускаем. Остается часть с описанием бизнеса - пакет регламентов или что-то подобное, можно в виде модели. НО ПРИЧЕМ ТУТ АВТОМАТИЗАЦИЯ?
Если вы проектируете автоматизированный бизнес, то система автоматизации уже закладывается в него, как любой другой инструмент и особое внимание ей не требуется.
Основанием для разработки системы автоматизации является концепция с готовым описанием объекта автоматизации (бизнес-процессов)

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

Давайте используя описанный бизнес сформулируем проблемы. Пусть они будут надуманы, несовсем очевидные, но определенные.

Берем тоже кафе: ты уже выписал ряд определенных проблем.

1. Проблема - трудно, сложно создавать план закупок продуктов на день. Информация по расходам продуктов есть, но она колеблится день ото дня, сложно быстро подготовить или быстро сорректировать план. Людей в кафе немного, каждый совмещает множество обязаностей. Взять на работу лишнего человека не по карману. Есть проблема иногда перерасхода продуктов (особенно опасно скоропортящиеся, выпечка), а иногда недобор продуктов, приходится докупать, отвлекать персонал, создаются проблемы в быстром и качественном обслуживании посетителей
Кого касается: менеджер, посетитель, директор, столовая, оптовая база (поправьте если я ошибаюсь, а ошибка кажется есть)
Результат: повышаются издержки на закупку лишних продуктов или их порчи при недоиспользовании, посетитель вынужден уйти недождавшись заказа (из-за отсутвия нужных продуктов для приготовления блюд или из-за необходимости ждать когда блюдо будет приготовлено)
Выгода от решения: снимит издержки при закупках, позволит быстро подготавливать заказ на закупку, поможет четко контролировать требуемые запасы

Пока остановимся на этом. Сначала "обсосем"(Boatman) - это. что правильно, что не правильно.

Сергей, искренное спасибо за помощь. Восхищаюсь мужеством, терпением и тактом, а также содержательностью ответа и самопожертвованием твоим при его создании.

Многое становится яснее. По поводу целей и проблем и так ненависного тебе и "т.п.". Не сомневайся это и "т.п." я ввожу только в посте. Не будет "и т.п." у студентов, не будет множества проблем и целей. Каждый (или каждая пара) возьмет и будет рассматривать свою проблему, моя задача как преподавателя помочь им ее выделить и сформулировать.

Общую концепцию подхода я понял. Но одного не понял все-таки.

Все авторитеты использования UML (в частности в RUP) говорят, на диаграмме BUC должны присутствовать только внешние к бизнесу актеры, инетересы и цели которых наш бизнес удовлетворяет. На твоих диаграммах  мы видим главным образом именно бизнес-исполнителей, а не бизнес-актеров. И в этом трудность понимания. Опять же следуя авторитетам бизнес-исполнители появляются на диаграмме деятельности, диаграмме бизнес объектов (реализация BUC) и диаграмме последовательностей. Переход к системным ВИ происходит из модели бизнес-объектов.
На твоих рисунках строится диаграмма с точки зрения исполнителей, чем тогда будет отличатся бизнес-модель от системной модели вариантов использования?

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

Кажется начинает что-то проясняться.
И вот что я подумал. Если мы рассматриваем бизнес как прозрачный ящик, описываем возможные BUC, то может изображать не саму диаграмму BUC, а диаграмму деятельности.
Или по другому, имеет смысл изображать и то, и другое?

Например, у Шмуллера при описании ресторанного бизнеса я увидел такой подход:
1. Интервью с администратором
2. Рисование диаграммы деятельности на его основе (там основной процеес именно обслуживание клиента)
3. Формирование диаграммы классов
4. Выделение ролей и определение для них вариантов использования

Я привел это лишь для примера

Вообще для ответа, что рисовать, надо бы разобрать несколько примеров на чртение диаграмм.
Вот каr бы ты, Эдуард, прочитал последнюю диаграмму в этом посте?

Клиент обращается в ЗАО "Рога и копыта", чтобы Получить обслуживание. В ходе обслуживания Продавец с помощью Кассового аппарата Пробивает чек.
Директор забирает дневную выручку у Продавца (вероятно в конце рабочего дня). Директор Узнает дневную выручку (Может узнает количество дневных посещений). Директор для чего-то Узнает среднюю интенсивность обслуживания в месяц. Директор Вычисляет интенсивность обслуживания в месяц, вероятно в конце месяца, чтобы потом ее когда-то узнать или что-то предпринять на базе этой информации :-)