Results 1 to 8 of 8
  1. #1
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59

    Answered:

    an alternative approach
    why not evaluate the 3 existing CRM systems used in this organisation. find out which one best meets the requirements of all 3. accept that there will be pressure form all 3 areas that 'their' CRM model is the best., then ignore that

    implement a company wide single system

    unless your organisation does something (procedurally or functionally) really weird resist the temptation to write your own system.

    if the head office isn't strong enough to bow to the lowest common denominator then identify a new CRM product that has none of the vested interest baggage from the existing systems.
    I'd rather be riding on the Tiger 800 or the Norton

  2. Best Answer
    Posted by jrbbldr

    "Let me begin by saying that Merging the 3 separate systems into is an admirable goal.
    And that should have happened at the start.
    Your management team should never have allowed the purchase of System 2 and 3.

    But now how to proceed?

    The 'Best of Breed" recommendation above is not bad.
    But, since all 3 appear to be off-the-shelf commercial systems, it does not support your desire to: Program the CRM system myself.
    They are most likely 'closed' systems without the ability to 'get under the hood' (a.k.a.into the source code) and program yourself.

    However, you also got another good recommendation:
    unless your organization does something (procedurally or functionally) really weird resist the temptation to write your own system.

    Having myself written multiple proprietary CRM/MRP/ERP systems for clients, in retrospect, the clients should have listened to that same advice and saved many thousands of development time dollars. Unfortunately their own egos got in the way and they didn't want to change how they were doing things - THEIR WAY.

    Another issue you are likely to face is that you don't mention knowing anything about the data 'backend' of the 3 separate CRM systems you have - the database(s), the data table(s), etc..
    Unless you are intimately familiar with that, you cannot hope to merge the data into something else.

    In order to merge data into anything else, you need to know where/how to find the individual data parts and then move them from DataSourceA - TableK - FieldAAA to DataSourceB - TableL - FieldXYZ and possibly the datatypes (Character, Numeric, DateTime, etc.) would need to be resolved as well.

    IF all 3 CRM systems used one single common Database type (example: MS SQL Server, MySQL, etc.) then the merge job would be easier, but not inconsequential. And it would not eliminate your having to understand how and where the individual systems were storing/retrieving their data elements.

    I've done these types of migrations for clients before and they are often a real headache.

    Recommendation - I'll echo the above - Pick 1 system for the company.
    I don't care if it is one of the existing systems or a totally new one, but the whole company needs to operate on one single system.

    Once that system is selected investigate with the vendor to see if they will assist with the conversion of data.
    Perhaps your working closely in conjunction with them will get you sufficiently 'educated' where you can do some of that work yourself.

    If there is no vendor that will assist you then you might look for a contractor who has experience with one or more of the systems.

    Failing to find that support then you would need to 'educate' yourself pretty thoroughly on one system at a time in regards to the data elements.
    Find out what data changes and where it goes for each and every operator function.
    With that knowledge behind you, you would need to do the same for the 'destination' system.
    After all of that you would know enough to begin merging the data - AFTER EXTENSIVE COMPLETE BACKUPS HAVE BEEN MADE.

    I don't envy your position since you are likely to be facing a Political Firestorm from the multiple departments and/or from Management.
    Be assured that you will likely have a number of people MAD AT YOU for making them CHANGE
    Regardless of that the company will Flounder if it continues on its current path and does not make the change.

    Good Luck"


  3. #2
    Join Date
    Nov 2002
    Posts
    128
    Provided Answers: 1
    Let me begin by saying that Merging the 3 separate systems into is an admirable goal.
    And that should have happened at the start.
    Your management team should never have allowed the purchase of System 2 and 3.

    But now how to proceed?

    The 'Best of Breed" recommendation above is not bad.
    But, since all 3 appear to be off-the-shelf commercial systems, it does not support your desire to: Program the CRM system myself.
    They are most likely 'closed' systems without the ability to 'get under the hood' (a.k.a.into the source code) and program yourself.

    However, you also got another good recommendation:
    unless your organization does something (procedurally or functionally) really weird resist the temptation to write your own system.

    Having myself written multiple proprietary CRM/MRP/ERP systems for clients, in retrospect, the clients should have listened to that same advice and saved many thousands of development time dollars. Unfortunately their own egos got in the way and they didn't want to change how they were doing things - THEIR WAY.

    Another issue you are likely to face is that you don't mention knowing anything about the data 'backend' of the 3 separate CRM systems you have - the database(s), the data table(s), etc..
    Unless you are intimately familiar with that, you cannot hope to merge the data into something else.

    In order to merge data into anything else, you need to know where/how to find the individual data parts and then move them from DataSourceA - TableK - FieldAAA to DataSourceB - TableL - FieldXYZ and possibly the datatypes (Character, Numeric, DateTime, etc.) would need to be resolved as well.

    IF all 3 CRM systems used one single common Database type (example: MS SQL Server, MySQL, etc.) then the merge job would be easier, but not inconsequential. And it would not eliminate your having to understand how and where the individual systems were storing/retrieving their data elements.

    I've done these types of migrations for clients before and they are often a real headache.

    Recommendation - I'll echo the above - Pick 1 system for the company.
    I don't care if it is one of the existing systems or a totally new one, but the whole company needs to operate on one single system.

    Once that system is selected investigate with the vendor to see if they will assist with the conversion of data.
    Perhaps your working closely in conjunction with them will get you sufficiently 'educated' where you can do some of that work yourself.

    If there is no vendor that will assist you then you might look for a contractor who has experience with one or more of the systems.

    Failing to find that support then you would need to 'educate' yourself pretty thoroughly on one system at a time in regards to the data elements.
    Find out what data changes and where it goes for each and every operator function.
    With that knowledge behind you, you would need to do the same for the 'destination' system.
    After all of that you would know enough to begin merging the data - AFTER EXTENSIVE COMPLETE BACKUPS HAVE BEEN MADE.

    I don't envy your position since you are likely to be facing a Political Firestorm from the multiple departments and/or from Management.
    Be assured that you will likely have a number of people MAD AT YOU for making them CHANGE
    Regardless of that the company will Flounder if it continues on its current path and does not make the change.

    Good Luck

  4. #3
    Join Date
    Nov 2002
    Posts
    128
    Provided Answers: 1
    I did think of one other possible approach that will depend on what your current CRM systems support.

    If they happen to support Import/Export then you might be able to Export the important data from one system, analyze it (possibly needing to re-format it), and then Import it into the other system.

    The chances of that being a possibility are slim, but worth looking into.

    Good Luck

  5. #4
    Join Date
    Oct 2015
    Posts
    3

    thx

    That is possible for all the CRM systems. They all run on a local server and with the latest backup you can load up the database in ms sql server studio. So retrieving data should not be a problem:)

  6. #5
    Join Date
    Nov 2002
    Posts
    128
    Provided Answers: 1
    They all run on a local server

    The APPLICATIONS may all run on the SAME server, but are the individually application-specific DATABASES all on running with the same Database Server?

    When I say an Application can Export/Import data, that is not the same as using the 'raw' data tables from MS SQL Server.

    If all 3 CRM's are all using a MS SQL Server then getting to the 'raw' data is not too difficult.

    However that does not preclude the possibility that each CRM has its own set of Data Tables within their Database and each table may be possibly using different Field Names.

    For example:
    * CRM1 could be using a table named Client and have a Field named ClientID
    * CRM2 could be using a table named Customer and have a Field named CustomerID
    * CRM3 could be using a table named PrimaryCust and have a Field named ID
    (Just one very SMALL example of how things could vary from system to system)

    Somehow those various fields would need to be recognized as representing the same info and used accordingly.

    Additionally when a user does something to one of the clients (for example: enters an Order) then various other fields in various other tables are modified.
    The challenge is that different systems do things differently (impacting different tables, different fields, etc.) towards completing any given task.

    If you want to get ALL of the information from the 3 systems synchronized into a single system, that will be a BIG CHALLENGE.
    But if you merely want the simplistic Client demographics info, that is easier.

    When I mentioned an Import/Export, I was referring to an Application Import/Export, not a Database extract of 'raw' data/
    An Application Import/Export would output the data into a formatted form and, hopefully, do so in a structured manner such that functional relevancies would be apparent.

    Good Luck

  7. #6
    Join Date
    Oct 2015
    Posts
    3

    tyvm

    Thanks for your detailed reply.

    Maybe it would be easier to explain the whole situation in detail;

    The three ERP/CRM systems we got are:
    Vtiger (Mostly CRM)
    Snelstart (Mostly ERP)
    ASR (Custom made, both CRM and ERP based)

    Vtiger and Snelstart both run on their own physical server with their own database server. ASR is a special one, this application is custom made by our company and uses the database server from Vtiger. Due to the fact Vtiger is open source, it is relatively easy to add tables to Vtigers database and use these for the ASR application. A massive benefit of this is ASR being able to use other tables from the Vtiger database.

    All summed up, there are two database servers, one is being used by two applications (Vtiger and ASR). The other one is only for Snelstart.

    I am aware that the data conversion is gonna be a huge project. I have done data conversion in the past with CloverETL, but this will be a whole new level, especially when the company wants to keep all their data.

    The Import/Export feature is not available for any of our CRM/ERP systems. Even when they would offer this feature, I doubt it would be any useful, because when we are going to export our current data to the future database system, we need to reformat a lot more data. For example;

    Snelstart stores customers by: ID, First_name, Last_name
    Vtiger stores customers by: ID, Full_name

    If this is the case, I would have to combine the First_name and Last_name from Snelstart or split the Full_name from Vtiger. Besides this problem, I also have to take the ID's into account. Snelstart may have customer id's ranging from 1 to 1000 and Vtiger could have customer id's ranging from 1 till 5000. Combining these would give several problems, due to duplicated primary keys. To solve this problem, I would need to give these entries a new ID and alter all corresponding foreing keys in the other tables, just to give the customers an unique ID and keep the joining tables.

    Otherwise said, I am confident with the data conversion, even though it will be a massive project. The only thing I'm worried about is choosing the 'right' system. Just a simple google search gives you hundreds of companies which offer their CRM/ERP system and why you should choose them. Our requirements are really specific, due to the diversity of data and wanting to keep all useful data from the current systems. This makes it pretty difficult to find a CRM/ERP system which satisfies all of these requirements. This also makes it very tempting to choose for a custom made CRM/ERP system, but I am not sure if this is the best solution. Even if we choose for a custom made system, are there any things to keep in mind and to take into account?

    Again, thanks for the help. Really appriciate it

    -Robin

  8. #7
    Join Date
    Nov 2002
    Posts
    128
    Provided Answers: 1
    I am not familiar with any of those 3 systems, but there are 100's of them out there on the market.

    It sounds as though you have a good grasp of the various systems and what will be involved with bringing the data together.

    makes it very tempting to choose for a custom made CRM/ERP system

    I certainly understand how individual departments and/or managers think this is the ONLY way to go, but, as we have already advised above, more often than not, it not only leads to MANY $$$'s being spent towards relatively small (if any) gains and towards your being held 'hostage' to the developers of your custom system (No one else will know anything about it).

    I generally use a Business Process Management approach towards assisting clients with selecting new systems. ( https://www.google.com/search?q=proc...ess+management )
    Map out each and every Process that your departments use - what is done, why it is done, what it results in.

    By doing so, the inefficient, duplicate, unnecessarily 'custom', off-the-wall and missing/lacking functions generally show up glaringly.

    NOTE - one thing often left out in analyzing current functional methods is handling the Business Strategy. How will the Business Strategy affect operations while moving into the future. Getting things done today (custom or not), might not serve the company well as things move into the directions that the Strategy (and company growth) leads it.

    Another thing to take into consideration is: in-house vs cloud approach.
    ( NOTE - even 'custom' systems can be hosted at one of the many Cloud vendors if desired. )

    * In-house requires hardware costs (perhaps already purchased), backup strategies and upgrades
    On-going maintenance costs, IT staff and/or contractor costs to keep things running ( 24/7?? )
    Physical floor space and overhead (environment controls, etc.) requirements
    Do you have HIPPA and/or PII issues? If so that requires additional hardware, etc. to support it
    But some companies feel more secure having things in-house so the 'extras' are justifiable.

    * The Cloud approach has no hardware purchase costs involved
    No staffing requirements
    Backups are handled for you.
    No physical space nor environmental conditioning requirements
    If you have HIPPA and/or PII issues, this is taken care of.
    There are on-going monthly 'service' costs which are sometimes reasonable and sometimes not

    I have worked with companies that thought both ways.
    Some consider in-house the only way and others wanted to get everything currently in-house running outside.

    Then after 'boiling it all down' to the most effective needs, that can be used as the guidelines for an RFP to various CRM/ERP system vendors and/or used by yourself to evaluate whatever offerings come your way.

    Good Luck

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •