GaryaВ топике "как определить экономию времени от внедрения ERP-системы?" обсуждение невольно коснулось вопроса систематизации НСИ. Я полагаю, это важный вопрос, который требует отдельного обсуждения, поэтому выделил его в отдельный топик. Высказывались мнения:
GaryaОдин из наиболее существенных выигрышей, который достигается при внедрении ERP-системы, это достижение СОГЛАСОВАННОСТИ информации, поступающей от разных источников. Те предприятия, руководители которых в конечном итоге этого не поняли, обычно проваливают проект внедрения ERP-системы. Но пока КАЧЕСТВО информации (кроме ее объема!) не достигнет некоторой величины, внедрение ERP-системы оказывается просто невозможной. Пока не систематизированы НСИ, пока у сотрудников различных подразделений нет моральной готовности вводить информацию, которая будет востребована не собственным подразделением, а каким-то другим (качественно и в срок!), пока не будут выработаны регламенты формирования и движения информации, проект внедрения ERP-системы остается не более чем маниловщиной. Попытки "выбить" решение этих вопросов некой сторонней силой (консультантами, внедренцами и т.п.) обречены на провал - только наличие внутреннего потенциала и внутренней воли может привести к положительным подвижкам.
...
Когда возникает понимание в необходимости состыковать информацию, разрушить информационные барьеры между подразделениями, тогда разрушают информационные барьеры и построенные информационные каналы ЦЕМЕНТИРУЮТ - с помощью ERP-системы.

iscrafm GaryaИнформация просто НЕ СТЫКУЕТСЯ
стыкуется. То, что Вы называете информационными коммуникациями как раз и занимается этим.
Иначе, получается голова отдельно, туловище отдельно. Т.е. БП живут своей жизнью, а потом информация просто вдалбывается в базу данных.

Garya iscrafm GaryaИнформация просто НЕ СТЫКУЕТСЯ
стыкуется. То, что Вы называете информационными коммуникациями как раз и занимается этим.
Иначе, получается голова отдельно, туловище отдельно. Т.е. БП живут своей жизнью, а потом информация просто вдалбывается в базу данных.Пример из "реальной жизни":
Бухгалтерия1. Вид бухгалтерских затрат 1
2. Вид бухгалтерских затрат 2
3. Вид бухгалтерских затрат 3
4. Прочие бухгалтерские затраты
Финансовая дирекция1. Вид финансовых затрат 1
2. Вид финансовых затрат 2
3. Вид финансовых затрат 3
4. Прочие финансовые затраты I. "2. Вид бухгалтерских затрат 2" частично входит "2. Вид финансовых затрат 2", плюс часть "3. Вид финансовых затрат 3"; плюс часть (небольшая) "4. Прочие финансовые затраты".
II. "3. Вид бухгалтерских затрат 3" в финансовой дирекции в самостоятельный вид затрат не выделен, и полностью попадает в "4. Прочие финансовые затраты", составляя при этом лишь его часть.
III. Некоторые затраты, попавшие в состав затрат в финансовой дирекции, в состав бухгалтерских затрат вообще не попадает
IV. Некоторые затраты, попавшие в состав затрат бухгалтерских затрат, в состав затрат финансовой дирекции попадает в другом учетном периоде.
Ну и как это всё может стыковаться? Некоторые полагают, что "таблицами перекодировки"...

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

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

Есть еще один нюанс, который очень часто упускается из виду любителями "таблиц перекодировки". Таблица перекодировки обычно воспринимается в виде промежуточного звена между некоторым источником и приемником. При этом подспудно подразумевается, что и источник, и приемник - один . На практике при решении задач информационной интеграции приходится иметь дело со множеством источников и со множеством приемников. Что это меняет? А то, что "таблица перекодировки" тоже не одна, а множество. И при появлении новой записи в одном из источников может понадобиться внести изменения во множество "таблиц перекодировки". Причем, НЕ ЗАБЫТЬ это сделать во всех местах!

Приведенный выше пример - не самый удачный для демонстрации множественности источников и приемников, хотя даже на таком примере ее можно проиллюстрировать. Имеется:
- налоговый учет (НУ), в котором состав расходов определяется НК РФ;
- бухгалтерский учет (БУ), в котором расходы задаются ПБУ;
- управленческий учет (УУ), в котором для целей бюджетирования, ABC-анализа и т.д. и т.п. используется своя классификация расходов (прежде всего с разделением их на переменные и постоянные для расчета маржинальной прибыли)

Итак, мы уже видим три слабо связанных между собой источника информации, требующих взаимной увязки. Казалось бы, ну и где какие проблемы? А теперь представим, что у нас множество предприятий в холдинге, расположенных в разных городах. И каждое из этих предприятий использует свой набор расходов, наиболее удобный для использования на данной площадке. Причем, на площадках, где расходы некоторого вида составляют существенную часть, по ним ведется детальный учет с дополнительными аналитическими уровнями, а на некоторых площадках, где этот же вид расходов считается несущественным, он просто сваливается в большую кучу под названием "прочие расходы". Теперь требуется консолидировать расходы по всем площадкам, увязав еще при этом БУ, НУ и УУ. Общее количество центров информации получается равным 3 (количество учетов разного вида) * N (количество предприятий в холдинге). Сколько должно быть "таблиц перекодировки"? (вопрос риторический) :) А теперь добавим к этой "маленькой каше" проблемы со стыковкой спрачоников материалов, продукции, контрагентов (вот уж этих справочников в разных приложениях вообще видимо-невидимо), видов деятельности и др. и прикинем, в какие сроки реально получить консолидированные данные при N=10, и среднем количестве подразделений на каждом предприятиии M=8, в каждом из которых используется собственный справочник.

Конечно же, получить полностью идентичные справочники врядли получится. Однако, нужно стремиться минимизировать их количество насколько это возможно. И регламенты-регламенты-регламенты... ПМСМ. И еще важно понимать, что систематизация НСИ - это организационная задача, а не задачка по программированию... :)
Разумеется, не удастся всё, вся и везде подвести под один знаменатель.

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