Рис.12 Декомпозиция модели документооборота входящих документов

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

Способ исполнения документа зависит от решения, принятого адресатом.

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

На рис.13 представлен фрагмент, иллюстрирующий процесс исполнения документа.

Рис.13 Исполнение документа

Остановимся подробнее на процессе под названием «Резолюция».

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

Рис.14 Создание резолюций на документ

У каждой резолюции должен быть исполнитель (Executer1 для Resolution111, Executer2 для Resolution112, Executer3 для Resolution113). При создании резолюции на документ создается соответствующая карточка резолюции. Далее резолюции проходят процесс исполнения, и данные об исполнении резолюции заносятся в специальные отчеты.

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

В системе электронного документооборота CompanyMedia поддерживается иерархическая структура хранения данных входящей документации. Это означает организацию информации по принципу родитель-потомок. Разрабатывать алгоритмы построения типовых бизнес-процессов, используя иерархические базы данных, довольно трудоемкая задача, требующая очень больших затрат мощности ЭВМ и определенного времени для написания сложных запросов. В данной работе предложен алгоритм решения задачи на основе реляционной модели данных. Реляционная модель предполагает использование таблиц, в которых содержатся все необходимая для работы информация. Данные в любой записи из таких таблиц связаны только с одним конкретным объектом. В качестве системы управления базы данных был выбран Microsoft Sql Server и Microsoft Management Studio в качестве среды для работы с СУБД.

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

Однако в системе CompanyMedia разработан специальный сервис под названием «Центр отчетов», позволяющий извлекать данные и выгружать их в xls-формате. Далее требуется провести преобразование xls-формата в формат dbo стандартными средствами импорта данных.

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

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



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

Во второй главе проанализированы современные системы электронного документооборота. Описаны основные наиболее важные с точки зрения решения задачи объекты СЭД CompanyMedia. Построена модель выявления типовых бизнес-процессов на основе слабоструктурированных данных.



Глава 3. Реализация алгоритмов построения деловых процессов на основе реляционной модели

3.1 Сервис построения отчетов

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

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

Подготовка данных для входа в построенную модель для решения поставленной задачи предполагает использование Центра отчетов.

С помощью сервиса «Центр отчетов» данные переводятся из иерархического вида в набор таблиц в формате xls. В таблицу 1 будут загружены документы формы РКК. В таблицу 2 лист ознакомления с документом. Каждая исполненная резолюция заданного уровня будет выгружена в свою таблицу. Запись таблицы соответствует документу со своим идентификатором doc_id. У документа есть ссылка на родителя ref (в реляционной модели полю ref соответствует поле par_id). Если документ сам является родителем, то в ref ставится 0. Остальные поля определены с точки зрения их необходимости для решения задачи. Их описание будет приведено в следующем пункте.

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

3.2 Алгоритм построения типовых бизнес-процессов

3.2.1 Проектирование реляционной модели

При проектировании баз данных в реляционной модели следует учитывать специфику документооборота системы CompanyMedia. Набор таблиц в БД будет отражать движение связанных документов по рабочим местам.

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

В БД формата Notes у главного документа может быть 32 ответных одного уровня, т.е. в БД можно зафиксировать до 32 резолюций 1-го уровня, у каждой резолюции 1-го уровня может быть до 32 резолюций 2-го уровня, у каждой резолюции 2-го уровня может быть до 32 резолюций 2-го уровня и так далее, пока хватит памяти. В работе алгоритм протестирован на первых трех уровнях, дальнейшее углубление идейно ничего не изменит, а повлечет лишь увеличение объема данных.

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

Для формы «РКК» значимыми полями будут являться:

· вид документа;

· корреспондент;

· подписант;

· адресат;

· место регистрации.

Значимые поля формы «Резолюция»:

· автор;

· исполнитель.

Используемые поля формы «Ознакомление»:

· инициатор;

· участник.

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

Для тестирования алгоритма с помощью среды Microsoft Management Studio созданы следующие таблицы:

1. таблица карточки документа CardDocs;

2. лист ознакомления LO1;

3. карточки резолюции:

3.1. R111 - резолюция 1-ого уровня;

3.2. R121 - резолюция 1-ого уровня;

3.3. R131 - резолюция 1-ого уровня;

3.4. R211 - резолюция 2-ого уровня;

3.5. R311 - резолюция 3-его уровня;

А также таблицы со справочными данными:

4. Departs - справочник отделов в организации;

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

6. Organizations - справочник организаций;

7. Posts - справочник должностей в организации.

В таблицах пунктов 1-3 первичным ключом являются Id документов. Также во всех таблицах предполагается существование внешнего ключа по полю par_id (ссылка на документ). Внешний ключ будет ссылаться на Id документа в предшествующей таблице.

Для таблицы LO1 и резолюций 1-ого уровня (R111, R121, R131) внешний ключ будет ссылаться на Id документа из таблицы CardDocs. Резолюция 2-ого уровня R211 ссылается на Id Документа из таблицы R111. Резолюция 3-его уровня R311 - на таблицу R211.

Тем самым обеспечивается целостность спроектированной базы данных.

3.2.2 Построение типовых бизнес-процессов

По данным на основе имеющихся таблиц строится матрица М1 из 0 и констант. Столбцы матрицы М1 соответствуют значимым полям и рабочим местам, по которым проходил документ. 0 означает, что по данному рабочему месту документ не проходил. Константы - это участие данного рабочего места в бизнес-процессе, а также конкретное местонахождение документа определенного типа на определенном этапе.

M1_m*n Где _m - количество документов; _n - количество значимых полей в сумме с возможными бизнес-процессами организации

Для построения матрицы M1 используется запрос и средства конкатенации таблиц по их идентификатору и ссылке на родителя. Соединение таблиц реализовано с помощью оператора left join. Оператор left join позволяет выполнить объединение записей из двух таблиц, даже если во второй таблице нет никаких данных о документе. В таком случае в полях проставляется значение Null (0).

На основе матрицы M1 строится матрица M2. Строки матрицы М2 представляют собой документы определенного типа. Тип определяется набором значимых полей. Столбцы матрицы M2 представляют собой значимые поля, определяющие тип документа, а также количество прохождения документов заданного типа по определенным рабочим местам.

M2_m2*n2 Где _m2 - количество документов определенного типа; _n2 - количество значимых полей в сумме с количеством бизнес-процессов организации

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

Описанный выше алгоритм удобно представить в виде блок-схемы (рис.15).

Рис.15 Блок-схема алгоритма построения типовых бизнес-процессов



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

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



Заключение

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

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



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

1. Андерсен Б. Бизнес-процессы. Инструменты совершенствования. - М.: РИА «Стандарты и качество», 2003.- 272 с.

2. Вендров А.М. Проектирование программного обеспечения. - М.: Финансы и статистика, 2000 - 77 с.

3. Елиферов В.Г., Репин В.В. Процессный подход к управлению. - М.: РИА «Стандарты и качество», 2005. - 406 с.

4. Мичи Д., Джонатон Р. Реляционные СУБД. 2004г. №8, стр. 4

5. Нaучно-учебная лаборатория процесснo-oриентированных инфoрмaционных систем (ПOИС). -- http://pais.hse.ru/

6. Бaрсегян А.А. Технoлогии aнализа данных: Dаta Mining, Visual Mining, Text Mining, OLAP / А.А. Барсeгян, М.С. Куприянoв, В.В. Степаненкo, И.И. Хoлод. - СПб.: БХВ - Пeтербург, 2007. - С. 190 - 204.

7. Кисeлев М., Солoматин Е.. Срeдства дoбычи знaний в бизнeсе и финaнсах. -- Открытые систeмы, № 4, 1997, с. 40-44.



Приложение

Листинг 1 файл SelectIntoBusprocM1.sql

select

c.doc_id,

o.org_name,

p.post_name as adr,

a.post_name as author,

d.typ_name as doc_typ,

dep.dep_name as reg_name --карточка ,

l1.doc_id as doc_idl,

pl1a.post_name as adrl,

pl1e.post_name as ex,

l1.par_id as pidl--ЛО1 ,

r111.rdoc_id as rdoc_id111,

pr111a.post_name as adr111,

pr111e.post_name as ex111,

r111.par_id as pid111 --Рез111 ,

r211.rdoc_id as rdoc_id211,

pr211a.post_name as adr211,

pr211e.post_name as ex211,

r211.par_id as pid211 --Рез211 ,

r311.rdoc_id as rdoc_id311,

pr311a.post_name as adr311,

pr311e.post_name as ex311,

r311.par_id as pid311 --Рез311 ,

r121.rdoc_id as rdoc_id121,

pr121a.post_name as adr121,

pr121e.post_name as ex121,

r121.par_id as pid121 --Рез121 ,

r131.rdoc_id as rdoc_id131,

pr131a.post_name as adr131,

pr131e.post_name as ex131,

r131.par_id as pid131 --Рез131

into

busproc

from

CardDocs c

left join

Organizations o

on o.org_id=c.org_id --Организации

left join

Posts p

on p.post_id=c.adr_id --Адресат

left join

Posts a

on a.post_id = c.author -- Автор

left join

Doc_type d

on d.typ_id = c.doc_id -- Вид докум

left join

Departs dep

on dep.dep_id = c.reg_id -- Место регистрации

left join

LO1 l1

on c.doc_id = l1.par_id --ЛО1

left join

Posts pl1a

on pl1a.post_id=l1.adr_id --Адресат ЛО1

left join

Posts pl1e

on pl1e.post_id=l1.ex_id --Исполнитель Л

left join

Res111 r111

on c.doc_id = r111.par_id --Рез111

left join

Posts pr111a

on pr111a.post_id=r111.adr_id --Адресат Рез111

left join

Posts pr111e

on pr111e.post_id=r111.ex_id --Исполнитель Рез111

left join

Res211 r211

on r111.rdoc_id = r211.par_id --Рез211

left join

Posts pr211a

on pr211a.post_id=r211.adr_id --Адресат Рез211

left join

Posts pr211e

on pr211e.post_id=r211.ex_id --Исполнитель Рез211

left join

Res311 r311

on r211.rdoc_id = r311.par_id --Рез311

left join

Posts pr311a

on pr311a.post_id=r311.adr_id --Адресат Рез311

left join

Posts pr311e

on pr311e.post_id=r311.ex_id --Исполнитель Рез311

left join

Res121 r121

on c.doc_id = r121.par_id --Рез121

left join

Posts pr121a

on pr121a.post_id=r121.adr_id --Адресат Рез121

left join

Posts pr121e

on pr121e.post_id=r121.ex_id --Исполнитель Рез121

left join

Res131 r131

on c.doc_id = r131.par_id --Рез131

left join

Posts pr131a

on pr131a.post_id=r131.adr_id --Адресат Рез131

left join

Posts pr131e

on pr131e.post_id=r131.ex_id --Исполнитель Рез131

Листинг 2 файл SelectFromBusprocM2.sql

select

org_name ,

adr ,

doc_typ ,

reg_name ,

count(adr) am_adr ,

adrl ,

ex ,

count(ex) am_ex ,

adr111 ,

ex111 ,

count(ex111) am_ex111 ,

adr211 ,

ex211 ,

count(ex211) am_ex211 ,

adr311 ,

ex311 ,

count(ex311) am_ex311 ,

adr121 ,

ex121 ,

count(ex121) am_ex121 ,

adr131 ,

ex131 ,

count(ex131) am_ex131

into busproc2

from

busproc

group by

org_name ,

adr ,

doc_typ ,

reg_name ,

adrl ,

ex ,

adr111 ,

ex111 ,

adr211 ,

ex211 ,

adr211 ,

ex211 ,

adr311 ,

ex311 ,

adr121 ,

ex121 ,

adr131 ,

ex131

Листинг 3 файл SelectFromBusprocEff.sql

select

org_name ,

adr ,

doc_typ ,

reg_name ,

max(am_adr) am_adr ,

adrl ,

ex ,

max(am_ex) am_ex ,

adr111 ,

ex111 ,

max (am_ex111) am_ex111 ,

adr211 ,

ex211 ,

max (am_ex211) am_ex211 ,

adr211 ,

ex211 ,

max(am_ex311) am_ex311 ,

adr311 ,

ex311 ,

max (am_ex311) am_ex311 ,

adr121 ,

ex121 ,

max (am_ex121) am_ex121 ,

adr131 ,

ex131 ,

max (am_ex131) am_ex131

from

busproc2

group by

org_name ,

adr ,

doc_typ ,

reg_name ,

adrl ,

ex ,

adr111 ,

ex111 ,

adr211 ,

ex211 ,

adr211 ,

ex211 ,

adr311 ,

ex311 ,

adr121 ,

ex121 ,

adr131 ,

ex131

Листинг 4 файл Таблицы.xls - имеющиеся в БД таблицы с данными

Posts

post_id	post_name	post_dep
100	Ген.директор	NULL
101	Зам.директора	NULL
102	1-ый зам	NULL
103	2-ой зам	NULL
104	3-ий зам	NULL
105	4-ый зам	NULL
106	5-ый зам	NULL
107	Рук.отдела1	отдел1
108	Рук.отдела2	отдел2
109	Рук.отдела3	отдел3
110	Рук.отдела4	отдел4
111	Рук.отдела5	отдел5
112	Рук.отдела6	отдел6
113	Рук.отдела7	отдел7
114	Рук.отдела8	отдел8
115	Менеджер1	NULL
116	Менеджер2	NULL
117	Менеджер3	NULL
118	Менеджер4	NULL
119	Менеджер5	NULL
120	Менеджер6	NULL
121	Менеджер7	NULL
122	Сотр1	NULL
123	Сотр2	NULL
124	Сотр3	NULL

Departs

dep_id	dep_name
1	Отдел1
2	Отдел2
3	Отдел3
4	Отдел4

DocTypes

typ_id	typ_name
1	тип1
2	тип2
3	тип3



Organisations

org_id	org_name	org_date
1	Орг1	01.01.2010
2	Орг2	01.03.2010
3	Орг3	01.02.2010
4	Орг4	01.02.2012
5	Орг5	05.04.2011

LO1

doc_id	adr_id	org_id	par_id
1245	100	1	1

Res111 - аналогична R121, R131, R211, R311

rdoc_id	adr_id	ex_id	par_id
45	100	109	1

Вид матрицы связей M1 (busproc) из двух строк. Первая строка соответствует названиям столбцов, вторая - документу.

doc_id	org_name	adr	author	doc_typ	reg_name
1	Орг1	Ген.директор	Сотр1	тип1	Отдел1

doc_idl	adrl	ex	pidl
1245	Ген.директор	1-ый зам	1

rdoc_id111	adr111	ex111	pid111
45	Ген.директор	Рук.отдела3	1

rdoc_id211

adr211

ex211

pid211

rdoc_id311

adr311

ex311

pid311

rdoc_id121

adr121

ex121

pid121

25

Рук.отдела3

Менеджер1

45

154

Менеджер1

Менеджер2

25

110

Ген.директор

Рук.отдела2

1

rdoc_id131	adr131	ex131	pid131
547	Ген.директор	Рук.отдела4	1

Вид матрицы связей M2 (busproc2) из двух строк. Первая строка соответствует названиям столбцов, вторая - документам определенного типа.

org_name	adr	doc_typ	reg_name	am_adr
Орг1	Ген.директор	тип2	Отдел3	1

adrl	ex	am_ex
0	0	0

adr111	ex111	am_ex111	adr211	ex211	am_ex211	adr311	ex311	am_ex311
0	0	0	0	0	0	0	0	0

adr121	ex121	am_ex121	adr131	ex131	am_ex131
0	0	0	0	0	0

Размещено на Allbest.ru

...