Definition & Management of In-House Database Revisions

C

C.E. Marshall

Definition & management of revisions of in-house d-bases

Our company has a "mature" quality system that is gaining momentum in our efforts to move from paper to electronic documentation. Since the inception of our QS we have used a document change process that has "controlled" every change for almost every document. The processes key input is a formal approval and one of it's key outputs is a change record. The exception to this formal approval process and resulting record trail has been our in-house databases that are regularly being "tweaked" to meet internal customer requirements. These continuous improvements are a good thing, but we struggle with what constitutes a change and if, when, or how to record these changes. Currently we enter these databases onto our master lists, but the majority are still the original issue despite numerous tweaks. D-bases are maintained on our network, are regularly backed up, and users can only access the most current" version. So, how do other folks define and manage all types of changes/revisions to internal databases?

Thanks C.E. Marshall
 

E Wall

Just Me!
Trusted Information Resource
I design and use Access db's to handle all but production/scrap reporting (done under another 'corporate' system) and SPC (we've about 250-300 created in Excel (set-up blank forms) for various departments processes - but capture data and maintain by hardcopy records only).

No one has ever questioned (including myself) the 'continual improvements' made to the db systems. It has never come up in registrar audits or any internal audits since I've been here and the company began using them (3.5 yrs). We're currently 9002 v1994 certified, going towards v2000 with goal of certification transition by Jan 2003.

I would have to say, under the v2k, that this falls under clauses 6.3, b & c as well as the 4.2.3 and 4.2.4, one could arguably include 8.4 since we do have SQC software that is used during receiving inspection of some purchased components.

Since I haven't gotten far in my transition effort, I don't have any answers for you right now...but will make a note of this thread (and you) to follow-up on/with at later date. Off the top of my head, I would be considering...adding a db change log identifying what was added/changed/deleted, as well as why and who did it (if there is more than 1 person that might this will be helpful....or down the road for those of us that do everything - but hey I can set myself as a default value so it's not extra data entry).

The rest will take a deeper review, but thanks for adding to my to-do list, maybe it will help in job security! Hehehe :biglaugh:
But seriously, I do appreciate your bringing this up for discussion and am interested in what information is gathered.
 
C

C.E. Marshall

Well it's been a week, and based on the one response, I'm wondering if this is the right forum to ask this question? Is this not an issue in the opinion of QS folks, from gurus to novices, or is it simply an issue that's difficult to answer? Still looking for help. CM
 
M

Michel Saad

Hey C.E.

Electronic Forms to fill out managed in a databse are always at the latest revision and do not have a form number or a revision. The minimum requirements of the form are spelled out in the corresponding procedure. If you make a major change to the db, then the procedure changes. If it is a small change, the change is logged for tracability purposes only.

We have a few forms that are very critical (ex: part creation form) that interface with our production software and those are controlled through ECN's.

For the forms that are still on paper, we still have a number and rev to prevent usage of an obsolete document.

Regards,
 
Top Bottom