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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.10.2015, 13:33   #1  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,518 / 4811 (166) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
? Архитектура. Что лучше: все в одной базе или консолидация компаний / бизнес-направлений
Могу добавить, что я считаю крайне сомнительным существование организации в которой вот прямо 8-10 тысяч одинаковых пользователей в одной линейной организации.Возможно - это вертикально-интегрированный холдинг с разными видами бизнеса в разных структурах. Вероятно, в таком случае, правильнее разрезать структуру на несколько сегментов (по схожести/смежности бизнеса) и каждый сегмент реализовать в отдельной инстоляции. (Не потому что сервер больше какого-то числа пользователей не потянет, а потому что тяжело металопрокат и продуктовый ритейл в одной установке скрестить).
Возможно также что это - филиальная структура (типа какого-то большого банка в котором много одинаковых по функциям филиалов). В этой ситуации правильнее разложить инстолляцию на несколько серверов, уже исходя из качества каналов, работы в одном часовом поясе (чтобы можно было устраивать профилактику без отрубания всех пользователей в стране) и тп.
За это сообщение автора поблагодарили: Aquarius (1).
Старый 01.10.2015, 14:19   #2  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,518 / 4811 (166) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Вот прям как на твои вопросы отвечает официальный маркетинг вендора Нате вам Партишны для разного вида бизнеса в одной БД, нате вам часовые пояса как базовая функциональность платформы и ускоренный накат моделей в AX 2012
Насладись скрещиванием доработок для десятка разных бизнесов в одном приложении
Еще неплохо попробовать запланировать профилактику SQL Server, если у тебя пользователи где-нить в 12 часовых поясах разных

Да и вообще - на мой взгляд - это не техническая задача. Если у тебя так много пользователей, то скорее всего речь идет о большом количестве достаточно автономных бизнес-юнитов. И если эти бизнес-юниты действительно автономны, то сажать их в общую инстолляцию - это такая модель коммунальной квартиры в Айти.
Причем - это независимо от того Аксапта у тебя, САП, BAAN или 1с. Просто неправильно так делать - даже если аппаратных и программных ограничений нету. У тебя на этапе согласования ТЗ и взаимодействия проектных команд разных бизнес-юнитов случиться коллапс - задолго до возникновения любых технических проблем...
Старый 01.10.2015, 15:49   #3  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,244 / 2131 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от fed Посмотреть сообщение
Если у тебя так много пользователей, то скорее всего речь идет о большом количестве достаточно автономных бизнес-юнитов. И если эти бизнес-юниты действительно автономны, то сажать их в общую инстолляцию - это такая модель коммунальной квартиры в Айти.
В случае когда есть куча филиалов, то как правило справочники общие. Поэтому и хочется посадить всех в одну базу. Если же базы разные, то интересно было бы вести справочники в отдельной инсталляции, из которой их "репилицировать" в остальные.
Старый 01.10.2015, 16:04   #4  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,068 / 2099 (78) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А тут поможет MDM из R3
Я лично за разные инстАлляции (сорри, Денис ) при реально разных бизнесах и географиях. В пределах Европы / РФ - еще вопрос, если Америки / Европы / Азии - слишком много рисков и ограничений.
__________________
Ivanhoe as is..
Старый 02.10.2015, 11:13   #5  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,432 / 1079 (44) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
У-у... Хорошая тема. И тут мне ближе позиция Дениса, уж больно я намучался в свое время с очень обширной функциональностью в одном приложении. Просто очень много сложной бизнес-логики добавляется и галок, которые ее регулируют: в зависимости от типа бизнеса одна и та же функциональность иногда должна вести себя абсолютно по-разному. Ну, во первых, каждый раз надо пристально смотреть на задачу, и оценивать плюсы и минусы того или иного архитектурного решения. Но при прочих равных я бы отдал должное распределенной информационной базе.

Все-таки я считаю, что если подразделения должны быть автоматизированы независимо, если их бизнес не укладывается в бизнес-модель головной компании. А даже если и укладывается - тоже не факт. Например, всемирный дистрибьютор :Номенклатура по всему миру примерно одна и та же, хотят видеть список клиентов, проводки и задолженность по ним - ну, кто ж не хочет. Пока дело в Европе и Америке - ну, ок. А вот стоит подключить Китай, Японию, Корею или хотя бы арабские страны - проводки и названия клиентов в виде иероглифов ставят руководство, мягко говоря, в тупик.

Да и потом выясняется, что не так уж и важен для головной компании проводки и задолженность ООО Ромашка в Нью-Васюках. А важно - выручка, прибыль, P&L, план/факт, доход на вложенный у.е. и на нанятую голову - все те показатели, по которым их оценивает рынок.

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

1. "Эталонная" база. Ведение НСИ, консолидация, финансовый учет и отчетность холдинга
Оргструктура
Описана структура холдинга со всеми входящими в него компаниями или долями компаний.

"глобальный" План Счетов:
- данный план счетов обязан для информирования дочерних компании с целью согласования мэппинга их плана счетов в пс головной компании
- [коносолидированные] проводки дочерних компаний должны по правилам мэппинга собираться в ГК головной компании на периодической основе.

НСИ.
Так же в ней ведутся основные справочники, обязанные к использованию по все группе компаний: это могут быть адреса, клиенты, номенклатура, телефоны... все что угодно.
Если справочники общие, то изменения / добавление общих справочников происходит только после утверждения оператором головной компании, после чего обновленные справочники будут реплицированы по всем "дочкам". Репликация происходит на периодической основе.

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

Структура приложения
То же самое релевантно, если мы используем одинаковую структуру приложений по дочерним компаниям. Изменяем струкуру мастер-приложения (вносим доработку) - и утром после синхронизации все работают с данной доработкой. В моей практике встречался с подобной реализацией на 1С РИБ, 53 филиала, 42 000 пользователей, функциональность по управлению персоналом.

Консолидация
Если у нас есть подобное "мастер-приложение", то его же можно использовать и для сбора данный. Но можно и отдельно, конечно. На периодической основе с дочерних компаний сливаются необходимые данные с указанной детализацией. Можно настроить вплоть до чека, можно грузить агрегаты сколько товара по какой цене отгрузили - в зависимости от задач и необходимой детализации для принятия управленческих решений в головной компании. И, на мой взгляд, предпочтительнее 2й вариант.

Планирование и распределение
Если данные с филиалов поступают оперативно, при есть потребность в распределении неких общих ресурсов, финансовых или материальных, например пополнение РЦ в зависимости от уходимости товаров и состояния складов дочерних компаний, то данное приложение можно задействовать и для глобального планирования распределения ресурсов и контроля за эффективностью их использования (бюджетирование, план/факт анализ)

Финансовый учет и отчетность
Если у нас есть проводки в ГК по дочерним компаниям, да еще и с необходимой детализацией (аналитическими разрезами), то, кончено, очень разумно данное приложение использовать для финансового учета, и, возможно, как базу для формирования отчетности по холдингу.

С Уважением,
Георгий
За это сообщение автора поблагодарили: MikeR (3), gl00mie (3).
Старый 02.10.2015, 11:24   #6  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,432 / 1079 (44) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Продолжаем.

2. "Подчиненная", или рабочая база, в которой ведется учет деятельность того или иного подразделения.

Все как обычно, только часть справочников "спускается" сверху, остальные ведутся локально.
Приложение - заточено под специфику деятельности именно этой компании, то, о чем так любят говорить "лучшие практики" и "best of breed", а использовать "1Х: Автосервис" и "2Х: Парикмахерская".
Необходимые для отчета в головную компанию данные маппируются по установленным холдингом правилам и передаются в головную компанию на периодической основе.

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

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

С Уважением,
Георгий
Старый 04.10.2015, 12:39   #7  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,441 / 1561 (59) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от fed Посмотреть сообщение
Насладись скрещиванием доработок для десятка разных бизнесов в одном приложении
Я дочь внедренца - поверьте тут не все так однозначно (с) А кому сейчас легко.. А тиражировать общие доработки \ фиксы по куче похожих приложений - намного лучше, проще и дешевле? Как насчет сопровождения, отладки, наката изменений, доступности ? Апгрейд версий тоже наверное проще один раз сделать, пусть и больше времени это занимает, вместо десяти ?
Цитата:
Еще неплохо попробовать запланировать профилактику SQL Server, если у тебя пользователи где-нить в 12 часовых поясах разных
Скажем так, сложности поддержки такой системы необязательно настолько велики чтобы городить огород из нескольких систем и распыляться на их сопровождение и синхронизацию \ интеграцию. У нас есть клиент с примерно полусотней компаний в одном инстансе AX 2012 (грубо, по legal entities, некоторые уже остановлены, некоторые только запускаются или в планах и еще не в системе). Часовых зон полагаю будет побольше 12 (бизнесов и офисов нет разве что в Австралии). Соответственно, 24х7. И ничего, жив как-то. Последняя профилактика (патч) сиквела, требовавшая остановки, была полгода назад и сводилась к нескольким минутам недоступности для переключения на зеркало и обратно. Изменения в продуктив выкатываются в рабочем порядке от одного до нескольких раз в неделю.
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: Ivanhoe (1), Link (1), gl00mie (2).
Старый 05.10.2015, 09:51   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,244 / 2131 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Имею аналогичный опыт.
Куча филиалов по всей России. Реально время простоя Аксапты - один час ночью на выходных. Всех это устраивает.
А вначале попробовали иметь иметь 2 базы - одну на Москву, другую на филиал (один ! без тиражирования по всем подразделениям) - заколебались синхронизировать приложение и справочники. Просто какой-то кошмар. Зато когда сели в одно приложение и одну базу - красота. И тиражировать внедрение намного проще. Кучи проблем - как не бывало.
За это сообщение автора поблагодарили: gl00mie (2).
Старый 05.10.2015, 10:11   #9  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,594 / 5229 (182) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Я бы сказал, вместо кучи рутинных проблем, которые кошмарят администраторов и службу поддержки, вроде накатывания обновлений, переноса модификаций, которые могут быть полезны всем, на кучу экземпляров приложения, синхронизации справочников и т.п., возникает куча других проблем, связанных с существенным усложнением разработки модификаций (то самое "скрещивание доработок для десятков разных бизнесов в одном приложении"). Особенно сложно это скрещивание дается тогда, когда бизнесы "почти" похожи, но чем-то отличаются. Тут волей-неволей приходится изобретать сложные универсальные механизмы и настраивать их под каждый бизнес либо, в особо запущенных случаях, делать ветвления типа "если бизнес такой-то, то идем сюда, а если другой - вон туда".
С другой стороны, вендор пошел в итоге именно этим путем: вместо кучи gls-слоев локализации под различные регионы скрестил всё и вся на sys-слое, разделив функционал по конфигурационным ключам и кодам стран. Исключение составляет, насколько я знаю, разве что расчет зарплаты (payroll), выпускаемый на отдельном слое.
Старый 05.10.2015, 10:13   #10  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,432 / 1079 (44) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от Vadik Посмотреть сообщение
А тиражировать общие доработки \ фиксы по куче похожих приложений - намного лучше, проще и дешевле? Как насчет сопровождения, отладки, наката изменений, доступности?
Необходимые доработки для всех подразделений накатываются на мастер-приложение. Одно серьезное но - в период синхронизации часть данных будет идти "по старому" бизнес-процессу и приложению, часть - по-новому. Решается, в частности, отложенным "часом Х", с которого начинает действовать доработка, еще есть пути решения, но надо учитывать этот нюанс.
Цитата:
Сообщение от Logger Посмотреть сообщение
А вначале попробовали иметь иметь 2 базы - одну на Москву, другую на филиал (один ! без тиражирования по всем подразделениям) - заколебались синхронизировать приложение и справочники. Просто какой-то кошмар. Зато когда сели в одно приложение и одну базу - красота. И тиражировать внедрение намного проще. Кучи проблем - как не бывало.
Да, если приложение одинаковое, то смысла плодить отдельные инстансы все меньше, с распространением высокоскоростного интернета.

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

Но я не просто рассказал про опыт с 42 000 пользователей.

С Уважением,
Георгий
Старый 05.10.2015, 12:18   #11  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,244 / 2131 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Я бы сказал, вместо кучи рутинных проблем, которые кошмарят администраторов и службу поддержки, вроде накатывания обновлений, переноса модификаций, которые могут быть полезны всем, на кучу экземпляров приложения, синхронизации справочников и т.п., возникает куча других проблем, связанных с существенным усложнением разработки модификаций (то самое "скрещивание доработок для десятков разных бизнесов в одном приложении"). Особенно сложно это скрещивание дается тогда, когда бизнесы "почти" похожи, но чем-то отличаются.
Да, именно это и было основной проблемой.
Поддержка двух баз вызвала столько усилий что перед тиражированием на всех приняли решение посадить всех в одну базу.
Старый 05.10.2015, 12:29   #12  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,518 / 4811 (166) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я только могу заметить что оба подхода имеют право на существование и свои плюсы и минусы. Но все-таки, прежде чем спрашивать про конфигурацию на 8-10 тысяч пользователей, стоит рассмотреть альтернативы (хотя таки да - возможно в каких-то конкретных случаях будет проще поддерживать один инстанс).
Хотя я лично, не могу представить такой проект - но не потому что железка не потянет, а потому что не представляю как в разумное время автоматизировать такое большое число пользователей. Я только один проект сопоставимого масштаба знаю - внедрение Оракла в Связьинвесте. И у меня как раз сильное впечатление, что там проект уткнулся не в технические проблемы, а как раз таки в организационные - тяжело было согласовать решение с таким количеством заинтересованных лиц.
Теги
как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
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, время: 23:10.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.