3.2. Моделирование процесса учета взаимоотношений клиентов с онлайн торговым центром ООО «Нижновтранс». Модель TO-BE
В результате проведенного анализа процесса учета взаимоотношений клиентов с онлайн торговым центром в службе поддержки покупателей, в диаграмму IDEF0 были внесены следующие изменения, в результате применения, которых повышается эффективность работы группы, занимающейся формированием истории заказа, сокращаются сроки исполнения, также сокращается количество ошибок, возникающих в работе, за счет внедрения информационной системы, а, следовательно, сокращения роли «человеческого фактора».
— вся информация о клиентах и магазинах-партнерах хранится в базе данных, из которой удобно и быстро можно получить все необходимые данные;
— система предоставляет простой и в тоже время эффективный механизм для формирования истории заказа;
— любое обращение клиента должно быть зарегистрировано в подразделении;
— в процессе ведения карты заказа добавлена возможность осуществления различных выборок для составления отчетов по различным критериям. Лицам, ответственным за ведение учета взаимоотношений, такая функция понадобится как для систематизации полученных данных, так и для того, чтобы предоставлять отчеты о ходе работ руководству.
В результате выполненного анализа и внесенных изменений, декомпозированная диаграмма А3 выглядит следующим образом (см. рис. 3.1.).
На основе анализа DFD-модели AS-IS, проведенного в параграфе 1.2., предлагаются следующие меры по повышению эффективности движения потоков данных для рассматриваемой задачи.
- Любое обращение клиента по созданному заказу фиксируется в карточке заказа. Оператор онлайн торгового центра ставит тему обращения клиента, закрепляет заказ за службой созданных заказов, записывает суть обращения клиента.
- Служба созданных заказов сортирует заказы по группам, получая тем самым информацию о заказах, по которым поступили обращения клиентов. Видя в карточке заказа суть обращения клиента, специалист группы СЗД принимает решение по сложившейся ситуации, выполняя действия, предусмотренные инструкцией.
- Так как теперь группа СЗД своевременно видит проблему клиента, на решение проблемы уходит меньше времени. Любой сотрудник, повторно принимая звонок клиента, у которого уже были обращения, видит всю историю заказа, тем самым может более грамотно проконсультировать клиента по его вопросу.
- Добавлено необходимое хранилище данных («Карточка заказа»), содержащее подробную информацию о деталях каждого заказа.
- Добавленная база данных также решает задачу контроля выполнения заказа,используя при этом информацию из хранилища данных «Карточка заказа».
Измененная и дополненная декомпозированная DFD-диаграмма представлена на рис. 3.2.
3.3. Объектно-ориентированное проектирование учёта взаимоотношений клиентов с онлайн торговым центром подразделением в ООО «Нижновтранс»
В данном разделе проводится проектирование информационной системы на основе объектно-ориентированного подхода с помощью языка моделирования UML (UnifiedModelingLanguage – унифицированный язык моделирования). UML предназначен для визуального моделирования информационных и других систем, и к настоящему моменту представляет собой набор диаграмм, позволяющих рассматривать информационную систему со всех возможных точек зрения.
3.3.1. Диаграмма вариантов использования
Рассмотрим диаграмму вариантов использования на рис. 3.3.
Оператор принимает входящий вызов, оформляет заказ, регистрирует клиента. При обращении клиента по созданному заказу закрепляет заказ за службой созданных заказов, ставит тему обращения клиента, фиксирует суть обращения.
Служба созданных заказов (СЗД)находит правильное и оптимальное решение возникшей проблемы клиента. Все варианты решения проблем клиента и алгоритм решения поставленной задачи разрабатываются отделом обучения и качества онлайн торгового центра.
В результате использования данной системы клиент получает своевременное и качественное обслуживание. Происходит «естественный отбор» интернет-магазинов, на основе анализа качества их работы. На основе данных о качестве работ того или иного магазина, отдел поддержки магазинов производит интеграцию их рейтинга на площадке онлайн торгового центра.
Магазин-партнер становится заинтересован в качественном обслуживании клиентов, так как в противном случае товары из его ассортимента потеряют места в пятерке первых рекомендуемых площадкой предложений.
Любой клиент может оставить отзыв на онлайн площадке о товаре, работе того или иного магазина, что стимулирует магазины качественно исполнять заказы.
3.3.2. Диаграмма классов для варианта использования «Ведение история клиента»
Рассмотрим диаграмму классов для варианта использования «Ведение истории заказа» на рис. 3.4.
Описание
Класс «Граница». Выбор статуса заказа – форма, предназначенная для выбора статуса заказа.
Операции: Принять.
Класс «Граница». Детали заказа – форма, через которую заносится и получается информация о предоставляемой услуге и клиенте.
Операции: Открыть, проверить наличие, связаться с клиентом.
Класс «Управление». Актуальность заказа – программный модуль, выполняющий конкретные действия – принимает информацию о заказе, его создание, сохранение информации.
Операции: Передача информации, сохранить, выставить статус заказа.
Класс «Сущность». Заказ – таблица, содержащая набор полей.
Атрибуты: Номер ФИО клиента, Контактный данные, Дата создания, Дата доставки.
Операции: Создать, просмотреть информацию, изменить информацию.
Класс «Управление». Выполнение заказа – принимает запросы, выполняющие текущие операции с данными.
Операции: Добавить информацию, Подбор альтернатив, сохранить, Проверка актуальности.
Класс «Сущность». Позиция заказа – таблица, содержащая сведения о заказах клиента.
Атрибуты: Статус заказа.
Операции: Просмотреть информации
3.3.3. Диаграмма классов для варианта использования «Учёт взаимоотношений клиентов с онлайн торговым центром»
Описание
Класс «Граница». Выбор шаблона, где оператор может выбрать необходимую стандартную форму обращения клиента.
Атрибуты: Название вида обращения.
Операции: Создать, Сохранить.
Класс «Граница». Выбор данных о клиенте, где есть возможность выбрать данные о клиентах, заказ, которые были оформлены ранее.
Атрибуты: Наименование, Идентификационный номер, Дополнительная информация.
Операции: Открыть, Создать.
Класс «Граница». Добавление информации о клиенте– форма, через которую заносится информация о новом клиенте.
Атрибуты: Идентификационный номер услуги, Номер клиента.
Операции: Открыть, Ввести информацию, Сохранить.
Существуют две аналогичные формы для информации о магазинах.
Класс «Управление». Менеджер запросов – программный модуль, выполняющий конкретные действия – принимает информацию о заказе, сохранение информации.
Операции: Создать, Получить информацию, Сохранить.
Класс «Сущность». Заказ – таблица, содержащая набор полей.
Атрибуты: Номер заказа, Наименование, Дата оформления, Дата исполнения.
Операции: Создать, Получить информацию, Задать информацию.
Класс «Управление». Проверка корректности – принимает запросы, выполняющие текущие операции с заказом – изменение, сохранение, проверяет соответствие существующим нормативам.
Операции: Зафиксировать изменения, Задать информацию.
Класс «Граница».Закрепление за специалистом- форма, через которую сотрудник может видеть, за ведение каких заказов он назначен ответственным и получать всю необходимую информацию.
Атрибуты: Имя, Идентификационный номер.
Операции: Открыть, Ввести информацию.
Класс «Сущность».Оператор – таблица, содержащая сведения об операторах.
Атрибуты: Номер оператора, Имя сотрудника.
Операции: Создать, Получить информацию, Задать информацию.
3.3.4. Диаграмма последовательности
Ниже представлена диаграмма последовательности для варианта использования «Исполнение заказа», рисунок 3.6.
На данной диаграмме схематично изображен процесс исполнения заказа. Онлайн торговый центр отправляет заказ магазину-партнёру на исполнение. Магазин-партнёр не видит данные клиента, пока не примет заказ.
После принятия заказа, магазину видны контактные данные клиента, условия доставки.
Детали доставки и актуальность заказа может изменять как сам магазин-партнёр, так и онлайн торговый центр. Так, например, если магазин не реагирует на заказ более суток, заказ аннулируется, с магазина при этом всё равно будет снята комиссия.
Выполнение заказа–непосредственно доставка товара или его самовывоз. В случае, если магазин-партнер не принял или не обработал заказ, специалисты онлайн торгового центра подбирают альтернативный товар для покупателя. Если клиента интересуют предложенные ему варианты, оформляется альтернативный заказ с обязательной отметкой о том, взамен какого заказа он был оформлен. Эти данные используются при подсчете процента по восстановлению заказов. Данная практика гарантирует возвращение клиента на площадку онлайн торгового центра.
3.3.5. Диаграмма кооперации
Ниже представлена диаграмма коопераций для варианта использования «Ведение истории клиента» (рис.3.7.).
Онлайн торговый центр отправляет заказ магазину-партнёру на исполнение. Магазин-партнёр не видит данные клиента, пока не примет заказ. После принятия заказа, магазину видны контактные данные клиента, условия доставки.
Детали доставки и актуальность заказа может изменять как сам магазин-партнёр, так и онлайн торговый центр, так, например, если магазин не реагирует на заказ более суток, заказ аннулируется, с магазина при этом всё равно будет снята комиссия.
Выполнение заказа–непосредственно доставка товара или его самовывоз.
3.3.6. Диаграмма состояний
Ниже представлена диаграмма состояний для класса «Заказ» (рис.3.8.).
На диаграмме состояний класса «Заказ» схематично изображены состояния заказов и их последовательность.
Сначала формируется заказ, в случае, если он подвергается изменениям до того, как магазин его подтвердит, магазин эти изменения не увидит, так как данные менялись в базе данных онлайн торгового центра. Как только магазин подтверждает заказ, изменения он может вносить только посредством комментариев. После согласования условий доставки с клиентом, менеджер магазина создает маршрутные листы для торговых представителей, которые занимаются непосредственно доставкой заказа клиенту.
3.3.7. Диаграмма деятельности
При моделировании поведения проектируемой информационной системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и процедурной реализации выполняемых системой операций.
На диаграмме деятельности изображается логика, или последовательность перехода от одной деятельности к другой. Деятельность по созданию заказа начинается с оператора, который фиксирует все обращения покупателя и создает заказы.
После оформления заказа с оператором онлайн торгового центра, заказ попадает в базу данных заказов онлайн торгового центра. После заказ автоматически попадает в корзину магазина-партнера. Если клиент вносит изменения в заказ до подтверждения заказа магазином, то данные меняются сразу в карточке заказа, которая находится в базе данных онлайн торгового центра, что обеспечивает автоматическое изменение данных заказа в корзине магазина-партнера.
Как только магазин видит заказ в своей корзине, происходит проверка наличия товара и подтверждение его менеджером магазина. Если товара нет в наличии, у магазина есть два варианта действий: поиск альтернативы среди своих товаров, либо передача заказа обратно в онлайн торговый центр, который также подбирает альтернативу. Если альтернатива устраивает клиента, оформляется новый заказ, если не устраивает – заказ сохраняется со статусом «Closedalternative».
Служба поддержки магазинов (СПМ) получает данные о всех созданных заказах на площадке для каждого отдельного магазина. На основе этих данных производится расчет комиссии магазина и их рейтинга.
Диаграмма деятельности для процесса «Исполнение заказа» изображена на рис. 3.9.
3.3.8. Диаграмма компонентов
Диаграмма компонентов — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т.п. На диаграмме компоненты с расширением .db – база данных, .exe- исполняемые файлы, .html – web-страницы на языке разметки гипертекста, .hlp – файлы справки, .dll – динамически подключаемые библиотеки.
Диаграмма компонентов изображена на рис. 3.10.
3.3.9. Диаграмма развертывания
Диаграмма развертывания – в UMLмоделирует физическое развертывание артефактов на узлах. Например, чтобы описать веб-сайт, диаграмма развертывания должна показывать, какие аппаратные компоненты («узлы») существуют (например, веб-сервер, сервер базы данных, сервер приложения), какие программные компоненты («артефакты») работают на каждом узле (например, веб-приложение, база данных), и как различные части этого комплекса соединяются друг с другом. Диаграммы развертывания используются для моделирования статического вида системы с точки зрения развертывания.
Диаграммы развертывания, или применения, — это один из двух видов диаграмм, используемых при моделировании физических аспектов объектно-ориентированной системы. Такая диаграмма показывает конфигурацию узлов, где производится обработка информации, и то, какие компоненты размещены на каждом узле.
Диаграммы развертывания используются для моделирования статического вида системы с точки зрения развертывания. В основном под этим понимается моделирование топологии аппаратных средств, на которых выполняется система. По существу, диаграммы развертывания — это просто диаграммы классов, сосредоточенные на системных узлах.
Это представление в первую очередь обращено на распределение, поставку и установку частей, из которых состоит физическая система. Диаграмма развертывания изображена на рис. 3.11.
