Заметки: Общие требования к НСИ (нормативно-справочная информация). Управление НСИ

31.01.22

Управление ИТ - Стандарты и документация

Кратко: что такое НСИ. Управление НСИ.

Добрый день, коллеги. 

Тема к обсуждению.

 

Что такое НСИ (нормативно-справочная информация).

Кратко: Справочники, хранящие условно-постоянную информацию.

Цитата: "Ключевое отличие НСИ от однократно вводимой информации состоит в том, что НСИ многократно используется при производстве данных, соответственно, ошибки в ней обходятся очень дорого." пруф.

Пример: Справочник Контрагенты( используются и переиспользуются во многих “документах” и операциях систем. в Заказ клиента, в Актах, в Заказах поставщику и тд)

Есть два способа управления условно-постоянными данными: централизованный ( единая НСИ), децентрализованный ( каждая система сама владеет данными, и сама договаривается с другими системами об интеграциях). ( Есть также Bounded Context, но это требует отдельной статьи).

Рассмотрим Централизованные НСИ.

 

Общий принцип построения централизованных НСИ.

Некая центральная база (или система), имеющая интерфейс доступа, api для работы с данными в базе.

К ней подключаются системы потребители, по понятному-общепринятому протоколу.

Центральная НСИ умеет и отвечает за  хранение, управление, раздачу централизованных данные, оповещает об изменениях, хранит историю  и т.д.

 

 

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

 

Свойства в данных

В общем случае Центральная НСИ может содержать только два свойства: уникальный ИД элемента, и наименование. Остальные свойства могут хранится в системах потребителях.

Все свойства(данные) можно разделить на, условно, два типа:

  1. Свойства уникальные для каждой системы.

  2. НЕ уникальные свойства.

 

Уникальные свойства - управляются системой потребителем. Хранятся в системе потребителе, в обменах не участвуют. (Пример: ГФУ в КА, Группа Финансового учета, в зависимости от которой формируются проводки в КА. Данное свойство важно только для КА. Другим системам не интересно.)

 

 

НЕ Уникальные свойства. Если свойство используется в двух и более системах, оно считается не уникальный. И в общей практике хранится в Центральной НСИ. Управляется (вносится и редактируется) в Центральной НСИ (возможно! в системе потребителе, с понятной обратной связью в центральную НСИ). Участвует в обменах.

 

 

Важно понимать. НЕ уникальные свойства, если не сопровождаются единой центральной НСИ, очень быстро порождают паразитические связи ( обмены) между другими потребителями. Что приводит к снижению достоверности в данных, и в сложности поддержки данных связей. Проще говоря будем ловить ошибки в данных в каждой системе + трудозатраты.

 

И что теперь?

Важно определить какие свойства являются:

  1. Уникальными (напомню: хранятся только в системе потребителе)

  2. НЕ уникальными (хранятся и управляются в центральной НСИ, раздаются всем)

Есть исключения.

Если свойство не значительно (с точки зрения поведения систем) : его можно считать уникальным и игнорировать в обменах, и в управлении НСИ.

Если свойство используется в упрощенном обмене,  между двумя системами, также можно пренебречь его НЕ уникальностью, и обходится без Централизованной НСИ (пример - ставка НДС , которая важна только для КА и БУ).

Как определить: понять, где, в каких процессах, в каких метриках компании, свойства используются.

А дальше уже задача архитектора грамотно выстроить системы и обмены между ними.

НСИ обмен справочники

См. также

Стандарты и документация Оценка проекта Бесплатно (free)

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

13.08.2025    370    0    INK2018    3    

6

Работа с требованиями Стандарты и документация Бесплатно (free)

Удивительно, но до сих пор большинство аналитиков не слышали о своде знаний по бизнес-анализу BABOK Guide и не знают, что фактически уже используют его техники в работе. Расскажем о том, как с помощью техник BABOK сделать ТЗ максимально «живым» – структурировать требования, визуализировать процессы, смоделировать данные и интерфейсы, чтобы ТЗ было понятно и заказчику, и разработчику.

31.07.2025    857    27    otkalo    8    

2

Стандарты и документация Бесплатно (free)

Статья посвящена распространённой проблеме в разработке 1С – чрезмерному формализму технических заданий, превращающих гибкий процесс внедрения в бюрократический кошмар. Мы разбираем, почему объёмное ТЗ не гарантирует успех проекта, как оно может парализовать работу команды и что делать, чтобы перейти от «мертвых» документов к живому процессу разработки. На практических примерах из мира 1С показываем, какие форматы взаимодействия действительно работают и как сохранить баланс между ясностью требований и гибкостью решений.

29.07.2025    1308    0    Vasin86    19    

23

Стандарты и документация Бесплатно (free)

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

04.03.2025    1075    0    3soft    0    

2

Проектирование Стандарты и документация Бесплатно (free)

СППР – удобный инструмент для работы с модификацией системы, в частности, упрощающий и автоматизирующий написание проектной документации. Расскажем о практическом опыте составления в СППР «Описания проектного решения».

18.12.2024    2706    0    user1959522    0    

4

Стандарты и документация Бизнес-аналитик Бесплатно (free)

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

24.09.2024    6013    0    chavalah    19    

20

Стандарты и документация Бесплатно (free)

Когда при внедрении систем 1С всплывает слово «ГОСТ» – практически всегда речь идёт о документе «Техническое задание». И у большинства внедренцев падает настроение, как только им говорят, что надо «написать ТЗ по ГОСТу». Но опытные кулинары знают, как готовить это блюдо так, чтобы оно оставило после себя приятное послевкусие, а не горькое разочарование. О собственных рецептах приготовления документации по ГОСТу пойдет речь в статье.

21.08.2024    4137    64    Laya    3    

24

Стандарты и документация Бесплатно (free)

Как гарантировать актуальную документацию и превратить ваши тесты в красивый фильм? Берём тесты, сценарии, Vanessa Automation, перемешиваем, но не встряхиваем – и рецепт готов. Расскажем о том, как добиться простой и невозможной цели – чтобы документация к вашему продукту соответствовала ему.

12.08.2024    8303    0    fenixnow    3    

25
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. DarkAn 1099 02.01.22 17:09 Сейчас в теме
Хорошо, а дальше тема развиваться будет?
exclusive1c; +1 Ответить
2. exclusive1c 3 31.01.22 10:12 Сейчас в теме
(1)Теперь видимо да)) Спасибо за коммент
Для отправки сообщения требуется регистрация/авторизация