Выпускная квалификационная работа - LMS
advertisement
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ «ВЫСШАЯ ШКОЛА ЭКОНОМИКИ» Московский институт электроники и математики Агапова Мария Анатольевна «РАЗРАБОТКА АЛГОРИТМОВ ПОСТРОЕНИЯ ТИПОВЫХ БИЗНЕС-ПРОЦЕССОВ НА ОСНОВЕ СЛАБОСТРУКТУРИРОВАННЫХ ДАННЫХ» Выпускная квалификационная работа студента образовательной программы бакалавриата по направлению 09.03.02 Информационные системы и технологии Студент ___________________ Рецензент К.т.н., проф., М. Р. Биктимиров М.А. Агапова Научный руководитель К.т.н., доцент, А.В. Белов Консультант Ст. преподаватель Н.С. Березина Москва 2015 г. Аннотация Цель данной работы - разработка алгоритмов построения типовых бизнес-процессов на основе слабоструктурированных данных. В работе проводится исследование методов оценки эффективности типовых деловых процессов и делается выбор в пользу наиболее оптимального метода с точки зрения поставленной задачи. Также построена модель выявления типовых бизнес-процессов, описан механизм ее реализации. Разработанные алгоритмы протестированы средствами СУБД Microsoft SQL Server. Результаты работы могут оказаться полезными для организаций с нерегламентированным документооборотом. 2 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. 3 Оглавление Введение....................................................................................................................................................... 5 Глава 1. Анализ современного состояния проблемы оценки эффективности деловых процессов организации ................................................................................................................................................. 6 1.1. Документооборот в организации как основа описания деловых процессов. Основные понятия и определения ........................................................................................................................... 6 1.2. Анализ методов оценки эффективности бизнес процессов ..................................................10 1.2.1. Cost Analysis.......................................................................................................................10 1.2.2. Методы имитационного моделирования ........................................................................17 1.2.3. Интеллектуальный анализ процессов..............................................................................21 1.3. Постановка задачи анализа эффективности деловых процессов на основе данных системы электронного документооборота..........................................................................................23 Выводы по главе 1 .....................................................................................................................................24 Глава 2. Построение информационной модели деловых процессов на базе СЭД ..............................25 2.1. Анализ современных СЭД .........................................................................................................25 2.2. Основные информационные объекты в СЭД ..........................................................................35 2.3. Построение модели выявления типовых бизнес-процессов ................................................40 Выводы по главе 2 .....................................................................................................................................46 Глава 3. Реализация алгоритмов построения деловых процессов на основе реляционной модели ..46 3.1. Сервис построения отчетов ......................................................................................................46 3.2. Алгоритм построения типовых бизнес-процессов .................................................................47 3.2.1. Проектирование реляционной модели ..........................................................................47 3.2.2. Построение типовых бизнес-процессов ..........................................................................49 Выводы по главе 3 .....................................................................................................................................51 Заключение ................................................................................................................................................51 Список литературы ...................................................................................................................................53 Приложение ...............................................................................................................................................54 4 Введение Очевидно, что успех организации во многом зависит от эффективности ее бизнес-процессов. Важными показателями эффективности бизнес- процессов являются время выполнения процесса и затраты на его обеспечение. Организации необходимо стремиться к минимизации этих показателей. В данной работе поставлена задача разработки алгоритмов, позволяющих выявить типовые бизнес-процессы. Из множества типовых бизнес-процессов можно выделить множество эффективных. Разработанные алгоритмы помогут реализовать типовые кейсы адаптивного кейс- менеджмента, что в свою очередь позволит автоматизировать определенные процессы, существенно сократив при этом затраты организации на обучение сотрудников. Структура работы определяется поставленной задачей и последовательностью раскрытия темы. Данная выпускная квалификационная работа состоит из введения, трех глав, заключения, списка литературы и приложения. В первой главе исследованы методы оценки эффективности бизнеспроцессов организации, выявляются сильные и слабые стороны каждого из методов. Сделан выбор в пользу наиболее эффективного метода и сформулирована постановка задачи. Во второй главе представлен обзор современных систем электронного документооборота, описаны основные объекты и построена модель решения задачи. В третьей главе приведено описание и тестирование алгоритма. В заключении сделаны основные выводы о результатах решения задачи. 5 Глава 1. Анализ современного состояния проблемы оценки эффективности деловых процессов организации 1.1. Документооборот в организации как основа описания деловых процессов. Основные понятия и определения «Документ» или по-латински “documentum” означает свидетельство, доказательство. Документ означает определенным способом оформленные письменные источники, которые имеют юридическую силу. Электронный документ – набор информации, сопровождаемый специальной карточкой с атрибутами, по которым можно найти документ. У каждого документа должен быть реквизит. Под реквизитом понимается обязательный элемент документа, например, номер, подпись, печать, дата. Такие элементы в совокупности идентифицируют документ. Реквизиты документа вместе с их схемой расположения образуют формуляр. Единство документирования обеспечивается установленным государственным стандартом формуляром. Типовой формуляр – это формуляр, который характерен для определенного вида документов. Делопроизводство – это отрасль деятельности, которая обеспечивает документирование и организацию работы с официальными документами. Документирование означает регламентированную запись информации на носители в соответствии с нормами РФ. Документ – это результат регламентирования. Документирование предполагает организацию работы с документами, для обеспечения которой, в свою очередь, необходимо спроектировать документооборот предприятия. Под документооборотом предприятия предполагается движение документов во времени. Начальный период предполагает момент создания документа (или его получения), конечный – уничтожение или хранение в архиве. 6 Электронный документооборот как способ организации работы с документами подразумевает хранение основной массы документов централизованно в электронном виде. Документопоток объединяет все документы предприятия, которые двигаются по определенным инструкциям. Благодаря их соблюдению, предприятие работает бесперебойно. Требуется создание условий для работы с документами в промежутке времени от создания (или получения) документа до уничтожения или передачи в архив. Документы организации можно разделить на три группы: внутренние документы – это документы, необходимые для реализации внутренних задач организации; исходящие документы - документы, созданные данной организацией для передачи какой-либо информации; входящие документы – документы, которые были получены от сторонних предприятий В зависимости от группы, к которой принадлежит документ, определяются вид работы с ним и форма его исполнения. Операции над документом предусматривают несколько стадий: рассмотрение, согласование, исполнение, утверждение, подписание. Поток работ или Workflow – это алгоритм действий сотрудников в границах данного бизнес процесса. Например, получение документа, его регистрация, рассмотрение, исполнение. Бизнес-процесс (или БП) - последовательность некоторых операций, результатом которых является значимый для организации результат (продукты или услуги). На вход бизнес-процесса подаются определенные виды ресурсов. На выходе создается продукт. Необходимость автоматизации выполнения БП привела к привлечению информационных систем, а значит к тесному взаимодействию бизнеса и информационных технологий. 7 Однако не все действия в рамках бизнес-процесса описываются формальным языком. Данные, на основе которых строится бизнес-процесс, бывают трех видов: Структурированные Слабоструктурированные Неструктурированные В работе находящиеся рассматриваются посередине слабоструктурированные между данные, структурированными и неструктурированными. Данные процессы более гибкие по сравнению со структурированными, в ходе выполнения они более неопределенны. Но их возможно описать с некоторой степенью формализации. Их структура носит рекомендательный характер. Оперативность работы организации, в том числе, зависит от качества организации документооборота. Если документ задерживается на какой-либо стадии, например, исполнение, то информация, содержащаяся в нем, рискует стать неактуальной. Это в свою очередь может нанести экономический ущерб предприятию или к сбою какого-либо процесса. Проектирование системы документооборота должно происходить на ранней стадии развития предприятия. Для каждого типа документов формируется свой маршрут движения, оформляемый в виде схем. Режим движения документов характеризуется объемом документопотока, пропускной способностью каналов связи, способами создания документов, загрузкой сотрудников. При планировании документооборота также необходимо учитывать вероятностный характер поступления документов. Можно выделить следующие этапы документооборота: Прием и обработка входящих документов; Резолюция; 8 Работы с исходящими документами. Входящие документы можно классифицировать по корреспондентам, т.е., авторам документов. Приемом входящих документов занимается специальная служба – канцелярия. При поступлении документа н нем фиксируется входящий номер. Затем документ регистрируют. пометка «срочно», Если в документе присутствует то указывается время поступления документа с точностью до часов и минут. Также документ проверяют на правильность поступления путем сопоставления данных в реквизите «Адресат и адреса на конверте. На стадии предварительной обработки происходит распределение поступившей корреспонденции по руководителям. Следует отметить, что данная стадия не является обязательной. Ее можно миновать путем прямой передачи срочного документа руководителю. Следующий этап движения документа - это процесс его рассмотрения или этап резолюции. Резолюция может быть внесена на входящие и внутренние документы, поступающие в адрес руководителя. Обычно руководитель рассматривает поступивший к нему документ в день получения. Резолюция – это решение руководителя или замещающего его в СЭД лица, на основе поступившего документа. Резолюции обычно содержат задания, связанные и исполнением данного документа. После этого документ передается указанному в резолюции лицу для исполнения. При внесении резолюций вводятся имя автора резолюции, текст резолюции, исполнители и срок исполнения резолюции. Исполнителям резолюции посылаются уведомления об этом. Существует также возможность рассылки уведомлений-напоминаний о приближающемся сроке резолюции. Пример внесения резолюции показан на рис.1: 9 исполнения Рис.1 Внесение резолюции Исходящие документы предназначены для отправки их сторонним предприятиям. Они проходят стадии составления, согласования, проверки правильности оформления, подписания, регистрации, тиражирования, отправки адресату, подшивки в дело. Документооборот предприятия является основой описания бизнес процессов, он не должен быть стихийным и неконтролируемым. Основная проблема заключается в отслеживании движения документов. Для организации документооборота необходим анализ деятельности организации. 1.2. Анализ методов оценки эффективности бизнес процессов 1.2.1. Cost Analysis Cost analysis или стоимостный анализ – это анализ системы, предполагающее исследование функциональных характеристик продукции и оценивание их стоимости и полезности. Конечные цели анализа могут быть: 10 вывод о необходимости уменьшить стоимости определенных видов продукции, при этом оставляя объем производства без изменений. Это решение означает необходимость минимизировать затраты на выполнение определенных функций; улучшить функциональные параметры продукции при минимуме затрат. Стоимостный производства анализ позволяет продукции, определить обнаружить бизнес реальную процессы, стоимость требующие немедленного повышения эффективности, определить реальную стоимость поддержки клиента и др. Для проведения анализа вначале необходимо построить функциональную модель организации бизнес процесса. Для этого требуется определить необходимые работы и последовательность их выполнения. Для выбранных функций определяют затраты и характеристику источника издержек. После этого рассчитываются затраты на производство продукта. В данной работе функциональная модель может быть построена с помощью инструмента визуального моделирования бизнес процессов AllFusion Process Modeler (Bpwin). Инструмент BPWin поддерживает два типа функциональных моделей: AS-IS и TO-BE. Из названий видно, что первая модель строится на основе существующей организации бизнес процессов. Как правило, она предшествует модели TO-BE. Вторая модель является результатом анализа бизнес процессов существующей модели. Моделей TO-BE может быть несколько. Выбор наиболее эффективной происходит по какому-либо критерию. Для моделирования бизнес-процессов удобно пользоваться языком моделирования IDEF0. Модель IDEF0 представляет собой текстовое и графическое поставленные описание вопросы. некоторой Система системы, отвечающее представляет взаимодействующих функций или работ. 11 собой на заранее совокупность На рисунках ниже представлены фрагменты, реализующие функциональную модель деловых процессов организации. Следует отметить, что любая модель строится с определенной целью, поэтому перед построением функциональной модели в графе Purpose формулируем цель нашей задачи. Рис.2 Цель построения модели Правильно сформулированная цель помогает в дальнейшем аналитикам фокусировать внимание и двигаться в нужном направлении. На рисунке ниже представлен фрагмент, реализующий создание контекстной диаграммы бизнес-процесса. Нотация IDEF0 предполагает отображение работ (Activity) в форме прямоугольников. 12 Рис.3 Функциональная модель бизнес процесса организации движения с документами Как видим на рисунке 3, в качестве входных данных подаются документы. Управление бизнес-процессом реализуется в виде регламента работы с документами (в нашем случае – регламентом). Сканеры, СЭД и анализатор представляют собой механизмы, выполняющие работу. Результатом выхода у нас являются бизнес-процессы движения документов. В BPwin функциональная модель предполагает детализацию функций в виде декомпозиции работ на составные части. Степень детализации описания модели определяется необходимостью достижения сформулированной цели. На рисунке ниже представлен фрагмент декомпозиции работы «Организация движения документов»: 13 Рис.4 Диаграмма декомпозиции диаграммы «Организация движения документов» Рис.5 Диаграмма декомпозиции дочерней диаграммы «Регистрация документа» 14 Здесь стоимостный анализ основан на работах (ABC – Activity Based Costing). Оценивание производится посредством выявления стоимости выполнения определенной функции. Инструмент BPwin позволяет выбрать валюту и единицу измерения времени. Для анализа ABS необходимо ввести следующие понятия: объект затрат; двигатель затрат; центры затрат. Под объектом затрат понимается выход работы. Сумма стоимости объектов затрат представляет собой стоимость работ. Двигатель затрат – это некоторые характеристики управлений и входов функций. Они влияют на выполнение и длительность работы. Центры затрат – это некоторые статьи расхода. На рисунке ниже представлен фрагмент, отображающий центры затрат построенной модели с указанием стоимости каждой: 15 Рис.6 Центры затрат Суммарная стоимость всех центров затрат образует общие затраты по работе. При подсчете затрат родительской функции сначала затраты дочерней функции умножаются на частоту работы, и затем результаты суммируются. Данные модели стоимости, как правило, оказываются полезными вовремя предварительной оценке затрат. Принцип расчета работает при последовательном выполнении функций. Если модель более сложная, то итоговые суммы задаются вручную. Результат стоимостного анализа можно представить в виде отчета и распечатать в файле: Number: 1 Name: Registration Activity Cost ($ U.S.): 95 000,00 Cost Center: Components Cost Center Cost ($ U.S.): 25 000,00 16 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 Стоимостный анализ влияет на очередность выполнения работ, если при этом технология их выполнения позволяет это сделать. Выполнение работ сортируется по возрастанию их стоимости. Вначале должна быть выполнена самая дешевая работа. Иногда стоимостных показателей оказывается недостаточно для проведения анализа. В этом случае пользователю предлагается внести собственные свойства – метрики (UDP – User-Defined Properties). Результат также можно проанализировать в специальном отчете. 1.2.2. Методы имитационного моделирования Метод имитационного моделирования заключается в построении модели, которая имитирует изучаемую систему. Этот метод позволяет создать модель с учетом времени выполнения операции и с обеспечением 17 средств анализа динамики бизнес процессов. Модель рассматривается в виде совокупности правил, определяющих состояние объекта в будущем. Модель, построенная с помощью имитационного моделирования, включает в себя следующие элементы: источники и стоки; очереди; процессы. Информация и объекты поступают в модель через источники. Их прием обеспечивается стоком. Ожидание обработки объектов происходит в очереди. Время их обработки различно, поэтому возможно накопление объектов, ожидающих своей очереди. Цель моделирования состоит в сведении к минимуму объектов в очередях. Процессы в имитационном моделировании аналогичны работам (Activity) в стоимостном анализе (cм. п.1.2.1). Стоит отметить, что в данной модели возможно задать производительность процессов. Алгоритм моделирования системы можно условно разделить на четыре пункта: 1. Построить модель процесса (или процессов), который хотим проанализировать. 2. Запустить имитацию выполнения построенных моделей процессов. 3. Проанализировать результаты. 4. Если требуется, повторить предыдущие пункты для других сценариев выполнения процесса. Вначале необходимо выбрать стартовое событие, являющееся началом выполнения процесса. Допустим, стартовым событием является поступление документа в канцелярию. Периодичность поступления документов может быть разной. Какие-то события возникают в определенный момент времени (канцелярия работает с 9 до 18.00), какие-то – через определенные интервалы (документы поступают каждые N – минут). При этом интервал повторений 18 событий – величины случайные. Далее требуется задать длительность шага. Длительность может быть как постоянной величиной, так и случайной. В зависимости от вида документа, квалификации сотрудника и исполняемой задачи время работы может увеличиваться или уменьшаться. Выбор следующего шага имеет вероятностный характер. Например, вероятность, что документ Д отправится к сотруднику А составляет 0.6, к сотруднику Б – 0.3, к сотруднику В – 0.1. Для оценки стоимости процесса для каждого шага задаем стоимость ресурсов – трудовых или материальных. Как только модель спроектирована, можно запустить имитацию. Оценки показателей формируются посредством неоднократного запуска повторов изменений. В результате получаются распределение полезного и затраченного на ожидание времени процесса и значений стоимости. Существуют несколько направлений Каждое направление моделирования. инструментальными средствами и в теории имитационного характеризуется системами своими имитационного моделирования. Приведем несколько примеров: Моделирование динамических систем (реализуется в системах MATLAB Simulink, VimSim и др.); Дискретно-событийное моделирование (Arena, Aris, AnyLogic, AutoMod и др.); Системная динамика (PowerSim, iThink. AnyLogic и др.); Агентное моделирование (Swarm, AnyLogic, Repast и др.); Системная динамика и моделирование динамических систем предполагают непрерывные во времени процессы. Дискретно-событийное и агентное моделирования – дискретные. Наиболее популярными подходами при решении задачи анализа бизнеспроцессов принято считать дискретно-событийное моделирование и агентное. В дискретно-событийных системах моделирование основано на описании процессов. К преимуществам данной модели относится статистическая 19 обработка данных на входе и выходе, оптимизация, относительная простота реализации, интерфейс. Однако данная модель не позволяет проводить моделирование на высоком уровне. В агентном моделировании динамика и функционирование определяются в результате индивидуальной активности участников модели. К достоинствам системы можно отнести любой уровень детализации, оптимизацию, интерфейс, реализм в описании системы. Недостатками являются сложность описания логики поведения агента в терминах модели, большие затраты по мощности. Таким образом, с помощью имитационного моделирования возможно выполнить какой-либо процесс в режиме ускоренного времени в условиях, соответствующим реальности, с учетом задержек работы и перерывов. Анализируя полученные результаты, можно выявить нуждающиеся в разгрузке ресурсы (ресурсы, к которым часто выстраиваются очередь из поступающих заявок), низко загруженные ресурсы, выявить дефицит или перепроизводство. В случае получения неудовлетворительных результатов анализа, модель можно оптимизировать и перестроить. Повторение экспериментов даст выборку наиболее оптимальных вариантов. Методы анализа, основанные на функциональном и имитационном моделированиях, связаны и хорошо дополняют друг друга. Функциональное моделирование помогает в оптимизации бизнес-процессов. Имитационное моделирование располагает большей информацией для анализа существующей системы и помогает модифицировать модель процессов. К недостаткам данного метода относятся следующие факты: получение достоверных результатов предполагает предварительную проделанную работу по выявлению законов распределения случайных величин. Также данный метод не дает четкого ответа на вопрос об эффективности работы системы, оптимальности показателей и способе перестройки бизнес20 процесса, он лишь располагает информацией для обработки и принятия управленческих решений. 1.2.3. Интеллектуальный анализ процессов Интеллектуальный анализ процессов (Process Mining) состоит в обнаружении, анализе эффективности и оптимизации БП. Process Mining основывается на данных из журналов событий (лог) и представляется некоторым обобщением и связующим звеном между классическими методами анализа бизнес-процессов и интеллектуальным анализом данных (Data Mining). Принцип Process Mining достаточно прост: имея след исполнения бизнес-процесса, можно восстановить цепочку событий, произошедших в реальности. В результате происходит обнаружение излишних циклов согласования, задержек исполнения, лишние действия, негативно отражающиеся на эффективности выполнения бизнес-процесса. Process Mining не анализирует сами данные и не занимается установкой низкоуровневых закономерностей. Предметом его анализа являются данные анализа бизнес-процессов. Задачи Process Mining состоят в получении ответов на вопросы: Производительность или эффективность бизнес-процессов Согласованность бизнес-процессов В качестве исходных данных используется журнал событий. Строка в таком журнале представляет отдельное событие. Каждый журнал должен содержать характеризующее событие: Идентификатор события Деятельность – выполняемые действия Время – дата и время регистрации события Прочая информация 21 некоторые атрибуты, Основные идеи методов интеллектуального анализа процесса состоят в следующем: У нас есть некоторое множество реальных бизнес-процессов, сотрудников, компонентов, сред взаимодействий. Исполнители данных объектов взаимодействуют с информационной системой, и в качестве выходных данных выступают некоторые записи, сообщения, транзакции. Эти записи представляют собой события, отраженные в журнале лог. На основе таких событий происходит выявление, анализ бизнес-процессов и построение их модели средствами Process Mining. Построенные модели бизнес- процессов анализируются сотрудником и вносятся решения об изменениях, модернизации БП. Рис.7 Применение Process Mining К примерам инструментария, который содержит функционал Process Mining, относят продукт ARIS PPM, ProcessAnalyzer, системы Disco и другие. Методы используются интеллектуального в бизнесе. анализа Построенные бизнес-процессов модели основаны широко не на запланированных событиях, а на происходивших в действительности, 22 поэтому модели Process Mining более точно отражают реальные системы, а значит, анализ с помощью таких методов более эффективен. Постановка задачи анализа эффективности деловых процессов 1.3. на основе данных системы электронного документооборота В работе рассматриваются документы базы данных Domino/Notes системы электронного документооборота CompanyMedia. Company Media поддерживает документооборот организации холдингового типа. Документы проходят стандартные этапы обработки в СЭД, включая регистрацию, предварительную обработку, при необходимости создание резолюций на его основе, исполнение и со временем отправление в архивное хранение. Для оптимальной организации работы с документами в СЭД CompanyMedia была разработана подсистема «СМ - адаптивный caseменеджмент». На основании информации, содержащейся в базах данных системы, требуется создать шаблоны типовых процессов для хранения в подсистеме «СМ – адаптивный case-менеджмент» и дальнейшего их использования. В данной работе поставленная задача решается для документов типа входящие. При поступлении и регистрации документа создается его карточка с необходимыми атрибутами. В карточке документа присутствует адресат – лицо или сотрудник, на имя предварительной обработки отправляется уполномоченным к которого документ по лицам. пришел документ. определенному Сотрудники по После маршруту решению инициатора могут начать процесс ознакомления с документом, также на основе поступившего документа могут быть созданы резолюции, которые в свою очередь представляют документы, проходящие по определенным лицам (маршрутам). В данной выделенными работе признаками, требуется определить характерными документов. 23 для бизнес-процессы определенных с типов Необходимо разработать алгоритмы, позволяющие отследить маршруты движения документов вместе с резолюциями, созданными на их основе. На основе данных, получившихся в результате применения алгоритмов, провести анализ и определить эффективные бизнес-процессы с выделенными признаками. В качестве критерия эффективности бизнеспроцесса будем рассматривать частоту прохождения документов заданного типа по определенным маршрутам. Для решения поставленной задачи необходимо: Провести анализ методов оценки эффективности деловых процессов. Выбрать наиболее эффективный, с точки зрения технико- экономических показателей, метод; Исследовать предметную область и построить модель, позволяющую выявить типовые бизнес-процессы на базе системы электронного документооборота; По имеющимся результатам анализа и исследования разработать алгоритмы оценки эффективности бизнес-процессов и провести тестирование модели. Выводы по главе 1 В первой главе проведен анализ методов оценки эффективности бизнес-процессов организации, показаны преимущества и недостатки каждого из методов. Был предложен способ решения задачи с помощью средств Process Mining. Сформулирована постановка задачи и план ее решения. 24 Глава 2. Построение информационной модели деловых процессов на базе СЭД 2.1. Анализ современных СЭД Работа с информацией занимает до 80% рабочего времени у руководителя. Около 30% рабочего времени занимает создание, поиск, согласование и отправка документов. Внутренние документы копируются приблизительно до 20 раз, теряется без возможности возврата около 6% документов. На основе такой статистике нетрудно сделать вывод, насколько сильно зависит эффективность выполнения бизнес-процессов и организации в целом от качества и эффективности работы документооборота. Решением проблемы для крупных организаций явились системы электронного документооборота. Ключевые принципы СЭД: Однозначная идентификация документа посредством однократной регистрации документа; Параллельное выполнение операций как возможность повысить оперативность исполнения документов и сокращение времени их движения; Непрерывное движение документов с целью идентификации исполнителя в каждый момент времени жизни процесса; Исключение возможности дублирования документов и ведение единой базы информации; Эффективный поиск документов; Система отчетности для контроля движения документов и принятия управленческих решений. Обязательными атрибутами СЭД являются технологий, предлагаемых разработчиками: 1. Workflow 25 композиции из трех 2. DMS 3. Groupware Остановимся подробнее на каждом из них. Workflow В данной концепции задачи автоматизации бизнеса рассматриваются как совокупность бизнес-процессов. Инструменты системы Workflow позволяют формировать описание процессов, данных, электронных форм для их обработки. Процесс должен быть исполнен точно согласно описанию. Сервисы в рамках данной технологии должны позволять реализовывать бизнес-процессы, формировать и подготавливать очереди стадий процесса, контролировать своевременность исполнений определенных этапов процесса, реагировать на проблемы. Также системы должна отличаться гибкостью и возможностью моделирования процессов, отслеживать состояния процессов с помощью определенного набора средств, получать информацию о возникших несоответствиях и накапливать статистики отклонений. Тем самым система улучшает и реструктурирует бизнеспроцессы организации, влияя на скорость выполнения бизнес-процессов, качество работы сотрудников. DMS (Document Management System) Данные системы были разработаны давно и вначале ограничивались несложными функциями хранения документов и доступом к ним с разграничением прав и отслеживанием истории обработки файлов. По мере развития систем появились дополнительные функции, например: 1. картотека документов, средства быстрой разработки электронных форм; 2. справочники для заполнения карточек; 3. поддержка описания процесса обработки документов; 4. организация информации о документах для учета; 5. возможность свободной маршрутизации документов; 26 6. возможность описания жизненного цикла документа; 7. контроль маршрутизации процессов. Данные средства обеспечивают применение системы для решения разнообразных задач, не ограничиваясь простым ведением архива документов. DMS – системы добавляют в СЭД возможность обрабатывать слабоструктурированные данные. GroupWare Идея данной концепции состоит в создании максимально удобной среды доступа к информации, а также групповая работа с ней. К данным системам можно отнести LinkWorks и Lotus Notes. К GroupWare относят следующие задачи: Создание и ведение БД с обеспечением группового доступа с возможностью хранения слабоструктурированных данных; Навигация по всем приложениям с помощью унифицированного клиентского рабочего места; Инструменты разработки электронных форм для обеспечения доступа к информации в БД; Возможность создания представлений (view) на основе хранящихся данных в БД; Маршрутизация электронных форм, инструменты группового планирования и интеграции с электронной почтой; Управление гиперссылками, использование их в приложениях. Описанные выше функции позволили разработать разнообразный набор приложений систем класса GroupWare. В таких приложениях интерфейс вместе со средствами навигации унифицированы, основаны на общем каталоге пользователей. Получение информации в виде сообщений, факсов, приглашений, документов 27 и т.д., инструменты управления расписанием и планирование основаны на концепции универсального почтового ящика (inbox). Объединение Workflow, DMS, GroupWare повышают прозрачность процессов, улучшают структуру организации, принятие решений, гибкость, скорость обработки документов и пр. Современные СЭД применяются одновременно с функционированием бумажного документооборота. Тем самым при внедрении системы не нарушается имеющийся режим работы, процесс внедрения происходит постепенно. Все обновления отличаются прозрачностью. Все системы электронного документооборота являются открытыми. Это означает возможность свободного добавления новых функций и организации работы в зависимости от конкретных бизнес-процессов. Таким образом, говоря о внедрении СЭД в компанию, речь идет о платформе (например, Lotus Notes/Domino) и об интеграторе. Интегратор представляет собой средство расширения платформы в зависимости от требований заказчиков. Важным свойством СЭД является возможность интеграции системы с другими программными обеспечениями. Это обеспечивается благодаря таким технологиям, как OLE Automation, DDE, ODMA и другие. Пользователи работают с привычными приложениями для обработки документов, но в эти прикладные программы во время установки клиентской части СЭД внедрятся функции и компоненты меню системы. То есть, при работе с текстовым редактором MS Word, пользователю при открытии файла видны библиотеки и папки СЭД. Сохранение файла также происходит в баз данных СЭД. Некоторые СЭД предусматривают интеграцию с ERP-системами (например, Oracle, ERP галактика). Это означает, что такая система электронного документооборота выступает в роли связующего звена между компонентами информационной системы компании. Архитектура большинства систем электронного документооборота распределенная с иерархической структурой хранения документов. 28 Остановимся подробнее на системе электронного документооборота Company Media. CompanyMedia информационной (CM) поддержки предназначена и для автоматизации решения задач документационного обеспечения управления Компании со сложной организационной структурой, в том числе территориально-распределенной. CM по сути есть разработанная компанией ИнтерТраст корпоративная информационная система, имеющая специальную архитектуру, при которой конкретное системное решение достигается путем использования различного набора прикладных подсистем, каждая из которых может взаимодействовать друг с другом и обязательно использует инфраструктуру ActiveFrame (AF), являющуюся каркасом, информационным ядром CM. Поэтому AF является обязательным элементом СМ любой конфигурации. Таким образом, СМ состоит из - ядра системы (ActiveFrame) и различного набора подсистем прикладного характера, представленных на рис.8. Делопроизводство AF-Портал Договоры Документы Заседания Управление персоналом AF-Справочники AF-WorFlow ... AF-Сервис AF-Администрирование AF Рис.8 Элементы СЭД Company Media Список прикладных подсистем СМ-Делопроизводство СМ-Обращения граждан СМ-Документы СМ-Нормативные и распорядительные документы (СМ-НРД) 29 СМ-Поручения СМ-Договоры СМ-Заседания СМ-Управление персоналом СМ-Планирование СМ-Клиенты и контакты СМ-Факс СМ-HelpDesk Автоматизированное рабочее место «Контроль исполнения поручений руководителей» (АРМ КИПР) Каждая из перечисленных подсистем использует инфраструктуру AF 3.4, которая в свою очередь также состоит из подсистем: AF-Справочники AF-Портал AF-Сервис AF-WorkFlow AF-Администрирование Кроме перечисленных прикладных подсистем в состав СМ входят: «СМ-Справка» - справочная информация о работе с базами данных «СМ 3.4 Documentation» - набор документации по СМ «AF ExecLibrary» - библиотека внешних программ, устанавливаемых на серверах и рабочих местах «Визуализация» - программные компоненты технологии VisualDocs, которые используются в СМ для графического отображения связей между документами «Locker-СМ» - дополнительно может быть использована подсистема защиты информации с помощью внешних криптографических средств. Устанавливается как на серверах, так и на рабочих местах и имеет собственные элементы настроек работы. 30 Архитектура СМ Особенности архитектуры 1. Неограниченное количество рабочих мест сотрудников организации, которая обеспечивается установкой необходимого числа серверов системы и конфигурированием системы - увеличением числа системных организаций. 2. Неограниченное количество организаций (или территориально-удаленных филиалов) - при этом все организации работают со своими БД документов, но используются общие механизмы информационного взаимодействия между собой. 3. Работа с базами данных коллективного доступа и разграничение прав доступа к документам. 4. Передача документов между организациями на основе репликационных возможностей Lotus Notes (без использования почтовых механизмов), что обеспечивает 100% гарантию доставки информации. 5. Автоматическое поддержание целостности данных - реквизитов организаций, данных о сотрудниках, реквизитов документов за счет работы серверных программных агентов, которые отслеживают изменения справочников и первичных документов и корректируют документы по ссылкам. 6. Корпоративность работы пользователя, когда каждая из организаций (филиалов) ведет свою базу данных, которая через репликации распространяется во все другие организации. Все пользователи могут выбирать в качестве адресатов или исполнителей любого сотрудника Компании. 7. Механизмы замещения при работе с документами - предоставление постоянного или временного доступа к документам "замещающим" как самим сотрудником, кого замещают, так и администратором системы. 8. Разграничение функций по администрированию с использованием централизованного и децентрализованного способа управления системой. 31 9. Автоматическое управление объемами реплицируемых данных между удаленными площадками одной организации (между сетями) и между разными организациями. Типы баз данных и комплекты системы Главным элементом программного обеспечения СМ является БД формата Lotus Notes (*.nsf). Для определения пути к каждой БД используется база "Структура системы" (СС), где базы данных регистрируются. Для обеспечения собственной идентификации и однозначного поиска в СС необходимых других БД введено понятие типа БД. Кроме типа базы данных в СС существует понятие комплекта БД. Цель использования комплекта - иметь возможность работы в рамках одной организации с несколькими однотипными БД. Например, при работе в БД «Входящие документы», отнесенной в СС к комплекту «Общий документооборот», в режиме редактирования карточки входящего документа и команде пользователя для вызова списка организаций идет поиск БД «Справочник организаций» в том же комплекте «Общий документооборот». В то же время, для совместимости с более ранними версиями СМ, а также для того, чтобы не надо было создавать все сервисные БД под каждое имя комплекта, в системе допускается иметь БД с неуказанным именем комплекта («пустой» комплект). БД из пустого комплекта будут использоваться в работе, когда не будет найдена БД из одноименного непустого комплекта. Исключением из данного правила является регистрация базы данных типа «Блокировки» - она регистрируется всегда в комплекте с именем, совпадающем с именем сети, где она будет использоваться. И, соответственно, «Блокировки» устанавливаются в каждой сети независимо как самостоятельная реплика. В качестве иллюстрации использования комплектов можно привести двойное использование подсистемы «СМ-Делопроизводство». Так в одной 32 организации могут быть установлены: комплект «Делопроизводство обычное» и комплект «Делопроизводство специальное (конфиденциальное)». В каждый из этих комплектов могут быть включены свои БД из подсистемы «AF-Справочники», или же эти БД могут быть для них общими. Корпоративные и внутренние базы данных Рассмотрим вариант, когда Компания состоит из нескольких Организаций (филиалов), разделенных территориально. Такие организации мы будем называть "системными", т.к. они будут обладать своей базой "Структура организации" (СО). Таким образом, все БД системы можно образно разделить на два основных класса: корпоративные БД; внутренние БД. Корпоративные БД характерны тем, что могут в виде реплики присутствовать в более чем одной организации Компании, и в этих БД могут работать сотрудники этих организаций. В отличие от них, внутренние БД хранятся только в своей организации (на одном или более серверах). В то же время любая из корпоративных БД (точнее любой тип БД) может быть одновременно как корпоративной, так и внутренней – это объясняется тем, что система разрешает установить в одной организации несколько баз данных одного типа, но входящих в разные комплекты. И даже БД «Шлюз СМ» может быть несколько — для каждой из подсистем «СМ- Делопроизводство». Хотя может использоваться и одна БД «Шлюз СМ» сразу для всех подсистем. 33 Организация 2 Организация 1 Договоры ФД ИсхД Заседания ОРД CMAgMa ВнД ВхД НД CMAgMa СО КЗ СпО Рассылка ВхД КЗ Ознакомление Ш ФД СО КЗ ВнД ИсхД CMAgMa Рассылка НД Рассылка СпО ВхД НД ВхД ВнД ФД Согласование СпО СО Уведомление ОРД ИсхД ОРД НД Рассылка ФД СС СпО CMAgMa КЗ Организация 3 СО ВнД ОРД ИсхД Организация 4 Рис.9 Корпоративные и внутренние БД в организациях К корпоративным БД обычно относятся: уведомления; согласование; ознакомление; шлюз СМ (Ш); структура системы (СС). Минимально необходимыми корпоративными базами являются «СС» и «Шлюз СМ». СО относится к внутренней БД, т.к. в других организациях доступна только на чтение. Особенность СО заключается в том, что все эти БД из всех организаций должны быть в виде реплик установлены на всех серверах Компании. В основном именно наличие корпоративных БД, через которые осуществляется обмен информацией с использованием механизма репликаций и позволяет говорить о CompanyMedia, как о корпоративной информационной системе. 34 2.2. Основные информационные объекты в СЭД В документоориентированных базах данных Domino/Notes данные хранятся в хранилище объектов (NFS). Документ в БД Notes является основной единицей хранения информации. Все документы отличаются по своей структуре, которая различается формой. Форма содержит в себе набор полей определенных типов. Данные в БД слабо структурированы: документ может обладать полем, которое отсутствует у другого документа. Поддерживается динамическое добавление поля к документу. Выделение памяти под поля документа происходит в зависимости от того количества, которое необходимо для хранения документа. БД Notes поддерживает любые типы данных (текстовые, числовые, время, дата, графические образы, видео, формат MS WORD и др.). В Notes реализована документная модель обработки. Пользователям предлагаются такие полезные функции, как: Возможность хранить форматированные тексты, присоединенные и внедренные объекты. Универсальное хранилище объектов и точка доступа к информации; Поддержка родительских и дочерних отношений документов; Управление версиями. Когда пользователь вносит изменения в документ, инструменты Lotus Notes отслеживают их и вносят отметки о документе, помечая его основным или производным от оригинала. Изменения могут производиться несколькими пользователями. Функция может быть модифицирована в зависимости от потребностей рабочей группы; Документ в Lotus Notes может иметь «ссылку» на другие документы. Масштабируемость системы зависит от доступных физических ресурсов. Размер хранилища объектов более ничем не ограничен. Обеспечение надежности производится алгоритмами протоколирования транзакций, 35 ведений журналов. Существуют отдельные сервисы репликации, маршрутизации. В данной работе рассматриваются документы типа входящие. Для работы с документами входящего типа используется следующие формы: РКК – карточка документа с его основными реквизитами, которые заносятся при регистрации; cопроводительное письмо; карточка резолюции – используется для фиксации в БД созданных резолюций карточка исполнения – отчет об исполнении документа классификатор – использование классификационных признаков документа, например, «вид документа», «вид доставки». Учет всей входящей корреспонденции, поступившей из других организаций, обеспечивает специальная база данных (УВК). УВК позволяет создавать учетную карточку, в которую можно внести дату документа и исходящий номер, корреспондента, адресатов, заголовок (краткое содержание документа). БД «Входящие документы» (ВхД) обеспечивает регистрацию входящей корреспонденции, поступившей из других организаций, на основе требований, предъявляемых типовой инструкцией по делопроизводству к регистрационно-контрольной карточке входящего документа. ВхД позволяет создавать РКК входящего документа, куда можно занести такую информацию, как: дата и исходящий номер документа, корреспондент, дата регистрации и входящий номер, заголовок (краткое содержание документа) и т.д. Зарегистрированные документы могут направляться на ознакомление одному или нескольким лицам. Инициатором отправки документа на ознакомление может быть любой пользователь, имеющий доступ к 36 документу для чтения. Инициатор ознакомления задает список лиц, которым предлагается ознакомиться с документом (участников ознакомления) и запускает процесс. Участники ознакомления получают уведомления о направлении документа на ознакомление. На входящие документы, поступающие в адрес руководителя, может быть внесена резолюция. Резолюции вносятся руководителями, в адрес которых поступил документ, или лицами, замещающими их в СЭД. Резолюции обычно содержат задания, связанные с исполнением данного документа. При внесении резолюций вводятся имя автора резолюции, текст резолюции, исполнители и срок исполнения резолюции. Исполнителям резолюции посылаются уведомления об этом. Существует также возможность рассылки уведомлений-напоминаний о приближающемся сроке исполнения резолюции. При внесении резолюций 2-го, 3-го и последующих уровней вводятся те же данные. При исполнении документа и резолюций обязательно карточка документа или соответствующая резолюция помечается исполненной. Таким образом, основными функциями ВхД являются: регистрация входящих документов; фиксация сопроводительных писем; учет движения каждого экземпляра и каждой копии; отношение документа к делу по месту регистрации; направление адресатам и/или перенаправление сотрудникам; создание карточек резолюций КР; отметка о доставке адресату или исполнителю; отношение к делу по месту получения или исполнения; создание карточек исполнения КИ; контроль исполнения документа в целом; 37 другим контроль исполнения отдельных резолюций и отдельных исполнителей; хранение в архивных делах. В ВхД предусмотрена возможность ввода образов и распознанных текстов при работе с потоковым сканером. В качестве сканера может использоваться любой сканер, с которым может работать FineReader, поскольку весь интерфейс работы с потоковым сканированием система реализует через эту программу. ВхД имеет режим жесткого разграничения доступа к документам на право создания, чтения, редактирования. Регистрация входящих документов, редактирование РКК, создание и редактирование КР, КИ, классификаторов возможно как в ВхД текущего года, так и в ВхД предыдущего года. Документооборот входящего документа изображен на рисунке ниже: Получение, Исполнение РасписываниеИ сполнители из Резолюция Регистрация св оей организации Вх РКК КР КР КИ Кто делает: КИ Делопроизводитель (общий отдел) Адресаты или по сотрудники исполнит ели из по переадресации других организаций Исполнители (Ав т оматически) и ес ич ат Что делает: м Создает РКК, то Ав вводит перенаправление ВхРКК Отмечает прием Вводит резолюцию Ставит на контроль Снимает с контроля Отмечает исполнение После пост упления отв ет а Отмечает прием Перепоручает (резол юция) Отмечает исполнение ИсхРКК Рис.10 Документооборот входящего документа В Систему CM внедрены решения на базе методологии адаптивного кейс-менеджмента. Адаптивный кейс-менеджемент (или АСМ) – это методология, которая позволяет динамически управлять бизнес-процессами. Инструменты АСМ применимы для работы со слабоструктурированными процессами, используются для решения сложных задач с многоэтапной реализацией. Такие задачи могут стоять 38 перед руководителями и другими сотрудниками, ответственными за организацию выполнения проектов, которые требуют участия нескольких подразделений. Инструменты АСМ позволяют добиться эффективности бизнес-процессов. Одна из проблем, стоящая перед руководителем на этапе решения задачи, состоит в нерегламентированных процессах в организации. Такие процессы никак не фиксируются в системах, и при возникновении их аналогов, сотрудник действует вслепую, т.к. у него нет никаких примеров, иллюстрирующих работу с тем или иным процессом такого типа. Средства адаптивного кейс-менеджмента позволяют управлять процессами, а также сохранять некоторую историю взаимодействия, применение которой повышает эффективность компании. В АСМ предложены такие ресурсы, как: документы, организации, данные о контрагентах, корпоративная база знаний, сведения. Кейс-менеджмеры могут выступать в ролях юристов, маркетологов, специалистов финансового отдела, менеджеров и т.д. У кейсов есть компоненты, которые позволяют комплексно работать над поставленными целями, а также осуществлять контроль хода движения. К таким компонентам относят: Задачи, выполняемые участниками кейса; Документы; Контрольный список – некие контрольные точки, по которым идет выполнение работы; Time-line – события в кейсе Участниками кейса могут быть: Инициатор (по сути, автор кейса) – может быть назначен в автоматическом режиме, а может быть переназначен на другого участника CM; 39 Ответственный – сотрудник, координирующий кейс. Данная роль может быть совмещена с предыдущей; Ответственный за документ – исполнитель, подготавливающий документ к данному сроку; Исполнитель задачи контрольного списка; Участники кейса могут изменять, разбивать или дополнять план выполнения задачи, использовать базу знаний организации, собственными силами проводить моделирование кейса без помощи других специалистов, привлекать новых исполнителей, получать способы решения аналогичных задач, а также обсуждать и выносить свои решения в рамках решения кейса. В системе CM существуют средства для создания шаблонов кейсов с типовыми задачами и документами. Таким образом, при появлении аналогов задач сотрудники ориентируются на некоторый шаблон решения. При этом каждый сотрудник может применить свой подход, не описанный в этом шаблоне. Тем самым в организации обеспечивается эффективная работа над процессами и сокращается время на их решение. 2.3. Построение модели выявления типовых бизнес-процессов Для построения модели выявления типовых бизнес-процессов целесообразно рассмотреть документооборот входящих документов, выбрав наиболее характерные процессы для данного типа документов. 40 Рис.11 Модель документооборота входящих документов На вход процесса поступают документы, обрабатывающиеся сотрудниками отделов с помощью СЭД по определенным регламентам. Выходными данными модели являются различного вида отчеты. Рассмотрим данную модель подробнее, выполнив декомпозицию процесса. Как видно на рисунке 12 поступающий на вход документ проходит следующие этапы: регистрация; рассмотрение; исполнение; отчет об исполнении. На все эти этапы движения документа действуют все те же правила работы, называющиеся регламенты. Обрабатываются соответствующими отделами с участием СЭД. 41 документы Рис.12 Декомпозиция модели документооборота входящих документов При регистрации на документ заводится карточка с определенными полями. Эти поля заносятся в базу данных. Далее документ отправляется лицу, на имя которого он пришел. Данный процесс носит название «Рассмотрение документа». После рассмотрения адресат выносит решение. Следующий этап называется «Исполнение документа». После создается отчет об исполнении. Способ исполнения документа зависит от решения, принятого адресатом. Адресат может запустить процесс ознакомления с документом, создать резолюцию или же сразу исполнить документ. В случае запуска процесса ознакомления или вынесения резолюции будут созданы новые карточки документов. На рис.13 представлен фрагмент, исполнения документа. 42 иллюстрирующий процесс Рис.13 Исполнение документа Остановимся подробнее на процессе под названием «Резолюция». Стоит отметить, что на документ может быть вынесено до 32-ух резолюций 1-ого уровня. На каждую из резолюций 1-ого уровня может быть создано до 32-ух резолюций 2-ого уровня и т.д., пока хватит памяти. Во избежание громоздкости модели остановимся на 3-ех резолюциях 1-ого уровня. 43 Рис.14 Создание резолюций на документ У каждой резолюции должен быть исполнитель (Executer1 для Resolution111, Executer2 для Resolution112, Executer3 для Resolution113). При создании резолюции на документ создается соответствующая карточка резолюции. Далее резолюции проходят процесс исполнения, и данные об исполнении резолюции заносятся в специальные отчеты. Необходимо построить модель, обеспечивающую отслеживание прохождений документов по описанным выше маршрутам (процессам). Следует отметить, что в данной модели в карточках документах будут содержаться только значимые поля. В системе электронного документооборота CompanyMedia поддерживается иерархическая структура хранения данных входящей документации. Это означает организацию информации по принципу родитель-потомок. Разрабатывать алгоритмы построения типовых бизнеспроцессов, используя иерархические базы данных, довольно трудоемкая 44 задача, требующая очень больших затрат мощности ЭВМ и определенного времени для написания сложных запросов. В данной работе предложен алгоритм решения задачи на основе реляционной модели данных. Реляционная модель предполагает использование таблиц, в которых содержатся все необходимая для работы информация. Данные в любой записи из таких таблиц связаны только с одним конкретным объектом. В качестве системы управления базы данных был выбран Microsoft Sql Server и Microsoft Management Studio в качестве среды для работы с СУБД. Существуют методы, позволяющие хранить информацию в иерархическом виде, используя реляционные базы данных. Например, реализация с использованием матрицы смежности. Моделирование такой матрицы заключается во внесении записей в таблицу, применяя механизм ссылок. Выборка происходит с помощью рекурсивных запросов, временных таблиц или хранимых процедур. Однако в системе CompanyMedia разработан специальный сервис под названием «Центр отчетов», позволяющий извлекать данные и выгружать их в xls-формате. Далее требуется провести преобразование xls-формата в формат dbo стандартными средствами импорта данных. Для того чтобы выполнить данный перевод, следует определить структуру хранения информации в реляционной модели. В работе предлагается использовать набор таблиц. Каждая таблица будет отражать определенную процедуру бизнес-процесса, то есть, принимаемое решение на основе поступившего документа. В дальнейшем модель может быть оптимизирована посредством создания шаблонов таблиц. Используя такой набор таблиц, применяется алгоритм классификации бизнес-процессов по определенным признакам характерных для заданных данных. 45 Выводы по главе 2 Во второй главе проанализированы современные системы электронного документооборота. Описаны основные наиболее важные с точки зрения решения задачи объекты СЭД CompanyMedia. Построена модель выявления типовых бизнес-процессов на основе слабоструктурированных данных. Глава 3. Реализация алгоритмов построения деловых процессов на основе реляционной модели 3.1. Сервис построения отчетов Центр отчетов в системе CompanyMedia обеспечивает предоставление данных в виде отчетов. Данные отчеты необходимы многим специалистам, например, сотрудникам, занимающимися аналитикой, менеджментом, а также вопросами юридического характера. Сложность таких отчетов может быть любой, построение может быть по запросам, результатам поиска, по определенным документам, по содержанию документа. Выбор способов построения зависит от вида отчета и требуемой информации. Отчеты могут быть в табличном виде или же в графическом. Также сервис располагает возможностью создания специальных шаблонов, тем самым оптимизируется процесс подготовки отчетов. Информация может быть представлена в различных форматах: xml, csv, xls, html и др. Процесс формирование не приводит к прерыванию работы сотрудника, так как используется фоновый режим. Данные обрабатываются на серверах, но могут также быть задействованы и компьютеры сотрудников. Подготовка данных для входа в построенную модель для решения поставленной задачи предполагает использование Центра отчетов. С помощью сервиса «Центр отчетов» данные переводятся из иерархического вида в набор таблиц в формате xls. В таблицу 1 будут загружены документы формы РКК. В таблицу 2 лист ознакомления с 46 документом. Каждая исполненная резолюция заданного уровня будет выгружена в свою таблицу. Запись таблицы соответствует документу со своим идентификатором 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-го уровня и так далее, пока хватит памяти. В работе алгоритм протестирован на первых 47 трех уровнях, дальнейшее углубление идейно ничего не изменит, а повлечет лишь увеличение объема данных. В главе 2 пункте 2.2 расписан документооборот входящих документов. Из возможных полей при заведении документа выбираются только те поля, являющиеся значимые для определения бизнес-процесса. Для формы «РКК» значимыми полями будут являться: вид документа; корреспондент; подписант; адресат; место регистрации. Значимые поля формы «Резолюция»: автор; исполнитель. Используемые поля формы «Ознакомление»: инициатор; участник. Помимо перечисленных выше полей у каждого документа есть свой номер, однозначно характеризующий этот документ. Не существует никакого другого документа с таким же номером. Столбец со значениями идентификаторов документов будет являться первичным ключом в таблицах реляционной базы данных. Также каждому документу соответствует ссылка на другой, родительский по отношению к нему, документ. Если сам документ является родительский, то в поле ссылка ставится значение 0. Для тестирования алгоритма с помощью среды Microsoft Management Studio созданы следующие таблицы: 48 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 означает, что по данному рабочему месту документ не проходил. Константы - это участие данного 49 рабочего места в бизнес-процессе, а также конкретное местонахождение документа определенного типа на определенном этапе. M1m*n Где m – количество документов; n – количество значимых полей в сумме с возможными бизнес-процессами организации Для построения матрицы M1 используется запрос и средства конкатенации таблиц по их идентификатору и ссылке на родителя. Соединение таблиц реализовано с помощью оператора left join. Оператор left join позволяет выполнить объединение записей из двух таблиц, даже если во второй таблице нет никаких данных о документе. В таком случае в полях проставляется значение Null (0). На основе матрицы M1 строится матрица M2. Строки матрицы М2 представляют собой документы определенного типа. Тип определяется набором значимых полей. Столбцы матрицы M2 представляют собой значимые поля, определяющие тип документа, а также количество прохождения документов заданного типа по определенным рабочим местам. M2m2*n2 Где m2 – количество документов определенного типа n2 – количество значимых полей в сумме с количеством бизнес-процессов организации М1, M2 по сути представляет собой таблицы связей документов. Детализация таблицы связи M2 зависит от требований заказчика. Информация из сводных таблиц может быть обработана в соответствии с критерием. По набору значимых полей выявляются эффективные бизнеспроцессы, т.е. такие процессы, по которым чаще всего проходил документ. Описанный выше алгоритм удобно представить в виде блок-схемы (рис.15). 50 Центр отчетов формирует данные в виде таблиц в формате Xls Импорт данных из Excel в реляционную СУБД Построение матрицы связей M1 Построение матрицы связей M2 Обработка информации из матриц связей M1 и M2 по значимым полям Выгрузка эффективных бизнеспроцессов Рис.15 Блок-схема алгоритма построения типовых бизнес-процессов Выводы по главе 3 В главе 3 описаны средства реализации алгоритма. Показан способ перехода от одной структуры хранения данных к другой. Реализован алгоритм построения типовых бизнес-процессов, предложены способы выявления эффективных деловых процессов. Заключение В выпускной квалификационной работе была поставлена задача построения алгоритмов, позволяющих выявить типовые бизнес-процессы, для создания шаблонов эффективных 51 процессов. Было проведено исследование способов решения данной задачи и выбор наиболее оптимального метода. Разработанные алгоритмы позволяют обеспечить быстрое формирование и исполнение бизнес-процессов организации, сокращая затраты на время и обучение сотрудников. 52 Список литературы 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. 53 Приложение Листинг 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 , 54 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 55 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 56 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 , , , , 57 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 , , , 58 ex311 , adr121 , ex121 , adr131 , ex131 Листинг 3 файл SelectFromBusprocEff.sql select org_name adr , , doc_typ , reg_name , max(am_adr) adrl ex am_adr , , max(am_ex) am_ex adr111 ex111 , , , max (am_ex111) adr211 ex211 , am_ex111 , , max (am_ex211) am_ex211 adr211 ex211 , , , max(am_ex311) am_ex311 adr311 ex311 , , , , max (am_ex311) am_ex311 , 59 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 60 Листинг 4 файл Таблицы.xls – имеющиеся в БД таблицы с данными Posts post_id 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 post_name Ген.директор Зам.директора 1-ый зам 2-ой зам 3-ий зам 4-ый зам 5-ый зам Рук.отдела1 Рук.отдела2 Рук.отдела3 Рук.отдела4 Рук.отдела5 Рук.отдела6 Рук.отдела7 Рук.отдела8 Менеджер1 Менеджер2 Менеджер3 Менеджер4 Менеджер5 Менеджер6 Менеджер7 Сотр1 Сотр2 Сотр3 Departs dep_id 1 2 3 4 dep_name Отдел1 Отдел2 Отдел3 Отдел4 DocTypes typ_id 1 2 3 post_dep NULL NULL NULL NULL NULL NULL NULL отдел1 отдел2 отдел3 отдел4 отдел5 отдел6 отдел7 отдел8 NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL typ_name тип1 тип2 тип3 61 Organisations org_id org_name 1 Орг1 2 Орг2 3 Орг3 4 Орг4 5 Орг5 org_date 01.01.2010 01.03.2010 01.02.2010 01.02.2012 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 45 100 ex_id par_id 109 1 Вид матрицы связей M1 (busproc) из двух строк. Первая строка соответствует названиям столбцов, вторая – документу. doc_id org_name 1 Орг1 doc_idl adr author Ген.директор Сотр1 adrl ex 1-ый 1245 Ген.директор зам doc_typ тип1 reg_name Отдел1 pidl 1 rdoc_id111 adr111 ex111 pid111 45 Ген.директор Рук.отдела3 1 rdoc_i d211 25 adr211 Рук.отд ела3 ex211 Менед жер1 pid2 11 45 rdoc_i d311 154 adr311 Менед жер1 ex311 Менед жер2 rdoc_id131 adr131 ex131 pid131 547 Ген.директор Рук.отдела4 1 62 pid3 11 rdoc_id 121 25 110 adr121 Ген.дир ектор ex121 Рук.отд ела2 pid1 21 1 Вид матрицы связей M2 (busproc2) из двух строк. Первая строка соответствует названиям столбцов, вторая – документам определенного типа. org_name adr Орг1 Ген.директор adrl ex 0 adr111 ex111 adr121 0 ex121 0 reg_name am_adr Отдел3 1 am_ex 0 0 doc_typ тип2 0 am_ex111 adr211 ex211 am_ex211 adr311 ex311 am_ex311 0 0 0 0 0 0 0 am_ex121 adr131 ex131 am_ex131 0 0 0 0 0 63
