42
− входящую интерфейсную дугу: выполненный заказ;
− управляющая интерфейсная дуга: внутренние нормативные акты;
− интерфейсные дуги механизма: менеджер, клиент, CRM;
− выходящую интерфейсную дугу: оповещение клиента.
Рисунок 1.17 – Диаграмма А5 «Завершить заказ»
Функциональный блок А52 «Согласовать условия доставки и монтажа»
имеет:
− входящую интерфейсную дугу: оповещенный клиент;
− управляющая интерфейсная дуга: внутренние нормативные акты;
− интерфейсная дуга механизма: менеджер, клиент;
− выходящую интерфейсную дугу: условия доставки и монтажа.
Функциональный блок А53 «Доставить заказ и произвести монтаж» имеет:
− входящую интерфейсную дугу: условия доставки и монтажа, выпол-
ненный заказ, дизайн-проект;
− управляющая интерфейсная дуга: внутренние нормативные акты;
− интерфейсные дуги механизма: мастер, клиент;
43
− выходящую интерфейсную дугу: принятый заказ, непринятый заказ.
Функциональный блок А54 «Принять оплату заказа» имеет:
− входящие интерфейсные дуги: принятый заказ;
− управляющая интерфейсная дуга: внутренние нормативные акты;
− интерфейсные дуги механизма: мастер, клиент;
− выходящая интерфейсная дуга: чек.
Функциональный блок А55 «Подписать акт приема-передачи» имеет:
− входящая интерфейсная дуга: чек;
− управляющие интерфейсные дуги: внутренние нормативные акты, ГК
РФ;
− интерфейсные дуги механизма: мастер, клиент;
− выходящие интерфейсные дуги: завершенный заказ, акт приема-
передачи.
Декомпозиция блока А43 «Проинформировать клиента о состоянии зака-
за» (рисунок 1.18) состоит из четырех функциональных блоков:
− получение вопроса от клиента (А431);
− посмотреть в CRM (А432);
− ответить клиенту (А433).
Функциональный блок А431 «Получение вопроса от клиента» имеет:
− входящую интерфейсную дугу: вопрос клиента;
− управляющая интерфейсная дуга: внутренние нормативные акты;
− интерфейсные дуги механизма: клиент, менеджер, CRM;
− выходящую интерфейсную дугу: полученный вопрос от клиента.
Функциональный блок А432 «Посмотреть в CRM» имеет:
− входящую интерфейсную дугу: полученный вопрос от клиента;
− управляющая интерфейсная дуга: внутренние нормативные акты;
− интерфейсные дуги механизма: мастер, менеджер, клиент, CRM;
− выходящую интерфейсную дугу: информация из CRM.
Функциональный блок А433 «Ответить клиенту» имеет:
44
− входящую интерфейсную дугу: информация из CRM;
− управляющая интерфейсная дуга: внутренние нормативные акты;
− интерфейсные дуги механизма: клиент, менеджер, CRM;
− выходящую интерфейсную дугу: ответ клиенту [8, 11].
Рисунок 1.18 – Диаграмма А43 «Проинформировать клиента о состоянии
заказа»
45
2 Проектная часть
2.1 Описание постановки задачи для проектирования ИС
2.1.1 Организационно-экономическая сущность задач
Организационно-экономическая сущность задачи дает возможность
определить границы и масштаб будущего проекта ИС. В данной выпускной
квалификационной работе рассматривается задача управления взаимоотноше-
ниями с клиентами.
Описании организационно-экономической сущности задачи:
− наименование задачи: управление взаимоотношениями с клиентами;
− место ее решения: Студия мебели «Атриум»;
− цель решения: обслуживание клиентов для получения заказа, его ис-
полнения и передачи клиенту; получение прибыли;
− назначение: Студия мебели «Атриум»;
− периодичность и сроки решения задачи: выполняется 1 или несколько
раз в день, сроки – от 1 до 90 дней;
− источники и способы поступления данных: клиенты (устно, в элек-
тронном виде);
− потребители результатной информации и способы ее отправки: дирек-
тор (информационная система), бухгалтер (информационная система, устно),
клиенты (устно, информационная система), мастер (устно, информационная си-
стема), дизайнер (устно, информационная система) [3].
2.1.2 Информационное обеспечение задачи
В данном разделе детально описывается состав, структура и содержание
информационных потоков, обеспечивающих решение задачи управления взаи-
моотношениями с клиентами.
46
2.1.2.1 Описание входной информации
К входной информации относят не только документы, но и сведения из
них, а также данные, поступившие в устной форме и введенные в систему.
Сведения о заявке вводится менеджером в систему один раз. Однократ-
ный ввод исходной информации поможет избежать ошибок и сократит время
затрачиваемое на поиск необходимых данных при ведении переговоров. Дан-
ные хранятся в электронном виде и доступны для вывода на экран.
Заказ оформляется менеджером в соответствии с требованиями клиента.
Заказ содержит информацию о предмете заказа, о примерных сроках его вы-
полнения, о всех лицах выполняющих его (менеджер, дизайнер, мастер).
Данные о заказываемом изделии предоставляет клиент дизайнеру, чтобы
тот разработал дизайн-проект, в соответствии с которым в последствии мастер
изготовит заказ.
2.1.2.2 Описание выходной информации
К выходной информации относят документы, сформированные в ходе
процесса ведения взаимоотношений с клиентами.
Договор составляют в двух экземплярах при оформлении заказа, он со-
держит данные о дате, сроках выполнения заказа, сумме оплаты, данные сторон
заключающих договор – клиент и менеджер от лица фирмы Студия мебели
«Атриум». Один экземпляр передается клиенту, а другой хранится у директора.
Авансовый чек передается клиенту, когда при заключении договора он
вносит аванс за заказ.
Дизайн-проект разрабатывается дизайнером в соответствии с пожелания-
ми и требованиями клиента. Дизайн-проект содержит параметры изделия и его
стоимость.
Акт приема-передачи оформляется бухгалтером, передается мастеру, ко-
торый подписывает его совместно с клиентом, когда заказ доставлен и установ-
лен в помещении заказчика.
47
Чек выдается клиенту, когда он вносит оставшуюся сумму за заказ. Чек
оформляется бухгалтером, который передает его мастеру, а тот в свою очередь
клиенту в момент принятия денежных средств.
2.2 Концептуальная информационная модель
Информационная модель реализована средствами CA ERwin Data
Modeler. Информационная модель построена в нотации IDEF1X.
Основными составляющими модели IDEF1X являются:
− сущность – объекты реального мира, обладающие некоторыми об-
щими характеристиками, о которых хранится информация;
− отношения – связи между этими объектами;
− атрибут – характеристики этих объектов [5, 12].
Информационная модель процесса управление взаимоотношениями с
клиентами (рисунок 2.1, приложение Б) состоит из 14 сущностей. Из этих сущ-
ностей девять показывают документы, а пять хранят информацию о сотрудни-
ках и клиенте. Основным атрибутом для идентификации сущности является
уникальный код (ID).
Сущностями информационной модели являются: сотрудник, менеджер,
заявка, заказ, задача, договор, клиент, дизайнер, дизайн-проект, мастер, звонок,
журнал звонков, сообщение, журнал сообщений.
Сущности Менеджер, Дизайнер и Мастер являются категориями сущно-
сти Сотрудник, основанием категоризации является должность.
Сущность Заявка использует информацию из сущности Менеджер, ID со-
трудника является внешним ключом. Такое отношение таблиц позволяет отно-
сить к одном менеджеру множество заявок. Отношение сущностей Заявка –
Менеджер является неидентифицирующим. Также сущность Заявка имеет не-
идентифицирующие отношение с сущностью Заказ, внешним ключом является
ID заявки.
48
Сущность Менеджер имеет неидентифицирующие отношение с сущно-
стью Заказ, что позволяет хранить информацию о всех заказ оформленных ме-
неджером. Сущность Менеджер также имеет неидентифицирующее отношение
с сущностью Договор, внешним ключом здесь будет ID сотрудника.
Рисунок 2.1 – Информационная модель процесса управления взаимоот-
ношениями с клиентами
Сущность Клиент связана с сущностями Заявка, Заказ, Дизайн-проект и
Договор неидентифицирующими отношениями для хранения данных по заказу
покупателя, внешним ключом является ID клиента.
Сущность Мастер связана неидентифицирующим отношением с сущно-
стью Заказ, внешний ключ ID сотрудника.
Аналогично сущность Дизайнер связана неидентифицирующим отноше-
нием с сущностью Дизайн-проект, внешний ключ ID сотрудника.
49
Сущность Задача связана идентифицирующей связью с сущностью Заказ,
внешний ключ ID заказа. Данная сущность показывает, что одному заказу соот-
ветствует несколько задач.
Сущность Сообщение связана неидентифицирующим отношением с сущ-
ностью Журнал сообщений, внешний ключ ID сообщения. Журнал хранит ис-
торию сообщений как между сотрудником компании и клиентом, так и между
самими сотрудниками.
Сущность Звонок связана неидентифицирующим отношением с сущно-
стью Журнал звонков, внешний ключ ID сообщения. Журнал хранит историю
звонков как между сотрудником компании и клиентом, так и между самими со-
трудниками.
Сущность Заказ объединяет многие данные из системы и служат для хра-
нения состоянии и параметрах заказа [5, 12, 3].
Для каждого атрибута каждой сущности были определены ограничения
(таблица 2.1).
Таблица 2.1
Ограничения атрибутов сущностей
Имя атрибута
Тип
Количество символов
Сущность «Сотрудник»
ID сотрудника
целочисленный
3
ФИО сотрудника
знаковый
<= 100
Контактные данные сотрудника
знаковый
<= 100
Сущность «Менеджер»
ID сотрудника
целочисленный
3
Сущность «Мастер»
ID сотрудника
целочисленный
3
Сущность «Дизайнер»
ID сотрудника
целочисленный
3
Сущность «Заявка»
ID заявки
целочисленный
3
Дата заполнения заявки
дата
10
50
Продолжение таблицы 2.1
Имя атрибута
Тип
Количество символов
ID сотрудника
целочисленный
3
ID клиента
целочисленный
3
Сущность «Заказ»
ID заказа
целочисленный
3
Название заказа
текстовый
<= 100
Дата совершения заказа
дата
10
Статус заказа
текстовый
<= 100
Дата исполнения
дата
10
Макет
знаковый
<= 200
ID заявки
целочисленный
3
ID сотрудника
целочисленный
3
ID клиента
целочисленный
3
ID дизайн-проекта
целочисленный
3
Адрес доставки
знаковый
<= 100
Дата/время доставки
знаковый
<= 20
Сущность «Клиент»
ID клиента
целочисленный
3
ФИО клиента
знаковый
<= 100
Телефон
знаковый
<= 30
Электронная почта
знаковый
<= 30
Адрес клиента
знаковый
<= 100
Сущность «Договор»
ID договора
целочисленный
3
Дата заключения
дата
10
Сроки выполнения
дата
10
Сумма
числовой
<= 9
ID заказа
целочисленный
3
ID сотрудника
целочисленный
3
ID клиента
целочисленный
3
Сущность «Задача»
ID задачи
целочисленный
4
ID заказа
целочисленный
3
Название
знаковый
<= 50
ID сотрудника
целочисленный
3
Дата/время выполнения
знаковый
<= 20
Содержание задачи
знаковый
<= 200
Файл
знаковый
<= 200
51
Продолжение таблицы 2.1
Имя атрибута
Тип
Количество символов
Сущность «Дизайн-проект»
ID дизайн-проекта
целочисленный
3
Название дизайн-проекта
знаковый
<= 100
Содержание
знаковый
<= 200
Стоимость
числовой
<= 9
ID дизайнера
целочисленный
3
ID клиента
целочисленный
3
Сущность «Звонок»
ID звонка
целочисленный
5
Вызывающий абонент
знаковый
<= 50
Вызываемый абонент
знаковый
<= 50
Дата/время звонка
знаковый
<= 20
Запись звонка
знаковый
<= 200
Сущность «Журнал звонков»
ID журнала звонков
целочисленный
3
ID звонка
целочисленный
5
Сущность «Сообщение»
ID сообщения
целочисленный
10
Адресант
знаковый
<= 50
Адресат
знаковый
<= 50
Дата/время звонка
знаковый
<= 20
Содержание
знаковый
<= 200
Сущность «Журнал звонков»
ID журнала сообщений
целочисленный
10
ID сообщения
целочисленный
6
2.4 Описание комплекса технических средств
Техническое обеспечение персональных компьютеров выбирается на ос-
нове минимальных требований для корректной работы автоматизированной си-
стемы. Требования представлены ниже.
Рабочее место менеджера, дизайнера:
− операционная система: Windows 7;