Введение

В двух частях этой серии статей описывается план проверенного архитектурного решения для проектировщиков и ведущих разработчиков по реализации системы отслеживания. Система управления мастер-данными (MDM, Master Data Management) значительно улучшает отслеживаемость в среде управления поставками (SCM, Supply Chain Management). Отображение архитектурного решения на программное обеспечение от IBM демонстрирует ключевые возможности, относящиеся к реализации отслеживаемости. В первой статье представляется общая система отслеживания товаров и дается обзор полной компонентной модели. Во второй статье рассказывается, как мастер-данные улучшают аналитику данных отслеживания и трассировки в BI-среде, на примере управления контейнером многократного использования. Такое улучшение аналитики позволяет существенно оптимизировать систему SCM. План Traceability Solution Blueprint for Business Performance Optimization отображает план PIM-RFID Solution Blueprint for Track and Trace, описанный в книге "Корпоративное управление мастер-данными: SOA-подход к управлению базовой информацией" (см. раздел "Ресурсы"), на стек программного обеспечения IBM и добавляет детали реализации.

Бизнес-мотивация

Общая отслеживаемость товаров в цепочке поставок является сегодня ключевым требованием. Например, отсутствие товара является проблемой любого торгового предприятия. Частое возникновение таких ситуаций приводит к недовольству клиентов и, что еще хуже, обращению к конкурентам. Накопление большого количества продуктов на полках подсобных помещений (что повышает текущие затраты розничных продавцов) является в лучшем случае частичным решением, поскольку все равно необходимо проверять полки на складе с целью их пополнения прежде, чем они опустеют. Проверка полок на складе мотивированными сотрудниками может решить проблему с точки зрения розничного продавца в масштабах отдельно взятого магазина. Намного более серьезной проблемой для розничного продавца является гарантирование своевременного пополнения запасов. Проблема заключается в следующем: как розничному продавцу узнать, что грузовик покинул оптовую базу вовремя? Если грузовик не вышел по каким-либо причинам, следует позвонить другому оптовику, чтобы получить товар в срок. Очевидно, что здесь необходимо детальное отслеживание цепочки поставок, чтобы понять, выполняются ли все пополнения товаров вовремя.

Аналогично, оптовик желает знать, доставляются ли товары от производителя на склад вовремя, поскольку в противном случае ему нечего поставлять розничным продавцам. Поэтому совершенно естественно возникает вопрос: как оптимизировать цепочку поставок от производителя до оптового продавца на склад и на стеллажи?

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

Возможны и другие варианты оптимизации цепочки поставок за счет системы отслеживания товаров:

• Уменьшение потерь скоропортящихся продуктов в системе SCM: мониторинг и гарантирование своевременной транспортировки скоропортящихся товаров с целью избежать потерь из-за их порчи.
  
  
• Автоматизированный прием: автоматическая проверка завершения доставки заказа.
  
  
• Уменьшение убыли: например, хранение портящихся продуктов, таких как молоко или мороженое, в соответствующих температурных режимах по всей цепочке поставок.
  
  
• Управление складскими помещениями и стеллажами: автоматический инвентарный учет и уведомление обслуживающего персонала о необходимости пополнения (на складе или в магазине), чтобы исключить ситуации с отсутствием товаров; потенциальная автоматизация всего процесса заказов оптовикам для пополнения запасов.

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

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

• По некоторым оценкам (см. раздел "Ресурсы") в 2010 году будет продано поддельных и фальсифицированных медикаментов на сумму 75 миллиардов долларов США.
  
  
• 25% упаковок лекарств в развивающихся странах являются поддельными (см. раздел "Ресурсы").
  
  
• Наличие сертификата происхождения позволяет избежать ущерба репутации компании от судебных исков, если потребителю будет нанесен вред фальсифицированными или поддельными медикаментами.

Фармацевтические компании, подчиняющиеся законодательству о регистрации происхождения медикаментов, ищут автоматизированные решения, известные под названием ePedigree. Соответствующие стандарты – это принятый в 2007 году Drug Pedigree Messaging Standard (DPMS) (см. раздел "Ресурсы"), а также стандарт EPCIS от EPCglobal (см. раздел "Ресурсы"). В настоящее время планируется использовать стандарт EPCIS для построения общеотраслевой системы отслеживания.

В начало

Решение для отслеживания и трассировки: стандарты EPCglobal

Участникам цепочек поставок нужны открытые стандарты для эффективного взаимодействия друг с другом. Определением и созданием стандартов, обеспечивающих эффективные решения отслеживания-трассировки (track-and-trace), занимается организация EPCglobal. Стандарты EPCglobal предлагают высокоуровневую архитектуру для решений отслеживания-трассировки, представленную на рисунке 1.

Рассмотрим стек, изображенный на рисунке 1, по порядку снизу вверх:

• Протоколы чтения и считыватели. Для решения отслеживания и трассировки считыватели создают исходные данные путем чтения двумерных штрих-кодов, RFID-тегов (Radio Frequency Identification) или другой аналогичной информации. Для считывателей EPCglobal определила набор стандартов, включая Low Level Reader Protocol (LLRP) и Standard and Class 1 Generation 2 UHF Air Interface Protocol Standard (ссылки на подробную информацию приведены в разделе "Ресурсы").
  
  
• Фильтрация и сбор данных с применением интерфейса ALE (Application Level Events - события уровня приложений). Этот интерфейс используется для обработки прочитанных данных путем их соответствующей фильтрации и сбора. Например, следует удалить продублированные события чтения. Ссылки на подробную информацию приведены в разделе "Ресурсы".
  
  
• EPC Information Services (EPCIS) System. Информация EPC (Electronic Product Code - электронный код товара) затем обрабатывается системой EPCIS (EPC Information Services System), состоящей из EPCIS Repository, EPCIS Query и EPCIS Capture Interface, основанных на спецификации стандарта EPCIS (ссылки на подробную информацию приведены в разделе "Ресурсы"). Интерфейс EPCIS Capture используется только для чтения, и все изменения, например детализация данных, необходимо выполнить между интерфейсами ALE и EPCIS Capture в приложении EPCIS Capture.
  
  
• Внутренние и внешние приложения. Эти приложения взаимодействуют с системой EPCIS через интерфейс EPCIS Query Interface (интерфейс запросов к EPCIS), например ePedigree-приложение.
  
  
• Стандарты данных EPCglobal, такие как EPC Tag Data Standard (TDS) или Pedigree Standard (см. раздел "Ресурсы") на рисунке 1 не показаны.

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

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

В начало

План решения по реализации отслеживаемости для оптимизации эффективности бизнеса

IBM предлагает передовое современное программное обеспечение для решений отслеживания-трассировки, основанное на архитектурном стеке EPCglobal и включающее в себя серверы InfoSphere Traceability Server и WebSphere® Premises Server. Сервер IBM InfoSphere Traceability Server поддерживает также ePedigree-решения. Размер сертификата происхождения увеличивается к концу цепочки поставок, поскольку в него добавляется все больше и больше информации. Качество мастер-данных (master data) о товаре при применении ePedigree-решения может быть улучшено путем использования системы MDM (Master Data Management) для управления атрибутами мастер-данных медикаментов и синхронизации их между всеми участвующими сторонами, начиная с производителя.

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

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

Реализация этих технологий позволяет создавать сеть датчиков, обеспечивающую фундамент для решений по отслеживанию-трассировке. План основан на стандартах, разработанных организацией EPCglobal Inc., являющейся частью более крупной организации по GS1-стандартам. Как показано на рисунке 2, имеются следующие основные компоненты:

• Промежуточное программное обеспечение датчиков.
  
  
• Система EPCIS со следующими ключевыми компонентами: EPCIS-репозиторий, интерфейс EPCIS Query и интерфейс EPCIS Capture.
  
  
• Система MDM с подключением к сети GDSN (Global Data Synchronization Network).
  
  
• Компоненты системы аналитики, включающей основные части системы хранения данных (Data Warehouse - DW) и приложение по составлению отчетности о производительности.
  
  
• Уровень взаимодействия и подключения, известный во многих компаниях под названием Enterprise Service Bus (ESB).
  
  
• Система защиты, включая аутентификацию с использованием LDAP.

Промежуточное программное обеспечение датчиков

Этот компонент приложения сбора данных можно разбить на две части. Первая часть - это промежуточное программное обеспечение датчиков (см. (1) на рисунке 2), которое должно интегрироваться с датчиками и устройствами активации для сбора информации о движении товара. Сюда включается как интеграция традиционных устройств чтения сериализованных штрих-кодов, так и интеграция более новых датчиков, предназначенных для чтения RFID-тегов. Промежуточное программное обеспечение датчиков также часто называется RFID Middleware по причине распространения в настоящее время именно RFID-решений. Такая сеть датчиков может быть установлена на предприятии и у его торговых партнеров в таких местах как двери помещений, конвейерные ленты, стеллажи и ручные считыватели для мобильного использования. Вторая часть - это приложение сбора данных, получающее данные от промежуточного программного обеспечения датчиков через ALE-совместимый интерфейс и обрабатывающее информацию при помощи набора вариантов использования и бизнес-логики для создания EPCIS-событий, передаваемых в ESB и EPCIS-репозиторий.

Система EPCIS

EPCIS-репозиторий принимает EPCIS-события из приложения сбора данных, сохраняет и предоставляет их EPCIS-приложениям и торговым партнерам через интерфейс EPCIS Query. Оба этих интерфейса являются частью спецификации EPCglobal EPCIS 1.0 Specification (см. раздел "Ресурсы"). В настоящее время имеется много поставщиков сертифицированных реализаций. Реализация стандарта обеспечивает систему EPCIS двумя ключевыми API для интеграции:

• EPCIS Capture Interface
  
  
• EPCIS Query Interface

Система EPCIS должна также подключаться к сети EPC Global Network, используя стандарт Discovery Services (EPCDS) (см. раздел "Ресурсы"), находящийся в разработке. Этот стандарт позволяет отслеживать прохождение товара через несколько систем EPCIS по всей цепочке поставок. Каждая система EPCIS уведомляет сервис обнаружения, когда она принимает в свое подчинение тегированные товары.

Система MDM (Master Data Management)

Система MDM является доверенным источником мастер-данных на предприятии. В контексте данного плана решения система MDM предоставляет мастер-данные о товаре, производителе, поставщике и местонахождении, используемые в системе EPCIS. Система MDM подключается к сети Global Data Synchronization Network (GDSN). Через это подключение в систему MDM интегрируется статическая информация о товаре и поставщике (например, GTIN, GLN и основные атрибуты товара, поставщика и местонахождения), передаваемая между поставщиками или торговыми посредниками. Отметим, что здесь может иметься подмножество атрибутов, таких как стоимость, которые еще не синхронизируются с поставщиками или торговыми посредниками через GDSN по соображениям, связанным с конкуренцией. Это означает, что могут иметься определенные двухточечные связи между поставщиками или торговыми посредниками и внутренней MDM-системой. MDM-система может удовлетворить все требования EPCIS-системы к мастер-данным, относящиеся к атрибутам из GDSN, а также другим основным атрибутам, которыми она управляет как доверенный источник.

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

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

Компонент аналитики

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

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

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

Enterprise Service Bus

Концепция Enterprise Service Bus (ESB) в плане решения предназначена для удовлетворения требований к интеграции приложений. Интеграция событий от датчиков с существующими бизнес-процессами и приложениями может быть выполнена путем подключения корпоративных приложений, таких как ERP или SCM, к запросам подписки EPCIS через ESB. Запросы подписки (subscription queries) обеспечивают передачу относящейся к событиям информации по ESB, и они позволяют использовать ESB-адаптеры для интеграции этого нового потока информации с существующими традиционными системами.

Система защиты, включая аутентификацию с использованием LDAP

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

В начало

Обзор компонентной модели плана решения по реализации системы отслеживания

После рассмотрения логических компонентов и их интеграции на высоком уровне давайте перейдем к более детальной компонентной модели, показанной на рисунке 3. Здесь повторно используется цветовая схема из рисунка 2 для облегчения отображения высокоуровневой модели на данную детальную модель. Например, желтые элементы на рисунке 2 остались желтыми на рисунке 3. Отметим, что для окрашенных компонентов показываются также некоторые части или элементы, явно не изображенные на рисунке 2. Например, компоненты пользовательского интерфейса. Эта схема компонентной модели основана на рекомендованной архитектуре MDM (MDM Reference Architecture).

Перейдите по этой ссылке для просмотра увеличенного рисунка 3.

Назначение окрашенных компонентов было описано в предыдущих подразделах. Это обязательные компоненты для данного плана решения. Компоненты, окрашенные в белый цвет, являются необязательными, но они часто используются в контексте решения по реализации системы отслеживания. Для некоторых из них в разделе "Дополнительные продукты" рекомендуется один или несколько продуктов или их комбинаций из портфеля продуктов IBM Software Group. К таким компонентам относятся:

• (21) Сервисы Web-приложений. Этот компонент инкапсулирует бизнес-логику для Web-приложений, выполняющихся на сервере Web-приложений.
  
  
• (22) Реестр сервисов. Это корпоративный репозиторий для сервисов в среде SOA.
  
  
• (23) Сервисы бизнес-процессов. Этот компонент представляет собой корпоративную платформу бизнес-процессов для оркестровки (orchestration) потока работ и бизнес-процесса. Типичными примерами являются потоки работ, описанные на языке BPEL (Business Process Execution Language) и выполняемые данным компонентом.
  
  
• (24) Сервисы представления. Этот компонент является корпоративной платформой для совместной работы, и она часто основана на корпоративном портале.
  
  
• (25) LOB-система. Этот компонент обычно встречается несколько раз в информационной среде и представляет на рисунке все приложения, не представленные иначе. LOB-системы интегрируются друг с другом и с изображенными компонентами через компонент ESB (16).
  
  
• (26) Сервисы управления содержимым. Этот компонент обеспечивает сервисы управления содержимым. Он часто основан на корпоративной системе управления содержимым.
  
  
• (27) Сервисы интеграции информации (Enterprise Information Integration - EII). Этот компонент обеспечивает виртуализованный доступ к источникам структурированных и не структурированных данных либо через сервисы виртуализации, либо через сервисы федерирования (federation).
  
  
• (28) Сервисы интеграции информации. Этот компонент тоже предоставляет сервисы интеграции информации, но он концентрируется на сервисах для профилирования и обнаружения модели данных, очистке данных и сервисах извлечения-преобразования-загрузки (Extract-Transform-Load - ETL).

Несколько потоков через схему компонентной модели, показанной на рисунке 3, представляют ключевые варианты использования решения. К этим потокам относятся:

• Поток 1. Интеграция мастер-данных из MDM-системы в EPCIS-систему.
  
  
• Поток 2. Сбор данных о событиях EPCIS в EPCIS-системе.
  
  
• Поток 3. Обмен событиями EPCIS между торговыми партнерами.
  
  
• Поток 4. Прикладные системы, запрашивающие EPCIS-систему.
  
  
• Поток 5. BI-интеграция (интеграция интеллектуальных ресурсов) с EPCIS-системой и MDM-системой с целью реализации аналитики для решений отслеживания-трассировки. Поток 5 будет рассмотрен более подробно в следующей статье.

Представим себе, что сеть датчиков прочитала EPC-данные. Также предположим, что создание MDM-системы и начальная подготовка мастер-данных уже завершены. Поток 1 начинает работать, когда мастер-данные должны быть загружены в EPCIS-систему:

1. Администрирование и конфигурирование EPCIS осуществляется через пользовательский интерфейс EPCIS (3). Через него также выполняется определение атрибутов мастер-данных, использующихся в EPCIS-системе. Созданная модель мастер-данных для EPCIS-системы локально сохраняется в EPCIS-репозитории. Существует два разных варианта интеграции MDM-системы и EPCIS-системы:
   
   
   • Начальная пакетная загрузка в сочетании с периодическими пакетными обновлениями измененных данных, например каждую ночь.
     
     
   • Начальная пакетная загрузка, сопровождаемая обновлениями в режиме реального времени или почти в режиме реального времени с использованием системы обмена сообщениями или инфраструктуры Web-сервисов.
     
     
2. В первом случае MDM-клиент (5) активизирует поток работ в MDM-системе (12) через вызов сервиса, генерирующего извлечение измененных данных, которые затем MDM-клиент обрабатывает и загружает в EPCIS-репозиторий (5).
   
   
3. Во втором случае после завершения начальной загрузки в одном из вариантов реализации MDM-клиент (5) может подписаться на запрос по ESB (16), в которой MDM-система (12) публикует изменения, используя шаблон Publish/Subscribe (публикация/подписка).

Процесс сбора данных от датчиков и перемещение их в EPCIS-систему представляется потоком 2:

1. Считыватель (1) читает EPC-тег с тегированного товара.
   
   
2. Эта необработанная EPC-информация передается в виде сообщения через шлюз сообщений (14) в промежуточное программное обеспечение RFID (2).
   
   
3. Обработка необработанных EPC-данных и удаление дублированных чтений является основной задачей промежуточного программного обеспечения RFID (2). После обработки этих данных выполняется публикация высокоуровневых событий через интерфейс ALE (2) в приложение EPCIS capture, которое применяет бизнес-правила и добавляет контекст к необработанным данным. EPCIS-события затем отправляются этим приложением в интерфейс EPICS посредством ESB (5).
   
   
4. Интерфейс EPCIS capture сохраняет данные в EPCIS-репозитории. Данные являются неизмененными, поскольку интерфейс EPCIS capture не может выполнять изменения. Изменения данных - это работа приложения EPCIS capture, которое (при его наличии) обычно располагается между промежуточным программным обеспечением и EPCIS-системой для улучшения данных при необходимости.

Поток 3 описывает обмен информацией между торговыми партнерами, например поставщиком и производителем по сети EPCglobal. Этот поток является типичным потоком в контексте реализации ePedigree-решений.

1. Из-за подписки в EPCIS-системе (5) торгового партнера, выполняющего предыдущее действие в цепочке поставок, EPCIS-система получает соответствующие EPCIS-события из EPCIS-системы торгового партнера (4). Эти события проходят через сеть EPCglobal Network, а EPCIS-система получает их через клиентское приложение EPCglobal Network (5). Обмен между клиентом EPCglobal Network (5) и системой торгового партнера (4) осуществляется через компонент ESB (16). Каждое событие сохраняется в EPCIS-репозитории (5).
   
   
2. После доставки груз обрабатывается и отправляется по следующему назначению. Все эти этапы отслеживаются и трассируются при помощи операций чтения EPC-кодов, выполняемой считывателями (1) и обрабатываемых промежуточным программным обеспечением RFID (2), которое предоставляет правильные события в интерфейс EPCIS capture (5) через интерфейс ALE (2).
   
   
3. Когда товары после завершения этих действий доставляются по следующему назначению, EPCIS-система публикует соответствующее событие, потребляемое следующим торговым партнером (4) в цепочке поставок, который может запросить дополнительную информацию через интерфейс запроса EPCIS (5). Транспортировка между торговым партнером (4) и EPCIS-системой (5) опять осуществляется компонентом ESB (16).

Поток 4 отображает взаимодействие прикладных систем с EPCIS-системой. Приложения, такие как хранилище данных (13), система планирования корпоративных ресурсов (Enterprise Resource Planning - ERP) (19) или система управления цепочками поставок (Supply Chain Management - SCM) (20), могут взаимодействовать с EPCIS-системой через интерфейс запросов (5). Также, некоторое программное обеспечение EPCIS поддерживает инфраструктуру сигналов и уведомлений, построенную на базе технологии обмена сообщениями. Такие возможности позволяют EPCIS-системе публиковать сигналы или сообщения в тематические очереди, на которые могут подписываться прикладные системы, используя архитектурные шаблоны обмена сообщениями, например Publish/Subscribe (публикация/подписка). ePedigree-приложение (6) может запросить в EPCIS-системе все релевантные данные через интерфейс запроса EPCIS (5), для того чтобы сформировать сертификат происхождения, например для клиента аптеки или для государственного контролера, заинтересовавшегося подозрительным лекарством. Торговый партнер в цепочке поставок должен иметь возможность предоставить сертификат происхождения, основанный на EPC-кодах, содержащих конкретный национальный код лекарства (national drug code - NDC). Аналогично GTIN, NDC не сериализуется. Поэтому вы можете считать NDC видом GTIN для лекарств.

В начало

Отображение решения

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

В таблице 1 перечислены рекомендуемые продукты фирмы IBM Software Group для компонентной модели, схема которой приведена на рисунке 3. Компоненты, отсутствующие в таблице 1, обычно не реализуются продуктами IBM. Если для компонента перечислено более одного продукта, возможны альтернативы или для реализации функциональности компонента требуется несколько продуктов.

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

В начало

Использование WebSphere Premises Server

В настоящее время доступен WebSphere Premises Server Version 6.1. Этот продукт обеспечивает надежную доставку сообщений между устройствами чтения и сервером WebSphere Premises Server. К тому же, он подключается к другим продуктам интеграции бизнес-деятельности, создавая бизнес-контекст, необходимый для автоматического принятия оперативных решений. Продукт предоставляет сервисы, основанные на базовом наборе продуктов IBM Service Oriented Architecture (SOA), обеспечивая корпоративную масштабируемость и надежность для целостных решений, основанных на датчиках. Эта платформа позволяет одновременно использовать датчики различных типов, таких как активные и пассивные RFID-теги или датчики состояния. Она является очень гибкой и простой для расширения. WebSphere Premises Server реализует единую платформу комплексной ситуативной обработки, основанной на событиях, порожденных имеющими значение событиями из необработанных данных, полученных от датчиков. После создания эти события могут потребляться новыми улучшенными или существующими бизнес-процессами для получения подробной информации из данных от датчиков. Ключевыми функциональными возможностями являются:

• Интеграция с сервером IBM InfoSphere Traceability Server для создания стратегического корпоративного приложения, использующего информацию от датчиков. Сюда входят рекомендованные отраслевые модели, поддерживающие варианты использования, такие как отслеживание и трассировка активов, управление контейнером многократного использования (см. следующую статью). Все это дополняется инструментальными средствами проектирования, интегрированными в Rational® Application Developer.
  
  
• Доставка сервисов отслеживания месторасположения в реальном режиме времени с интерфейсом к устройствам для активных тегов.
  
  
• Интеграция датчиков с использованием открытой платформы, основанной на Eclipse.
  
  
• Агенты LLRP-устройств для использования LLRP-совместимых считывателей RFID-кодов.
  
  
• Совместимость со стандартами из EPCglobal, такими как фильтрация и объединение с реализацией ALE.
  
  
• Передовой механизм бизнес-правил формирует сложные бизнес-процессы, использующие датчики, уменьшая время развертывания и одновременно повышая гибкость обработки и управляемость.

При использовании продукта Feature Pack for Sensor Event Services, поставляемого с последней версией WebSphere Premises Server V6.1, становятся доступными гибкие сервисы бизнес-уровня. Это существенно уменьшает время реализации вариантов использования с управлением от событий датчиков. Добавление WebSphere Business Events обеспечивает способность реализовать обработку событий от интеллектуальных датчиков.

В начало

Использование сервера IBM InfoSphere Traceability Server

Продукт IBM WebSphere RFID Information Center был переименован в IBM InfoSphere Traceability Server (Traceability Server), начиная с версии 2.0, которая вышла в октябре 2008. На рисунке 4 показана высокоуровневая схема ключевых компонентов.

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

Модель метаданных

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

Интегрированная среда сбора событий

Интегрированная среда сбора событий с сервером Traceability Server обеспечивает надежное, гибкое и масштабируемое решение для сбора и хранения EPCIS-событий на сервере Traceability Server. Систему можно настроить на использование нескольких направлений, включая MQ и HTTP. Компонент сбора можно также настроить на получение событий из AS2 с использованием очереди сообщений MQ. Компонент сбора событий сервера Traceability Server читает события из очереди сообщений WebSphere MQ, выполняет синтаксический разбор событий и сохраняет их в базе данных, как показано на рисунке 5.

Интегрированная среда сбора событий является:

• Совместимой со стандартом EPCIS для HTTP и связыванием с очередью сообщений.
  
  
• Легко настраиваемой при помощи метаданных.
  
  
• Масштабируемой до сотен точек сбора событий на один DC.

Интегрированная среда сбора событий обеспечивает:

• Расширяемость. Стандарт EPCIS EPCglobal позволяет определить новые типы событий, а также расширить существующие. IBM Traceability Server управляется метаданными, поэтому пользователи могут надежно и быстро расширить типы событий и атрибуты событий под требования стандарта EPCIS. Процессы сбора, запроса, сохранения и составления отчетов автоматически меняются согласно изменениям в метаданных.
  
  
• Обработчики. Traceability Server обладает мощной и гибкой системой обработки данных, позволяющей определять обработчики данных для отображения специфичных данных EPCIS-событий в свои собственные мастер-данные. Использование API обработчиков полностью интегрировано в компонент запросов и сбора событий, и это существенно повышает производительность системы путем оптимизации процессов сохранения и извлечения данных из базы данных. Traceability Server предоставляет Java® API для определения обработчиков. Обработчики являются необязательным компонентом системы.
  
  
• Отклоненные события. Отклоненные события либо содержат XML, несовместимый со стандартом EPCIS, либо данные о товаре, месторасположении или словаре, отсутствующие в базе данных. На рисунке 6 показаны отклоненные события в консоли Traceability Server.
  
  Рисунок 6. Отклоненные события
  
  
  

  Перейдите по этой ссылке для просмотра увеличенного рисунка 6.

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

Компонент мастер-данных

Интеграция мастер-данных о товаре и месторасположении с EPCIS-событиями позволяет обеспечить контекст, необходимый для того, чтобы пользователи понимали путь следования товаров в цепочке поставок. Стандартный подход с использованием MDM-системы (Master Data Management) для выражения этих мастер-данных и предоставления их серверу Traceability Server гарантирует, что торговые партнеры смогут использовать общую информацию и поступить соответствующим образом.

Перейдите по этой ссылке для просмотра увеличенного рисунка 7.

Ниже приведены примеры мастер-данных:

• Заказчики могут идентифицировать линии производства и упаковки товаров как логические сущности. Система ассоциирует сериализованные товары с линиями, используя EPCIS-события, по мере продвижения товара по физическим точкам считывания. При дальнейшем движении по цепочке поставок торговые партнеры могут использовать информацию в событиях для точного определения того, куда товар был перемещен.
  
  
• Приложения используют информацию об упаковке товаров, например ожидаемое число единиц учета в ящике, для того чтобы гарантировать отсутствие ошибок при подсчетах, выполняемых в процессе упаковки.
  
  
• Системы уведомлений и составления отчетов тоже используют информацию о товарах и месторасположении для классификации информации более пригодным для чтения способом и для классификации конкретных EPC-кодов, как показано на рисунках 7 и 8.

Перейдите по этой ссылке для просмотра увеличенного рисунка 8.

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

Запросы и система защиты

IBM осуществила большие инвестиции для достижения защищенности на уровне значений атрибутов наряду с надежной производительностью. Решение сформировалось в результате трех лет работы группы IBM Research в области улучшенного управления базой данных; оно основывается на трех проверенных подходах, опубликованных в исследовательских статьях и в зарегистрированных заявках на изобретение (сделана заявка на патент; см. раздел "Ресурсы").

Сервер Traceability Server обеспечивает:

• Очень надежную, легко настраиваемую авторизацию на уровне значения атрибутов для запросов торговыми партнерами и для внутреннего использования.
  
  
• Поддержку всех протоколов аутентификации, определенных стандартом EPCIS, включая HTTP, HTTPS и AS2.

Возможности системы защиты Traceability Server 2.0 позволяют пользователям при необходимости использовать данные совместно с их торговыми партнерами. Для точной настройки подмножества информации в системе, которую можно предоставлять каждому торговому партнеру, администратор использует несколько правил разглашения (disclosure rules). Стратегии системы защиты определяются при помощи мастер-данных в системе. Они не требуют вмешательства потребителя.

На рисунках 10 и 11 показано, как определить стратегию системы защиты для Traceability Server.

Перейдите по этой ссылке для просмотра увеличенного рисунка 10.

Перейдите по этой ссылке для просмотра увеличенного рисунка 11.

На рисунке 12 представлен обзор всех определенных стратегий.

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

Web-сервисы генерирования серийного номера

Использование сериализации и ее интегрирование в процессы производства и решения, связанные с цепочками поставок, требуют наличия очень надежного способа размещения серийных номеров, которые будут использоваться при кодировании EPC-тегов. Компонент Serial Number Generation сервера Traceability Server предоставляет ряд возможностей, которые можно использовать для создания EPC-тегов, согласованных со стандартами EPCglobal Tag Data Standards (см. раздел "Ресурсы"). К этим возможностям относится пакетное распределение для получения набора номеров, которое может быть передано стороннему производителю меток или контрактному производителю. Серийная часть самого номера может изменяться последовательно или случайно, чтобы обеспечить гибкость правил, которые может использовать компания в распределении своих номеров.

Централизованное управление и распределение сервисами генерирования серийных номеров гарантирует, что товар не будет дублировать EPC-коды при работе с цепочками поставок нескольких систем ERP, MES и WMS, выступающих для данного сервиса в качестве клиентских приложений.

Traceability Server поддерживает SGTIN-96, AI(01)+AI(21), SSCC-96, AI(00), известные как кодировка тегов SSCC-18, и их идентификаторы приложения GS1.

Аудит

Traceability Server 2.0 также содержит компонент Audit, позволяющий отслеживать все основные операции в системе. Компонент Audit применяет формат CBE XML для публикации сообщений по ESB, которые могут использоваться в целях аудита и мониторинга управления системой. Сообщения CBE Audit тесно интегрированы с интерфейсом EPCIS Query сервера Traceability Server и выдаются на каждом шаге запроса, предоставляя пользователям возможность выполнять мониторинг обработки запроса системой. Корреляция сообщений позволяет определить время обработки запросов и проследить за любыми исключительными ситуациями системы защиты.

На рисунке 13 показано, где располагается компонент audit в потоке процессов.

Предупреждения

IBM разработала расширяемую систему обработки предупреждений (alerts), инкапсулирующую сложные механизмы обработки событий (потоков). Система обеспечивает расширяемый и комплексный механизм обработки предупреждений. Управление предупреждениями позволяет пользователям преобразовывать информацию от своих датчиков и другую информацию в значимые события почти в режиме реального времени. Компонент alerts позволяет управлять предупреждениями, подписками, уведомлениями и вариантами доставки значимых предупреждений в режиме реального времени на основе событий, принимаемых сервером Traceability Server. Можно также сгенерировать отчеты по хронологии отправленных уведомлений. Поскольку объем данных о событии из датчика может быть очень большим, интегрированная среда предупреждений позволяет выполнять автоматический мониторинг по шаблонам событии и предпринимать соответствующие действия практически в режиме реального времени. Например:

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

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

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

Функциональность предупреждений Traceability Server обеспечивает прямую интеграцию в механизм обработки сложных событий (complex event processing - CEP). Механизмы CEP оптимизируются для эффективного обнаружения взаимосвязей между событиями, имеющими зависимости по времени. Эти механизмы обычно обрабатывают программы, написанные на специализированном языке программирования CEP, который предоставляют конструкции, облегчающие указание взаимосвязей событий по сравнению с языками программирования общего назначения. Когда механизм CEP обнаруживает набор событий, совпадающих с указанными взаимосвязями, он уведомляет компонент alerts, который создает определяемое пользователем уведомление.

В начало

Использование сервера IBM InfoSphere Master Data Management Server for Product Information Management

Продукт IBM WebSphere Product Center был переименован в IBM InfoSphere Master Data Management Server for Product Information Management (MDM Server for PIM) (см. раздел "Ресурсы"), начиная с версии 6.0. Предлагаемое программное обеспечение является решением для управления информацией о товарах, связывающим информацию о товарах, местоположениях и торговых партнерах (например, поставщиках и оптовых продавцах), обычно разбросанную по предприятию. Согласование и материализация этих мастер-данных в продукте MDM Server for PIM может дать следующие преимущества:

• Эффективное распределение мастер-данных о товарах между бесчисленным множеством потребителей, торговых партнеров и сотрудников.
  
  
• Полная информация о товарах, предоставляемая на Web-сайтах, в приложениях для электронной коммерции и решениях для вывода на печать, использующихся для генерирования рекламных листовок и каталогов товаров.
  
  
• Единая точка интеграции в сеть Global Data Synchronization Network, что еще больше оптимизирует обмен информацией о товарах между торговыми партнерами.
  
  
• Более точное определение категории товаров менеджерами категорий.
  
  
• Наследование атрибутов в иерархиях товаров. Расходы на управление товарами могут уменьшиться, более эффективно поддерживаются такие варианты использования, как микромерчандайзинг в розничных предприятиях с прямой доставкой).

MDM Server for PIM спроектирован с поддержкой открытых стандартов, таких как JMS, для упрощения интеграции с другими системами в среде SOA. Поддерживаются также такие форматы, как Microsoft Excel для упрощения импорта и экспорта информации о товарах. На рисунке 14 показаны компоненты сервера MDM Server for PIM.

Моделирование товаров

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

Домен мастер-данных о товаре от домена потребителя отличают следующие ключевые характеристики:

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

MDM Server for PIM решает эти задачи, благодаря следующим ключевым функциональным возможностям:

• Каталог. Каталог - это логический контейнер для набора товаров. Одновременно можно использовать несколько товаров. Например, в швейной промышленности может иметься каталог осенней коллекции, а создаваться следующая версия каталога для летней коллекции.
  
  
• Спецификации. Спецификации описывают набор атрибутов для товаров. Все спецификации поддерживают релевантные типы данных для домена товаров, такие как строковые, числовые и типы данных для работы с датами. Более того, имеется поддержка атрибутов, основанных на таблицах поиска, многократных атрибутов, групп атрибутов и атрибутов взаимосвязи.
  
  
  • Главная спецификация. Каждый каталог имеет главную спецификацию (primary specification), представляющую набор общих атрибутов для всех товаров в каталоге. Иерархия тоже имеет главную спецификацию, определяющую общий набор атрибутов для каждой категории в дереве иерархии. Более подробно тема иерархий рассматривается в разделе "Управление иерархиями".
    
    
  • Второстепенные спецификации. Второстепенные спецификации (secondary specifications) определяют:
    
    
    • Атрибуты, специфичные для всех товаров в категории.
      
      
    • Атрибуты, расширяющие определение самой категории. Они расширяют набор атрибутов для категории, но набор атрибутов для товаров в этой категории не расширяется.

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

Благодаря возможностям гибкого моделирования, редактирования и просмотра, реализованным поверх моделей решения по реализации системы отслеживания, MDM Server for PIM может поддерживать совместимые версии для всех товаров, которые предположительно будут транспортироваться по цепочке поставок, и обеспечивать релевантные атрибуты для решения InfoSphere Traceability Server.

Управление иерархиями

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

• Иерархия по типу товаров. Категория в данной иерархии представляет тип товаров. Отображение товара на категорию устанавливает семантическое представление товара типа x. Например, если поместить товар Screen Elegant 99 в категорию LCD screens, это укажет человеку, просматривающему иерархию, что данный товар является жидкокристаллическим экраном.
  
  
• Иерархи по месторасположению. Категория в данной иерархии представляет месторасположение. Отображение товара на месторасположение может устанавливать, например, семантическое представление пункта продажи товара, если иерархия по месторасположению определяет магазины. Это типичный сценарий микро-продаж, где цены меняются в зависимости от месторасположения (например, товар может стоить дороже в Нью-Йорке, чем в небольшом городке в Техасе). Пример показан на рисунке 15. Для решения по реализации системы отслеживания иерархии по месторасположению могут использоваться для того, чтобы предоставить серверу InfoSphere Traceability Server критичную информацию, такую как Global Location Numbers расположения в цепочке поставок, с целью показать, через какие центры дистрибуции доставлялся товар.
  
  Не все товары могут иметь одинаковый маршрут в цепочке поставок. Мощной функциональностью в контексте иерархий по месторасположению является наследование атрибутов, которое может значительно уменьшить расходы на ввод и обслуживание товаров. Обычно товар в дочернем узле наследует все атрибуты товара, категоризованного в родительском узле, пока какой-либо атрибут не будет переопределен. Просто представьте, что все атрибуты, кроме цены, аналогичны, поскольку товар продается в одном магазине, а не в другом.
  
  
• Иерархия по производителям. Категория в данной иерархии представляет производителя или продавца. Отображение товара в данной категории устанавливает семантику продавца товара.
  
  
• Иерархия по поставщику. Категория в данной иерархии представляет поставщика. Отображение товара в данной категории устанавливает семантику поставщика товара.

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

Поток работ

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

К ключевым возможностям инфраструктуры потока работ относятся:

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

Обзор WebSphere Commerce integration

Продукт IBM WebSphere Commerce (WC) integration обеспечивает фундамент для установки единой высокопроизводительной среды подготовки информации о товарах для коммерческих Web-сайтов B2B (business-to-business) и B2C (business-to-consumer). MDM Server for PIM может значительно расширить ценность реализаций решений для электронной коммерции, существенно улучшая подготовку для публикации полной и точной информации о товарах. Совместно с платформой электронной коммерции он предоставляет инструментальные средства для определения участия различных пользователей в функциях различных WC-процессов. Он также предлагает функциональные возможности для существенного упрощения агрегирования, улучшения, управления и утверждения больших объемов сложной информации о товарах. Продукт WebSphere Commerce Server integration содержит:

• Базовое моделирование данных MDM Server for PIM, включающее представления для таких объектов каталога WebSphere Commerce как категории, товары, группы товаров и SKU.
  
  
• Экспорт всех данных каталога, а также только их изменений в WebSphere Commerce.
  
  
• Предварительный просмотр элемента в MDM Server for PIM путем выбора меню предварительного просмотра на экране WebSphere Commerce и навигация в приложение WebSphere Commerce для просмотра всех релевантных объектов каталога WebSphere Commerce.

MDM Server for PIM может использоваться как единая точка синхронизации информации о товаре между поставщиками и продавцами, что устраняет необходимость в значительном количестве соединений точка-точка между бизнес-партнерами. Ключевым компонентом для этого является IBM Global Data Synchronization.

В начало

Обзор продукта IBM Global Data Synchronization

Продукт IBM Global Data Synchronization для сервера IBM InfoSphere Master Data Management Server for PIM представляет собой полное решение по синхронизации данных, позволяющее принимать участие в GDSN. Он поддерживает весь спектр требований к синхронизации данных для GDSN-решения. К ключевым функциональным возможностям продукта относятся:

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

IBM Global Data Synchronization обеспечивает синхронизацию данных для MDM Server for PIM, который является лидирующим продуктом промежуточного уровня по управлению информацией. IBM Global Data Synchronization поддерживает ключевые бизнес-цели. Он помогает максимизировать эффективность взаимоотношений с торговыми партнерами, а также улучшить общую производительность SCM для повышения доходов. К ключевым бизнес-преимуществам относятся:

• Возможность повышения точности атрибутов.
  
  
• Совместимость с глобальными стандартами и стандартами пула данных.
  
  
• Масштабируемость, производительность и надежность корпоративного уровня, позволяющие решить первоначальные, небольшие и безотлагательные задачи глобальной синхронизации данных с возможностью разработки широкомасштабного решения.
  
  
• Передовые возможности интеграции, позволяющие использовать существующую информацию о товарах во всей IT-инфраструктуре.
  
  
• Подробная информация по всем действиям механизма синхронизации данных с использованием возможностей системы составления отчетов с целью улучшения процесса на постоянной основе внутри предприятия и вне его.
  
  
• Проверенная основа совместной работы партнеров по цепочке поставок в таких сценариях как RFID, совместное планирование, прогнозирование и пополнение (collaborative planning forecasting, replenishment - CPFR), а также в других B2B-действиях.

Сервисы аналитики и обнаружения

Продукты, необходимые для данного компонента, будут рассмотрены во второй статье. В ней мы обсудим поток данных из EPCIS и MDM System в систему DW, на которой развертывается аналитика и панели управления.

Другие продукты

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

ESB-продукты

Для компонента ESB доступно несколько продуктов: IBM WebSphere Enterprise Service Bus, IBM WebSphere MQ Message Broker и IBM WebSphere Data Power. Все три продукта способны реализовать функциональность корпоративной шины сервисов (Enterprise Service Bus). Однако между ними имеются некоторые отличия:

• IBM WebSphere Enterprise Service Bus. Этот продукт основан на сервере WebSphere Application Server. Он реализует инфраструктуру обмена сообщениями на языке Java, основанную на JMS.
  
  
• IBM WebSphere MQ Message Broker. Этот продукт реализует наиболее совершенное, масштабируемое ESB-решение. Он написан на языке C/C++ и имеет много адаптеров для большого числа разнообразных приложений, таких как SAP.
  
  
• IBM WebSphere Data Power. Этот продукт является программным решением с мощными возможностями по преобразованию XML-сообщений, ускоренными специализированным аппаратным обеспечением.

IBM WebSphere Portal Server

WebSphere Portal Server позволяет создавать и управлять первоклассными приложениями-порталами B2C, B2B и B2E. WebSphere Portal Server позволяет быстро интегрировать приложения и содержимое в основанных на ролях приложениях с интегрированным механизмом поиска и защиты. Вместе с IBM WebSphere Portlet Factory доступна инструментальная программа быстрой разработки, основанная на Eclipse. На основе WebSphere Portal Server может быть разработан пользовательский интерфейс управления мастер-данными.

IBM WebSphere Process Server

IBM WebSphere Process Server - это высокопроизводительная система поддержки бизнес-процессов. IBM WebSphere Process Server эффективно организует сервисы для бизнес-процессов в среде SOA и других средах. Основан на трехуровневой архитектуре, использующей язык BPEL (Business Process Execution Language) для построения сервисов, архитектуре SCA (Service Component Architecture) для инкапсуляции всех активизированных артефактов интеграции (таких как процессы, задания для пользователей, бизнес-правила и т.д.) и SDO-объектах (Service Data Objects) для инкапсуляции информации о типичных бизнес-объектах. В контексте решения, приведенного на рисунке 3, посредством этой платформы могут быть организованы процессы руководства данными (Data Governance), имеющие отношение к разным системам, необходимым для распорядителей данными (Data Stewards).

IBM Tivoli Directory Server

Продукт IBM Tivoli Directory Server предоставляет высокопроизводительную, основанную на LDAP инфраструктуру для управления идентификацией. Эта инфраструктура масштабируема, надежна и основана на стандартах. Она реализует критичные функциональные возможности для системы защиты, такие как аутентификация для всех типов приложений, включая порталы и Web-приложения. IBM Tivoli Directory Server может поддерживать несколько сотен миллионов элементов. Кроме того, можно развернуть группы с тысячами пользователей, благодаря повышенной надежности и масштабируемости, реализуемых на базе проверенного сервера IBM DB2 Enterprise Server Edition и встроенного прокси-сервера. Поддерживается отраслевой стандарт LDAP v3, позволяющий реализовать инфраструктуру идентификации по требованию для передовых бизнес-решений. В контексте схемы решения, представленного на рисунке 3, для репликации данных из основного каталога (17) в зависимые каталоги, доступные только по чтению, (18) в DMZ может использоваться такая функциональность как высокая готовность, использующая возможности репликации мастер/подчиненный и одноранговой идентификации. MDM Server может плавно интегрироваться с провайдером LDAP, например IBM Tivoli Directory Server. Это означает, что в контексте рассматриваемого решения сервер мог бы обеспечивать аутентификацию для MDM-сервисов.

IBM WebSphere Service Registry and Repository

IBM WebSphere Service Registry and Repository (WSRR) - это важнейший компонент в сервис-ориентированной архитектуре, обеспечивающий единое место для публикации, поиска и управления описаниями сервисов. Он также является ключевым компонентом для руководства SOA, применяемого на всем протяжении цикла жизни сервисов. В контексте рассматриваемого решения (рисунок 3) описания MDM-сервисов хранились бы в WSRR.

IBM InfoSphere Information Server

IBM InfoSphere Information Server - это целостная платформа интеграции информации. Она может выполнять профилирование, очистку, преобразование и доставку информации из гетерогенных источников для более быстрого получения подробной информации, с меньшими затратами. Платформа имеет встроенную сквозную инфраструктуру метаданных общего использования. Она позволяет повторно использовать метаданные, такие как определения таблиц, разными функциональными компонентами. Например, обнаруженное через компонент Information Analyzer определение таблицы может тотчас же использоваться в компоненте Data Stage для преобразования данных.

Общим для компонентов является также уровень поддержки SOA: Information Services Director. Этот компонент используется для отображения информационных функций в виде сервисов. Information Services Director имеет каталог информационных сервисов, в котором хранятся все сервисы, созданные при помощи Information Server. Они легко могут быть опубликованы в корпоративном репозитории сервисов через WSRR. Данный продукт может использоваться на фазе интеграции мастер-данных для согласования и очистки мастер-данных перед их загрузкой в MDM-систему. На возможности, предоставляемые данным программным продуктом, обычно могут отображаться компоненты (27) и (28) (см. рисунок 3).

В начало

Заключение

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

В начало

Анонс книги

В книге "Управление корпоративными основными данными: SOA-подход к управлению мастер-данными" намного подробнее рассматриваются проблемы, связанные с управлением мастер-данными (Master Data Management). В написании этой книги принимали участие Аллен Драйбелбис (Allen Dreibelbis), Эберхард Хечлер (Eberhard Hechler), Иван Милман (Ivan Milman), Мартин Оберхофер (Martin Oberhofer), Пол ван Рун (Paul van Run) и Дэн Вольфсон (Dan Wolfson). Она была опубликована издательством Pearson Publishing в июне 2008 года (ISBN-10: 0132366258, ISBN-13: 9780132366250). Книга охватывает многие ключевые аспекты управления мастер-данными, определяет его значимость для бизнес-деятельности и способ разработки решения по управлению корпоративными мастер-данными. В данной книге предоставляется исчерпывающее руководство по разработке данного решения, включая рекомендованную архитектуру, планы решения, архитектурные принципы, шаблоны и свойства MDM-систем. В книге описывается взаимосвязь между MDM и сервис-ориентированными архитектурами и отмечается важность руководства данными. Представленный материал не зависит от производителя и программного продукта и концентрируется на принципах и методологиях проектирования правильной архитектуры для MDM-решения. Описание отдельных глав приводится на дополнительной вставке.

Ресурсы

• Оригинал статьи Traceability solution blueprint for business performance optimization, Part 1: Understanding the architecture of a comprehensive track-and-trace solution (EN).
  
  
• Книга, послужившие источником информации для данной статьи: Управление корпоративными мастер-данными: SOA-подход к управлению базовой информацией (EN).
  
  
• Используйте RSS-фид для запроса уведомлений о готовящихся статьях данной серии (дополнительная информация о RSS-фидах по содержимому developerWorks).
  
  
• Зыбучие пески государственного законодательства о происхождении. Торговля фармацевтическими препаратами, 30 июня 2007 года (EN).
  
  
• Доклад Всемирной организации здравоохранения (World Health Organization - WHO) о подделке лекарственных препаратов, 14 ноября 2006 года (EN).
  
  
• ВОЗ создала оперативную группу для борьбы с подделкой лекарственных препаратов. Бюллетень Всемирной организации здравоохранения, сентябрь 2006, 84 (9) (EN).
  
  
• Страница стандартов EPCglobal со ссылкой на все документы и спецификации стандартов EPCglobal, упомянутые в данной статье.
  
  
• InfoSphere Master Data Management Server for Product Information Management.
  
  
• Дополнительная информация в статье Интеграция продукта IBM InfoSphere Master Data Management Server for Product Information Management с WebSphere Commerce (EN).
  
  
• Дополнительная информация о сервере IBM InfoSphere Traceability Server (EN).
  
  
• IBM Global Data Synchronization (EN).
  
  
• Дополнительная информация об управлении информацией в разделе Information Management на сайте developerWorks. Техническая документация, статьи с инструкциями, обучающие материалы, файлы для загрузки, информация о продуктах и многое другое (EN).
  
  

Об авторах

Мартин Оберхофер (Martin Oberhofer) - старший инженер-консультант по MDM. Специализируется в области управления мастер-данными, миграции и консолидации данных, технологиях баз данных, разработке программного обеспечения на Java и интеграции информационных систем в среду SOA. Является экспертом по интеграции MDM-систем с прикладными системами SAP. Мартин ведет международные семинары по архитектуре для клиентов и системных интеграторов. Он получил степень магистра по математике в Университете Констанца, Германия.

Умар Акил (Umair Akeel) работает старшим разработчиком-программистом продукта IBM InfoSphere Traceability Server. Отвечает за общую архитектуру, дизайн и реализацию решений по управлению информацией для сетей датчиков. До этого Умар работал ведущим разработчиком в IBM WebSphere Product Center и отвечал за полный цикл разработки продуктов. Руководил проектированием и реализацией клиентских решений в различных отраслях: высокие технологии, фармацевтика, потребительские товары и продажи. Умар принимал активное участие в EPCglobal, в частности как один из разработчиков стандарта EPCIS. Специализируется главным образом на интеграции мастер-данных, системе защиты и обработке запросов. Является приверженцем разработки сервис-ориентированных и управляемых событиями архитектур для управления доставкой информации от датчиков клиентам.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Бизнес-мотивация
• Решение для отслеживания и трассировки: стандарты EPCglobal
• План решения по реализации отслеживаемости для оптимизации эффективности бизнеса
• Обзор компонентной модели плана решения по реализации системы отслеживания
• Отображение решения
• Использование WebSphere Premises Server
• Использование сервера IBM InfoSphere Traceability Server
• Использование сервера IBM InfoSphere Master Data Management Server for Product Information Management
• Обзор продукта IBM Global Data Synchronization
• Другие продукты
• Заключение
• Анонс книги
• Ресурсы
• Об авторах
• Комментарии