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

Разработка алгоритмов построения типовых бизнес-процессов на основе слабоструктурированных данных. Также построена модель выявления типовых бизнес-процессов описан механизм ее реализации. Анализ методов оценки эффективности бизнес процессов.

2015-10-20

755.56 KB

16 чел.


Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск


ФЕДЕРАЛЬНОЕ  ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Московский институт электроники и математики

Агапова Мария Анатольевна

«Разработка алгоритмов построения типовых бизнес-процессов на основе слабоструктурированных данных»

Выпускная квалификационная работа

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

                                                                       

Студент

___________________      М.А. Агапова

    

Рецензент

К.т.н., проф.,

М. Р. Биктимиров

Научный руководитель

К.т.н., доцент,

А.В. Белов

Консультант

Ст. преподаватель

Н.С. Березина

Москва 2015 г.

Аннотация

Цель данной работы - разработка алгоритмов построения типовых бизнес-процессов на основе слабоструктурированных данных. В работе проводится исследование методов оценки эффективности типовых деловых процессов и делается выбор в пользу наиболее оптимального метода с точки зрения поставленной задачи. Также построена модель выявления типовых бизнес-процессов, описан механизм ее реализации. Разработанные алгоритмы протестированы средствами СУБД Microsoft SQL Server. Результаты работы могут оказаться полезными для организаций с нерегламентированным документооборотом.


Development of Algorithms for Constructing Standard Business Processes on the Basis of Semi-Structured Data

by

Agapova M.A.

Abstract

The purpose of this work is developing of algorithms for constructing standard business processes on the basis of semi-structured data. The methods of evaluating the effectiveness of business processes are investigated and the choice in favor of the most optimal from the point of view of the task is made. Also the model for constructing business processes is built and the implementation mechanism is described. The algorithms are tested in DBMS Microsoft SQL Server. The results can be useful for organizations with unregulated flow of documents.


Оглавление

[1] Аннотация

[2] Development of Algorithms for Constructing Standard Business Processes on the Basis of Semi-Structured Data

[3] Abstract

[4] Оглавление

[5] Введение

[6] Глава 1. Анализ современного состояния проблемы оценки эффективности деловых процессов организации

[6.1] Документооборот в организации как основа описания деловых процессов. Основные понятия и определения

[6.2] Анализ методов оценки эффективности бизнес процессов

[6.2.1] Cost Analysis

[6.2.2] Методы имитационного моделирования

[6.2.3] Интеллектуальный анализ процессов

[6.3] Постановка задачи анализа эффективности деловых процессов на основе данных системы электронного документооборота

[7] Выводы по главе 1

[8] Глава 2. Построение информационной модели деловых процессов на базе СЭД

[8.1] Анализ современных СЭД

[8.2] Основные информационные объекты в СЭД

[8.3] Построение модели выявления типовых бизнес-процессов

[9] Выводы по главе 2

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

[10.1] Сервис построения отчетов

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

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

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

[11] Выводы по главе 3

[12] Заключение

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

[14] Приложение

Введение

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

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

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

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

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

В третьей главе приведено описание и тестирование алгоритма.

В заключении сделаны основные выводы о результатах решения задачи.  

Глава 1. Анализ современного состояния проблемы оценки эффективности деловых процессов организации

  1.  Документооборот в организации как основа описания деловых процессов. Основные понятия и определения

«Документ» или по-латински “documentum” означает свидетельство, доказательство. Документ означает определенным способом оформленные письменные источники, которые имеют юридическую силу.

Электронный документ – набор информации, сопровождаемый специальной карточкой с атрибутами, по которым можно найти документ.

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

Реквизиты документа вместе с их схемой расположения образуют формуляр.  Единство документирования обеспечивается установленным государственным стандартом формуляром. Типовой формуляр – это формуляр, который характерен для определенного вида документов.

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

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

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

Электронный документооборот как способ организации работы с документами подразумевает хранение основной массы документов централизованно в электронном виде.

Документопоток объединяет все документы предприятия, которые двигаются по определенным инструкциям. Благодаря их соблюдению, предприятие работает бесперебойно.

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

  •  внутренние документы – это документы, необходимые для реализации внутренних задач организации;
  •  исходящие документы  - документы, созданные данной организацией для передачи какой-либо информации;
  •  входящие документы – документы, которые были получены от сторонних предприятий

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

Операции над документом предусматривают несколько стадий: рассмотрение, согласование, исполнение, утверждение, подписание.

Поток работ или Workflow – это алгоритм действий сотрудников в границах данного бизнес процесса. Например, получение документа, его регистрация, рассмотрение, исполнение.

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

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

Однако не все действия в рамках бизнес-процесса описываются формальным языком. Данные, на основе которых строится бизнес-процесс, бывают трех видов:

  •  Структурированные
  •  Слабоструктурированные
  •  Неструктурированные

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

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

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

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

Можно выделить следующие этапы документооборота:

  •  Прием и обработка входящих документов;
  •  Резолюция;
  •  Работы с исходящими документами.

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

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

Следующий этап движения документа  - это процесс его рассмотрения или этап резолюции.

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

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

Рис.1 Внесение резолюции

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

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

  1.  Анализ методов оценки эффективности бизнес процессов
    1.  Cost Analysis

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

Конечные цели анализа могут быть:

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

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

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

В данной работе функциональная модель может быть построена с помощью инструмента визуального моделирования бизнес процессов AllFusion Process Modeler (Bpwin). Инструмент BPWin поддерживает два типа функциональных моделей: AS-IS и TO-BE. Из названий видно, что первая модель строится на основе существующей организации бизнес процессов. Как правило, она предшествует модели TO-BE. Вторая модель является результатом анализа  бизнес процессов существующей модели. Моделей TO-BE может быть несколько. Выбор наиболее эффективной происходит по какому-либо критерию.

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

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

Рис.2 Цель построения модели

 Правильно сформулированная цель помогает в дальнейшем аналитикам фокусировать внимание и двигаться в нужном направлении.

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

Рис.3 Функциональная модель бизнес процесса организации движения с документами

Как видим на рисунке 3, в качестве входных данных подаются документы. Управление бизнес-процессом реализуется в виде регламента работы с документами (в нашем случае – регламентом).  Сканеры, СЭД и анализатор представляют собой механизмы, выполняющие работу. Результатом выхода у нас являются бизнес-процессы движения документов.

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

На рисунке ниже представлен фрагмент декомпозиции работы «Организация движения документов»:

Рис.4 Диаграмма декомпозиции диаграммы «Организация движения документов»

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

Здесь стоимостный анализ основан на работах (ABCActivity Based Costing). Оценивание производится посредством выявления стоимости выполнения определенной функции. Инструмент BPwin позволяет выбрать валюту и единицу измерения времени.

Для анализа ABS необходимо ввести следующие понятия:

  •  объект затрат;
  •  двигатель затрат;
  •  центры затрат.

Под объектом затрат понимается выход работы. Сумма стоимости объектов затрат представляет собой стоимость работ.

Двигатель затрат – это некоторые характеристики управлений  и входов функций. Они влияют на выполнение и длительность работы.

Центры затрат – это некоторые статьи расхода.

На рисунке ниже представлен фрагмент, отображающий центры затрат построенной модели с указанием стоимости каждой:

Рис.6 Центры затрат

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

Результат стоимостного анализа можно представить в виде отчета и распечатать в файле:

Number: 1

Name: Registration

Activity Cost    ($ U.S.): 95 000,00

Cost Center: Components

Cost Center Cost ($ U.S.): 25 000,00

Cost Center: Management

Cost Center Cost ($ U.S.): 40 000,00

Cost Center: Work force

Cost Center Cost ($ U.S.): 30 000,00

Number:   1.1

Name: Document entry

Activity Cost    ($ U.S.): 45 000,00

Cost Center: Components

Cost Center Cost ($ U.S.): 10 000,00

Cost Center: Management

Cost Center Cost ($ U.S.): 20 000,00

Cost Center: Work force

Cost Center Cost ($ U.S.): 15 000,00

Number:   1.2

Name: Acess to documents

Activity Cost    ($ U.S.): 50 000,00

Cost Center: Components

Cost Center Cost ($ U.S.): 15 000,00

Cost Center: Management

Cost Center Cost ($ U.S.): 20 000,00

Cost Center: Work force

Cost Center Cost ($ U.S.): 15 000,00

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

Иногда стоимостных показателей оказывается недостаточно для проведения анализа. В этом случае пользователю предлагается внести собственные свойства – метрики (UDPUser-Defined Properties). Результат также можно проанализировать в специальном отчете.

  1.  Методы имитационного моделирования

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

Модель, построенная с помощью имитационного моделирования, включает в себя следующие элементы:

  •  источники и стоки;
  •  очереди;
  •  процессы.

Информация и объекты поступают в модель через источники. Их прием обеспечивается стоком.

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

Процессы в имитационном моделировании аналогичны работам (Activity) в стоимостном анализе (cм. п.1.2.1). Стоит отметить, что в данной модели возможно задать производительность процессов.

Алгоритм моделирования системы можно условно разделить на четыре пункта:

  1.  Построить модель процесса (или процессов), который хотим проанализировать.
  2.  Запустить имитацию выполнения построенных моделей процессов.
  3.  Проанализировать результаты.
  4.  Если требуется, повторить предыдущие пункты для других сценариев выполнения процесса.

Вначале необходимо выбрать  стартовое событие, являющееся началом выполнения процесса. Допустим, стартовым событием является поступление документа в канцелярию.  Периодичность поступления документов может быть разной. Какие-то события возникают в определенный момент времени (канцелярия работает с 9 до 18.00), какие-то – через определенные интервалы (документы поступают каждые N – минут). При этом интервал повторений событий – величины случайные. Далее требуется задать длительность шага. Длительность может быть как постоянной величиной, так и случайной. В зависимости от вида документа, квалификации сотрудника и исполняемой задачи время работы может увеличиваться или уменьшаться. Выбор следующего шага имеет вероятностный характер. Например, вероятность, что документ Д отправится к сотруднику А составляет 0.6, к сотруднику Б – 0.3, к сотруднику В – 0.1. Для оценки стоимости процесса для каждого шага задаем стоимость ресурсов – трудовых или материальных.

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

Существуют несколько направлений в теории имитационного моделирования. Каждое направление характеризуется своими инструментальными средствами и системами имитационного моделирования. Приведем несколько примеров:

  •  Моделирование динамических систем (реализуется в системах MATLAB Simulink, VimSim и др.);
  •  Дискретно-событийное моделирование (Arena, Aris, AnyLogic, AutoMod и др.);
  •  Системная динамика (PowerSim, iThink. AnyLogic и др.);
  •  Агентное моделирование (Swarm, AnyLogic, Repast и др.);

Системная динамика и моделирование динамических систем предполагают непрерывные во времени процессы. Дискретно-событийное и агентное моделирования – дискретные.

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

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

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

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

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

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

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

  1.  Интеллектуальный анализ процессов 

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

Принцип Process Mining достаточно прост: имея след исполнения бизнес-процесса, можно восстановить цепочку событий, произошедших в реальности.

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

Process Mining не анализирует сами данные и не занимается установкой низкоуровневых закономерностей. Предметом его анализа являются данные анализа бизнес-процессов.

Задачи Process Mining состоят в получении ответов на вопросы:

  •  Производительность или эффективность бизнес-процессов
  •  Согласованность бизнес-процессов

В качестве исходных данных используется журнал событий. Строка в таком журнале представляет отдельное событие.

Каждый журнал должен содержать некоторые атрибуты, характеризующее событие:

  •  Идентификатор события
  •  Деятельность – выполняемые действия
  •  Время – дата и время регистрации события
  •  Прочая информация

Основные идеи методов интеллектуального анализа процесса состоят в следующем:

У нас есть некоторое множество реальных бизнес-процессов, сотрудников, компонентов, сред взаимодействий. Исполнители данных объектов взаимодействуют с информационной системой, и в качестве выходных данных выступают некоторые записи, сообщения, транзакции. Эти записи представляют собой события, отраженные в журнале лог. На основе таких событий происходит выявление, анализ бизнес-процессов и построение их модели средствами  Process Mining. Построенные модели бизнес-процессов анализируются сотрудником и вносятся решения об изменениях, модернизации БП.

Рис.7 Применение Process Mining

К примерам инструментария, который содержит функционал Process Mining, относят продукт ARIS PPM, ProcessAnalyzer, системы Disco и другие.

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

  1.  Постановка задачи анализа эффективности деловых процессов на основе данных системы электронного документооборота

В работе рассматриваются документы базы данных Domino/Notes системы электронного документооборота CompanyMedia.  Company Media поддерживает документооборот организации холдингового типа.

Документы проходят стандартные этапы обработки в СЭД, включая регистрацию, предварительную обработку, при необходимости создание резолюций на его основе, исполнение и со временем отправление в архивное хранение. Для оптимальной  организации работы с документами в СЭД CompanyMedia была разработана подсистема «СМ - адаптивный case-менеджмент».

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

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

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

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

Для решения поставленной задачи необходимо:

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

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

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

Глава 2. Построение информационной модели деловых процессов на базе СЭД

  1.  
    1.  Анализ современных СЭД

Работа с информацией занимает до 80% рабочего времени у руководителя. Около 30%  рабочего времени занимает создание, поиск, согласование и отправка документов. Внутренние документы копируются приблизительно до 20 раз, теряется без возможности возврата около 6% документов. На основе такой статистике нетрудно сделать вывод, насколько сильно зависит эффективность выполнения бизнес-процессов и организации в целом от качества и эффективности работы документооборота. Решением проблемы для крупных организаций явились системы электронного документооборота.

Ключевые принципы СЭД:

  •  Однозначная идентификация документа посредством однократной регистрации документа;
  •  Параллельное выполнение операций как возможность повысить оперативность исполнения документов и сокращение времени их движения;
  •  Непрерывное движение документов с целью идентификации исполнителя в каждый момент времени жизни процесса;
  •  Исключение возможности дублирования документов и ведение единой базы информации;
  •  Эффективный поиск документов;
  •  Система отчетности для контроля движения документов и принятия управленческих решений.

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

  1.  Workflow
  2.  DMS
  3.  Groupware

Остановимся подробнее на каждом из них.

Workflow

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

DMS (Document Management System)

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

По мере развития систем появились дополнительные функции, например:

  1.  картотека документов, средства быстрой разработки электронных форм;
  2.  справочники для заполнения карточек;
  3.  поддержка описания процесса обработки документов;
  4.  организация информации о документах для учета;
  5.  возможность свободной маршрутизации документов;
  6.  возможность описания жизненного цикла документа;
  7.  контроль маршрутизации процессов.

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

GroupWare

Идея данной концепции состоит в создании максимально удобной среды доступа к информации, а также групповая работа с ней. К данным системам можно отнести LinkWorks и Lotus Notes.

К GroupWare относят следующие задачи:

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

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

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

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

Важным свойством СЭД является возможность интеграции системы с другими программными обеспечениями. Это обеспечивается благодаря таким технологиям, как OLE Automation, DDE, ODMA и другие. Пользователи работают с привычными приложениями для обработки документов, но в эти прикладные программы во время установки клиентской части СЭД внедрятся функции и компоненты меню системы. То есть, при работе с текстовым редактором MS Word, пользователю при открытии файла видны библиотеки и папки СЭД. Сохранение файла также происходит в баз данных СЭД.  

Некоторые СЭД предусматривают интеграцию с ERP-системами (например, Oracle, ERP галактика). Это означает, что такая система электронного документооборота выступает в роли связующего звена между компонентами информационной системы компании.

Архитектура большинства систем электронного документооборота распределенная с иерархической структурой хранения документов.

Остановимся подробнее на системе электронного документооборота Company Media.

CompanyMedia (CM) предназначена для решения задач информационной поддержки и автоматизации документационного обеспечения управления Компании со сложной организационной структурой, в том числе территориально-распределенной.

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

Рис.8 Элементы СЭД Company Media

Список прикладных подсистем

  •  СМ-Делопроизводство
  •  СМ-Обращения граждан
  •  СМ-Документы
  •  СМ-Нормативные и распорядительные документы (СМ-НРД)
  •  СМ-Поручения
  •  СМ-Договоры
  •  СМ-Заседания
  •  СМ-Управление персоналом
  •  СМ-Планирование
  •  СМ-Клиенты и контакты
  •  СМ-Факс
  •  СМ-HelpDesk
  •  Автоматизированное рабочее место «Контроль исполнения поручений руководителей» (АРМ КИПР)

Каждая из перечисленных подсистем использует инфраструктуру AF 3.4, которая в свою очередь также состоит из подсистем:

  •  AF-Справочники
  •  AF-Портал
  •  AF-Сервис
  •  AF-WorkFlow
  •  AF-Администрирование

Кроме перечисленных прикладных подсистем в состав СМ входят:

  •  «СМ-Справка» - справочная информация о работе с базами данных
  •  «СМ 3.4 Documentation» - набор документации по СМ
  •  «AF ExecLibrary» - библиотека внешних программ, устанавливаемых на серверах и рабочих местах
  •  «Визуализация» - программные компоненты технологии VisualDocs, которые используются в СМ для графического отображения связей между документами
  •  «Locker-СМ» - дополнительно может быть использована подсистема защиты информации с помощью внешних криптографических средств. Устанавливается как на серверах, так и на рабочих местах и имеет собственные элементы настроек работы.

Архитектура СМ

Особенности архитектуры

  1.  Неограниченное количество рабочих мест сотрудников организации, которая обеспечивается установкой необходимого числа серверов системы и конфигурированием системы - увеличением числа системных организаций.
  2.  Неограниченное количество организаций (или территориально-удаленных филиалов) - при этом все организации работают со своими БД документов, но используются общие механизмы информационного взаимодействия между собой.
  3.  Работа с базами данных коллективного доступа и разграничение прав доступа к документам.
  4.  Передача документов между организациями на основе репликационных возможностей Lotus Notes (без использования почтовых механизмов), что обеспечивает 100% гарантию доставки информации.
  5.  Автоматическое поддержание целостности данных - реквизитов организаций, данных о сотрудниках, реквизитов документов за счет работы серверных программных агентов, которые отслеживают изменения справочников и первичных документов и корректируют документы по ссылкам.
  6.  Корпоративность работы пользователя, когда каждая из организаций (филиалов) ведет свою базу данных, которая через репликации распространяется во все другие организации. Все пользователи могут выбирать в качестве адресатов или исполнителей любого сотрудника Компании.
  7.  Механизмы замещения при работе с документами - предоставление постоянного или временного доступа к документам "замещающим" как самим сотрудником, кого замещают, так и администратором системы.
  8.  Разграничение функций по администрированию с использованием централизованного и децентрализованного способа управления системой.
  9.  Автоматическое управление объемами реплицируемых данных между удаленными площадками одной организации (между сетями) и между разными организациями.

Типы баз данных и комплекты системы

Главным элементом программного обеспечения СМ является БД формата Lotus Notes (*.nsf). Для определения пути к каждой БД используется база "Структура системы" (СС), где базы данных регистрируются. Для обеспечения собственной идентификации и однозначного поиска в СС необходимых других БД введено понятие типа БД.

Кроме типа базы данных в СС существует понятие комплекта БД. Цель использования комплекта - иметь возможность работы в рамках одной организации с несколькими однотипными БД. Например, при работе в БД «Входящие документы», отнесенной в СС к комплекту «Общий документооборот», в режиме редактирования карточки входящего документа и команде пользователя для вызова списка организаций идет поиск БД «Справочник организаций» в том же комплекте «Общий документооборот». В то же время, для совместимости с более ранними версиями СМ, а также для того, чтобы не надо было создавать все сервисные БД под каждое имя комплекта, в системе допускается иметь БД с неуказанным именем комплекта («пустой» комплект).  БД из пустого комплекта будут использоваться в работе, когда не будет найдена БД из одноименного непустого комплекта.

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

В качестве иллюстрации использования комплектов можно привести двойное использование подсистемы «СМ-Делопроизводство». Так в одной организации могут быть установлены: комплект «Делопроизводство обычное» и комплект «Делопроизводство специальное (конфиденциальное)». В каждый из этих комплектов могут быть включены свои БД из подсистемы «AF-Справочники», или же эти БД могут быть для них общими.

Корпоративные и внутренние базы данных

Рассмотрим вариант, когда Компания состоит из нескольких Организаций (филиалов), разделенных территориально. Такие организации мы будем называть "системными", т.к. они будут обладать своей базой "Структура организации" (СО).

Таким образом, все БД системы можно образно разделить на два основных класса:

  •  корпоративные БД;
  •  внутренние БД.

Корпоративные БД характерны тем, что могут в виде реплики присутствовать в более чем одной организации Компании, и в этих БД могут работать сотрудники этих организаций. В отличие от них, внутренние БД хранятся только в своей организации (на одном или более серверах). В то же время любая из корпоративных БД (точнее любой тип БД) может быть одновременно как корпоративной, так и внутренней – это объясняется тем, что система разрешает установить в одной организации несколько баз данных одного типа, но входящих в разные комплекты. И даже БД «Шлюз СМ» может быть несколько  — для каждой из подсистем «СМ-Делопроизводство». Хотя может использоваться и одна БД «Шлюз СМ» сразу для всех подсистем.

Рис.9   Корпоративные и внутренние БД в организациях

К корпоративным БД обычно относятся:

  •  уведомления;
  •  согласование;
  •  ознакомление;
  •  шлюз СМ (Ш);
  •  структура системы (СС).

Минимально необходимыми корпоративными базами являются «СС» и «Шлюз СМ».

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

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

  1.  Основные информационные объекты в СЭД

В документоориентированных базах данных Domino/Notes данные хранятся в хранилище объектов (NFS). Документ в БД Notes является основной единицей хранения информации. Все документы отличаются по своей структуре, которая различается формой. Форма содержит в себе набор полей определенных типов. Данные в БД слабо структурированы: документ может обладать полем, которое отсутствует у другого документа.  Поддерживается динамическое добавление поля к документу. Выделение памяти под поля документа происходит в зависимости от того количества, которое необходимо для хранения документа. БД Notes поддерживает любые типы данных (текстовые, числовые, время, дата, графические образы, видео, формат MS WORD и др.).

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

  •  Возможность хранить форматированные тексты, присоединенные и внедренные объекты. Универсальное хранилище объектов и точка доступа к информации;
  •  Поддержка родительских и дочерних отношений документов;
  •  Управление версиями. Когда пользователь вносит изменения в документ, инструменты Lotus Notes отслеживают их и вносят отметки о документе, помечая его основным или производным от оригинала. Изменения могут производиться несколькими пользователями. Функция может быть модифицирована в зависимости от потребностей рабочей группы;
  •  Документ в Lotus Notes может иметь «ссылку» на другие документы.

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

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

  •  РКК – карточка документа с его основными реквизитами, которые заносятся при регистрации;
  •  cопроводительное письмо;
  •  карточка резолюции – используется для фиксации в БД созданных резолюций
  •  карточка исполнения – отчет об исполнении документа
  •  классификатор – использование классификационных признаков документа, например, «вид документа», «вид доставки».

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

УВК позволяет создавать учетную карточку, в которую можно внести дату документа и исходящий номер, корреспондента, адресатов, заголовок (краткое содержание документа).

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

ВхД позволяет создавать РКК входящего документа, куда можно занести такую информацию, как: дата и исходящий номер документа, корреспондент, дата регистрации и входящий номер, заголовок (краткое содержание документа) и т.д.

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

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

При внесении резолюций вводятся имя автора резолюции, текст резолюции, исполнители и срок исполнения резолюции. Исполнителям резолюции посылаются уведомления об этом. Существует также возможность рассылки уведомлений-напоминаний о приближающемся сроке исполнения резолюции.

При внесении резолюций 2-го, 3-го и последующих уровней вводятся те же данные.

При исполнении документа и резолюций обязательно карточка документа или соответствующая резолюция помечается исполненной.

Таким образом, основными функциями ВхД являются:

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

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

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

Документооборот входящего документа изображен на рисунке ниже:
Рис.10 Документооборот входящего документа

В Систему CM внедрены решения на базе методологии адаптивного кейс-менеджмента. Адаптивный кейс-менеджемент (или АСМ) – это методология, которая позволяет динамически управлять бизнес-процессами. Инструменты АСМ применимы для работы со слабоструктурированными процессами, используются для решения сложных задач с многоэтапной реализацией. Такие задачи могут стоять перед руководителями и другими сотрудниками, ответственными за организацию выполнения проектов, которые требуют участия нескольких подразделений. Инструменты АСМ позволяют добиться эффективности бизнес-процессов.

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

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

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

  •  Задачи, выполняемые участниками кейса;
  •  Документы;
  •  Контрольный список – некие контрольные точки, по которым идет выполнение работы;
  •  Time-line – события в кейсе

Участниками кейса могут быть:

  •  Инициатор (по сути, автор кейса) – может быть назначен в автоматическом режиме, а может быть переназначен на другого участника CM;
  •  Ответственный – сотрудник, координирующий кейс. Данная роль может быть совмещена с предыдущей;
  •  Ответственный за документ – исполнитель, подготавливающий документ к данному сроку;
  •  Исполнитель задачи контрольного списка;

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

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

  1.  Построение модели выявления типовых бизнес-процессов

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

Рис.11 Модель документооборота входящих документов

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

Рассмотрим данную модель подробнее, выполнив декомпозицию процесса. Как видно на рисунке 12 поступающий на вход документ проходит следующие этапы:

  •  регистрация;
  •  рассмотрение;
  •  исполнение;
  •  отчет об исполнении.

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

Рис.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. Реализация алгоритмов построения деловых процессов на основе реляционной модели

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

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

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

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

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

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

  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.  карточки резолюции:
    1.   R111 – резолюция 1-ого уровня;
    2.   R121 – резолюция 1-ого уровня;
    3.   R131 – резолюция 1-ого уровня;
    4.   R211 – резолюция 2-ого уровня;
    5.   R311 – резолюция 3-его уровня;

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

  1.  Departs – справочник отделов в организации;
  2.  Doc_type – возможные виды документов (приказ, служебная записка, письмо и т.д.);
  3.  Organizations – справочник организаций;
  4.  Posts – справочник должностей в организации.

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

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

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

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

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

M1m*n 

Где

m – количество документов;

n – количество значимых полей в сумме с возможными бизнес-процессами организации

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

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

M2m2*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



 

Другие похожие работы, которые могут вас заинтересовать.
11023. Разработка процедуры построения спектральных разрезов в системе обработки сейсмических данных PROspect 2.97 MB
  Объектом изучения в сейсморазведке является осадочная толща и кристаллический фундамент земной коры. Информацию о строении осадочной толщи несёт регистрируемое на земной поверхности волновое поле, которое искусственно возбуждается в среде источниками упругих колебаний.
18854. Создание бизнес-модели предприятия, согласно инструментарию планирования бизнес-процессов 1.17 MB
  В современных условиях многие компании повышают свою конкурентоспособность за счет создания холдинговых структур, объединяя тем самым под общим управлением процессы разработки, производства и дистрибуции товаров и услуг. Интегрированная холдинговая структура - совокупность материнской компании и контролируемых ею дочерних предприятий...
9476. РЕМОНТ ТИПОВЫХ ДЕТАЛЕЙ И УЗЛОВ МАШИН. ПРОЕКТИРОВАНИЕ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ ВОССТАНОВЛЕНИЯ ДЕТАЛЕЙ 8.91 MB
  Высокая экономическая значимость этого при ремонте машин обусловлена тем что восстановлению подвергаются их наиболее сложные и дорогие детали. Виды технологических процессов восстановления Технологический процесс восстановления детали представляет совокупность действий направленных на изменение ее состояния как ремонтной заготовки с целью восстановления эксплуатационных свойств. Единичный технологический процесс предназначен для восстановления конкретной детали независимо от типа производства Типовой технологический процесс разрабатывается...
1399. Освоение методов нечеткого моделирования и разработка алгоритма для оптимизации базы правил нечеткого классификатора на основе наблюдаемых данных с помощью генетического алгоритма 1.15 MB
  Данный подход реализуется на базе нечетких систем в которых классы объектов описываются приближенно с помощью продукционных правил. Для нечетких классификаторов как и для всех нечетких систем актуальной является задача построения и оптимизации базы знаний которая состоит из базы правил и базы данных содержащей параметры лингвистических переменных с помощью которых описываются объекты заданного множества.
19799. Реинжиниринг бизнес-процессов 27.74 KB
  Непрекращающееся развитие технологий управления поднимает требования к конкурентоспособности предприятий и организации на принципиально новый уровень и заставляет многие компании искать инновационные решения для повышения эффективности своего бизнеса.
15940. Моделирование и планирование бизнес-процессов 500.22 KB
  В компании имеются следующие структурные подразделения: Складская служба Бухгалтерия Магазин Коммерческий отдел который подразделяется на отдел продаж и отдел снабжения. Основные процедуры в компании таковы: Начальник отдела продаж ОП изучает и обобщает спрос клиентов на стройматериалы требования к внешнему виду качеству материалов и стоимостным характеристикам а также анализирует отчет по продажам получаемый от магазина. Составленный отчет он передает начальнику отдела снабжения ОС. Начальник отдела снабжения...
3261. Реинжиниринг бизнес-процессов «ОАО Ростелеком» 1.88 MB
  Бизнес-процессы. Объектом изменений при реинжиниринге являются бизнес-процессы. Именно в этом состоит основное отличие реинжиниринга от реструктуризации, в которой объектом изменений является организационная структура.
17277. СОВЕРШЕНСТВОВАНИЕ БИЗНЕС ПРОЦЕССОВ ООО «АЛЫЕ ПАРУСА» 601.38 KB
  Существует немного других отраслей в которых сбор обработка применение и передача информации были бы настолько же важны для ежедневного функционирования как в туристической индустрии. Такой подход требует ответа на ряд нетехнологических вопросов: в чем выражается доход от внедрения информационных систем и услуг как его измерить какие организационные и кадровые преобразования следует предпринять для полноценной реализации проекта внедрения информационных технологий. Кроме того для получения информации о месте пребывания его...
12192. РАЗРАБОТКА АЛГОРИТМОВ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПОСТРОЕНИИ ГЕОМЕТРИЧЕСКИЕ ФРАКТАЛОВ НА БАЗЕ R-ФУНКЦИИ 65.38 KB
  В нашей республике уделяется огромное внимание для эффективного использования информационных технологий в научной и производственной деятельности. Количество различных масштабов длины в естественных формах можно считать бесконечным для каких угодно практических задач. Программное обеспечение может быть использовано в текстильной промышленности при рисовании узоров для штамповки на ковры ткани и т. В 1988 году известные американские специалисты в теории динамических...
19374. Необходимость использования консультантов при реинжиниринге бизнес-процессов 61.17 KB
  Необходимость использования консультантов при реинжиниринге бизнес-процессов Работа по обеспечению реинжиниринга бизнес-процессов сопровождается серией интервью с персоналом заказчика процессным консультированием семинарами и тренингами а также мероприятиями необходимыми для построения базовых моделей бизнес - процессов как есть с последующей разработкой рекомендаций как должно быть . Особую роль в обеспечении эффективности реинжиниринга бизнес-процессов принадлежит консультантам. Возможными целями проекта могут быть: Перепроектирование...
© "REFLEADER" http://refleader.ru/
Все права на сайт и размещенные работы
защищены законом об авторском праве.