LINUX.ORG.RU

Избранные сообщения bieming

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

Форум — Talks

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

 , , ,

byko3y
()

Удаление deb-пакетов с некорректными pre- и post-скриптами

Статьи — Администрирование

Иногда возникает ситуация (особенно на машине разработчика/мейнтейнера), когда deb-пакет нельзя ни корректно доустановить, ни удалить, поскольку сценарий prerm (postrm, preinst, postinst) содержит ошибки. Ключи в apt и dpkg, посвящённые сломанным пакетам (--force-remove-*, -f) тоже могут не помочь, поскольку в первую очередь разруливают битые зависимости между пакетами.

В этом случае эффективным может оказаться «лечение» на низком уровне. Наиболее радикальный метод предлагался на опеннете: просто зайти в /var/lib/dpkg/info и удалить все файлы package-name.*, после чего удалить упоминания о пакете из /var/lib/dpkg/status (подробности по ссылке). Однако в этом случае удалится лишь метаинформация о пакете, а вот хвосты в /usr, /etc и др. останутся, как отмечали в комментариях.

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

Далее мы заходим в /var/lib/dpkg/info и просто исправляем package-name.prerm или package-name.postrm так, чтобы он отработал корректно. Например, если в .prerm удалялся несуществующий каталог без проверки на его существование, стираем или комментируем команду удаления.

После этого, как обычно, сносим пакет средствами dpkg -r.

Перемещено hobbit из development

 , ,

hobbit
()

unblocker для госреестра

Форум — Talks

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

Пускать все подряд через VPN конечно можно, но не рационально.

 

Vit
()