Дипломная (вкр): Автоматизация формирования оптимальных вариантов туристских предложений

2.2 Моделирование бизнес-процессов

Бизнес-процессы можно описывать несколькими способами: в форме текста, в виде таблиц или предоставлять графически. Но для более наглядного представления наиболее логично бизнес-процессы представлять графически [34]. Для графической модели построения применяются нотации IDEF, ARIS UML, BPMN [34].

Чтобы понимать модели бизнес-процессов И. Г. Федоров [36] вводит понятие перспективы. Под данным понятием понимается некая направленность, которая может выразить направление бизнес-процессов. И вводит четыре понятия перспективы:

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

·        поведенческая - описывается план работ и расписание выполнения работ участниками;

·        информационная - дает представление, какие задачи обрабатывают участники;

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

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

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

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

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

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

Нотация BPMN применяется для систем управления и представляет стандарт, легко читаемый способ анализа бизнес-процессов. BPMN обеспечивает стандартное обозначение, которое понятно руководителям, аналитикам и разработчикам. Цель BPMN заключается в том, чтобы помочь устранить пробелы в передаче данных, которые часто существуют между различными отделами внутри организации или предприятия. BPMN также может помочь визуализировать документы XML (Extensible Markup Language), предназначенные для выполнения различных бизнес-процессов, с общей нотацией.

Диаграмма в BPMN [35] собрана из небольшого набора основных элементов, что позволяет техническим и нетехническим наблюдателям легко понять происходящие процессы.

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

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

Таблица 2.1 Выбор подхода методом вариантных секторов

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

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

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

Flexberry Designer содержит в себе модули расширения для кода генерации и генерации базы данных, также поддерживает SQL и C#.

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

·        LogService - это сервис для записи логов;

·        CurrentUserService - это сервис текущего пользователя, который позволяет получать различную информацию о текущем пользователе, но не зависимо от типа приложения;

·        UserSettingsService - это сервис различных настроек, позволяет хранить настройки для приложений.

Также имеются вспомогательные инструменты, такие как средства для просмотра UML диаграмм.

2.2.1 Модели бизнес-процессов

Поэтому представим наш процесс, как есть на рисунке 2.1. с помощью нотации UML и средства Visio, выявим, что можно будет упростить для поиска вариантов, и опишем его как бы мы хотели его видеть на рисунке 2.2. Диаграммы IDEF0 и потоков данных являются описанием системы и представлены на рисунке 2.3., 2.4., 2.5. Диаграмму намного легче понять, чем описательный текст. Это позволяет упростить общение и сотрудничество для достижения цели эффективного процесса, который обеспечивает высокое качество результата.

Рисунок 2.1 Бизнес-процесс как есть

Рисунок 2.2 Бизнес-процесс как бы хотели видеть

Рисунок 2.3 Диаграмма IDEF0

В таблице 2.2. приводится описание процессов диаграммы IDEF0.

Таблица 2.2 Контекстная диаграмма

После того как мы дали описание функций, проведем декомпозицию диаграммы IDEF0. Декомпозиция представлена на рисунке 2.4.

Рисунок 2.4 Диаграмма декомпозиции IDEF0

В таблице 2.3. представлено описание работ декомпозиции.

Таблица 2.3 Описание работ декомпозиции

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

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

Рисунок 2.5 Диаграмма потоков данных

Дадим краткое описание в таблице 2.4. диаграммы потоков.

Таблица 2.4 Описание диаграммы потоков

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

Рисунок 2.6 ER диаграмма

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

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

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

Применяя данную технологию можно сократить время разработки и минимизировать усилия разработчиков. Для построения диаграмм во Flexberry Designer необходимо создать репозитарий, стадии и системы (см. рис. 2.7. и 2.8.), а создание диаграмм показано на рисунках 2.9. и 2.10.

Рисунок 2.7 Создание репозитария

Рисунок 2.8 Создание стадии

Рисунок 2.9 Создание диаграмм

Рисунок 2.10 Создание диаграмм активности

Построим диаграмму прецедентов, описывающих типы отношений между прецедентами и акторами (см. рис. 2.11.).

Рисунок 2.11 Диаграмма прецедентов

Дадим краткое описание диаграммы прецедентов.

Акторы: турист и менеджер.

.        Турист запрашивает тур по критериям, менеджер уточняет критерии поиска.

.        Турист проверяет все ли позиции выбранного тура соответствуют пожеланиям туриста.

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

Альтернативные потоки: отмена заказа, если туриста не устраивает соотношение выбранные услуги и стоимость.

В таблице 2.5. дадим описание диаграммы прецедентов.

Таблица 2.5 Описание диаграммы прецедентов

Также опишем автоматизируемые бизнес-процессы в нотации диаграмм активностей (см. рис. 2.12.) UML в системе Flexberry, для этого создадим поле на консоли, без создания данного поля невозможно построить диаграмму, это является особенностью продукта Flexberry и разделим его разделителями для введения ролей.

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

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