Файл: Разработка регламента выполнения процесса «Управление документооборотом» ..pdf

Далее рассмотрим модель бизнес-процесса в IDEF0, IDEF3 и DFD методологии.

Функциональный аспект архитектуры в методологии IDEF может быть описан диаграммами IDEF0 [6]. В IDEF0 система представляется как совокупность функций, взаимодействующих между собой. Обычно функцию можно рассматривать как процесс с входами и выходами. Поэтому вместо названий функций можно использовать названия процессов.

IDEF0 или IDEFØ (определение интеграции для моделирования функций) - это метод, предназначенный для моделирования решений, действий и действий организации или системы. IDEFØ был получен из хорошо зарекомендовавшего себя графического языка, структурированного анализа и методики проектирования (SADT - аббревиатура от англ. Structured Analysis and Technique Technique ).

ВВС США поручили разработчикам SADT разработать метод моделирования для анализа и представления функциональной перспективы системы. Эффективные модели IDEFØ помогают организовать анализ системы и способствуют хорошей коммуникации между аналитиком и клиентом. IDEFØ полезен для определения объема анализа, особенно для функционального анализа. Как инструмент коммуникации, IDEFØ улучшает участие экспертов в предметной области и консенсуса в принятии решений с помощью упрощенных графических устройств. Как инструмент анализа, IDEFØ помогает моделисту определить, какие функции выполняются, что необходимо для выполнения этих функций, что текущая система делает хорошо или делает неправильно. Таким образом, модели IDEFØ часто создаются как одна из первых задач разработки системы.

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

Рисунок 1. Контекстная диаграмма

На контекстной диаграмме основной процесс – торговля товарами, - рассматривается как «черный ящик», который имеет входные и выходные потоки.

Report for Diagram: A-0, Документооборот

Activity Name: Документооборот

Link Name: Входящий документ

Link Name: Информация руководству

Link Name: Персонал

Link Name: Нормативные документы

Link Name: Руководитель

Link Name: Приказ

Следующим шагом будет декомпозиция контекстной диаграммы, рис.2

Рисунок 2. Декомпозиция контекстной диаграммы

Перечислим основные функции рис.2

• Activity Name: Зарегестрировать документ
• Activity Name: Назначить исполнителя
• Activity Name: Контролировать выполнения
• Link Name: Зарегестрированный документ
• Link Name: Документ в работе

Вход и выход:

• Link Name: Входящий документ
• Link Name: Информация руководству
• Link Name: Приказ

Исполнители:

• Link Name: Персонал
• Link Name: Руководитель

Управление:

• Link Name: Нормативные документы

Модель IDEF3 описывает переходы объектов. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие. На рис.3 приведена диаграмма для процесса издания приказа, которая предполагает подготовку проекта, согласование, подписание приказа.

Рисунок 3. Диаграмма IDEF3

Activity Name: Подготовить проект приказа

Activity Name: Корректировка

Activity Name: Анализ проекта приказа

Activity Name: Согласование

Activity Name: Подписание

Расшифруем обозначения, рис.4

Рисунок 4. Обозначения IDEF3

DFD - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Обозначение DFD опирается на теорию графов, первоначально использовавшуюся в операционных исследованиях для моделирования рабочих процессов в организациях. DFD возникла из Диаграммы Деятельности, использованной в методологии SADT (Структурный анализ и дизайн) в конце 1970-х годов. Популяризаторы DFD включают Эдварда Юдона, Ларри Константина, Тома Демарко, Криса Гэйна и Триш Сарсон. [2]

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

DFD состоит из процессов, потоков, складов и терминаторов. Существует несколько способов просмотра этих компонентов DFD.

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

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

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

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

На рис.5 показана DFD диаграмма по обработке документов. В ходе работы, был проведен анализ потоков данных организации, и построена диаграмма DFD. В ходе исследования выяснилось, что клиент или внешние организации передает организации документы, которые зарегистрированы и зарегистрированы в журнале. После этого сотрудник организации прикрепляется к этим документам для этой работы (прилагается к подрядчику), после чего в журнал вносится запись о поступление документа, о дате, когда должна быть выполнена работа. Чтобы контролировать производительность работы, есть запись управления, в которой выполняется запись о доставке управления документами и информацией о нем. После завершения работы с документом дата устанавливается при завершении работы, после чего документ, в котором была выполнена работа, удаляется из элемента управления и отправляется в архив или клиенту внешней организации. При необходимости ведется статистика.

Рисунок 5. Диаграмма DFD для заключения договора

Процессы:

• Activity Name: Зарегестрировать документ
• Activity Name: Сделать запись о поставке на контроль
• Activity Name: Отследить ход выполнения
• Activity Name: Прикрепить исполнителя
• Activity Name: Вести статистику

Потоки информации:

• Link Name: Документ
• Link Name: Статистика
• Link Name: Запись в журнале
• Link Name: Запись о прикрепление
• Link Name: Информация о документе
• Link Name: Запись о поставке на контроль
• Link Name: Дата окончания контроля
• Link Name: Данные о документе
• Link Name: Данные о ходе выполнения

Хранилища:

Data Store Name: Журнал

Data Store Name: Журнал контроля

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

ЗАКЛЮЧЕНИЕ

Результатом исследования темы: «Разработка регламента выполнения процесса «Управление документооборотом», стали следующие выводы, а именно:

1. Были рассмотрены общие вопросы процессного подхода. Определены основные понятия, прежде всего «бизнес-процесс».

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

3. Выполнен анализ технических средств поддержки методологии IDEF. Установлено, что наиболее продвинутыми программными продуктами являются системы, созданные в конце 20-го века и в начале 21-го века. В наиболее полной мере возможности методологии реализованы в продукте компании Computer Associates в пакете AllFusion. Хотя в настоящее время эти продукты не поддерживаются, решено использовать именно их.

4. В качестве бизнес - процесса для исследования выбран «Учет документооборота». Это связано с тем, что данный бизнес - процесс есть практически на любом предприятии и в любой организации, т.к. присутствует движение документов.

5. Построена модель бизнес-процесса с использованием программ BpWin, которые поддерживают методологию IDEF1, IDEF3 и DFD. Сравнение трех методологий показало, что лучшим вариантом является методология IDEF0, и может быть рекомендована к практическому использованию

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Основы бизнес-анализа [Текст] : учеб. пособие / ред. В. И. Бариленко. - М. : Кнорус, 2014. - 270 с.
2. Винтова, Т. А. Основы функционального моделирования автоматизированной системы управления персоналом [Текст] / Т. А. Винтова, П. Е. Коваль // Менеджмент и бизнес-администрирование. - 2015. - N 3. - С. 171-175
3. Высочина, М. В. Моделирование управленческого процесса [Электронный ресурс] / М. В. Высочина, М. В. Шкиндер // Научный вестник : финансы, банки, инвестиции. - 2016. - N 4. - С. 159-164. – Режим доступа: http://science.cfuv.ru/nauchnye-zhurnaly-kfu
4. Карминский, А. М. Информационные системы в экономике [Электронный ресурс] : учеб. пособие: в 2 ч. Ч. 2. Практика использования / А. М. Карминский, Б. В. Черников. - М. : Финансы и статистика, 2006. - 239 с.
5. Маклаков, С. В.. Моделирование бизнес-процессов с BPwin 4.0[Текст]/ С. В Маклаков - Москва "ДИАЛОГМИФИ", 2002 - 250 с.
6. Мосягин, А. А. Проблема выбора CASE-средства управления бизнес-процессами [Текст] / А. А. Мосягин, А. Б. Мосягин // Менеджмент и бизнес-администрирование. - 2015. - N 3. - С. 137-143
7. Фролова, Л. В. Формирование бизнес-модели предприятия [Текст] : учебник / Л. В. Фролова, Е. С. Кравченко. - К. : ЦУЛ, 2012. - 380 с.