Should software be controlled in the same manner as documents?

[qualitychic]

I agree with Chergh. Let's not make our lives more difficult than it already is... I wouldn't bother to control which MS office software. But, I would control software that I use to produce/accept product. For example, I would control the version of the BIOS that we upload into our computer or I would control the version of testing softwares that I used on the production. Again, this is only my opinion.

 

[vanputten]

It may be a marketing ploy. But what does it matter? The reason for multiple versions of software that don't necesarily work well together doesn't matter. The end result is users of the software need to know what version they are using.

What is the question trying to be answered?

Is the question, "Is software a document?"

Is the question, "Should software be controlled LIKE a document?" (I am not sure what "like a document" means.)

Is the question, "Should software be part of our business management system?"

I was providing an example which I hoped caused readers to think about the concepts of control. If people want to discuss the reason for software versions, etc., have a great time.

Unquestionably, organizations must know what version of software they are using. Must! Does the software need to be controlled like a document? No idea. That depends on the organizations operational defiention of "control of documents." Is software a document? I would say, "No." Should software be part of the business managmement system? Yes. Why not?

Regards,

Dirk

 

[James Gutherson]

Unquestionably, organizations must know what version of software they are using. Must!
Dirk

I don't agree. Not all organisations need to know what version of software they are running. A small tool shop that has a predominatly paper based process control system, ie some paper manuals and work instructions only needs to be able to access their documents to print of make changes - the software is a tool to do this. It would depend on the format of the document but say a *.txt file could be read by virtually any version of Word, WordPerfect, Write, Notepad, or their MAC equivalents, or a web browser. In this case the documents themselves are the control element.

The situation where control of software versions becomes critical is where the software itself has an infulence over the outcome of the process - such as decision support software, or a database application with business processes built in.

There are grey points in the middle where say a Word document uses features of the latest version that mean it will not open in earlier versions - but I would still argue that the critical control is the document rather than the software.

Anyway this is my opinion,... and ain't diversity grand.

 

[al40]

I have written a very simple procedure that states that states that all commerical software is excluded from revision control. We do however validate and control all home-grown software that is used to accept product or used in business making decesions like an accoutning spreadsheet that is used by our managers. My advice is "KISS" keep it simple.

best regards,

al40

 

[David DeLong]

I would not suggest controlled software in the same manner as other controlled documents BUT one should have all computer files noted in their Records section and back ups should be taken off site about once per week.

 

[M Greenaway]

What elements of 'control' should be placed over a home grown database system, lets say a non-conformance database made by yourself in Lotus Notes ?

 

[Manix]

What elements of 'control' should be placed over a home grown database system, lets say a non-conformance database made by yourself in Lotus Notes ?

Whoa!!! You are asking the exact question I was going to add to this thread!!! I have just done a non conformance database (In Access though) and I would like to know whether people think it needs to be controlled like a document.

My take is that document control is there to control the format and content of documents.

I.e a controlled form is controlled so that the information the user fills in is consistent and meets the organisations current requirements for capturing specific data (Format).

A controlled specification, is controlled so that the content represents the current status of the actual part/process etc.... (Content)

A database is a tool to capture data. So both "Format" and "Content" apply, so I would say they need to be applied. A database has forms, the format of which would need to be controlled to ensure that the current version represents the current requirement for data capture. A database can contain information, which maybe updated periodically and so should this not be controlled?!!!

However, it does get a little confusing, because a database, is usually a single entity available to multiple users. It's not quite the same a piece of paper that can have multiple versions. Or is it? You could have multiple version of the same database? Do you? Should you? Ummm I'm confused. For backup purposes you probably do have multiple copies and maybe that's the reason you should control your database and it's contents with version control.

Does anyone have an example of a database with efficient version control of both the format and the content?

 

[chergh - 2008]

I don't bother with version control for my databases, I just cant see any point, and I regularly add and remove functionality.

The only control over my databases is security to prevent the average user from accessing anything that might affect the data in the database and the only other control I suppose is that I look after it.

If I make changes to my databases that affect the users, e.g. change a form, add/remove a field etc. then these changes will be reflected in updated work instructions or procedures.

The only time I would see change control being relevant to these sorts of databases is when you have frontend clients on individuals machines then when a new verion of these frontends are released you have to ensure all have the new frontend. I don't have enough users of my databases to be bothered with splitting like this.

So in essence I see no need for version control of apps like databases for NC's or internal audits when they are not split into front and backends.

 

[CliffK]

Been there, done that, with databases.

A strict interpretation of ISO 9001 would require you to have a control procedure for these databases. Except for media, how are they different from the other forms you use?

Personally, I wouldn't write a control procedure unless forced to. Luckily, most auditors don't seem to recognize the application OR they have the wisdom to avoid making a fuss about a non-problem.

About splitting the database between client and server--don't do it. Keeping the clients updated is a terrible chore.

Side note: this is Microsoft Excess, right? It's a bandwidth hog, which is why MS suggests splitting the databases. There are lots of cost-effective (even free) alternatives that make your data accessible by browser.