Records Management -Who decides where departmentwise records are stored?

[mbr22m]

Hi all,
I have some questions on records management. First some background.. I was responsible for document control of product documentation (datasheets, app notes, white papers) for a large, ISO compliant semiconductor corp. I started working for a fairly small Aerospace company (150 employees) doing doc control/processing for the engineering dept, but then was moved to doing doc control for the entire company in support of AS9100 certification/audit. I'm a little overwhelmed with the scale of everything, especially records management... Right now, no one consistently maintains their records. They are all over the place. My QA director is trying to tell me that I need to dictate where each department should store their records. It is my understanding that each department is responsible for maintaining their own records and deciding where they will be stored (as long as it's consistent and they are retrievable and identifiable) e.g. if the record originates from Engineering, Engineering will decide where they store the record and Doc Control will note on the Quality Records list. Am I correct, or do I need to go around and tell everyone exactly where they should store their records?? I apologize for my ignorance with this.. A lot of this is new to me, but it just makes absolutely no sense to me that doc control should dictate where each and every single record should be stored. What do other companies do?
Thank you all!

 

[Jen Kirley]

Re: Records Management

Can you meet them in the middle?

Can you find out who stores what how and where, and fill gaps with knowledge some people may not have about good practices to reduce the risk of loss based on type of media and the practices?

 

[mbr22m]

Re: Records Management

Hi Jennifer,
Thanks for the quick reply! That's kind of what I've been trying to do for existing records, but a problem I'm running into is that as QA writes new procedures, he's creating a lot of new forms and I really don't know where these will eventually be stored and the people that will be using them aren't really aware of them yet either.... So it's hard to determine where these records will go. There's been no training yet either and we have a Stage 1 on Monday!

 

[Michael_M]

Re: Records Management

The standard does not dictate anything about 'who' must control the records. The standard just wants the records identified, protected, retrievable, the retention of, and disposition of the records.

If specific department(s) are not willing to define these themselves, then that may be when you have to step in. I would get with the manager(s) of the department(s) and get a core concept for record retention (electronic records will be stored as PDF unless otherwise required), get a basic definition about where the files will be stored generally and document it.

For example, in our procedure, I have 'material certifications' stored as .PDF at "this specific folder location of our server" [Z:\Quality\Material Certifications]. This defines what type of record and where it is stored. The .PDF protects the file and makes it retrievable and the file name makes it identifiable. Get with the process owners and find out how/what they want to do based on these requirements since they are the ones who are going to be the ones doing it. We just choose to store material certifications as PDF's so we can access them easily. Records can be stored by whatever method is appropriate to how you do business.

 

[Michael_M]

Re: Records Management

Hi Jennifer,
Thanks for the quick reply! That's kind of what I've been trying to do for existing records, but a problem I'm running into is that as QA writes new procedures, he's creating a lot of new forms and I really don't know where these will eventually be stored and the people that will be using them aren't really aware of them yet either.... So it's hard to determine where these records will go. There's been no training yet either and we have a Stage 1 on Monday!

Also, don't be afraid of removing records that are not used anymore. During the discussion, ask what the record is for, and is it useful? If you can, remove the need for them. Be careful not to be overly ambitious and remove records that you actually need.

 

[mbr22m]

Re: Records Management

Thanks, Michael for listening to my rant and talking me down off the ledge.. Lol. Thanks for the guidance too; it seems less daunting now and more achievable. We just have so many new forms now (about 50) and we're under a really tight deadline, so I'm stressing. I do think like you said that some forms can be eliminated, which will help.

 

[Mikhail Sudbin]

Re: Records Management

I agree with Michael. You should keep only what is used. Also you may think about different classes of control to balance your efforts.

For example, some sensitive information may have class 1 control and stored in configuration management system with change control and other heavy-weight procedures. Some information (class 2) may be used just for reference and bulked into folder on the sever.

I usually aim at defining record storage policy. Each division (program) has its own relevant way to store information. However they are required to have record index, where they provide taxonomy of their data. Taxonomy includes data origin, control class, storage location and other properties. I audit if all used data is classified correctly and handled according to its class. Of course, record index is not too granular: it has entries like "Problem reports" or "Manuals", rather than "PR 1" or "Manual for ...".

 

[mbr22m]

Re: Records Management

Thanks, Mikhail. I just counted our new forms and we have 70 total right not =-O. So I'm hoping some can be weeded out. I like the idea of classes, as some records need to be more controlled than others (e.g. Engineering stores STCs in a safe)

 

[somashekar]

Re: Records Management

As you have posted in the AS9100 sub-forum., Please look into the following:
1. Your Statutory and Regulatory requirements
2. Your Customer requirements
3. Your QMS requirements