This is a topic that I have been quiet on for a while, but over the next few weeks I will be returning to it many times with a series of tips and tricks specific to CRM and GP.

Despite being around for a number of years there still appears to be a great deal of trepidation when a partner sets out on a CRM to GP integration. I want to set out to prove that there is no need for trepidation and a CRM to GP integration can be and should be a standard activity for any GP/CRM reseller. There are a number of reasons why I think this trepidation has developed:
1. Partners being burnt by launching into the complexities of Scribe, unprepared.
2. The original GP/CRM connections in SmartConnect were not yet fully functional
3. More recently the inflexibility and simplicity of the standard connector from Microsoft
4. Underestimating the complexity of the line ‘we just want a simple and standard integration’
5. Choosing the wrong team to implement the integration
6. Fear of the unknown
7. Lack of useful specification

To resolve point 1, 2 and 3 – SmartConnect has come to the rescue. After a recent SmartConnect (for CRM) training session the attendee was quoted to say “Holy crap, I can not believe how far SmartConnect has come in the last few versions. This means that any clown that can double click can integrate CRM and GP. I will dig deeper into the reasons why SmartConnect has blown away any competition over the next few weeks.

Today I want to focus on the team that should implement an integration. Traditionally the CRM team has either put up their hand, or been nominated to lead the integration process. GP consultants got to hide their head, and hope it all worked out for the good. This is a dreadful model. The reason for this is that more often than not the CRM team were already familiar with Scribe and had used it in conjunction with Sales Logix or the initial releases of Microsoft CRM. The use of Scribe was for initial data load to CRM, conversions from ACT etc and duplicate checking on these data loads. This meant a file of data (usually a spreadsheet) that needed to end up in CRM. There is almost no similarity between that type of project and a two way ERP to CRM integration project.

The fundamental difference between ERP software and CRM software is ‘unique records’. Now this sounds fundamental to any database but in CRM it is perfectly legitimate to have the same customer or contact in your database multiple times. (for example John Smith can be a vendor, a customer, a prospect, an ex employee, have worked for multiple customers previously etc etc). Where in an ERP each record must have a unique identifier.

Secondly, most CRM implementers have no idea what an ERP does and often times why you would even have one. (a wild generalization I accept). CRM’s are a place to store large volumes of data – but are not really transactional. CRM’s have many less transaction rules for things like Tax, Double Entry accounting, Serial Number Processing, Inventory tracking etc. An ERP is a whole bunch of Business Rules through which all data is funneled/processed before and after hitting the database. Once that data hits it moves to history as processed, unchangeable data. Compared to a CRM system and ERP is an extremely complex beast.

The above said, do not underestimate the free form flexibility and associated complexity of CRM. ERP’s are to an extent governed by the rules of accounting, rules of tax and governments and the standard process of doing business. CRM’s are governed by the creativity of a sales manager and sales team. Now that can get complex.

Terminology and concepts are different with CRM and GP. In CRM you have to understand GUID’s and in GP you have to understand the impact of the payment terms field on all Receivables transactions. What about a class ID? How do you integrate form CRM to GP without passing through a class ID for customers? There is no Class ID in CRM so too bad? A GP consultant understand the importance of this field in GP but a CRM consultant sees it as just another classification.

In CRM the workflow is everything – what happens next and who should be reminded to act after this step. When you create an order what happens next, when does it become committed and when can users stop editing the record. These are questions that are usually givens in an ERP but are all open to change in a CRM.

So in short you need both a CRM guru and a GP Guru on your implementation team – particularly for the scope and design exercise. YES – the scope and design exercise for the integration. I will come back to this topic as it is the most important step in any integration, and is essential no matter how simple the initial requirements.

With SmartConnect you are able to configure an entire integration form within GP. You never even have to log into CRM (other than testing). So in theory all you need is a good GP consultant? (it has been done but not recommended). You must have both a CRM Guru and a GP Guru involved in each and every implementation project. I tend to recommend that the GP Guru take the lead as the GP side is usually the more complex as far as transaction complexity. The CRM guru is essential for the work flow of what happens in CRM and how things are displayed to the sales team. The mapping and pushing of data is the easy bit and tends to be best handled and mapped by the GP consultant, with the CRM team working on the display and who gets to do what when within CRM.

Lastly, involve the customer in every step. They need to own it, feel part of the process and truly understand it.

No Project should commence without sign off on the scope by all parties.