What's Wrong with Duplicating Data?

The single biggest problem with nearly every computer system today (not just CRM systems, but EVERY SYSTEM) is that they merrily duplicate things like shared address and phone number details between different people’s records. This means that you, rather than the system, have to remember whether there are other records that have to be changed when one of them changes.

When most existing systems were developed the technology simply did not exist to allow their designers to do other than duplicate data between records – if they wanted to retrieve it in a timely manner. Unfortunately this was always their ‘Achilles Heel’ as the User had to know which data had been duplicated and change it themselves. This is impossible if multiple people are updating the same database. It is also impractical for a large database, even with a single user – unless you’ve got a mind like an elephant. (And if you've got a mind like an elephant why do you need a datbase?) Recent advances have meant this is no-longer a constraint. GEM now leapfrogs this earlier technology.

Take for example the way GEM finds out someone’s Work Phone Number. In a conventional system this information would be in the Person’s record – so there is nothing else to do. Unfortunately, if you know someone else who works for the same employer, the same number would be in their record too. That's why if you need to change it you have to remember who else has the same phone number - so you can change it. GEM however stores the employer’s phone number only once. It also ‘knows’ that both employees work for the same employer. So changing one person’s work phone number will automatically change the work phone number of all other employees and you don't have to remember who they are. (This does not apply to direct-dial or mobile numbers.)

If you give someone an Address that GEM recognises from its Phone Number, then GEM will immediately know who they live with. Any subsequent changes made to their Address or home phone number will apply to everyone at the same address. (If someone leaves home, it’s easy, you do what has happened in the real-world. You remove them from their old Address and give them a new Address.)

This does mean a ‘Generalised Entity Model’ does do more work than most existing systems. However, who would you rather did all the work – you or your computer system? In a conventional system you have to remember who else is affected. GEM effectively remembers it for you – so you don’t need to.

This is particularly important in a multi-user system, as you personally may not have put the original data in, in the first place. So how are you expected to remember it? The answer is of course you can’t. What happens is you end up with differences in data between people’s records that should actually be the same. Then of course you loose confidence in your system because you don't know who's data is correct.

Systems that use 'Groups'

Some systems, realising the short-comings of this approach, have recently retro-fitted them to enable you to create ‘groups’ of records, so that if one of them changes, the system will remind you to change the others too. This sounds OK, but it still means that you have to remember, when adding new records to the system that there are other records with which they may have to be grouped. The onus is still on you. The grouping is not done for you! The timing of when you have to remember has merely changed - from when a change is made to the data, to when a new record is added. The problem is, if someone else input the data, how are you supposed to know its even there?

GEM on the other hand recognises shared Addresses for you. So you don’t need to create artificial ‘groups’ of records - or even remember you have done so.