|
05.04.2021, 10:36 | #1 |
Участник
|
Цитата:
Сообщение от sonik
На мой взгляд концепция ERP, как единой монолитной системы, all in one, умирает. Я вижу тут несколько причин:
1. Растет объем данных, которые нужно анализировать бизнесу при принятии решений. Причем форматы, концепции самого бизнеса меняются очень быстро, и потоки данных все время меняются. Как следствие возрастает сложность систем для обработки этих данных. Я это к чему. В таких разговорах очень часто смешивают понятие ERP как Автоматизированной системы (и тут может быть целый набор разного ПО) и конкретное ПО от того же MS. Чуть дальше из той же серии противопоставление Agile и waterfall. Цитата:
Сообщение от sonik
И тут два пути:
а. Делать свои продукты, растить свою экспертизу (удел крупняка типа Сбер, Х5, Сибур), б. Брать с рынка готовые решения для какой-то узкоспециализированной функции или новой экспериментальной фичи (мелкий, средний бизнес). Классические ERP в обоих случаях идут мимо. Крупняк делает своё, но это не гарантирует хорошего результата. И в последнее время тенденция крупняка все таки искать хоть как-то готовые продукты на рынке и вписывать в свою архитектуру, иначе даже они не успевают. Ну и зачастую видно, что их собственные монстры зашли в тупик, да. Очень хочется сделать "быстрый" вывод что Agile и продуктовая разработка не вариант Цитата:
Сообщение от sonik
2. Весь прогрессивный ИТ мир перешел на agile и продуктовый подход к разработке. Это короткие итерации, компактные самоуправляемые команды, на выходе которых получаем полностью оттестированный и рабочий продукт. В системе, в которой количество жестких связей между объектами исчисляется запредельными числами, и например изменение одной строчки кода в модуле Главная книга может обрушить кучу функционала в Управлении запасами - невозможно качественно вносить изменения и применять продуктовый подход к разработке. Точнее можно, что все мы и делаем последние 20 лет. Но не с тем качеством и скоростью как в микросервисной архитектуре.
Цитата:
Сообщение от sonik
3. Пока в основе ERP лежит единая БД под управлением классической реляционной СУБД, это будет ограничивать сверху возможности масштабирования вычислительной мощностью основной ноды СУБД (SAP в своей СУБД HANA пытается решить эту проблему через технологию scale out). А объем данных, используемых для принятия решений будет только расти, и эта проблема вскоре возможно коснется и средних по размеру компаний.
Посмотрите, что бедным саперам в Х5 приходится переживать https://habr.com/ru/company/X5RetailGroup/blog/432412/ Они сейчас дышать боятся на их SAP. Естественно речи о том, чтобы в нем сейчас реализоывать новые проекты (например маркировки, прослеживаемости) даже не идет. Иначе все точно встанет колом. Цитата:
Сообщение от sonik
Так что MS то в принципе идет в правильном направлении, но как всегда какими то очень окольными путями ))) Причем я думаю, у них реальные проблемы с сильными архитекторами и разработчиками. За последние 10 лет рынок ИТ для B2C вырос кратно, если не на порядки. И сейчас стало не модно идти в разработку для B2B. ИТ B2C рынок высосал все лучшие кадры. Все хотят разрабатывать софт для миллиардов людей, а не жалких сотен тысяч компаний То же самое кстати касается внедренцев, которые идут в консалтинг. Раньше у выпускников топовых вузов был магнитом антураж консультанта SAP в галстуке и лакированных ботиночках, который делал революцию на советских заводах с зоопарком из самописных программулин из 80-ых. Теперь sexy – это пилить сервис с котиками для миллиардов подростков. И лучшие умы идут туда.
Цитата:
Сообщение от sonik
Но если со временем MS сможет родить систему, которая:
1. Построена на открытых, кастомизируемых (!!!) микросервисах. 2. Покрыта автотестами по всему стандартному функционалу. 3. В которой будет out of the box оркестратор контейнеров, простой и надежный, позволяющий бесконечно масштабировать приложение горизонтально. Имеющий удобный мониторинг и визуализацию ошибок и bottle neck-ов во всем этом винегрете. И честный CI\CD, интегрированный с таск треккером. 4. Простой, гибкий конструктор мобильных и веб интерфейсов пользователя. 5. Хорошо документированный API с брокером гарантированной доставки сообщений типа Kafka или RabbitMQ. Это будет бомба. В принципе многие вещи в D365 в зачаточном виде уже есть, но все пока очень сыро и сложно.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: mazzy (2), Lemming (5). |