Working with two contact management system

[leosayer]

My company are looking to link two CRM systems as users are raising lots of issues about re-keying of data.

Both system have their own Oracle db, but one is in-house developed and the other is off-the-shelf.

Does anyone know of any reading material that I can get to help me decide where to start on this.

[aldi]

Are you keeping two, or going to end up with just one?

[pdV6]

aldi said:

Are you keeping two, or going to end up with just one?

And if just one, which will it be? If the in-house system, my guess is that the deveopers would be able to import data from the commercial version fairly easily, seeing as they know the db structure inside out...

[leosayer]

We have yet to make that decision. We're only at the stage of 'Something needs to be done'.

I am keen to move bring the functionality in-house for a number of reasons:
1. The commercial version isn't popular and we have spent much time configuring away from standard to meet user's requirements.
2. We only use about 5% of the functionality of the commerical product and it is very costly.
3. We have the budget, technology and expertise to do this in-house.

There are some problems, in that the commercial product is mainly used for prospecting whereas the in-house system is used for reporting (ie. after the prospect becomes a client). There is overlap on the names and addresses side, but that's about it.

I guess I'll need to make a business case for the in-house solution.

Thanks for the replies so far.

[3200ac]

if you've got 2 Oracle databases, it's possible to avoid duplicatiopn by making one or other the holder of the 'truth', and linking the 2 systems, with several options available to you. To name a few options, Advanced Queueing, Database Links, Replication, Materialised Views... also worth familiarising yourself with the concept of 2 Phase Commit, as making the stuff work as expected needs an awareness of this.

If you're keeping both, you can use the stuff above to create/merge functionality that spans across both databases.
If you're chucking one of them, you can use some/all of the above techniques to migrate your data.

Hopefully you're using a formal methodology to hang all this stuff off.
cheers,
M

>> Edited by 3200ac on Tuesday 18th October 14:02

[roadsweeper]

Have you considered an alternative non-Oracle-based CRM solution? There are good cost-effective packages out there now.

[Plotloss]

You should, in 90% of cases be able to completely avoid the re-keying of information and in some cases even avoid transformation (as mentioned above).

What sort of account volumes are we talking here?

100's, 1000's, 1,000,000's??

[leosayer]

roadsweeper said:

Have you considered an alternative non-Oracle-based CRM solution? There are good cost-effective packages out there now.

Cost is unlikely to become an issue. The solution MUST be Oracle based in order to integrate with existing database and systems.

[leosayer]

The commerical product holds 40,000 people and organisations along with associated accounts, addresses, roles, linked contacts, contact reports, mailing instructions queries and runs, pdf documents.

Most of the account data is stored on the in-house system, along with 150,000 people and organisations, most of which are duplicated in the commerical product.

My preferred soltuon is to ditch the commercial product and thereby spare us the pain of transformation. However, I'd like to know how to keep both systems and yet avoid transformation.

[Plotloss]

Create a file which contains the key of the customer on the inhouse and they key of the customer in the commercial along with a record identifier.

So Known By Customer UID, Refers to Commercial Customer, Refers to In House Customer

Moving forward you only write to in house and dont write a record in this new control file.

Then you should be able to use all the commercial data structures, via this control table to access all the data you need.

Quite a lot of code changes but should be fairly transparent from a data perspective.