Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Управление документооборотом» (Описание предметной области и постановка задачи)

Содержание:

Введение

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

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

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

Цель работы – разработать регламент выполнения процесса «управление документооборотом».

Задачи: выделить основные задачи автоматизации предметной области, построить функциональные модели бизнес-процессов, модели информационной системы в нотациях UML 2.0 [14].

Анализ предметной области

Описание предметной области и постановка задачи

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

Рисунок 1 – Организационная структура Компании

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

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

На рисунке 2 приведена общая диаграмма документооборота, отражающая схему движения одного документа.

создание документа;
распространение первичным исполнителям;
распространение документа далее по цепочке исполнения (согласований);
исполнение и отчет в той или иной форме.

diag_document_workflow

Рисунок 2 – Диаграмма документооборота

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

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

Выходные данные типовой системы документооборота могут быть представлены:

данные по процессу обработки документов;
электронные копии документов;
архив электронной документации;
события (задания) исполнителям;
отчеты по документам.

Выбор средства для моделирования бизнес-процессов

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

Для демонстрации бизнес-процессов, анализа их архитектуры в целом и принятия решений об оптимизации имеются специальные методики и языки моделирования [2]. Рассмотрим некоторые из них.

SADT

SADT использует структурный подход к моделированию – методологию структурного анализа и проектирования (Structured Analysis and Design Technique). SADT разработана Дугласом Т. Россом в 1969-1973 годах и базируется на структурном анализе систем и графическом представлении организации в виде системы функций [8]. Для существующих систем нотации IDEF методологии SADT могут быть использованы для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются [9]. SADT требует определенной строгости следования своим правилам, в то же время не накладывает жестких ограничений.

Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы [6].

В рамках SADT используется несколько нотаций моделирования. Остановимся на трех из них:

IDEF0. Основной концептуальный принцип IDEF0 состоит в представлении любой анализируемой системы в виде набора взаимосвязанных блоков. Этот набор отображает процессы, происходящие в анализируемой системе [15]. Таким образом, IDEF0 сводится к декомпозиции основных функций на отдельные бизнес-процессы, работы и действия, в результате чего разрабатывается иерархическая модель; при этом декомпозицию можно производить многократно, до четкого и детального описания всех процессов [8]. Таким образом, моделируемая система рассматривается как произвольное подмножество неограниченного множества. При этом система имеет рамки, через которые описывается взаимодействие с внешним миром посредством входов (исходные данные, которые обрабатывает система), выходов (результаты деятельности системы), управлений (стратегий и управляющих процедур, регламентирующих выполнение работ) и механизмов (ресурсы и исполнители работ). В итоге получается, что управляемая система преобразует входы в выходы, используя механизмы.

Методология IDEF0 имеет ряд преимуществ:

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

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

DFD (Data Flow Diagram) – диаграммы потоков данных. Являются основным средством моделирования функциональных требований проектируемой системы. С помощью этих диаграмм функциональные требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных [6]. Логическая модель DFD показывает внешние по отношению к системе источники данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ [12].

Для построения диаграмм DFD существуют разные нотации: Гейна-Сарсона и Йордана-де-Марка.

BPMN

Одной из технологий описания бизнес-процессов, относящихся к типу «work-flow» – моделей, является нотация моделирования BPMN (Business Process Model Notation) – технология моделирования и нотации бизнес-процессов [11]. Данная технология предлагает довольно обширные средства для отражения самых подробных и самых важных понятий моделируемого процесса.

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

Основные достоинства нотации BPMN [3]:

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

eEPC

Методология EPC (Event-Driven Process Chain – цепочка процессов, управляемая событиями) является расширением нотации IDEF3, дополняя ее таким понятием, как событие. Методология eEPC – некоторое расширение методологии EPC.

Диаграммы eEPC представляют собой упорядоченный граф событий бизнес-функций. Нотация EPC предлагает простое, наглядное и эффективное средство моделирования, позволяющее в виде последовательности событий и функций описывать сложные бизнес-процессы. Она применяется в таких распространенных программных продуктах, как SAP и ARIS [13].

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

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

В данной работе для моделирования бизнес-процессов будет использована нотация IDEF0 методологии SADT.

Моделирование бизнес-процессов «как есть»

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

На рисунке 3 приведена контекстная диаграмма документооборота в нотации IDEF0.

Рисунок 3 – Контекстная диаграмма IDEF0

Сам процесс документооборота включает (рисунок 4):

создание документа;
исполнение документа;
отчет по исполнению.

Рисунок 4 – Диаграмма декомпозиции IDEF0

Создание документа реализуется следующими этапами (рисунок 5):

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

Рисунок 5 – Диаграмма декомпозиции создания документа

Выводы по главе 1

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

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

Реинжиниринг существующих бизнес-процессов

Предлагаемые мероприятия по улучшению бизнес-процессов

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

ИСЭД может применяться для замены «бумажных» документов их электронными копиями с отслеживанием всего жизненного цикла документа от его создания до исполнения.

Основные цели, преследуемые при создании ИСЭД:

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

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

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

Рисунок 6 – Диаграмма вариантов использования ИСЭД

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

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

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

Рисунок 7 – Диаграмма состояний документа в ИСЭД

Новый – начальное состояние документа при его создании.
Отправлен на согласование – состояние после того, как пользователь указывает адресата и отправляет документ на согласование.
Отправлен на исполнение – состояние после того, как пользователь указывает исполнителей и отправляет документ на исполнение.
На согласовании – состояние после того, как указанный адресат получил задачу согласовать документ и открыл ее для просмотра.
На исполнении – состояние после того, как указанный исполнитель получил задачу исполнить документ и открыл ее для просмотра.
Согласован – состояние документа после того, как адресат выполнил задачу согласования документа.
Не согласован – состояние документа после того, как адресат отклонил задачу согласования документа.
Исполнен – состояние документа после того, как исполнитель выполнил задачу исполнения документа.

Для описания алгоритмов, в котором участвует пользователь и система, используются блок-схемы или диаграммы активности [1]. Описанные состояния, отражены на диаграмме активности управления документооборотом на рисунке 8.

Рисунок 8 – Диаграмма активности

ИСЭД

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

Основой программного обеспечения ИСЭД является его объектная архитектура.

Объектная архитектура программного обеспечения ИСЭД состоит из следующих компонентов:

Статического класса User, который будет отвечать за авторизацию пользователя в ИСЭД, содержать в себе аккаунт авторизованного пользователя и выполнять все действия от имени этого аккаунта;
Классов-сущностей (данные классы отображают структуру базы данных и соответствуют ее таблицам): Account (данные аккаунта пользователя), Document (данные документов), DocEvent (данные событий с документами, регистрируемых в процессе документооборота), DocTask (задачи, создаваемые для других аккаунтов в процессе документооборота).
Интерфейсов:

IDBManage – интерфейс доступа к базе данных, представляющий методы для управления классами-сущностями, соответствующими запросам к БД;

IUserManage – интерфейс пользователя с классом сущности, позволяющий выполнять команды с данными, вызывая соответствующие диалоги ввода данных.

Пользовательских форм:

frmLifeCycleTree – окно построения «дерева» ЖЦ документа;

frmTasks – окно списка задач пользователя.

Объектная архитектура программного обеспечения ИСЭД приведена на рисунке 9 в виде UML-диаграммы классов. Диаграммы классов являются основными составляющими модели любого программного обеспечения [4].

Рисунок 9 – Диаграмма классов ИСЭД

Один из главных вариантов использования ИСЭД – это построение дерева обработки документа, в котором отражена вся история документа: от момента его создания, включая все этапы согласований и перенаправлений, и заканчивая подписанием документа в архив.

Создадим диаграмму коопераций для варианта использования: Построить «дерево» ЖЦ документа.

На рисунке 10 приведена результатная диаграмма кооперации ИСЭД для варианта использования «Построить «дерево» ЖЦ документа».

Рисунок 10 – Диаграмма кооперации ИСЭД для ВИ «Показать «дерево» ЖЦ документа».

Таким образом, в ВИ участвуют следующие кооперации:

Инициализация документа из БД.
Вызов команды построения дерева ЖЦ.
Чтение событий, связанных с документом.
Инициализация этих событий (из БД).
Загрузка формы построения дерева ЖЦ.
Построение дерева из данных прочитанных событий.

Еще одним важным процессом документооборота в ИСЭД является вариант использования «Исполнить документ».

Создадим диаграмму последовательности для варианта использования «Исполнить документ»

На рисунке 11 приведена результатная диаграмма последовательности сообщений ИСЭД для варианта использования «Исполнить документ».

Рисунок 11 – Диаграмма последовательности сообщений ИСЭД для ВИ «Исполнить документ»

Из диаграммы видны сообщения между участниками ВИ:

Команда: показать текущие задачи исполнителя.
Загрузка задач из БД.
Создание формы списка задач.
Загрузка формы списка задач.
Обновление списка задач на форме.
Выбор исполнителем задачи, которую необходимо исполнить (соотнесение с соответствующим документом).
Создание объекта «Документ».
Инициализация данных документа из БД.
Команда исполнителя на исполнение задачи (документа).
Создание нового события, связанного с документом.
Запись нового события (события исполнения документа) в базу данных.
Обновление в базе данных статуса выбранного документа (с отметкой даты исполнения).
Обновление списка задач исполнителя.

Помимо объектной архитектуры, важно также правильно выстроить модульную архитектуру программного обеспечения ИСЭД, то есть определить состав ее компонентов.

Так, основными компонентами ИСЭД являются:

набор функциональных библиотек, входящих в состав пакета .NET Framework версии 4.5;
библиотека MS Office Object Library, требуемая для возможности работы с документами MS Word;
непосредственно исполняемый файл приложения ИСЭД – Application;
ресурсы приложения, в частности иконка – ApplicationIcon;
библиотека MySQL.Data.dll, необходимая для работы приложения с адаптерами таблиц и соединения с провайдером СУБД MySQL;
сам сервер БД, выполненный на базе MySQL;
сервер документов, в каталогах которого будут храниться файлы, которые являются приложениями к документам.

На рисунке 12 приведена результатная диаграмма компонентов информационной системы.

Рисунок 12 – Диаграмма компонентов ИС

На рисунке 13 показана типовая техническая архитектура, поддерживающая ИСЭД.

Рисунок 13 – Техническая архитектура ИСЭД

Основными компонентами диаграммы развертывания ИСЭД являются:

рабочие станции (компьютеры) пользователей, на которых установлено приложение ИСЭД;
сервер базы данных, на котором установлена клиент-серверная СУБД MySQL и создана база данных ИСЭД;
сервер файлов, на котором размещены директории для хранения файлов, прикрепляемых к электронным документам; предполагаемая схема хранения файлов состоит в следующем: для каждого документа в директории создается новая папка, имеющая в качестве названия номер документа – в эту папку будут сохраняться все файлы, прикрепленные к данному документу;
устройства, входящие в инфраструктуру локальной сети предприятия: коммутаторы, хабы, маршрутизаторы и т.д.

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

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

Рисунок 14 – Инфологическая модель данных ИСЭД

В таблице 1 приведена спецификация сущности «Posts» – должности.

Таблица 1

Спецификация сущности «Posts»

Атрибут	Тип	Ключ	Описание
ID	Число	PK	Идентификатор
Name	Текст	-	Наименование

В таблице 2 приведена спецификация сущности «Departments» – подразделения.

Таблица 2

Спецификация сущности «Departments»

Атрибут	Тип	Ключ	Описание
ID	Число	PK	Идентификатор
Name	Текст	-	Наименование

В таблице 3 приведена спецификация сущности «Accounts» – аккаунты.

Таблица 3

Спецификация сущности «Accounts»

Атрибут	Тип	Ключ	Описание
ID	Число	PK	Идентификатор (например, табельный номер сотрудника)
Furname	Текст	-	Фамилия
Firstname	Текст	-	Имя
Secondname	Текст	-	Отчество
Login	Текст	-	Логин
Password	Текст	-	Пароль
AccessID	Число	-	Идентификатор типа учетной записи пользователя, определяющий его права доступа к функциям ИСЭД
PostID	Число	FK	Идентификатор должности
DepartmentID	Число	FK	Идентификатор подразделения

В таблице 4 приведена спецификация сущности «Tasks» – задачи.

Таблица 4

Спецификация сущности «Tasks»

Атрибут	Тип	Ключ	Описание
ID	Число	PK	Идентификатор
SenderID	Число	FK	Идентификатор создателя
ReceiverID	Число	FK	Идентификатор исполнителя
DocumentID	Число	FK	Идентификатор документа
Content	Текст	-	Содержимое задачи
CreateDate	Дата	-	Дата создания задачи
Deadline	Дата	-	Срок исполнения задачи
DateOK	Дата	-	Дата исполнения задачи

В таблице 5 приведена спецификация сущности «Documents» – документы.

Таблица 5

Спецификация сущности «Documents»

Содержание

Атрибут	Тип	Ключ	Описание
ID	Число	PK	Идентификатор
Name	Текст	-	Наименование
Content	Текст	-
CreatorID	Число	FK	Идентификатор создателя
DocType	Текст	-	Тип документа
CreateDate	Дата	-	Дата создания документа
Deadline	Дата	-	Срок исполнения документа

В таблице 6 приведена спецификация сущности «Events» – события.

Таблица 6

Спецификация сущности «Events»

Атрибут	Тип	Ключ	Описание
ID	Число	PK	Идентификатор
DocumentID	Число	FK	Идентификатор документа
ActorID	Число	FK	Идентификатор инициатора
Event	Текст	-	Описание события
DateTime	Дата и время	-	Дата и время события

Все связи инфологической модели ИСЭД относятся к типу «один ко многим».

Моделирование бизнес-процессов «как должно быть»

На рисунках 15 – 18 приведены диаграммы бизнес-процессов «как должно быть» с учетом предложенного внедрения ИСЭД в бизнес-процессы обеспечения автоматизации документооборота.

В контекстную диаграмму «TO-BE» добавляется новый механизм – новая система ИСЭД (рисунок 15).

Рисунок 15 – Контекстная диаграмма IDEF0 (TO-BE) процесса документооборота

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

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

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

Эти изменения отображены на диаграмме декомпозиции процессов документооборота на рисунке 16.

Рисунок 16 – Диаграмма декомпозиции IDEF0 (TO-BE) документооборота

Декомпозиция задачи создания документов полностью переработана и отображена на диаграмме на рисунке 17.

Рисунок 17 – Диаграмма декомпозиции IDEF0 (TO-BE) создания документа

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

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

Изменения в информационных потоков при новой системе документооборота с использованием ИСЭД приведено на диаграмме потоков данных на рисунке 18.

Рисунок 18 – Диаграмма потоков данных (TO-BE) процесса документооборота

Выводы по главе

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

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

Заключение

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

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

Для устранения выявленных недостатков были предложены цели оптимизации проекта, его исполнители, механизмы и средства его реализации. По результатам предложений был проведен реинжиниринг разработанной схемы IDEF0 процесса. Новая схема IDEF0 предполагает разработку и внедрение ИСЭД.

В работе были разработаны модели бизнес-процессов (реинжиниринг: IDEF0 TO-BE), модели системы в нотации UML 2.0.

В работе были использованы такие программные средства автоматизированного проектирования информационных систем (CASE-системы), как:

AllFusion Process Modeler 7.1;
MS Visio 2013.

Cписок литературы

Арлоу Д. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование: пер. с англ. / Д. Арлоу, И. Нейштадт. – 2-е изд. – СПб.: Символ-Плюс, 2012. – 624 с.
Балдин К.В., Уткин В.Б. Информационные системы в экономике. М.– Издательский центр Академия, 2005 – 288 с.
Баранкова И.А. Нотация моделирования бизнес-процессов BPMN и ее применение при проектировании автоматизированных систем.: Молодежный научно-технический вестник. – Электронный журнал.: Изд. ФГБОУ ВПО «МГТУ им. Н.Э. Баумана». Эл. No. ФС77-51038
Бардина Н.В. Диаграмма классов и модель «сущность-связь» как логические модели информационной системы. // Модели, системы, сети в экономике, технике, природе и обществе. 2012., № 2 (3)
Буч Г. UML. Классика CS / Буч Г., Якобсон А., Рамбо Дж.; пер. с англ.; под общей ред. проф. С. Орлова. – СПб.: Питер, 2009. – [2-е изд.]. – 736 с.
Головичнер М Н. – Проектирование информационных систем. Методические указания по подготовке к государственному экзамену, Томск, 2009., 110 с.
Игонина Л.Л. Инвестиции: Учеб. пособие / Под ред. д-ра экон. наук, проф. В.А. Слепова. — М.: Юрист, 2002. — 480 с.
Коцюба И.Ю., Чунаков А.В., Шишков А.Н. – Основы проектирования информационных систем. Учебное пособие. – СПб: Университет ИТМО, 2015. – 206 с.
Маклаков С. В. – ERWin и BPWin. CASE-средства разработки информационных систем. М., 1999
Малыхина М. П. Базы данных. Основы, проектирование, использование. – БХВ-Петербург, 2013. – 528 с
Нотация BPMN. Электронный ресурс: [Режим доступа]: http://bpmsoft.org/bpmn/
Тасваева А.Н. Диаграммы потоков данных и вариантов использования как инструменты проектирования информационных систем. // Модели, системы, сети в экономике, технике, природе и обществе. 2012., № 2 (3)
Самуйлов К.Е., Серебренникова Н.В., Чукарин А.В., Яркина Н.В. «Основы формальных методов описания бизнес-процессов»: Учеб. пособие. – М.: РУДН, 2008. – 130 с.: ил.
Object Management Group Inc., UML 2.0 Infrastructure Specification: Document number 03-09-15 (Спецификация инфраструктуры языка UML 2.0: Документ номер 03-09-15). сентябрь 2003 г.
Orientsoft. Software development & Business consulting. Функциональное моделирование на базе IDEF0. Учебный курс – Минск: 2002 – 35с.