Master Product Data for the Field to Factory Landscape
Upcoming SlideShare
Loading in...5
×
 

Master Product Data for the Field to Factory Landscape

on

  • 2,099 views

In the Field to Factory vision, a consistent version of the product definition is a basic requirement. This presentation addresses an integration framework between popular engineering systems and ...

In the Field to Factory vision, a consistent version of the product definition is a basic requirement. This presentation addresses an integration framework between popular engineering systems and front office sales systems that allows organizations to support mission critical processes, while at the same time building on a common product data model.

Ken Noll, Practice Manager – Ken is a senior business consultant for Lighthouse Transformtions of Cincinnati, Ohio with over 15 years experience managing large projects for such companies as General Motors, Electronic Data Systems (EDS) and the Boeing Company. Ken holds a BS in Industrial Engineering and an MS in Engineering Management. He has been responsible for helping a diverse group of fortune 500 companies realize substantial manufacturing throughput and production scheduling efficiencies. Ken has wide experience in Lean Manufacturing, Theory of Constraints, Set-Up Reduction, Information Technology and Cellular Manufacturing

Statistics

Views

Total Views
2,099
Views on SlideShare
2,091
Embed Views
8

Actions

Likes
0
Downloads
85
Comments
1

3 Embeds 8

http://www.slideshare.net 6
https://www.linkedin.com 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • great presentation. thank you!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Master Product Data for the Field to Factory Landscape Master Product Data for the Field to Factory Landscape Presentation Transcript

  • 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
  •