Product lifecycle management

[sharmanakul]

Is your feature request related to a problem? Please describe. The ERPNext does not have the PLM functionality.

Describe the solution you'd like New product introduction process Engineering change request and engineering change order for Items, BOMs, Routing Versioning of Items, BOMs, Routing Attach and view CAD designs

[fishter]

A quick wishlist from me:

1. Multi-Level BOMs will, at time of WO creation, pick the Default BOM for an included Item. I.e. a change in a low-level BOM will not mean manually updating all parent BOMs.
2. Versioning Items by locking their properties (selected properties/attachments). No changing without creating a new version.

[sharmanakul]

1. we plan to handle it by giving the options to the user to allow the impact only on the the select items (thorugh 'where used' kind of report)
2. absolutely

[raveslave]

happy to see this plan!

input / wishlist:

• hierarchical category structure
  • flexible numbering scheme, prefix/suffix, revision-sequences
  • global attributes, inherited from the level above or category specific
  • rules (mandatory, optional, validation, formatting)
• editable life-cycle phases + changes function
  • configurable with auto-numbering, i.e. ECO-000123 (engineering change order)
  • a change could encapsulate: life-cycle, specs, bom, sourcing related, files
  • routings / approval requirements / approval roles
  • life-cycle defines if a formal change is required or not
• ensure all data is "event sourced" / ledger based
  • items, supplier-items, boms, changes, plm configuration
  • offering full history & difference-view down to field level
  • a smart data-structure like this will also allow subscribing to any data-change (great for custom api integrations)
  • view to show global activity, filter down per user, item, etc
• revision control & releases
  • git flows, versions (incremental work), tags (releases), merge (changes)
  • staging state prior to release (candidate) > review / diff-view > approval workflow > new release
• separate items structure from supplier items / sourcing relations
  • i.e. one bom-item must be able to reference one or many supplier-items
  • sourcing should be able to be either direct or two levels via a specific vendor/distributor
  • when multiple sources exist, system should offer to select approved, potential, etc
  • supplier items must have their own life-cycle, i.e. new, prototype, production, eol
  • inherited parameters from supplier item data to items to avoid duplicate data-entry, (example component description)
• BOM features
  • hierarchical bom's, flat, expanded (showing one or many sourcing relations)
  • difference view between two released bom revisions
  • bom-substitutes (important feature!)
  • most other PLM's just offer to add relations globally, but substitutes in real world are often tied to a specific manufacturer/country or specific project. so it's important that one bom item can point to alternative supplier items while another defaults to the pre-assigned relationships.
• files/attachments
  • versioned storage
  • configurable file-types, hierarchical
  • supplier files should live in a separated tree from internal data
  • granular file access history
• enable scientific data-types to ensure data is stored as such and can be presented/configured as wanted
  • i.e. storing value separate from unit type
  • this offers better and smarter search, i.e. resistors between 500R and 2.5K
  • fields should parse & transform input data like resistor.resistance "4K7" -> 4700 Ohms
• make it possible to configure triggers to run async jobs upon any change, item, state change, etc
  • i.e. fetch meta-data from digikey, mouser, octopart based on supplier-item.mfg-part-no
  • this way creating an item would just require a full "MPN" that in its turn would fetch and auto-populate other relevant fields automatically
• import preview & dry-run (essential feature!)
  • offer full preview of what will happen when a item-list, bom or supplier-items are imported
  • show before vs. after import, colorized for add, update, remove
  • allow auto-creation of PLM item-numbers as long as full category-path is included in import supplier

[kriengpre]

Here are some example function of another PLM Platform https://www.aras.com/en/resources?data-selectable-Types=Demo https://www.arenasolutions.com/platform/plm/ https://github.com/docdoku/docdoku-plm

[raveslave]

@sharmanakul did you see my feature spec suggestion above?

[erictmyers]

Great ideas. Prioritizing a couple of these could give a usable first-pass system.

Fundamental:

• New product introduction process / Engineering change request and engineering change order for Items, BOMs

  • (Think these are one and the same. An Engineering Change is the vehicle for both introducing and changing items, though not all organizations opt to go through the engineering change system to introduce new items.

• Versioning of Items, BOMs

  • (The term most often used in the US is Item Revision... just an aside)

Another very common integral concept is Engineering Change Notification (ECN), emphasizing a system for messaging affected parties. High end ERP's even feature messaging triggered to notify production, purchasing, warehouse, sales, etc. if the items are on things such as open work orders, purchase orders, sales orders, in stock, and the like. (**Edit: the auto-triggering of messaging should go into the nice-to-have-but-later section below. A method for messaging manually-selected individuals or groups would be nice to have now.)

There are other features nice to have but not fundamental. If they're complicated to implement, I wouldn't think they should get in the way of rolling out Item/BOM revision history and Engineering Change Management.

• Versioning of Routing / Engineering Change Request for Routing

  • There are differing opinions on this, but many organizations don't consider manufacturing routings to be part of product/design engineering. Per that philosophy, the basic definition of a product is published and unchanging, regardless of the myriad of process routes that may correctly achieve a compliant product.

• Attach and view CAD designs

  • ERPNext already has "Attach File" function, which can be used for retrieving PDF's of machine drawings, test procedures, etc. Integration of 3D CAD is exciting, but is not vital to basic functionality.

[raveslave]

agree with @erictmyers on the core feature-set needs.
regarding attachments for engineering data, the current side-pane / 'attachments' feature in erpnext will need a reworked storage backend for this to work well in manufacturing projects where everything needs to be traceable and atomic (like git).
as a first step:

• drawings/cad files must act as individual parameterized entities
  • type of file
  • additional attributes (based on file type)
  • individual versioning + history + sha/checksum
  • traceability (if file changes via web-gui or api)
• write/delete protection for "released" files
  • just like an invoice, a file that has been submitted must never change
  • instead a new version will be created along with the necessary (parent) ECN/ECO

a while back I made an issue about improving the attachment function here: https://github.com/frappe/frappe/issues/14336

[raveslave]

checking in!

[ankush]

We'll mostly attempt implementing the version control in some generic manner: https://github.com/frappe/frappe/issues/22075