There are two basic paradigms for CRM systems: Contact centric or Account Centric. In Contact Centric systems, the primary organization is around independent contacts. In Account Centric systems, there are two levels to the basic organization: a company or account layer to which multiple contacts can be related.

Contact Centric

In a contact centric system, the database is organized around individual contacts. So, if you have dealings with 3 different people all from the same company, you would have 3 different contact records and in each record would be the company name. There may be ways to relate different contacts together, but these will be in the “workaround” class.

A Contact centric organization makes sense if you are dealing with individuals and you do not need to do such things as look at an organization’s combined history. It is very difficult/clumsy to track company related information separately from contact information. For example, if you want to track information about a company (e.g. sic code, # employees, annual budget, etc.) separately from contact related information (e.g. favourite hobby, home phone number, spouse’s name, etc.). there isn’t an easy way to do that:

difficult.

and somehow relate the contacts to it?

Account Centric

Account centric CRM systems have a layer above contact, the organization or account, that can tie multiple contacts together. This has the advantage of being able to track company-related information entirely separately from contact-related information. This approach is usually easier to:

My Recommendation

If you’re working in an industry where you only need one contact record per account, you may want the simplicity of contact centric. However, if you are going to want to track multiple contacts per account then contact vs. account centric becomes a very important consideration and you should give heavy weighting to systems that are truly account centric. This is just one of many considerations that must go into determining whether or not a particular CRM software fits your needs. For a complete step-by-step process for evaluating CRM software, see the Insider’s CRM Success System.

Scott Gingrich, founder of The CRM Coach (http://www.thecrmcoach.com) is the creator of “The Insider’s CRM Success System” (http://www.crminsidersguide.com), the world’s most complete and only CRM Success System guaranteed to save thousands, developed specially for small business.

If you have Microsoft Great Plains and support it for your company and have light or heavy Great Plains customization, written in Dexterity – you need to know your options in upgrading Great Plains or migrating it from ctree/Pervasive to MS SQL/MSDE.

Great Plains Dexterity is proprietary programming language/environment, which was created in early 1990-th to provide platform / database / graphical interface independence for Mac and Windows based Great Plains Dynamics.  Today it is legacy and Microsoft Business Solutions is phasing Dexterity out.

However Great Plains 7.5 and even 8.0 is Dexterity based application, so you have to deal with it and it’s customization.

Good news.  Prior to version 7.0 Great Plains had plans on expanding GP functionality and so was changing tables structure – forcing Dexterity customization to be analyzed and partially rewritten with each upgrade.  Not any more – GP structure stays the same – Microsoft is doing new modules acquisition and unifying it’s graphical interface to move all it’s ERP packages: Great Plains, Solomon, Navision and Axapta to web-based Microsoft Business Portal.

Still pain.  Dexterity has possibility to customize existing Great Plains screens, so called Alternative Great Plains forms.  This was upgrade problem in the past and it stays now – there is no way to do it in house (until you are willing to pay for full-time internal developer – who is usually in the learning curve).  You got to bring in consultant.

Recommended approach.  You should have the strategy to migrate Dexterity customization to SQL, Crystal Reports, custom web publishing – Visual Studio.net and slowly abandon Dexterity customization

1. SQL Stored procedures - performance improvement.  Consider replacing dexterity data manipulation with SQL stored procedures.  Dexterity is cursor-driven language and it is not efficient when processing huge datasets.
2. Crystal Reports.  Take advantage of open and leading technology.  Crystal Reports will eliminate the need in the future for painstaking Dexterity reports upgrade.  Base you Crystal report on the SQL view or stored proc
3. Do direct web publishing off your GP database.  Use Visual Studio – it is easy to find specialists and have them in staff.  We are in the World when web publishing is very easy.

Good luck and if you have issues or concerns – we are here to help! if you want us to do the job - give us a call 1-866-528-0577! help@albaspectrum.com

Andrew Karasev is Chief Technology Officer in Alba Spectrum Technologies – USA nationwide Great Plains, Microsoft CRM customization company, based in Chicago, Los Angeles, San Francisco, San Diego, Boston, New York, Houston, Dallas, Miami, Atlanta, Minneapolis, Seattle and having locations in multiple states and internationally (www.albaspectrum.com), he is Dexterity, SQL, C#.Net, Crystal Reports and Microsoft CRM SDK developer.