Если бы я писал ERP-систему

[George Nordic]

Коллеги, день добрый. Просто мыслей много накопилось на эту тему. Присоединяйтесь, будем в этой ветке их складировать. Возможно, разделим на несколько - Сервер приложений, Распределенная БД, Язык и интерфейс.

Про данную тему напомнил Юра:

Цитата:

Сообщение от macklakov

ERP обычно внедряют для того, чтобы повысить управляемость конторы в целом, а не для повышения эффективности операционистов (которого обычно не происходит). ERP это, своего рода, лекарство от болезней роста. Управляемость же достигается за счет консолидации информации, позволяющей строить разноплановую отчетность в реальном времени... Менеджмент хочет видеть что у них в конторе творится. Т.е. если у на то пошло, то пляска идет даже не от базы, а от построителей отчетности.
... Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться.

Действительно, мы забываем, а зачем мы в ERP все данные заталкиваем? Да чтобы их потом извлекать. Иначе зачем мы их туда пишем? Поэтому очень важно, чтобы DB имела ясную и простую структуру в RDB + извлекала необходимые данные в MPP (поколонку) для отчетов. Тем самым я бы разделил процессы записи и извлечения информации.

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

Третье - Внедрение системы должно разгружать операционистов, а не грузить их дополнительной работой. Система должна позволять гибко настраивать автозаполнение всевозможных аналитик, и заполнять все по возможности в автоматическом режиме. И следить, чтобы при изменении роли пользователя (переход на другую должность или в другой отдел) система просила обновить значения - отдел, ЦФО и т.п. И при делегировании - тоже что бы все корректно заполнялось.

Четвертое - Роли и безопасность. Необходимо сразу предусмотреть интеграцию с LDAP-системой (например, MS AD), и удобство администрирования прав пользователей.

Пятое - интерфейс. Ну, мы живем в 21 веке, так что "морду" я бы писал на HTML 5. тот же SalesForce - очень крут - запоминает последние значения и т.д. очень много мелочей, которые делаю работу с системой очень приятно. Еще - крупное ->детализация: Сначала просматриваем (вводим) основную информацию - потом идем к деталям. Да, все должно автоматом масштабироваться, интерфейс - на разных языках. Для этого идеально подходит механизмы EDT и меток в DAX.

Шестое - распределенная BD. Система, по большому счету, будет представлять из себя хранение данных + шину данных. И маппинг. Т.е. возможность множества небольших инсталляций с возможностью взаимодействия - заказ в одном центре отразиться в другом (или в WMS), консолидацией (один инстнас собирает данные за день с других инстнансов, или просто сгруппированные чеки, а детали лежат в отдельной POS-системе). Мапинг - чтобы собирать финансы в одном иснстансе с других, по некоторым правилам.

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

Восьмое - это контроль за подобными разработками и "накатыванием" на сервер приложений: версионность, слои и т.д.

Девятое - централизация управления НСИ. Очень важно, если мы хотим получить более-менее чистые данные. Проверка на уникальность (клиента, например), корректность ввода адресов и т.д. Возможность ввода "черновика" с последующей заменой "чистыми" данными. Один ввел - кто-то ответсвенный одобрил, после чего заполнился "золотой" справочник. Возможность репликации справочников.

Десятое... Трех звенка, это очевидно. Пользователь - на HTML 5, не должно быть зависимости от DB (что, возможно, исключает использование хранимых процедур).. но новые технологии, hadoop и все такое.. кто знает какие изменения произойдут в DB скоро. Возможно, стоит сразу присмотреться к big data DB. Таким образом, основная разработка - это движок сервера приложений (балансировка? или бить на инстансы?), модель / структура базы данных, код - как будет писаться само приложение, как оно будет исполняться... Язык - не принципиально ООП. Что-то распространенное, по синтаксису похожий на С или Delfi - что сейчас народ лучше знает. Но чтобы можно было по шагам отследить, что и куда пишется. Да, дебагер еще!

Структура журналы -> разноска (остается в модуле) -> трансляция в ГК - очень хороша. Все идет в виде черновиков, потом фиксируется (разносится в журнал). Черновик переходит в архив (можно будет поднять при аудите историю изменений), в журнале - фиксированные данные, которые можно транслировать дальше. Вообще - архивирование тоже надо продумать. Как и интеграцию с почтовыми клиентами. Я бы с CRM/BPM бы начинал, возможно.

С Уважением,
Георгий