we are planning to create an app for PLM and are going ahead with the following use cases:
New item code creation process
Engineering change for Items, BOMs and Routings
Maintain versions
‘Where used’ report to assess the impact of the item being changed.
Allow impact of change on ‘where used’: certain items of user’s choice, all the items, do not allow the impact but disable them instead
New Item Code creation
Propose new item, with design files. Standard Workflow is applied. On approval, new Item code is created.
New Item also have BOM properties (RM and routing), which can enable new BOM creation. Perhaps we can use same tables created for Engineering Change Order.
This will allow updation of RM and Workstation property in the existing BOM, with design file attached.
Also, this will be used as a tool to replace on redundant RM with another RM in multiple BOMs at once. Same will apply to workstation and operation as well. On updation of BOM, design file will be attached / replaced in BOM master.
A new Attach field for updating design, which will keep getting over-written on each iteration.
We are also thinking of making a standard feature for making changes in the doctypes. This will allow selection of a DocType, selection of a field (parent / child), allows editing and then put it through standard approval workflow.
This can be a common change request for masters like Customer, Supplier, Employee etc. Like a generic Document Change Request.
Please let me know your thoughts.
We gave further thoughts on this and understood that this feature could be given the shape of generic feature, instead of restricting it’s use-case to just Item and BOM approval.
There will be many masters which will need approval matrix. Also, for updating the values in the masters / (transactions?) similar tool could be used. Here is the final solutioning we came-up with, and would like to know your thoughts on the same.
Change Request
If we try and make this feature generic, it will look somewhat like Employee Transfer / Promotion. Perhaps we will give an option to:
Select a DocType, and then select a record (say Item Code) to be updated.
Select a field in which values are to be updated.
See current value, and then set a new Value in the field. It will also allow selection of value in the child table. Also, user could attach a design file, which will be updated as a new value in the field
Save > workflow approval > submit
On submit, the document gets updated.
With the tool of update value in a specific record, it will also cover the use-cases like of BOM Replacement Tool.
New Record Creation
This refer to the first use case described in the Nakul’s post.
Just like above, the use-case for new record, specially masters creation can be generalised with another form “New Document Request”.
After selecting a doctype, we can fetch all the mandatory fields at once, where users can enter the values.
Do let us know if this use-cases will be good enough for the first version of PLM and will cover the most required use-cases.
The product lifecycle management is a very good concept!
Our company productsavants.com can help test if needed, we use projects to develop products now and it’s…clunky… If you need features tested we’re happy to help as it relates especially to physical products sourcing. We can also provide translations in Tagalog and Mandarin and Cantonese if needed for new field sets.
We like the idea of approval flows for other documents as well.
We agree that the version 1.0 for change request is useful as you have described it.
The idea of product development for us has several stages - this graphic is a contract manufacturing sourcing concept vs. a BOM for internal manufacturing in case it helps show what many of us deal with.
perhaps it’s better to move “has-bom” to the category tree making up item code’s ← → part/component categories. it’s quite common to have cats like ‘finished goods’ (which has a bom) while a category ‘capacitors’ is not structural so no bom items can be added to it
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
This would be a huge improvement to ERPNext functionality!
Some of the things you touch on that I consider to be “fundamentals”:
Maintain a history of item revisions, with associated BOM and item data being saved and retrievable for all revisions.
Have a “Current Revision” that is the default when viewing item information, adding the item to BOM’s, etc.
Where-used report: YES! Bonus if this could be a multi-level graphical browser
Implement new revisions via engineering change order. It is also very useful to be able to send notifications when engineering changes are released.
There are a couple of items that I see differently:
Routing revisions are a separate thing from item revisions, since the steps to manufacture an item can change but still result in an identical product. In my own view, routing must follow product design engineering, but not vice-versa.
The “Attach Design File” point seems like it may be too tailored to a specific idea of how to do things. Maybe the “Design File” term can be dropped in favor of “File”?
Has there been progress on the project since November?
this will be a great improvement
for documents like BOM - can we have a Change request made mandatory to carry out additions deletions or modifications and maintain a revision history
Hello everyone!
Is there any movement on this subject? There are so many manufacturing companies who are eager to have ECO and Product Lifecycle Management.
