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

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

Рассматривая проблему НСИ в контексте автоматизации бизнеса, важно понять, что вопреки распростаненному заблуждению НСИ не является частью 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 игроков российского рынка систем управления НСИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Варианты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Сотрудник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В состав НСИ обычно входят следующие информационно-аналитические компоненты:

• справочники
• классификаторы, например, такие как ОКДП, ОКАТУ и т.д
• различные словари

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

Особенности и достоинства НСИ

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

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

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

H4 class="g-subhead">Определение нормативно-справочной информации (НСИ)

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

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

Основу НСИ организации составляют три основные группы:

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

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

НСИ в организациях и фирмах

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

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

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

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

За иллюстрации отдельное спасибо замечательному художнику Васе Ложкину .

Случай первый. Как загрузить вагон и маленькую тележку

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

Живая история
Проект был согласован со всеми заинтересованными сторонами (в этом нас убедило руководство заказчика) и разработан в заданные сроки в соответствии с утвержденными требованиями.

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

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

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

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

Случай второй. Как хотим, так и используем

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

Живая история

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

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

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

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

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

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

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

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

Случай третий. Не слонёнок, а слон, да еще и должен летать

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

Обычно у заказчиков среднее количество записей на один справочник составляет от нескольких сотен до нескольких тысяч. Наш недавний рекордсмен – справочник, в котором было 11 млн. записей. Но этот заказчик преподнес нам сюрприз. В его справочнике оказалось свыше 100 млн. записей. Загружали мы его больше суток, т.к. при начальной загрузке выполнялось множество проверок данных. Это не было бы большой проблемой, но заказчик потребовал, чтобы справочник загружался за несколько минут.

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

Случай четвертый. Сложный фокус с файлами

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

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

Подробнее о системе NORMA.

Задачи наших заказчиков во многом схожи, и мы решили снизить затраты на программные разработки и сократить время проектов, создав собственную универсальную платформу для ведения НСИ и основных данных (Reference Data Management & Master Data Management). Система существует уже более 10 лет, и все эти годы мы в ЛАНИТ ее активно развиваем.

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

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

В ответ на возникновение различных событий в системе, например, события внесения изменений в справочник, могут запускаться подключаемые программные компоненты, написанные на C#, которые могут как проверять данные, так и взаимодействовать с внешними системами и, собственно, самой системой NORMA. Практически все функции системы доступны через веб-сервисы.

Система может масштабироваться как вертикально, путем увеличения мощности сервера приложений и базы данных, так и горизонтально за счет использования многоузлового сервера приложений, в котором каждый узел или группа узлов отвечает за выполнение отдельной функции. Для хранения НСИ система может использовать Microsoft SQL Server, Oracle или PostgreSQL.

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

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

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

Случай пятый. Я привыкаю к несовпадениям

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

В этот раз мы дальше нескольких презентаций не продвинулись. Наша система NORMA очень понравилась технарям. Она закрывала все их существующие проблемы. Дальше пришла очередь показывать систему руководству, и вот тут произошел облом десятилетия. Высокий руководитель посмотрел, послушал и сказал: «Мы тут все работаем на продуктах Apple, у них есть определенный стиль, а ваша система в этот стиль не вписывается. Мы ее даже рассматривать не будем».

Подобные истории случаются в различных проектах. Что интересного было в вашей проектной жизни? Что стало для вас неожиданным уроком? Делитесь в комментариях.

Теги: Добавить метки