Файл: Разработка модели автоматизированной системы «Аптека №73».pdf

Рисунок 16 – Диаграмма действий менеджера группы планирования и маркетинга

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

• Ввод в систему прайс-листов поставщиков (операция № 3)
• Анализ предложений поставщиков (операция № 4)
• Выбор поставщиков (операция № 5)
• Формирование графика поставок без указания количества (операция №6)

1. Соединим действия менеджера отдела закупок стрелками аналогично описанию, приведенному в п. 12.
2. Поставим в соответствие действиям менеджера отдела закупок документы, формируемые в системе. В данном случае это прайс-листы и контракты, список поставщиков с расстановкой приоритетов, график поставок. Выполним работу по рисованию диаграммы в соответствии с описанием в п. 15-16.
3. После формирования менеджером отдела закупок графика поставок в работу включается менеджер группы логистики.
4. На диаграмме отобразим следующие действия менеджера группы логистики:

• Расчет необходимого количества закупок (операция № 7);
• Формирование заказов поставщикам (операция № 8);
• Расчет затрат на сертификацию импортных товаров, если медикаменты импортные) (операция № 9);
• Проверка суммы затрат на сертификацию на непревышение внутрифирменной нормы);
• Формирование заказов поставщикам при превышении затрат на сертификацию (операция № 10);
• Подпись заказа (операция № 11);
• Направление заказа менеджеру отдела закупок (операция № 12).

1. Изучая общее описание бизнес-процесса, обратим внимание на то, что менеджер группы логистики дважды производит проверку условий и в зависимости от результата выполняет то или иное действие.
2. Покажем действие "Расчет необходимого количества закупок" и опустите стрелку вниз.
3. Ввиду того, что формирование заказов поставщикам может происходить неоднократно при превышении затрат на сертификацию, предусмотрите эту ситуацию и используйте графику для объединения параллельных потоков (Transition|Join).
4. Покажем действие "Формирование заказов поставщикам" после символа объединения потоков.
5. Покажем ромб-символ проверки условия . Проведите из него две стрелки и надпишите их "Импорт", "Россия".
6. Стрелку "Россия" направьте к операции № 11 "Подпись заказа".
7. По направлению стрелки "Импорт" диаграммируйте последовательно два действия "Расчет затрат на сертификацию импортных товаров", "Проверка суммы затрат на сертификацию на непревышение внутрифирменной нормы".
8. За операцией "Проверка суммы затрат на сертификацию на непревышение внутрифирменной нормы" вновь отобразите ромб-символ проверки условия . Проведите из него две стрелки и надпишите их "больше х%", "меньше х%". Здесь х% - норма затрат на сертификацию.
9. Стрелку с надписью "больше х%" соедините с операцией № 8 "Формирование заказов поставщикам" через символ объединения потоков.
10. Стрелку с надписью "меньше х%" направьте к операции № 11 "Подпись заказа".
11. Поскольку к операции № 11 "Подпись заказа" направлено два потока действий (п. 29 и п. 33), воспользуемся обозначением объединения независимых (параллельных) потоков (Transition|Join). В операцию №11 "Подпись заказа", как и в любую другую, должна входить только одна стрелка. Для выполнения этого правила и используем символ объединения потоков.
12. Поставим в соответствие операции "Подпись заказа" документ - акцептованный заказ поставщику аналогично тому, как написано в п. 15-16.
13. В качестве следующей операции покажем операцию № 12 "Направление заказа менеджеру отдела закупок". На этом действия, выполняемые менеджером группы логистики, завершаются. Вновь работа переключается на менеджера отдела закупок, поэтому направьте стрелку от 12 операции в поле действий менеджера закупок.
14. Отобразим на диаграмме переход документа "Заказ поставщику" от менеджера группы логистики к менеджеру отдела закупок. Для этого сначала поставим в соответствие операции № 12 "Направление заказа менеджеру отдела закупок" документ "Заказ поставщику" так, как это описано в п. 15-16. После этого изображение документа с надписью "Заказ поставщику" путем копирования разместите в поле действий менеджера отдела закупок. Затем направим пунктирную стрелку (Object Flow) между двумя отображениями документа "Заказ поставщику" в направлении поля действий менеджера отдела закупок.
15. Соединим операцию № 12 "Направление заказа менеджеру отдела закупок" с операцией № 13 "Направление заказа поставщику", выполняемой менеджером отдела закупок. Это последняя операция в соответствии с заданием.
16. Укажим на диаграмме конец процесса. Для этого используем символ (Final State). Соедините стрелкой операцию № 13 "Направление заказа поставщику" с символом Final State.

Рисунок 15 – Диаграмма действий бизнес-процесса «Планирование закупок, формирование заказов поставщикам»

Заключение

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

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

Мы просмотрели понятие, историю создания и применение языка UML, как универсальное средство моделирования проектных решений. Выявили множество UML-диаграмм и назвали 7 самых основных и чаще используемых в проектировании диаграмм, таких как диаграмма классов, диаграмма коммуникаций, диаграмм прецедентов и т.д.

Несмотря на мощные и продвинутые во всех отношениях специализированные инструменты, некоторые разработчики считают UML чересчур сложной технологией. В общем-то, для мелких проектов её применение действительно может быть и не лучшим из всех возможных вариантов, поскольку для них чаще легче сразу написать код. UML действительно трудно применять, предварительно в нём не разобравшись, а потому делать так чревато всякими осложнениями в процессе разработки. Ну и уж совсем не стоит пытаться применять UML в проектах, которые пишутся не на объектно-ориентированных языках. Тем не менее, в большинстве случаев UML всё же очень и очень полезен. Он позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы, и при этом диаграммы UML более просты для чтения и изменения, нежели готовый код, пластичность которого, как известно, низка и чревата багами. Богатый инструментарий позволяет выбрать то, что наилучшим образом подходит для конкретного проекта. А поддержка со стороны гигантов индустрии гарантирует, что перспективы у UML есть.

На примере ОАО «Аптека № 73» показали диаграмму прецедентов и спроектировали диаграмму действий бизнес-процесса «Планирование закупок, формирование заказов поставщикам».