Пример организации и поддержки единого справочника номенклатур GDR

В компаниях с ИТ-отделом, собственным или интегрированнным софтом и множеством справочников знают про проблему соответствия номенклатур (справочников значений).

Пример на пальцах - допустим у вас в 1с есть набор товаров, которые вы регулярно покупаете, например, канцелярия для компании.

А еще у вас есть в екселе прайс от поставщика этих канцтоваров. И вот однажды товар “блок клейкий 200 листов” в прайсе заменяется на “стикеры 200 шт”. Если с этого момента вы будете искать в 1с название из прайса, вы его не найдете, т.е. его там не существует. Вы скорее всего создадите новый объект и назовете его как в прайсе, чтобы иметь возможность сравнивать позиции в прайсе, а значит далее в счетах и фактурах вашего поставщика и в вашей программе.

Хотя по смыслу товар остается тем же, а у вас в 1с для него появляется 2 разных названия.

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

Это был простой пример. Все усложняется когда у вас несколько разных связанных ИТ-систем с разным предназначением со многими такими справочниками.

Например, помимо 1с у вас есть какое-нибудь отдельное приложение или целая система для других целей, которая тоже работает с номенклатурой. Ну например, простенькое планирование мероприятий и ресурсов для них. И там допустим, тоже нужна канцелярия - ручки, блокноты и наши стикеры. И в конце каждого месяца вам надо отчитываться сколько какой канцелярии вы потратили и что вам нужно докупить. Даже если взять и постараться сделать по умному и выгрузить справочник канцелярии из 1с, например на 1 января 2024 года, то дальше начнутся расхождения. У поставщика как мы помним название стикеров поменялось, например в апреле, и в 1с добавился новый элемент. В то же время организаторы мероприятий, скорее всего, чихать хотели на эти мелкие условности и продолжают работать в своей ИТ-системе планирования с их “клейким блоком”.

Но кому-то придется заплатить за эти расхождения, сводя отчеты для оплат, ревизий и планирования.

Чем больше компания, чем больше ИТ-систем и меняющихся с разной периодичностью номенклатур, тем больше в итоге накапливается расхождений. В лучшем случае это просто разбухание базы данных, в худшем - отклонения в отчетности и учете вплоть до принятия неверных решений на основе неверных данных.

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

Дано - французская страховая компания, с десятками связанных ИТ-систем и общеупотребимых справочников, в которой я сейчас тружусь в качестве бизнес-аналитика. Сильно специфичные справочники, которые действуют только в рамках одной системы, типа перечня должностей в каждой дочерней компании, не берем. Для них нам общий “словарь” не нужен, по крайней мере, пока.

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

Но в жизни все несколько иначе. Так, в одной системе национальность может быть “гражданин России”, а в другой “русский”, а в третьей просто “Россия”. Где-то не предусмотрено гражданство Папуа Новой Гвинеи и т.п. И не надо умничать и предлагать все переделать. Как сказал бы Боромир, нельзя просто взять и переписать национальность, сохраненную а базе для какого-нибудь человека 10 лет назад, на другую, даже если она соответствует по смыслу, ведь в документах у человека может быть указано иначе.

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

В этом случае нам и нужен единый справочник - GDR (фр. gestion des données de référence, англ. reference data management), в котором хранится номенклатура - национальности.

Принципиально есть 3 варианта хранения, которые зависят от вашей архитектуры систем и данных:

Вариант 1 - вы для каждого значения номенклатуры GDR храните коды соответствующих значений ваших прочих ИТ-систем.

Вариант 2 - вы для каждого элемента справочника внешней системы храните соответствующий код из GDR

Вариант 3 - микс из предыдущих двух. Для ключевых внешних систем коды хранятся в GDR, прочие сами хранят нужные референсы.

В любом из этих трех случаев мы сможем через соответствующие коды восстановить национальность в любой связанной с GDR системой.

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

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

И одной помарки в рамках назначенных задач или проверок может быть достаточно чтобы откатить на полпути все изменения до нуля и начать все согласования и объяснения с нуля.

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

В общем думайте сами, решайте сами, иметь или не иметь GDR.

#базыданных #itil #deliverymanagement