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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

ИСЭД

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Команда: показать текущие задачи исполнителя.
2. Загрузка задач из БД.
3. Создание формы списка задач.
4. Загрузка формы списка задач.
5. Обновление списка задач на форме.
6. Выбор исполнителем задачи, которую необходимо исполнить (соотнесение с соответствующим документом).
7. Создание объекта «Документ».
8. Инициализация данных документа из БД.
9. Команда исполнителя на исполнение задачи (документа).
10. Создание нового события, связанного с документом.
11. Запись нового события (события исполнения документа) в базу данных.
12. Обновление в базе данных статуса выбранного документа (с отметкой даты исполнения).
13. Обновление списка задач исполнителя.

---

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

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

• набор функциональных библиотек, входящих в состав пакета .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	Дата	-	Дата исполнения задачи

---