Но всё же в банке, моё глубокое имхо, увы, не основанное на практике, лоскутов быть не должно... может я неправ.

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

А в пути никто кормить не обещал.

Нет уж, извините. Мне в пути детей кормить надо, поэтому туда, где в пути не кормят, меня не интересует. Я просто работаю, а не занимаюсь пламенной революционной борьбой. 

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

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

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

2 div:
да это к слову... в том смысле, что простого можно не ждать, а нужно в любом случае действовать.

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

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

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

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

То что написал Водолей, насколько я понимаю, поможет нарисовать картинку to-be. Поскольку вроде упоминалась еще и некая существующая система то полезно понять и картинку as-is. Имея их обе можно понять что делать с уже существующей - выбросить или доделать

PS

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

Мне кажется требования к отчетам можно и нужно формировать не дожидаясь наличия данных

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

по второму согласен, за исключением оговорок сказанных ранее (когда таких данных в природе нет)

Мне кажется требования к отчетам можно и нужно формировать не дожидаясь наличия данных

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

2 div
Я настаиваю на том что требования по отчетам должны формироваться на этапе проектирования OLAP решения или DW (т.е. когда не то что данных в OLAP системе нет - еще самих систем то нет). Невозможно понять какие витрины, какие факты и по каким разрезам (т.е. какие кубики) строить если нет понимания требований к отчетам. Другое дело на каком уровне определять эти требования.
Детализировать описание отчетности до уровня полей на этапе подписания обязательств (тут я может Вас не понял) - в век Agile както вот странно!!!!

PS а вы отчетность на чем делаете? В смысле на какомто продукте или сами кодируете?

Детализировать описание отчетности до уровня полей на этапе подписания обязательств - в век Agile както вот странно!!!!

Как жаль, что заказчик этого не знает!

PS а вы отчетность на чем делаете? В смысле на какомто продукте или сами кодируете?

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

если мотороллер не ваш, то откуда вы знаете что знает заказчик а что нет?

если мотороллер не ваш, то откуда вы знаете что знает заказчик а что нет?

Приятель жаловался.

ЗЫ: диалог в этой ветке ушел ИМХО от конструктива.