ФОРМИРОВАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ ДЛЯ СИСТЕМЫ УПРАВЛЕНИЯ ВЗАИМООТНОШЕНИЯМИ С КЛИЕНТАМИ

CREATING A USE CASE DIAGRAM FOR A CUSTOMER RELATIONSHIP MANAGEMENT SYSTEM

Anna Novozhilova

master's degree student, Practical and Applied Computer Science Department, MIREA – Russian Technological University,

Russia, Moscow

Yuliya Kirillina

Scientific director, Ph.D. in Economics, assistant professor Practical and Applied Computer Science Department, MIREA – Russian Technological University,

Russia, Moscow

АННОТАЦИЯ

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

ABSTRACT

This article discusses the issue of defining the functions of an information system for managing customer relationships based on the use of the unified modeling language UML. The result of the work is the use case diagrams and the specifications for each diagram.

Ключевые слова: управление взаимоотношениями с клиентами; CRM-система; проектирование информационной системы; диаграмма прецедентов.

Keywords: customer relationship management; CRM-system; information system design; use case diagram.

Конкуренция между компаниями практически на любом рынке в настоящее время характеризуется как сильнейшая. Пандемия, приведшая к снижению темпов роста мировой экономики и снижению доходов населения практически в каждой стране мира, обострила эту конкуренцию. На этом фоне отмечается тенденция усложнения ИТ-инфраструктур организаций, так как руководство компаний в 2020 году начало «оперативно переходить на «цифровые рельсы» развития бизнеса». [1] Частью ИТ-инфраструктуры является программное обеспечение, предназначенное для решения бизнес-задач. Среди таких бизнес-задач выделяют управление взаимоотношениями с клиентами.

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

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

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

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

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

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

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

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

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

На Рисунке 2 представлена детализация прецедента «Управление лидами». Лиды или предварительные контакты — это потенциальные клиенты, которые отреагировали на маркетинговую коммуникацию, таким образом заинтересовавшись в покупке товара или получении услуги.

Рисунок 2. Детализация прецедента «Управление лидами»

Поток событий для прецедента «Управление лидами» представлен ниже.

1.1    Предусловия (отсутствуют).

1.2    Главный поток.

Система отображает окно, содержащее список всех лидов и поле для ввода номера лида. Менеджеру становятся доступны следующие варианты действий:

1. Регистрация нового лида.
2. Просмотр информации о лиде.
3. Редактирование лида.
4. Фильтрация лидов.

Если выбрана операция 1: выполняется подпоток А.

Если выбрана операция 2: выполняется подпоток Б.

Если выбрана операция 3: выполняется подпоток В.

Если выбрана операция 4: выполняется подпоток Г.

1.3    Подпотоки.

Подпоток А. Регистрация нового лида.

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

Подпоток Б. Просмотр информации о лиде.

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

Подпоток В. Редактирование лида.

Менеджер выбирает лид из списка или вводит его номер в поле (П-1). Система открывает карточку лида со всей информацией, известной о данном потенциальном клиенте. Менеджер имеет возможность:

1. Внести изменения или заполнить недостающие данные.
2. Совершить или запланировать коммуникацию (П-2):
   
   1. отправить e-mail.
   2. назначить встречу.
   3. совершить звонок.
3. Создать сделку.

Система фиксирует введенные данные, для случая В-3 выполняется постусловие. Затем прецедент начинается сначала.

Подпоток Г. Фильтрация лидов.

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

1.4    Альтернативные потоки.

П-1: введен неправильный номер лида. Менеджер должен повторить ввод или завершить прецедент.

П-2: выбранная коммуникация недоступна (нет данных о e-mail/номере телефона). Менеджер должен выбрать другую коммуникацию.

1.5    Постусловия.

После завершения прецедента по подпотоку В-1 исполняется подпоток Создать новую сделку прецедента Управление сделками, при этом лид становится контрагентом.

Ниже на Рисунке 3 представлена детализация прецедента «Управление контрагентами».

Рисунок 3. Детализация прецедента «Управление контрагентами»

Поток событий для прецедента «Управление контрагентами».

2.1    Предусловия (отсутствуют).

2.2    Главный поток.

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

1. Добавление (нового) контрагента.
2. Просмотр данных контрагент.
3. Редактирование контрагент.
4. Фильтрация контрагентов.

Если выбрана операция 1: выполняется подпоток А.

Если выбрана операция 2: выполняется подпоток Б.

Если выбрана операция 3: выполняется подпоток В.

Если выбрана операция 4: выполняется подпоток Г.

2.3    Подпотоки.

Подпоток А. Добавление (нового) контрагента.

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

Подпоток Б. Просмотр данных контрагента.

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

Подпоток В. Редактирование контрагента.

Менеджер выбирает контрагента из списка или вводит его в поле (П-1). Система открывает карточку контрагента со всей информацией, известной о данном контрагенте. Менеджер имеет возможность:

1. Внесения изменений или заполнения недостающих данных (П-2).
2. Управление сделками.

При выборе подпотока В-2 менеджер переходит в инцидент Управление сделками, описываемый ниже (Рисунок 4).

Система запоминает введенные данные. Затем прецедент начинается сначала.

Подпоток Г. Фильтрация контрагентов.

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

2.4    Альтернативные потоки.

П-1: введено неправильное имя. Менеджер должен повторить ввод или завершить прецедент.

П-2: заполнены не все обязательные поля. Менеджер должен заполнить незаполненные поля или завершить прецедент.

На Рисунке 4 представлена детализация прецедента «Управление сделками».

Рисунок 4. Детализация прецедента «Управление сделками»

Поток событий для прецедента «Управление сделками».

3.1    Предусловия.

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

3.2    Главный поток.

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

1. Создание новой сделки.
2. Просмотр данных сделки.
3. Редактирование данных сделки.
4. Фильтрация реестра сделок.

Если выбрана операция 1: выполняется подпоток А.

Если выбрана операция 2: выполняется подпоток Б.

Если выбрана операция 3: выполняется подпоток В.

Если выбрана операция 4: выполняется подпоток Г.

3.3    Подпотоки.

Подпоток А. Создание новой сделки.

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

Подпоток Б. Просмотр данных сделки.

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

Подпоток В. Редактирование данных сделки.

Менеджер выбирает сделку из списка или вводит номер заказа в поле (П-2). Система открывает карточку сделки со всей возможной информацией, касающейся данной сделки. Менеджер имеет возможность:

1. Внести изменения в выбранные поля.
2. Перевести сделку на следующий этап воронки продаж (П-3).
3. Назначить задачу по сделке.
4. Выставить счет на оплату (П-4).

Система запоминает введенные данные. Затем прецедент начинается сначала.

Подпоток Г. Фильтрация сделок.

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

3.4    Альтернативные потоки.

П-1: введен неправильный номер клиента. Менеджер должен повторить ввод или завершить прецедент.

П-2: введен неправильный номер заказа. Менеджер должен повторить ввод или завершить прецедент.

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

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

На Рисунке 5 представлена детализация прецедента «Формирование отчетности».

Рисунок 5. Детализация прецедента «Формирование отчетности»

Поток событий для прецедента «Формирование отчетности».

4.1    Предусловия (отсутствуют).

4.2    Главный поток.

Система отображает окно, содержащее все отчеты, сформированные ранее в системе, и поле для ввода названия конкретного отчета. Менеджеру становятся доступны следующие варианты действий:

1. Создание отчетов. Система открывает карточку формирования отчета со списком шаблонов возможных отчетов. Менеджер выбирает шаблон отчета и заполняет поля по требованию. Система формирует отчет по введенным условиям, затем прецедент начинается сначала.
2. Просмотр деталей отчета. Менеджер выбирает отчет из списка или вводит его в поле (П-1). Система открывает выбранный отчет. Когда менеджер просмотрит информацию, прецедент начнется сначала.
3. Фильтрация отчетов. Система открывает окно, в котором предоставляется список возможных полей для фильтрации отчетов. Менеджер может выбрать от одного до нескольких полей, после чего система отображает только те отчеты, которые удовлетворяют выбранным условиям. Затем прецедент начинается сначала.

4.3    Подпотоки (отсутствуют).

4.4    Альтернативные потоки.

П-1: введен неправильно номер или название отчета. Менеджер должен повторить ввод или завершить прецедент.

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

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

Список литературы:

1. Влияние коронавируса COVID-19 на экономику стран мира — TADVISER. Государство. Бизнес. ИТ Режим доступа. — URL: https://www.tadviser.ru/index.php/ (Дата обращения: 08.05.21)
2. Рочев К.В. Информационные технологии. Анализ и проектирование информационных систем: учебное пособие / К. В. Рочев. — 2-е изд., испр. — Санкт-Петербур: Лань, 2019. — 128 с. (Дата обращения: 29.04.2021)
3. Системы автоматизированного проектирования программного обеспечения: лабораторные работы [электронный ресурс]. — Режим доступа. — URL: http://khpi-iip.mipk.kharkiv.edu/library/case/index.html  (Дата обращения: 27.04.21)