Shop Floor Manager (OSFM) and Business to Business (B2B) Tips and Fabless Semiconductor Implementation Example - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Shop Floor Manager (OSFM) and Business to Business (B2B) Tips and Fabless Semiconductor Implementation Example

Description:

Shop Floor Manager (OSFM) and Business to Business (B2B) Tips and Fabless Semiconductor Implementation Example Jerry Edwards Definitions: Shop Floor Manager (OSFM ... – PowerPoint PPT presentation

Number of Views:186
Avg rating:3.0/5.0
Slides: 74
Provided by: JEdw9
Learn more at: http://www.norcaloaug.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Shop Floor Manager (OSFM) and Business to Business (B2B) Tips and Fabless Semiconductor Implementation Example


1
Shop Floor Manager (OSFM) and Business to
Business (B2B) Tips and Fabless Semiconductor
Implementation Example
  • 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 (Receipt, Start, Move, Completion,
    Ship, etc.)
  • Data element specific data column required in an
    event. Events have multiple data elements.
  • Business to Business Communications (B2B)
    Subcontractor manufacturing event communication
    and processing into Oracle applications.
  • Rosettanet 7B1 PIP Process information protocol
    for manufacturing events.

4
  • Presentation Scope
  • OSFM Best Practices
  • Product structure
  • Network routing scope
  • OSFM Tips and tricks
  • Mapping subcontractors into OSFM
  • Single inventory organization for all vendors
  • Vendor specific inventory organizations
  • B2B Process Outline
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • B2B Process Outline Details

5
  • OSFM Product Structure Suggestions
  • Define separate part numbers for each stage where
    lots will flow in and out of stock
    (subinventories) and where wafers are converted
    to unassembled die.
  • Typical stages FAB / SORT / DIE/ASSEMBLED DIE /
    TESTED DIE / FINISHED DIE
  • Network routing scope
  • start and complete work orders at the same vendor
    for a single part number (stage)
  • Keep routings simple add operations to track
    progress and 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 over-planning
    by ASCP.
  • 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
  • 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 queue intra-operation step of an
    operation with OSP resource or you will duplicate
    purchasing activity. Work around Move lot out of
    queue intra-operation step 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 job 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 based on user entered date range.
  • For Automated B2B include a form to perform
  • Event level data element corrections
  • Event status changes feature to trigger
    reprossing the corrected event

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).
  • Co-products
  • Enable user to enter co-products and s for
    bills of material created via bill of material
    form, not just the co-products 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
  • Control with profile option

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 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
  • - for product costs (more complex)
  • - 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
  • B2B Process Outline
  • Collecting subcon event data
  • Staging tables database
  • Subcon event processing
  • Subcon B2B performance measurement
  • Backup Processes
  • Subcon bring-up for manual and automated
    reporting
  • B2B Project suggestions

19
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Fabless Semiconductor Business process Scope
  • Subcontractor manufacturing event communication
  • Staging Table scope, event validation, error
    correction, generating and sequencing lot based
    Oracle application transactions
  • Oracle transaction upload via application program
    interfaces into Oracle purchasing, inventory, and
    OSFM application modules

20
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Business Process Overview
  • Staging Tables Scope
  • Manufacturing Event 7B1 Process Flow
  • Process Flow Details
  • B2B Event Handler Process
  • Execute preceding events filter process
  • Reported stage/event
  • Allowed preceding event
  • Lot last successful event
  • Perform Level 2 Content Validation
  • Oracle Transactions Logic for each Stage/Event
  • Automated Purchase Order Receiving for Outside
    processing services

21
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Business Process Overview
  • Subcontractor event reporting and collection as
    per industry standard format 7B1.
  • Perform format (level 1) validation
  • Report level 1 errors to subcontractors
  • Stage level 1 pass events in a new database
  • Track event status
  • Perform event matrix test
  • Content check for valid stage and event
  • Filter events prior to data content validation
    (level 2) based on predecessor event maps
  • Place events that fail predecessor event check
    into pending status
  • Queue passing events for level 2 (further content
    validation)

22
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Business Process Overview
  • Perform data content validation (level 2) on
    events that pass predecessor event check
  • For level 2 pass events For events that pass
    level 2 validation Change transaction status
    code to VA
  • Sequence events
  • Sort events by event_id within lot number within
    part number (requires securing an event id from
    subcontractors that is easily sorted)
  • For each event generate appropriate Oracle
    transactions (map events to required Oracle
    transactions)
  • Upload transactions to application program
    interfaces
  • Track interface results
  • Update event status
  • Track event success history
  • Maintain event error history

23
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Business Process Overview
  • Provide subcontractor event quality reports
  • B2B Management Workbench
  • Subcon setup
  • Error correction
  • Reset event status to force level 2 validation
  • Pending Event handler.
  • Maintain Lookup tables.
  • Logic requirements for B2B Error Handler
  • Update event status to error
  • Generate user friendly error explanations
  • Provide user access to correct errors and
    resubmit events for level 2 validation by
    changing data and event status code

24
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Staging Tables Scope
  • Dynamic data
  • Subcontractor Reported events
  • Subcontractor events as reported
  • Subcontractor event errors
  • Subcontractor event current data content and
    status
  • Subcontractor events successfully interfaced into
    Oracle applications (history table)
  • Static (Setup Data)
  • Event Filtering matrices For each stage (FAB,
    SORT, etc.) and event (RECEIPT, etc.)
  • Allowed Preceding Events (Predecessor) by
    flow/stage/event
  • Level 2 (Content) Error codes and messages
  • Subcon site data
  • Subcon mapping to inventory organization. Each
    subcon is represented as a separate inventory
    organization Site DUNS is tied to the vendor
    (subcon) site setup which, in turn, identifies
    the inventory organization.

25
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Staging Tables Scope example of as reported
    event columns

26
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Staging Tables Scopecontinued
  • Flow/stage/event allowed predecessor events
  • Last successful event by lot
  • Events with errors (history for quality
    reporting)
  • Other look up tables where look up is 100
    consistent

27
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Manufacturing Event 7B1 Process Flow

28
  • Fabless Semiconductor (B2B) Functional Spec
  • Application Server Integration

29
  • Fabless Semiconductor (B2B) Functional Spec
  • BPEL Transformation / Populate Staging tables

30
  • Fabless Semiconductor (B2B) Functional Spec
  • BPEL Transformation / Populate Staging tables

31
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Process Flow Details
  • Subcontractor event reporting and collection as
    per industry standard format 7B1.
  • Perform format (level 1) validation available
    from standard B2B software
  • Expected File format
  • File Parsing Error
  • Zero Byte check
  • Mandatory Fields as per 7B1 RosettaNet standards
    requirement (we are optional rows to meet
    business requirement which we will verify in
    level 2 content validation/check)

32
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Process Flow Details
  • BPEL Transformation and population of the staging
    table
  • Transport to message queue successful
  • Check for staging db available
  • if it is up then insert into staging
  • If the staging db is not up then BPEL will wait
    for some time and sending an email
  • Successful load to B2B tables (Pass messages)
  • Incorrect File according per DSPG requirements
  • Future enhancement 1 Check for daily
    transmission from subcon to validate
    communications even if subcon has no events to
    report.
  • Communicate level 1(format) errors to
    subcontractors

33
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • Process Flow Details
  • Insert level 1 pass events in a new database
    (staging tables)
  • Track event status Proposed statuses
  • NE new Loaded into staging tables
  • QU Passed event matrix test Ready for level 2
    validation Passed event matrix check
  • PE Pending, Failed filter process due to
    incompatible last successful event (for the event
    lot)
  • VA Validated ready for sequencing and
    submitting to Oracle application interfaces
  • ER Error (content)
  • IN Sequenced (event id within lot number for
    each part number) and submitted to application
    interfaces (APIs)
  • FA Failed Oracle interface
  • SU Successfully processed into Oracle
    applications
  • ME Manual entry , not further action required .
  • NA As we got from the sub contactor we nothing
    to do with it.
  • None Applicable to internal build event where we
    search for work order requirement from Build
    request file and none exists.

34
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • B2B Event Handler Process
  • Filter events prior to data content validation
    (level 2) based on predecessor event maps
  • Setup, for each stage (FAB, SORT, ASSY, FG,
    PRE-ASSEMBLY) and event (RECEIVE, START, MOVE,
    etc.) combination generate a look up table
    (matrix) containing allowed predecessor
    stage/events for the reported stage/event
    combination.

35
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • B2B Event Handler Process
  • Filter events prior to data content validation
    (level 2) based on predecessor event maps
  • Setup, for each stage (FAB, SORT, ASSY, FG,
    PRE-ASSEMBLY) and event (RECEIVE, START, MOVE,
    etc.) combination generate a look up table
    (matrix) containing allowed predecessor
    stage/events for the reported stage/event
    combination.
  • Perform Level 2 data content validation
  • Global (all events) validation logic and Event
    Specific validation logic

36
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • B2B Event Handler Process
  • For validated events generate required Oracle
    transactions
  • Receipt event Generate appropriate receipt
  • Start event Generate lot based job
  • Etc.
  • Automated Purchase Order Receiving for Outside
    processing services

37
  • Fabless Semiconductor (B2B) Functional
    Specifications and Solution Design Example
  • B2B Event Handler Process Error Correction HTML
    form

38
  • 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
  • products with the same stage sequence and events
    constitute a product flow
  • Define stage and event matrix
  • Define valid predecessor events for each
    stage/event
  • Define event data elements
  • Oracle transaction data elements
  • B2B data elements

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

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

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

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

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

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

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

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

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

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

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

50
  • 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) Map
    event data elements to pre-defined 7B1 rows.
  • 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

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

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

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

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

55
  • 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 reported event

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

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

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

59
  • B2B Process Outline
  • 3. Vendor event processing
  • Event status Maintain vendor reported event
    processing status codes per event
  • New Loaded into staging tables passed level 1
    validation
  • Pending Event is out of sequence based on
    Product line, stage, and event allowed
    predecessor events.
  • Error Data content (based on level 2 validation)
  • Queue Event ready for level 2 validation
  • Ready for Upload to Oracle applications
  • Error Upload error in Oracle open interface
  • Successful Upload Loaded successfully through
    open interface into Oracle application

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

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

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

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

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

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

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

67
  • B2B Process Outline
  • 3. Vendor event processing
  • Event sequencing requirements Sequence events by
    maintaining product line and stage allowed event
    sequence matrices. This is a key process.
  • For some events multiple predecessor and
    successor events are possible.
  • Generate Oracle applications transactions for
    events that pass level 2 validation.

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

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

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

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

72
  • 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
    and user operation codes (work order move events)
  • 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

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