Master Product Data for the Field to Factory Landscape

Ken Noll Lighthouse Transformations

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
1 2 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.

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

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.

How many integration would you like to do? >> R = N 2 - N 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 responds
to the originator of the message. This model
encapsulates the private implementation details of
the object and enables communication through a
public interface.
Business Object Documents (BOD’s) become
the common object through which integration servers
provide 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

Customers are able to select individual business applications from the best source without sacrificing integration and data sharing.
This gives customers the ability to more easily execute a "Best of Breed“ strategy.
Customers will reduce overall system cost by dramatically lowering the amount of money spent on building and maintaining integrations.

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

by LighthouseTransformations

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 6

Statistics

Master Product Data for the Field to Factory Landscape Presentation Transcript