Коллеги,
есть большая матрица реквизитов, которые встречаются в  нескольких системах. Порядок - 1000 реквизитов, в 15 системах. Какая-то часть реквизитов в некоторых системах может отсутствовать, в каждой системе разная часть. Необходимо сделать мапирование реквизитов друг на друга в разных системах. На ум приходит Excel, но есть опасения, что с ним будет не удобно работать.
Может быть для этой задачи есть специализированный инструмент?

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

Прилагается пример из картинок. Результат - автоматическая матрица трассировкки.
В принципе, можно строить любые зависисмости (матрицы) между любыми типами элементов.
Средство - PD 15.1.

На трех объектах с тремя атрибутами иллюстрация понятна. Как будет выглядеть картинка, когда атрибутов 1000 и по 700 из них встречаются в 15 системах.

Мапирование нужно, например, для следующей задачи:
Изменяется блок реквизитов в источнике - вводятся новый блок данных или, что сложнее, заменяется один набор атрибутов другими, не всегда один в один, а по части атрибутов не меняется название, но меняется тип данных. Нужно параллельно внести изменения во все 15 систем. Мапирование позволяет проследить - что где на что нужно менять. 

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

p.s. Прошу прощения, если неправильно использую терминологию,  - давно не брал в руку шашки.

Что такое мапирование?

На трех объектах с тремя атрибутами иллюстрация понятна. Как будет выглядеть картинка, когда атрибутов 1000 и по 700 из них встречаются в 15 системах.

ХА!!!. Будет матрица строк на 1000 и столбцов на 15 (в минимуме, если не делить на подсистемы,  компоненты).На то она и матрица.

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

Про PD – в нем ОЧЕНЬ много моделей и возможностей.  Ваш случай – частный

Из личного опыта. Не говорю, что идеально.
Нужно иметь логическую модель, из которой генерится (изменяется)  базовая физическая модель, на основе которой сгенерированы модели конкретных объектов (эталоны, по нашему).
Изменения (особенности) учитываются на всех уровнях .Логика - новые требования и изменения, базовая физическая - как должно быть, частные модели - учитывают особенности каждого объекта (имеется ввиду ОА, или системы).
Для исключения дублирования в части атрибутов используется механизм ReplicatedObject.
Если короче - то "Тыкая" в системе на 1 элемент (например, бизнес функцию), можно выйти и на колонку и на атрибут и на систему и на класс и на форму и на изначальное требование.
При необходимости, создается любая матрица зависимостей (я еще раз подчеркиваю – практически любая, между ЛЮБЫМИ элементами, в том числе и вычисляемым транзитивным путем). Матриц можно сделать сколько угодно, и они все будут актуальными.
  Очень важно понимать, на какой вопрос нужен ответ. Соответственно, в ходе разработки, сопровождения, тестирования, т.е. постоянно, нужно поддерживать актуальность данных.
У нас 26 «объектов», 3 типа СУБД, 2 унаследованные системы, реквизитов (по вчерашним селектам, с учетом суррогатов)– 7876 (это только в базе, без учета особенностей в GUI, Hibernate и т.д.) Есть эталоны каждого объекта, всегда знаем, где, что отличается, что надо свести, что оставить.
Если честно – не успеваем все отслеживать. Частный бизнес на людях экономит, но снежный ком уже нарастает.
 

Из подобных тому, что на скриншоте с некоторыми натяжками подойдут:
- IBM Rational RequisitePro (как раз работа с матрицей)
- Sparx Systems Enterprise Architect (инструмент, подобный PD) и RaQuest (работа с матрицей, анализ влияния)
А так из подручных средств для обработки более удобен MS Access, но для ввода - не фонтан.

Именно с натяжкой.
Из личного опыта использования связки requsite+ WebSphere Business modeler + RSA.
Лучше сразу повеситься. По указанию начальства внедрял полгода. Всех заставлял использовать. Потом плюнул и выбрал с нуля PD.
Ранее для ООМ использовал Rose +requsitе. Для маленьких задачек в маленьком (8 чел) коллективе. Кое-как жили. С Soda – геморрой был страшный.

Что такое мапирование?

Про маппинг.  На рисунке простой пример из документации.
Т.е. сопоставление одно объекта другому. Если есть возможность определения и правил трансформации – то вообще замечательно.

Кстати, достаточно хорошие матрицы были в Oracle Designer. Я его долго использовал. Но, по моему,  это уже мертвый продукт.