Архитектура. Что лучше: все в одной базе или консолидация компаний / бизнес-направлений

[fed]

Могу добавить, что я считаю крайне сомнительным существование организации в которой вот прямо 8-10 тысяч одинаковых пользователей в одной линейной организации.Возможно - это вертикально-интегрированный холдинг с разными видами бизнеса в разных структурах. Вероятно, в таком случае, правильнее разрезать структуру на несколько сегментов (по схожести/смежности бизнеса) и каждый сегмент реализовать в отдельной инстоляции. (Не потому что сервер больше какого-то числа пользователей не потянет, а потому что тяжело металопрокат и продуктовый ритейл в одной установке скрестить).
Возможно также что это - филиальная структура (типа какого-то большого банка в котором много одинаковых по функциям филиалов). В этой ситуации правильнее разложить инстолляцию на несколько серверов, уже исходя из качества каналов, работы в одном часовом поясе (чтобы можно было устраивать профилактику без отрубания всех пользователей в стране) и тп.

[fed]

Цитата:

Сообщение от Ivanhoe

Вот прям как на твои вопросы отвечает официальный маркетинг вендора Нате вам Партишны для разного вида бизнеса в одной БД, нате вам часовые пояса как базовая функциональность платформы и ускоренный накат моделей в AX 2012

Насладись скрещиванием доработок для десятка разных бизнесов в одном приложении
Еще неплохо попробовать запланировать профилактику SQL Server, если у тебя пользователи где-нить в 12 часовых поясах разных

Да и вообще - на мой взгляд - это не техническая задача. Если у тебя так много пользователей, то скорее всего речь идет о большом количестве достаточно автономных бизнес-юнитов. И если эти бизнес-юниты действительно автономны, то сажать их в общую инстолляцию - это такая модель коммунальной квартиры в Айти.
Причем - это независимо от того Аксапта у тебя, САП, BAAN или 1с. Просто неправильно так делать - даже если аппаратных и программных ограничений нету. У тебя на этапе согласования ТЗ и взаимодействия проектных команд разных бизнес-юнитов случиться коллапс - задолго до возникновения любых технических проблем...

[Logger]

Цитата:

Сообщение от fed

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

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

[Vadik]

Цитата:

Сообщение от fed

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

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

Цитата:

Еще неплохо попробовать запланировать профилактику SQL Server, если у тебя пользователи где-нить в 12 часовых поясах разных

Скажем так, сложности поддержки такой системы необязательно настолько велики чтобы городить огород из нескольких систем и распыляться на их сопровождение и синхронизацию \ интеграцию. У нас есть клиент с примерно полусотней компаний в одном инстансе AX 2012 (грубо, по legal entities, некоторые уже остановлены, некоторые только запускаются или в планах и еще не в системе). Часовых зон полагаю будет побольше 12 (бизнесов и офисов нет разве что в Австралии). Соответственно, 24х7. И ничего, жив как-то. Последняя профилактика (патч) сиквела, требовавшая остановки, была полгода назад и сводилась к нескольким минутам недоступности для переключения на зеркало и обратно. Изменения в продуктив выкатываются в рабочем порядке от одного до нескольких раз в неделю.

[Ivanhoe]

А тут поможет MDM из R3
Я лично за разные инстАлляции (сорри, Денис ) при реально разных бизнесах и географиях. В пределах Европы / РФ - еще вопрос, если Америки / Европы / Азии - слишком много рисков и ограничений.

[George Nordic]

У-у... Хорошая тема. И тут мне ближе позиция Дениса, уж больно я намучался в свое время с очень обширной функциональностью в одном приложении. Просто очень много сложной бизнес-логики добавляется и галок, которые ее регулируют: в зависимости от типа бизнеса одна и та же функциональность иногда должна вести себя абсолютно по-разному. Ну, во первых, каждый раз надо пристально смотреть на задачу, и оценивать плюсы и минусы того или иного архитектурного решения. Но при прочих равных я бы отдал должное распределенной информационной базе.

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

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

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

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

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

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

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

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

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

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

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

С Уважением,
Георгий

[George Nordic]

Продолжаем.

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

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

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

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

С Уважением,
Георгий

[Logger]

Имею аналогичный опыт.
Куча филиалов по всей России. Реально время простоя Аксапты - один час ночью на выходных. Всех это устраивает.
А вначале попробовали иметь иметь 2 базы - одну на Москву, другую на филиал (один ! без тиражирования по всем подразделениям) - заколебались синхронизировать приложение и справочники. Просто какой-то кошмар. Зато когда сели в одно приложение и одну базу - красота. И тиражировать внедрение намного проще. Кучи проблем - как не бывало.

[George Nordic]

Цитата:

Сообщение от Vadik

А тиражировать общие доработки \ фиксы по куче похожих приложений - намного лучше, проще и дешевле? Как насчет сопровождения, отладки, наката изменений, доступности?

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

Цитата:

Сообщение от Logger

А вначале попробовали иметь иметь 2 базы - одну на Москву, другую на филиал (один ! без тиражирования по всем подразделениям) - заколебались синхронизировать приложение и справочники. Просто какой-то кошмар. Зато когда сели в одно приложение и одну базу - красота. И тиражировать внедрение намного проще. Кучи проблем - как не бывало.

Да, если приложение одинаковое, то смысла плодить отдельные инстансы все меньше, с распространением высокоскоростного интернета.

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

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

С Уважением,
Георгий

[gl00mie]

Я бы сказал, вместо кучи рутинных проблем, которые кошмарят администраторов и службу поддержки, вроде накатывания обновлений, переноса модификаций, которые могут быть полезны всем, на кучу экземпляров приложения, синхронизации справочников и т.п., возникает куча других проблем, связанных с существенным усложнением разработки модификаций (то самое "скрещивание доработок для десятков разных бизнесов в одном приложении"). Особенно сложно это скрещивание дается тогда, когда бизнесы "почти" похожи, но чем-то отличаются. Тут волей-неволей приходится изобретать сложные универсальные механизмы и настраивать их под каждый бизнес либо, в особо запущенных случаях, делать ветвления типа "если бизнес такой-то, то идем сюда, а если другой - вон туда".
С другой стороны, вендор пошел в итоге именно этим путем: вместо кучи gls-слоев локализации под различные регионы скрестил всё и вся на sys-слое, разделив функционал по конфигурационным ключам и кодам стран. Исключение составляет, насколько я знаю, разве что расчет зарплаты (payroll), выпускаемый на отдельном слое.

[Logger]

Цитата:

Сообщение от gl00mie

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

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

[fed]

Я только могу заметить что оба подхода имеют право на существование и свои плюсы и минусы. Но все-таки, прежде чем спрашивать про конфигурацию на 8-10 тысяч пользователей, стоит рассмотреть альтернативы (хотя таки да - возможно в каких-то конкретных случаях будет проще поддерживать один инстанс).
Хотя я лично, не могу представить такой проект - но не потому что железка не потянет, а потому что не представляю как в разумное время автоматизировать такое большое число пользователей. Я только один проект сопоставимого масштаба знаю - внедрение Оракла в Связьинвесте. И у меня как раз сильное впечатление, что там проект уткнулся не в технические проблемы, а как раз таки в организационные - тяжело было согласовать решение с таким количеством заинтересованных лиц.