Главная страница

Моделирование бизнеспроцессов организации. Диаграммы прецедентов


Скачать 1.85 Mb.
НазваниеМоделирование бизнеспроцессов организации. Диаграммы прецедентов
Дата26.04.2023
Размер1.85 Mb.
Формат файлаdocx
Имя файлаLR_10 (1).docx
ТипЛабораторная работа
#1091826

Лабораторная работа №10
Тема: МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ ОРГАНИЗАЦИИ. ДИАГРАММЫ ПРЕЦЕДЕНТОВ
Краткие теоретические сведения
1. Информационная система и ERP-система
Вспомним, что такое информационная система? Существует множество определений этого термина, но если все не усложнять, то в качестве общего определения можно использовать такое: информационная система (ИС) – это программно-аппаратная система, предназначенная для хранения, обработки, поиска, распространения, передачи и предоставления информации.

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

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

Информационные системы бывают разные, но все они предназначены для решения определенного круга задач. Тут уместно задать вопрос: является ли информационной системой MicrosoftExcel? А MicrosoftAccess? И ответом будет НЕТ. Конечно, есть скупые определения, гласящие, что Excel – это табличный процессор (средство для работы с электронными таблицами), а Access – система управления базами данных (СУБД), а никакие не информационные системы. Но если подумать, становится понятно, что сами по себе ни Excel, ни Access никаких задач автоматизации человеческой деятельности решить не в состоянии. Почему? Ну, вот запустим мы Excel – увидим пустую таблицу. Запустим Access – увидим даже не базу данных, а пустоту – ни таблиц, ни запросов, ничего. Поэтому эти программные средства можно рассматривать как инструменты разработки ИС. С их помощью можно создавать информационные системы, пусть простые, с ограниченными возможностями, но вполне способные автоматизировать какие-то задачи, хранить данные, осуществлять их поиск, обработку и т.п. Информационная система – это готовый продукт, способный сразу решать какие-то задачи прикладного характера.
И здесь мы подходим к такому классу ИС, как ERP-системы. Есть простое определение, передающее самую суть: ERP-система – это информационная система, которая позволяет хранить и обрабатывать большинство критически важных для работы компании данных. Критически важные данные – такие данные, без которых компания не может функционировать. Большинство – потому что абсолютно все данные собирать и хранить в ИС невозможно, их слишком много.

В чем отличие ERP-системы от информационной системы? ERP – понятие более узкое, это разновидность ИС, предназначенная именно для автоматизации бизнес-процессов компании. ИС ведь не обязательно служат для автоматизации бизнес-процессов; например, в России очень популярна справочно-правовая система «Консультант Плюс», которая является, по сути дела, базой данных российского законодательства – федеральных законов, кодексов, указов, приказов, судебных решений и т.п. нормативно-правовых актов. Это ИС, но, конечно, не ERP-система. Или ИС библиотеки, служащая для учета книг, журналов и т.д.; ИС для составления расписаний занятий в вузе – это все не ERP-системы, потому что автоматизируют какую-то одну, пусть и достаточно сложную сферу деятельности, но относящуюся не ко всей организации в целом, а к какому-то ее подразделению. И вот таких специфических ИС в компании может использоваться много (ИС бухгалтерии; ИСотдела кадров; ИС отдела информационных технологий, содержащая сведения о компьютерах, серверах, принтерах, учетных записях пользователей и т.п.). В то же время аббревиатураERPозначает «Enterprise Resource Planning, планирование ресурсов предприятия». Ведь что такое бизнес, что такое компания с т.з. управленца (менеджера)? Это некая совокупность ресурсов (кадровых, финансовых, материальных – помещения, оборудование, запасы, и т.д.). И для успешного ведения бизнеса этими ресурсами необходимо грамотно управлять, в чем и состоит задача менеджера. Так вот, ERP – это такая стратегия управления ресурсами компании, а ERP-система – информационная система, реализующая стратегию ERP. Поэтому ERP-система – это такая интегрированная ИС предприятия, автоматизирующая деятельность предприятия в целом, различные его бизнес-процессы.

Бизнес-процесс – это последовательность операций, направленных на решение одной из задач бизнеса. Из бизнес-процессов складывается деятельность организации. Например, к бизнес-процессам может относиться закупка сырья или продажа готовой продукции.

Насколько я понимаю, ERP-системой в ПГНИУ пытается стать ЕТИС – Единая ТелеИнформационная Система. На текущий момент в ЕТИС входят подсистемы для поддержки учебной, научной и библиотечной деятельности, составления расписаний, кадрового учета, внутреннего документооборота организации (и, возможно, чего-то еще). Однако, например, финансовый учет (бухгалтерский, налоговый учет, расчет зарплаты, стипендий), учет государственных закупок (которыми занимается контрактная служба университета) в ЕТИС не реализован, для этих целей в ПГНИУ используются другие ИС – в том числе различные конфигурации «1С:Предприятие».
2. Проектирование ИС. Унифицированный язык моделирования UML
Чтобы разработать ERP-систему (и информационную систему вообще), нужно выполнить множество шагов. Существуют различные классификации этапов разработки ИС, различные модели жизненного цикла ИС (каскадный, спиральный, …), но останавливаться на этих тонкостях в рамках лабораторных работ мы не будем.

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

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

Стоит отметить, что существуют два основных подхода к проектированию ИС:

1. Структурно-функциональный. Система представляется в виде иерархии (дерева) взаимосвязанных функций. На высшем уровне система представлена единым целым с наивысшей степенью абстракции; по мере детализации (добавления уровней) она разбивается на функциональные компоненты с более конкретным содержанием. Например, пусть есть фирма, производящая веники. На высшем уровне абстракции ее деятельность можно описать функцией с названием «Деятельность фирмы по производству веников». Углубляясь, можно произвести декомпозицию этой мегафункции на более конкретные подфункции: «Закупка сырья для веников», «Производство веников», «Сбыт веников». Затем эти функции можно детализировать еще сильнее, и т.д. Получится некое иерархическое (древовидное) представление функций компании. Т.е. первоосновой при проектировании (тем, от чего, так сказать, «пляшем») является функция (какие именно задачи решает система и ее подсистемы).

2. Объектно-ориентированный.В рамках этого подхода система разбивается на набор объектов, соответствующих объектам реального мира, взаимодействующих между собой. Первоосновой является не функция, а объект, обладающий какими-то свойствами, характеристиками и выполняющий некоторые функции.
Соответственно, существуют различные методологии моделирования бизнес-процессов, основанные на том или ином подходе. К структурно-функциональным методологиям относится, например, IDEF (Integrated Definition for Function Modeling). Ярким представителем объектно-ориентированного подхода является методология RUP (Rational Unified Process), предполагающая использование в качестве средства формализации бизнес-процессов язык UML.

UML (Unified Modeling Language– унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

Средства языка UML включают в себя несколько видов диаграмм, позволяющих описывать проектируемую систему (предметную область, бизнес-процессы – в общем, описывать то, что мы анализируем) с разных точек зрения. К основным из них относятся:

  • диаграммы прецедентов (вариантов использования, сценариев) (Use Case Diagram)

  • диаграммы действий (активностей) (Activity Diagram)

  • диаграммы состояний (Statechart Diagram)

  • диаграммы классов (Class Diagram)

  • диаграммы последовательности (Sequence Diagram)

  • диаграммы кооперации (Collaboration Diagram)

  • диаграммы компонентов(Component Diagram).

При моделировании бизнес-процессов обычно используются первые 2 вида (диаграммы прецедентов и действий). Другие диаграммы полезны на более глубоких уровнях проектирования ИС и используются разработчиками ИС (IT-специалистами).

Также стоит отметить, что бывают модели «как есть» (AS-IS), описывающие бизнес-процессы в том виде, в каком они существуют, и модели «как должно быть» (TO-BE), описывающие бизнес-процессы в их желаемом виде, т.е. с учетом автоматизации, внедрения ИС. Как правило, по результатам анализа бизнес-процессов компании строится модель «как есть», выявляются ее недостатки, затем с учетом этих недостатков формируется модель «как должно быть». Мы сразу будем моделировать желаемое состояние вещей – «как должно быть».
3. Диаграммы прецедентов (UseCaseDiagram)
Для диаграмм прецедентов основной акцент в рассмотрении бизнес-процессов делается на бизнес-задачах, порядке их решения, а также на их исполнителях и участниках. Диаграмма прецедентов – это наиболее общая, абстрактная модель бизнес-процессов, которая указывает на то, какие задачи решаются и кто в их решении участвует, но не указывает, как конкретно это происходит.
Основные элементы диаграммы прецедентов:

Название элемента

Графическое представление

Описание

1. Актер (Actor) (актор)



Это исполнители или участники бизнес-процесса. Те, кто начинает (инициирует) выполнение прецедентов, а также те, кто участвует в их выполнении, но необязательно начинает их. Для информационной системы актер – это, как правило, ее пользователь (человек) или внешняя система. Актер – необязательно человек.

2. Прецедент (вариант использования, сценарий) (UseCase)



Это бизнес-задача, которая реализуется бизнес-процессом. Для ИС это функция, которую она выполняет, то, для чего ИС вообще предназначена, что она позволяет с собой делать.

3. Ассоциация(Association Relationship)



Это связь между актером и прецедентом, показывающая их взаимодействие между собой. Направление связи указывает, кто является инициатором взаимодействия (либо актер начинает прецедент, либо в процессе выполнения прецедента происходит обращение к актеру).

4. Включениеирасширение (Inclusive, Extensive Relationship)

Включение:


Расширение:



Это связи между прецедентами, характеризующие отношение между ними.

Включение показывает, что базовый прецедент использует функционал включаемого прецедента. Стрелка идет от базового. Т.е. включаемый прецедент детализирует, конкретизирует, уточняет базовый. Решение задачи (базовый прецедент) включает в себя решение подзадачи (включаемый прецедент).

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


Пример диаграммы прецедентов для бизнес-процесса «Обслуживание клиента в банке»:



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

Понятно, что реальный бизнес-процесс обслуживания клиента в банке намного шире и многообразнее, но для простоты примера мы решили, что он будет таким.
4. Онлайн-сервис построения диаграмм diagrams.net
Изначально предполагалось, что данный блок лабораторных работ будем выполнять в программе Visio. MicrosoftVisio – это векторный графический редактор, обладающий широкими возможностями по созданию схем и диаграмм в различных нотациях (в т.ч. UML, IDEF и многих других). Пожалуй, можно сказать, что Visio де-факто является стандартом среди инструментов для рисования диаграмм, поэтому работать в нем уметь нужно. Однако данный программный продукт не бесплатен и доступен не всем. В состав офисного пакета MicrosoftOffice он не входит, приобретается отдельно.

В настоящее время существует большое количество свободно распространяемого (т.е. бесплатного) программного обеспечения для работы с диаграммами. А т.к. Visio – это не комплексный программный продукт для разработки ИС, а всего лишь графический редактор, для наших целей (нарисовать несколько диаграмм) он вполне заменим. Есть хороший онлайн-инструмент:
https://app.diagrams.net/ (ранее draw.io)
К его достоинствам можно отнести:

+ возможность немедленно начать построение диаграмм прямо в веб-браузере без регистрации;

+ широкая поддержка различных нотаций, множество фигур;

+ возможность сохранять диаграммы в файл и загружать их из файла.
При входе на страницу возникает такое окно:

В нем можно сменить язык, также щелчком мыши выбрать место для сохранения файлов диаграмм (Deviceозначает локальный компьютер (или смартфон, если сайт открыт с него)).

Тут выбираем, создать диаграмму с нуля или загрузить ранее созданную и сохраненную диаграмму из файла.


Тут в левом столбце предлагается выбрать набор фигур подходящей тематики, а в большой области справа – готовый шаблон диаграммы того или иного вида. Можно оставить пустую диаграмму.

Далее открывается окно графического редактора.

Слева – фигуры, сгруппированные по тематическим разделам. Их можно перетаскивать в область рисования (клетчатое полотно) мышью либо просто щелкать по ним, фигуры будут появляться сами. Можно рисовать.

Для сохранения диаграммы в файл (с целью ее последующей доработки) используется пункт «Save» в меню «File». Также диаграмму можно экспортировать (сохранить) как изображение и в разных других форматах.



Порядок выполнения лабораторной работы
Пусть стоит задача спроектировать и разработать информационную систему, автоматизирующую деятельность по управлению запасами сети розничных продуктовых магазинов. Это не ERP-система, автоматизирующая большую часть бизнес-процессов компании; не будем чрезмерно увеличивать объемы работы и для простоты рассмотрим лишь один достаточно большой бизнес-процесс и смоделируем его средствами UML.
Краткое описание деятельности компании
ООО «Шестерочка» занимается розничной продажей продуктов питания широкого ассортимента, включая алкоголь. Она закупает товары у поставщиков и реализует их населению через сеть розничных магазинов. Централизованного склада компания не имеет, товары доставляются поставщиками прямо в магазины. Управление запасами осуществляется согласно концепции JIT («точно в срок»), не предполагающей простаивания денежных средств компании в виде низко ликвидных активов.

Организационная структура компании представлена на рисунке.


Генеральный директор осуществляет общее руководство компанией.

В сферу коммерческого директора входит управление основной деятельностью компании.

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

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

В функции отдела логистики входит поиск поставщиков товара и заключение договоров с ними.

Магазины занимаются непосредственно реализацией товаров всем желающим. Каждый магазин имеет свою организационную структуру – директора, товароведа, менеджера по качеству, продавцов, грузчиков и т.д.

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

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

Отдел кадров осуществляет ведение кадрового учета, принимает и увольняет работников, оформляет отпуска и т.п.

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

Бухгалтерия подчиняется непосредственно генеральному директору и занимается ведением бухгалтерского учета.
Описание бизнес-процесса «Управление запасами»
Исполнителем данного бизнес-процесса является отдел закупа. Суть бизнес-процесса заключается в том, чтобы отслеживать состояние остатков товара в магазинах и своевременно формировать заказы поставщикам на закупку необходимого количества товара. Цель – поддержание определенного количества товара в магазинах в соответствии с регламентом. Предполагается, что поставка товаров осуществляется в течение одного дня.

В системе имеются данные о номенклатуре (ассортименте) реализуемого товара. Имеются следующие данные о товаре: наименование, единица измерения, категория (виноводочные изделия, соки и т.п.). Номенклатуру вносит категорийный менеджер отдела закупа.

Также имеется справочник поставщиков, для каждого из которых указаны категории поставляемых им товаров. Напр., кто-то специализируется на виноводочных изделиях и минеральной воде, а кто-то на соках и макаронах. Есть следующие данные о поставщике: наименование компании поставщика, адрес местоположения склада, категория поставляемых товаров. Справочник поставщиков также ведет категорийный менеджер.

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

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

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

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

Наполнение заказа происходит в два этапа:

1) Определяется разница между нормативом и фактическими остатками товара по каждому товару в каждом магазине.

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

Заказами управляет начальник отдела закупа. В начале дня он проверяет список заказов, и если появился новый заказ, он его распечатывает и запускает на исполнение. Предполагается, что в течение дня заказанный товар поступает в соответствующие магазины. Начальник отдела закупа вносит информацию о поступлениях в систему.

Процесс формирования заказов на примере гречневой крупы (кг):


День

Норма

на начало дня

Остаток

на начало дня

Необходимость заказа

1

500

600

На 1-ый день хватает. Чтобы хватило на 2-ой день, остаток должен быть не менее (500 + 500 =) 1000, а он составляет 600. Следовательно, необходимо заказать еще (1000 – 600 =) 400.

2

500

550

На 2-ой день хватает. Чтобы хватило на 3-ий день, остаток должен быть не менее (700 + 500 =) 1200, а он составляет 550. Следовательно, необходимо заказать еще (1200 – 550 =) 650.

3

700

710

На 3-ий день хватает. Чтобы хватило на 4-ый день, остаток должен быть не менее (500 + 700 =) 1200, а он составляет 710. Следовательно, необходимо заказать еще (1200 – 710 =) 490.

4

500







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

В данном бизнес-процессе можно выделить 3 подпроцесса (более детальных процесса):

1) Заполнение справочников. Всего 3 справочника: товары, категории товаров и поставщики. Их заполнением занимается категорийный менеджер.

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

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

Порядок работы
1. Открыть в браузере онлайн-редактор диаграмм (перейти на веб-страницу https://app.diagrams.net/). Выбрав нужные параметры (см. теоретическую часть, п. 4), перейти к окну с пустой диаграммой.
2. В левой части страницы развернуть раздел с фигурами UML.



Здесь нас интересуют фигуры, описанные в теоретической части, а именно:
– актер – прецедент


связь «Ассоциация»


– связи «Включение» и «Расширение»



Надписи «включает» и «расширяет» вместо «Use» можно написать вручную, перейдя двойным щелчком мыши в режим редактирования надписи, когда указатель мыши имеет вот такую форму. Сделать это не всегда получается, надо потренироваться.


3. Построить общую диаграмму прецедентов. Вид диаграммы приведен на рисунке:


4. Переименовать страницу с диаграммой на «Общая диаграмма прецедентов», для этого дважды щелкнуть мышью по вкладке с текстом «Страница 1» в нижней части окна:


Задание 2. Построить диаграмму прецедентов, конкретизирующую подпроцесс «Заполнение справочников» бизнес-процесса «Управление запасами».
Порядок работы
1. Создать новую страницу в окне редактора, чтобы разместить на ней другую диаграмму. Для этого нужно нажать на «плюс» в нижней части окна.



Назвать страницу «Заполнение справочников».
2. Построить диаграмму следующего вида (часть элементов предыдущей диаграммы можно скопировать через контекстное меню):


Задание 3. Построить диаграмму прецедентов, конкретизирующую подпроцесс «Продажи» бизнес-процесса «Управление запасами».

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

Задание 4. Построить диаграмму прецедентов, конкретизирующую подпроцесс «Закуп» бизнес-процесса «Управление запасами».

Основным актером в данном прецеденте является начальник отдела закупа.

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

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

Наконец, начальник отдела периодически формирует различные отчеты.
Порядок работы
1. Создать новую страницу, назвать ее «Закуп».
2. Построить диаграмму следующего вида:

Таким образом, при помощи UML-диаграмм прецедентов мы смоделировали один из основных бизнес-процессов компании – «управление запасами». Конечно, данная модель очень абстрактна, концептуальна, ее необходимо декомпозировать, детализировать, чем и займемся в следующей лабораторной работе.
Задание 5.В предыдущих заданиях были выполнены начальные шаги проектирования ИС для управления запасами. Теперь представим, что стоит задача спроектировать не просто узкоспециализированную ИС, а ERP-систему для автоматизации основных бизнес-процессов ООО «Шестерочка».

Необходимо построить общую диаграмму прецедентов для деятельности всей компании (самостоятельно).

Для этого нужно изучить организационную структуру компании с ее описанием и выделить основные бизнес-процессы (процесс «Управление запасами» уже известен), а также их участников (актеров). В качестве некоторого примера можно привести вот такую диаграмму:



Разумеется, наличие этого примера не означает, что диаграмма должна быть точно такой же.
Порядок работы
1. Создать новую страницу, назвать ее «Диаграмма прецедентов ERP».
2. Построить диаграмму.
3. С помощью меню FileSave (либо нажатия сочетания клавиш CTRL+S) сохранить результаты работы в файл с расширением .drawio.
4. Не закрывая текущую страницу, открыть новую страницу с редактором (https://app.diagrams.net/), выбрать пункт



и убедиться, что сохраненный файл корректно открывается, все диаграммы сохранились.
В качестве отчета по лабораторной работе 10 преподавателю необходимо предъявить файл с диаграммами.
Комментарии к заданию 5
1. Что конкретно нужно сделать?

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

Диаграмма UseCase может описывать деятельность компании с разным уровнем детализации. Например, на самом верхнем уровне может быть единственный прецедент: «Деятельность компании ООО «Шестерочка».


Откуда взяты актеры для этой диаграммы? Очевидно, что из организационной структуры предприятия (см. выше в методичке). Это работники тех или иных подразделений, отделов. Причем тут перечислены не все возможные актеры, только некоторые для примера. Все эти работники является непосредственными участниками деятельности компании и исполнителями входящих в нее бизнес-процессов. Кроме того, некоторые бизнес-процессы (управление запасами, снабжение, логистика) требуют участия внешних для компании актеров – поставщиков. Это ведь тоже участники бизнес-процессов, поэтому и они могут быть актерами. Хотя в детализирующие диаграммы прецедентов бизнес-процесса «Управление запасами» мы их не включили, рассмотрели лишь процессы внутри самой компании. Можно было добавить, можно было не добавлять – это уже зависит от того, как рассматривать деятельность предприятия и какие требования предъявлять к проектируемой информационной системе.

Из чего же состоит деятельность компании, из каких бизнес-процессов? Ну, один мы уже знаем точно – это управление запасами. Актерами, участвующими в этом прецеденте, являются работники отдела закупа, потому что именно этот отдел занимается управлением запасами. Какие еще есть бизнес-процессы? А какие еще есть подразделения в компании? Есть отдел маркетинга. Чем занимается отдел маркетинга? Собственно, маркетингом. Или, можно сказать, стимулированием спроса. Есть бухгалтерия. Есть отдел снабжения. И т.д.

Таким образом, на диаграмме в этом задании должны быть отображены в виде прецедентов основные бизнес-процессы компании (управление запасами, маркетинг, кадровый учет и т.д.), а в виде актеров – специалисты, которые являются участниками и непосредственными исполнителями этих бизнес-процессов (это работники соответствующих подразделений).
2. Надо ли придумывать свои отделы?

НЕТ! В этом задании не нужно. Свои надо будет придумывать для своей компании в лабораторной работе 12.
3. Как называть прецеденты (бизнес-процессы)?

В описании оргструктуры компании сказано, что, например, «отдел кадров осуществляет ведение кадрового учета, принимает и увольняет работников, оформляет отпуска и т.п.». Это бизнес-процесс? Определенно, из этого тоже состоит деятельность компании. Значит, прецедент так и называть, вставлять в название все эти слова? НЕТ. Это описание бизнес-процесса. А называться он должен кратко и емко – например, «кадровый учет». И сразу понятно, что это за деятельность. Есть «управление запасами». Для других бизнес-процессов тоже надо подобрать короткие названия, передающие их суть.
4. Являются ли руководители (директора) актерами?

Как правило, руководство не указывают на диаграмме прецедентов. Директора не реализуют свои собственные бизнес-процессы, они лишь управляют бизнес-процессами компании. Поэтому они могут быть связаны со всеми прецедентами, но это слишком усложнит диаграмму, запутает ее, так обычно не делают. Поэтому в качестве актеров директоров добавлять не надо.
5. Нужно ли использовать на диаграмме связи «включение» и «расширение»?

Не запрещается. Только нужно их применять логично – для детализации тех или иных прецедентов (см. еще раз теоретическую часть про элементы диаграммы прецедентов).
6. Зачем дан пример диаграммы с бизнес-процессами компании «МЕД»?

Чтобы посмотреть, как в целом должна выглядеть диаграмма. Точно такой же она быть не должна ни в коем случае! У компании «Шестерочка» свои подразделения и свои бизнес-процессы. Она занимается не тем же самым, что компания «МЕД».

М-р – это менеджер! Автор диаграммы так назвал работников, но далеко не все работники являются менеджерами. Есть специалисты отделов, инженеры, программисты, аналитики и т.д.


написать администратору сайта