Единая система НСИ – основа сервисно-ориентированной архитектуры.

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

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