ОБЩИЕ СВЕДЕНИЯ О ФУНКЦИОНАЛЬНО-СТРУКТУРНОМ ПОДХОДЕ К МОДЕЛИРОВАНИЮ БИЗНЕС-ПРОЦЕССОВ

2019-05-24

1016

Обсуждений (0)

0.00 из 5.00 0 оценок

Тема. МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНО-СТРУКТУРНОГО МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ

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

2. Методология функционального моделирования IDEF0.

3. Методология DFD.

4. Методология IDEF3.

5. Инструментальная среда All Fusion Process Modeler

ОБЩИЕ СВЕДЕНИЯ О ФУНКЦИОНАЛЬНО-СТРУКТУРНОМ ПОДХОДЕ К МОДЕЛИРОВАНИЮ БИЗНЕС-ПРОЦЕССОВ

Функционально-структурный подход к моделированию бизнес-процессов предусматривает выделение в исследуемой системе путем ее декомпозиции процессы, подпроцессы, функции и определение их иерархии. Подобный подход был предложен Дугласом Россом в 1960-х гг. в качестве методологии SADT (Structured Analysis and Design Technique), предусматривающий проведение декомпозиции анализируемого процесса и представление его как совокупности взаимосвязанных операций, каждая из которых имеет четко определенные входы и выходы, определяющие связи между операциями с учетом необходимых для их выполнения ресурсов.

В 1970-х гг. методология SADT получила распространение, благодаря ее использованию Министерством обороны США в качестве поддержки производства ICAM (Integrated Computer-Aided Manufacturing). Основной целью применения функционально-структурного подхода стало повышение эффективности производственного процесса за счет использования компьютерных технологий. В последствии методология SADT была переименована в IDEF (ICAM DEFinition, далее – Integrated DEFinition) и утверждена в качестве федерального стандарта США «IDEF0». Последняя редакция данного стандарта выпущена в 1993г.

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

- IDEF0 – используется для функционального моделирования бизнес-процессов верхнего уровня, образующих общую структуру процесса;

- IDEF1 – методология моделирования внутрисистемных информационных потоков;

- IDEF1X – методология моделирования реляционных структур;

- IDEF3 – методология моделирования атомарных функций (не подлежащих дальнейшей декомпозиции) в виде потоков работ;

- IDEF4 – методология объектно-ориентированного моделирования систем в виде классов, диаграмм наследования и др.

- IDEF5 – онтологическое моделирование сложных систем путем создания словаря терминов и правил для формулирования и описания системы в определенный момент времени.

Для описания потоков данных между компонентами исследуемой системы (процессами, подпроцессами) используется методология DFD (Data Flow Diagrams) – диаграммы потоков данных. Данная методология используется для детализации процессов, представленных в IDEF0 и IDEF3.

2. МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО
МОДЕЛИРОВАНИЯ IDEF0

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

Рисунок 1 – Функциональная модель в нотации IDEF0

Нотацию IDEF0 определяют следующие правила:

1. Функция изображается в виде прямоугольника (Activity), в правом нижнем углу которого приведен ее номер.

2. Левая сторона блока Activity используется для изображения входов функции в виде стрелок.

3. Из правой стороны блока Activity в виде стрелок изображаются выходы системы.

4. В нижнюю сторону блока Activity входят стрелки, изображающие механизмы функции.

5. В верхней части функции определяются способы управления функцией.

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

7. Каждая функция должна иметь минимум по одному входу, выходу, механизму и управлению.

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

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

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

На рисунке 2 в верхней части изображена ТОР-диаграмма с четырьмя граничными стрелками. На средней части рисунка приведена декомпозиция ТОР-диаграммы, а в нижней части – декомпозиция «Функции 3». При этом, если обратить внимание, граничные стрелки с ТОР-диаграммы мигрировали на диаграмму декомпозиции, и представлены на ней как нераспределенные стрелки у границ диаграммы. Тогда как диаграмма декомпозиции «Функция 3» вообще не содержит граничных стрелок. Данный факт обуславливается тем, что у функции «Функция 3» на диаграмме декомпозиции ТОР-диаграммы не определены вход, выход, механизм и управление.

Рисунок 2 – Принцип декомпозиции в нотации IDEF0

Каждая диаграмма в нотации IDEF0 имеет свой уникальный номер, представленный в левой нижней части, а в правой верхней части - контекст декомпозиции. Так, например, ТОР-диаграмма имеет номер А-0. Буква «А» в индексе образована от Activity, «0» - уровень декомпозиции, контекст – «ТОР-диаграмма».

Номер диаграмма декомпозиции «А-0» обозначается индексом «А0» (без дефиса), имя диаграммы образуется по названию Activity на ТОР-диаграмме (в приведенном примере – «Функция»), а контекст представлен блоком Activity с черной заливкой.

Рисунок 3 – Принцип формирования номера диаграммы

Номера диаграмм последующих уровней декомпозиции формируются по принципу «А1», «А2», «А3» и т.д. Так, например, на рисунке 2 нижней диаграмме присвоен индекс «А3» ввиду того, что она изображает результат декомпозиции блока Activity с номером «3», что и изображено в поле «Context». Имя диаграммы «А3» образовано по имени соответствующего блока Activity на родительской диаграмме.

При дальнейшей декомпозиции блоков Activity будут образовываться номера «А3.1», «А3.2», «А3.1.4» и т.д. Так, например, номер диаграммы «А3.1.4» говорит о том, что на ней приведен результат декомпозиции четвертого блока Activity диаграммы «А3.1», а сама диаграмма представляет пятый уровень декомпозиции модели.

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

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

1. Вход. В качестве входов функциональных блоков Activity могут выступать различного рода информация, документы, материальные объекты, которые будут трансформированы в результате выполнения функции. Например, документ, который будет подписан, информация, которая будет обработана, сырье, которое будет переработано в полуфабрикат или готовый продукт.

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

3. Механизмы. В качестве механизмов функции выступают различные ресурсы, с помощью которых она может быть выполнена (человек, оборудование, инструмент, приложение, финансы, энергетические ресурсы и др.). Например, если в качестве входа функции определен документ, а в качестве выхода – подписанный документ, тогда механизмом этой функции будет человек, который подписывает документ.

4. Управление. В качестве управления для функции, чаще всего, выступают документы, регламентирующие ее выполнение. Например, положение, инструкция, рецептура, методические указания, локальные нормативно-правовые акты (приказы, распоряжения, решения и др.), федеральные, краевые нормативно-правовые акты и др.

Граничные стрелки в методологии IDEF0 можно представлять укрупненно, а также при необходимости проводить их детализацию. В первую очередь это предусматривается для обеспечения удобочитаемости диаграммы. Так, например, на ТОР-диаграмме не имеет смысла приводить перечень всех должностей персонала организации, а достаточно привести одну стрелку «Персонал», а потом на диаграммах декомпозиции уточнить соответствующую должность. Аналогичный прием, можно провести с входами, выходами и управлением, как показано на рисунке 4.

Рисунок 4 – Детализация граничных стрелок модели

В процессе корректировки и уточнения модели исследователь может добавлять или удалять граничные стрелки на диаграммах, что приводит к их обрыву. Граничная стрелка с обрывом изображается в квадратных скобках [ ], что показано на рисунке 5.

Квадратные скобки на границе диаграммы обозначают, что граничная стрелка оборвана на родительской диаграмме. Если квадратные скобки изображены возле блока Activity – это говорит о том, что граничная стрелка оборвана на дочерней диаграмме.

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

Рисунок 5 – Обрыв граничной стрелки

Рисунок 6 – Туннелирование граничной стрелки

Рассмотрим процесс создания модели бизнес-процесса с использованием методологии IDEF0 и инструментального средства All Fusion Process Modeler на примере бизнес-процессов ЗАО «Мясоперерабатывающего комплекса «Динской», который представляет собой многопрофильную группу сельскохозяйственных, производственных, торгово-сбытовых компаний для совместной хозяйственной деятельности. Глобальной целью ЗАО «Мясоперерабатывающий комплекс Динской» является расширение рынка товаров и услуг Краснодарского края, ЮФО, России за счет производства колбасных и деликатесных изделий.

На рисунке 7 приведена ТОР-диаграмма бизнес-процессов ЗАО «Мясоперерабатывающий комплекс «Динской».

Рисунок 7 – ТОР-диаграмма бизнес-процессов ЗАО «Мясоперерабатывающий комплекс «Динской»

Основными входами модели являются: сено и кормовое сырье; племенные животные; сырье от поставщика; желание и потребности клиента; информация о внешней среде.

Выходами модели являются: колбасные изделия в ассортименте; отчетность предприятия; заявка на сено и кормовое сырье; заявка поставщику сырья.

Механизмы: ресурсы от поставщиков; клиенты; оборудование; персонал; руководители.

Управление: федеральное и краевое законодательство; правила пожарной безопасности; правила санитарии и гигиены; ГОСТы, ТУ; правила торговли; стратегия развития корпорации.

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

Рисунок 8 – Декомпозиция ТОР-диаграммы

«Деятельность ЗАО МПК «Динской»

Как видно из рисунка 8, деятельность ЗАО «Мясоперерабатывающий комплекс «Динской» декомпозируется на три подпроцесса: основные бизнес-процессы, вспомогательные бизнес-процессы, управление.

Входами основных бизнес-процессов являются: сено и кормовое сырье; племенные животные; сырье от поставщика; желание и потребности клиента; информация о внешней среде.

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

Механизмы: клиенты; персонал; транспорт; ресурсы.

Управление: локальные нормативно-правовые акты; стратегия развития корпорации.

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

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

Механизмы: персонал и ресурсы от поставщиков.

Управление: локальные нормативно-правовые акты; стратегия развития корпорации.

Входами бизнес-процессов управления являются: отчетность подразделений; аналитическая, учетная и управленческая информация; информация о внешней среде.

Выходы: отчетность предприятия; локальные нормативно-правовые акты.

Механизмы: руководители, ресурсы.

Управление: Федеральное и краевое законодательство; стратегия развития корпорации.

Основные бизнес-процессы разделяются на (рисунок 9):

- вырастить КРС и свиней;

- забить КРС и свиней;

- произвести колбасные изделия;

- хранить сырье и готовую продукцию;

- продать колбасные изделия.

Дальнейший пример будет строиться на процессе «Продать колбасные изделия», а также смежных с ним процессах.

Рисунок 9 – Диаграмма декомпозиции «Основные бизнес-процессы»

Как видно из рисунка 9 бизнес-процесс «Продать колбасные изделия» связан с бизнес-процессом «Хранить сырье и готовую продукцию». Входами бизнес-процесса этого процесса являются: мясо на хранение; готовая продукция; заявка на сырье; сырье от поставщика; заявка на отгрузку товара.

Выходы: сырье в производство; готовая продукция на продажу; заявка поставщику сырья; колбасные изделия в ассортименте.

Механизмы: транспорт и персонал.

Управление: локальные нормативно-правовые акты.

Входами бизнес-процесса «Продать колбасные изделия» являются: готовая продукция на продажу; информация о внешней среде; желание и потребности клиента.

Выходы: колбасные изделия в ассортименте; договора; информация о должниках; заявка на отгрузку товара.

Механизмами бизнес-процесса «Продать колбасные изделия» являются клиенты и персонал. Управление – локальные нормативно-правовые акты.

Связь бизнес-процессов «Продать колбасные изделия» и «Хранить сырье и готовую продукцию» обеспечивается наличием у ЗАО «Мясоперерабатывающий комплекс «Динской» собственной транспортной базы и сети магазинов розничной торговли. Наряду с розничной торговлей, ЗАО «Мясоперерабатывающий комплекс «Динской» осуществляет поставки продукции клиентам в рамках бизнес-процесса «Оптовая торговля» (рисунок 10). Таким образом, бизнес-процесс «Хранить сырье и готовую продукцию» (рисунок 11) обеспечивает начальные этапы (готовая продукция на продажу) процессов розничной торговли и завершающие этапы (колбасные изделия в ассортименте) процесса оптовой торговли.

Рисунок 10 – Диаграмма декомпозиции «Продать колбасные изделия»

Входами бизнес-процесса «Оптовая торговля» являются: информация о внешней среде; желание и потребности клиента; информация об оплате заявки. Стрелка «Информация об оплате заявки» являются туннельной по границе потому, что для бизнес-процесса «Оптовая торговля» эта информация является стратегической, однако на уровне декомпозиции А0 «Деятельность ЗАО «Мясоперерабатывающий комплекс «Динской» она бы только перегружала диаграмму информацией.

Выходами бизнес-процесса «Оптовая торговля» являются: договора; запрос на подтверждение оплаты заявки; информация о должниках; заявка на отгрузку товара.

Механизмы: персонал и клиенты, управление – локальные нормативно-правовые акты.

Входами бизнес-процесса «Розничная торговля» являются: желание и потребности клиента; готовая продукция на продажу.

Выходы: заявка на отгрузку товара; колбасные изделия в ассортименте.

Механизмы: персонал и клиенты, управление – локальные нормативно-правовые акты.

Как видно из диаграммы (рисунок 10), основная связь между бизнес-процессами «Оптовая торговля» и «Розничная торговля» является документ «Заявка на отгрузку товара», направленный на вход бизнес-процесса «Хранить сырье и готовую продукцию» (рисунок 10).

Декомпозиция бизнес-процесса «Хранить сырье и готовую продукцию» представлен на рисунке 11. Как видно из диаграммы процесс «Хранить сырье и готовую продукцию» состоит из несвязанных между собой двух процессов: сырьевой склад; склад готовой продукции.

Входами бизнес-процесса «Склад готовой продукции» являются: готовая продукция; заявка на отгрузку товара.

Выходы: готовая продукция на продажу; колбасные изделия в ассортименте.

Механизмы – персонал и транспорт. Управление – локальные нормативно-правовые акты.

Все граничные стрелки бизнес-процесса «Склад готовой продукции» являются туннельными, что связано с тем, что дальнейшая декомпозиция данного бизнес-процесса будет проводиться с использованием нотации DFD, которая не предусматривает граничных стрелок и обрыв связан со сменой нотаций моделирования. Более детально данный бизнес-процесс будет рассмотрен в следующем вопросе.

На рисунке 12 приведена диаграмма декомпозиции бизнес-процесса «Оптовая торговля». Как видно из диаграммы данный процесс состоит из следующих подпроцессов: изучение внешней среды; заключение договора; прием и обработка заявки; оплата.

Рисунок 11 – Декомпозиция бизнес-процесса

«Хранить сырье и готовую продукцию»

Рисунок 12 – Декомпозиция бизнес-процесса «Оптовая торговля»

Основная цель бизнес-процесса «Изучение внешней среды» - поиск новых клиентов. Результатом этого процесса является информация о потенциальных клиентах, которым может быть интересно коммерческое предложение ЗАО «Мясоперерабатывающий комплекс «Динской».

После заключения договора, клиенты подают заявку (желание и потребности клиента), которая обрабатывается (заявка на отгрузку товара) и реализуется. После отгрузки товара клиент оплачивает заявку на основании выставленного счета.

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

МЕТОДОЛОГИЯ DFD

Диаграммы потоков данных (Data Flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как есть связанных между собой функциональных блоков. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.

Рисунок 13 – Графические средства формирования функциональной модели

Графическая нотация DFD предусматривает описание:

- функций обработки информации;

- документов (стрелки), объектов, сотрудников или отделы, которые участвуют в обработке информации;

- внешних сущностей (External references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;

- таблиц для хранения документов (хранилище данных, data store).

Рисунок 14 – ТОР-диаграмма модели в нотации DFD

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

Стрелки. Описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона Activity не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника функционального блока. В DFD также применяются двунаправленные стрелки для описания диалогов типа команды – ответа между функциональными блоками, между функциональными блоками и внешними сущностями.

Рисунок 15 – Пример использования двунаправленной стрелки при описании бизнес-процессов

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

Рисунок 16 – Диалоговое окно Arrow Properties (Свойство стрелки)

Внешние сущности. Изображают входы в систему и/или выходы из системы. Внешние сущности (рисунок 17) изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы.

Рисунок 17 – Блок диаграммы, используемый для

изображения внешней сущности

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

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

Рисунок 18 – Блок диаграммы, используемый для

изображения хранилища

Одноименные хранилища данных также могут быть использованы многократно на одной или нескольких диаграммах. Хранилища данных могут иметь как стандартный вид отображения, так и настраиваемый. Для того чтобы изменить вид, необходимо открыть свойства объекта и на вкладке Box Style переключить переключатель в положение Custom и из выпадающего списка выбрать интересующее изображение. Чтобы на объекте было видно его название, необходимо поставить галочку в пункте Show Name.

Рисунок 19 – Пример настраиваемого вида хранилища

Как уже говорилось ранее, наиболее распространённым случаем использования методологии DFD – детализация диаграмм IDEF0. Вернемся к примеру с ЗАО «Мясоперерабатывающий комплекс «Динской». На рисунке 20 приведено дерево бизнес-процессов нашего объекта моделирования, на котором наглядно виден, переход от одной нотации моделирования к другой.

Рисунок 20 – Фрагмент дерева бизнес-процессов

ЗАО «Мясоперерабатывающий комплекс «Динской»

Рассмотрим пример применения методологии DFD для построения модели бизнес-процесса «Оптовая торговля». На рисунке 21 приведена диаграмма декомпозиции функции «Изучение внешней среды».

Рисунок 21 – Диаграмма декомпозиции функции «Изучение внешней среды»

бизнес-процесса «Оптовая торговля» в нотации DFD

База данных реализована в виде настольного приложения MS Access, доступ к которому каждый торговый представитель получает непосредственно в офисе. В приложении настроена функция отчета о новых клиентах, закрепленных за каждым торговым представителем. Используя эту информацию, торговый представитель проводит деловую встречу, результаты которой заносит в базу данных в виде комментариев типа «холодный клиент, нужна дополнительная встреча», «не устраивает ценовая политика», «заключен договор» и т. д. Если клиент согласен на сотрудничество, делается специальная отметка «согласен работать». Для заключения договора в приложении формируется отчет о потенциальных клиентах, т. е. тех клиентах, которые отмечены в базе как «согласен работать».

На рисунке 22 приведена диаграмма декомпозиции функции «Заключение договора» бизнес-процесса «Оптовая торговля» в нотации DFD.

Рисунок 22 – Диаграмма декомпозиции функции «Заключение договора»

бизнес-процесса «Оптовая торговля» в нотации DFD

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

Параллельно с этим обсуждаются условия договора и заполняется бланк договора. Шаблон договора выполнен в виде текстового документа MS Word, печатную копию которого торговые представители берут в офисе. Договор заполняется вручную и вместе с собранными документами передается торговым представителем на согласование в ЗАО «Мясоперерабатывающий комплекс «Динской». После подписания договора он регистрируется и одна копия возвращается клиенту. Торговый представитель после подписания договора заносит все его условия в базу данных клиентов.

На рисунке 23 представлена диаграмма декомпозиции функции «Прием и обработка заявки» бизнес-процесса «Оптовая торговля». Клиент направляет заявку торговому представителю или оператору в офис. Подача заявки осуществляется в устной форме по телефону. Обработка заявки осуществляется с помощью настольного приложения «1С: Торговля». После регистрации заявки осуществляется выставление счета. При регистрации заявки система 1С: Торговля проверяет наличие дебиторской задолженности, при наличии таковой заявка отклоняется. В случае успешной регистрации заявки, формируется заявка на отгрузку товара, которая передается на склад готовой продукции в систему 1С: Торговля. Склад.

Рисунок 23 – Диаграмма декомпозиции функции «Прием и обработка заявки» бизнес-процесса «Оптовая торговля» в нотации DFD

На рисунке 24 приведена диаграмма декомпозиции функции «Оплата» бизнес-процесса «Оптовая торговля». В системе 1С: Торговля формируется отчет по неоплаченным заявкам, т.е. клиентам, имеющим дебиторскую задолженность. На основании полученной информации торговые представители начинают работу с клиентом по погашению задолженности или в случае отсутствия результата на проводимые мероприятия, готовят служебную записку в юридический отдел с приложением распечатанной карточки клиента-задолжника. Подготовка служебной записки осуществляется в текстовом редакторе MS Word.

Рисунок 24 - Диаграмма декомпозиции функции «Оплата» бизнес-процесса «Оптовая торговля» в нотации DFD

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

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

Рисунок 25 – Декомпозиция бизнес-процесса «Склад готовой продукции»

в нотации DFD

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

МЕТОДОЛОГИЯ IDEF3

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

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

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

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

IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.

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

Рисунок 26 – Основные элементы графической нотации IDEF3

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (действиями), являются центральными компонентами модели. В IDEF3 функциональные блоки изображаются прямоугольниками с прямыми углами и имеют имя, выраженным отглагольным существительным, обозначающим процесс действия, одиночным или в составе словосочетания, и номер (идентификатор); другое имя существительное в составе того же словосочетания, зависимое от отглагольного существительного, обычно отображает основной выход (результат) функционального блока (например, «Изготовление изделия»).

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

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

Перекрестки (Junction). Окончание одного действия может служить сигналом к началу нескольких действий, или же одно действие для своего запуска может ожидать окончание нескольких действий.

Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующего действия. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out junction) стрелок. Перекресток не может использоваться одновременно для слияния и разветвления.

Для внесения перекрестка в диаграмму, служит кнопка Junction Tool на панели инструментов. В диалоговом окне Select Junction Style, необходимо указать тип перекрестка (таблица 1). Все перекрестки на диаграмме по умолчанию нумеруются, каждый номер имеет префикс J.

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

Чтобы избежать конфликтов, необходимо соблюдать следующие правила:

1. Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

2. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ».

Таблица 1 – Характеристика типов перекрестков

Обозначение

2019-05-24

1016

Обсуждений (0)

0.00 из 5.00 0 оценок

Обсуждение в статье: ОБЩИЕ СВЕДЕНИЯ О ФУНКЦИОНАЛЬНО-СТРУКТУРНОМ ПОДХОДЕ К МОДЕЛИРОВАНИЮ БИЗНЕС-ПРОЦЕССОВ

Обсуждений еще не было, будьте первым... ↓↓↓