Обзор ERP на базе Drupal 9

Введение

В данной статье предлагаю вам обзор ERP, созданной на основе Drupal 9 для зооклиники «Зоостатус» ( кстати сайт у них тоже сделан на Drupal 9, был переход с Bitrix, но уже совсем другая история).

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

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

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

При написании обзора я буду опираться на статью «Что такое ERP?».

Платформа.

1. Ядро.

Ядро представляет собой Drupal 9, которая является PHP CMS-системой, которую кто-то еще может называть CMF системой. Много об этом я рассказывать не буду. Вы можете сами почитать о ней в статье «Что такое Drupal 9?». В ней вы найдете полный обзор системы Drupal 9.

2. API.

API реализована на основе модуля RESTful API. Это является модулем, который находится непосредственно в ядре. Он может быть, как активирован, так и не активирован, смысл в том, что этот модуль всегда есть в системе, какую бы вы конфигурацию Drupal 9 не установили. Про это вы также можете почитать в статье про Drupal 9.

3. Управление данными.

Управление данными в данном случае реализовано на основе функционала CMS Drupal 9. В ней есть все необходимые элементы. Это ноды, таксономия и так далее.

4. Программный код.

В данном случае используется PHP с использованием фреймворка Symfony. Про фреймворк Symfony вы можете почитать на сайте про Symfony. Базовый функционал представлен Drupal 9.

Это кратко о том, что касается платформы. Если резюмировать, то в качестве платформы в этой ERP используется не изменённый Drupal 9.

Теперь давайте непосредственно перейдем к самой системе. Система состоит из следующих модулей: CRM, CMS, телефония, POS-функционал, личный кабинет, связь с BI-системой. Давайте рассмотрим все эти модули по порядку.

Модуль CRM.

Модуль CRM разделён на несколько блоков под модули. Это модуль записи и модуль смс-информирования.

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

Система устроена таким образом, что у администратора осуществляющего запись есть возможность при выборе врача сначала выбрать услугу (например, Анестезиолог), а вместо конкретного врача выбрать вариант “Любой”.

Смс-информирование сделано посредством интеграции с смс-сервисом смс.ru. Каким образом это происходит. Заведены шаблоны и при определенных изменениях в базе данных — при создании новых записей или при наступлении определённого момента — высылается смс, оповещающее об определенных событиях. 

Модуль CMS.

CMS (Content Management System) в данном случае реализован полностью на базовом функционале Drupal 9. То есть там, где нужно, у нас созданы виды материалов. Это, к примеру, могут быть счета, заключения и таксономия. Таксономии в данном случае являются словарями, например, Категории услуг, Виды и Породы животных. То есть модуль CMS и все возможные CMS-системы Drupal 9 никак не изменены и используются как есть.

Телефония.

Телефония реализована в полноценной связке с системой Asterisk посредством API. Для этого используется API Drupal и API системы Asterisk. Про телефонию вы также можете почитать в статье.

Что такое телефония в CRM и как её выбирать.

Как происходит работа модуля телефонии:

При поступлении звонка система показывает окно, в котором оператор заполняет все необходимые поля и сохраняет. Если это необходимо, он тут же может завести нового клиента или записать клиента на определенную дату.

Также следует отметить интересный момент: если клиент отмечен как «неадекват», то скорее всего система его не запишет. Каким-либо образом произойдет отмена записи, и с ним просто не будут работать.

При исходящем звонке оператор просто нажимает на соответствующую кнопку в карточке клиента, и происходит вызов клиента, которому необходимо позвонить. Об этом тоже можно сделать запись. Все входящие и исходящие звонки, к которым подключена телефония и ERP-система, сохранены в определенном блоке «звонки», которые вы можете увидеть на скриншотах.

POS.

В системе имеется также система POS (Point of Sale). За Point of Sale отвечает программа Frontol, в которую выгружаются данные о товарах для аптеки и об услугах непосредственно для зооклиники.

Личный кабинет.

Стоит отметить, что личный кабинет реализован опять-таки на базе Drupal 9. Просто в данном случае в систему входят по номеру телефона. То есть человек регистрируется и получает логин и пароль. Логином служит его номер телефона, а пароль он устанавливает сам. После этого он может увидеть все документы, которые ему необходимы в системе.

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

Оказание услуги.

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

Как устроено Оказание услуги внутри.

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

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

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

История болезни.

При переходе кнопкой Посмотреть ИБ из редактирования услуги откроется окно карточки пациента (животного). Здесь представлена сводная информация по всем аспектам взаимодействия с животным нашедшим отражение в системе.

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

Конструктор Заключений.

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

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

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

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

Отчетность.

Надо сразу отметить что в Drupal нет своей системы отчетности как таковой, всё-таки это прежде всего CMS система, система для Web-разработки и вопрос отчетности, сбор и интерпретация отчетности, не решается средствами Drupal.

BI система Zoho Analytics.

В связи с этим было принято решение использовать BI систему Zoho Analytics. Система отчетности используется не Drupal. То есть данные выгружаются из Dupal в Zoho Analytics, в ней уже созданы отчеты. Zoho Analytics, используя данные из Drupal, показывают на их основе различную отчетность. Почему выбор был сделать в пользу Zoho Analytics? Это наиболее близкая система, наиболее дешевая, из тех которые представлены на рынке в сравнительном функционале.

Как это было сделано?

Для формирования отчетности в Zoho Analytics мы настроили полную выгрузку базы данных из Drupal и последующую её загрузку и синхронизацию в Zoho Analytics. Были настроены соответствующие SQL запросы таким образом, чтобы они могли формироваться исходя из тех данных, которые есть в этой базе данных. Так как сам по себе Drupal это достаточно стройная система, особых сложностей при создании требуемых отчетов не возникало. На скриншоте вы можете видеть как устроены таблицы Drupal. И даже при добавлении в них новых полей, новых данных сложностей никаких не возникало. Синхронизация данных происходит с периодичностью 1 раз в 5 часов. Выгружаются только изменения в базе данных, которые мониторятся и выгружаются специальным плагином.

Модули вне ядра.

Какие модули были использованы в Drupal 9 кроме тех, которые в ядре, и которые также хотелось бы отметить.

1. Field group.

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

2. Field validation.

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

3. Field Inline Entity Form.

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

4. Better Exposed Filters.

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

5. Multiple fields remove button

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

Почему был выбран именно Drupal.

Эта платформа была выбрана заказчиком из всех остальных по следующим причинам:

Первое — это цена. На тот момент, если бы закупался 1С, то по расчетам только один сервер и ПО стоили бы больше миллиона, а лицензии — порядка полутора миллионов. И это было полтора года назад. Сразу скажу, что внедрение и разработка ERP модуля стоила гораздо меньше. Так как сам Drupal бесплатен и гораздо менее требователен к железу. Мы запросили системного администратора клиента информацию о сервере, вот его ответ:

То есть вся система вместе с развернутой виртуалкой занимает менее 8 ГБ ОЗУ, а сама система занимает менее 1.8 ГБ. Это на систему в которой на текущий момент зарегистрировано более 100 пользователей и накоплено данных почти за целый год (запуск был в мае 2021 г.).

Второе — очень важна была масштабируемость. То есть 1С масштабируется очень сложно. Как это не прискорбно, но 1С при определённых параметрах начинает просто тормозить. И в данном случае было очень важно, чтобы это всё на определенном уровне работало быстро. Drupal это сделать позволяет, о чем, среди прочего, говорят приведенные выше технические данные по потребляемым системой ресурсам.

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

Какая в итоге получилась система.

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

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

С уважением Кинзябулатов Рамиль.