Changing Document Control software. Must I transfer EVERYTHING?

rogerpenna

Involved In Discussions
#1
Hello.

For a decade, my company used Excel tables to control documents. Then about 5 years ago, we acquired a software for document control, Non Conformity control, and other stuff.

It never fully satisfied us. The interface is clogged, clumsy and old. It has other problems that I wont describe in the OP (if someone is interested, I might later)


Anyway, we've been researching other software and we have now found a software we really like, both for ECM, Non Conformity/Action Plans and also for BPM Automation.



Question is... what kind of information do I need to take from the old software to the next? Do I need to take ALL old versions and revisions of a document? As well as the justifications for changes and the changes descriptions themselves?

Should I start documents in the new software from version 0.0 or from the current version in the old system?

What about the dates logged in the system... dates of release of versions or revisions, etc?


Can I take shortcuts and create a master document, like an Excel table, where I can easily input all the old info of the documents and then just reference it, probably in the Document Procedure?



---------------------------------------------------------------------------

Finally, saw some old Version vs Revision thread, but thought it was better to not ressurect it
https://elsmar.com/Forums/document-...ve-difference-version-revision.html#post97862


As we used a single number system in our previous system, we did not really worry about differences between version and revision. We basically we make a new version for ANY small change, if it was already published.


As I want to change this system for a XX.XX numbering system, my idea is VERSION.REVISION.

Version being major changes in formatting, info, etc, or changes that directly reflect on real world process, instruction changes, etc.

And revision being minor changes as well as changes due to mistakes not caught in the approval process (which can happen once in a while)


For example:

1.0
"In case of accident with an employer, ambulanc should be called"

both employer and ambulanc are in this case spelling mistakes. It's kinda obvious that we are not talking about the employeR, and that the real world procedure is about employees.
So we change REVISION

1.1
"In case of accident with an employee, ambulance should be called"

Obvious mistakes in text redaction also would only change revision

"In case of an accident with an ambulance, employee should be called"

While if we were an hospital that could be a real procedure, in our case it's obvious it is a text mistake, as the real world procedure is not like that.

So we would also change revision.




Now, suppose it's a real process change. Either it changed first in the real world and then the procedure text was changed to reflect it, or the inverse... first the process was discussed and revised, and then we tell the employees to follow it.

1.1
"In case of an accident with an employee, an ambulance should be called"

2.0
"In case of an accident with either employees or employers, ambulances should be called as well as the police"
 
#2
Most software, either built in or as a service from the company, will have a way to import legacy items and details into the new system. It may or may not allow importing of all the change record logs, but you should at a minimum get the last revision details.
If it were me, I would want as much detail as possible imported into my new system. It is important to be able to review previous changes to understand what happened and why.

As for the numbering schema, I have seen that type of numbering scheme at other companies before and it worked for them. It all depends on if the software is flexible enough to allow that type of documentation level control. At my last position, the software only allowed whole numeric revisions only, no alphanumeric or X.XX as you are thiniking.
 

rogerpenna

Involved In Discussions
#3
Yes, the one we are changing too allows XX.XX... in fact, it allows even XX.XX.XX.XX, which is way overkill for a DOCUMENT system imho... maybe for software it is necessary.

Although I guess some overzealous company might want to have several levels, so the first might be for major changes in the content of the document, second for small changes, third for aesthetic changes or changes in wording, etc, and last level just for small changes to correct spelling, some formatting error, etc.

But again... overkill.




"will have a way to import legacy items and details into the new system"

You mean, automatically? Maybe. Although that also depends on the previous software giving access to their database or having quality export functions.
 

ScottK

Not out of the crisis
Staff member
Super Moderator
#4
Yes, the one we are changing too allows XX.XX... in fact, it allows even XX.XX.XX.XX, which is way overkill for a DOCUMENT system imho... maybe for software it is necessary.

Although I guess some overzealous company might want to have several levels, so the first might be for major changes in the content of the document, second for small changes, third for aesthetic changes or changes in wording, etc, and last level just for small changes to correct spelling, some formatting error, etc.

But again... overkill.




"will have a way to import legacy items and details into the new system"

You mean, automatically? Maybe. Although that also depends on the previous software giving access to their database or having quality export functions.
So I don't do "versions".
I only do revisions and that has served me just fine for a long time.
I've worked with software that would allow "Major" and "Minor" revisions, but I always found it much cleaner to just increase the Rev and not deal with sub-revs.

So for very minor things like typos and grammatical corrections I would write into the procedure that up-revving is not needed. Simply swap out the document with the changes, but still document what occurred in the rev history, just don't give it a rev number. Also for these sort of revisions no training would be needed.
Alternately at other places I have up-revved for minor changes, but the approval process was just me for those kind of changes - didn't need process owner signoff, etc.

As far as converting from an old system to new I suggest you perform a thorough audit and determine if you can obsolete any docs and clear them out. Otherwise I would think that everything has to come over unless you're going to run two documentation systems.

The most important thing is document the methodology you plan on using and the timeline. There is no reason that you can't convert from System A to System B slowly and keep the old system running while converting to the new. I would advise against just keeping things in the old system until they need revision, then revise into the new system. This can take a long time and could create confusion.
 

Top