LINUX.ORG.RU
ФорумTalks

Энтерпрайз ERP/CRM фо отомейшн оф ё сириоз бизнес

 , , ,


6

2

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

https://habr.com/en/post/447162/ - Не купитесь на ERP

Сразу скажу, что я не согласен с автором, но позиция интересна. Если слегка смягчить ее, то получится что-то такое: если на вашем предприятии бардак, то ERP за вас не сможет его организовать; если же вы навели порядок на своем предприятии, то ERP вам уже особо и не нужна.

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

Подход SAP в этом плане весьма остроумен с коммерческой точки зрения, потому что работы по сверхточному нанесению пользы сам SAP не выполняет, вместо этого клепая вот такие таблички на 240 столбцов:

https://www.sapdatasheet.org/abap/tabl/mara.html

Ну или просто позволяя вам выбрать из готового набора 110 000 (сто десять тысяч) табличек те, которые подойдут вашему бизнесу... или не подойдут. Остроумен с коммерческой точки зрения такой подход потому, что с позиции человека, который не разбирается в IT, то есть, типового клиента SAP, какой-нибудь SAP R/3 предоставляет собой крупную хорошо проработанную и проверенную систему, которая покрывает чуть ли не все на свете варианты бизнес-процессов предприятия. В такие моменты я люблю вспоминать покойного Дейкстру:

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

То есть, приходит менеджер, который отвечает за принятие решений, и спрашивает у продажника SAP: «у вас есть ${фичанейм} в системе? Насколько хорошо автоматизирует ${процесснейм} ваше решение?». Причем, говорить об этом до начала внедрения — это все равно, что спрашивать у женщины «вы можете родить мальчика или девочку? А мальчик будет гениальным?». Особенно если этой женщине 50 лет и ее маркетинговое преимущество — это что оба ее сына стали успешными учеными.

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

Пока что, из моего опыта разработки CRM/недо-ERP, мне видится, что одно из ключевых препятствий на пути заполнения данной ниши — это реляционные СУБД, которые используется к месту и не к месту — просто потому, что РСУБД есть готовые в большом количестве. Как правило, даже у достаточно конкретного клиента есть ни разу не конкретные требования по автоматизации, которые меняются день ото дня, вроде «мы узнали длину члена Василия Петровича — давайте сохраним эту информацию в CRM записи про Василия Петровича, в надежде, что со временем удастся собрать аналогичные сведения по другим клиентам и вывести кореляции». Происходит это не только из-за сиюминутных прихотей конкретного менеджера, но и из-за постепенной смены коньюктуры и технологий в фирме.

Реляционная же модель приводит к тому, что когда внезапно появляется необходимость сделать связь сущностей N-к-M вместо какой-нибудь 1-к-N, то приходится перекраивать базу верх ногами, создавая новую таблицу связей между сущностями и изменяя алгоритмы создания-чтения-обновления-удаления. А в случае перехода от 1-к-1 в N-к-M нужно создавать уже две дополнительные таблицы. У того же SAP по этому поводу из коробки для целой кучи атрибутов есть поддержка множественных связей, откуда и появилось астрономическое количество табличек — в реальности таблиц корневых сущностей там всего несколько сотен.

Апгрейды, поддержка, доработка — это, между прочим, основной доход вышеупомянутой SAP. Моя воображаемая цель проста: уничтожить SAP с ораклом. По крайней мере, такова она по состоянию на момент создания треда.

Есть много опенсорсных попыток писания ERP софта (например, Odoo, OpenERP, IDempiere/Compiere/Adempiere/Openbravo/metasfresh), но каждая из них, как правило, представляет собой одну и ту же попытку повторить SAP в мелком масштабе. У меня есть некоторые абстрактные зарисовки по этой теме, но, как показывает практика, публиковать их не имеет смысла, а пытаться сделать что-то конкретное прямо сейчас у меня тупо нет времени/желания, поскольку я работаю над релизом предыдущего незаконченного проекта питоньей многозадачности. Так что принимайте эстафету.

★★★★

Ответ на: комментарий от sanyo1234

IMHO для меня синтаксис VB.NET похож на смесь Паскаля с Сишными ништяками типа объявления переменной в любом месте кода

Да, я почитал получше — это очень похоже на Oxygen.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Питон - это тоже обертка над сишечнами либами, но массово приложуху и высокоуровневую скриптоту пишут на питоне, а не на сишке? (по крайне мере в рамках сравнения Python vs C и DotNet vs С/Delphi)

Я тебе отвечаю на конкретную претензию по поводу «чего ты сравниваешь версию DevExpress для VCL с версией для WinForms». А я и ответил, что разница в самой либе там минимальна.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Я тебе отвечаю на конкретную претензию по поводу «чего ты сравниваешь версию DevExpress для VCL с версией для WinForms». А я и ответил, что разница в самой либе там минимальна.

Ну так:

1) Хотя бы управление памятью они отдали DotNet рантайму.

2) Разве они не переложили хотя бы часть своей старой работы с Quantum на плечи разработчкиков WinForms из Microsoft? Майкрософтовцы, которые пилят внутренности DotNet вероятно тоже уровнем повыше, чем скриптописатели и даже мелкие компонентоделы? Хотя конечно бывают и исключения, я про в среднем по ...

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 4)
Ответ на: комментарий от sanyo1234

Разве они не переложили хотя бы часть своей старой работы с Quantum на плечи разработчкиков WinForms из Microsoft? Майкрософтовцы, которые пилят внутренности DotNet вероятно тоже уровнем повыше, чем скриптописатели и даже мелкие компонентоделы? Хотя конечно бывают и исключения, я про в среднем по

Да, VCL просел по уровню, но у меня не было проблем от VCL — все проблемы квантумгрида были вызваны самим квантумгридом. Они там переписали все базовые контролы чуть ли не с нуля, то есть: кнопки, поля ввода, выпадающие списки, и прочее, прочее, прочее. Потому это уже не VCL и не WinForms — это DevExpress for WinForms и DevExpress for VCL, то есть, не «на», а «для».

byko3y ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.