I remember the first “big” database system that I programmed. It used the paradox database engine and was used by insurance agencies as a convenient way to look at, print out and generally track their policy holders. It was reasonably lightweight program, the output was displayed in text windows, think MS DOS, and was pretty fast.
Not only fast but it was possible to setup commission structures and load the agencies renewals from disks, make a lot of calculations and print out who should be paid, and how much – pretty nifty actually.
Well, it did have some drawbacks, such as being tied to a specific printer model as well as being more prone to failure when it was run on any of the newer flavors of windows. I knew this would be a fairly risky platform to depend on in the future so in my free time I wrote a new one, a better one. It used Microsoft Sql server as the database, it had a very nice graphical user interface it was beautiful.
There was just one little problem. It would be necessary to import the data from the old system into the new system and to bring the user up to speed with the software. I can appreciate you need to get your job done and learning a new system may not be the highest priority, but Lydia seemed to bring up new reasons why it couldn’t be used rather than how it would help her. In that sense, I guess time was on my side as Lydia did eventually leave and Marta was really quite eager to get the new system implemented.
Ok, ok, the new software was complex but it did seamlessly support all of the insurance company’s policy holders. The old system was a bit hard coded as only one company could even provide the data electronically but that was the mid eighties. In the new millennium, it turns out that only one of all the companies could electronically provide the policy holder information. Just like 20 years ago only one company could provide the renewal information electronically which didn’t seem to be an improvement.
That isn’t to say with the computer revolution that the other companies couldn’t provide their information electronically but they all chose a different path. The information was available but it was only available online. If you needed to look up information about one of your policy holders you went to that companies online portal to check. To be honest, I cannot say that I blame them a bit. This gives the insurance companies full control over their customer data, which given the recent data security laws is quite reasonable.
The thing that I find unique was that in the intervening 20 years it was still not possible to receive the client renewal information in a machine processable file. Yup, this information was available to be downloaded and printed out but nothing straight forward where the data can be simply processed.
The agency that used my software was going through reams of paper each month and making entries in excel spreadsheet. This file was loaded separately by my program as a list of exceptions.
My system was really neat. It kept an account balance for each agent and did automatically load the data files that could be fed to it. It was a reasonably complex piece of software for a small company and 95% of the companies couldn’t provide any input files to support this level of complexity. The software solution was too complex so the only reasonable solution was to re-write the software yet again but this time with the goal of simplicity.
The new solution was that all the renewal information was entered into an excel spreadsheet and exported as a text file. The text file was processed by a simple program which read the text file and output a PDF file for possible printing. I can understand how this very simple almost fool proof solution would appeal to a small company. It is a disappointing counter point for the 21st century. The final solution was to manually enter and calculate all the information and then print out reams of paper.