Last updated by yautja_cetanu on Fri, 2011-09-30 09:51
I think this question seems to come up a few times. I've created this as a wiki page because I do not feel I am best placed to answer this question due to my limited interaction with CiviCRM (Which I actually really like). But I feel like it will probably come up so others, feel free to get involved in this page and clear up my english and reasoning. I definitely welcome re-wording of some of my points.
Related Questions
Firstly I think this question is strongly related to other "why nots" throughout the Drupal ecosystem. The only difference is there is not yet a "Drupal way" of doing things:
- Why not use phpbb instead of forums and advanced forums?
- Why not use magento instead of Drupal Commerce/ Ubercart?
- Why not use Wordpress instead of advanced blogs/ blogs?
At the moment if anyone wants a good CRM system that works well with Drupal, CiviCRM seems to best way to go. However, we're making the equivalent of advanced forums/ blogs/ drupal commerce for CRM so that it is no longer the only option. Here are some reasons why:
1) A solution built in Drupal allows you to take advantage of the Drupal learning curve
It is possible to modify CiviCRM. However you'd have to learn how to use it. CiviCRM is a complicated piece of code because it is really good at doing alot. But conversely it means if you're used to making Commerce websites you probably won't be able to just install CiviCRM and use it (particularly modify it) without some considerable learning. A Drupal Shop that specialises in CRM can afford to do this but many will not. Even if CiviCRM APIs were the best on the planet, it would still be something new to learn.
Similarly if a user becomes used to the Drupal way of doing things and like the Drupal UX they get that automatically with a Drupal CRM. Within a month we have built a very basic CRM that does very little more add contacts. Nothing compared to CiviCRM. However I sat my client in front of it and though they were not technically skilled at all they were able to add and manage all the fields with very little hand-holding. Whilst CiviCRM can do more... the drupal one was so easy to use they can customise it themselves. This manage field screen is the same one they will use when adding products, configuring content types, etc.
2) If content is created by a Drupal module it becomes "Drupal Content" that is IN drupal. This means it can be treated like Drupal content
I've heard Michelle talk about this when talking about why we should use advanced forum over phpbb even if technically as pure forum software phpbb is better. I find this concept a little harder to understand because technically as the data sits in a database, anything you can do with Drupal content you can do with phpbb content. However it does seem there is an advantage in this. Drupal content can be seen easily by views. You can attach taxonomy to it and see all the different kinds of content automatically. If everything is drupal content it makes it much easier to make dashboards or blocks that consolidate information together.
I think this can be seen clearly with CiviEvents. Whilst CiviEvents is powerful there is a lot you can do with calender+views+flag+field api+entities. These events can easily integrate with loads of different aspects of your site. Bridges are possible but less desirable.
Finally if its Drupal Content it can potentially be used by the thousands of other modules available to Drupal in ways that us developers wouldn't be able to predict.
3) Consolidated code-base
If you have Drupal + something else you will normally also need a bridge. This means 3 different sets of code with different release schedules and potentially different methods of updating things. CiviCRM is admittely more closely tied with Drupal which makes things nicer but I think its much nicer if all your code is Drupal when it comes to upgrading, troubleshooting and maintaining everything.
4) Drupal allows you to use complicated frameworks and building blocks to make a system unltimately easier to use and more tailored to a client's needs
This reason is to me, the strongest reason for using Drupal. I have found regularly when comparing Drupal to wordpress or joomla that whilst Drupal is harder for a site builder to understand. The complexity is there to allow you to build sites that are more finely tuned for the client and in the end much easier to use. Whereas VirtueMart will give you a complete shop out of the box, Drupal Commerce allows you to think about exactly what you need and only give that to the client making things much more streamlined. I feel CRM is something that actually means many different things to different people and has a huge amount of differences in scale. Therefore once the Drupal CRM is made it will allow site builders to build sites that will blow competitors using CiviCRM out of the water for some specific use cases (especially smaller scale organisations that are rapidly growing).
I can tailor my sites for the specific needs at one time (which might be basic) and slowly add features and complexity as the organisation grows. This fits in with the Drupal Way really nicely with its modules.
These reasons are nothing really to do with CRM. Its just the advantage of a solution in Drupal vs outside. Even if CiviCRM was the greatest piece of software in the world, these 4 reasons would still give a Drupal CRM a slight edge for some people.
Comments
Finally - Thank you
What a great question to answer - thank you James, this is valuable. That is one of the big questions I'm trying to get help answering for the sake of my clients. Along with your reason #3, can we also say that life becomes simpler if your CRM components are "native" to Drupal: less time spent in troubleshooting errors in a second code-base and no compatibility issues.
However, I still have this nagging thought in the back of my mind: can it make sense for a user to keep CMS tasks separate from CRM tasks (justification for use of CiviCRM)? Or is this unnecessary compartmentalization? One plus for CiviCRM is, you have not really left your Drupal site while working within Civi, the way you would if you have to click out into Constant Contact or MailChimp. My users have not complained about having to jump back and forth between Civi and Drupal, but yes, a Drupal CRM would give them a coherent and simpler interface to work with (you have seen this in action with your user testing).
I would love to see these issues discussed at PNWSummit and the next DrupalCon. Maybe by Denver2012 time, the Drupal CRM will be ready to rumble.
I added troubleshooting as an
I added troubleshooting as an advantage.
I think there is potentially an advantage in this seperation. But there are a couple of things about that
hehe I'd love to be at PNWSummit and the next Drupalcon but we're a very small startup with basically no money :P Maybe we could find some way of being on skype or IRC but it didn't work that well at DrupalCon London, people on IRC were kind of not heavily involved.
ThinkShout might end up being involved with our group a bit more though and it looks like they are going anyway? I don't know if anyone else amongst us is going.
I think your points are well
I think your points are well made.
The question "Why not use CiviCRM?" is more relevant if CiviCRM happens to do what you need. But I don't think CiviCRM should be looked at as a general purpose CRM system.
CiviCRM is a "Constituency" Relationship Management system and has a focus on member-based organizations, such as non-profits, associations, political organizations. The default types of Contact entities in CiviCRM reflect that: households, organizations, people. It is also reflected in other aspects of CiviCRM such as the collection of Contacts into "Memberships", with member dues and other aspects of a membership management system. CiviCRM can excel at cultivating and maintaining relationships with contributors, organizers, volunteers, members, families, etc, with the goal being the promotion of a cause, an organization a candidate, etc.
CRMs like salesforce.com or SugarCRM, on the other hand, are more business oriented: CRM as in "Customer" Relationship Management. By default these systems define core entities based on for-profit structures: contacts, companies, clients, projects, etc. These systems excel at cultivating business relationships with the primary goal of generating increased revenue.
CiviCRM could likely be made to perform well in a for-profit environment and, likewise, Salesforce or SugarCRM could be leveraged to serve non-profits. But given the option, I would use a system that had best out-of-the-box support for my needs, rather than trying to adapt one to be the other.
A Drupal CRM API could be useful on many levels, perhaps to build a system that competes with CiviCRM, but I would anticipate that it would be used for custom CRM implementations or smaller implementations that didn't merit the scope of a large, focused CRM system. I could see it also building better bridges between other systems, including CiviCRM, and, as yautja_cetanu said, I can see it being used by developers in many other ways that can not be anticipated.
Regarding the whole Large /
Regarding the whole Large / small, personally I wonder if its the other way round. We're looking at one client that has about 100,000 contacts. Does that count as large or small? (To me its large but I don't have loads of experience in this area). Anyway, at their size the importance of a Drupal CRM or at least something that can interface between their site and their CRM is becoming more important because so much of their interactions with clients is happening through the web. Whereas before a CRM system could be offline as it only needed to track meetings, phone calls, etc. Now we want to keep track of e-mails but also tweets, events they have signed up to throguh the site, groups on the site they are in and their posts/ comments on articles throughout the site.
I'd say one major disadvantage of a Drupal CRM is the main disadvantage of Drupal. If you have large needs, but don't know exactly what they are and you install CiviCRM you'll probably be fine. Drupal CRM will require you to know exactly what your needs are and plan for this, this is true of both a large site and a small site.
I think eventually we could have a Drupal CRM install profile that could compete with CiviCRM as an "out of the box solution" that you describe. But to be honest thats a long way off as even Drupal 7 is not quite there yet regarding Install profiles and distributions. There are a few great ones but they are incredibly difficult to maintain it seems.
I meant "large" as in the
I meant "large" as in the "large needs" - a wide scope of capabilities and requirements. Lots of contact records is one thing. How many ways one might interact with those contacts and how many related enitities there are in the system is a bigger issue. These combined will drive the user interface and information requirements, and that's where performance issues will come into play.