AXForum  
Вернуться   AXForum > Рынок > Методология внедрения
CRM
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.10.2015, 10:11   #1  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Я бы сказал, вместо кучи рутинных проблем, которые кошмарят администраторов и службу поддержки, вроде накатывания обновлений, переноса модификаций, которые могут быть полезны всем, на кучу экземпляров приложения, синхронизации справочников и т.п., возникает куча других проблем, связанных с существенным усложнением разработки модификаций (то самое "скрещивание доработок для десятков разных бизнесов в одном приложении"). Особенно сложно это скрещивание дается тогда, когда бизнесы "почти" похожи, но чем-то отличаются. Тут волей-неволей приходится изобретать сложные универсальные механизмы и настраивать их под каждый бизнес либо, в особо запущенных случаях, делать ветвления типа "если бизнес такой-то, то идем сюда, а если другой - вон туда".
С другой стороны, вендор пошел в итоге именно этим путем: вместо кучи gls-слоев локализации под различные регионы скрестил всё и вся на sys-слое, разделив функционал по конфигурационным ключам и кодам стран. Исключение составляет, насколько я знаю, разве что расчет зарплаты (payroll), выпускаемый на отдельном слое.
Старый 05.10.2015, 12:18   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,882 / 3148 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Я бы сказал, вместо кучи рутинных проблем, которые кошмарят администраторов и службу поддержки, вроде накатывания обновлений, переноса модификаций, которые могут быть полезны всем, на кучу экземпляров приложения, синхронизации справочников и т.п., возникает куча других проблем, связанных с существенным усложнением разработки модификаций (то самое "скрещивание доработок для десятков разных бизнесов в одном приложении"). Особенно сложно это скрещивание дается тогда, когда бизнесы "почти" похожи, но чем-то отличаются.
Да, именно это и было основной проблемой.
Поддержка двух баз вызвала столько усилий что перед тиражированием на всех приняли решение посадить всех в одну базу.
Теги
как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axforum blogs: Кто такой Бизнес-Аналитик? Blog bot DAX Blogs 0 03.10.2014 16:11
несколько компаний в одной IKA DAX: Программирование 11 31.08.2010 11:44
консолидация финансовых данных из 3 компаний в одну wojzeh DAX: Программирование 8 24.03.2008 07:58

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:21.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.