Единая отраслевая система нормативно-справочной информации. Управление нси в информационных системах Нормативно справочная информация автоматизированной системы

Дмитрий Гулько
Канд. техн. наук, президент
НЦИТ «Интертех»

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

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

Одно из характерных заблуждений состоит в том, что система НСИ рассматривается не как самостоятельный надструктурный ИТ-компонент, а как «придаток» к той или иной ERP-системе. Вот и получается - сколько прикладных систем, столько и «придатков». На одном из крупнейших российских предприятий нефтехимического профиля при проведении обследования было обнаружено более 25 не связанных (!) справочников товарно-материальных ценностей (ТМЦ) и сырья. О какой консолидации информации, о каком мониторинге и оптимальном планировании может в этом случае идти речь?

На наш взгляд компаниям пора понять, что НСИ - не элемент ERP-системы, а часть общекорпоративной ИТ-инфраструктуры. От качества и надежности основных данных (т. е. НСИ) во многом зависит и качество собственно управленческой информации. Ведь никто пока не отменял принципа GIGO (garbage in - garbage out, что в смысловом переводе означает: «Если информационный мусор на входе, то такой же мусор и на выходе»).

Если не часть ERP, то что же?

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

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

Рис. 1 . Схема единой системы НСИ

Единая система НСИ

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

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

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

Требования и принципы построения
единой системы НСИ

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

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

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

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

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

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

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

И, наконец, структуризация необходима для громоздких, многочисленных элементов/записей и информационных массивов, например справочника материально-технических ресурсов (МТР).

Целесообразно также выделить принципы построения единой системы НСИ.

Корпоративность предусматривает необходимость использования ЕС НСИ в масштабе всей компании, ее структурных подразделений и предприятий.

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

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

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

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

Интегрируемость ЕС НСИ с существующими ERP- и другими корпоративными информационными системами.

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

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

Рис. 2. Этапы создания единой системы НСИ

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

Сервисно-ориентированная архитектура

Крупные компании (причём не только в России, но и в передовых странах по внедрению ИТ-приложений, таких как США, европейские государства и др.) по мере роста бизнеса, его диверсификации или перепрофилирования, укрупнения за счет слияний и поглощений сталкиваются с одними и теми же проблемами: в первую очередь это разноплатформенный (гетерогенный) ИТ-ландшафт, порождающий несогласованность информации в различных разобщенных корпоративных приложениях. Очень важно понять следующее: проблемы гетерогенного ИТ-ландшафта - это не только «историческое наследие». Это возможный путь развития .

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

Безусловно, отсутствие в крупных компаниях, на фоне гетерогенного ИТ-ландшафта, эффективной системы поддержки единой унифицированной НСИ - ключевая проблема автоматизации учетно-управленческих задач. Другая проблема - обеспечение взаимодействия эксплуатируемых систем. Третья - упорядочение, унификация функций (сервисов) в масштабе компании, устранение функционального дублирования. И, наконец, четвертая - возможность модульного наращивания ИТ-ландшафта «по кирпичикам».
Одним из подходов, дающих внятное решение упомянутых проблем, является сервисно-ориентированная архитектура (service-oriented architecture, SOA). При этом надо понимать, что SOA - это не какая-либо конкретная технология, а именно подход, концепция. Используемые в Web-сервисах технологии, стандарты и протоколы (SOAP, WSDL, UDDI и др.) нередко служат технологической основой SOA.

Еще в 2003 году в одном из отчетов Gartner было предсказано, что «...в 2008-м SOA станет превалирующим подходом в инженерии ПО, прекращающим 40-летнее доминирование монолитной ПО-архитектуры». В конце 2003-го журнал CIO Magazine провел опрос, в котором более 50% респондентов отметили, что они в той или иной степени заняты разработкой SOA. В марте 2004-го Smith Barney (аналитическое подразделение Citigroup), опросив сто ведущих CIO, выяснило, что SOA является главным приоритетом в области новых технологий. Основной целью перехода на SOA безусловно является сохранение инвестиций, вложенных и вкладываемых в существующий ИТ-ландшафт, а также:

• пошаговое, эволюционное наращивание сервисов (приложений) по мере роста бизнеса и увеличения потребностей в ИТ-обеспечении, модульный принцип построения;
• сшивка разноплатформенных приложений в единую информационно-управленческую среду;
• платформенная толерантность, возможность сохранения существующих, в том числе устаревших, систем и платформ и включения в общекорпоративный ИТ-ландшафт разноплатформенных приложений «best-in-class» независимо от их платформы;
• органичность, простота и надежность использования внешних сервисов (т. е. сервисов, предоставляемых внешними организациями на условиях аутсорсинга);
• устойчивость, работоспособность системы в целом и других компонентов ИТ-инфраструктуры при сбое одной из систем.

Проблемы НСИ в интерьере SOA

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

Иными словами, унификация сервисов (функций) подразумевает унификацию основных данных (НСИ). Так, если сервис «формирование заявки на приобретение материала» поддерживается модулем «Заявочная кампания», написанным местным разработчиком ПО, а сервис «запрос информации об остатке материала на складе» - ERP-системой на платформе SAP R/3, то для учета остатков при планировании потребности (т. е. для смежной работы двух сервисов в одном бизнес-процессе) нужно, чтобы оба сервиса работали с единым справочником материалов (или, что по сути то же самое, со справочниками, полностью увязанными между собой посредством переходных ключей).

Рис. 3. Схема-фрагмент СОА

Еще одной важнейшей особенностью SOA является то, что «сервисы» могут быть доступны из любой точки корпоративной сети независимо от ее расположения - достаточно лишь иметь доступ к сети. Для хранения спецификаций и описаний «сервисов» в SOA предусмотрен так называемый регистр и репозитарий сервисов (РРС), где хранятся адреса доступа к каждому зарегистрированному «сервису», данные о его расположении в сети, описание правил вызова, регламенты его предоставления и т. п. Помимо собственно сервисов и информационной шины обмена запросами и данными, о чем очень часто говорят при обсуждении SOA, важнейшим компонентом этой архитектуры является портал, который значительно реже упоминается именно в контексте SOA.

Для примера на рис. 3 показана схема-фрагмент сервисно-ориентированной архитектуры приложений, участвующих в бизнес-процессе «Заявочная кампания»; здесь как раз можно видеть важнейшие компоненты SOA, в том числе РРС и портал. Кроме того, из этого рисунка понятна очевидная востребованность сервисов ЕС НСИ (компонент Master Data Managment, MDM) на протяжении всего процесса. При этом на схеме наглядно продемонстрирован механизм вызова сервисов и взаимодействия приложений в SOA.

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

Рис. 4. Уровни ИТ-инфраструктуры
в сервисно-ориентированной архитектуре

Интересным на наш взгляд является выделение уровней ИТ-инфраструктуры в сервисной архитектуре. На рис. 4 показаны семь уровней, определяющих структуру «вглубь». Показательно, что данные НСИ составляют нижний уровень - «информационный фундамент» всей ИТ-инфраструктуры. Система управления НСИ (через MDM) может строиться на самостоятельной независимой платформе, состоять из нескольких бизнес-приложений (в том числе АРМ пользователя, АРМ эксперта, АРМ администратора) и предоставлять сервисы, доступные из корпоративной сети. Особо следует отметить, что такая сервисно-ориентированная архитектура весьма удобна при аутсорсинговой организации процесса ведения данных НСИ. При этом сотрудники компании, используя сервисы доступа к НСИ и обращаясь с запросами в службу ведения НСИ, получают требуемый уровень обслуживания (закрепленный в SLA-SLR), не задумываясь о том, где и кем обслуживается данный сервис.

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

По данным TAdviser, объем рынка систем управления НСИ составляет около 1,5 млрд рублей на конец 2017 года. Спрос на эти решения растет на 20-25% в год - прямо пропорционально росту цифровизации бизнеса. Ускорению динамики способствует рост проникновения облачных сервисов на отечественном рынке (на уровне около 20% в год), а также запуска инициатив по информатизации государства и общества в рамках реализации программы .

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

В фокусе внимания

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

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

По состоянию на 2018 год до 75% этого рынка приходится на консалтинг и около 25% занимают лицензии. Такая ситуация обусловлена тем, что помимо непосредственного создания справочника, компаниям необходима его интеграция с другими информационными системами, а для справочников клиентов - с системами защиты персональных данных, отмечают в «Крок ».

Новые тренды

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

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

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

Топ-8 игроков российского рынка систем управления НСИ

Сабир Асадуллаев и Александр Карпов
Опубликовано 09.11.2010

Основные понятия и терминология

Мастер - данные (МД) включают в себя информацию о клиентах, сотрудниках, продуктах, товарах, поставщиках, которая, как правило не является транзакционной по своей природе.

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

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

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

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

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

При этом НСИ и МД имеют много общего, поэтому в тех случаях, когда рассматриваемые факторы касаются и НСИ, и МД, мы будем упоминать их как «НСИ и МД», например, «система ведения НСИ и МД».

Общие недостатки традиционного ведения НСИ и МД

Наиболее распространенной и очевидной проблемой традиционного ведения НСИ и МД является отсутствие поддержки временных изменений. Адрес, как правило, является одной из важнейших компонент НСИ и МД. К сожалению, адреса меняются. Клиент может переехать, но может «переехать» целый дом и даже улица. Так, в 2009 году адрес комплекса зданий «Башня на набережной» изменился с «Краснопресненская набережная, дом 18» на «Пресненская набережная, дом 10». Таким образом, запрос “Какое количество корреспонденции было доставлено в офис компании, арендующей помещения в «Башне на набережной» в 2009 году?” должен корректно обрабатывать записи о доставках с двумя разными адресами.

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

Таким образом, корпоративное ведение НСИ и МД включает в себя три категории мероприятий:

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

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

Технологические недостатки ведения НСИ и МД

Нет единой модели данных НСИ и МД

Единая модель данных НСИ и МД отсутствует, или она не формализована, что не позволяет эффективно использовать объекты НСИ и МД и затрудняет любую автоматизацию работы с данными.

Модель данных является основной и самой важной частью ведения НСИ и МД, отвечая, к примеру, на следующие вопросы:

• что включать в идентифицирующие атрибуты объекта НСИ и МД?
• что из всех атрибутов объекта НСИ и МД хранить в модели данных и отнести к НСИ и МД, а что отнести к операционным данным и оставить в эксплуатируемой информационной системе?
• как провести интеграцию по модели с внешними идентификаторами и классификаторами (ОКПО, ОКУД)?
• дает ли совокупность двух атрибутов из различным ИТ систем третий уникальный и важный с точки зрения бизнеса атрибут?

Нет единого регламента ведения истории и архивации

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

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

Сложность отождествления объектов НСИ и МД

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

Возникновение дубликатов объектов НСИ и МД

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

Несогласованность метаданных НСИ и МД

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

Ссылочная целостность и синхронизация модели НСИ и МД

В реальной жизни все объекты НСИ и МД, находящиеся в пространстве своей IT системы, содержат в себе не только значения, но и ссылки на другие НСИ и МД, которые могут находиться (и вестись) в отдельных внешних системах. Здесь в полный рост встает проблема синхронизации и поддержки целостности всей модели НСИ и МД организации. Одним из общепринятых путей решения такого рода проблем является переход к использованию НСИ и МД которые ведутся и импортируются в организацию извне (к примеру, справочники КЛАДР, ОКВЭД, ТН ВЭД, ФСКП и ЕКПС).

Рассогласование жизненного цикла объекта НСИ и МД

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

Выработка правил очистки

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

Неверный выбор мастер-системы ведения НСИ и МД

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

Неготовность ИТ систем к интеграции НСИ и МД

Для того, чтобы полноценно внедрить ведение НСИ и МД в существующие ИТ системы предприятия, необходимо провести интеграцию этих систем и, чаще всего, эта интеграция необходима не как единовременный и локализованный акт, а как изменение процессов, живущих внутри ИТ систем. Помимо интеграции для работы в операционном режиме (online), необходимо провести интеграцию для проведения первоначальной пакетной загрузки данных (ETL), а также для проведения процедур ручной сверки (реконсиляции).

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

Примеры проблем традиционного ведения НСИ и МД

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

Паспортные данные как уникальный идентификатор

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

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

Адрес как уникальный идентификатор

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

Необходимость массового переоформления договоров

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

Расхождение согласованных данных

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

Преимущества корпоративного ведения НСИ и МД

Корпоративное ведение НСИ и МД обеспечивает следующие преимущества:

• Выполнение требований закона и снижение рисков
• Снижение затрат
• Повышение гибкости для поддержки новых бизнес стратегий.

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

Выполнение требований закона и снижение рисков

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

Рост прибылей и удержание клиентов

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

Снижение затрат

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

Повышение гибкости для поддержки новых бизнес стратегий

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

Архитектурные принципы системы ведения НСИ и МД

Ресурсы для скачивания

static.content.url=http://www.сайт/developerworks/js/artrating/

Zone=Information Management

ArticleID=577045

ArticleTitle=Ведение НСИ на практических примерах

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

Требование обеспечения взаимодействия и унификации различных прикладных систем бизнес-процессов протекающих на http://en.wikipedia.org/wiki/Service_oriented_architecture предприятиях и в различных организациях, консолидации отчетной документации, приводит к необходимости построения системы нормативно-справочной информации. Систему нормативной справочной информации образуют группы объектов, построенных на общероссийских, отраслевых и корпоративных (внутренних) [классификаторах] и справочниках.

Основные проблемы НСИ в корпоративных информационных системах:

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

Информационные системы Нормативно-Справочной Информации .

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

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

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

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

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

Системы Управления Справочниками можно приравнять к международному понятию Master Data Management (MDM), которые могут рассматриваться как часть Service-Oriented Аrchitecture (SOA).

Принципиальным является, что словари, стандарты, правила, нормативы, которые обыкновенно включают в понятие НСИ, не являются объектами систем MDM.

См. также

• Блог по НСИ Сабира Асадуллаева
• SAP Master Data Management

Ссылки

Wikimedia Foundation . 2010 .

Смотреть что такое "НСИ" в других словарях:

НСИ - несанкционированный съём информации Источник: http://www.energosys.ru/?nav=entr&id=6105 НСИ нормативно справочная информация; нормативная справочная информация юр. НСИ нашлемная система индикации в маркировке …

НСИ - нормативно справочная информация … Словарь сокращений русского языка

НСИ Банк - Банк Невастройинвест http://nsvbank.ru/​ банк., организация, Санкт Петербург … Словарь сокращений и аббревиатур

НСИ Рунавик Полное название Nes Sóknar Ítróttarfelag Runavík Основан 1957 Стадион Рунавик … Википедия

Полное название Nes Sóknar Ítróttarfelag Runavík Основан 1957 Стадион Рунавик … Википедия

НСИ Рунавик Полное название … Википедия

Нескл., мн. (ед. манси, нескл., м. и ж.). Народ, составляющий коренное население Ханты Мансийского автономного округа РСФСР, а также лица, относящиеся к этому народу … Малый академический словарь

И грунши, груси, нескл., м. и ж … Русское словесное ударение

Манси, нескл., м. и ж. (народ) … Русское словесное ударение

ЕОС НСИ - единая отраслевая система управления нормативно справочной информацией Источник: rosatom.ru … Словарь сокращений и аббревиатур

Книги

• Интегрированные системы проектирования и управления. SCADA. Учебное пособие , Кузяков Олег Николаевич , Мартынюк Роман Васильевич , Музипов Халим Назипович , Хохрин Сергей Александрович , Чащина Маргарита Викторовна , В учебном пособии рассмотрены основные сведения о программах системы реального времени "Сириус-SCADA". Описана программа "Редактор БД НСИ", предназначенная для создания баз данных… Категория: Автоматика. Вычислительная техника Серия: Учебники для вузов. Специальная литература Издатель: Лань ,
• Интегрированные системы проектирования и управления. SCADA , Музипов Х.Н. , Рекомендовано Региональным отделением УрФО УМО вузов РФ по образованию в области радиотехники, электроники, биомедицинской техники и автоматизации в качестве учебного пособия для студентов… Категория:

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

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

Приведем пример иерархии подразделений:

Из этого примера видно, что производство может быть структурировано до подразделений (участков, секторов, групп, отделений) с любым уровнем вложенности.

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

Перечислим реквизиты производственного подразделения,значения которых необходимо определить в подсистеме «Управление производством».

График работы. Выбирается из справочника «Графики работы».

Элемент этого справочника определяет расписание работы – время начала и окончания работы отдельно на каждый день недели и отдельно – на все предпраздничные дни. Для каждого дня недели можно отдельно указать время начала и окончания работы согласно графику, причем временных отрезков работы может быть несколько на день недели, например, с 8.00 до 13.00 и с 14.00 до 18.00. График работы для подразделения необходим для того, чтобы процедура расчета графика производства могла определить количество часов работы, доступных в подразделении, на каждый календарный день.

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

Интервал планирования . Определяет, какой интервал будет применяться для подразделения при расчете графика производства по этапам. Варианты: «День», «Неделя», «Месяц».

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

Критерии выбора интервала планирования для подразделения – соответствие длительности типичных этапов, выполняемых в подразделении, и длительности интервала. Например, если большинство этапов в подразделении имеют длительность не более нескольких дней, то разумно использовать интервал «День». Если типичная длительность этапа существенно превышает неделю, то разумно использовать интервал «неделя».

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

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

Способ управления маршрутными листами . Эта настройка используется при управлении Маршрутными листами, выполняемыми в подразделении.

Варианты:

«Методика ББВ/УББВ». Расписание выполнения МЛ формируется для ключевых РЦ, контроль выполнения МЛ производится по прохождению МЛ предварительного и завершающего буфера.

«Пооперационное планирование». Расписание формируется для всех РЦ и операций маршрутного листа. Дополнительно нужноуточнить «Способ планирования» -«Вперед» или «Назад».

Склады (складские территории)

Склад с точки зрения планирования производства, является объектом производственной системы, обеспечивающим потребности производственных подразделений в материалах и полуфабрикатах.

При расчете графика формируется график потребностей на складах в материалах и полуфабрикатах (номенклатура, характеристика, количество, интервал планирования).

Склад, с которого «запитывается» производственное подразделение по умолчанию – определяется реквизитом подразделения.

Но не наоборот: реквизит «Подразделение» в справочнике «Склад» не влияет на планирование (и служит для учетных целей).

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

Бригады и состав бригад

Бригада является непосредственным исполнителем работ по этапу (операций) в цехе. Для учета выработки сотрудников по Маршрутному листу локальный диспетчер формирует документ «Бригадный наряд», в котором указывает бригаду, и виды работ которые выполнила бригада согласно Маршрутному листу.

Бригада состоит из сотрудников. Состав бригады устанавливается документом «Формирование состава бригады », и действует с даты, указанной в документе.

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

Виды рабочих центров, рабочие центры

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

Вид рабочего центра состоит из конкретных рабочих центров, например, единиц оборудования. Синоним вида рабочих центров – «Группа взаимозаменямых рабочих центров».

Примеры рабочих центров:

- Единица оборудования

- Рабочее место

- Группа рабочих (бригада или объединение по профессиональному признаку)

- Сотрудник

- Единица оснастки

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

Реквизиты вида рабочих центров следующие:

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

Максимальная доступность (час, мин, сек). Определяет максимальную длительность обработки одной партии этапа в интервале подразделения, к которому принадлежит вид РЦ. По одной партии этапа не может быть назначена длительность обработки в интервале большая, чем максимальная доступность.

В текущей версии УП2 настройки видов РЦ, сохранив описанную суть, уже несколько изменились. Теперь флажками можно задать:

- Учитывать ли доступность времени РЦ в составлении графика на верхнем уровне. И если да, то будет ли этот РЦ загружаемым или нет.

- Задействовать ли РЦ в управлении производством по Маршрутным листам на нижнем уровне.

На следующей схеме показана структура и взаимосвязь справочников «Структура предприятия», «Виды рабочих центров», «Рабочие центры».

Ввод доступного времени рабочих центров

Для ввода фонда доступного времени рабочих центров по интервалам используется документ «Доступность рабочих центров». В шапке документа выбирается подразделение, вид рабочего центра, период документа.

Табличная часть документа разворачивается по колонкам - интервалам подразделения (например, дням) в периоде документа.

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

Ресурсные спецификации

Ресурсная спецификация как сетевой график

Известны различные типы спецификаций, например – конструкторские спецификации, пооперационные технологические карты маршрутов,«расцеховки», как маршруты прохождения детали по подразделениям.

Наиболее общий способ описания процесса изготовления любого изделия – это сетевой график.

Ресурсная спецификация описывает сетевой график изготовления изделия.

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

Дуги – взаимозависимость между этапами, показывают, по завершению каких этапов можно начинать следующие этапы.

Сетевым графиком удобно описывать любой производственный процесс – в дискретном, непрерывном производстве, в строительстве, в проектной деятельности.

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

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

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

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

Пример ресурсной спецификации, как сетевого графика с этапами-узлами показан на следующей схеме:

Структура ресурсной спецификации

Структура ресурсной спецификации, как объекта конфигурации, показана на следующей схеме:

Ресурсная спецификация содержит:

Список выходов,

Список материальных входов,

Список трудозатрат (по видам работ),

Список этапов.

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

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

Т.е. это те компоненты, которые для данного этапа не являются выходами других этапов этой же спецификации.

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

Такой каскад спецификаций используется при формировании спецификации для конкретной строки заказа на производство. В спецификацию строки заказа копируется весь каскад связанных ресурсных спецификаций.

В реквизите «Оптимальное количество передачи между этапами » можно указать количество партии изделия (результата работ), которое целесообразно передавать между этапами. При расчете графика производства количество этапа разбивается на данные партии, и каждая партия планируется отдельно, исходя из времени доступности загружаемых видов РЦ.

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

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

По каждому виду работ в периодическом регистре сведений «Расценки » можно указать действующую расценку на единицу вида работ.

Этапы ресурсной спецификации

Ресурсная спецификация может быть одноэтапной или многоэтапной.

Если спецификация одноэтапная – реквизиты единственного этапа редактируются непосредственно в форме спецификации. Если спецификация многоэтапная – то спецификация содержит список этапов. Для редактирования реквизитов этапа нужно открыть отдельную форму этапа из списка этапов.

Последовательность выполнения этапов определяется реквизитами этапа: «Номер этапа», «Номер следующего этапа». По номеру этапа иномеру следующего этапа выстраиваются связи между этапами в виде сетевого графика этапов.

Реквизиты этапа определяют основные параметры планирования этапа:

Подразделение, в котором выполняется этап. Для этапа определяется только одно подразделение. Если одни и те же этапы могут выполняться в разных подразделениях – то необходимо создавать разные ресурсные спецификации

Одновременно производимое количество. Р азмер партии или объем работ, для которого нормируется время выполнения этапа. Например, если в реквизите указана единица, то время выполнения этапа нормировано на единицу.

Флаг «Планировать работу видов РЦ» . Определяет способ нормирования длительности этапа.

Флаг включен. В этапе необходимо указать, какие виды РЦ будут загружены этапом и длительность обработки одновременно производимого количества на загружаемом виде рабочего центра. Эти виды РЦ могут оказаться «узкими местами» при выполнении графика производства, поэтому рассчитывается их загрузка в графике. Кроме того, необходимо указать предварительное (до обработки на загружаемом виде РЦ) и завершающее буферное время. Буфера в графике производства занимают отдельные интервалы. Напомним, что если время обработки до загружаемого вида РЦили после намного меньше длительности интервала, то указание буферных времен может привести к неоправданному захвату буферами целых интервалов и соответственно, к неоправданному увеличению длительности этапа в графике производства.

Флаг выключен. В этапе указывается время его выполнения, для любого количества партии. Считается, что за это время этап будет выполнен в любом случае, независимо от количества в этапе. Флаг можно выключить в этапах, выполнение которого не связано с обработкой на загружаемых видах РЦ («т.н. «узких местах»), соответственно, считается, что подразделение при выполнении такого этапа имеет (относительно подразделений с «узкими местами») неограниченные производственные мощности.

Флаг «Непрерывный » этапа определяет,можно ли разбивать в графике выполнение этапа на несколько не соседнихинтервалов.

Если флаг включен – то этап выполняется непрерывно и может располагаться в графике только в соседних интервалах.

Если флаг выключен – то выполнение этапа можно прерывать, т.е. часть этапа повремени можно быть расположена в графике в одном интервале, а часть – в другом,не примыкающим к первому, интервале.

Критерий непрерывности – хоть одна операция внутри этапа является непрерывной и сопоставима с длительностью интервала. К таким операциям относятся, например, термообработка, покраска, сушка и т.д.

Различие между планированием «прерывных» и «непрерывных» этапов показано на следующей схеме: