[George Nordic]

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

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

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

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

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

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

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

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

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

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

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

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

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