The greatest knowledge-loss disaster I can think of was the destruction of the great library of Alexandria by fire around 642 AD. This was the world’s largest and most complete store of knowledge at the time and it was almost totally destroyed. It would take over a thousand years for mankind to rediscover and regain the knowledge that went up in smoke and to this day we still don’t think we have recovered or re-discovered a lot of what was lost. It was an unmitigated disaster for mankind because nearly all of Alexandria’s records were flammable and most were irreplaceable.

By contrast, we still have far older records from ancient peoples like the Egyptians of five-thousand years ago because they carved their records in stone, a far more durable material.

How durable and protected are your vital records?

I mentioned vital records because disaster recovery is really all about protecting your vital records.  If you are a business a vital record is any record without which your business could not run. For the rest of us a vital record is irreplaceable knowledge or memories. I bet the first thing you grab when fire or flood threatens your home is the family photo album or, in this day and age, the home computer or iPad or backup drive.

In 1996 I presented a paper to the records management society titled “Using technology as a surrogate for managing and capturing vital paper based records.” The technology references are now both quaint and out-of-date but the message is still valid. You need to use the most appropriate technology and processes to protect your vital records.

Interestingly, the challenges today are far greater than they were in 1996 because of the ubiquitous ‘Cloud’.  If you are using Google Docs or Office 365 or even Apple iCloud who do you think is protecting your vital records? Have you heard the term ‘outage’? Would you leave your children with a stranger, especially a stranger who doesn’t even tell you the physical location of your children? A stranger who is liable to say, “Sorry, it appears that your children are missing but under our agreement I accept no liability.” Have you ever read the standard terms and conditions of your Cloud provider? What are your rights if your vital records just disappear? Where are your children right now?

Some challenges are surprisingly no different because we are still producing a large proportion of our vital records in paper. Apart from its major flaws of being highly flammable and subject to water damage paper is in fact an excellent medium for the long term preservation of vital records because we don’t need technology to read it; we may say paper is technology agnostic.

By contrast, all forms of electronic or optical storage are strictly technology dependent. What good is that ten year old DAT tape if you no longer have the Pentium compute, SCSI card, cable and Windows 95 drivers to read it? Have you moved your vital records to new technology lately?

And now to the old bugbear (a persistent problem or source of annoyance), a backup is not disaster recovery. If your IT manager tells you that you are OK because he takes backups you should smack him with your heaviest notebook, (not the iPad, the iPad is too light and definitely not with the Samsung tablet, it is too fragile).

I have written about what disaster recovery really involves and described our disaster recovery services so I won’t repeat it here, I have just provided the link so you can read at your leisure.

Suffice to say, the objective of any disaster recovery process is to ensure that you can keep running your business or life with only a minimal disruption regardless of the type or scale of the disaster.

I am willing to bet that ninety-percent of homes and businesses are unprepared and cannot in any way guarantee that they could continue to run their business or home after a major disaster.

We don’t need to look as far back as 642 AD and the Alexandria Library fire for pertinent examples. How about the tsunami in Japan in 2011? Over 200,000 homes totally destroyed and countless business premises wiped from the face of the earth. Tsunamis, earthquakes, floods, fire and wars are all very real dangers no matter where you live.

However, it isn’t just natural disasters you need to be wary of. A recent study published by EMC Corporation offers a look at how companies in Japan and Asia Pacific deal with disaster recovery. According to the study, the top three causes of data loss and downtime are hardware failure (60%), data corruption (47%), and loss of power (44%).

The study also goes on to analyse how companies are managing backups and concludes, “For all the differences inherent to how countries in the Asia Pacific region deal with their data, there is at least one similarity with the rest of the world: Companies are faced with an increasing amount of data to move within the same backup windows. Many businesses in the region, though, still rely on tape backup systems (38%) or CD-ROMs (38%). On this front, the study found that many businesses (53%) have plans to migrate from tape to a faster medium in order to improve the efficiencies of their data backup and recovery.”

It concludes by estimating where backups are actually stored, “The predominant response is to store offsite data at another company-owned location within the same country (58%), which is followed by at a “third-party site” within the same country.”

I certainly wouldn’t be relying on tape as my only recovery medium and neither would I be relying on data and systems stored at the same site or at an employee’s house. Duplication and separation are the two key principles together with proven and regularly tested processes.

I recently spoke to an IT manager who wasn’t sure what his backup (we didn’t get to disaster recovery) processes were. That was bad enough but when he found out it seemed that they took a full backup once a month and then incremental backups every day and he had not tested the recovery process in years. I sincerely hope that he has somewhere to run and hide when and if his company ever suffers a disaster.

In a nutshell, disaster recovery is all about being able to get up and running again in as short a time as possible even if your building burns to the ground. That in fact is the acid test of any disaster recovery plan. That is, ask your IT manager, “If this building burns down Thursday explain to me how we will be up and operating again on Friday morning.”

If his answer doesn’t fill you with confidence then you do not have a disaster recovery plan.

We have all heard and read a lot about the Cloud and why we should all be moving that way. I wrote a little about this in a previous post. However, when we look at specific applications like records management we need to think about the human interaction and how that may be affected if we change from an in-house system to a hosted system. That is, how will the move affect your end-users and records management administrator? Ideally, it will make their job easier and take away some pain. If it makes their job harder and adds pain then you should not be doing it even if it saves you money.

We also need to think about the services we may need when we move to the Cloud. That is, will we need new services we don’t have now and will the Cloud vendor offer to perform services, like application maintenance, we currently do in-house?

In general, normal end-user functions should work the same whether we are running off an internal system or a Cloud-based one. This of course will depend upon the functionality of your records management software. Hopefully, there will be no difference to either the functionality or the user interface when you move to the Cloud. For the sake of this post let’s assume that there is a version of your records management system that can run either internally or in the Cloud and that the normal end-user interface is identical or as near-as-such that it doesn’t matter. If the end-user interface is massively different then you face extra cost and disruption because of the need to convert and retrain your users and this would be a reason not to move to the Cloud unless you were planning to change vendors and convert anyway.

Now we need to look at administrator functions, those tasks usually performed by the records management administrator or IT specialist to configure and manage the application.  Either the records management administrator can perform the same tasks using the Cloud version or you need to ask the Cloud vendor to perform some services for you. This will be at a cost so make sure you know what it is beforehand.  There are some administrator functions you will probably be glad to outsource to the Cloud vendor such as maintaining the server and SQL Server and taking and verifying backups.

I would assume that the decision to move a records management application to the Cloud would and should involve the application owner and IT management. The application owner has to be satisfied that the end-user experience will be better or at least equal to that of the in-house installation and IT management needs to be sure that the integrity and security of the Cloud application will at the very least be equal to that of the in-house installation. And finally, the application owner, the records manager, needs to be satisfied that the IT support from the vendor of the Cloud system will be equal to or better than the IT support being received from the in-house or currently out-sourced IT provider.

There is no point in moving to the Cloud if the end-user or administrator experience will deteriorate just as there is no point in moving to the Cloud if the level of IT support falls.

Once you have made the decision to move your records management application to the Cloud you need to plan the cutover in a way that causes minimal disruption to your operation. Ideally, your staff will finish work on the in-house application on Friday evening and begin working on the Cloud version the next Monday morning. You can’t afford to have everyone down for days or weeks while IT specialists struggle to make everything work to your satisfaction. This means you need to test the Cloud system extensively before going live in production. In this business, little or no testing equals little or no success and a great deal of pain and frustration.

If it was me, I would make sure that the move to the Cloud meant improvements in all facets of the operation. I would want to make sure that the Cloud vendor took on the less pleasant, time-consuming and technical tasks like managing and configuring the required IT infrastructure. I would also want them to take on the more bothersome, awkward and technically difficult application administration tasks. Basically, I would want to get rid of all the pain and just enjoy the benefits.

You should plan to ‘outsource’ all the pain to make your life and the life of your staff easier and more pleasant and in doing so, make everyone more productive. It is like paying an expert to do your tax return and getting a bigger refund. The Cloud solution must be presented as a value proposition. It should take away all the non-core activities that suck up your valuable time and allow you and your staff more time to do the core activities in a better and more efficient way; it should allow you to become more productive.

I am a great believer in the Cloud as a means of improving productivity, lowering costs and improving data integrity and security. It is all doable given available facilities and technology but in the end, it is up to you and your negotiations with the Cloud provider.  Stand firm and insist that the end result has to be a better solution in every way; compromise should not be part of the agreement.

Have you ever had to remove files from shelving or cabinets and reallocate them to other spaces because a drawer or shelf is packed tight? Then had to do it again and again?

One of my favourite records managers used to call this the “Squishing” problem.

The squishing problem is inevitable if you start to load files from the beginning of any physical filing system, be it shelving or cabinets and unload file files from random locations as the retention schedule dictates. If you create and file parts (a new folder called part 2, part 3, etc., when the original file folder is full) then the problem is exacerbated. You may well spend a large part of your working life shuffling file folders from location to location; a frustrating and worthless, thankless task. You also get to inhale a lot of toxic paper dust and mites which is not a good thing.

You may not be aware of it but there is a very simple algorithm you can utilize to make sure the squishing problem never happens to you. It is usually referred to as the ‘Terminal Digit’ file numbering system but you may call it whatever you like. The name isn’t important but the operation is.

Importantly, you don’t need to change your file numbering system other than by adding on additional numbers to the end. These additional numbers are the terminal digits.

The number of terminal digits you need depends upon how many file folders you have to manage. Here is a simple guideline:

·         One terminal Digit (0 to 9) = one thousand files

·         Two Terminal Digits (00 to 99) = ten thousand Files

·         Three Terminal Digits (000 to 999) = greater than ten thousand files

Obviously, you also have to have the filing space and appropriate facilities available (e.g., boxes, bays, etc.,) to hold the required number of files for each terminal.

It is called the Terminal Digit system because you first have to separate your available filing space into a number of regular ‘terminals’. Each terminal is identified by a number, e.g., 0, 1, 2, 09, 23, 112, 999, etc.

The new terminal digit is additional and separate from your normal file number. It determines which terminal a file will be stored in. Let’s say your normal file number is of the format YYYY/SSSSSS. That is, the current year plus an automatically incrementing auto number like 2012/000189 then 2012/000190, etc. If we use two terminal digits and divide your available filing space into one hundred terminals (think of it as 100 equally sized filing slots or bays numbered 00 to 99) then your new file number format is YYYY/SSSSSS-99. The two generated file numbers above may now look like 2012/000189-00 and 2012/000190-01.

File folder 2012/000189-00 is filed in terminal number 00 and 2012/000190-01 is filled in terminal number 01. In a nutshell, what we are doing is distributing files evenly across all available filing space. We are not starting at terminal 00 and filling it up and then moving on to terminal 01, then terminal 02 when 01 is full etc. Finding files is even easier because the first part of the file number you look at is the terminal digit. If a file number ends in 89 it will be in terminal 89 in file number order.

The other good news is that when we unload files from the shelves say at end of life or at the point in the lifecycle when they need to sent offsite we will also unload files evenly across all available filing space. If the terminals are actually big enough and if you have calculated everything correctly you should never again suffer from the ‘squishing’ problem and you should never again have to ingest paper dust and mites when tediously shuffling files from location to location.

Obviously, there is a little more to this than sticking a couple of digits on the end of your file number. I assume you are using a computerised records management system so changes have to be made or configured to correctly calculate the now extended file number (including the new terminal digit) and your colour file labels will need to be changed to show the terminal digit in a prominent position.

There is also the question of what to do with your existing squished file store. Ideally you would start from scratch with your new numbering systems and terminals and wait for the old system to disappear as the files age and disappear offsite to Grace or Iron Mountain. That probably won’t be possible so you will have to make decisions based on available resources and budget and come up with the best compromise.

I can’t prove it but I suspect that the terminal digit system has been around since people began filing stuff. It is an elegantly simple solution to an annoying and frustrating problem and involves nothing more complicated than simple arithmetic.

The surprise is that so few organizations actually use it. In twenty-five plus years in this business I don’t think I have seen it in use at more than one to two-percent of the customers I have visited. I have talked about it and recommended it often but the solution seems to end up in the too-hard basket; a shame really, especially for the records management staff charged with the constant shuffling of paper files.

It may be that you have a better solution but just in case you don’t, please humour me and have another look at the terminal digit filing solution. It may just save you an enormous amount of wasted time and make your long-suffering records staff a lot happier and a lot healthier.

Twenty-eight years ago we released our first records management product, DocFind I.

Twenty-six years ago we released the first version of our iconic records management product RecFind 1.0.

Twenty-five years ago we released our first imaging enabled records management product, ImageFind 1.0.

Thirteen-years ago we shipped our first fully featured Electronic Document and Records Management Solution (EDRMS) with a full complement of records, document, imaging and workflow functionality, RecFind 3.2.

Twenty-five years ago I used to do a lot of trade show and seminar presentations about the coming paperless office yet here we are today with more paper records in existence than I would have ever imagined all those years ago. The fabled paperless office as far away now as it has ever been.

It isn’t because of a lack of functionality to deal with the problem. Most of the other vendors did what we did and produced products merging records, document and imaging functionality many years ago so the functionality to facilitate the paperless office has been around for a very long time. Yet, governments and private companies are still using paper as records and are still using and storing billions of sheets of paper each year. Organizations like Iron Mountain and Crown are rushing to build new warehouses all over the world to store boxes of paper records and there seems to be no end in sight. We are drowning in paper.

In order to understand why we are still storing millions of boxes of paper every year we have to ask ourselves two very important questions:

1. What are we (still) doing we shouldn’t be doing?; and
2. What is it we should be doing that we are (obviously) not doing?

Answering number one is easy; we are still using paper and are using it at a rate many, many times that of twenty-five years ago.

Answering number two is also easy; we are not taking advantage of available technology.

The next and most important question to ask is why? Why are we still using paper and why aren’t we taking advantage of available technology?

I have pondered the above questions for a long time and have discussed them at length with my customers and staff and associates in the industry for many years. Whereas you are likely to get any number of responses from industry experts, I am going to narrow it down to four simple issues.

1. Paper is actually still a great medium for many applications and its convenience, cost and flexibility is hard to beat;
2. Most electronic document management systems on the market today are expensive to buy, difficult and expensive to roll out, difficult to use and difficult to maintain;
3. Most EDRMS implementations fail (albeit over time) because very few organizations budget for or are prepared to pay the huge ongoing cost to retrain workers as software changes or train new workers as staff turns over; and
4. Records management is not a core business activity in most organizations and it is seen as a cost centre, not a profit centre so it gets little senior management attention and little funding.

Basically, in most large organizations senior management is aware of the paper problem but it is not high on their agenda and it is easier to just maintain the status quo; keep packing files into boxes and sending them off to Iron Mountain. It is a lot like the Greek Debt problem, that is, keep ignoring the problem and leave it to someone in the future to solve.

To summarize, management says, “It works and isn’t my major priority so I will leave it for someone else to solve.” Or, applying that time-honoured old maxim, “If it ain’t broke, don’t fix it.”

The reality is that we have to find ways to manage paper. The additional reality is that very few of the ECM/EDRMS software packages on the market today do the job well or even at all. SharePoint 2010 for example is hopeless at managing physical records so don’t even think about paying a consultant hundreds of thousands of dollars to configure it for you to solve the problem.

Luckily for us, and largely because we started developing applications for physical records management back in 1984, we have incorporated a rich subset of physical records management functionality (our legacy if you may) into our latest product suite, RecFind 6.  This means we are one of the few vendors with a product that can easily handle any physical records management requirement.

Also, and this still surprises me, we are receiving more and more inquiries for a product that just does physical records management. To be honest, if anyone had told me twenty-five years ago that I would still be receiving requests for a physical records management product in 2012 I would have laughed at them. Yet, here we are today in a world swimming in paper with organizations all around the world desperately needing to solve a paper records management problem.

Now I am really glad that I insisted that my design teams maintain upwards compatibility through all of our product releases and that they should continue to refine and improve our physical records management capabilities.

I hope I am happily retired in another twenty-five years but just in case I am not, I will set myself a reminder to re-read this post and once again review how far we have progressed in replacing paper records with digital records. With luck, I will be living in a luxury apartment converted from an old Iron Mountain warehouse and there won’t be a sheet or paper or archive box in sight.

What will they do with all those warehouses?