ERP-подобные системы на базе CMS: краткий обзор семейства

 
Статьи
ERP-подобные системы на базе CMS: краткий обзор семейства
Для малого онлайн-бизнеса оптимальны герои нашей статьи — качественно реализованные интернет-магазины, дополненные минимально необходимым функционалом для организации общего простого учета.

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

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

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

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

Ильф и Петров, «12 стульев»

CMS-based ERP-like systems, они же ERP-подобные системы на базе CMS (content management system — система управления сайтом), являются, в некотором роде, противоположностью промышленным модульным ERP-системам, рассмотренным ранее в другом тексте.

Если классические ERP, будучи изначально софтом для управления ресурсами традиционного промышленного предприятия, путем более или менее случайной пристыковки обилия внешних «модулей» на протяжении десятков лет наращивали функционал, и ныне пытаются изобразить из себя работоспособную систему для современного бизнеса (и даже, в некотором роде, с возможностями e-commerce), то у сабжевых «систем», напротив, ноги растут из примитивной админки для управления HTML-страницами.

Если поименно, то речь идет о бесчисленных поделках (тысячи их в буквальном смысле) на базе Joomla, Drupal, Prestashop и десятках менее известных «платформ».

С конца 1990-х — начала 2000-х гг, с развитием интернета и бизнеса в нем, потребности аудитории усложнялись, эволюционировал и функционал.

Некогда статичные HTML-страницы получили каталоги товаров с кнопкой «купить».

Стали хранить информацию о клиентах (логин-пароль-адрес доставки).

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

Также к услугам эксплуатантов бесчисленные «интеграции» с чем угодно.

Чуть менее, чем все из этих ERP-подобных систем являются оpen source разработками.

Само собой, со всеми изначально присущими такому софту плюсами и минусами.

Open source модель развития надстроек на популярных CMS-платформах с годами дала ошеломляющее разнообразие функционала, доступное в открытом доступе.

А вкупе с изначальной бесплатностью «платформ» привела к любопытному эффекту: если на постсоветском пространстве нишу дешевых систем для малого бизнеса непокобелимо оккупирует монстр рынка 1С, то на собирательном Западе эту нишу распределенно обсели неструктурированные толпы героев нашего рассказа.

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

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

Особо инициативные бойцы делают это вполне официально.

Однако™, несмотря на все притязания a la parvenu на принадлежность к высшему обществу, к трем почетным буквам ERP («Анна на шею»), употребляемым касательно героев нашего рассказа, мы все-таки дописываем снобистский субклассификатор -like.

«Типа» — в высоком штиле отечественной илиты последних лет в целом и Министерства иностранных дел в частности.

Из дальнейшего разбора их внутреннего устройства будет понятно, почему.

Ниже в таблице представлено сравнение технических параметров, общих для всего семейства, и частной реализации IEM System:
показать таблицускрыть таблицу

IEM System
CMS-based ERP-like
Архитектура
Монолитная
Модель данных
Насыщенная модель данных: справочники, документы, итоги. Rich data model позволяет делегировать платформе базовые операции и верификации, многократно увеличивая скорость разработки и снижая число ошибок.
Реализация веб-сайтов, ориентированность на «Страницы», контент, отображение информации. Модели данных нет (или ограничивается записями, возможно вложенными). Как правило, не используется ORM, данные вносятся и запрашиваются прямыми SQL запросами. Как следствие, нет проверки при компиляции и растет число ошибок и сложность (стоимость) поддержки приложения.
Язык программирования

C# 6.0 (ООП + функциональные расширения + язык запросов + асинхронные расширения).
Современный стремительно развивающийся язык, индустриальный стандарт, который изучают на большинстве курсов по программированию.
Практически неограниченный трансграничный рынок разработчиков с необходимой экспертизой.

PHP, JavaScript, Java, Python. Языки для веб-разработки, без встроенного языка запросов. За исключением Java — нетипизированные языки, ориентированные на разработку сайтов. Не позволяют делать валидацию в момент компиляции (сохранения), ошибки проверяются только в результате пробных запусков — усложнение и удорожание поддержки, снижение надежности приложения.
Стоимость разработчиков, долларов США в месяц
1088 Java
777 PHP
1049 JavaScript

* Данные по России от Trud.com на январь 2016
** Плюс к разнице в зарплатах необходимо учесть и разницу в потребном количестве программистов.

Поддержка СУБД
Родная связка с Oracle Database Enterprise Edition с максимальным использованием самых новых и мощных возможностей мирового лидера СУБД.
Объекты СУБД могут быть произвольно модифицированы для оптимизации.
Используется
— SQL, PL/SQL
— Result cache
— Read only standby
— Array binding
— Bitmap indexes
— Triggers, packages, procedures
— Context
— SKIP LOCKED
— Full text index
— Analytic functions
— CUBE, ROLLUP, MERGE
Как правило используют стандартные механизмы (драйверы для интерпретаторов языков, на которых работает CMS) соответствующей платформы (PHP, Nodejs и так далее). Иногда используется минимальная прослойка для упрощения получения доступа к БД. В отсутствие встроенного в язык разработки языка запросов используют голый SQL, как следствие нет возможности валидации запроса на этапе компиляции — растет сложность и стоимость поддержки.
Управление транзакциями

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

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

Разграничение прав доступа для групп пользователей с учетом вложенности ролей ко всем типам объектов, а так же к отдельным объектам (элементам справочников и документам) через предикативный доступ на уровне СУБД.
Защищенность данных гарантируется платформой даже при использовании прямых SQL запросов отдельно на чтение, запись, редактирование, удаление.
Сверх того, прикладному разработчику доступен параллельный механизм adhoc permissions: сколь угодно сложные логические конструкции, формулируемые самим разработчиком («удалить документ продажи может только пользователь-мужчина, Овен по знаку зодиака и только в пятницу 13-е в високосные года»). Платформа предоставляет набор методов для управления такими правами на уровне ролей пользователей с учетом иерархии и вложенности ролей.

Нет
Средства быстрой разработки и прототипирования
Прототипирование и генерация пользовательского интерфейса на основе метаданных, готовые механизмы для построения отчетов на основе метаданных
Нет
Управление версиями
Встроенная распределенная система контроля версий и управление развертыванием приложения. Позволяет в структурированном виде просматривать всю историю сделанных изменений, переносить изменения в конфигурацию для тестирования и полноценного использования, связывать изменения с запросами на изменения. Платформа поддерживает автоматическое обновление сервера приложений и клиентских приложений и контроль согласованности конфигураций. Версионирование позволяет осуществлять откат к последней стабильной версии, сокращая время простоя.
Все приложение хранится либо в виде программ в исходном коде во внешней системе управления версиями, либо в базе данных без поддержки версионирования.
Редактор печатных форм
Встроенный редактор с поддержкой встраивания компонент(карт, графиков и т.п.) с выгрузкой в PDF, HTML, Excell, RTF, PNG, JPG с поддержкой сценариев при рендеринге.
Отсутствует
Среда разработки

Integrated, полноценный IntelliSense, WinForms клиент, интегрированный с метаданными.
Произвольные наборы компонент (по умолчанию используется DevExpress).
Клиентское приложение полностью асинхронное без дополнительных расходов для прикладного разработчика.
Для упрощения взаимодействия с данными используется DataBinding.
Библиотеки компонент активно развиваются и используются в десятках тысяч проектов по всему миру. Как следствие — высочайший уровень удобства интерфейса, кастомизируемого для каждого отдельного пользователя.
Также в инструменты разработчика включены:
— поиск по истории изменений объектов и скриптов
— механизмы настройки прав
— механизмы управления настройками
— unit-tests
— механизмы верификации
— etc.

Внешние фреймворки для разработки, не связанные с метаданными.
Поддержка SOAP/REST

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

Есть, иногда детали прикрывают платформой.
Поддержка локализации

Встроенная система для локализации интерфейса пользователя, интегрированная с версионируемой средой.
Поддержка мультиязычных строк упрощает внедрение в транснациональных компаниях (название товара на разных языках, etc)

Есть, в меточных файлах
Подсистема печати

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

 

Отсутствует
Производительность

Компилируемый язык C# с JIT виртуальной машиной.
Оптимизация запросов и нативная интеграция с Oracle Database позволяют распределить нагрузку в кластере, снизить время обращения, сократить как общее время транзакции, так и срок жизни блокировки в частности.

В силу изначальной ориентированности платформ на реализацию сайтов собственно обработки выполняются быстро. Однако, для выполнения всех необходимых бизнес-правил необходима невероятно сложная реализация и структура программы. Как с ассемблером: программы на нем работают очень быстро, однако написать сколько-нибудь сложную программу на нем невозможно в силу экспоненциально возрастающей сложности. Таким образом, самостоятельная реализация на сабжевой платформе сложного и мощного функционала (для чего и нужны промышленные ERP-системы) принципиально нерентабельна, а эффективная поддержка и развитие готовых «решений» невозможна по тем же причинам.
Многопоточность
Встроенные механизмы реализации многопоточных решений с контролем транзакционной целостности.
На низком уровне, через стандартные механизмы языка разработки. Многопоточные решения крайне редки. Обработка больших объемов данных в несколько потоков затруднена.
Интерфейс пользователя

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

Сортировки, фильтры


Прокомментируем содержимое таблицы развернуто.

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

К плюсам CMS, несомненно, можно отнести простоту создания новых страниц и управления их общим стилем.

Список минусов (везде по тексту — применительно к рассматриваемой области применения — эрзац-ERP) — значительно больше.

Естественным образом, основные недостатки следуют из различий в назначении ERP и CMS.


1. Система безопасности CMS

(В лучшем случае) позволяет управлять правами на редактирование шаблонов тех или иных страниц.

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

То есть — поверх нее.

Языки программирования, предназначенные для веб-разработки (PHP, JavaScript, Python, etc), как правило, не имеют:

  • строгой типизации;
  • средств функциональных расширений;
  • языка запросов.

И это хорошо при использовании этих языков по назначению — потому что упрощает написание скриптов для сайта.

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

  • колоссальный объем работ по тестированию (стоимость), либо

  • колоссальная масса ошибок (качество).
     

2. Модель данных

В качестве модели данных (ORM — object relational mapping) либо используется прокладка, позволяющая убрать прямые SQL-запросы к СУБД, либо модель данных отсутствует в принципе.

В любом случае, полезной логики (преобразования данных, проверки прав, валидации, etc) такой «ORM» (-like!) не содержит.

Уровень эксплуатационной надежности «системы» при сколько-нибудь значительных нагрузках соответствует.


3. Управление транзакциями

Для CMS-систем, с учетом их функционального назначения, такой инструмент нужен как рыбе зонтик.

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

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

4. Поддержка многопоточности

Опять-таки, из изначального целеполагания CMS-систем вытекает практическое отсутствие поддержки многопоточности (multithreading).

Промышленные ERP-системы постоянно сталкиваются с задачами обработки больших объемов данных. Например, банальный пересчет цен для 100К+ товаров (изменение курса валюты).

Технически это обновление нескольких миллионов записей в соответствии со сложной бизнес-логикой (т.е. нельзя написать один запрос, который все разом пересчитает).

Такого объема задачи должны выполняться в несколько потоков только для того, чтобы просто дождаться результатов. Если пересчет будет длиться более суток, то какие-то товары не пересчитаются никогда.

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

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

5. Быстрое прототипирование отсутствует в принципе

Поскольку CMS-системы работают не с данными, а с объектами.

Простейшие экранные формочки списка и редактирования записей (которых тысячи в самой простой конфигурации IEM System) в ERP-like «системах» изготавливаются вручную по сверхсовременной технологии copy-paste.

Соответственно, объем прикладного кода, реализующего абсолютно одинаковый функционал, растет катастрофически («не можешь работать головой — работай руками»).

А если (когда) всплывет ошибка, код придется править в тысяче мест.

Каждый раз.
 

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

Собственно программный код ERP-подобной системы хранится в файлах на веб-сервере.

Это не является проблемой, пока ваша компания работает на единственном сервере, с которым работает единственный прикладной разработчик.

Если серверов больше одного (например, два), возникает проблема синхронизации изменений.

Иными словами, в том или ином виде появляется соответствующая подсистема. Которую тоже надо поддерживать — «кто будет контролировать контролера?».

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

Правильная же ERP-система самостоятельно заботится об управлении кодовой базой.
 

7. Формы печати.

Корпорации до сих пор много печатают.

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

Например, редактор печатных форм и систему отправки печатной формы на заданный принтер, в том числе из заданий по расписанию, вызову внешней системы и т.д. и т.п.

Никакая CMS такой функциональности не предоставляет (и не может — опять-таки в силу природы), а предоставляемый сервис ограничивается генерацией HTML страницы.

Для понимания не знакомых со сферой веб-дизайна читателей: верстка (=рисование+подготовка для веб-программиста) счета-фактуры в HTML — развлечение на день даже для опытного верстальщика. Про кошмары более сложных форм и речи нет.

Et cetera, et cetera...

При всем объеме высказанной критики в адрес героев статьи, мы вовсе не хотим сказать, что это плохой софт.

Это неплохой, а применительно к некоторым представителям семейства, — даже отличный софт.

Если его применять по назначению.

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

И даже обеих рук.

Главное, удачно выбрать «систему» из сотен готовых вариантов. Потому что дорабатывать ее — заведомо неблагодарный труд по причинам, рассмотренным выше.

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

К счастью, такие случаи достаточно редки.