How do I validate our ERP system?

Hello All -

This may be a silly question - but I would like to get the opinions of you all to make sure we do this validation the right way.

We are currently a paper-based system. Paper Order Trackers are used to track the whole job, including who took the order, who ran the job, who mixed it, who inspected it, who shipped it - EVERYTHING. We are moving towards a CUSTOM made electronic system. No more paper.

We have not conducted much validation on anything - and I know software needs to be validated. What is the simplest, but best way to validate this type of software?

Do we go through a few trial runs using the software and just cross check to make sure nothing is missed? If so, how many trials are a good amount? We produce around 250 lots a month...

Thoughts?

Thank you in advance!
-Nikki

 

Hmmm, never quite had to validate an entire ERP system when I worked in medical device, though I did have to conduct similar efforts for our Preventive Maintenance (glorified Access database) software, Access databases which stored final inspection procedures (and records), Adobe Acrobat for DHR scan & storage, programmable table top vision systems, and certain Excel spreadsheets which calculated Ppk or GR&R.

Defining user (your) requirements, i.e. what (QMS) processes are controlled by this software, is an essential place to start.

From there one can generally go the IQ/OQ/PQ route. For each of these steps, we would compose a protocol which defined the requirements, criteria for acceptance, and reference instructions/ documentation, and obtain cross-functional management (and Customer?) approvals. After executing the planned testing/ answering the checklist questions for compliance per the protocol, results, and any deviations from plans are outlined in a report which also indicates whether results are overall acceptable, and reports are approved by protocol approvers.

Essentials for the IQ phase: software identification and revision control, data storage and backup arrangement, controls of access to system data (and verifibility of who/ when data is altered), identification of compatible users' hardware, compatibility of accessories (barcode scanners, label printers, data entry aids or attached gaging), adequate server hardware per manufacturer's specifications.

OQ phase: define the tasks the system is used for, trial runs to determine functionality, ensure adequate work instructions are developed for consistent execution of tasks, testing of data integrity per plan defined in IQ stage

PQ phase: challenge the system to ensure robustness. Will system require multiple people to utilize at once? If so, trials of function with multiple users inputting at once. Identify risks (likely through FMEA or FTA) to system stability and test out against them, including entry controls which assure that a response is present, or programmed controls for proper coding or formatting of input data. Determine method and frequency for revalidation/ validation review.

Regarding sample size, we generally didn't do a full "power and sample size" routine like we did for dimensional product data, we seemed to get by with 3 distinct trials or test cases for transactional tasks within the software. You may want to do something statistical to sample records created by the software. Use risk-based rationale to justify heightened or minimal testing.

Hope this gets you started, I'm sure others will have more details...

 

Well, I'll be validating a new ERP system sooner or later. Implementation is currently 2 years behind, lol!

However, I am not the person writing the protocols. Someone at another location that is currently implementing the system is. I will simply be executing the protocols. And I have yet to see them.

I would assume they will be similar to other software validations I have completed. Run through some examples and verify that the expectations are met. Information entered one place is moved to another location and is correct, reports print the correct information, searches yield the correct information. When you select an option, the correct thing happens, navigation through the system works, ect. For us we would do one validation per product type. Sample size doesn't necessarily correlate here. It helps if you know the in's and out's of the software so that you know where mistakes could happen. Data tables should be reviewed....

Software validation is not fun. Sometimes you can pay the software company to write the validations for you, and you approve the protocol and execute. That may be of value to you if you are unfamiliar with software. It isn't cheap though.

 

This may help, or completely confuse you!

 

Consider to use the GAMP guidelines by ISPE

s

 

For those who might not be aware:
IQ = Installation Qualification
OQ = Operational (sometimes also referred to as Operator) Qualification
PQ = Performance Qualification

 

Good ))