Are Database Objects Controlled Documents and/or Records?

[Manix]

Hi All,

I am currently trying to move my customer complaints, NCM and Customer returns over to a database approach from a heavily paper based system.

Now the paper based system has various forms all of which are standardised and the format of which is controlled using our document control system. So the format remains controlled and is always used.

Now I want to move all this over to an electronic database. Now reading the standard (TS), it seems I have to:

• Approve documents for use.
• Review and update and re approve.
• Revision status and changes are identified.
• Relevant versions are available at point of use
• Documents are identifiable
• Prevent unintended use of obsolete documents.

Now my dilemma is initially, is a database and it's forms, reports, tables etc... actually documents?

I am trying to figure out the controls I need to have in place.

My initial thoughts are:

- Control the database at the top level in terms of being able to edit. That way only the current approved versions of the database and it's elements are able to be used by users.
- Ensure changes to any elements of the database are approved and recorded.
- The very essence of a networked database means it is available at the point of use.
- Preventing use of obsolete documents will be done by only the approved version of the Database being available to users.

However, reporting from the database become documents, how do I identify them? The current forms have unique numbers, but I see no point in having this on reports coming from a controlled database???!!

Can anyone help with examples of how they have approached this very issue?

TIA

 

[Stijloor]

Hi All,

I am currently trying to move my customer complaints, NCM and Customer returns over to a database approach from a heavily paper based system.

Now the paper based system has various forms all of which are standardised and the format of which is controlled using our document control system. So the format remains controlled and is always used.

Now I want to move all this over to an electronic database. Now reading the standard (TS), it seems I have to:

• Approve documents for use.
• Review and update and re approve.
• Revision status and changes are identified.
• Relevant versions are available at point of use
• Documents are identifiable
• Prevent unintended use of obsolete documents.

Now my dilemma is initially, is a database and it's forms, reports, tables etc... actually documents?

I am trying to figure out the controls I need to have in place.

My initial thoughts are:

- Control the database at the top level in terms of being able to edit. That way only the current approved versions of the database and it's elements are able to be used by users.
- Ensure changes to any elements of the database are approved and recorded.
- The very essence of a networked database means it is available at the point of use.
- Preventing use of obsolete documents will be done by only the approved version of the Database being available to users.

However, reporting from the database become documents, how do I identify them? The current forms have unique numbers, but I see no point in having this on reports coming from a controlled database???!!

Can anyone help with examples of how they have approached this very issue?

TIA

Manix,

The easy way is to control everything electronically. Any report produced from this database has a limited "life" and is considered "uncontrolled." Some of my Clients print a footer on the document stating that it is only valid for 24 hours or state that any hardcopy report is considered uncontrolled.

Stijloor.

 

[BradM]

Manix, good questions.

In most of the databases I have worked within there is an output form or template. Be it through Crystal Reports or some other report generation system, there is a "fixed" format for which the data is rendered. So, we would always put form/data controls on the report. Then, any information being produced on the form would be just like writing something down.

Like paper forms, there are minor changes you may make (move a field over a bit) up to major. Usually, anytime the information would look different, it would call for a revision change. That, is entirely up to you.

Now... then you say forms, many times that is an input tool on a database. You may control that if you wish (limit what goes into the database), but I would only worry about the output (forms). Too, there may be several Ad Hoc reports you want for management use (sales figures, % in/out, etc.) that I would not put under change control. Just identify them clearly as management reports or something.

To me, while the spec. may not call for it, assure you have proper security/ access levels in place. Also, design the thing right up front, the first time. Whatever time you spend now, will return you 10 fold later.

 

[szohar]

Brad: To me, while the spec. may not call for it, assure you have proper security/ access levels in place. Also, design the thing right up front, the first time. Whatever time you spend now, will return you 10 fold later.

Agreed on all counts. My preferred approach: Don't allow anyone other than IT to tap directly into databases, and only release reporting tools to users when a decent amount of security and canned formatting is built into those tools.

It's a bit of a hassle when getting started, but as Brad said, it's better to invest the time up front. I have learned through painful experience that it's a lot uglier to fix that sort of thing later.

 

[Manix]

Thanks for the replies so far. Some valid points.

I think I should say that we are a very small company (sub 20) and I developed the DB myself, with no previous DB experience.

It has been a long and arduous road, but the system has been in place since the turn of the year in parallel with the paper based system. It has worked well, with some minor tweaks here and there.

I need to implement some kind of control over Access rights and perhaps a log in system. I think as long as I address the change control and security aspects, it will remain within the bounds of the standard.

 

[zancky]

Hi All,

I am currently trying to move my customer complaints, NCM and Customer returns over to a database approach from a heavily paper based system.

• Approve documents for use.
• Review and update and re approve.
• Revision status and changes are identified.
• Relevant versions are available at point of use
• Documents are identifiable
• Prevent unintended use of obsolete documents.

Now my dilemma is initially, is a database and it's forms, reports, tables etc... actually documents?


- Control the database at the top level in terms of being able to edit. That way only the current approved versions of the database and it's elements are able to be used by users.
- Ensure changes to any elements of the database are approved and recorded.
- The very essence of a networked database means it is available at the point of use.
- Preventing use of obsolete documents will be done by only the approved version of the Database being available to users.

However, reporting from the database become documents, how do I identify them? The current forms have unique numbers, but I see no point in having this on reports coming from a controlled database???!!

I'm not an expert but I have written my own database for material incoming inspection, gage and instruments device managing (calibration records/status/procedures), material NC managing. and it works fine

first I have studied the database standard rules (something you can fine in every DB book).

2nd I have designed the basic DB structure according to the db standard rules and I have found out the first problem. Applying the standard rules it would be difficult to keep trace of the changes (e.g. printing a report of two years old data I need the specification at that time). So I'm storing in a single table the data and the specification used to control that data. To me the format can be changed but not the content! .

Very important a backdoor that only YOU can use for correct input etc.
(don't allow anybody to know it, they will destroy the db integrity!)

3rd I have design the forms too (No problem for the revision of the format)

3rd I had request to my colleagues to use it. it was like a revolution I had to modify a lot of things to avoid mistyping, double click, insert explanation etc

4th the problem of special characters:some databases don't allow them and You need special tricks according to the software

the review / approval etc can be done very easily with a form once you state a version for your software. A paper document that states something like "we as YYY, approve the "XXXX" software into the revision "AAA" as valid to be used etc" or by electronic signature (a table field password controlled).


sorry but I don't understand revision concern Can you explain me?

best luck ( .. and please don't hesitate to ask me if you think I can help You)

 

[szohar]

One common convention I've seen (and use, when I have the option) is that software changes are released as "versions" while document changes are released as "revisions" - not everyone does things this way, but the distinction can be useful in terms of clarity, if nothing else.

I don't know if that was what Manix was referring to.

 

[Manix]

HI All,

I am now determined to get this DB up to speed and in full use so need it in line with TS16949 requirements.

My idea and hopefully my source of questions is detailed in the attached .pdf. Effectively if I control the revision of the whole DB, then I control both it's input and it's output. This is entirely feasible using our current change control process.

I will incorporate a change table with maybe some electronic signatures, but need to swat up on how to protect the DB using passwords and user names etc....!!!

I do have one small question still though: The revision will appear at the front console of the DB, but should the current revision of the DB be stated on all output reports? So in essence, this report was created using V1.1 of the DB?

I hope this is clear!!!

 

[CycleMike]

You should keep track of your database and all your changes to it using version numbers. But I would only have the documents themselves (reports) stamped with a small textbox, maybe at the bottom, that show the actual document revision.

Is your database MSAccess? Will you be splitting it into a frontend/backend?

If not, you should consider it. You can keep all the tables on the server and only have an .mde of the database on the users PC's. Then if you have to change a form or report or something, you only have to redistribute the updated frontend as an .mde. A plus is that no one can get into an .mde and change the reports or forms.

 

[Manix]

You should keep track of your database and all your changes to it using version numbers. But I would only have the documents themselves (reports) stamped with a small textbox, maybe at the bottom, that show the actual document revision.

Is your database MSAccess? Will you be splitting it into a frontend/backend?

If not, you should consider it. You can keep all the tables on the server and only have an .mde of the database on the users PC's. Then if you have to change a form or report or something, you only have to redistribute the updated frontend as an .mde. A plus is that no one can get into an .mde and change the reports or forms.

Thanks,

I think I will take you advice on the version numbers etc.... The front end back end thing I will proably look to do in the near future, but for the time being it will remain an mdb file. We are very small and there is only likely to be 2-3 users.