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.