19
Рис. №3 Схема элементов CRM
Необходимо сделать CRM хранящую информацию о всех компаниях-
клиентах, их контактных лицах, которые участвуют в процессе работы, а также
всех проектах компании.
Данные внутри системы должны иметь возможность связи друг с другом,
чтобы можно было выстроить цепочку связей. Например, проект может иметь
связь как компанию, так и на контактное или множество контактных лиц.
Рис. №4 Схема связей в CRM
Как показано на рис. 4, все элементы системы должны быть связаны
между собой, явно или неявно, но при этом всегда должна быть возможность
прийти из одного элемент в другой. Например, контактное лицо имеет явную
связь с компанией, и видно к какой компании или компаниям принадлежит
конкретное контактное лицо. При этом у компании нет явной связи с проектом,
но в проекте есть явная связь с компанией, которой принадлежит проект. Таким
образом, должна быть возможность получения данных о проектах компании,
непосредственно от компании. Также, например, должна быть возможность
20
проследить полную цепочку связи: найти проект компании, и через него найти
ответственное контактное лицо за данный проект из этой компании.
Каждый элемент должен быть реализован как модуль для используемой
системы и быть максимально самодостаточным. Хоть все данные и должны быть
в итоге связаны между собой, модули должны быть написаны таким образом,
что система должна продолжать функционировать, если один из них будет
отсутствовать. Например, проект может иметь связь с компанией. Эта связь
выставляется непосредственно в проекте, и требует наличия модуля
отвечающего за компании. При этом нужно сделать так, чтобы если модуля
отвечающего за компанию по каким-то причинам нет, или он будет отключен,
проекты работали в штатном режиме. Для этого нужно, чтобы модуль,
отвечающий за компании, в случае обнаружения активного модуля отвечающего
за проект, добавлял возможность установки связи на компании. Таким образом,
если модуль компании будет отключен - эта связь пропадет, ровно как и в случае
если модуль отвечающий за проект будет отсутствовать или не активен, он не
будет пытаться добавлять возможность установки связи без необходимости.
Каждый из элементов должен содержать информацию о себе, с
максимальным разделением данных на смысловые куски, вместо одного
большого значения. Таким образом, каждое значение должно быть явно
объявлено и доступно для чтения и записи.
Данные необходимые для хранения о контактных лицах описаны в
таблице №1.
21
Таблица №1
Описание необходимых для хранения данных контактного лица.
Название
значения
Описание
Машинное
название
Является ли
значение
множественн
ым
Дата создания
Дата, когда был создано
контактное лицо.
created
нет
Дата изменения
Дата, когда были внесены
последние изменения.
changed
нет
Имя
Имя контактного лица
name
нет
Фамилия
Фамилия контактного
лица
second_name
нет
Отчество
Отчество контактного
лица
last_name
нет
Должность
Должность в компании
post
нет
Адрес
Комплексное значение,
содержащее в себе:
Улицу, Страну, Регион,
Город, Почтовый индекс
address
нет
День рождения
День рождения
контактного лица
birthday
нет
Комментарий
Комментарий к
контактному лицу,
содержащий
дополнительную
информацию, не
подходящую ни под одно
из значений
comments
нет
Email адрес
Электронные адреса
контактного лица
emails
да
Форма обращения
Форма обращения к
контактному лицу
honorific
нет
Телефон
Телефоны для связи с
контактным лицом
phones
да
Продолжение таблицы №1.
22
Веб-адреса
Различные ссылки на веб-
ресурсы связанные с
контактным лицом.
webs
да
Интернет-
мессенджеры
Различные никнеймы, и
другая информация для
связи при помощи
интернет-мессенджеров
ims
да
Данные необходимые для хранения о компании описаны в таблице №2.
Таблица №2
Описание необходимых для хранения данных компании.
Название
значения
Описание
Машинное
название
Является ли
значение
множественн
ым
Название
компании
Полное наименование
компании
title
нет
Дата создания
Дата создания компании в
системе.
created
нет
Дата изменения
Дата последнего
изменения компании в
системе.
changed
нет
Банковские
реквизиты
Банковские реквизиты
компании
banking_detail
s
нет
Комментарии
Дополнительные
комментарии о компании.
comments
нет
Emails
Электронные адреса
компании.
emails
да
Интернет-
мессенджеры
Различная контактная
информация по
средствами интернет-
мессенджеров.
ims
да
Телефоны
Телефонные адреса.
phones
да
Веб-адреса
Различные ссылки
связанные с компанией.
webs
да
Данные необходимые для хранения о проекте описаны в таблице №3.
Таблица №3
23
Описание необходимых для хранения данных проекта.
Название
значения
Описание
Машинное
название
Является ли
значение
множественн
ым
Название
Название проекта
title
нет
Статус
Статус проекта,
обозначающий активный
он или нет.
status
нет
Описание проекта
Необходимое описание
для проекта.
description
нет
Дата создания
Дата создания проекта в
системе.
created
нет
Дата изменения
Дата последнего
изменения проекта в
системе.
changed
нет
Веб-адрес
Различные ссылки для
проекта.
В таблицах выше представлены данные, необходимые для хранения
информации о каждом элементе CRM. Также, модули могут добавлять свои
данные динамически, для того чтобы не появлялись ненужные зависимости.
24
Рис. №5 Схема связи данных
Данная система должна быть разработана с использованием CMF Drupal 8,
так как компания занимается разработкой на ней и поддержка, а также доработка
функционала, в дальнейшем, под свои нужды, не составит проблем.
Каждый элемент CRM должен быть выделен в отдельный модуль и быть
самодостаточным. Реализация хранение данных должна использовать свои
собственные сущности системы.
Entity
11
- в Drupal являются структурными единицами, описывающие те
или иные данные, как их хранить, где их хранить и всевозможные операции над
ними. В задаче компания, контактное лицо и проект являются сущностями, и
должны быть объявлены соответственно.
Данная реализация поможет компании начать перенос всех данных на
своё собственное решение с последующим расширением функционала под
специфику её работы. Это позволит не только, в будущем, сэкономить
множество времени на ввод и анализ информации, а также, отказаться от
сторонних сервисов, которые накладывают свои ограничения на текущий
процесс работы.
11
Entity - сущность.
25
1.2.3. Обоснование необходимости использования вычислительной
техники для решения задачи
На данный момент хранение информации в компании производится при
помощи сторонних сервисов.
Хранение информации о проектах и клиентах производится при помощи
Google Spreadsheets
12
. Клиенты никак не связаны с проектами, что может сильно
замедлять работу, при возвращении к старым клиентам\проектам.
Рис. №6 Текущее состояние хранения данных
Также, на данный момент, в таблицах отдельно записываются все записи о
работе над тем или иным проектом для того или иного клиента. Приходится
постоянно указывать дату работ, клиента, проект, а также время работы.
После реализации функционала с контактными лицами, компаниями и
проектами, можно будет развивать CRM дальше и добавлять требуемый
функционал. Как минимум, имея явные связи проект - клиент, необходимость
указывать клиента отпадает.
В текущей ситуации даже нет такого понятия как “контактное лицо”. Нет
четкой привязанности какого-то конкретного человека к проекту или компании.
При работе с постоянными клиентами и их сотрудниками, данные проблемы не
так остры, как при возвращении к старым клиентам. Через полгода-год, уже
приходится вспоминать, что за человек пишет, о каком проекте он ведет речь, и
что это за компания. Заполнять это всё в таблице тоже не имеет особо смысла,
так как не будет явных связей, и если что-то поменяется, придется проделывать
объемную работу чтобы проследить, что везде данные теперь актуальны.
12
Google Spreadsheets - таблицы.
26
Хранение данной информации в таблицах также имеет ряд недостатков.
Так как постоянно появляются новые проекты, клиенты, контактные лица, база
начинает расти, она становится менее структурированной и более хаотичной без
явных связей. Для решения этой задачи, приходится в начале каждого нового
финансового года, создавать новую таблицу и переносить действующие проекты,
клиентов и прочую информацию, чтобы можно было продолжать историю, и
новые добавляются по мере их обращения. Если взять данную информацию за 3
года, это 3 разных таблицы, что очень сильно усложняет поиск какой-либо
информации, если она от прошлого года или позже. Также данная проблема
остро ощущается в первый квартал года, когда новая таблица не имеет еще всех
данных или какие-то были забыты. Приходится постоянно возвращаться к
предыдущий и проводить сверку с ней. Это требует очень много времени, и
очень легко допустить ошибки.
Собирая данные в одном месте, четко разделяя какая сущность за что
отвечает, данная проблема будет сведена к минимуму, так как данные будут
скапливаться в одном месте, а имея полный доступ к ним и кодовой базе, можно
добавлять различный функционал, фильтрации, поиск и т.д.
Немаловажен и тот факт, что текущий процесс заточен исключительно
под одного человека. Разобраться в данных таблицах человеку со стороны,
потребуется больше времени, чем, если бы они были четко разделены на свои
разделы и не путались вместе. При этом, появление нового сотрудника,
полностью противоречит текущему способу ведению данных, так как если туда
начнет вносит изменения второй человек, не будет ясно, кто что вносит, и кто за
что отвечает.
Другой проблемой является то, что данные в таблице ограничены
возможностями таблиц. Примерно со второй половины года, данных становится
так много, что для добавления простой записях, приходится долго листать
таблицу, чтобы дойти до последней строки. Перенеся всё на собственное
решение, вывод информации, её редактирование и добавление будут явно
разделены и не будут мешать друг другу.
27
Всё это приводит к снижению производительности работы, меньшему
контролю над информацией, повышает вероятность ошибок и не пригодно для
работы в команде.
Начав реализацию CRM с самых фундаментальных для неё данных:
контактных лиц, компаний и проектов - повысится скорость внесения данных,
их целостность, появится совершенно новые возможности по хранению и
расширению данных, лишит ограничений на одного пользователя и даст
фундамент для дальнейшего расширения функционала и переноса других
используемых сервисов в один общий и связанных, например: учет времени,
выставление счетов, движение по балансу и т.д.
1.2.4. Анализ системы обеспечения информационной безопасности и
защиты информации
На текущий момент информация хранится в публичном сервисе Google
Drive. Данный файл закрыт от внешнего просмотра и к нему не имеют доступа,
никто, кроме его автора.
Защита до файла осуществляется на уровне аккаунта Google. Для этого
используется сложный пароль, содержащий как символы, так и буквы с спец.
символами, а также двухфакторную аутентификацию. Этот пароль был
сгенерирован случайно, не известен даже его владельцу и хранится в
зашифрованном файле по стандарту AES
13
-256 (3), который открывается по
мастер-паролю
14
на 30 секунд, и все взятые оттуда данные, самоуничтожаются
через 30 секунд из буфера обмена, а зашифрованный файл, снова блокируется.
Мастер-пароль является также уникальным, никому не известным комбинацией
букв, цифр, символов и спец. символов, вводимый исключительно по памяти
владельца файла.
Доступ к данному аккаунту активирован только на рабочей станции,
которая находится вне доступа для третьих лиц. На случай доступа, там
используется защита на уровне операционной системы. На рабочей станции
установлен Linux, благодаря чему, вероятность вирусов, сведена, практически к
нулю, так как всё контролируется и распределено по группам и правам доступа.
13
Advanced Encryption Standard - расширенный стандарт шифрования.
14
Пароль, на основе которого производится шифрование, и который, позволяет дешифровать
зашифрованные им данные.
28
Вмешательства в компьютер извне практически невозможно, так как доступ из
интернета блокируется еще на уровне маршрутизатора не доходят
непосредственно до машины.
Имея физический доступ к рабочей станции, там также установлен пароль,
который блокирует всю систему либо при нажатии горячих клавиш, либо спустя
определенное время не активности пользователя.
Компания не имеет защиты от инсайдерских угроз, так как на данный
момент весь процесс построен под одного человека. Разрабатывая собственную
CRM, данная особенность будет предусмотрена.
1.3. Анализ существующих разработок и выбор стратегии
автоматизации «КАК ДОЛЖНО БЫТЬ»
1.3.1. Анализ существующих разработок для автоматизации задачи
Чтобы провести более детальный анализ существующий разработок,
придется заглянуть немного наперед и составить список требований к CRM,
часть из которых будет реализована в дальнейшем, после реализации основной
части, которая описана в дипломной работе.
Конечная CRM должна содержать:
● базу контактных лиц;
● базу компаний (контрагентов);
● базу проектов;
● базу счетов;
● хранение истории поступления платежей и затрат;
● учет времени и пересчет в транзакцию с сохранением истории;
● анализ информации.
С учетом будущих планов по развитию CRM можно более детально
проанализировать и сравнить существующие решения.
Для анализа были выбраны популярные решения, с которыми также был или
имеется опыт взаимодействия у компании и имеют схожий функционал:
Битрикс24, amoCRM, GitLab, Toggl, Jira.
Каждый из данных решений сравнивается с конечным требованием к CRM от
компании, а также дополнительных требований, таких как: является ли решение
OpenSource или основано на OpenSource решении, имеет API позволяющий