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.

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

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

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

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

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

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

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

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