iscrafms_ustinov,

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

Часто приходится слышать от своих коллег по ИТ "да какие проблемы! настройте мэпинг, и все дела!". Я полагаю, у них слишком упрошенные представления о том, что такое "мэпинг", они плохо себе представляют ограничениния, которые связаны с его применением. Во-первых, его можно использовать только для массивов информации, которые не обладают высокой динамикой изменений. Во-вторых, его можно использовать только для связей "один-к-одному" и "многие-к-одному". Для связей "один-ко-многим" и "многие-ко-многим" их использовать НЕВОЗМОЖНО В ПРИНЦИПЕ . По той простой причине, что менее детализированную информацию в принципе невозможно мэпировать в более детализированную (банальный пример: подразделение -> сотрудник).

Регламенты, да, делают систему менее гибкой. Однако, крупная система не может сохранять гибкость мелкой системы. По аналогии с природой. Морская звезда - более простая живая система, нежели человек. Если ее разрезать на 5 частей, из каждого ее луча вырастет новая морская звезда. Гибко, регенеративно? Да! Но человека, ежели четвертовать, то из каждой его части не вырастет новый человек. Менее гибко и менее регенеративно? Тоже да. Тем не менее, морской звезде не дано клепать космические корабли и летать на них в космос, а человеку - дано... :)

iscrafms_ustinovмаппинг как раз и есть стандартизация

маппинг <> стандартизация. Эти механизмы более близки к ETL.
Стандартизация - это когда в разных системах всю НСИ приводят к единым терминам. Никаких разных кодов, идентификаторов, наименований и т.д. и т.п. Стандартизация и оттягивает радостный момент внедрения на годы.Вы не правы. НСИ не обязывает бухгалтерию ссылаться на самую высокую из возможных степеней детализации, если только в этом нет реальной необходимости. При внедрении НСИ как раз и оценивается, в каких частях бизнес-процессов какая информация должна быть представлена до какой степени детализации, и почему.

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

Поэтому когда "система работает, но неправильно", это практически не отличается от "не работает, но правильно". :)

Нужно привести ее в состояние, когда она "работает, и притом правильно". Как ни крути. А это и достигается только при изначальной постановке задачи на внедрение ТЕХНООЛОГИИ , а не программы, которая, "слава богу, после запуска не остановила весь завод". :)

2 Iscrafm. Я, может быть, не совсем удачно выбрал Вашу цитату. Отвечал я сразу на несколько Ваших постов, и не согласен с Вашей позицией как таковой. По крайней мере, как я понял, Вы являетесь противником НСИ-зации и MDM-зации :) как таковой, потому что из-за низ затягивается "запуск программы"... Если я Вас не так понял, то приношу извинения.

Лично я глубоко убежден в том, что в 1000 раз лучше, когда запуск программы откладывается, но когда она оказывается запущенной, она работает в рамках ТЕХНОЛОГИИ , а не изображает из себя пук соломы, по формам очень похожий на трактор. Вообще, "запуск программы" - это событие совершенно ничтожное для бизнеса. Оно не имеет никакого бизнес-подтекста, никакого реального смысла. Когда в такое событие вкладывают некий волшебный смысл, это само по себе уже говорит о том, что к внедрению относятся изначально в корне неправильно.

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