I’ve had experience at one company with ERP systems validation.
There are a few things of an ERP system which can be considered GMP, and other functions which are not GMP. Your question shows that you have a correct high level understanding about this.
GMP features might include expiration dating assigning, inventory control (first-in-first-out or first-expired-first-out), or lot number assigning/database (are there other functions I’m just not thinking of?).
Some ERP systems contain bill of materials, to help manufacturing “pull” the correct material from the warehouse for manufacturing. These bill of material lists should be validated. Same thing if the ERP system is used to generate a “bill of documents” for all the forms, manufacturing orders, etc. which might need to be printed to be completed for manufacturing. The bill of documents should also be a validated system.
While other functions are not GMP, and do not require validation. These might be finances or manufacturing scheduling (but I could see an auditor arguing that scheduling is critical and if done poorly could upset quality operations).
Basically, I would validate any feature which is universal, such as log-in, security, backup/archive, and audit trails as these affect the GMP features as well as the non-GMP features… I would then validate GMP functions. I would not validate the financial or scheduling aspect of the ERP system, except maybe in a commissioning document, testing that it works correctly, but never claiming that it is GMP. But at this point it might be easier to validate everything together.
I would prepare a validation plan or traceability matrix, in which you lay out the various features of the system, and indicate if they are GMP/non-GMP, and thus if they will be validated (GMP) or commissioned (non-GMP). If there are features that an auditor believes should be GMP, you will at least be able to show them the commissioning document. Also, the auditor might be pleased with your traceability matrix, and feel that you have shown correct control and understanding of your system (what the purpose of validation is), and then not feel the need to dig super deep into the individual test cases.
I’m not much good at computer validation, so take my advice with a grain of salt. I believe Graham O’Keefe (CEO of this forum) has a bit more computer validation experience than I do.