Методика выбора информационной системы для автоматизации бизнес-процессов (БП) на предприятиях

· дата и время события;

· индикатор успеха или отказа;

· источник события;

· идентификатор или название задействованных данных, системного компонента или ресурса.

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

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

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

Другие стандарты в области информационной безопасности, в том числе СТО БР ИББС-1.0 [11], РС БР ИББС-2.3 [12], ISO 27002 [13], CobiT [14] включают в себя схожие требования к протоколированию событий ИС, поэтому их подробный анализ будет опущен.

2.2 BPMS-системы

Отдельного внимания заслуживают системы класса BPMS (Business Process Management System) - системы управления БП, как способ генерации и анализа журналов событий. Основная концепция очень проста - создаётся модель БП, с указанием всех необходимых связей, ресурсов и исполнителей, и отслеживается ход его выполнения с помощью специальных программных модулей [17].

Gartner в 2013 году обозначила четыре основных сценария, по которым применяются решения в области управления бизнес-процессами:

· специализированные решения для бизнес-процессов;

· реинжиниринг SOA-процессов;

· непрерывное улучшение процессов;

· трансформация бизнеса[18].

Основные функции BPMS:

· моделирование БП;

· исполнение БП;

· мониторинг БП.

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

Необходимым требованием BPM-систем является наличие трех компонент: проектирование, исполнение, мониторинг, что соответствует этапам жизненного цикла БП. Возможность моделировать бизнес-процесс при помощи графического редактора является принципиальной особенностью BPM-систем: проектирование бизнес-процесса должен выполнять бизнес-аналитик без участия программиста, обычно это делается в нотации BPMN (Business Process Management Notation). Ядром BPM-системы, отвечающей за исполнение БП, является его «движок» (BPM Engine). Он стартует экземпляры бизнес-процессов, отслеживает смену их состояний, хранит значения реквизитов, выполняет бизнес-правила. Далее, при мониторинге выполнения БП, бизнес-аналитику не приходится выяснять, на каком этапе сейчас тот или иной процесс, т.к. для каждого экземпляра БП можно просмотреть его текущее состояние и ценную статистику о параметрах выполнения экземпляров бизнес-процессов.

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

Для примера, можно привести систему ELMA BPM, в которой есть средства интеграции с основными корпоративными приложениями (SOA, CRM, почтовые сервисы, оповещения на почту и по sms). Для российских пользователей плюс системы состоит в тесной интеграции с «1С: Предприятие». У системы богатая поддержка работы с веб-сервисами, что полностью задокументировано разработчиком. Поэтому интегрировать ELMA с любой внешней системой не составляет труда. Кроме того, есть поддержка работы с сервисной шиной (ESB) и интеграция с шинами передачи данных на уровне моделирования бизнес-процессов (JMS, MSMQ). Порталы ELMA встраиваются в корпоративные Порталы: SharePoint, Bitrix [18].

Среди большого количества зарубежных BPMS-систем, отраженных в «квадрате Gartner»: ActiveVOS[20], BizagiBPMSuite[21], ADONIS[22, BonitaOpenSolution[23], IBMBPM[24], существует несколько довольно успешных и многофункциональных российских разработок: ELMA от компании EleWise [18] и RunaWFE, распространяющейся по свободной лицензии LGPL [25].

2.2.1 Runa WFE

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

Система состоит из двух компонент:

· среда разработки (редактор бизнес-процессов):

o создание бизнес-процессов в BPMN нотации;

o создание и назначение на задачи исполнителей;

o создание и назначение на задачи ресурсов;

o создание пользовательских форм соответствующих заданий;

· клиентское приложение:

o авторизация и аутентификация пользователей;

o работа в web-интерфейсе;

o инициализация экземпляров процессов, автоматические назначение исполнителям и отслеживание в реальном времени хода выполнения процесса в виде графа;

o визуализация пользовательских форм при выполнении задач процесса;

o ведение журнала событий о всех действиях пользователя и системы;

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

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

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

Регистрация всех событий производится в общий текстовый файл формата.txt и на примере выполнения задачи «Подготовка пояснительной записки» выглядит следующим образом:

Листинг 1. Журнал событий Runa WFE

18:01:28,602 DEBUG [wfelang] (http--127.0.0.1-8080-2) event 'node-enter' on 'TaskNode{id=ID33, name=Подготовка Пояснительной записки}' for 'Token{id=33, processId=33}'

18:01:28,603 DEBUG [wfelang] (http--127.0.0.1-8080-2) event 'node-enter' on 'Deployment{id=39, name=Budgeting, version=9}' for 'Token{id=33, processId=33}'

18:01:28,604 DEBUG [ru.runa.wfe.execution.Swimlane] (http--127.0.0.1-8080-2) assigning swimlane 'РуководительФЭОобщества' to 'Actor{id=1, name=Administrator, code=-1}'

18:01:28,605 DEBUG [ru.runa.wfe.task.cache.TaskCacheCtrl] (http--127.0.0.1-8080-2) On CREATE: Task{id=null, name=Подготовка Пояснительной записки, assignedTo=null}

18:01:28,606 DEBUG [ru.runa.wfe.task.cache.TaskCacheCtrl] (http--127.0.0.1-8080-2) On CREATE: Swimlane{name=РуководительФЭОобщества, value=Actor{id=1, name=Administrator, code=-1}}

Регистрация выполнения одной задачи процесса регистрируется более чем 10 событиями, что безусловно является избыточным для целей анализа такого лога. Кроме того, в это же время регистрируются системные события, такие как например, авторизация пользователя. Лог имеет всю необходимую для анализа информацию: временные отметки всех событий, наименование и номер экземпляра бизнес-процесса, наименование исполняемых задач, должность (роль) и конкретный пользователь, которому назначена и кем исполнена задача. Структура лог-файла не подразумевает заголовки и идентичные разделительные символы, например, табуляции, что делает дальнейшую предобработку - импорт в системы анализа крайне трудоёмким процессом.

2.2.2 Bizagi Studio

BizAgi - компания занимающаяся в основном поддержкой и улучшением одноимённого продукта - BizAgi BPMS. Система состоит из трёх компонент, выполняющих все основные функции BPMS-систем:

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

· Средства интеграции со сторонними системами и базами данных (SQL, Oracle);

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

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

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

По умолчанию, отслеживание и регистрация событий в журналах отключена, и включить её можно прямо в BizAgi Studio, при том, выбирая типы событий которые нужно регистрировать. Это могут быть события связанные с выполнения экземпляров процессов, события аутентификации, события взаимодействия с базами данных и т.д. Лог событий выполнения процесса Бюджетирования на предприятии выглядит следующим образом:

Листинг 2. Журнал событий BizAgi Studio

2016-05-25 03:28:42.251 None INFO WORKFLOW-------- ASSIGNMENT

2016-05-25 03:28:44.648 None INFO WORKFLOW- activating workitem

2016-05-25 03:28:44.649 None INFO RULES- START EXECUTING RULE True, ID 1000

2016-05-25 03:28:44.651 None INFO RULES-END EXECUTING RULE True, ID 1000

2016-05-25 03:28:44.651 None INFO WORKFLOW- Executing transition id=6 Name=CaI Form Verified? DisplayName=Costs and Incomes Form Verified?

2016-05-25 03:28:44.659 None INFO WORKFLOW- BEGIN: Executing task id=7 Name=Gateway1 DisplayName= on EventTypeOnEnter

2016-05-25 03:28:44.660 None INFO RULES- BEGIN: Policy Name=BOOLEANEXPRESSION

2016-05-25 03:28:44.660 None INFO RULES- Start Time:5/25/2016 3:28:44 AM

2016-05-25 03:28:44.661 None INFO RULES- [Evaluating Boolean Expression 10001 - BoolExp26863]

2016-05-25 03:28:44.661 None INFO RULES- Evaluating conditions with AND

2016-05-25 03:28:44.661 None INFO RULES- Evaluating Operator is equal to with the following parameters:

2016-05-25 03:28:44.661 None INFO RULES- Parameter 0 --> [Budgeting.CostsAndIncomesCorrect] --> [True]

2016-05-25 03:28:44.661 None INFO RULES- Parameter 1 --> [false] --> [False]

2016-05-25 03:28:44.661 None INFO RULES- Condition <Budgeting.CostsAndIncomesCorrect is equal to false> result is FALSE

2016-05-25 03:28:44.661 None INFO RULES- Chrono Summary

2016-05-25 03:28:44.661 None INFO RULES - END

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

2.3 Workflow-системы

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

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

Как говорилось ранее, Workflow-системы не только позволяют контролировать выполнение проектов, но и позволяет учитывать пожелания заказчиков и просматривать процесс удовлетворения этих пожеланий, учитывать при их решении различные видения на проблему со стороны участников проекта. Часто происходят ситуации, когда покупатель оперирует такими понятиями, как задача, степень ее готовности (в процентах), затраченные человеко-часы и деньги, в то время как для исполнителей проекта необходимы другие критерии оценки завершенности, например, разбиение задач на подзадачи, наличие знаний о которых, покупателю не нужны, для него нет смысла углубляться во внутренние процессы компании. Кроме того, важным является наличие средств интеграции со средствами автоматизированного тестирования, управления версиями файлов [16].

Обязательным условием Workflow-систем для разработчиков является интеграция с другими программами, поддерживающими Жизненный Цикл разработки ПО.

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

После создания задачи, можно начинать работу над ее выполнением. Если задача не тривиальна, то на это требуется время, требуется участие других специалистов и не факт, что с первого раза удастся решить поставленную задачу. Поэтому JIRA оперирует понятием Workflow, т.е. это набор этапов, через которые проходит задача. Также Workflow - это набор правил перехода между этими состояниями. Это еще и набор действий, которые выполняются в ходе перехода, условий которые могут быть наложены на состояние и переход. В различных версиях JIRA работа с Workflow выполняется по-разному, например, в старших версиях можно создавать собственный Workflow, и даже можно сделать так, чтобы задача одновременно проходила по нескольким Workflow одновременно. Ниже приведена диаграмма, на которой показаны состояния и переходы, реализованные в JIRA Workflow по-умолчанию (Рисунок 2.1). На данной схеме показаны все события, и переходы между ними, которые регистрируются в журналах JIRA, и которые затем можно использовать для анализа хода выполнения задачи.

Рисунок 2.1 - Workflow-диаграмма по умолчанию в JIRA

Сразу после создания задачи ей назначается статус OPENED (открыта и подлежит решению). Затем исполнитель начинает выполнять присвоенную ему задачу и ставит задаче с IN_PROGRESS (задача в разработке). После завершения выполнения задачи, её статус изменяется на RESOLVED (задача была решена). Так бы выполнилась задача в идеальном случае, однако очень часто, в выполненной задаче находятся ошибки, и в таком случае, она переводится в состояние REOPENED (открыта повторно), после чего исполнитель исправляет недочёты и повторно переводит в состояние RESOLVED. Только после того как задача была проверена и все ошибки исправлены, ей меняется статус на CLOSED (задач завершена).

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

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

2.4 1С: Предприятие8

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

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

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

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

· дата и время события;

· пользователь, инициировавший событие;

· идентификатор компьютера пользователя;

· идентификатор приложения;

· номер сеанса;

· наименование объекта, над которым было произведено действие;

· наименование действия;

· статус транзакции (отменена/отложена/произведена);

· дата и время транзакции.

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

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

Выводы

В данной главе представлен анализ стандартов в области информационной безопасности, в том числе PSI DSS-2.0, СТО БР ИББС-1.0, РС БР ИББС-2.3, ISO 27002, CobiT и показаны минимальные требования, необходимые для корректного и безопасного автоматизированного ведения журналирования событий в процессе работы предприятия. Анализ данных стандартов также позволяет говорить о степени проработанности и важности внедрения такого процесса на предприятии для мониторинга, анализа, совершенствования внутренних бизнес-процессов.

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

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

информационный журналирование событие автоматизированный

Глава 3. Анализ логов событий и формирование системы взвешенных критериев

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

Администраторы систем уже десятки лет производят анализ системных логов для выявления путей появляющихся ошибок с при помощи текстовых редакторов, но только в последнее время появляются ИС позволяющие визуализировать и проводить глубокий анализ огромного количества информации, содержащейся в логах. Результатом анализа могут являться графическое представление бизнес-процессов, т.е. модели описывающие жизненные цикл наиболее часто встречаемых последовательностей событий (workflow instances). Наиболее часто используемыми методами анализа логов событий являются методы Process Mining. Под ProcessMining понимается методы извлечения структурированных представлений процессов из наборов записей реальных событий [28].

Process Mining стал очень популярной методикой анализа по нескольким причинам:

· результаты анализа используются для нахождения реальной картины работы сотрудников или бизнес-процессов;

· Process Mining используются для Дельта-анализа, позволяющего сравнивать и оценивать регламент бизнес-процесса и реальный ход его выполнения [27].

Всё это позволяет оптимизировать бизнес-процессы (Business Process Reengineering), удалять лишние переходы, процессы, перераспределять ресурсы, пересматривать сроки выполнения задач и т.д.

Методы Process Mining реализованы в специальных аналитических системах, таким как ProM [31], Logentries [32], Celonis [33] и т.д. Все продукты предоставляют возможность в тестовом режиме в течении некоторого времени протестировать функциональные возможности.

3.1 Метод получения системы взвешенных критериев

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

3.1.1 Получение весов критериев

В задачах многокритериального выбора альтернатив возникает необходимость объективной оценки важности частных критериев. Как и в методах, имеющих аксиоматическое обоснование, так и в эвристических методах информация, требуемая для вычисления коэффициентов важности критериев может быть получена от лиц, принимающих решения (ЛПР). Существует множество способов определения степени важности критериев, наиболее известные из них [39]:

· метод отношений (метод парных сравнений), часто используемый как этап в методе SMART. Эксперт ранжирует критерии по степени важности, значение наиболее важного критерия назначается как 10 баллов (либо вес наименее важного назначается как 1 балл), а значения важности других критериев определяется из отношения критериев по важности.

· Метод наибольших отклонений (swing). Первоначально, всем критериям выставляются худшие весовые оценки, затем эксперты просят оценить, по какому критерию изменение от минимального значения до максимального оценки наиболее важно. После, находится второй по важности критерий и т.д. Изменению наиболее важного критерия (swing) присваивается 10 баллов. Эксперты определяют в баллах значения изменений от худших до лучших оценок по остальным критериям.

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

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

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

При проведении опросов больших групп экспертов, их суждения могут сильно разниться, однако то, на сколько велико это различие, имеет немаловажное значение. Групповая оценка может считаться достаточно надежной только при условии хорошей согласованности ответов отдельных специалистов. Для анализа разброса и согласованности оценок применяются статистические характеристики - меры разбросаили статистическая вариация [40]. Согласованность мнения ЛПР можно оценивать по величине коэффициента конкордации и по множеству других коэффициентов, которым уделено должное внимание во многих работах.

3.1.2 Weighted Sum Method

Самым очевидным способом снизить размерность задачи - свернуть все критерии в один-единственный обобщённый (интегральный, синтетический, компромиссный агрегированный, комплексный, составной, глобальный, и т.д.) критерий F, представляющий собой агрегат критериев, полученный путём их взвешивания на основе степени важности каждого из них. Приведённая идея вошла в основу метода взвешенной суммы критериев - Weighted Sum Method (WSM).

Одни из них обусловлены привлекательными достоинствами WSM:

· метод представляется простым и понятным,

· он удобен для расчетов,

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

Пусть Z_i - множество допустимых значений (градаций) критерия f_i (его «шкала»). Каждая альтернатива (план, стратегия, вариант) x характеризуется значениями критериев , критериальную, или векторную оценку этого варианта ).

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

, (3.1)

где числа w_i, w_i>0 (обычно в сумме равные 1) - это веса (коэффициенты важности), предназначенные для оценивания, различной степени весомости, значимости критериев. Назначив значения весов этих коэффициентов каждый вариант x с использованием формулы (3.1) характеризуется одним числом - значением взвешенной суммы критериев

(3.2)

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

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

3.1.3 Процесс получения системы взвешенных критериев

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

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

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

Рисунок 3.1 - Анализ выполнения БП «Подготовка ежемесячного финансового отчёта»

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

3) Анализ журнала с помощью систем, реализующих Data-Mining, Process-Mining методы. На этом этапе необходимо выбрать наиболее подходящий алгоритм анализа, в зависимости от размерности и принимаемых данными значений.

4) Проверка результатов анализа включает в себя анализ построенных на предыдущем этапе моделей на предмет корректного отражения и расчёта значений измерений, связей между процессами. Возможно входной набор данных был подан некорректно и необходимо переопределить назначения измерений, вернувшись к этапу 2. Если калькуляция параметров произведена корректно, то переходим к следующему шагу. Обычно на этом этапе происходит выгрузка результатов анализа.

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

6) Расчёт средневзвешенных оценок критериев для каждого процесса осуществляется согласно методу WSM, описанному в главе 3.1.1.

7) Нормализация полученных оценок позволит представить их в удобном для аналитика диапазоне и привести их к общему с другими оценками виду, например от 0 до 1 или 10.

3.2 BizAgi-Studio

В главе 2.2.2. уже были рассмотрены возможности BPMS-системы BizAgi-Studio и продемонстрирован вид регистрируемых в журнале событий. Данная ИС имеет встроенные возможности по анализу генерируемых ею журналов событий по различным метрикам в удобном графическом интерфейсе и с возможностью экспорта в Microsoft Excel.

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

В подсистеме BizAgi Modeler был описан бизнес-процесс подготовки и сдачи ежемесячного бюджета компании в котором участвует три исполнителя: Financial Manager, Economist, Parent Organization Economist, см. рисунок3.2. Каждый исполнитель выполняет определённые ему функции на своём рабочем месте в сгенерированных, для выполнения задач, формах. Настройки позволяет делать срезы данных по большому количеству аналитик: например, анализировать зарегистрированные события только на интересующем отрезке времени, либо определённым сотрудником (можно выявить зависимость времени выполнения задач от профессиональных качеств сотрудников).

Рисунок 3.2 - Анализ выполнения БП «Подготовка ежемесячного финансового отчёта»

При выделении задачи, появляется основная информация о выполнении задачи, на рисунке 3.2. показано выполнение процесса «Prepare Explanatory Notes» - «подготовка пояснительной записки» за полтора года со следующими характеристиками:

· Exp Duration(mins) - ожидаемое время выполнения задачи;

· Avg Duration(mins) - среднее время выполнения задачи по выбранным фильтрами событиями;

· Closed On Time - количество раз, которые процесс был выполнен вовремя (Exp Duration > Avg Duration;)

· Closed Overdue - количество раз, которые процесс не был выполнен в установленные сроки (Exp Duration < Avg Duration);

· Case Number(usage) - количество анализируемых экземпляров процесса;

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

Выгрузив отчёт по заданному разрезу в Microsoft Excel, получим таблицу следующего вида (таблица 3.1.).

Таблица 3.1 - Результат анализа выполнения БП в BizAgi Studio

CaseID	Activity	Exp Duration(mins)	Fact Duration(mins)
1	Prepare Working File	15	18
1	Fill Investing Program	30	16
1	Fill Costs and Incomes Form	120	144
1	Fill Cash Flow Budget Form	120	126
1	Verify Forms	30	34
1	Fill Costs and Incomes Form	120	86
1	Fill Cash Flow Budget Form	120	21
1	Verify Forms	30	14
1	Fill Cash Flow Budget Form	120	65
1	Verify Forms	30	9
1	Prepare Explanatory Notes	180	164
2	Prepare Working File	15	18
2	Fill Investing Program	30	19
2	Fill Costs and Incomes Form	120	147

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

Проведя группировку задач по их наименованию и найдя средние значения Exp Duration и Avg Duration, сопоставим каждую задачу с должностью исполнителя(Performer Position) и его почасовым должностным окладом (Costs(rubperhour)), как показано в таблице 3.2. Добавляя информацию о должностных окладах, аналитик не может исказить результаты анализа в какую-либо сторону, т.к. размер вознаграждения сотрудников должен быть закреплён приказами, организационными положениями, трудовыми договорами.

Рассчитав регламентируемые и средние затраты на оклады сотрудников при выполнении бизнес-процесса (Exp Costs (rub) и Avg Costs (rub)) необходимо нормировать временные и затратные показатели к 100%.

Получаем нормированные планируемые и средние временные (Exp Time Costs (% of Total Time Costs) и Avg Time Costs (% of Total Time Costs)) и денежные (Exp Costs (% of Total Costs) и Avg Costs (% of Total Costs)) затраты, в процентном соотношении к общей сумме затрат по соответствующему показателю. По факту, таблица 3.2. имеет всего два критерия временной и стоимостной, поэтому необходимо задать два весовых критерия (Time Costs Criteria Weight и Costs Criteria Weight) равные 7 и 3 соответственно, т.е. в данном исследовании преследуется основная цель не снизить издержки производства, а снизить общее время выполнения процесса.

Показатели Exp - плановые и Avg - средние используются здесь для наглядности, при реальном анализе это делать не обязательно. Получив произведения весов критериев на значения критериев, а затем нормировав к 10, получаем окончательную оценку взвешенных критериев (Normalized Weighted Tasks Criteria (Exp) и Normalized Weighted Tasks Criteria (Avg)).

Таблица 3.2 - Получение системы взвешенных критериев на основе анализа BizAgi Studio

Activity	Exp Duration (mins)	Avg Duration (mins)	Exp Time Costs (% of Total Time Costs)	Avg Time Costs (% of Total Time Costs)	Perfomer Position	Costs (rub per hour)	Exp Costs (rub)	Avg Costs (rub)	Exp Costs (% of Total Costs)	Avg Costs (% of Total Costs)
Prepare Working File	15	17	3%	3%	Financial Manager	500	125	142	4%	5%
Fill Investing Program	30	16	6%	3%	Financial Manager	500	250	133	8%	4%
Fill Costs and Incomes Form	120	136	24%	28%	Economist	250	500	567	17%	18%
Fill Cash Flow Budget Form	120	89	24%	18%	Economist	250	500	371	17%	12%
Verify Forms	30	24	6%	5%	Parent Org. Economist	300	150	120	5%	4%
Prepare Explanatory Notes	180	209	36%	43%	Financial Manager	500	1500	1742	50%	57%
Сумма	495	491		3025	3074
Time Costs Criteria Weight	7
Costs Criteria Weight	3
Activity	Weighted Tasks Criteria (Exp)	Weighted Tasks Criteria (Avg)	Normalized Weighted Tasks Criteria (Exp)	Normalized Weighted Tasks Criteria (Avg)
Prepare Working File	0,3	0,4	0,8	0,8
Fill Investing Program	0,7	0,4	1,7	0,8
Fill Costs and Incomes Form	2,2	2,5	5,4	5,3
Fill Cash Flow Budget Form	2,2	1,6	5,4	3,5
Verify Forms	0,6	0,5	1,4	1,0
Prepare Explanatory Notes	4,0	4,7	10,0	10,0
Сумма	10,0	10,0

Полученные оценки наглядно показывают, каким процессам необходима автоматизация в первую очередь, по таблице 3.2. это процессы Prepare Explanatory Notes, Fill Costs and Incomes Form и Fill Cash Flow Budget Form. Плановые оценки показывают оценки, которые бы возможно были использованы, в случае отсутствия анализа реального хода выполнения бизнес-процесса.

3.3 Rapid Miner - ProM библиотека

Rapid Miner [34] - информационная система, разработанная для решения задач Data Mining, не требующая от аналитика (пользователя системы) знания языков программирования. Весь процесс построения моделей анализа данных строится в графическом редакторе при помощи функциональных блоков(операторов), что сильно облегчает работу с системой. Каждый блок выполняет одну определённую функцию и может иметь обязательные входные, а также несколько выходных параметров.

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

Построив простую, логически понятную модель анализа, попробуем проанализировать лог, записанный BizAgi Studio. Для начала, необходимо загрузить лог в репозиторий Rapid Miner, при этом, необходимо контролировать правильное соотношение полей и автоматически присвоенных им типов данных.

Первым этапом анализа будет определение используемого метода анализа в пакете ProM их более 15, принцип их работы и алгоритмы описаны голландским учёным W.M.P. van der Aalst в книге Defining and Executing Process Mining Workflows with RapidProM [30]. Для небольших и не сложных журналов подойдёт Alpha Miner алгоритм, который в качестве входного результата требует журнал событий - ProM Event Log, а в качестве результата анализа даёт Сеть Петри.

Первым элементом на схеме анализа лога, показанной на рисунке 3.3., будет извлечение данных из файла с помощью оператора Retrieve. Затем, для Alpha Miner необходимо преобразовать данные в вид тип ProM Event Log, для этого устанавливаем оператор Data Table to Event Log. Для того, чтобы при анализе результатов не только оценивать построенную сеть, но и видеть преобразованный журнал событий, необходимо создать копию ProM Event Log, и одну из них сразу же отправить в результаты res, а одну на вход в оператор Alpha Miner. Модель, построенную Alpha Miner, можно сразу же показывать пользователю, поэтому соединяем её с res.

Рисунок 3.3 - Модель анализа лога событий в Rapid Miner при помощи ProM расширения

Результат оператора Data Table to Event (см. рисунок 3.4.), построенный на журнале событий, записанном с помощью BizAgi Studio по бизнес-процессу, отраженному на рисунке 3.2., предоставляет обобщённые визуальные инструменты для анализа лога в целом, и рассчитывает частоту появлений событий/процессов в логе.

Рисунок 3.4 - Результат оператора Data Table to Event в Rapid Miner при помощи ProM расширения

Результатом оператора Alpha Miner является Сеть Петри, отражающая переходы между этапами бизнес-процесса, которые хоть раз появлялись в загруженном логе событий. На рисунке 3.5. видно, что все возможные переходы между процессами в данном бизнес-процессе (см. рисунок 3.2.).

Рисунок 3.5 - Результат оператора Alpha Miner в Rapid Miner при помощи ProM расширения

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

3.4 Disco Analysis Studio

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

Демо-версия продукта не позволяет загружать журналы с более чем 100 событиями, а также хранящиеся в формате .xls. Для загрузки журнала, записанного с помощью BizAgi Studio по бизнес-процессу, отраженному на рисунке 3.2., необходимо уменьшить количество событий в журнале и сохранить .xls файл в .csv формат.

Назначение измерений происходит также в графическом интерфейсе, притом основные, необходимые для анализа измерения определяются автоматически, если это возможно. Параметр Exp Time Costs и Avg Time Costs необходимо определить, как Resources, иначе в последующем анализе участвовать они не будут.

Далее система восстанавливает схему бизнес-процесса из журнала и показывает её в виде карты-процесса, показанной на рисунке 3.6.

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

· средняя продолжительность процессов;

· максимальная продолжительность процессов;



Рисунок 3.6 - Карта процесса подготовки ежемесячной финансовой отчётности построенная на основе журнала событий

· общая продолжительность процессов;

· средняя и максимальная частота повторения задач внутри одного экземпляра процесса.

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

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

Выводы

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

Поскольку выражение (3.2) предусматривает, что с коэффициентами важности производятся арифметические операции, то эти коэффициенты, согласно теории измерений, следует рассматривать как результаты количественного измерения важности (причем в шкале отношений), т.е. должны иметь смысл утверждения типа: «Если w₁ = 0,4 и w₂ = 0,2, то первый критерий важнее второго в 2 раза». Предложено множество методов оценивания важности критериев, т.е. на значения величин w_i . Но все они страдают общим тяжелым пороком - точного (формального) определения понятию важности критериев не дается, и полагается, что человек должен исходить из своего понимания, что такое важность. Поэтому для оценивания коэффициентов важности человеку предлагается отвечать на вопросы, сводящиеся в итоге к таким: «Во сколько раз критерий f_i важнее критерияf_j?» или «Какая доля общей (единичной) важности приходится на данный критерий?». Проблема здесь состоит в том, что невозможно установить (а потому и обоснованно формализовать) точный смысл, вкладываемый конкретным человеком в ответы на указанные вопросы [37].

Далее с помощью данного метода и журналов событий, полученных в главе 2, было проведено тестирование метода в нескольких ИС: Rapid Miner - ProM расширение (глава 3.2.), BizAgi Studio (глава 3.3.), Disco (Nitro) Analysis Studio (глава 3.4.). В ходе анализа, было выявлено большое количество недостатков в работе систем (недостаточность функционала), основные из них следующие:

· отсутствие настройки и, соответственно, анализа дополнительных анализируемых измерений (затрачиваемых ресурсов);

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

· отсутствие возможности импорта результатов анализа в другие приложения (для последующего анализа и сохранения результатов).

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

информационный журналирование событие автоматизированный

Заключение

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

В главе 1 были проанализированы экспертные методы, применяемые к разработке критериев для выбора автоматизированных ИС. Из анализа традиционных подходов к определению критериев выбора систем и определению их весомости для вынесения решения сделаны выводы о необходимости избегания экспертных оценок, при оценивании влияния критериев на итоговые оценки рассматриваемых альтернатив.

В главе 2 отражено обоснование использования журналов регистрации событий для решения поставленной проблемы. Рассмотрены стандарты, регламентирующие процесс внедрения, ведения и анализа журналов событий, а также отражающие минимальные наборы регистрируемой информации. Далее был рассмотрен целый класс систем для управления бизнес-процессами - BPMS, предназначенных для управления бизнес-процессами позволяет манипулировать схемой выполнения бизнес-процесса, со всеми используемыми ресурсами и вести регистрацию хода выполнения этих процессов (ведение журнала регистрации событий). В ходе исследования было протестировано две функционирующие BPMS-системы: RunaWFE и BizAgi-Studio и проанализированы генерируемые ими журналы событий. А также некоторый аналог BPM-систем - Workflow системы, в частности, один из самых распространённых и универсальных продуктов - JIRA. В ходе анализа главы 2 была обнаружена основная проблема работы с логами: отсутствие регламентированной структуры. Наличие большого количества стандартов ведения журналов событий игнорируется разработчиками ИС, что в некоторых случаях, делает невозможным их анализ, либо требует огромных усилий для преобразования в подходящий для систем анализа вид.

В главе 3 был разработан оригинальный метод получения системы взвешенных критериев на основе анализа журналов регистрации событий. Самым трудоёмким этапом этого процесса является предобработка данных, и уменьшение размерности данных. Журналы событий несут в себе огромный объём информации, который довольно сложно «переварить» аналитическим системам. Необходимо максимально «отчистить» лог от необязательных измерений, иначе построенный с помощью методов Process Mining процесс будет иметь огромное количество неинформативных и излишних отношений. Журнал событий созданный Runa WFE системой после большого количества попыток предобработки, так и не был загружен ни в одно из используемых систем. Журнал сгенерированный BizAgi-Studio был промоделирован тремя аналитическими системами: Rapid Miner (с помощью библиотеки ProM), BizAgi-Studio и Disco Analysis System, результаты анализа представлены в главах 3.2, 3.3. и 3.4 соответственно.