'If it ain't broke don't fix it' is an old saying that rings in my ears. It is the idea which recommends if the system you are working on is not broken then why change it. I can understand you want to make it faster, easier to use and more efficient. The issue is while converting it to a new form do we need to change anything else? A great example for this is the library system. We stored books for many years using the same system we use today. The thing is that many of our books are not paper on a shelf, they are digital files in the ether of our networks and computers. Why did it NOT change? It still works! Yes we added indexes and other things to the system to make it better but the heart and soul of the library system is still the same numbers we have used for many years. Even the IBSN number has not changed. If you are going to change something in your system make certain to look at the benefit and the impact it will have on all of your labor and systems. Big mistakes I have seen systems go thru: 1: You can index every page! Oh boy would that not be amazing that every page had an index that told us who'sit was and what date it was received and who indexed it etc...... Every one of those systems failed....I have never seen a system that can take random paper, information and index everything symmetrically without a great deal of labor to accomplish it. If it were that easy Google would have done it already. Imagine if every page you take into your office someone had to type 1000 characters to describe it. 2: I do not need to index anything the computer can read it. Once again this is a dream that has not reached reality. OCR/BARCODE/QR has all gotten better but perfect it is not and reading handwriting with a computer is impossible. . Let's pretend a computer could read 80% of the letters on a type written page. It is probably more than likely 60 %to 70% so we can pretend. If we assumed 80% accuracy for every 100 letters it reads 20 of them are wrong. If the average word has 4.5 letters in them than 100 letters becomes 22 words and 20 of them could be wrong. Seems there is a flaw in our logic. 3: Store everything in color at high resolution. I have seen this over and over again for 20 years, clients do not consider the impact they have on a network making files bigger and more complex. Large files take up lots of space and lots of bandwidth to deliver to the client. If you were a governmental agency trying to answer a FOIA request and the files needed were 100's of Gigabyte in size. Gathering them would be difficult and time consuming and delivering them even more so. Size matters because time matters. Bigger files slower delivery to screen, slower to store and retrieve slower everything and slower is more expensive than faster. 4: It's on backup. I can not tell you how many people never test their backup system until the system fails. When a system fails you can't have a failed backup because it could all be gone. Even worse. What if you had a backup but it would take 3 weeks to restore, now what? Redundant active systems to keep systems alive. Offsite cloud etc can work but restoring could take so long you are still out of business. When you design a system think of the end of it's life as well as what is designed to do. End of life is in some ways more important than the process itself. Since 1972 we have seen and made many mistakes, ones we do not want our clients to repeat. When you do start to look for a newer design, ask someone else about their experiences you may learn how NOT to do it. |