29
пользоваться системой на программном уровне из внешних источников,
стоимость использования за 1 рабочее место.
Обозначения в сравнительной таблице №4:
● “+” - имеется в достаточном объеме;
● “-” - полностью отсутствует;
● “~” - имеется частично, или с определенными
ограничениями\требованиями.
Таблица №4
Сравнение имеющихся систем
Особенность
Битрикс24
amoCRM
GitLab
Toggl
vtiger
База
контактных
лиц
+
+
-
-
+
База компаний
(контрагентов)
+
+
~
~
+
База проектов
+
+
+
~
+
База счетов
+
-
-
-
~
Учет движения
финансов
~
~
-
~
-
Учет времени с
пересчетом в
движение
баланса
~
-
~
+
-
Аналитика
+
+
+
+
+
Соответствие
на OpenSource
~
-
+
-
-
API
+
+
+
+
+
Стоимость
0-11990
руб./м.
499-1499
руб./м.
до
7000р/м
. за 1
пользов
ателя
0-
1500р/м.
за 1
пользоват
еля
3000р/м. за
1
пользовател
я
Далее представлено небольшое резюме по каждой рассмотренной системе:
30
● Битрикс 24 (5). Имеет огромный функционал даже в бесплатной версии.
По основным функциям полностью подходит, но слишком избыточна для
конечных задач. Большинство возможностей просто не нужно в
специфике работы компании. Основной упор сделан на маркетинг и то что
с системой будут работать маркетологи, нежели разработчики. API
достаточно большой, но невозможность модифицировать систему под
свои нужды с программной стороны, делает её очень не выгодной.
● amoCRM (6). Имеет базовый функционал, и похожа на урезанную версию
Битрикс 24. Больше заточена под маркетинг и маркетологов, нежели
разработчиков.
● GitLab (7). Из базовых требований в достаточном объеме имеет только
проекты, и немного в своеобразном виде клиентов, которых можно делать
через группы, и полностью отсутствующей базой контактных лиц. Имеет
учет времени, но без возможности как-то его в дальнейшем отслеживать,
выводить по нему статистику и пересчитывать в движение средств. Также
в плюсы данного сервиса можно отнести её полную открытость, и при
разворачивании проекта на своём сервере, платить за пользоавтелей
придется только при очень больших потребностях. В самых больших
пакетных планах, функционал уже больше походит на желаемый, но
стоимость, как минимум, в $99 за одного пользователя в месяц, очень
большая, для таких потребностей. Из всего что там будет доступно, опять,
потребуется только часть, как и в Битрикс 24, выходит большая переплата
за воздух.
● Toggl (8). Хотя сервис и является тай менеджером, он содержит в себе
куда больший функционал. Там можно организовывать хранение
клиентов и их проектов с прямыми связями, отслеживать затраченное
время, даже для нескольких сотрудников одновременно, анализировать
затраты времени, пересчитывать их в счета. Данная система уже больше
подходит для процесса работы компании, но функционал достаточно
ограничен и скуден. В клиентах и проектах нет никакой дополнительной
информации, она сведена к минимуму, контактные лица отсутствуют, а
31
учет времени с оплатой и одновременная работа нескольких лиц
недоступна для бесплатного использования.
● Vtiger (9). Одна из самых первых CRM на рынке, с большой историей,
функционалом и имеет много информации о себе. К сожалению, она по
большей части также заточена на маркетологов и учет продаж, нежели на
другие способы взаимодействий с клиентами.
Подводя общий итог по уже существующим решениям, можно сделать вывод,
что представленные на рынке популярные сервисы и решения, хоть и
удовлетворяют базовым задачам необходимой CRM, но по остальным пунктам
сильно расходятся с необходимым функционалом. Либо сходятся, но не в
полном объеме, а возможности доработки не имеется в принципе.
Большинство сравниваемых CRM заточены под маркетинг и привлечение новых
клиентов, что не вписывается в процесс и принцип работы компании. В текущей
кампании, взаимоотношения с клиентами строятся на существующих и будущих
проектах, необходимо детально отслеживать по каждому проекту затраченное
время, переводить его в счета и вести аналитическую часть, кто сколько должен
или переплатил. Хранить историю финансовых расчетов, а также информацию о
всех контактных лицах и кто ответственен за какой проект. Компания не ставит
для себя целью привлечение новых клиентов, не проводит никаких рекламных
акций. В связи с этим, функционал большинства рассмотренных решений не
вписывается в процесс работы, построенный в компании.
Существующие решения делают большой упор на привлечение новых клиентов,
когда компании нужен больше инструмент, для отслеживания рабочего процесса
тесно связанного с клиентами и их проектами.
В данном случае, самым лучшим решением будет создание своей собственной
CRM, которая будет учитывать все необходимые нюансы компании и
специфику её работы. Также, большим плюсом в пользу разработки своей CRM
выступает то, что компания сама является разработчиком, и может своими
силами развивать и поддерживать собственную CRM, без необходимости
обращения к третьим лицам. CRM будет разрабатываться на системе, с которой
компания знакома, что не потребует изучения того, как и что устроено в CRM и
исходный код будет всегда доступен. Выбор популярной системы с открытым
32
исходным кодом, также позволит привлекать разработчиков со стороны, и, если
штат будет расти, он будет пополняться разработчиками данной системы, так
как она активно используется в работе. Это также положительный момент, ведь
другие разработчики, использующие выбранную систему, спокойно смогут
влиться в разработку.
Разработка своей системы будет практически бесплатной, где основной платой
будет время. Если взять примерную стоимость часа разработчика на выбранной
системе в $15. И сравнить с двумя, максимально приближенными решениями
GitLab и Toggl, можно выявить и экономическую выгоду.
Примерно, для реализации всего необходимого функционала, без учета
серьезных UX
15
(10), то техническая часть может занять в районе 25-50 часов.
Таким образом, если переводить затраты времени компании в убытки, то это
порядка $375-$750 за полностью рабочую под задачу систему, на года вперед.
Если это сравнить, хотя бы, с годовыми затратами на самых подходящих
системах, то получится, что год пользования GitLab одним пользователем, на
тарифе, который больше всего покрывает задачи $99 в месяц, выйдет в $1188 за
год. Toggle, при покупке за год, делает скидку, таким образом выходит, что
месяц подходящего тарифа будет стоить $18, что выйдет в $216 за год. При этом,
нужно учитывать, что получившиеся суммы для сравнения за одного
пользователя, когда в своей системе они будут не ограничены. Toggl хоть и
выходит выгоднее, но совершенно ненамного, при этом будет лишен половины
того функционала что нужен. Если же расписать эти расчеты на уже 3 года, то
суммы будут разниться ещё сильнее.
При этом, покупая готовый сервис, нет никакой возможности влиять на его
функционал и подстраивать его под себя. Выходит, что компании придется
подстраивать свой процесс работы под покупаемую систему, вместо того, чтобы
система подстраивалась под нужды компании. А беря во внимание, что
компания сама является разработчиком, покупать решение и подстраиваться под
него, вместо того чтобы разработать решение, подстроенное под уже
действующий процесс — пустая трата денег, и возможно, пагубные последствия
перестройки процесса под систему.
15
User eXperience - опыт пользователя.
33
В плюсы собственной разработки можно отнести и то, что исходный код
системы можно опубликовать в открытом доступе и сделать его OpenSource
проектом. Это как минимум, не будет стоить компании ничего, так как требует
порядка пары минут на создание такого проекта из имеющегося. В случае
заинтересованности системой других компаний и разработчиков, система может
получить независимый аудит и помощь других разработчиков, будет
дополнительный фидбэк
16
и улучшения в систему, что положительно скажется
на конечном продукте. При необходимости, компания сможет оказывать
коммерческую помощь по установке, настройке и доработке своей системы под
другую компанию, что может в итоге стать дополнительным источником дохода
компании. Что совершенно исключено с другими системами.
1.3.2. Выбор и обоснование стратегии автоматизации задачи
Разработку стратегии автоматизации можно разделить на следующие
этапы:
● Анализ бизнеса.
○ Описание этапа: На данном этапе необходимо
проанализировать бизнес и изучить те аспекты, которые собираются
автоматизировать. Необходимо выявить узкие места текущего процесса, какой
конечной целью являются те или иные действия, а также, как это всё связано с
другими аспектами работы компании.
○ Цель этапа: Выявить узкие места в текущем процессе. Что не
хватает, что работает плохо, а что работает хорошо.
● Анализ стратегии развития бизнеса.
○ Описание этапа: Помимо того, что необходимо внедрять прямо
сейчас, также, необходимо и изучить, как планируется развивать бизнес в
дальнейшем и что теоретически может появиться, что будет отражено на
разрабатываемой системе. Так, накладывая на базовую структуру потребности,
которые могут появиться позже, можно выявить ее несовершенство.
○ Цель этапа: Выявить места в системе, которые могут стать узкими в
будущем, и заранее проработать более детальную архитектуру при ее разработке.
● Определение основного функционала ИС.
16
От англ. feedback - обратная связь.
34
○ Описание этапа: Необходимо определить, что из желаемого
функционала, приоритетнее всего в реализации, без чего другие части системы
не будут полезны или работать вообще.
○ Цель этапа: Определение фундаментального функционала системы,
без которого другие этапы либо не реализуемы, либо не будут иметь пользы.
● Определение используемых технологий.
○ Описание этапа: Необходимо изучить, какие технологии могут быть
использованы, и должны быть использованы в обязательном порядке.
○ Цель этапа: Формирования списка используемых технологий.
Определение роли каждой технологии в ИС.
● Определение архитектуры и подхода к реализации.
○ Описание этапа: На данном этапе, необходимо решить, как будет
выполняться задача с использованием выбранных технологий. Изучить все
возможные варианты решения задачи в пределах выбранных технологий и
выбрать самый лучший.
○ Цель этапа: Определение, как будет делаться проект с
использованием выбранных технологий.
● Определение методологии разработки.
○ Описание этапа: Изучить известные методологии разработки и
выбрать наиболее подходящую.
○ Цель этапа: Грамотно выбранная методология не позволит проекту
умереть на этапе разработки.
1.3.3. Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Для решения задачи решено не использовать готовые ИС, а построить
свою собственную, так как это выгодно с экономической стороны и
репутационной для бизнеса.
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному
обеспечению
В качестве базового функционала необходимо сделать хранилище для
контактных лиц, компаний и проектов компании. Данные, необходимые для
35
хранения по каждому из модуля ИС основываются на необходимых данных
компании, и общепринятых данных. Каждый модуль должен иметь свою форму
как для ввода, так и для редактирования данных. Все данные должны храниться
в реляционной БД, к которой подключается система. Это позволит делать
сложные выборки данных с быстрой обработкой.
Описание каждого из модулей должно производиться программно. Все
базовые данные и структура должно собираться программно, с минимальным
использованием интерфейса выбранной системы, который предоставляет лишь
универсальные хранилища, а для текущей ИС необходимо получить
максимальный контроль над данными на всех их этапах.
Прежде всего, при хранении данных, стоит максимально опираться на
общепринятые стандарты хранения данных, что позволит при необходимости
конвертировать в другие.
При организации файловой структуры проекта, стоит придерживаться
стандартам принятым в используемой системе. Структура должна быть четкой,
понятной и не конфликтовать с той, что используется в ядре выбранной системы
и ее компонентах.
Весь написанный код для ИС должен быть разбит на самостоятельные
модули и задокументирован по стандарту PHPDoc
17
(11). Все функции, методы и
свойства объектов, должны быть задокументированы по всем требованиям
системы. Сложные участки кода должны быть также закомментированы и
объяснены, почему используется та или иная логика, и какую цель она
выполняет.
Формы для ввода и редактировании информации должны быть описаны
при помощи Form API (20), если это требуется, по умолчанию необходимо
использовать штатные формы сущностей.
1.4.2. Обоснование проектных решений по программному
обеспечению
CRM систему необходимо сделать в виде веб-сайта. Это необходимо для
максимальной доступности системы, с любого устройств и любого места.
17
PHPDoc — адаптированный стандарт документирования Javadoc для использования в PHP.
36
Компания является веб-разработчиком, что позволит поддерживать и
сопровождать проект собственными силами.
Для реализации задачи, необходимо использовать систему Drupal 8.6.2
или выше. Drupal — является OpenSource системой управления содержимым, а
также каркасом для управления содержимым написанной на языке
программирования PHP. Система имеет большое сообщество, что предоставит
большой объем информации, и более быструю скорость поддержки по решению
проблем. Имеет полностью задокументированное ядро, которое также покрыто
тестами, что доказывает качество системы и ее надежность. Первая версия
системы появилась в 2000 году, и вот уже 18 лет, система является одним из
лидеров на рынке, что позволяет смело делать на ней долгосрочные проекты, и
риск, что всё быстро свернется, сводится к нулю.
В Drupal имеются очень строгие стандарты кода (12), необходимо писать
систему строго следуя данным стандартам. Весь код должен сопровождаться
комментариями, описанием аргументов, отдаваемых данных и реализуемых
особенностей. Это необходимо для того, чтобы код был идентичен всему
остальному коду, написанному в систему, и любой другой Drupal-разработчик
мог с легкостью подключиться к проекту.
Каждый элемент CRM: контактное лицо, компания, проект — должны
быть описаны в своих собственных модулях. Это необходимо для разделения
кода по смыслу, и не мешать всё в одну кучу. Каждый модуль должен быть
максимально самодостаточным и не зависеть от других, если в этом нет острой
необходимости.
Также, каждый из требуемых элементов должен быть описан как контент-
сущность
18
(14) Drupal. Все основные поля каждой сущности должны быть
созданы автоматически, в момент включения модуля, и удаляться, при удалении
модуля. Нужно определить и правильно добавить поля к сущности. Самые
важные, должны быть объявлены как базовые поля сущности (свойства
сущности), а все побочные, должны быть объявлены как конфигурационные-
сущности
19
. Это позволит сделать проект максимально гибким и иметь полный
18
Описание определенной единицы данных для хранения в БД.
19
Описание определенной единицы данных для хранения в YAML файле.
37
контроль над данными, а не подгонять существующие типы данных под
необходимые.
Ядро проекта должно быть установлено при помощи Composer Drupal
Project (16).
Если необходимо объявить свои объекты с какой-то логикой, которые не
являются частью Drupal API, необходимо их таковыми сделать, описав их как
сервисы (17).
Все требуемые внешние зависимости для проекта, должен быть
установлены при помощи Composer
20
(18). Это позволит очистить кодовую базу
от хаотичных внешних библиотек, а также ускорит процесс установки, удаления
и восстановления зависимостей.
Кодовую базу проекта необходимо вести с использованием VCS GIT.
Коммиты, их частота и объем не имеет значение. В репозитории не должно
присутствовать ничего, кроме собственного кода, конфигураций системы, и
очень базовых файлов, например index.php, composer.json, composer.lock. Таким
образом, репозиторий будет содержать только изменения на систему, без самой
системы и зависимостей.
В качестве веб-сервера будет использован NGINX, так как он является
высокопроизводительным и эффективным в использовании ресурсов, прост в
конфигурации и имеет очень большой функционал. Выбирая NGINX вместо
Apache, потребуется меньше ресурсов сервера для работы сайта, тем самым,
позволит сэкономить дополнительные средства компании.
Сайт будет работать на удаленном веб-сервере под операционной
системой Linux, в вариации дистрибутива CentOS 7 (19). Linux является самым
популярным выбором для веб-серверов и имеет множество готовых решений,
сообщества и самый актуальный софт. Весь основной софт под веб-разработку
разрабатывается, в первую очередь, а расчетом на Linux. В связи с этим
проблемы сводятся к минимуму. Также, данная система является полностью
свободной, что уменьшает издержки на покупку лицензий.
20
Composer - менеджер для управления зависимости на языке PHP.
38
Интерпретатор PHP будет версии 7.1.x в вариации FPM
21
, что обусловлено
использованием NGINX.
В качестве БД будет использована MariaDB (21), которая является
свободной вариацией MySQL. Данная БД рекомендована для использования с
Drupal.
Все запросы к БД, должны быть написаны с использованием штатных
инструментов Database API (22). Никаких прямых запросов в БД не должно быть
в кодовой базе проекта. Это позволит сохранить гибкость системы, при смене
типа БД, так как API, автоматически будет генерировать запросы в БД с учетом,
какая используется сайтом. Помимо прочего, данные запросы будут
автоматически оптимизированы, стерилизованы он возможных SQL инъекций
(23), что повысит качество и безопасность кода.
В качестве среды разработки будет использоваться phpStorm, так как он
имеет отличную интеграцию с Drupal, Symfony, Git, и другими используемыми
технологиями, что позволит серьезно сократить время на разработку продукта,
при этом, повысив его качество.
1.4.3. Обоснование проектных решений по техническому обеспечению
Реализуемая система является веб-сайтом. Поэтому, для его разработки, а
также использования, потребуются веб-сервера. Как минимум один основной, и
один рабочий.
Для основного веб-сервера, который будет использоваться для
эксплуатации ИС по назначению, потребуется VPS (24). На данном сервере
будет развернута ОС, веб-сервер, развернут и установлен проект.
Для веб-сайта в сети интернет, также потребуется доменное имя (43). По
нему будет осуществляться доступ к сайту и серверу. Так как сайт изначально не
будет содержать много информации, будет достаточно следующей
конфигурации: 1 vCPU (25), 2 гб оперативной памяти, объем SSD
22
(26)
накопителя 30 гб.
Для веб-сервера на рабочей станции потребуется как минимум 8гб
оперативной памяти, лучше 16. Современный процессор, с тактовой частотой не
21
FastCGI Process Manager
22
Твердотельный накопитель.