ведение нси что это

Анатомия системы НСИ

Данная статья основана на реальных событиях,
и все проблемы в ней не вымышленные. (С)

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

Вот и в моём случае оказалась та же картина — система стоит на продуктиве более десяти лет, строилась по тому же принципу, если что нужно, рисуем и включаем в оборот. Таким образом были созданы несколько таблиц для хранения разного рода оборудования. Но вот пришёл час Х, когда стало необходимо добавить ещё пару таблиц для нового оборудования и при этом все (включая старые) должны входить в определённую группу. Это значит, что ссылки на разные таблицы должны быть включены в кросс-таблицу между группой и всеми пятью видами оборудования, то есть для каждого своё поля с констреинтом на соответствующую таблицу. А если ещё одно добавится, менять структуру. И обработку нужно делать в зависимости от того, какие поля заполнены. Вот и возникает первая проблема, как разные таблицы обобщить, что бы с ними одинаково можно было работать и не менять структуру, если добавляется ещё одна. Замечательная мысль, создаём отдельную табличку, которая призвана хранить абстрактное понятие оборудование с указанием типа, а тогда остальные таблички ссылаются по внешнему ключу на своего родителя. На этой радостной волне мы заливаем в созданную табличку записи из одной и пытаемся тоже сделать для другой. Но что-то пошло не так, сработало ограничение первичного ключа, к чему бы это? А к тому, что на заре бурной молодости системы для каждой табличке были свои сиквенсы. Конечно, со временем это безобразие поправили, но старые ключи всё равно остались. Более того, они корнями проросли по внешним ключам с другими таблицам. Фиксируем вторую проблему, связанную со сквозной нумерацией всех справочников.

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

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

Ну мы же молодцы, мы и это победили))) Теперь, попивая чай из своей кружки, начинаешь дискутировать с другими коллегами на тему, что им приходилось решать, и понимаешь, что список проблем пополняется. В обсуждении стоит вопрос как хранить версии одной и той же записи. Хочу оговорится, что версия, это не то, что укладывается в таблицу историчности. В историчности понятно, до такого-то числа было одно название, а начиная с этой даты актуальным становится другое. А в версионности подразумевается, что запись была сначала сохранена с ошибкой, а через несколько часов это поняли и её изменили, и нужно знать все состояния этой записи. Во-первых, здесь должно быть дробление на время, не только сутки. А во-вторых, такие следы нужны в случае разборок. Например, заполняли прайс, ошиблись, успели товар продать по такой цене, а потом поправили, но в конце дня случился дебаланс. Однако решение для таких ситуаций меня лично напрягло, предлагалась все такие изменения хранить в самой таблице. Не буду устраивать холивар на сколько так правильно, но для меня точно обозначилась пятая проблема, а именно хранение изменений записей.

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

Сколько можно наступать на одни и те же грабли, давайте скинимся и купим новые

Начиная проектировать систему с нуля, никто не может предугадать путь её развития, а значит не сможет сказать на каком уровне придётся обобщать, как в описанном примере с оборудованием. Поэтому имеет смысл сразу задать абстрактную сущность, распространяемую на все таблицы НСИ. Таким образом все справочники будут иметь прообраз в едином справочнике с разделением на типы.

Таблица nsi_type системная, заполняется по мере добавления новых справочников. Таблица nsi хранит ключи и системные поля. Заодно создаём собственный сиквенс и тем самым закрываем вторую проблему.

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

Здесь пока представлены вспомогательные функции для обеспечения необходимой инфраструктуры.

Итак стоит задача создать справочник организаций, куда же без него, любое предприятие контактирует со сторонними организациями — это и поставщики, и клиенты, и партнёры. Сразу добавим соответствующий тип в таблицу nsi_type и определим таблицу nsi_organization.

Теперь, пока не поздно, нужно вспомнить про грабли с номером «пять». Если начнём добавлять записи в созданную таблицу организаций, то это событие нужно где-то фиксировать.

А так же в пакет добавлена функция логирования.

Таким образом разрешена пятая проблема, теперь для любой записи НСИ можно посмотреть, что с ней происходило.

Пытаемся добавить туда организацию.

Конечно мы нарвёмся на констраинт nsi_organization_nsi_fk. Поэтому все справочные таблицы должны быть снабжены необходимой доработкой триггеров.

А теперь добавление записи пройдёт без проблем (ключ уже указывать не надо). Заодно в таблице nsi появится первая запись, а так же в таблице логирования будет зафиксировано это событие.

Но пока можно заметить только дополнительные расходы на создание таблицы какого-то справочника, а никак не преимущество единого подхода. Тогда вспомним про четвёртую проблему — нам необходимо хранить историчность данных в таблицах справочника, а так же извлекать актуальное состояние на заданную дату.

В пакет pkg_nsi добавим функцию сохранения записи в историческую таблицу. Хранить запись будем в формате json, поэтому в пакете так же появится возможность получить json для переданного запроса.

Таким образом любой справочник может воспользоваться этой функцией, чтобы увести в историю текущее состояние. Уже хорошо, хоть что-то полезное появилось от такого обобщения))) Для извлечения актуального состояния справочника добавим в пакет соответствующую pipeline-функцию. Записи справочника будут возвращаться в тип, расширенный системными полями.

Применим к нашей таблице nsi_organization.

Функция nsi_organization_table очень полезна, потому как удовлетворяет нашим требованиям и окончательно уводит проблему номер четыре в прошлое.

Идём дальше. Раз у нас появилось такое преимущество с введением единого подхода для работы со всеми справочниками, то воспользуемся им и для хранения дополнительной информации, которой может быть наделена любая запись из любого справочника. Такое механизм уже давно существует, называется EAV-pattern, его и реализуем.

Очень часто в контексте документов имена собственные необходимо использовать в каком-то падеже, поэтому создадим новую таблицу с физическими лицами и по аналогии с организациями добавим обработку триггеров и тип для выборки.

Осталось дополнить пакет pkg_nsi обработкой этой таблицы.

И добавим кого-нибудь в эту таблицу.

Создадим атрибуты для самого востребованного родительного падежа.

В пакете pkg_nsi добавим функции для работы с атрибутами справочников.

Теперь присвоим соответствующие атрибуты.

Таким образом мы победим третью проблему.

Кроме таблиц справочников в системе НСИ также важны отношение между ними. Так, например крупные организации включают в себя различные подразделения, филиалы, отделы и т.п., которые можно выстроить в древовидную структуру. Для начала заведём в нашей системе ещё несколько организаций, которые будут в подчинении у уже существующей «Рога и копыта».

Теперь нужно показать в каком отношении эти организации находятся между собой. Для этого необходима таблица с древовидной структурой и указанием периода действия, потому как всё подвержено изменением во времени и нужно это учитывать.

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

После появления такого инструмента можно смело выстраивать отношения между организациями.

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

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

Осталось только заполнить и собрать необходимые классификаторы.

Ой, как это не читабельно!

Следует не забывать, что кроме отношения включения (в том числе и древовидного), существует отношение пересечения, то есть кросс-таблиц. Здесь добавляется дополнительное условие проверки пересечения по времени.

Всё, теперь мы с уверенностью можем сказать, что закрыли первую проблему.
Конечно можно много чего пытаться прикрутить к этой системе, но я думаю, что поставленную задачу в начале статьи я выполнила, а остальное уже можно рассмотреть в процессе дискуссии.

Материал подготавливался на версии Oracle 18c, хотя нативное поддержание формата json уже присутствует в версии 12. Здесь ссылка с архивом скриптов.

Источник

Способ оптимизировать работу предприятия – НСИ от ЭТП ГПБ

Правильное структурирование нормативно-справочной информации – одна из фундаментальных задач современного бизнеса, тесно связанная с закупками, логистикой, управлением персоналом и целой плеядой других важных направлений. Хорошо организованные каталоги ТМЦ позволяют рационально распределять рабочее время, выходить на новые рынки, находить крупных заказчиков, выгодно управлять закупками и всегда быть в курсе положения дел с ТМЦ на предприятии.

На вебинаре «Ключевые проблемы ведения НСИ» эксперт ЭТП ГПБ, руководитель проекта по разработке и ведению системы НСИ Анастасия Рожкова рассказала, почему важно структурировать нормативно-справочную информацию, как эффективно решать возникающие проблемы и что ощутимо выигрывает организация с верно выстроенной системой НСИ.

Мы отобрали самые важные мысли из вебинара Анастасии и спешим поделиться полезными знаниями в этом материале.

Почему нормативно-справочная информация важна?

Значимость процесса закупок для предприятия играет очень большую роль. Эффективная работа самого предприятия зависит от своевременного, стабильного и качественного осуществления закупок необходимого количества материалов, товаров или сырья.

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

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

Когда предприятие разрастается и увеличивается количество ТМЦ, которые оно закупает, часто возникают проблемы. Некоторые решают их на ранних этапах, но многие не задумываются об этом.

Что такое нормативно-справочная информация?

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

В части ТМЦ нормативно-справочная информация – это классификаторы, справочники, словари, вспомогательные константы, мини-справочники и т.д.

Справочники ТМЦ могут быть разделены на:

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

Ошибки в ведении НСИ могут привести к серьезным проблемам для предприятия – простою, проблемам с запуском новых продуктовых линеек, неравномерному распределению задач, отсутствию понимания расположенных на складе запасов и другим общим трудностям.

Ключевые проблемы ведения НСИ

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

1. Отсутствие единого подхода

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

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

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

2. Отсутствие единой методологии

Следующая закономерно вытекающая из отсутствия единого подхода проблема ведения НСИ на предприятии – отсутствие методологии.

Методология устанавливает требования к процессу ведения справочника:

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

3. Дубликаты

Следующая проблема – возникновение дубликатов, когда один и тот же продукт может получать различные наименования и несколько различающееся описание характеристики от разных сотрудников, отделов, в разных справочниках и классификаторах. Из-за отсутствия единого подхода дубли могут постоянно копиться, расти в числе, «замусоривать» справочник, делать его громоздким и неудобным в использовании.

ПРИМЕР: Рассмотрим «хомут нейлоновый пластик», также его могут называть стяжками. Какие проблемы могут быть? Для данного класса позиций: кто-то может назвать номенклатуру стяжкой, кто-то хомутом. Например, если на предприятии не регламентировано, что только определенная группа сотрудников вводит номенклатуру в справочник, и это доступно разным отделам, может возникнуть множество дубликатов.

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

Появление дубликатов ведет к негативным последствиям. Из-за того, что справочник не уникален, становится невозможно достоверно отследить движение ТМЦ. Например, 7 хомутов-стяжек, заведенных в разные справочники, являются на деле одной фактической позицией. Они разошлись по разным складам, например, и в разных складах используются, их считают за разные позиции. И найти на одном и том же складе определенный хомут бывает сложно. Проблемы с точной идентификацией позиции могут вести к невозможности ее использования, исключению из рабочего процесса, ненужным закупкам и т.д.

Сложность сопоставления

Цепочка сложности сопоставления продукции выглядит следующим образом (в качестве примера):

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

Грязный справочник создает осложнения при создании отчетов, аналитике, формировании будущих потребностей в ТМЦ. Часто в таких условиях то, что лежит на складе, может не соответствовать позициям в справочнике, не может быть найдено и использовано.

Дополнительная классификация

При работе по запросам заказчика со стандартизированными товарами и в госзаказе ТМЦ должны снабжаться дополнительными классификаторами, кодами – ОКПД2, КТРУ, ЕСКЛП и т.д. Соответственно, каждой позиции, которая должна быть представлена к закупке, должен быть присвоен стандартизированный классификатор, а она должна ему соответствовать.

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

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

Пример: Зачем нужны коды? Зачастую на площадках заказчики проводят предварительный анализ имеющейся номенклатуры или поиск поставщиков, и обычно это делается по кодам общероссийских классификаторов. Например, на Торговом Портале ЭТП ГПБ реализован поиск по ОКПД2. После того, как заказчик опубликовал свою потребность в закупках, он рассылает всем зарегистрированным поставщикам информационное сообщение о том, что есть потребность в определенной продукции. Например, заказчик хочет купить автошины. Соответственно, он устанавливает ОКПД2 в своей продукции, и все поставщики на портале, кто имеет у себя в прайс-листах позиции схожие по данному коду ОКПД2, получат рассылку с запросом. Соответственно, и поставщикам, и заказчикам выгодно иметь позиции, соответствующие стандартизированной классификации.

Отслеживание востребованности

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

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

Решение проблем ведения НСИ на предприятии по шагам

Обеспечение регламента и настройка бизнес-процессов НСИ – это системная задача, которая требует комплексного подхода.

Процесс настройки НСИ включает следующие шаги:

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

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

НСИ от ЭТП ГПБ

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

ЭТП ГПБ предлагает комплексное решение задачи по нормализации от экспертов рынка, постоянно взаимодействующих со сложнейшими классификаторами крупных заказчиков (в том числе, ГК Газпром). Решения по НСИ от нашей команды – это возможности по интеграции со всеми необходимыми сервисами, отточенный опыт ведения справочников, поддержка и адаптация к рыночным условиям с масштабированием под клиента с учетом требований бизнеса и практических задач предприятия.

Рассмотрим МДМ-решение на примере «MDM управление НСИ» от ЭТП ГПБ.

Сама система это:

Наиболее важные преимущества:

Преимущества ведения единой НСИ

Единая система ведения нормативно-справочной информации демонстрирует целый ряд преимуществ для предприятий:

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

«MDM управление НСИ ТМЦ» от ЭТП ГПБ позволяет освободить время сотрудников, автоматизировать бизнес-процессы предприятия, структурировать списки справочной информации по продукции и оптимизировать бизнес-процессы, на практике повышая конкурентоспособность, эффективность и устойчивость организации.

НСИ от ЭТП ГПБ – изучайте вопрос с нами

Для понимания важности НСИ в организации снабжения и поддержании бизнес-процессов предприятия Обучающий Центр ЭТП ГПБ проводит регулярные вебинары с участием экспертов рынка, где подробно разбираются подходы к нормализации, важность НСИ для предприятия, даются практически полезные советы по ведению справочников самостоятельно и разъясняются случаи, в которых важно доверять профессионалам.

16 сентября 2020 года состоялся вебинар «Ключевые проблемы ведения НСИ», спикером которого также выступила руководитель отдела НСИ ЭТП ГПБ Анастасия Рожкова.

Источник

Создание единой системы управления НСИ

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

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

Централизованное управление нормативно-справочной информацией с DATAREON

Специалисты DATAREON имеют значительный опыт систематизации нормативно-справочной информации, разработки единых регламентов использования и ведения НСИ, внедрения специализированных автоматизированных систем управления НСИ на базе MDM-системы «1С:Предприятие 8. MDM Управление НСИ». В рамках выполненных проектов специалистами DATAREON проводилась экспертная обработка записей справочников МТР, услуг, контрагентов, справочников финансового блока, организационной структуры и управления персоналом.

Успешный опыт работы в области управления НСИ, апробированные на практике эффективные методики и собственная экспертиза позволяют DATAREON оптимизировать использование ресурсов предприятий-клиентов в результате автоматизации управления НСИ.

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

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

Нормативно-справочная информация — условно-постоянная составляющая общей корпоративной информации. Она используется при регламентации деятельности компании, обеспечивая «сшивку» данных, сопровождающих бизнес-процессы компании. Другими словами, НСИ — это ядро единого информационного пространства организации, включающее в себя набор справочников, словарей, классификаторов, стандартов, регламентов, используемых в деятельности предприятия.

Предпосылки для организации централизованного управления нормативно-справочной информацией

Создание единого информационного пространства — необходимое условие эффективного управления современными крупными и средними предприятиями. Формирование единой среды предполагает интеграцию управленческих процессов, сопровождающуюся нормализацией информационных потоков. Часто перемещение информации на разных внутрикорпоративных технологических участках поддерживается различными информационными и учетными системами. Соответственно, возникает необходимость интеграции этих систем.

Задача интеграции информационных и учетных систем состоит из двух взаимосвязанных частей: интеграции данных и следующей за ней интеграции приложений. Выполняя интеграцию данных, предприятию следует провести унификацию и стандартизацию нормативно-справочной информации.

Для чего необходимо централизованное управление НСИ

Менеджеры DATAREON будут рады ответить на все вопросы по тел. +7(495)280-08-01. Также вы можете написать нам через форму

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *