LINUX.ORG.RU
ФорумTalks

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

 , , ,


5

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

★★★★

первое правило разработки ERP - никогда не занимайся разработкой и внедрением ERP :)

Harald ★★★★★
()

Я в одной своей конторе EspoCRM использую. Очень удобная, лёгкая и простая штука, позволяет легко допилить нужное, если чуть-чуть соображаешь в БД и вебне. Всем использующим нравится, после говнобитриксCRM все беземерно счастливы.

В общем, это несложная OpenSource CRM, дефолта которой вполне достаточно для какой-то распространённой в мелком и среднем бизнесе деятельности, но у неё есть относительно низкоуровневый конструктор кастомных таблиц и их представлений. Низкоуровневость позволяет навертеть практически что угодно, и связать что угодно с чем угодно. Но это одновременно и недостаток, произвольный юзер, незнакомый минимально с концепциями БД хрен там что сделает, даже несмотря на достаточно удобную вебморду для конструирования. Впрочем, это лечится объяснением что такое БД и с чем её едят.

Не знаю насчёт уничтожения SAP, это ещё тот невменяемый монстр, но вот ублюдочный БитриксCRM эта штука уничтожает однозначно. Даже чисто одним только отсутствием тормозов и вменяемыми и простыми настройками.

В общем, рекомендую глянуть, в смысле принципа построения конструктора в этой штуке. Мне понравилось как это сделали в Espo.

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

первое правило разработки ERP - никогда не занимайся разработкой и внедрением ERP

Ты знаешь, со моим складом ума перспектива поглощения и переработки самой разнообразной информации умеренной говнистости выглядит неплохо. Конечно, с каким-то тупым кассиром общаться нет смысла — обычно грамотные внедряльщики предпочитают сами поработать какое-то время на этом месте, или хотя бы проследить за фактической работой. Потому что кассир или вахтер сидит на своей должности не благодаря выдающимся способностям систематизации и передачи информации другому человеку. Я вот поработал программистом с разными менеджерами-аналитиками, и прям весьма остро пронаблюдал разницу между человеком, который пытается разобраться в своей работе, и человеком, который выполняет работу в стиле «отстаньте от меня уже». У последнего довольно бесполезно что-то спрашивать, потому что он сам толком не понимает, что и почему происходит.

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

после говнобитриксCRM все беземерно счастливы

Вот тут помедленнее, пожалуйста. Я знаю контору, которая не серьезных щах реализует проприетарную CRM, копируя битрикс. Ну типа «у них получилось — и у нас получится». Почему же «говно-»?

Но это одновременно и недостаток, произвольный юзер, незнакомый минимально с концепциями БД хрен там что сделает, даже несмотря на достаточно удобную вебморду для конструирования

Самое фуфлыжное внедрение начинается от тысяч долларов. За такие деньги можно найти фрилансера, минимально знакомого с концепциями БД, и его руками сделать структуру табличек. Если у фирмы нет нескольких тысяч долларов, то ей и не нужно CRM.

Не знаю насчёт уничтожения SAP, это ещё тот невменяемый монстр, но вот ублюдочный БитриксCRM эта штука уничтожает однозначно. Даже чисто одним только отсутствием тормозов и вменяемыми и простыми настройками

Загадка века — почему битрикс и SAP безбожно тормозят. Причем, даже в интерфейсе, а не в запросах к базе. Такое ощущение, что чем больше капитализация проекта, тем хуже техническое исполнение.

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

Почему же «говно-»?

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

За такие деньги можно найти фрилансера, минимально знакомого с концепциями БД, и его руками сделать структуру табличек.

Да, тоже вариант. Причём если фрилансер объяснит что он делает какому-нибудь вменяемому сотруднику, то сотрудник и сам сможет запиливать какие-то нужные по ходу дела штуковины.

Загадка века — почему битрикс и SAP безбожно тормозят. Причем, даже в интерфейсе, а не в запросах к базе. Такое ощущение, что чем больше капитализация проекта, тем хуже техническое исполнение.

Такое впечатление, что и та и другая хрень писались без какой-то концепции. Т.е. по мере написания фичи, свистелки и перделки добавлялись костылями без какой-либо системы или плана. «Добавляем срочно вот такую фичу!!!» - разумеется изначально никто не предусмотрел, что такая фича может понадобится, и никто даже не попытался посмотреть, можно ли уже существующий код задействовать - и всё это пишется как придётся, лишь бы внешне соответствовало ТЗ.

Загляните в EspoCRM и сравните с битриксом. Обе написаны на похапе/SQL/JS. Разница просто огромна.

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

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

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

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

Такое впечатление, что и та и другая хрень писались без какой-то концепции. Т.е. по мере написания фичи, свистелки и перделки добавлялись костылями без какой-либо системы или плана. «Добавляем срочно вот такую фичу!!!» - разумеется изначально никто не предусмотрел, что такая фича может понадобится, и никто даже не попытался посмотреть, можно ли уже существующий код задействовать - и всё это пишется как придётся, лишь бы внешне соответствовало ТЗ

Да, ты прав в том, что оно писалось бездушными менеджерами для впаривания, а не для души. Однако, «добавляем срочно фичу» — это реалии компьютерной системы предприятия. Пришла какая-то новая железяка, вроде платежного терминала или сканера штрих-кодов — нужно встроить ее в систему. Интеграция того же SAP, бывало, проваливалась из-за того, что терминал не выдавал региональной информации, и в итоге в базе оказывалась какая-то малоинформативная хрень, из-за которой отваливались штатные модули планирования. В итоге нужно было либо переделывать все терминалы, либо половину самой SAP, а делать этого никто не будет.

Возможно в одном случае люди писали для себя, в охоточку и неторопясь, чтобы красиво было, а во втором - из-под палки за зарплату зависящую от количества строк

Ну это точно нет, пишут там повременно и за фичи... я надеюсь. Я уже на фоне того кошмара ничему не удивлюсь.

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

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

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

В той же Espo, когда понадобилось сделать компиляцию свежей версии софта для конкретного железа определённого клиента, я сделал это не напрягаясь за пару часов вместе с чтением документации. Написал строк 100 наверно. Причём никаких костылей в коде самой CRM не понадобилось вообще - всё в отдельных новых файликах в custom директории. В вебморде открываешь клиента, его железо, жмёшь кнопку «Собрать ПО», на серваке фоном запускается процесс компиляции (make и всё такое), можно заниматься другими делами, через некоторое время у клиента появляется в файлах инсталляшка со свежей софтиной. Можно сразу на почту отправить оттуда же. Юзеры счастливы, меня никто не достаёт «собери апгрейд для ООО Вектор», в общем, workflow успешно оптимизирован минимальными усилиями. Как сделать то же самое в битриксе я просто не представляю.

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

Если создатель подобной системы заранее не предусматривает возможность «добавления срочно фичи», то это как минимум странно. Или же создатель заведомо планирует разводить клиентов на бабло за «добавление срочно фичи».

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

Почему же «говно-»?

Вот ещё что вспомнил, вроде фигня, а на самом деле очень бесячая штука - в битриксе за каким-то хреном везде понапиханы какие-то совершенно неуместные анимации, мыргалки, блямкалки и пр. которые ещё и хер выключишь. Человеку работать надо, а приходится смотреть как это анимированное говно мыргает и блямкает перед тем, как что-то сделать.

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

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

шаг в сторону от «концепции» приводит к необходимости кучи костылей

Вот два чая. Фичи делаются «чтоб было», чтобы можно было при окучивании клиента сказать, что есть, а в реале чуть шаг в сторону, и фичей нельзя пользоваться. Еще и все забаговано страшно.

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

О продуманности свидетельствует то, что не все сотрудники могут сами там зарегистрироваться, некоторым надо помогать.

goingUp ★★★★★
()

byko3y ★★  любитель хазина

Учитывая это, читать твой бред нет никакого смысла

zgen ★★★★★
()

весьма тяжело найти тот самый общий знаменатель, который подошел бы всем и при этом не ограничивал бы никого

  1. Всё на джаве
  2. UI фреймворк на базе HTML/CSS с возможностью гибкой кастомизации шаблонов на клиенте
  3. Гибридная СУБД со схемой домена напрямую завязанная на джава классы для отслеживания всех нарушений схемы и запросов к БД через IDE в реальном времени
  4. Всё остальное в модули, где каждая индустрия сообща находит общий знаменатель схемы и бизнес логики, а затем уже кастамизирует под свой уникальный случай через ООП.
foror ★★★★★
()
Ответ на: комментарий от goingUp

Такое впечатление, что разные части Битрикса пилят разные отделы, которые друг с другом посрались и кодом не обмениваются, в разных частях админки разные виджеты

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

Проблема не только в «посрались», а и в том, что задача обозначения общего знаменателя здесь — ответственная и творческая, но не такая сложная, как реализация конечной интегрированной системы. По этой причине в плохо организованных/набранных коллективах очень часто эту наиболее ответственную задачу на себя берут самые бездарные, потому что квалифицированный кодер сразу видит проблемы, а бездарь — не видит их, потому сразу лепит архитектуру, которая, как правило, оказывается ни к селу ни к городу. В итоге, как ни странно, самый простой выход из этой ситуации — чтобы каждый использовал свои виджеты.

О продуманности свидетельствует то, что не все сотрудники могут сами там зарегистрироваться, некоторым надо помогать

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

У меня складывается такое ощущение, что в последнее время крайне сложная регистрация стала нормой для веба. Ух, помню, пытался зарегаться на сайте оракла, чтобы скачать JDK — пукан погорел знатно, будто регаюсь на сайте какой-то госконторы с их знаменитым «пароль должен быть минимум из 16 символов, и обязательно должен включать в себя строчные и прописные буквы латиницы, цифры, и иероглифы китайского алфавита».

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

1. Всё на джаве
2. UI фреймворк на базе HTML/CSS с возможностью гибкой кастомизации шаблонов на клиенте

В первых двух пунктах ты звучишь как эффективный менеджер. Не хватает только перед ними добавить «проект должна реализовывать команда высокомотивированных программистов» и «нужно поставлять заказчику ценное ПО с минимальными задержками».

Гибридная СУБД со схемой домена напрямую завязанная на джава классы для отслеживания всех нарушений схемы и запросов к БД через IDE в реальном времени

Уже придумал как собираешься апгрейдить схему базы?

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

При сложных модификациях схемы пишутся миграционные скрипты. Другого ничего не придумали. И не придумают.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 2)
Ответ на: комментарий от no-such-file

Зачем так далеко ходить? Начни с малого, уничтожь 1С

Ты знаешь, я даже не понимаю, кто пользуется 1С. Видимо, каким-то образом я так ювелирно обошел мимо тех людей, которые бы могли им пользоваться. Зато знаю чела, который на заводе рено в экселе «программирует». Так что про 1С я знаю только из страшилок про запросы на десять экранов. Оно живо вообще? Чем лучше экселя?

byko3y ★★★★
() автор топика

Моя воображаемая цель проста - засадить яблонями Bенеру. Но поскольку сейчас мне надо идти кормить кур, принимайте эстафету.

Краткая суть этого выпуска.

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

При сложных модификациях схемы пишутся миграционные скрипты. Другого ничего не придумали. И не придумают

Написали скрипт, мигрировали. Через день-два приходят из цеха и ревут — побились данные по каким-то там технологическим операциям. Поднимают бэкап, и дальше в любых раскладах система либо уходит в read-only, либо вообще умирает на некоторое время, пока идут работы.

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

На DB2 когда-то ACID так и реализовывали: нужно сделать аналитический запрос — останавливаешь работу системы, читаешь значения, продолжаешь работу. Сервак упал — работа продолжается, потом как-нибудь когда-нибудь внесем изменения. Соответственно, такая штука вполне себе заработает и на MyISAM, и на древней монге.

А нынче, с учетом моды на распределенные системы, durability аспект вообще встает под вопросом, хотя бы потому, что не существует способа для двух узлов, выполняющих транзакцию, зависящую от успеха транзакции другого узла (например, двухэтапная транзакция) когда-либо закончить эту транзакцию атомарно. То есть, эти два узла будут бесконечно спрашивать друго друга «ты точно внес транзакцию, тогда я тоже вношу, о чеми и сообщаю», а второй узел отвечает «да, я внес, ты тоже вноси, и я внесу у себя подтверждение что ты внес» — и так бесконечно, потому что в любой момент соединение рвется и узел не знает, дошло ли подтверждение подтверждения до другого узла. Вроде двух болтушек, которые не могут решить, кому из них первым повесить трубку.

То есть, процесс работы распределенной базы представляет собой бесконечную синхронизацию, уточнение и подтверждение соответствия данных между узлами, почти как в модели «eventual consistency» — так зачем было тужиться с ACID, когда никакой атомарности нету?

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

После миграции создавай и запускай тесты. Не используй распределенных СУБД, если у тебя не гугл.

При добавлении одного поля миграция не нужна.

Ну и везде используй джаву и IDE, если не хочешь проблем со своей питоньей скриптотой.

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

Чем лучше экселя?

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)

А что достопочтенные доны скажут о http://www.tryton.org/ или https://erpnext.org/ ? Мне нужно было для нестандартного решения, для технического обслуживания и поигравшись я выбрал erpnext, потому что смог сварганить из него то что нужно не прибегая к программированию как к таковому. Но я ненастоящий сварщик и интересно, насколько оно жизнеспособно в той среде для которой написано?

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

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

Ну и везде используй джаву и IDE, если не хочешь проблем со своей питоньей скриптотой.

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

foror ★★★★★
()
Ответ на: комментарий от no-such-file

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

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

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

https://erpnext.org/ ? Мне нужно было для нестандартного решения, для технического обслуживания и поигравшись я выбрал erpnext, потому что смог сварганить из него то что нужно не прибегая к программированию как к таковому. Но я ненастоящий сварщик и интересно, насколько оно жизнеспособно в той среде для которой написано?

Я не стал копать дальше под ERPNext, потому что мне не понравилась класическая БД. Много кто упирается в эту же проблему при росте масштаба. Да, графики красивые, готоая телефония и трекинг, но когда поток данных растет, а база одна, то тормозить уже начинает не GUI, а сама база, особенно при расчете графиков и табличной статистики за большие периоды времени. Или даже хотя бы тупо глобальный текстовой поиск. Даже не сильно крупная фирма может иметь сотни тысяч клиентов и миллионы заказов. Потому что крупная имеет сотню тысяч заказов В ДЕНЬ. А теперь прикинь, каково будет найти в этом деле заказы к некоторой группе названий товаров?

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

Везде. Я пока что не видел иных отзывов.

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

Потому что крупная имеет сотню тысяч заказов В ДЕНЬ

Ты же говорил для малого бизнеса? У нас была мелкая контора, часть большой, но ни там ни там небыло автоматизации и эксель головного мозга. Но довольно интересная ситуация - куча проходного народа, который обучался, получал струмент, отправлялся в командировки и сеть цехов в которых работа сменялась по три раза в день. Когда я поставил контроль над происходящим - я был горд собой. Но чтобы данные были актуальными вайзерам нужны были планшеты, чтобы вовремя отмечать и следить. Прикинь, всё упёрлось в покупку четырёх планшетов... Самых дешёвых... без них всё опять скатилось в заполнение екселей вечером, после работы. Обезьянам гранаты не нужны. Но мне очень понравился пиковый момент, когда всё работало как часики и я смог вернуться к своим прямым обязанностям.

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

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

Вот. Всё сводится к тому, что работа происходит IRL, а система автоматизации там — третья нога, потому что не упрощает, а усложняет работу. И только когда через это усложнение удается в конечном итоге получить упрощение в глобальном масштабе — тогда внедрение можно считать успешным. В идеале про компьютерную систему сотрудники вообще ничего не должны знать.

byko3y ★★★★
() автор топика

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

С чего бы это? В ERP всегда есть случаи, когда нужно M:N

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

Оно сильно живо.
И CRM в ней был лет 20 назад. С интеграцией с ККМ, картами лояльности и управлением складом.

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

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

С чего бы это? В ERP всегда есть случаи, когда нужно M:N

Я не понял вообще, к чему была фраза. Что «это», когда «всегда», какие «случаи»? Изобилие связей N-к-M и является причиной адово переусложненный схемы БД в том же SAP. И еще более переусложненных запросов, потому что представь себе запрос, который нужен для создания новой сущности в таблице материалов:

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

Я сам в итоге примерно с такими запросами и работал. Даже простое чтение с трудом влезало в экран 1920х1080. Теперь ты знаешь, почему SAP тормозит. А нет, не знаешь — даже такие запросы могут быстро бегать.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от Shadow

Оно сильно живо.
И CRM в ней был лет 20 назад. С интеграцией с ККМ, картами лояльности и управлением складом

Да там много чего пытались притянуть, но в итоге востребована только бухгалтерия и ЗП, и то из-за того, что там из коробки встроено рашкинское законодательство. В остальном руководители берут 1С потому что все берут 1С. Ниша не такая уж большая, особенно в СНГ, особо не развернешься. Некоторые одинэсные барыги рассказывают, что за три часа можно легко сделать систему для ларька, но правда жизни в том, что ларек прекрасно справляется без 1С, и без экселя, и даже вообще без компьютера. У нас в регионе есть контора, которая ищет 1С программистов и отправляет работать на московские фирмы. Но не на местные. Потому что здесь никому не нужен 1С. Вообще никому.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от Shadow

Ты описал odoo, но на java, например

Ты упустил нить дискуссии. Odoo очередное ненужно. Почему? Потому что тяжело и дорого кастомизируется на конкретном клиенте.

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

Даже не сильно крупная фирма может иметь сотни тысяч клиентов и миллионы заказов. Потому что крупная имеет сотню тысяч заказов В ДЕНЬ.

У тебя сегодня есть суперкомпьютеры стоимостью до 50к USD. На одном сервере у тебя могут быть 512 ядер и десятки терабайт оперативки для обслуживания сотен тысяч клиентов в реальном времени на сотнях Гбит/с ethernet. Я уже не говорю об nvme размером в петабайты при желании.

Другой вопрос, что на таком монстре в лучшем случае запустят 1с под офтопик, которые в паре просрут все полимеры этого железа.

Сейчас просто нет конкурентов и в эту нишу можно приходить с головой и уложить всех на лопатки.

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

У тебя сегодня есть суперкомпьютеры стоимостью до 50к USD. На одном сервере у тебя могут быть 512 ядер и десятки терабайт оперативки для обслуживания сотни тысяч клиентов в реальном времени на сотнях Гбит/с ethernet. Я уже не говорю об nvme размером в петабайты при желании

Cerebras CS-1 содержит 400 тысяч ядер и 18 Гб L1 кэша. Правда, на рядовой сервер всё равно упрется в оперативу и накопители.

Мейнфреймы с терабайтами памяти — это уже сотни тысяч долларов. Потому что одна плашка памяти DDR4 128 Гб с ECC обойдется тебе примерно в 2000$ — 50к$ там в лучшем случае будет одна оператива. Обычный процессор это не потянет, нужна многопроцессорная система.

Другой вопрос, что на таком монстре в лучшем случае запустят 1с под офтопик, которые в паре просрут все полимеры этого железа

1C не может поднять даже одиночную аптеку, это вообще не игрок на рынке — только ларьки на нем и автоматизировать.

Сейчас просто нет конкурентов и в эту нишу можно приходить с головой и уложить всех на лопатки

Ты уже осваиваешь нишу? Я вот осознал, что давно «осваиваю», только совсем не с той стороны, а зря. Вот, решил перейти на другую сторону.

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

О нет, эта система заставляла придерживаться плана. Как было до этого?

- Где у тебя работает такой-то? Мы собираемся переворачивать ферму, надо будет его, он лучше всех варит.

-- Не знаю, я его сегодня даже не видел, я в другом цеху работаю.

И все начинали бегать, искать такого-то, а потом оказывалось, что его аппарат сегодня не фурычит, он его в починку отдал и т.д. работа стопорится, ведётся скачкообразно и ещё хуже. Это был атъ. Директор на каждом заседании давал разнос за то, что начальство вообще не представляет чем занимаются работники и даже когда сдавать проект. С этой системой на компах всё сразу стало ГОРАЗДО глаже, но нужен был носимый, дешёвый, легкозаменяемый планшет, чтобы не бегать к компу и всё встряло. Ну и один вайзер, которому эта система мешала ездить халтурить к соседям, рогами в землю упёрся, и планшетов нет этот крендель работает по своему, остальные потмхоньку начинают по старинке работать... Тьфу.

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

1C не может поднять

Сижу сейчас в одной конторе, в которой с 90-страшного года работает 1С77 в самописной конфигурации. Т.е. «1С, как СУБД в первоначальном смысле: Средство Управления Базами Данных».

Видимо, на чём умел писать программист в 90-страшном году, на том и написал.

И всех всё устраивает. Уже месяц у них сижу, разбираюсь. И, кажется, всё идёт к тому, что выдам резюме: «и не надо вам ничего менять, раз все счастливы от того что сейчас есть».

---------

За аптеками и МДЛП приглядваю в другой конторе. И ваяют, и ваяют. И моднее, и моднее. И как нихрена толком не работало, так и не работает.

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

DDR4 128 Гб с ECC обойдется тебе примерно в 2000$

10 штук - 20к usd. Вот тебе теребайт оперативки, остальное потратишь на процессор и nvme. 50к usd это условная цифра. Понятно, что где-то это будет 100к usd, а где-то 25к usd.

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

Обычный процессор это не потянет, нужна многопроцессорная система.

Ставишь два эпика и всё потянет. И не забывай, на подходе еще более мощные системы для розничного рынка.

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

тяжело и дорого

Странно, я буквально на коленке openerp 7 кастомизировал. Внедренцы из Литвы в опенсорс выложили тогда шаблонизатор первички для OpenOffice, что вообще зарулило всё что можно.

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

Сижу сейчас в одной конторе, в которой с 90-страшного года работает 1С77 в самописной конфигурации. Т.е. «1С, как СУБД в первоначальном смысле: Средство Управления Базами Данных»

Здесь MS Access было бы выше крыши. Среди простых СУБД у 1С очень серьезная конкуренция, и 1С там далеко не самый заметный игрок.

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

Ставишь два эпика и всё потянет. И не забывай, на подходе еще более мощные системы для розничного рынка

Два EPYC 7713 обойдутся в 14k$.

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

В остальном руководители берут 1С потому что все берут 1С

Нет, немного не так. Да, мне всегда везло на адекватных руководителей, но...
Смотри, конечно, у всех есть 1C Бухгалтерия. Логично, туда же подтянуть управление складом.
У АДЕКВАТНЫХ руководителей на этом месте прекращается взаимодействие с внедренцами и происходит найм 1С разработчика, часто на удалёнке парт тайм. И часто дорогого разработчика, давно переросшего внедренцев. И конфигурация уже становится самописной, если разработчик хороший(=дорогой) - сохраняет совместимость с обновлениями первичной документации.
Видел даже реализацию двойной бухгалтерии. Называлось «система управленческого учёта».

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

Изобилие связей N-к-M

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

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

Смотри, конечно, у всех есть 1C Бухгалтерия. Логично, туда же подтянуть управление складом

Согласен, кроме этого пункта. У кого «у всех»? Далеко не у всех. В россии всего состоянию на 2016 год ИП и юрлиц по 4 млн, то есть, 8 млн в сумме. Всего у 1С около миллиона внедрения за всё время, большая часть из них — это ООО или ИП на 1-5 сотрудников, и значительная часть уже не функционирует. Какая доля из них мертва? Я подозреваю, что в связи с событиями последних лет уже больше половины. На 200 тысяч внедрений — только 20 внедрений в крупные организации (30+ сотрудников):

https://1c.ru/solutions/public

По сути, когда ты разрабатываешь собственное решение с применением 1С, то там уже недалеко и до того, чтобы 1С просто болталась сбоку, а большую часть работы делал самописный код, напрямую работающий с базой.

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

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

Так ты в чем-то со мной не согласен, или как? Я писал в исходном сообщении о том, что реляционная модель данных негибка, и потому реляционная модель данных, построенная «с запасом», оказывается намного сложнее, чем аналогичная модель на СУБД с гибкими связями между сущностями, вроде того же постгреса, где можно в поля таблицы совать сложные объекты.

Я вообще, на самом деле, пока что сижу и удивляюсь: почему же это реляционная модель оказалась настолько популярная и заезжена? Даже та же монга в итоге из key-value превратилась в реляционную, где роль кортежей (строки таблицы) выполняют сочетания индексов, вычисленных для изначально одного значения-документа со сложной структурой и гибкой схемой.

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

Твои расчёты никак не прокомментирую.

А вот

напрямую работающий с базой

ты сильно не прав. 1С при всём её SQL синтаксисе имеет «регистры» с состоянием по времени. На стороне базы это выглядит как какой-то ад с кучей связей. Поэтому ни один нормальный пейсатель кода сбоку от 1С не будет отказываться от передачи данных через механизмы 1С.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от byko3y

Я не согласен, что модель данных «с запасом» в большинстве случаев сильно сложная, и что в ERP ей следует предпочесть данные-объекты.

сижу и удивляюсь

Бюрократия по своей природе реляционна.
И есть мнение, что при всей кажущейся неэффективности, в сочетании с IT даёт достаточную управляемость и комфорт, как ни что другое.

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

1С при всём её SQL синтаксисе имеет «регистры» с состоянием по времени. На стороне базы это выглядит как какой-то ад с кучей связей. Поэтому ни один нормальный пейсатель кода сбоку от 1С не будет отказываться от передачи данных через механизмы 1С

По факту, отказываться не будут, а вот дополнять прямым доступом штатные механизмы — будут:

https://expert.chistov.pro/public/1130066/

Ну типа у того же SAP внутренние схемы тоже не сахар — это неизбежное следствие для сложной структуры данных.

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