Если бы я писал 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 бы начинал, возможно.

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

[ax_mct]

Если бы я писал ERP-систему то сделал бы достаточно глубокий анализ существующих на рынке Open-source ERP.
Если по каким-то причинам не нашел что подходит то тогда сделал бы достаточно глубокий анализ существующих на рынке программных фрэймворков.

Если же тема про "идеальную" ERP то тогда другое дело.
И тут есть еще разрез модульности. Для кого-то идеальная ERP это когда каждый модуль - независимая программа, а кто-то считает что единая база данных - суть ERP.
То есть не только вопрос горизонтального масштабирования, а еще вопрос стоит или нет делать отдельные базы для каждого модуля.

Цитата:

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

[Ivanhoe]

А зачем единая ERP система тогда? Набор сервисов, единое MDM и отчетность современными средствами (множество источников и т.п.).

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

Шестое - в чем цель?

[Logger]

Поддержу вопрос
В чем цель ?

[macklakov]

Цитата:

Сообщение от George Nordic

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

Если бы я писал ERP систему, я бы не писал ERP систему
Я бы делал платформу. Но ее уже сделали и без меня, называется Business Application Platform.

[Bobkov]

Цитата:

Сообщение от George Nordic

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

Если бы я писал "ERP систему", я бы сначала определил, что имеется в виду. Иначе будет "что такое счастье - каждый понимал по своему"
Определять лучше всего через назначение этой системы. Итак, кому и для чего нужна "ERP система"?

[George Nordic]

Вопрос чисто теоретический. "Идеальный" сферический конь в вакууме. Собираем Best Practices, смотрим в будущее... Кому что понравилось в увиденных системах. SIFT тот же.

На рынке - или закрытые, или java-писные монстры. Увы, ни у кого из нас не хватит сил написать полноценную ERP - это десятки (вернее, сотни) человеко-лет.

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

[Ivanhoe]

Давай хоть что-нибудь ограничим Целевой клиент какой?

[Sancho]

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

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

[Sancho]

и еще
про план счетов в идеальной ERP
GAAP? IAS? РСБУ?
нет.
все это надстройки, "в какой системе посмотреть изволите?"
главные внутренние книги учета должны быть в натуральных показателях:
объект учета тип такой-то код такой-то в рамках транзакции такой-то такого-то числа изменил свое состояние на 13 штук локальных валют в рамках процесса такого-то типа.

[George Nordic]

Цитата:

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

Давай хоть что-нибудь ограничим Целевой клиент какой?

Хороший вопрос. Коммерческая компания. Купил - (что-то сделал) - Продал. Дистрибуция, Производство, Ритейл... кто еще является основным клиентом? Телеком, Финансовые Организации - там больше бэк-офис... Сервисные компании, Строители... У всех есть закупки, кадры, номенклатура.. У многих - склады.

Цитата:

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

и еще про план счетов в идеальной ERP
GAAP? IAS? РСБУ?

Я не просто так про маппинг говорил. Каждая компания - живет отдельно, но транслирует в головную компанию.

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

[Ivanhoe]

Я скорее про объемы: операций, пользователей, выручки (от которой зависит платежоспособность в плане покупки ERP).

Для малого бизнеса идеальная ERP - коробка в облаке без доработок, соответствующая локальным законам и дающая нужную аналитику для управления.

Для крупняка критерии будут другие.

[egorych]

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

[George Nordic]

Цитата:

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

Никогда на моей памяти внедрение чего-нибудь не уменьшало работы операционистам! Ну как может быть работы меньше, если данных входных больше!

Вот. Поэтому и дикое сопротивление внедрению. Нафига операциониста заставлять отдел, ЦФО, фазу луны - она что, меняется у него? Да, данная аналитика нужна (например, себестоимость правильно рассчитать, а что что-то в полнолуние чудит), но зачем писать длинные инструкции - "в это красненькое поле вбей УКЛМИП-1, а вот сюда - ОТД4". Мы очень активно пользовались шаблонами записей, и заполняли все что можно с карточки сотрудника. Если сотрудника переводили в другой отдел - система запрашивала обновленные обязательные поля шаблонов.

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

[macklakov]

Цитата:

Сообщение от George Nordic

Вот. Поэтому и дикое сопротивление внедрению.

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

[George Nordic]

В Коммерции тоже бывает. Руководить 40 сотрудниками всяко приятнее, чем 4мя. И данного руководителя пройти тяжело. А наверху - у них свои задачи, им иногда и не до EPR. Но, в целом, коммерческие компании сильнее заинтересованы в оптимизации затрат, в т.ч. и на персонал.

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

[egorych]

Цитата:

Сообщение от George Nordic

Вот. Поэтому и дикое сопротивление внедрению. Нафига операциониста заставлять отдел, ЦФО, фазу луны - она что, меняется у него? Да, данная аналитика нужна (например, себестоимость правильно рассчитать, а что что-то в полнолуние чудит), но зачем писать длинные инструкции - "в это красненькое поле вбей УКЛМИП-1, а вот сюда - ОТД4". Мы очень активно пользовались шаблонами записей, и заполняли все что можно с карточки сотрудника. Если сотрудника переводили в другой отдел - система запрашивала обновленные обязательные поля шаблонов.

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

Ну это хорошо, если можно обойтись 5-ю шаблонами и все заполнить! А если их уже больше 10-20? Какой в них смысл? Опять писать инструкцию по всем возможным вариантам?
И потом - шаблоны можно удалить! Помнится у нас как-то удалили самый древний шаблон, созданный при царе горохе - пол дня был кипеш - никто не помнит что в нем было, как заполнялось и почему так а не иначе.

ps У нас Босс говорил раньше по этому поводу - "Мы систему внедряем не для удобства операторов, а для моего удобства!"

[George Nordic]

Цитата:

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

У нас Босс говорил раньше по этому поводу - "Мы систему внедряем не для удобства операторов, а для моего удобства!"

Ясно. А еще лучше - сделать систему, удобную для программиста. Кому эти пользователи нужны? Только вечно жалуются.

Но я всегда старался делать систему, удобную для пользователей. Чем она проще, тем быстрее идет бизнес-процесс и тем меньше ошибок допускают сотрудники.

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

[Sancho]

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

[ax_mct]

Цитата:

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

Если бы я писал ERP систему, я бы не писал ERP систему
Я бы делал платформу. Но ее уже сделали и без меня, называется Business Application Platform.

Неужели это?
https://businessplatform.microsoft.com/
Подавляющий результат в поиске Google.

Идеальная ERP это та которая не зависит от MS. Ни в чем.