Hi @nash, no real solutions here, only critique from the sidelines…
Yes, but this is common among PLM in general because it is usually not efficient to store large binary blobs in a DBMS and can also reduce performance of the DBMS in general.
Why? Can you show compliance by demonstrating adequate control over documents, regardless of the storage mechanism? Are you required to comply with a specific system architecture? (some standards do, I understand PCI financial payment processing is one, but often ISO and management of change standards only require that you have processes which meet some more general requirements).
Storing document blobs in a database is only as good as the dbms user password. If the password is exposed it really doesn’t matter if the file system is encrypted (unless physical theft of the drive is your greatest concern). Vice versa, if you have good authentication processes, a “belt-and-braces” strategy may only make the system more complicated, not safer (and more complicated is often less safe).
IMHO the key is to have well defined traceable control over documentation related to Items (part numbers) and stock (physical substantiation of a part number). There must be controlled verified entry into the system, controlled management within the system, and no access from outside the system.
These steps can be configured as workflows within ERPNext, with flow moving from one step to the next based on user permissions and assigned roles.
A formal naming and numbering system customized to your unique needs is undoubtedly code you will need to write. I would suggest you keep naming and numbering under centralized manual control (e.g. a “doc control” office) and look to automate later. This can certainly be automated given an appropriate set of rules, but I would not recommend mixing the two.
IMHO you are setting a high minimum bar. I would look for parts of your process that do not need to change (i.e. your manual processes work as-is, although not as efficient as you would like) and initially implement ERPNext for what must be changed (either to correct an aspect of your current manual processes, or if required as part of a minimal ERPNext installation).
If possible, I would try to move automated naming and numbering to a parallel project, Even though it is desirable to complete both projects before going live, any delays in the naming and numbering should not impact the basic ERPNext implementation project. You may argue this is just “tomato tomahto” but perception is everything, and you do not want momentum in the erpnext implementation to be upset if it is difficult to achieve consensus on a definitive naming and number rule, or in its implementation (or just struggling to get consensus on the user interface).
How are you storing CAD documents now? Do you have the concept of a PLM now, or do you have the classic system where design documents are stored by domain (e.g. mechanical, electronics, PCB and especially firmware all have their their own way).
An ERP can be an opportunity to clean house, but only so much before the project loses clarity and focus (and you know where that leads… ).
What is the primary source of friction in your current system? Is it more related to the transaction processes in an ERP, or the change management of PLM? Can I also assume your “paper trail” process is well documented, and your new electronic system will require certification? I might consider how I might adapt the current certified process to the new process, and if one approach might be preferred over another based on ease of re-certification.