Введение

В данной статье предлагаю вам обзор 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, благодаря своей гибкости, позволил создать такой инструмент, как конструктор форм, который использовался для вывода форм в различных заключениях и так далее.

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

Комментарии (12)


  1. Ranyee
    22.03.2022 14:20
    +1

    Сколько пользователей? Какое ПО вы считали для 1с? Хотели сильно сэкономить, можно было купить только лицензии 1с, остальное на линукс и тонкий клиент, 2.5 мульта там никак не вырисовывается. Ну и функциональность к erp имеет очень далекое отношение. Управление закупками, бухгалтерию и зарплату все равно считать надо. Значит 1с какая-никакая есть. Личный кабинет можно было на сайте, остальное в 1с. Какой смысл всего этого - непонятно. Ну и вопрос дальнейшей поддержки и развития остается...


    1. ramil_trinion Автор
      22.03.2022 14:28
      +1

      Сколько пользователей? Какое ПО вы считали для 1с? Хотели сильно сэкономить, можно было купить только лицензии 1с, остальное на линукс и тонкий клиент, 2.5 мульта там никак не вырисовывается

      Спросите клиента. Считали они.

      Ну и функциональность к erp имеет очень далекое отношение. Управление закупками, бухгалтерию и зарплату все равно считать надо. Значит 1с какая-никакая есть. Личный кабинет можно было на сайте, остальное в 1с

      Этого мне неизвестно. Закупки запускаем как раз. Про зарплату тоже неизвестно.

      Ну и вопрос дальнейшей поддержки и развития остается...

      Drupal не 1с, обновления ядра ничего ни разу не ломали при мне.


      1. Ranyee
        22.03.2022 15:25

        Ну, это вредительство. И потом, вам это зачем, тоже непрнятно.


        1. ramil_trinion Автор
          22.03.2022 15:33
          +1

          Что именно вы называете вредительством?


  1. svboobnov
    22.03.2022 15:09
    +1

    Как-то странно называть словом "ERP" (напомню, что это "планирование ресурсов предприятия") довольно простую CRM. Вы бы посмотрели в сторону Dolibarr или Intars, или какую - нибудь ещё открытую / бесплатную систему, в которой, помимо учёта оказанных услуг, можно отчёты строить и бухучёт вести.

    А то сейчас у вас "...данные выгружаются из Dupal в Zoho Analytics,...", а о зарплате данные руками переносятся в зарплатную программу, а об услугах данные руками переносятся в бухгалтерскую программу... И так далее. (Вы же не в курсе, что с бухучётом, налогами и зарплатой, и выгрузки в эти системы не делали). То есть, ваш заказчик платит какому-то отдельному человеку за ручной перенос данных, а бухгалтерам доплачивает за перепроверку этих данных. Нехорошо.


    1. ramil_trinion Автор
      22.03.2022 15:41
      -1

      Как-то странно называть словом "ERP" (напомню, что это "планирование ресурсов предприятия") довольно простую CRM. 

      Ознакомьтесь с моей статьей на тему ERP пожалуйста, ссылку на нее я привел в статье.

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

      Зачем? Есть работающая система, она заказчика устраивает.

      А то сейчас у вас "...данные выгружаются из Dupal в Zoho Analytics,...", а о зарплате данные руками переносятся в зарплатную программу, а об услугах данные руками переносятся в бухгалтерскую программу...

      Бухгалтерский учет и налоговый, это вопросы которые решаются другими системами.

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

      Делал, и много раз. Именно поэтому и считаю что проще выгружать данные в готовую бухгалтерскую систему, чем писать свою. Крайне важно понимать к тому же, что БУ и НУ необходимы для сдачи отчетности, а не для ведения оперативного учета.

      То есть, ваш заказчик платит какому-то отдельному человеку за ручной перенос данных, а бухгалтерам доплачивает за перепроверку этих данных. Нехорошо.

      Кому как. Заказчику виднее.


  1. donpadlo
    22.03.2022 16:52
    +1

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


    1. ramil_trinion Автор
      22.03.2022 16:59
      +1

      На минутку представим, что будет если создавший эту систему человек пропал. 

      Создавал не один человек, а команда. Так что знания о системе имеют несколько человек.

      И начинаются поиски с дикими глазами того кто сможет её поддерживать и дорабатывать.

      А это уже проблема не продукта, а руководства. DRUPAL открытая система, которая написана на PHP. При желании специалиста всегда можно найти.


      1. donpadlo
        22.03.2022 17:07
        +3

        Есть небольшой опыт владения сайта на Drupal (не "ЕРП" но тоже не простого). Студии на любое изменение заряжали ОЧЕНЬ не гуманные ценники. А фриланс был не удачен при двух попытках из 2-х. Причем выбирали не "самых дешевых". В конечном итоге пришлось идти на поклон к той студии которая собственно сайт и создавала. Потому очень скептически отношусь к каким либо ИТ системам привязанных к работе и в экземлярах внедрения 1-2 штуки на всю страну

        Спустя почти 2 года спустя, пришел к мысли, что хоть битрикс и отвратителен по своей глубинной сути, но из-за доступности специалистов, в моём случае это был бы правильный выбор.


        1. ramil_trinion Автор
          22.03.2022 17:13
          +1

          Есть небольшой опыт владения сайта на Drupal. Студии на любое изменение заряжали ОЧЕНЬ не гуманные ценники. А фриланс был не удачен при двух попытках из 2-х. Причем выбирали не "самых дешевых".  В конечном итоге пришлось идти на поклон к той студии которая собственно сайт и создавала. 

          Мне жаль что у вас так получилось. Это проблема рынка в целом ( читай капитализма).

           Потому очень скептически отношусь к каким либо ИТ системам привязанных к работе и в экземлярах внедрения 1-2 штуки на всю страну

          Это вы про SAP?


  1. OksikOneC
    22.03.2022 21:47
    +1

    Спросите клиента. Считали они.

    Кому как. Заказчику виднее.

    Ну хорошо, давайте я посчитаю "за заказчика" цену, проверяя по факту одну вашу цитату из текста статьи:

    На тот момент, если бы закупался 1С, то по расчетам только один сервер и ПО стоили бы больше миллиона, а лицензии — порядка полутора миллионов.

    Начнем со второй части. Лицензии. Текущая цена 100 клиентских лицензий по прайсу на текущую дату:

    1С:Предприятие 8 ПРОФ. Клиентская лицензия на 100 рабочих мест- 360 тыс. руб.

    Также приплюсуем сюда и лицензию на сервер 1С из учета, что его куплено не было ранее:

    1С:Предприятие 8.3 ПРОФ. Лицензия на сервер (x86-64). Электронная поставка - 86 тыс. 400 руб.

    Итого: на лицензии 1С цена на текущую дату 446 400 руб. Куда делся еще миллион?

    Перейдем к первой части: "сервер и ПО стоили бы больше миллиона". Во-первых ПО - это же про Win сервер? Зачем он вам? Linux + PostgreSQL = бесплатно. По поводу железа, я внимательно прочитал, то что описали Вы в статье - там не видно, как сервер за условный миллион в тех ценах вы могли "утилизировать" под ваши задачи. То что вы описываете как "ERP", не вдаваясь в теоретические дебаты, по факту - обычный забивочный фронт, в котором пока даже не видны какие-то контроли остатков, задолженностей, вычислений себестоимостей, план-факторных каких-то анализов и т.д. Т.е. переводя на язык 1С - у вас пока не видно ни задач, ни объемов, ни количества пользователей на которых клиен-серверный вариант 1С - лег. Но конечно, в любом случае, это не виртуалка с 8 Гб оперативы и 2 Гб на дисковой подсистеме. Но и не сервер за миллион.

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

    Оно уже и давно масштабируется, причем по всякому и давно при обновлениях - ничего не ломается, это не от платформы зависит, от кривизны рук и мозгов обновлятора, Вы написали статью в ключе VS. Разработка на Друпале vs разработке на 1С, и вывод - последнее на вашей задаче стоит космо-денег, оно чот там при обновлениях какое-то не такое, оно там не масштабируется, ну дальше по тексту. Вы никаких цифр в статье не привели, пришлось считать за вас. Мои расчеты выше - космо-денег даже в нынешних ценах нет.

    Собственно, если вообще подойти критически к экономической составляющей вашей разработки и ее целесообразности с точки зрения вакуума, т.к. "заказчику виднее", то лично я тут что вижу?

    1. 100% bus factor. Вы конечно это отрицаете, но это очевидно. 1С именно в вашем конкретном случае, если бы разработка велась на ней - таковым фактором не является.

    2. Скорость и цена разработки. Понятно, что в вашем случае это NDA и все такое, но тут по вашему описанию, хоть вы и говорите, что в рамках одной статьи все не написать - не видно какой-то сложной долгой коммерческой разработки. В 1С тоже есть готовый фреймворк, который позволит вам многие вещи получить прямо из коробки бесплатно с миллионами блэков, девочек и т.д. Да у вас много печатных форм, но это все давным давно пройденный этап для 1С - если вы чуть копнете эту тему, то это не проблема, это работа для джуна с соотв. тарифной ставкой.

    3. Вы утверждаете, что ничего подобного, что подошло бы клиенту на 1С - нет. Возможно. Но с трудом вериться именно в "уникальность" бизнес-процессов клиента, даже исходя из скринов, которые Вы представляете. Ну т.е. скорее всего - даже с нуля писать бы ничего не пришлось, можно было бы взять что-то за основу скелета и получить на выходе прям совсем киллер-фичный "уникальный" продукт, кои и представляют основной массой собой все подобного рода внедрения.

    Подведу итог: спасибо Вам за статью, интересно почитать про чужой опыт подобной автоматизации. С тезисами именно неприменимости 1С по вашей аргументации - я не совсем согласен. Как смог, попытался свою позицию Вам обосновать.


  1. fosihas
    23.03.2022 12:59

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

    По производительность что 1С проигрывается, соглашусь отчасти. С чем сравнивали т.к. тут на нет готового решения 1с, и придется разрабатывать. То и производительность системы будет на совести разработчика.