Archiving Data
Archiving is a much-misused term when it comes to asset-managent databases. Suppose that you were managing your inventory using old-fashioned paper files. You might have a file for each asset in which you kept all relevant information, ranging from the original purchase order, all its service reports etc. What would you do when the device was decommissioned? One approach would be to write “SCRAPPED” in big red letters across the front of the file and then put it back into your filing cabinet. You would be unlikely to shred it, after all you might still need to access the file for some time.
Time passes, and it’s now 10 years since you scrapped this item. By now, you probably have added a few more filing cabinets to your collection, as you not only have a file for every one of your active devices, but also for every device that you have scrapped over the last 10 years. As your collection of files grows you are faced with a choice – get a bigger office or do something about the really old files that you are unlikely to ever need again. Some companies have their own departments who will take these files off your hands and store them safely for you, although hopefully safer than in Dilbert’s company 🙂
Copyright (c) United Feature Syndicate Inc. 1997
This is what archiving means. An archived file is no longer in your filing cabinet; you can’t get immediate access to it but it is possible to get it back (eventually) in the rare situation when you need it. The analogy with computer files or databases is not much different. Once you no longer need immediate access to data it can be archived – i.e. removed from its normal location and stored off-line. Archiving a database record implies that it will be deleted from the database and copied elsewhere and you will no longer have immedidate access to those data. Arguably the concept of archiving data is not really that relevant these days. A database recording every job done on every device in every hospital in the UK since the founding of the NHS in 1948 could be handled by quite a modest server. As long as you can easily find what you’re looking for without old data getting in the way, there really is no compelling reason to archive data at all.
How Can you Stop “Old” Data Getting in the Way?
If you never archive old data, how do you stop it from getting in the way? Suppose that you have just scrapped an MS26 because it failed with fault code “AE32” (I just made that up, so don’t bother looking for it in the MS26 specification!) and can’t be repaired. Having written “SCRAPPED” in big red letters across the front of the equipment file; do you still need access to that file? Suppose you wanted calculate the average life and MTBF of the MS26 – you would need to be able to see every job that has ever been done on an MS26 in order to do this, so you would still need to see the files for all your scrapped MS26’s. What if in 2 years time another MS26 fails with fault code “AE32” and the engineer wants to find out how this was resolved in the past. Again the job details of the scrapped device would come in useful.
Delving a little deper, what does “getting in the way” actually mean? By far the most common searches in a database like E-Quip are for things like:
1. A particular asset
2. A particular job
3. All jobs for a particular asset
4. All jobs carried out within a specified date range (by model, location, team, technician etc)
5. All jobs planned within a specified date range (by model, location, team etc)
In all of these searches. no “old” information will be retrieved unless you are specifically searching for it. In fact, in practice, it turns out that all of this old information doesn’t really get in the way at all – people just have a perception that it does.
There is however, an exception to this. When users are entering data there is always the possibility of error. People aren’t computers – they make mistakes, and one situation where “old” data can be problematic is when it is referenced in error. For example, when raising a job a user might mistype an equipment serial number and inadvertently select a redundant asset. A mechanism is needed to prevent this.
Deactivating Records
There are many examples of errors that should be prevented, but some of the most common include:
1. Creating a job for a scrapped device
2. Creating a new asset using an obsolete model
3. Assigning a device to a closed ward
4. Assigning a technician who has left your employment
5. Using an obsolete spare part on a job
6. Using decommissioned test equipment on a job
7. Assigning a device to an expired contract
In E-Quip, these problems are solved by deactivating records. In order to deactivate any record simply select it in the appropriate summary screen and then choose “Deactivate Record” from the Office menu. What will this achieve? The most common way that users select data when creating or editing assets, jobs etc. is by using the lookup control. The primary effect of deactivating any record is that it will no longer appear in lookups. This is worth restating:
“The primary effect of deactivating any record is that it will no longer appear in lookups”
Notice that by default making a record inactive does not affect its visibility except when using the lookup control. For example, an inactive device may or may not appear on the equipment summary screen, depending on the system configuration. However, it will never appear in a lookup. All of the 7 examples listed in the previous paragraph are addressed by deactivating records.
Any record can be reactivated by selecting it in the appropriate summary screen and choosing “Reactivate Record” from the Office menu.
How are Inactive Records Displayed?
By default inactive records are displayed in summary screens in exactly the same way as active records, although conditional grid formatting can be used to display them in a different colour. However, the Role Manager can be used to configure roles so that inactive data is hidden by default. The status bar at the bottom of the summary screen will indicate whether or not inactive records are being displayed.
The default condition for any user will depend on the configuration of the role that the user belongs to. If the user is not a member of a role then the default will be ACTIVE, i.e. only active records will be displayed.
In order to change the current setting, press the F6 key, which will toggle the setting. i.e. if the current setting is ACTIVE, then pressing F6 will change it to INACTIVE; if the current setting is INACTIVE then pressing F6 will change it to ACTIVE. Note that after changing this setting you must refresh the screen (F5) for it to take effect.
When the status bar setting says INACTIVE, this means that both active and inactive records will be displayed.
Deactivating Jobs
Deactivating data records like assets, models, spare parts, locations etc as a means of preventing them from being selected by mistake is a simple enough idea to understand, but why is it possible in E-Quip to deactivate a job? What does an inactive job actually mean?
The PPM auto-scheduling mechanisms used by E-Quip means that future PPM jobs are created when current PPM jobs are closed. For example, if a device is on 2 PPM schedules, say a 6-monthly and an annual service. Completing the 6-monthly service will automatically generate the next 6-monthly job; completing the annual service will automatically generate the next, and so on. This means that there will always be 2 open jobs for this device. If this device is removed from service, then these 2 jobs will remain in the database forever. They will never actually be completed because you would never complete a PPM job on a decommissioned device.
Would it make sense to delete these 2 jobs, as they will never be done? Well, if you’re absolutely certain that the device will never come back into service, and you’re 100% certain that you have not accidentally decommissioned the wrong asset, then that might be a possibility. But if the device ever did re-enter service you would have to re-create the PPM jobs you have just deleted.
You could give the jobs a special status, something like “CANCELLED”, but then you would have to remember when planning future PPM work to exclude all “CANCELLED” jobs, which is extra work.
When an asset is decommissioned (i.e. its status is set to a value with ther status class of “Decommissioned“), then E-Quip takes the following actions:
1. The asset is deactivated
2. All non-completed jobs for the asset are deactivated
We can see now that deactivating jobs is simply a convenient mechanism for hiding jobs which will never actually be done because the device that they relate to has been decommissioned. This is the only reason that jobs should be deactivated.
Other systems that you may have seen use pseudo-archiving as a way of locking completed jobs, or to implement so-called “soft” deletes; both of which, in our view, are a thoroughly bad idea.