Хорошая статья. ERP проекты одни из самых сложных. Особенно когда в меняется старая ERP которая критична для обеспечения непрерывности бизнеса и работает в режиме 24*7 с аптаймом 99,99%.
Автору спасибо - очень качественная статья. Замена ERP это реально искусство хождения по минному полю. Особенно если, менять "Большим взрывом". Сейчас ведем проект замены ERP в дочке ГазПрома по методологии Parallel Running, темп вывода в прод ровный, уровень стресса приемлемый (во всяком случае без героизма).
Это нормальная практика, часто один и тоже человек выполняет функции и ВА и СА.
Ему в помощь могут дать технаря, если Заказчик требует сделать, нечто мудреное ( типа системы «автоматического планирования перевозок» ).
Если же предметная область Заказчика очень сложная, то в помощь дадут того хорошо этот бизнес знает (например банковское дело)
у нас компании есть следующее разделение:
БА — обязан понимать as-is бизнес заказчика и уметь сформировать бизнес требования. Здесь ему часто нужна помощь СА ибо заказчик может попросить «из соломы небоскреб построить»
СА — на основании бизнес требований должен спроектировать to-be solution, то есть как требуемый функционал будет реализован с точки зрения пользователя (какие экраны, логика расчетов и прочее). Здесь СА часто требуется помощь TechLead.
ПС
Часто один и тот же человек выполняет роль и БА и СА
Думаю более точное название статьи «CUBA. Механизм кастомизации продуктов» , так как с точки зрения бизнеса это релевантно именно для продуктов. В случае когда:
— есть 100 заказчиков, использующих продукт и для которых сделаны доработки.
— пришло время переводить их на новую версию.
Возникают вопросы объединения новой версии и доработок, вот здесь то этот механизм и очень полезен, так как избавляет от необходимости делать объединение кода в ручную.
Интересный подход, при случае надо будет применить.
Хорошая статья. ERP проекты одни из самых сложных.
Особенно когда в меняется старая ERP которая критична для обеспечения непрерывности бизнеса и работает в режиме 24*7 с аптаймом 99,99%.
Причины две.
Или старая система не устраивает или импортозамещение.
Устарела, это комбинация нескольких факторов, таких как:
не устраивает производительность
не устаивает отказоустойчивость
дорабатывать систему для поддержки нового функционала невозможно/сложно/дорого или трудно найти людей, которые имеют эти навыки
Автору спасибо - очень качественная статья.
Замена ERP это реально искусство хождения по минному полю.
Особенно если, менять "Большим взрывом".
Сейчас ведем проект замены ERP в дочке ГазПрома по методологии Parallel Running, темп вывода в прод ровный, уровень стресса приемлемый (во всяком случае без героизма).
Толковая статья. Спасибо !
как ни странно мне нравиться определение ВА и СА данное в Википедии
Ему в помощь могут дать технаря, если Заказчик требует сделать, нечто мудреное ( типа системы «автоматического планирования перевозок» ).
Если же предметная область Заказчика очень сложная, то в помощь дадут того хорошо этот бизнес знает (например банковское дело)
БА — обязан понимать as-is бизнес заказчика и уметь сформировать бизнес требования. Здесь ему часто нужна помощь СА ибо заказчик может попросить «из соломы небоскреб построить»
СА — на основании бизнес требований должен спроектировать to-be solution, то есть как требуемый функционал будет реализован с точки зрения пользователя (какие экраны, логика расчетов и прочее). Здесь СА часто требуется помощь TechLead.
ПС
Часто один и тот же человек выполняет роль и БА и СА
— есть 100 заказчиков, использующих продукт и для которых сделаны доработки.
— пришло время переводить их на новую версию.
Возникают вопросы объединения новой версии и доработок, вот здесь то этот механизм и очень полезен, так как избавляет от необходимости делать объединение кода в ручную.