Master Product Data for the Field to Factory Landscape

Ken NollLighthouse Transformations

www.lighthousetransformations.com

Executive Summary Unified Product Definition Business Process Automation Integration Framework Recommendations


Internet sales channels, now well established, require real-time access to product information

With the far flung effects of Global Sourcing, duplicate sets of product information has a crippling effect on the organization

Customer Data Requirements have grown considerably


The modularization of product offerings that support CTO often require a higher level of abstraction of critical business information.

Most recently, companies have begun to address data harmonization by taking advantage of recently established standards like ISO 10303 and OAGIS along with an information abstraction methodology know as Service-Oriented Architecture (SOA).

Most SOA implementations are in the form of Web Services

12

3

4

5

- Order of Events

Master Product Data (MPD) is that authoritative, reliable foundation of data used across many applications. MPD does not entail a new, all-inclusive

database, but a layer of abstraction (metadata) that identifies data ownership for a specific domain, product set, or attribute.

The goal is a single view of the truth, no matter where is lies.

Master Product Data (MPD) is that authoritative, reliable foundation of data used across many applications. MPD does not entail a new, all-inclusive

database, but a layer of abstraction (metadata) that identifies data ownership for a specific domain, product set, or attribute.

The goal is a single view of the truth, no matter where is lies.


Leverage product data (definition, attributes, etc) from the PLM into other To-Order applications

Automate the product design process by passing design requirements (ie; specials) from sales configuration into PLM workflow

Consistently control the authoring and versioning of parts, options, and rules

SOA provides a gateway for multiple business applications to broker and share common master product information and execute product configuration management consistently

SOA provides a foundation for companies to realize a consistent information framework between Product Engineering and Sales

SOA provides a foundation for companies to realize a consistent information framework between Product Engineering and Sales


If you haven’t already, begin rationalizing your product

Assess all view of the product definition truth, then create one comprehensive object to satisfy all views

Take as much business logic out each system put it into your integration domain

Develop a IT governance process. Identify business events that will govern how/when the UPD gets changed


World is Flat - Thomas Friedman, 2005

“We do a lot of collaborating … Demand shaping goes on constantly. It works like this: At 10am in Austin, Dell discovers that so many customers have ordered notebooks with 40 Gb hard drives … the supply chain will run short in two hours. The signal is automatically relayed to Dell.com …phone operators will now say …For the next hour we are offering 60Gb hard drives … for just $10 over the price of the 40Gb!

Dell just reshaped the demand curve to fit its current supply chain condition


Not only should UPD convey identity, it should convey: Schema Design Process Change Management Structure

But since a single master data repository is still probably years away, UPD should also: Allow for a heterogeneous environment of authoring, management scope,

and data exchange service capabilities Be aggregated from various information sources Be openly exchanged via a consistent product data information service


Share master product data and product structures – The service requestor can call a Product Information web service for data such as component ID’s, revision levels, attributes, and descriptions. Using Extensible Stylesheet Language Transformations (XSLT), XML representations of the product structure (ie; product BOM) can be shared between business applications.

Product Constraints and Selection Rules – Cardinality rules like “REQUIRES”, “REQUIRES ONE OF”, or “CONFLICTS WITH” can be requested from product configuration data sets. Business rules like sales and marketing constraints, production resource rules, and pricing rules can be exposed to other enterprise applications.

Initiate Business Objects into Enterprise Workflows – Workflow engines typically found in most PLM applications can be requested when business objects (options, parts, orders, etc) are created, modified, or deleted.


PLM Providers STEP Providers

K Shell Analysis


SMARTEAM – Gateway™

Provides bi-directional data exchange between SMARTEAM and multiple enterprise applications,

Gateway reduces the product development cycle by connecting the company's design data to its various enterprise applications

SMARTEAM Gateway exposes the SMARTEAM data repository to EAI Platforms, enabling businesses to share and exchange the latest product data, including Parts, Bill of Materials, Change Processes, and Document information, across engineering design, manufacturing logistics, customer service, and other legacy systems.

SMARTEAM Gateway currently supports Microsoft BizTalk and will support IBM WebSphere Business Integrator in the near future.


Example: Integrating Smarteam with SAP for Parts, Bills of Material, and documents

Part Synchronization from SMARTEAM to SAP – Automatic synchronous transmission of part information from the SMARTEAM system to the SAP system when a part is promoted in SMARTEAM.

Bill of materials Synchronization from SMARTEAM to SAP – Automatic synchronous or asynchronous transmission of a single or multilevel EBOM from the SMARTEAM system to the SAP system when an EBOM is promoted in SMARTEAM.


Windchill PDMLink™

A Web-based master product data management repository, enabling global access to current, accurate information from myriad sources

Connects to multiple mechanical/electrical CAD applications, desktop applications and Enterprise Resource Planning systems via STEP standard for product information

Synchronizes parts, documents, bill of material (BOM) structures, engineering change notification (ECN), product configurations

Bundles TIBCO EAI technology for connectivity to the broad suite of TIBCO adapters


Business process automation (BPA) is the process of integrating enterprise applications, reducing human intervention wherever possible, and assembling software services into end-to-end process flows. As a significant part of business process reengineering, BPA improves operational efficiencies and reduces risks. BPA is made possible through enterprise application integration and service-oriented architecture solutions.


R = N2 - N

How many integration would you like to do?

R = 2N


Consider the generally accepted approach to accessing an object.

One invokes an object by sending it a message with an object name, a method, and a set of arguments.

The object processes the request and respondsto the originator of the message. This model encapsulates the private implementation details ofthe object and enables communication through a public interface.

Business Object Documents (BOD’s) becomethe common object through which integration serversprovide services such as publish and subscribe, request and reply, transport mechanisms, data mapping tools, integration routing and logging capabilities.


According to the OAGIS standard, there are 190 BOD’s

Here are a few examples:GetPurchaseOrder GetQuote GetRequestForQuote GetRequisition GetRouting GetSalesOrder GetSequenceSchedule GetShipmentSchedule


There are 3 main sections within the Integration Framework:

Service Transport XML Messaging Service Description Service Discovery


Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).


XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.


Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.


Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.


Understand your product’s current structure and how it is viewed from engineering, sales, manufacturing…

Measure the steps, data sets, and persons that touch product data whenever a change occurs

Develop a strategic approach to Service Oriented Architecture

And last, look at Information Governance as a Competitive Advantage going forward

Master Product Data for the Field to Factory Landscape

Technology

Transcript of Master Product Data for the Field to Factory Landscape