Q:

CRM: In-House vs. OTS

Many, many years ago, when I was young and naive and wrote everything from scratch unless it came with the language, I was working for a company with two sales people in two locations who were trying to share leads and contacts. I had just discovered a shiny new hammer, PHP, so of course I built them what I would today would describe as a primitive MySQL backed CRM system. They loved it--at this point most in history all their competitors were using local Access databases.
I have since learned how much easier life is when you don't try to reinvent the wheel. I am again faced with a growing company that needs an online CRM system. I am roughly aware of what CRM systems do of course, but I am not very familiar with what exactly products like MS Dynamics or SAP offer.
I am having a hard time sorting through marketing fluff trying to figure out just what exactly these companies spend tens of millions of dollars and euros developing. Most of them appear to be fairly straightforward enterprise applications with a few bells and whistles that I'm not really interested in, such as Outlook and Sharepoint integration or the ability to create workflows through a click-and-drag interface.
So my question is, are you crazy to attempt to develop a custom CRM system from scratch?

A:

I was working for an employer once making CRM software when someone 'important' asked

Why are you making CRM software and not using one of the plethora of CRM packages that already exists?

To which I replied:

For the very same reason that there are a plethora of CRM packages.

I went on to explain, that for certain (many?) types of businesses there is a specific way in which they want to deal with their customers because it's more effective for them. If managing a customer is a core competency* of your business, then why would you use someone else's prescribed method/software (this precluded the highly customizable solutions that are available now)?
These days, what it boils down to is does the cost of one of the (not so cheap from what I can recall) CRM solutions available + the time to make any customizations and train for using it is less than the time to produce and maintain your own then get the existing one.
The best bet, IME, is to do a strong requirements analysis of how your company wants to deal with its customers, even to the point where you might even mock some UI/processes that would be implemented and then compare that to the capabilities and costs of existing packages and then your answer should be plain to you.
1* Everyone says that dealing with customers is a core competency but it's often not true. IME, the litmus test is if a 'consultant' visits your home at least twice.

A:

Some reasons to build your own:

OTS solutions do not offer what you need.
You have the resoruces (time, budget, talent).

If an OTS solution can provide what you need then it might be better to go with those. If you aren't familiar with what existing solutions are capable of, ask the vendors for a demo. They will probably be very happy to set you up with something, and actually taking the software for a test drive is a lot better than reading glossy brochures. Some solutions may have a plugin framework to help you get what you need if the base system doesn't do exactly what you want. Then you could either code your own plugins or purchase (assuming it's cheaper/faster then doing it yourself) existing ones.

A:

I can't speak about SAP's CRM implementation, but Microsoft Dynamics CRM 2011 (previous versions, not so much) is an impressive bit of software (as far as "enterprise" software goes).  It's really an application platform/framework that happens to have a built-in CRM solution.  It can be customized quite extensively right from within the browser-based interface, without requiring a line of code - you can build an app that has nothing to do with CRM, and that isn't just a line used by Microsoft's sales people.  It's also available as a cloud service (just like SalesForce) where it is almost as customizable as it is in a local deployment.
I have a love/hate relationship with the product though.  It's a big framework, not nearly as much hair-pulling-frustration as SharePoint, but still intimidating and sometimes obtuse.  It can sometimes take longer to figure out how to do something with the framework than it would be to just build from scratch, and no matter what, some things just can't be done nicely from within the framework and that's when things get irritating.  Also, performance is something to be desired in many cases (it's not outright terrible, but it is by no means optimal).
That said, like any buy vs build scenario, the most important thing is to clearly know your business needs.  If you know them, then you can map them to the capabilities of the various products - any gaps then need to be considered.  If you have more gaps that matches, then you should probably build, otherwise buying it generally the better option (my opinion, of course).

