Vad72,

Позволю себе для начала задать несколько уточняющих вопросов:
1) Крупный холдинг не имеет решения по консолидации данных или хранилище? Или у Вас каждый отдел строит своё "хранилище" и Вы из одного из таких отделов? Попробуйте узнать, возможно, такая система уже существует и в рамках её можно собирать необходимые данные.
2) как упомянул Dinamo - "Если не выстроить требования к системе показателей сверху-вниз, то вероятность получения нужно результата очень низка". Надо начинать с бизнес-требований - т.е. описать те отчеты, которые нужны центру. Затем понять, какие данные нужны для этих отчетов. Затем, спроектировать логическую модель, после физическую. Затем запрашивать эти данные из филиалов. Проще всего, чтобы филиалы сами выгружали их на FTP. Таким образом, Вам будет все равно какая учетная система, СУБД и ОС в филиале. Необходимо описать политику контроля качества данных, порядок обновлений/инкрементов, НСИ, подсистему метаданных, ETL и кучу всего, что свойственно хранилищу =)

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

Vad72,

Для информации - более 70% проектов по построению хранилищ загибаются из-за отсутствия приемлемых/корректных/точных бизнес-требований.
Вам необходимо по максимуму выжать из внутренних заказчиков бизнес-требования. Как уже писал - "Надо начинать с бизнес-требований - т.е. описать те отчеты, которые нужны центру. Затем понять, какие данные нужны для этих отчетов. Затем, спроектировать логическую модель, после физическую. Затем запрашивать эти данные из филиалов."

Нужно выяснить, в каком формате им нужны отчеты - Excel, Word, PDF, web-интерфейс и т.д. Уточнить требования ко времени формирования отчетов. Выяснить характер данных - детальные или сводные. По максимуму извлечь бизнес-требования.
От этого зависит:
1) Системные требования к хранилищу -> выбор платформы.
2) Обеспечение максимально простого, понятного и прозрачного, доступа к данным для пользователей
3) Стомость всех работ, их продолжительность. Дальнейшие затраты на сопровождение.

Немаловажны работы по оценке требований к производительности, дисковому пространству, ежедневным инкрементам. +политика резервного копирования +соглашение об уровне обслуживания.

Хотя, если нет бюджета, и нет возможности привлечь внешних консультантов - единственное, могу рекомендовать выкладывать на форум частные вопросы (и это в холдинге(!)). Люди здесь отзывчивые. Грязью польют, но всё равно помогут =)

Ваши заказчики должны более-менее четко себе представлять, какая информация им нужна, сколько прибыли им даст своевременное получение качественных консолидированных и очищенных данных. Сколько прибыли/клиентов/абонентов/пациентов они упускают из-за того, что оперативно не видят картины происходящего и не могут подстраиваться под конъюнктуру рынка. Исходя из этих цифр они могут понимать, на какого уровня проект/систему они могут расчитывать и в какие сроки (т.е. стоит овчинка выделки или нет). Как правило, для начала делают пилотный проект - нравится, продолжают, нет - так нет. Организация должна ещё дорасти до такого уровня - где DWH, MIS, DSS и прочее - основной стратегический инструмент управленца.

В целом 100% согласен с softwarer (без обид): "примерно как зрелище ребёнка, сосредоточенно изготавливающего для мишки деревянный велосипед".

Vad72,

в общем, FTP Вам в помощь. Данные, в утвержденном формате, пусть выкладывают сами регионы. Если они не захотят писать конверторы-выгружалки, то пусть выкладывают дампы баз в zip, а Вы их будете сами крутить-вертеть. Выполняете первоначальное наполнение, а далее ночными джобами льёте данные в БД. Инструментов - куча. Лучшие из них - те, которые Вы знаете лучше других.

PS: легко другим давать советы, но не себе - это я про себя)