Показать сообщение отдельно
Старый 05.04.2021, 10:36   #31  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от sonik Посмотреть сообщение
На мой взгляд концепция ERP, как единой монолитной системы, all in one, умирает. Я вижу тут несколько причин:
1. Растет объем данных, которые нужно анализировать бизнесу при принятии решений. Причем форматы, концепции самого бизнеса меняются очень быстро, и потоки данных все время меняются. Как следствие возрастает сложность систем для обработки этих данных.
Данных больше, процессов больше, но почему концепция умирает? Если ты про натягивание сильно возросших объемов и кучи новых процессов на зацементированную монолитную систему, внедренную пять лет назад без концепции развития, то конечно она не справится. Да и любая другая не справится без адекватной архитектуры, технологических возможностей и т.п. Тут, думаю, надо аккуратно дать определение той самой монолитной системы. Кто-то запрещает поставить две аксапты: на розничную сеть одну и на собственное производство - другую? В определении ERP однозначно сказано что нельзя операционные процессы выносить в отдельные CRM, WMS и т.п.?

Я это к чему. В таких разговорах очень часто смешивают понятие ERP как Автоматизированной системы (и тут может быть целый набор разного ПО) и конкретное ПО от того же MS. Чуть дальше из той же серии противопоставление Agile и waterfall.

Цитата:
Сообщение от sonik Посмотреть сообщение
И тут два пути:
а. Делать свои продукты, растить свою экспертизу (удел крупняка типа Сбер, Х5, Сибур),
б. Брать с рынка готовые решения для какой-то узкоспециализированной функции или новой экспериментальной фичи (мелкий, средний бизнес).
Классические ERP в обоих случаях идут мимо.
Мелкий бизнес в принципе может без ERP, но как только станет средним - начнутся проблемы. И тут опять же проблема не в конкретном ПО, а в системе. И возможность ее развития больше будет зависеть не от ПО, а от архитектуры и Архитектора, который за нее отвечает.
Крупняк делает своё, но это не гарантирует хорошего результата. И в последнее время тенденция крупняка все таки искать хоть как-то готовые продукты на рынке и вписывать в свою архитектуру, иначе даже они не успевают. Ну и зачастую видно, что их собственные монстры зашли в тупик, да. Очень хочется сделать "быстрый" вывод что Agile и продуктовая разработка не вариант

Цитата:
Сообщение от sonik Посмотреть сообщение
2. Весь прогрессивный ИТ мир перешел на agile и продуктовый подход к разработке. Это короткие итерации, компактные самоуправляемые команды, на выходе которых получаем полностью оттестированный и рабочий продукт. В системе, в которой количество жестких связей между объектами исчисляется запредельными числами, и например изменение одной строчки кода в модуле Главная книга может обрушить кучу функционала в Управлении запасами - невозможно качественно вносить изменения и применять продуктовый подход к разработке. Точнее можно, что все мы и делаем последние 20 лет. Но не с тем качеством и скоростью как в микросервисной архитектуре.
Опять смешение всего и вся Если брать утрированную версию Waterfall, то почему не берем утрированную версию Agile? Вот сидит команда и говорит, что ей год мешали работать и они свою velocity не знают, им нужно еще полгодика на расчет и потом они тебе дадут примерные сроки. Или "у нас всё работает, разбирайтесь с тем микросервисом" - не знакомая картинка?

Цитата:
Сообщение от 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 – это пилить сервис с котиками для миллиардов подростков. И лучшие умы идут туда.
Да. И в целом это касается не только ИТ. Основательная инженерия стала совсем не модной и на чем держится не понятно. Скорее всего и дальше будет разделение на "скучную но надежную и масштабируемую" инфраструктуру и "модную и легкую" фронтовую часть. И вторая будет low code или тот же AI, пишущий алгоритмы на лету с диктовки хайпового стартапера

Цитата:
Сообщение от sonik Посмотреть сообщение
Но если со временем MS сможет родить систему, которая:
1. Построена на открытых, кастомизируемых (!!!) микросервисах.
2. Покрыта автотестами по всему стандартному функционалу.
3. В которой будет out of the box оркестратор контейнеров, простой и надежный, позволяющий бесконечно масштабировать приложение горизонтально. Имеющий удобный мониторинг и визуализацию ошибок и bottle neck-ов во всем этом винегрете.
И честный CI\CD, интегрированный с таск треккером.
4. Простой, гибкий конструктор мобильных и веб интерфейсов пользователя.
5. Хорошо документированный API с брокером гарантированной доставки сообщений типа Kafka или RabbitMQ.
Это будет бомба. В принципе многие вещи в D365 в зачаточном виде уже есть, но все пока очень сыро и сложно.
Согласен. Глядя на текущие тренды от производителей, хотелки заказчиков и куда вообще идет автоматизация, думаю, мы пройдем очередной виток моды на "отдельные" сервисы и вернемся к монолитным платформам. Но внутри платформ будут те самые сервисы на любой вкус и с гарантией от поставщика платформы, что оно всё заработает вместе. По сути тот самый SAP разделенный на маленькие кусочки.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: mazzy (2), Lemming (5).