Полностью присоединяюсь к предыдущему оратору

К слову добавлю, что сама задача, мягко говоря, несколько осложнилась: как выяснилось, необходимые для создания хранилища данные, содержащиеся в существующих АС, во-первых, далеко не всегда отражают действительность (т.е. некорректны), и, во-вторых, их явно недостаточно для получения тех отчетов, которые хочет видеть руководство.
Так что пока я нахожусь на стадии выявления проблем (таких проблем, влияющих прямо или косвенно на задачу разработки OLAP-системы, уже накопилось немало), их причин и т.п., чувствую, что до описания требований к "написанию собственного велосипеда" мне еще далеко... Но замечание учту.

Эээээ, таким макаром Вы никакого OLAP'а не построите. Т.е. конечно, технически систему заставить работать можно (как асфальтоукладчик без асфальта), но вот отчеты с правильными данными, ради которых всё затевается, Вы не получите, пока, собственно, данные, доступные для обработки, не окажутся в хранилище. Скажите об этом своему руководству прямо: так, мол, и так, нет данных - нет и отчетов.

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

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

Как раз на прошлой неделе обдумывали схожую ситуацию в одной банковской системе. Одному департаменту (1) нужны отчеты, данные для которых вводятся в другом департаменте (2). бОльшую часть данных департамент (2) вводит исправно. Но есть небольшая, нужная только для этих конкретно отчетов, часть данных, наличие которых для сотрудников департамента (2) в системе не важно. Поэтому они их, естественно, не вводят (экономят свое время), и административное давление не помогает.
 
Посмотрели, как сейчас делают отчеты в (1) - выуживают из плохо структурированных документов недостающие данные, хранят в Экселе или на бумаге и подставляют их во вручную в Экселе изготавливающиеся отчеты.
Рекомендовали - полностью довбить сотрудникам (1) эти данные в Эксель, сделать эту Эксель таблицу дополнительным источником для хранилища (наряду с основной банковской БД), взять департаменту (1) на себя поддержку ее актуальности. После этого банковские айтишники легко могут сделать автоматическую генерацию нужных отчетов, т.к. в хранилище появляется нужная достоверная информация.

2 div:
Чего-то я не совсем понял. Получилось в итоге, что для (1) существует экселевкая табличка, в которую сотрудники этого же (1) вносят данные вручную? И так же сами и вручную следят за её актуальностью? А отчёты строятся путём обработки данных находящихся как в хранлище, так и в этом экселевском файле?

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

кому нужен этот эксель? или у Вас кусочно-лоскутная автоматизация?

Вообще тут речь идёт о хранилище, поэтому поток данных должен быть направлен именно в хранилище, иначе подобные лоскуты и костыли будут плодиться и дальше, а хранилище теряет смысл. И вообще, создание дополнительного источника данных в обход хранилища для отчётов, да ещё в виде ручного экселя - это вообще ересь, если нет каких-то неозвученных особенных факторов.
ИМХО.

2 STUTK, Водолей

Чего на человека набросились - он же написал "..сделать эту Эксель таблицу дополнительным источником для хранилища (наряду с основной банковской БД).."

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

2 KIRILLSS:
Побойтесь Бога, никто на человека не набрасывался! Просто безудержный интерес к теме накладывает эмоциональный отпечаток на стиль изложения. =)

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

ну хоть в теории сошлись... )))))
а как на практике ? Делитесь... раз уж безудержный интерес)))

А насчет этого пассажа - вообще слов нет...

как говорится: "как это нет слов - надо было подготовиться" (с)

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

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

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

Делитесь... раз уж безудержный интерес)))

Вас что-то конкретное интересует или так... безудержный интерес? :о))

2 Водолей
Моя фраза, процитированная Вами относилась к лоскутной автоматизации. Я с некоторых пор перестал воспринимать этот термин как однозначно ругательный. Иногда такая автоматизация - зло, иногда - экономически оправдана. По имеющейся от div информации трудно определить что имеет место в данном случае..

Что касается безудержного интереса - то вопрос, как нетрудно восстановить из двух предыдущих постов, относился к "функции консолидации.." хранилища

1. Вообще то "мотороллер не мой" , т.е. банк не мой, просто попросили проконсультировать как оперативно решить проблему. Через месяц-другой посмотрим, что получится на практике.
2. Наверное, не так просто на деле "спрямить бизнес-процессы". Вы лично пробовали подойти к хозяину банка - простому миллиардеру и так предложить спрямить ему пару-тройку бизнес-процессов; мол, я вот тебе дам совет, как тебе разбогатеть? Вот я когда то по неопытности, воодушевленный правильными книжками, попробовал...
А дать одному подразделению права на редактирование данных, за которые ответственно другое подразделение - кто подпишется под этим, если за этим правом КОНКРЕТНАЯ ответственность?
3.

кто-то ведь определял задачи этим департаментам, кто-то закупал, устанавливал и обслуживал эту систему.

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

4.

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

Немного, это данные типа словарей: редко меняющиеся и небольшие по объему - до нескольких сотен записей.

ну хоть в теории сошлись... )))))
а как на практике ? Делитесь... раз уж безудержный интерес)))

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

2 Водолей
Моя фраза, процитированная Вами относилась к лоскутной автоматизации. Я с некоторых пор перестал воспринимать этот термин как однозначно ругательный.

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

1. Вообще то "мотороллер не мой" , т.е. банк не мой, просто попросили проконсультировать как оперативно решить проблему. Через месяц-другой посмотрим, что получится на практике.

Посмотрим-посмотрим. Но пока всё-таки неясно в чем суть проблемы. IMHO кто-то не делает своей части общей работы.

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

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

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

А дать одному подразделению права на редактирование данных, за которые ответственно другое подразделение - кто подпишется под этим, если за этим правом КОНКРЕТНАЯ ответственность?

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

3. Основные повседеневные задачи хорошо решаются, система в целом работает хорошо. Но аппетит приходит во время еды - появляются новые потребности, не учтенные в начале. Я думаю, все сталкивались с этим?

Хорошо построенная архитектура даст ответ. Тогда-то и станет ясна разница хорошего и кусочно-лоскутного способа ее построения.

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

Крамолу скажу: Не их дело возражать - их дело работать, как требуется бизнесу. Сложно - учитесь!

4. Немного, это данные типа словарей: редко меняющиеся и небольшие по объему - до нескольких сотен записей.

вообще в непонятках, вроде выше было написано, что по этим данным строятся отчеты.

В общем, успехов в большом и трудном деле...