Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Управление взаимоотношениями с клиентами» с помощью UML

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Глава 1. Анализ технологии решения задачи

1.1 Описание предметной области. Постановка задачи

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

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

-        Обработка входящего заказа с сайта

-        Обработка заявки «обратного звонка» с сайта

-        Прием входящих звонков от клиентов

-        Информирование клиентов обо всем, что связано с покупкой в интернет - магазине

-        Предложение дополняющих товаров в рамках телефонного разговора

-        Сбор информации о клиенте

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

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

Важнейшим пунктом для построения качественного обслуживания клиента является наличие CRM системы, в которой будет вестись учет всех соприкосновений как с клиентами, так и с потенциальными клиентами, а также вестись сбор, обработка информации как о всех клиентах, так и об эффективности деятельности отдела продаж [1]

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

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

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

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

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

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

1.1.1 Задачи проекта

  • Построить диаграмму вариантов использования (диаграмма прецедентов);
  • Построить диаграмму последовательности по решаемой задаче;
  • Построить диаграмму состояний по решаемой задаче;
  • Построить диаграмму деятельности по решаемой задаче;
  • Построить диаграмму классов по решаемой задаче.

1.1.2 Сотрудники и их функционал

Рассмотрим понятие взаимоотношений с клиентами.

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

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

КОНТЕНТ-МЕНЕДЖЕР

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

БУХГАЛТЕР

  • Работа с документами и отчетами.
  • Прием оплаты

Оператор

  • Отслеживание заказов и их подтверждение.
  • Консультации по телефону.
  • Отслеживание пути заказа, пока он не поступит клиенту.
  • Работа с базой клиентов

КЛАДОВЩИК

  • Упаковка товара.
  • Прием товара
  • Инвентаризация
  • Передача курьеру

КУРЬЕРЫ

  • Развоз заказов по адресу
  • Прием оплаты (наличные)

УПРАВЛЯЮЩИЙ

  • Ведение отчетности.
  • Анализ данных
  • Обучение персонала.

1.1.3 Отчеты

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

  • Работа с претензиями покупателей;
  • Отчет по новым клиентам;
  • Классификация покупателей;
  • Продажи по картам лояльности клиентов ;
  • Отчет по событиям, как мы общались с клиентом и сделал ли он заказ (Телефонный звонок, Личная встреча, Электронное письмо).Статистика;
  • Отчет по проделанной работе.

1.2 Предлагаемые мероприятия по улучшению бизнес-процессов


В этом магазине всего два оператора, еще не отлажена система обработки заказов и операторы не обучены, по этой причине обработка заказа занимает около 7-10 минут Вследствие чего клиенты , которые хотят сделать заказ или у них возникает вопросы ждут на линии в среднем 5 минут . Наша цель сократить время обработки заказа оператором до 2 минут и тем самым уменьшить время ожидания на линии, а также увеличить лояльность клиентов. Достигать этих показателей мы будем с помощью создания базы клиентов, создания скриптов для операторов. Также для повышения лояльности клиентов ,увеличения оборота и чтобы сократить обязанности операторов мы введем две должности кладовщик и курьер.

Что еще мы получим от внедрения CRM , помимо указанных выше плюсов:

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

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

Глава 2. Проектирование предметной области

2.1 Выбор средства для моделирования предметной области решаемой задачи

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

UML – это Unified Modeling Language, как следует из названия – унифицированный язык моделирования. UML представляет собой набор соглашений, которые предназначены для облегчения процесса моделирования и обмена информацией в проектной группе. Наличие стандартизированной нотации позволяет сократить время на усвоение информации, упрощает общение и взаимодействие, облегчает документирование.

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

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

  • Use case diagram (диаграммы вариантов использования);
  • Statechart diagram (диаграммы состояний);
  • Activity diagram (диаграммы активности);
  • Interaction diagram (диаграммы взаимодействия);
  • Sequence diagram (диаграммы последовательности);
  • Collaboration diagram (диаграмма сотрудничества / кооперативная диаграмма)

Структурные диаграммы отображают элементы, из которых состоит система.

  • Implementation Diagram (диаграммы реализации):
  • Deployment diagram (диаграммы топологии);
  • Component diagram (диаграммы компонент).
  • Class diagram (диаграммы классов);

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

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

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

2.1.1 Сравнительный анализ средств моделирования

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

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

В ходе анализа деятельности компании строится модель «как-есть» (AS-IS). Она показывает все недостатки функционирования исследуемого объекта. На основе модели «как-есть» строится модель «как должно быть» (TO-BE), которая с учетом недостатков модели «как-есть» будет по-новому организовывать деятельность исследуемого объекта. После внедрения в работу модели «как должно быть» будут решены поставленные в ходе планирования проекта задачи. К ним может относится:

· внедрение программного обеспечения;

· сокращение времени выполнения бизнес-процессов;

· сокращение производственных затрат;

· повышение качества поставляемых на рынок продуктов/услуг;

· повышение качества обслуживания клиентов и т.д.

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

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

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

2.1.1.1 Microsoft Visio

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

  • Изобразительные же возможности Visio действительно весьма широки:
  • Используя предопределенные фигуры Visio Professional , drag-and-drop и мастера, вы можете быстро и просто создавать понятные и информативные диаграммы.
  • Возможности Visio можно легко расширять, используя новые шаблоны бизнес-диаграмм. Вы можете включать внешние источники данных, хранилища или коллекции хранимых шаблонов.
  • В Visio можно прототипировать интерфейс приложений с помощью встроенных шаблонов пользовательского интерфейса Microsoft Windows XP, что позволяет создавать модель пользовательского интерфейса в стандартном Windows XP-стиле.
  • Можно легко рисовать диаграммы сетевых ресурсов, иллюстрирующие развертывание нового ПО на существующие сетевые ресурсы.
  • Visio Professional также тесно интегрируется с Microsoft Office Project, что позволяет, например, импортировать оттуда задачи для членов команды.
  • С помощью шаблонов UML вы можете создавать UML-диаграммы статической структуры ПО или проводить обратное проектирование с помощью Visio 2003 Reverse Engineer Wizard.
  • Visio 2003 может документировать для вас структуру существующих веб-сайтов, помогая таким образом в разработке, реализации или интеграции веб-приложений.
  • Можно также создавать отчеты, сохранять диаграммы как вебстраницы и еще многое-многое другое...

Отметим, что Visio - это не полноценное средство моделирования, а программа для создания иллюстраций, умеющая, кроме прочего, рисовать UML-диаграммы[6]

2.1.1.2 BPWin

BPwin это программный продукт, разработанный компанией ltd. Logic Works. Он предназначен для поддержки процесса создания информационных систем. Относится к категории CASE средств верхнего уровня. Первая версия BPwin была выпущена в 1995 г. совместно с другим CASE средством - ERwin, предназначенным для моделирования данных. В дальнейшем, развитием и поддержанием BPwin занималась компания Platinum Technology, а последние версии разрабатывала компания CA Technologies.

BPwin является достаточно развитым средством моделирования, позволяющим проводить анализ, документирование и улучшение бизнес процессов. С его помощью можно моделировать действия в процессах, определять их порядок и необходимые ресурсы. Модели BPwin создают структуру, необходимую для понимания бизнес процессов, выявления управляющих событий и порядка взаимодействия элементов процесса между собой. BPwin поддерживает функциональное моделирование, моделирование потока работ и потока данных. Соответствующие диаграммы реализованы на основе стандартов IDEF0, IDEF3 и DFD. Функциональное моделирование дает возможность осуществлять систематизированный анализ бизнес процессов, обращая внимание на регулярно выполняемые задачи (функции). Моделирование потока работ обеспечивает анализ логики выполнения процесса. Моделирование потока данных позволяет сконцентрировать внимание на обмене данными между различными задачами. Кроме того, что в BPwin создаются отдельные модели, также могут создаваться и смешанные модели.

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

Разработка моделей требует четкого понимания всех аспектов бизнес процессов. CASE средство должно позволять моделировать действия процесса, порядок их исполнения и контроля, состав ресурсов и информации, состав входов и выходов процессов, а также давать возможность документировать полученные результаты. BPwin 7, в той или иной степени, выполняет все эти задачи. [7]

2.1.1.3 CaseBerry

CASEBERRY — CASE-инструмент, реализующий стандартную нотацию UML. CASEBERRY может быть использован как для бизнес-моделирования (анализ бизнес-процессов, реинжиниринг бизнес-процессов), так и для объектно-ориентированного проектирования программного обеспечения и баз данных. 
Традиционно, преимуществами проектирования в UML называют:

  • собственно моделирование, дающее ясное понимание предметной области и возможностей по улучшению бизнеса, а также соответствующих этому требований к программному обеспечению;
  • формальное документирование бизнес-процессов на стандартном языке;
  • моделирование позволяет избежать наиболее дорогих ошибок на поздних стадиях, когда разработанное приложение уже эксплуатируется
  • наглядность — служит универсальным «мостиком» между предметными специалистами и разработчиками;
  • сокращение цикла разработки приложений;
  • увеличение продуктивности работы программистов за счёт чёткой спецификации, значительное упрощение и автоматизация процесса проектирования;
  • улучшение потребительских качеств создаваемых программ за счет ориентации на пользователей и бизнес;
  • возможность повторного использования уже созданного ПО за счет упора на разбор их архитектуры и компонентов;
  • возможность определить модели предельно формально, что упрощает создание исходного кода, в идеале — до автоматической генерации кода по модели.
  • Поддерживает все диаграммные методы нотации UML; Может использоваться как индивидуально (однопользовательский репозитарий), так и группой пользователей (как централизованный многопользовательский репозитарий моделей), что позволяет вести различные по масштабу проекты и группы проектов, а также использовать для обучения UML;
  • Репозитарий моделей имеет чёткую структуру, не ограничивающую, вместе с тем, проектировщика какой-либо одной, предопределённой, методикой. Например, пользователь может создать любое количество систем, конфигураций, стадий, поддерживать жизненный цикл проекта, как ему удобно. 
  • Репозитарий может быть расширен с целью добавления другой функциональности, а также для генерации исходного кода при помощи механизма надстроек (Plugins).

CASEBERRY — инструмент отечественного производства, альтернатива многим зарубежным средствам, обладающим аналогичной функциональностью. CASEBERRY делает доступным качественное моделирование широкому кругу разработчиков.[8]

2.1.1.4 IBM Rational Rose

CASE-средство IBM Rational Rose со времени своего появления претерпело серьезную эволюцию, и в настоящее время представляет собой современный интегрированный инструментарий для проектирования архитектуры, анализа, моделирования и разработки программных систем. Именно в IBM Rational Rose язык UML стал базовой технологией визуализации и разработки программных систем, что определило популярность и стратегическую перспективность этого инструментария.

В рамках общего продукта IBM Rational Rose существуют различные варианты этого средства, отличающиеся между собой диапазоном предоставляемых возможностей. Базовым средством в настоящее время является IBM Rational Rose Enterprise Edition, которое обладает наиболее полными возможностями.

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

Rational Rose объединяет команду разработчиков на базе универсального языка моделирования UML, который определяет стандартную графическую символику для описания архитектуры ПО. Любые участники проекта - аналитики, специалисты по моделированию, разработчики и другие - могут использовать модели, построенные в Rational Rose, для большей эффективности создания конечного продукта.[9]

2.1.1.5 StarUML

StarUML - программная платформа моделирования, которая поддерживает UML (Унифицированный Язык Моделирования . Поддерживает

нотацию UML версии 2 и одиннадцать различных типов диаграмм. Она активно поддерживает подход MDA (Архитектура Управляемая Моделью) и концепцию профилей UML. StarUML превосходен в отношении настройки окружения пользователя и имеет высокую степень расширяемости в том, что касается его функциональных возможностей.

StarUML предоставляет максимальные возможности адаптации к требованиям пользователя, предлагая настройку параметров, которые определяют методологию создания программного обеспечения, проектную платформу и язык разработки. StarUML обладает превосходной расширяемостью и гибкостью. Он поддерживает использование аддинов1, позволяющих расширять его функциональные возможности. При их разработке предоставляется доступ ко всем функциям модели/метамодели и другому инструментарию через COM, включая расширение меню и набора опций конфигурации. Также,

пользователи могут создавать свои собственные подходы2 и фреймворки3, соответствующие специальным методологиям. StarUML™ может также быть интегрирован с любыми внешними инструментальными средствами.[10]

Исходя из анализа существующих средств моделирования, выбор сделан в пользу IBM Rational Rose, CaseBerry, Microsoft Visio. Основными факторами, повлиявшими на выбор, являются наличие бесплатной версии, простота использования, возможность описывать модели в нотации языка UML. Связь Caseberry с СУБД MS SQL Server удобна, но требует больших усилий, чтобы корректно настроить СУБД для работы с CASE-средством. Окончательный выбор был сделан в пользу Visio так как нравится творческий подход к созданию диаграмм.

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Построим объектно-ориентированную модель на основе бизнес-модели организации. Для этого воспользуемся программным средством MS Visio и опишем разрабатываемую систему посредством языка UML.

2.2.1 Диаграмма вариантов использования

Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью, так называемых прецедентов. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. [11]

Описание элементов диаграммы:

  • Контент-менеджер – разрабатывает акции для привлечения клиентов, наполняет сайт информацией для клиента;
  • Покупатель – Смотрит каталог товаров на сайте ,выбирает нужный, оформляет заказ, оплачивает заказ ;
  • Оператор – Оформляет карточку покупателя для ( возраст, ФИО, адрес) отмечает важные сведения о покупателе( не любит красный цвет, плохой опыт использования румян и т.д.), предлагает дополнительные товары, помогает в дальнейшем оформлении заказа, отправляет информацию кладовщику ;
  • Кладовщик – Ведет учет товаров, собирает поступившие заказы , выдает заказ курьеру;
  • Курьер – Получает заказ от кладовщика и доставляет его клиенту, если оплата наличными, то получает оплату и передает ее в бухгалтерию;
  • Бухгалтерия – Получает оплату по безналичной оплате от клиента или за наличный расчет через курьера.
  • Управляющий – Получает отзыв от клиента.

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

Рисунок 1. Диаграмма вариантов использования.

2.2.2 Диаграмма последовательности

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

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

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

  • Управляющий изучил слабые места операторов;
  • Управляющий провел тренинг с операторами и выдал скрипты;
  • Клиент оформил заказ на сайте;
  • Оператор получил информацию о поступившем заказе;
  • Оператор запросил в базе клиентов информацию о клиенте;
  • База выдала данные о клиенте;
  • Оператор связался с клиентом;
  • Оператор уточнил дополнительную информацию у клиента;
  • Оператор внес изменения в базу клиентов;
  • Оператор сделал индивидуальное предложение клиенту;
  • Оператор предложил клиенту дополнительные товары;
  • Клиент выбрал дополнительные товары;
  • Оператор уточнил дату доставки у клиента;
  • Клиент оплачивает заказ картой ;
  • Бухгалтерия принимает оплату;
  • Оператор передает информацию о заказе кладовщику;
  • Кладовщик собирает заказ;
  • Кладовщик оправляет информацию о готовности заказа в базу клиентов;
  • Кладовщик передает заказ курьеру;
  • Курьер доставляет заказ;
  • Клиент оплачивает заказ наличными;
  • Клиент оставляет отзыв управляющему;
  • Курьер передает наличные в бухгалтерию;
  • Курьер передает документы по заказу кладовщику;
  • Управляющий дает обратную связь по отзыву клиента оператору;

На рисунке 2 представлена диаграмма последовательности.

Рисунок 2. Диаграмма последовательности по решаемой задаче.

2.2.3 Диаграмма состояний

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

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

    • Поступает звонок от клиента;
    • Клиента соединяют со свободным оператором;
    • Если клиент постоянный его ищут в CRM и если есть делают индивидуальное предложение;
    • Если клиент новый, то вносят данные о клиенте в базу CRM;
    • Любому из клиентов предлагается дополнительная продукция;
    • Если клиент согласен на товары, то оператор подбирает дополнительные товары;
    • Если клиент отказался от дополнительных товаров, то сразу переходим к оплате;
    • Клиент выбирает вариант оплаты (карта или наличные);
    • Если товар есть в наличии, то совершается сборка товара;
    • Затем совершается доставка товара;
    • Если товара нет, то соединяем клиента с оператором;
    • Клиент может отказаться от товара;
    • Клиент может принять решение на изменение или добавление других товаров в заказ;

На рисунке 3 представлена диаграмма состояний

Рисунок 3. Диаграмма состояний.

2.2.4 Диаграмма деятельности

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

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

Описание диаграммы деятельности:

  • Блок покупатель

Звонок в магазин

  • Блок оператор

Соединение с оператором - Звонок клиента принят

Отмена или изменение заказа

Новый клиент – внесение информации в CRM

Постоянный клиент –поиск клиента в CRM – индивидуальное предложение

Предложение дополнительных товаров любому из клиентов - скрипт отработан

Согласие не доп. Товар – подбор товара - заказ оформлен

Отказ от доп. Товара - заказ оформлен

  • Блок бухгалтерия

Прием оплаты картой от клиента

Прием оплаты наличными через курьера

  • Блок склад

Сборка заказа при его наличии

Доставка заказа

На рисунке 4 представлена деятельности

Рисунок 4. Диаграмма деятельности.

2.2.5 Диаграмма классов

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

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

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

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

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

Класс (class) - категория вещей, которые имеют общие атрибуты и операции.

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

При проектировании объектно-ориентированных систем диаграммы классов обязательны.

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

Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++).

Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки. [15]

Описание диаграммы классов:

  • Данная диаграмма показывает взаимосвязи между сущностями участвующими в оформлении заказа интернет - магазина.
  • Работники – включает в себя работников магазина участвующих в оформлении заказа клиента интернет - магазина:
  • Управляющий, контент-менеджер, оператор, бухгалтер, работники склада, курьер. Главным атрибутом класса является должность.
  • Контент-менеджер – Работа с сайтом. Главным атрибутом класса является ФИО
  • Управляющий – Обладает правами увольнять и нанимать сотрудников. Полный цикл управления. Главным атрибутом класса является ФИО
  • Оператор – принимает заказ и отправляет информацию в систему для остальных сотрудников. Главным атрибутом класса является
  • Бухгалтер – принимает платежи клиентов и информирует администратора о результате. Главным атрибутом класса является
  • Работники склада – проверяют наличие товара и передают заказ в службу доставки. Главным атрибутом класса является Кладовщик
  • Курьер – принимает заказ от работников склада и доставляет заказ клиенту. Главным атрибутом класса является
  • Товар – перечень всего товара, представленного в интернет – магазине и его цена. Главным атрибутом класса является: наименование товара.
  • Заказ – в заказе указывается номер заказа, дата заказа, состояние заказа, стоимость заказа, статус выполнения и номер клиента. Главный атрибут: ID заказа.
  • Оплата – Чек и вид оплаты. Главным атрибутом класса является ID транзакции

На рисунке 5 представлена классов

Рисунок 5. Диаграмма классов.

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

  1. Технологии CRM. Экспресс-курс, Молино П., Переводчик: Татьяна Новикова,, 272 с.
  2. http://www.itproject.ru (дата обращения 05.08.19)
  3. Проектирование программного обеспечения экономических информационных систем: Вендров А.М. Учебник, 2006. — 544
  4. Разработка метода поведения сравнительного анализа языков бизнес-моделирования , Э.А. Бабкин, В.П. Князькин, М.С. Шиткова, 2010
  5. Объектно-ориентированные CASE-средства. https://studbooks.net (дата обращения 10.08.2019)
  6. Введение в UML. https://www.intuit.ru (дата обращения 10.08.19)
  7. CASE-средства .Учебно-методическое пособие. - 2007. - 88 с. Тебайкина Н.И.
  8. https://caseberry.net/ (дата обращения 10.08.2019)
  9. http://www.interface.ru (дата обращения 10.08.2019)
  10. Руководство пользователя © Перевод Д. В. Летуновского, 2007
  11. UML Основы. Мартин Фаулер. Перевод А. Петухова.2005 192 с.
  12. Язык UML. Руководство пользователя — Гради Буч, Джеймс Рамбо, Ивар Якобсон 2007
  13. Российский экономический университет имени Г. В. Плеханова Unified Modeling Language (UML) - унифицированный язык моделирования. к.т.н.,доцент Горбенко А.О.
  14. Моделирование на UML. Учебно-методическое пособие, Денис Иванов и Федор Новиков.
  15. Самоучитель UML. Леоненков Александр 418.c 2004