Shop%20Floor%20Manager%20(OSFM)%20and%20Business%20to%20Business%20(B2B)%20Tips%20and%20Tricks

1
Shop Floor Manager (OSFM) and Business to
Business (B2B) Tips and Tricks

• Jerry Edwards

2

• Definitions
• Shop Floor Manager (OSFM) Lot centric and
  lot/serial number centric manufacturing product
• Stage Product physical state and unit of
  measure. Semiconductor stages include
• FAB, BUMP, SORT, DIE, ASSEMBLY, TEST, FGI
• Adaptor Custom software to generate Oracle
  application transactions based on vendor reported
  events
• Binning Process that results in multiple output
  parts based on process results (usually test)

3

• Definitions continued
• Event Action affecting a product lot that vendor
  must report
• Data element specific data to support B2B
  communication and a specific Oracle application
  transaction
• Business to Business Communications (B2B)
  Subcontractor manufacturing event communication
  and processing into Oracle purchasing, inventory,
  and OSFM application modules

4

• Presentation Scope
• OSFM Best Practices
• Product structure
• Network routing suggestions
• Tips and Tricks
• Suggested Enhancements
• Mapping subcontractors into OSFM
• Single inventory organization for all vendors
• Vendor specific inventory organizations
• Business to Business (B2B) Functional
  Requirements

5

• OSFM Product Structure Suggestions
• Define separate part numbers where
• subcontractors complete added value processes
  and move lots into stock or ship to other
  subcontractors
• where wafers are converted to unassembled die
• Typical stages FAB / SORT / DIE/ASSEMBLED DIE /
  TESTED DIE / FINISHED DIE
• OSFM Network Routing Suggestions
• Start and complete work orders at one vendor for
  a single part number (stage)
• Keep routings simple add operations to track
  progress and to separate pay points.
• Define alternate paths if required (rework for
  example)

6

• OSFM TIPS TRICKS
• Co-Products Use co-product s to enter test
  binning expected results to drive ASCP
  over-planning
• Note user must enter primary bill via
  co-products form to use this feature. User
  cannot enter bill via bill of material form and
  then add co-product s in co-products form
• WIP Lot Bonus
• Starting job value is based on previous operation
  value
• Start network routings with dummy IN operation
  and use WIP Lot Bonus at subsequent operations
  only.
• Do not use WIP Lot Bonus into the first operation
  as component value is excluded resulting in
  inaccurate job costs

7

• OSFM TIPS TRICKS
• Binning Process Options
• During Work Order Perform WIP Split and update
  assembly for each bin. Note Update assembly
  treats update as a move so do not use update
  assembly at operation with OSP resource or you
  will duplicate purchasing activity. Move lot to a
  non-OSP operation to prevent duplicate purchasing
  activity.
• Post Work order Complete work order, then
  perform Inventory lot split and Inventory lot
  translate for each bin to change the part
  numbers.
• OSP Receiving
• Assign OSP resources so that quantity moved in
  will be correct OSP requisition quantity. For
  example assembly charges for good quantity only.
  Assign OSP to operation after assembly.
• Automate OSP receipts based on blanket releases.
  

8

• OSFM TIPS TRICKS
• Supervisor Workbench versus Move form
• Viewing many jobs versus playing transactions for
  specific jobs

9

• OSFM TIPS TRICKS
• Supervisor Workbench versus Move form
• Move form faster for playing specific job
  moves.

10

• OSFM TIPS TRICKS
• Partial Move Behavior
• Move quantity retains mother lot name (not
  updateable) instead of default child lot name.
  This is mismatch to real world lot naming as move
  quantity is usually the child lot.

11

• OSFM TIPS TRICKS
• Lot Create Work Order default lot name
• Default lot name assumes a split. If using full
  lot drop the suffix.

12

• OSFM TIPS TRICKS
• Recommended Custom Reports
• Work Order Location for all released jobs
• Actual yield versus estimated yield by job and
  part number.

13

• Suggested Enhancements
• Sub-lots Use for die parts
• Enables user to track good die by wafer in die
  bank. Each wafer is a die sub-lot. User selects
  sub-lots when selecting lots and lot create form
  accumulates quantities into the child lot. Today
  user cannot track good die by wafer unless
  treating each wafer as a separate lot (not
  feasible due to volume).
• Co-products
• Enable user to enter co-products and s for
  bills created via bill of material form.
• Lot Create
• Default mother lot number into resulting lot
  field.
• Add default split lot extension if user enters a
  quantity less than full lot (add extension when
  user tabs from quantity field)

14

• Suggested Enhancements
• Genealogy network (source and where used)
• Explode with single select

15

• Vendor mapping to OSFM
• Options
• Single inventory organization for all vendors
• One Inventory organization per vendor
• Hybrid
• Separate inventory organizations for major
  vendors
• Single inventory organization for smaller volume
  vendors

16

• Mapping subcontractors to OSFM
• Single inventory organization for all vendors
• Represent vendors via subinventory names to
  represent vendor / product stage
• Setup an intransit subinventory to track lots
  moving between vendors
• for monthly close
• One inventory organization to close
• for reporting all lots on one shop floor
• - For Advance Supply Chain Planning
• Sourcing rules apply to inventory organizations
  so ASCP cannot recommend vendors via sourcing
  rules
• Excludes product transit time among vendors
• Limits resource capacity planning in network
  routings

17

• Mapping subcontractors to OSFM
• Separate inventory organizations for each vendor
• Subinventories represent product stage by vendor
• - for product costs (more complex roll-up)
• - for monthly close (multiple organizations to
  close)
• for Advanced supply chain planning
• Sourcing rules for vendor inventory organization
• Explicit transit times
• Vendor specific resource capacity planning

18

• Business to Business Communications
• B2B
• Subcontractor manufacturing event
  communication and processing into Oracle
  purchasing, inventory, and OSFM application
  modules

19

• B2B Process Outline
• Collecting vendor event data
• Vendor event database
• Vendor event processing
• Vendor B2B performance measurement
• Backup Processes
• Vendor bring-up for manual and automated
  reporting
• B2B Project suggestions

20

• B2B Process Outline
• Collecting vendor event data
• Define stages and events within each stage by
  product line
• Define product lines Product line scope
• same stage sequence
• same events within each stage
• Define stage and event matrix
• Define event data elements
• Oracle transaction data elements
• B2B data elements

21

• B2B Process Outline
• Collecting vendor event data
• Sample Stage and Event Matrix

22

• B2B Process Outline
• Collecting vendor event data
• Define data elements for each stage and event
  combination

23

• B2B Process Outline
• Collecting vendor event data
• Stage and event example SHIP at FAB
• EVENT CODE
• SHIP
• Vendor ID
• This field represents the Partners DUNS number
  and needs to be reported by every partner.
• Vendor Location ID
• This field represents the Location DUNS number
  for Vendor Site location at which the respective
  manufacturing stage is being processed.
• To Vendor ID
• This field represents the ship-to vendors
  Location DUNS number.

24

• B2B Process Outline
• Collecting vendor event data
• SHIP at FAB Stage and event Example continued
• Transaction ID
• Vendors need to report a transaction identifier
  that will be unique for all the events that are
  being reported by the vendor. This field
  eliminates confusion between user and vendor when
  errors occur with a transaction.
• Transaction Date and Time
• Vendors need to report all the transactions in
  GMT time and in 24 hr format. Code the value as
  per xml format YYYYMMDDThhmmssZ.
• Part Number
• This field represents a user part number being
  purchased as per PO line provided to the FAB
  vendor .
• Manufacturer Part Number
• This field represents the FAB part number
  assigned by the Wafer Foundry that cross
  references to the user part number.

25

• B2B Process Outline
• Collecting vendor event data
• SHIP at FAB Stage and event Example continued
• Lot Stage Identifier
• This field represents physical location of the
  lot in the manufacturing cycle. This is a
  hardcoded field and needs to be reported as FAB
  all the time for all transactions being reported
  as shipment from the FAB vendors.
• Lot Type Classification
• This field represents the classification of the
  Lot and has two possible choices,
• Engineering
• Production
• This is needed if vendors cannot omit engineering
  lots from reporting.
• Lot Number
• This field represents the FAB assigned lot number
  to the lot that is being shipped by the FAB
  vendor. Each event requires a unique lot number.
  Do not report the same part number, lot number
  for multiple shipments.

26

• B2B Process Outline
• Collecting vendor event data
• SHIP at FAB Stage and event Example continued
• Lot Quantity
• This field represents the full lot quantity being
  shipped for the purchased part number
• PO Number
• This field represents the NetLogic PO number for
  the purchased wafer. and lot
• PO Line Number (optional)
• This field represents the NetLogic assigned PO
  Line number for the purchased part number and
  lot. Note automation will be easier if the FAB
  vendor can supply the PO line number in addition
  to the PO number.
• REPEAT FOR ALL PRODUCT LINE STAGE/EVENTS

27

• B2B Process Outline
• Collecting vendor event data
• Generate vendor reporting requirements document
  to include
• Reporting rules by stage
• Stage and event data elements with explicit
  definitions
• Provide spreadsheet event samples

28

• B2B Process Outline
• Collecting vendor event data
• Generate Network Routing Flow document
• Routing flow for each product line and stage
• Enables vendors to map their routings to OSFM
  network routings
• Multiple vendor operations may occur for each
  OSFM operation
• OSFM operations are based on pay points and
  product lot tracking requirements (lot location
  and lead times)

29

• B2B Process Outline
• Collecting vendor event data
• Generate vendor communications bring up document
• Manual reporting
• Automated reporting

30

• B2B Process Outline
• Collecting vendor event data
• Manual Reporting
• Require event reporting that builds foundation
  for and eases transition to automated reporting
• Do not derive Oracle application transactions
  from vendor snapshots (shop floor picture or lot
  location report)
• Error prone
• User accepts ownership for playing the correct
  transaction rather than the vendor accepting
  responsibility to report correct event data and
  sequence

31

• B2B Process Outline
• Collecting vendor event data
• Select data collection process and event data
  format and language
• Data Collection Process Options
• File Transfer Protocol (FTP) or secure FTP
• Vendor places file on a server
• User retrieves the file from the server
• B2B Software (Web Services) TIBCO, BEA, IBM, etc.
  
• Vendor communicates specific data package
• B2B software authenticates, validates, and passes
  event to a B2B database

32

• B2B Process Outline
• Collecting vendor event data
• Event Data Formats and language
• .CSV files, comma delimited flat files matching
  user proscribed format and text language
• RosettaNet Partner Interface Process (PIP) by
  mapping event data elements to pre-defined
  columns for a PIP event (7B1) Distribute WIP
• Each PIP specification includes a business
  document and a detailed business process that
  includes interaction, data transmission, security
  and error-handling requirements.
• Language usually XML

33

• B2B Process Outline
• Collecting vendor event data
• Data Formats and language
• Extensible Markup Language (XML)
• XML was designed to describe data and to focus on
  what data is.
• The Main Difference Between XML and HTML
• XML was designed to carry data.
• XML is not a replacement for HTML.XML and HTML
  were designed with different goals
• XML was designed to describe data and to focus on
  what data is.HTML was designed to display data
  and to focus on how data looks.
• HTML is about displaying information, while XML
  is about describing information.

34

• B2B Process Outline
• Collecting vendor event data
• XML Example
• ltnotegt
• lttogtTovelt/togt
• ltfromgtJanilt/fromgt ltheadinggtReminderlt/headinggt
• ltbodygtDon't forget me this weekend!lt/bodygt
  lt/notegt
• The note has a header and a message body. It also
  has sender and receiver information. But still,
  this XML document does not DO anything. It is
  just pure information wrapped in XML tags.
  Someone must write a piece of software to send,
  receive or display it.

35

• B2B Process Outline
• Collecting vendor event data
• Data Formats
• RosettaNet 7B1
• Simple Object Access Protocol (SOAP) 1.1
• XML based protocol that consists of three parts
  an envelope that defines a framework for
  describing what is in a message and how to
  process it, a set of encoding rules for
  expressing instances of application-defined
  datatypes, and a convention for representing
  remote procedure calls and responses.
• ebXML Business Process Specification Schema
  (BPSS) ebXML
• (Electronic Business using eXtensible Markup
  Language), is a modular suite of specifications
  that enables enterprises of any size and in any
  geographical location to conduct business over
  the Internet.

36

• B2B Process Outline
• Collecting vendor event data
• Generate a trading partner agreement (TPA) with
  each vendor.
• Communication process (FTP, Web Service, etc.)
• Event content
• Communication frequency (daily, per shift, etc.)
• Error Handling
• Level 1 format
• Level 2 content
• Vendor bring up and certification process

37

• B2B Process Outline
• 2. Vendor event database
• Event Processing
• Level 1 Validation of vendor events
• File Format
• Data file uniqueness
• File Parsing (corrupt data)
• Successful insert to vendor data base
• Send response to vendor for each vendor
  transmitted file

38

• B2B Process Outline
• 2. Vendor event database
• Event storage
• Convert vendor reported event into an input
  record for the vendor database.
• Insert vendor reported events into a common
  database independent of the manner in which
  vendors reported the event. This is often
  referred to as a canonical database.

39

• B2B Process Outline
• 2. Vendor event database
• Event storagecontinued
• Store events as reported but enable error
  correction process to change event data elements
  PRIOR to generating and uploading Oracle
  applications transactions.
• Generally vendors resend events for level 1
  errors only
• Vendors resend events with new transaction IDS
  for a level 2 (content) errors.

40

• B2B Process Outline
• 2. Vendor event database
• Maintain event status codes (details in next
  section)
• Event archive and purge Provide process to
  archive data and reduce active database size.

41

• B2B Process Outline
• 3. Vendor event processing
• Event status Maintain vendor reported event
  processing status codes per event
• New Loaded into vendor data base
• Error Data content (based on level 2 validation)
• Pending Event is out of sequence based on
  Product line, stage, and event pre-defined
  matrices
• Ready for Upload to Oracle applications
• Error Upload error in Oracle open interface
• Successful Upload Loaded successfully through
  open interface into Oracle application

42

• B2B Process Outline
• 3. Vendor event processing
• Error Checking Design Level 2 (content)
  validation to ensure generated Oracle
  applications transactions will process
  successfully through Oracle application open
  interface tables.
• Design level 2 error checks by product line,
  stage, and event. (samples follow)

43

• B2B Process Outline
• 3. Vendor event processing
• Receipt
• Validate correct event sequence (check last
  successful event and pre-defined event sequence
  table)
• Valid part/Lot/Quantity
• Correct vendor mapping ( INV ORG and vendor
  subinventory mapping)
• Report lot attributes if required at reported
  stage

44

• B2B Process Outline
• 3. Vendor event processing
• Split/Merge processing
• Validate correct event sequence (check last
  successful event and pre-defined event sequence
  table)
• Valid part/Lot/Quantity
• Required fields available
• Meets pre-defined split and merge business rules

45

• B2B Process Outline
• 3. Vendor event processing
• Start Work order start
• Validate correct event sequence (check last
  successful event and pre-defined event sequence
  table)
• Valid part/Lot/Quantity
• Required fields available
• Valid bill of material and routing
• Valid component part, lot, quantity, or
  component lots (multiple components)
• Report lot attributes if required at reported
  stage

46

• B2B Process Outline
• 3. Vendor event processing
• Map events to Oracle transactions Adaptor will
  generate appropriate Oracle transactions or
  series of transactions for successful event.
  Examples follow
• Receipt Inventory receipt
• Split Inventory lot or work order lot split
• Merge Inventory lot or work order lot merge
• Start work order start
• Move work order move
• Complete work order move/complete
• Ship Inventory lot transfer or inter-org
  transfer

47

• B2B Process Outline
• 3. Vendor event processing
• Error correction process requirements
• Track errors in the vendor event database by
  maintaining error codes and explanations
• Link appropriate error code to vendor event
  records where errors are identified

48

• B2B Process Outline
• 3. Vendor event processing
• Error correction process requirements...continued
• Develop user form based interface to
• Query errored events and enter data corrections.
  The goal is to correct errors rather then
  deleting records and having vendors resend. Each
  vendor input event is a unique transaction
  regardless of transaction data.
• User resets event status code so that adaptor
  next run will recheck this event and if
  successful generate Oracle transaction and upload
  to Oracle applications

49

• B2B Process Outline
• 3. Vendor event processing
• Event sequencing requirements Sequence events by
  maintaining correct predecessor event matrices
  for each product line and stage.
• Where event does not match a correct predecessor
  place event in pending status
• For some events multiple predecessor and
  successor events are possible.
• Generate Oracle applications transactions for
  events that pass level 2 validation.

50

• B2B Process Outline
• 3. Vendor event processing
• Load transactions to Oracle interfaces
• Identify errors in Oracle interface Record data
  and remove errored records from Oracle open
  interfaces. Report errors so that users can
  correct input data or address and Oracle software
  based problem.
• Event status changes Update event status as
  event is processed into Oracle applications

51

• B2B Process Outline
• 4. Vendor B2B performance measurement
• Generate reports that measure vendor reporting
  results
• Timely reports
• Accuracy by stage and event and part.
• Report comparing vendor system on hand balances
  and open work orders with Oracle application
  on-hand balances and open work orders.

52

• B2B Process Outline
• 5. Backup Processes
• Vendor reporting alternate reporting method if
  automated reporting is down. May be possible
  depending on volume
• Vendor event processing if automated system is
  down for extended period. Playing transactions
  directly into Oracle applications.
• Holding events when ERP system is down.

53

• B2B Process Outline
• 6. Vendor bring-up for manual and automated
  reporting
• Key Documents for vendors
• B2B MFG Vendor reporting requirements document
• Reporting rules by stage and event
• Event reporting details by stage and event
• Event sample spreadsheet
• User Product Routing flows
• Vendor communications process

54

• B2B Process Outline
• 7. B2B Project suggestions
• Vendors need to understand user part numbers,
  product structures, and network routings.
• Vendors report user part numbers and lot numbers
• Generate consistent reporting process across all
  vendors
• Allow time for rigorous event testing
• Parallel testing with real data is wise
  particularly if volume is high
• Expect high error volume at first
• Go live when you can correct errors within one
  day and..
• Error correction is effective and fast
• Vendors respond quickly to reported errors

55

• B2B Process Outline
• Contact Information
• Jerry Edwards
• jkedwards2002_at_hotmail.com
• 650-799-6699