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

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

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

	Широкий набор моделей	Выявление узкого места	Понятность	Создание графической модели	Возможность создания прототипа
	6	8	9	5	8
Сервисная система	8	7	7	7	9	274
Система управления	6	8	7	8	6	251

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

Как правило, системы управления разрабатываются для нескольких ролей и между ними происходит взаимодействие под контролем правил, но так мы будем следовать по дереву, то наша система сервисная, поэтому целесообразно использовать нотацию 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. Описание диаграммы потоков

Функция	Описание	Источник
Запрос по критериям	Менеджер вводит в систему критерии для поиска	База данных
Ответ системы	Система выдает лучшие варианты по заданным критериям, которые отсортированы по воронке продаж	База данных
Запрос данных спроса по турам	Директор или менеджер-координатор вводит запрос, какие туры были наиболее востребованы	База данных
Экспорт данных	Информационная система формирует запрос о том, какие туры были наиболее востребованы в формат MS Excel	База данных
Отчеты, графики	Сформированные отчеты в формате MS Excel выдаются пользователю	База данных

ER диаграмма представлена на рисунке 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. Описание диаграммы прецедентов

Действия актора	Отклик системы
1. Менеджер входит в систему и предлагает критерии для поиска вариантов	2. Система выдает лучшие варианты по заданным критериям
3. Менеджер связывается с туристом и уточняет, все ли соответствует требованиям. Если возникли изменения, то вводит их в заявку.	4. Система сообщает, что изменения приняты
5. Менеджер бронирует выбранные, согласованные услуги.	6. Система сообщает, что услуги забронированы и сообщает общую сумму заказа

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

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

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

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

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

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

2.3 Проектирование интерфейса

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

Интерфейс пользователя должен быть:

дружелюбным;

графический;

простой в использовании;

удобство в работе для пользователя;

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

надежность для использования базы данных;

поддерживать платформу Windows.

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

Система имеет следующие функции, а в скобках указано, что надо для реализации:

система должна позволять вводить, редактировать дерево классификации признаков (названия критериев);

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

система должна предлагать пользователю список признаков и соответствующим им критериям в сортированном виде от максимальной конверсии до минимальной конверсии (конверсия);

система должна позволять связывать критерии между собой в измеряемую смысловую связь (степень связанности критериев);

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

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

система должна записывать предпочтения туристов (фамилия, имя, телефон, e-mail, названия точки проведения отдыха, способ передвижения);

журнализация беседы (журнал беседы);

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

внесение изменений в классификацию («воронка продаж»);

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

выгрузка данных в формате excel и word.

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

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

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

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

В соответствии сданными функциями представим интерфейс на рисунке 2.13.

Рисунок 2.13. Проектирование интерфейса

Если турист пришел в первый раз то в поле «ввод нового туриста» открывается форма для ввода контактных данных туриста, таких как фамилия, имя отчество, e-mail, телефон, количество человек и сроки поездки, см. рис. 2.14. После того, как мы ввели данные о туристе, турист выбирается в поле «Турист», см. рис. 2.15, а в поле «Менеджер» выбирается менеджер осуществляющий поиск предложения, см. рис. 2.16. Турист и менеджер выбираются из выпадающего списка и у туриста для быстрого поиска фамилия имя отчество вводиться в поле для поиска. После чего система выделяет необходимую фамилию и менеджер, нажимая на нее начинает вести структурированный диалог.

Рисунок 2.14. Поле для ввода нового туриста

Рисунок 2.15. Выбор туриста

Рисунок 2.16. Выбор менеджера

После того как были выбраны турист и менеджер, выбирается «Группа признаков». Из группы признаков выбирается «Классификационный признак» и если признак не совсем понятен туристу, то нажимается кнопка «Информация о выбранном классификационном признаке», см. рис. 2.17 и турист может ознакомиться с данным признаком, понять его сущность.

Рисунок 2.17. Кнопка «Информация о выбранном классификационном признаке»

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

Выбор осуществляется кнопками «да», «нет». Кнопка «да» означает, что турист согласен с выбором, а кнопка «нет», что не согласен, см. рис. 2.18.

Рисунок 2.18. Кнопки управления для выбора

Слабо связанные признаки и критерии на данный момент выделяются курсивом, и система на следующем шаге их исключает, см. рис. 2.19.

Рисунок 2.19. Слабосвязанные критерии

В результате выбора классификационного признака, критерия и места предлагается предложение. Результат выбора представлен на рисунке 2.20 и выделен жирным, курсивом с подчеркиванием, а ход рассуждения представлен шагами с 1 по 5 шаг.

Рисунок 2.20. Результат выбора

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

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

Вывод

В данной главе рассмотрены методология разработки Feature Driven Development (функционально-ориентированная разработка).

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

Глава 3. Частичное прототипирование информационной системы

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

Рисунок 3.1. Диаграмма классов для генерации части прототипа

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

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

«Стадии»;

«ASP.NET»;

«SQL Microsoft SQL Server»;

«Настройка БД».

Рисунок 3.2. Генерация типов данных

В строке соединения меняем server на .\SQLEXPRESS и создаем в database любую несуществующую базу данных, в нашем случае это будет KRITERII, при генерации она сама создается. И отмечаем галочкой «БД полномочий и БД приложений», см. рис. 3.3. Для реализации нашей базы данных, см. рис. 3.4., воспользуемся стандартной «Картой типов» представленной в программном продукте Flexberry.

Рисунок 3.3. Генерация типов данных и редактирование стадии

Рисунок 3.4. Карта типов

После того, как мы изменили настройки, нажимаем кнопку «Сохранить и закрыть». Далее необходимо повторить процедуру для будущих C# приложений, представленную на рисунке 3.5. Для этого мы правой кнопкой нажимаем на:

«Стадия»;

«ASP.NET»;

«C#»;

«Свойства модели».

Рисунок 3.5. Настройка для C# приложений

В строке «Название компании», «Название продукта», «Каталог для исходящего кода» вводим свои названия латиницей, см. рисунок. 3.6.

Рисунок 3.6. генерация типов данных для C# приложений

Для реализации C# приложений воспользуемся стандартной «Картой типов», см. рис. 3.7.

Рисунок 3.7. Карта типов для C# приложений

После того, как мы изменили настройки, нажимаем кнопку «Сохранить и закрыть».

На диаграмме, представленной, на рисунке 3.1. на классе нажимаем «Редактировать свойства» и в раскрывшемся окне нажимаем кнопку «Атрибуты», см. рисунок. 3.8. Кнопка «NotNull» позволяет показать атрибут, как обязательный или необязательный, поэтому как будет отмечено, так данный параметр будет генерироваться на уровне кода. Если мы указываем «NotNull», то данная функция не позволит закрыть приложение, пока не будет введено значение в данную строку, поэтому важно определиться на уровне модели какие параметры важны для введения. После того, как мы определились какие параметры для нас важны, нажимаем кнопку «Сохранить и закрыть».

Рисунок 3.8. Редактирование свойств

После того, как мы выбрали важные для нас атрибуты диаграмма классов, представленная на рисунке 3.1. измениться. Важные значения атрибутов будут выделены знаком «+».

На основе построенной модели предметной области построим модель прототипа приложения. Для этого, см. рис. 3.9. правой кнопкой мыши встаем на «Систему» далее «ASP.NET», «Утилиты», «Создать представления, формы и приложения».

Рисунок 3.9. Построение модели прототипа приложения

Появляется форма запрашивающая имя приложения, которая в дальнейшем будет использоваться, рисунок 3.10.



Рисунок 3.10. Форма для имени приложения

На рисунки 3.11. представлено автоматическое создание дополнительной модели.

Рисунок 3.11. Автоматическое создание дополнительной модели

После того, как мы автоматически создали дополнительную модель, то во все сущности добавились представления, позволяющие определенный набор полей читать и писать в базу см. рис. 3.12. и 3.13. Генерируются два стандартных представления, которые L для списковой формы и Е для формы редактирования.

Рисунок 3.12. Форма представление

Рисунок 3.13. Форма представления Е и L

Далее мы редактируем атрибуты, для этого нажимаем на кнопку рис. 3.14. и 3.15.

Рисунок 3.14. Кнопка для редактирования атрибутов

Рисунок 3.15. Редактирование атрибутов

И кнопками «стрелочка влево» и «стрелочка вправо» редактируем нужные нам атрибуты, которые будут представлены на форме.

После этого закрываем и сохраняем и Flexberry создает автоматически диаграмму с тремя стереотипами, представленную на рисунке 3.16. Стереотип «application» представляет собой приложение в нем создаются настройки. И стереотипы «editform» и «listform» для списковой формы и формы представления.

Рисунок 3.16.Диаграмма со стереотипами

В стереотипе «application» выбираем «Редактирование свойств», далее нажимаем кнопку «Containeres» и выходит следующая форма см. рис. 3.17.

Рисунок 3.17. Редактирование формы

Далее с помощью кнопки «Добавляем новую папку» и расставляем в соответствии с нашим представлением.

Далее в «Конфигурации» проверяем, встали ли настройки в соответствии с параметрами, которые мы задали на рисунке 3.3. Чтобы .\SQLEXPRESS и созданная нами база данных соответствовали.

После того, как мы отредактировали наши формы мы генерируем базу. Для начала генерируется «Стадия», «ASP.NET», «SQL», «Microsoft SQL Server», “Привести БД в соответствие с моделью» см. рис. 3.18.

Рисунок 3.18. Приведение БД в соответствие с моделью

После удачной генерации скрипта появляется сообщение см. рисунок 3.19. Нажимаем «Ок».

Рисунок 3.19.Сообщение об удачной генерации скрипта

Следующий шаг - это генерация web-приложения, для этого генерация происходит в С#. По кнопке «Стадия» нажимаем «ASP.NET», «С#», «Генерировать и компелировать», процесс представлен на рисунке 3.20.

Рисунок 3.20. Генерация web-приложения

После удачной генерации web-приложения появляется сообщение. Для того чтобы запустить web-приложения необходимо запустить Visual Studio в папке CodeGen.

Для того чтобы запустить web-приложения необходимо авторизироваться. Создаем пользователя администратора во Flexberry. Для этого нажимаем на «Стадию», далее «ASP.NET», C#, Microsoft SQL Server, «Полномочия», «Создать пользователя по умолчанию» создается код и появляется сообщение о создании пользователя с логином и паролем, см. рис. 3.21. и 3.22.

Рисунок 3.21. Создание пользователя

Рисунок 3.22. Создание пользователя 1

Нажимаем «Ctrl» + F5, на вкладке «Отладка» нажимаем «Запустить без отладки». И появляется сообщение о форме входа см. рис. 3.23.

Рисунок 3.23. Форма входа

В «Форму входа» вводим логин и пароль, представлены на рисунке 3.24. полученные при создании пользователя.

Рисунок 3.24. Вход в систему

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

Рисунок 3.25 Структура проекта

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

Документация пользователя для работы с системой

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

Шаг 1. Для входа в систему администратор выдает пользователям логин и пароль.

Шаг 2. В поле «Турист» менеджер по туризму вводит контактные данные о туристе такие как: ФИО и телефон.

Шаг 3. В поле «Группа признаков» выбирается наиболее интересующий признак туриста на данный момент. После того, как выбранный признак согласован с туристом нажимается клавиша «Ok».

Шаг 4. В случае если появляется новый признак, который не был внесен в систему, то в поле «Группа признаков» вводим новый и фиксируем какие критерии будут связаны с данным признаком в процессе критериального выбора.

Шаг 5. Далее система предлагает критерии и турист выбирает наиболее интересующие его критерии на данный момент. После того, как выбранный критерий согласован с туристом нажимается клавиша «Ok».

Шаг 6. Далее система предлагает место и турист выбирает наиболее интересующие его места на данный момент. После того, как выбранное место согласован с туристом нажимается клавиша «Ok».

Шаг 7. После того как выбрано место, система предлагает оптимальное, но достаточное количество предложений по выбранному критериальному признаку.

Шаг 8. Система анализирует предпочтения туристов и выбранные ими места для ежемесячных онлайн-отчетов о заполняемости и предпочтениях туристов.

Выводы

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

Заключение

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

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

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

Также были сформулированы требования к интерфейсу и спроектирован его внешний вид.

В ходе работы были выполнены поставленные задачи. Цель работы достигнута.

Результаты исследования были представлены на конференциях:

VII студенческой научно-практической конференции «Информационные технологии - фактор успеха в бизнесе» НИУ «Высшая школа экономики» г. Пермь 22 апреля 2016 г.;

I международной научно-практическая конференции «Индустрия туризма и сервиса: актуальные проблемы, достижение, развитие» г. Санкт-Петербург 30 апреля 2017 г.;

во Всероссийской научно-технической конференции «Автоматизированные системы управления и информационные технологии» г. Пермь 23 мая 2017 г.

Библиографический список

Абатурин А.А. Совершенствование системы управления индустрией туризма в регионе: автореф. дис. эконом. наук 08.00.05 / Абатурина Андрея Александровича. - Москва., - 2011. - 201 с.

Автоматизация турбизнеса [Электронный ресурс]//ERP travel. - URL: http://www.erp.travel/ (дата обращения: 13.03.2017).

Аксенова О.П., Аксенов К.А., Антонов А.С., Смолий Е.Ф. Анализ графических нотаций для имитационного моделирования бизнес - процессов предприятия [Электронный ресурс]/ О. П. Аксенова, К. А. Аксенов, А. С. Антонов, Е. Ф. Смолий//Современные проблены науки и образования. - URL: https://science-education.ru/ru/article/view?id=9745 (дата обращения 15.03.2017)

Аргументация в продажах [Электронный ресурс].//Блок консультанта фаберлик. - URL: http://faberlic-usluga.ru/blog/argumentacija-v-prodazhakh/ (дата обращения: 03.03.2017).

Воронка продаж: определение, этапы, показатели, метрики [Электронный ресурс].//Маркетиногое агенство «Биплан» - URL: https://biplane.ru/blog/voronka-prodazh/ (дата обращения: 13.03.2017).

Гуляев В. Г. Мультипликативный эффект в туризме.//Вестник РМАТ, №3, 2011.

Жуков А.А. Организационно-экономические методы повышения эффективности въездного туризма в регионе: автореф. дис. эконом. наук: 08.00.05/ Жукова Алексея Александровича. - Санкт-Петербург, 2004. - 24 с.

Зорин И. В., Квартальнов В. А. Энциклопедия туризма: Справочник. - М.: Финансы и статистика, 2000. - 368 с.

Иваницкая Т. Ю. Развитие туристких услуг на основе маркетинга: автореф. дис. эконом. наук:/Иваницкой Татьяны Юрьевной. - Белгород, 2010. - 238 с.

Кабушкин Н.И. Менеджмент туризма: -- Мн.: БГЭУ, 1999. - 644 с.

Классификация [Электронный ресурс]//Гуманитарные технологии информационно-аналитический портал. - URL: http://gtmarket.ru/concepts/6879 (дата обращения: 07.03.2017).

Колодкина Ю. И. Предоставление туристской информации по критериальному выбору//Индустрия туризма и сервиса: актуальные проблемы, достижение, развитие: сборник научных трудов по материалам I Международной научно-практической конференции 30 апреля 2017. - Санкт-Петербург.

Конверсия (в интернет - маркетинге) [Электронный ресурс]//ВикепедиЯ Свободная энциклопедия. - URL: https://ru.wikipedia.org/wiki/Конверсия_(в_интернет-маркетинге) (дата обращения: 13.03.2017).

Лиоба Верт. Экономическая психология. Теоретические основы и практическое применение./Пер. с нем. - Х.: Гуманитарный центр, 2013. - 432 с.

Перемены изнутри. Какой маркетинг нужен компаниям, чтобы забыть про кризис?// Маркетолог № 05, 2010 г.

Пирогов В. Ю. Информационные системы и базы данных: организация и проектирование: - СПб.:БХВ-Петербург, 2009. - 528 с.

План Amway по продажам и маркетингу [Электронный ресурс]// Amway возможности дохода - URL: http://www.amway.ru/start-a-business-new/income-opportunities#.WMmV24m3nqD (дата обращения: 03.03.2017).

Платная консультация: мечта или реальность? [Электронный ресурс]// Туристический портал - URL: http://travel-simply.ru/platnaia-konsyltaciia-mechta-ili-realnost/ (дата обращения: 23.01.2017).

Платные консультации в турагестве от 28.10.2013 [Электронный ресурс]// PROFI+TRAVEL - URL: http://profi.travel/articles/185/details (дата обращения: 23.01.2017).

Платный подбор тура: как оформить? от 13.09.2016 [Электронный ресурс]// НП «Пермская туристическая гильдия» - URL: http://www.ptgperm.com/novosti_turizma/platnyj_podbor_tura_kak_oformit/ (дата обращения: 23.01.2017).

Россия поднялась на 43-е место в мировом рейтинге конкурентоспособности в сфере туризма ВЭФ [Электронный ресурс]//Интерфакс туризм - URL: http://tourism.interfax.ru/ru/analytics/market_overview/40340/ (дата обращения: 05.05.2017).

Россияне стали чаще ездить на отдых семьями [Электронный ресурс]// НОО «Ассоциация туроператоров» - URL: www.atourus.ru дата обращения 02.02.2017).

Саак А. Э., Пшеничных Ю. А. Менеджмент в социально-культурном сервисе и туризме. - СПб.: Питер, 2007. - 512 с.

Системы автоматизации турфирмы: вчера, сегодня, завтра [Электронный ресурс]// Тонкости PRO - URL: https://pro.tonkosti.ru/it-tehnologii_v_turizme/sistemy_avtomatizatsii_turfirm_vchera_segodnya_zavtra-31135061 (дата обращения: 13.03.2017).

Скобкин, С. С. Экономическая стратегия развития индустрии гостеприимства в Российской Федерации: методология и практика: автореф. дис. эконом. наук: 08.00.05 /Скобкина Сергея Сергеевича.- М., 2013. - 50 с.

Сладких, Л. С. Совершенствование механизма управления туристскими активами в рамках развития услуг в сфере внутреннего туризма в России: автореф. дис. эконом. наук: 08.00.05 /Сладких Лилии Сергеевны. - М., 2013. - 135 с.

Субботин А. Классификация. Формы систематизации знаний [Электронный ресурс]/А. Субботин//Гуманитарные технологии гуманитарно-аналитический портал - URL: http://gtmarket.ru/laboratory/basis/3794/3796 (дата обращения: 07.03.2017).

Типы вопросов в продажах [Электронный ресурс]//World$ellers - URL: http://worldsellers.ru/tipy-voprosov-v-prodazhax/ (дата обращения: 03.03.2017).

Тян Е. Г. Потребительская оценка совокупной ценности инновационного продукта в условиях ускоряющихся рыночных изменений.//Маркетинг в России и за Рубежом 2013 г. №1, 2013.

Фёдоров И.Г. Моделирование бизнес-процессов в нотации BPMN2.0 / Монография, Москва 2013 г. МЭСИ. - 255 стр.

Федоров И.Г. Сравнительный анализ нотаций моделирования бизнес-процессов. Открытые системы № 08, 2011.

Федоров Н. В. Проектирование информационных систем на основе современных CASE-технологий. - М.: МГИУ, 2008. - 278 с.

Что такое конверсия в продажах - определение, расчет и применение [Электронный ресурс].// Бизнес журнал для начинающих предпринимателей. - URL: http://business-ideal.ru/chto-takoe-konversiya-v-prodazhax-opredelenie-raschet-i-primenenie (дата обращения: 13.03.2017).

Шаповал Г. Ф. История туризма. - Мн.: «Экоперспектива», 1999. - 303 с.

Широкова Г.В. Применение информационных технологий в индустрии туризма: дис. эконом. наук:08.00.05/Широковой Галины Викторовны. - Санкт-Петербург, 1998. - 178 с.

Приложение А

Выбор направления туристами на ноябрьские праздники

Рисунок А.1. Выбор направления туристами на ноябрьские праздники

Приложение Б

Отчет предпочтений за 2016 год Некоммерческого отраслевого объединения Ассоциации Туроператоров при подборе тура у туристов

Таблица Б.1. Отчет предпочтений за 2016 год Некоммерческого отраслевого объединения Ассоциации Туроператоров при подборе тура у туристов

№	Предпочтения
1	Состав путевки: 70% - семьи/туры на двоих; 15% - одноместное проживание; 8% - путешествие на три персоны;
2	Предпочтения при выборе проживания: 30% - отели 3*; 24% - отели 5*; 23% - отели 4*; 11% - бунгало;
3	Питание: 45% - «система все включено»; 23% - питание по системе полупансион; 15% - трехразовое питание; 15%- питание на базе завтраков.

Приложение В

«Яндекс статистика» наиболее востребованных предпочтений для отдыха

Таблица В.1. «Яндекс статистика» наиболее востребованных предпочтений для отдыха

№	Направление	Количество запросов	Наиболее востребованные туроператоры направления
1	Тайланд	6,35%	«Пегас Туристик», «Анекс Тур»
2	Турция	27,70%	«Пегас Туристик»
3	Индия (ГОА)	4,75%	«Библио Глобус», «Анекс Тур»
4	Вьетнам	5,84%	«Пегас Туристик», «Анекс Тур»
5	Египет	5,64%	-
6	Финляндия	6,55%	пользователями не уточнен желаемый туроператор
7	Доминиканская республика	10,33%	«Анекс Тур»
8	Италия	22,19%	«Библио Глобус», «Натали Турс»
9	Израиль	1,74%	«Библио Глобус»
10	Китай	8,91%	пользователями не уточнили желаемого туроператора

Приложение Г

Бланк опросника

Таблица Г.1. Бланк опросника

Бланк опросника

Время начала:

Время окончания:

Вопросы от туриста:

Вопросы туристу:

Характеристика:

новичок

«поговорить»

опытный путешественник

Итог беседы:

да

нет

подумаем

Приложение Д

Результаты констатирующего эксперимента

Рисунок Д.1. Результаты констатирующего эксперимента

Рисунок Д 2. Результаты констатирующего эксперимента

Приложение Е. Техническое задание

«Утверждаю»

Директор ООО «СамМит»

_________(Борисова А. Г.)

«____»__________20____ г.

Техническое задание

на разработку «Информационной системы

подбора актуальных туристских предложений»

Пермь, 20____

Общие сведения.

«Информационная система подбора актуальных туристских предложений».

Заказчик - ООО «СамМит».

Исполнитель - определяется по конкурсу.

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

Политика согласования между Заказчиком и Поставщиком опирается на следующие нормативные документы:

приказы;

основные положения в области информационных технологий, утвержденные решением Правления;

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

Техническое задание разработано в соответствии с гостом ГОСТ 34.602_89.

Начало разработки - 01.04.2017.

Окончание разработки - 01.10.2018

Работы по разработке информационной системы финансируются за счет средств ООО «СамМит».

Приемка «Информационной системы подбора актуальных туристских предложений» осуществляется в присутствии Заказчика и Исполнителя.

Назначение системы.

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

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

Характеристика объектов автоматизации.

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

Эксплуатация системы осуществляется в условиях окружающей среды.

Требования к системе.

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

В систему вводится цифровая подпись.

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

Пользователи до начала работы с бизнес-приложениями ИТ системы должны пройти обучение. Процесс сопровождения осуществляется 1 год с возможностью пролонгации.

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

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

Используя информационную систему, пользователи выполняют нижеследующие задания:

формирование и редактирование проездных документов;

обновление предпочтений путешествия в личном профиле путешественника;

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

определять статус проездного документа в любое время.

Система выполняет следующие задачи:

просмотр и утверждение проездных документов;

отмена авторизации;

возвращение по дереву диалога для внесения изменений или исправлений;

редактирование конверсии признаков и критериев;

делегировать и отзывать полномочия на подпись.

Сообщения об ошибке может приходить если:

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

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

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

Состав работ по созданию системы.

Этапы работ выполняются в соответствии с ГОСТ 32 и приведены в таблице Е.1.

Таблица Е.1. Этапы работ

Этап	Выполняемые работы	Результат	Сроки
1	Этап разработки технического задания «Информационной системы подбора актуальных туристских предложений»	Техническое задание	01.04.2017 - 15.04.2017
2	Проектирование системы	Технический проект	15.04.2017 - 15.05.2017
3	Создание пилотного прототипа	Откорректированные требования	15.05.2017 - 01.09.2017
4	Ввод в эксплуатацию	Протокол испытаний, руководство пользователя, методические пособия	01.09.2017 - 01.10.2017
5	Сопровождение	Протокол о сопровождения	01.10.2017 - 01.10.2018

Приемка информационной системы.

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

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

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

Состав и содержание работ.

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

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

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

вебинары;

выездные лекции;

выставление инструкций.

Состав ресурсов - средства технические, трудовые ресурсы (аналитик, тестировщик, специалист поддержки, технический писатель, менеджер, экономист).

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

Рабочие места пользователей - персональные компьютеры, системное ПО рабочих мест пользователей, периферийные устройства.

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

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

должностное лицо, отвечающее за эксплуатацию и обеспечение работоспособности сегмента инфраструктуры, вводимого в промышленную эксплуатацию;

сроки разработки информационной системы;

сроки сопровождения.

Специалист Поставщика разработки информационной системы присутствует на предприятии в течение 14 рабочих дней (по договоренности договором), для проверки как функционирует система.

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

Период поддержки - 1 год с возможностью пролонгации. Адаптация доведение до уровня необходимого Заказчику.

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

Документирование системы.

Документирование системы осуществляется приказами, должностными инструкциями, ведомостями, пояснительными записками в соответствии с ГОСТом.

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

...