I've been reading through the discussions (http://groups.drupal.org/node/91689, http://groups.drupal.org/node/92239 and http://groups.drupal.org/node/92294) and some of the framework coming in to place for how we should build a Drupal CRM. The conversation up to this point has been useful, but I think at this point we're delving a bit too much in the specifics. Questions of whether we should use Profile2 or if this should be a collection of modules are ones that are entirely dependent on how we want this CRM system to function. I want to step back for a second and take a 10,000 foot view of this issue and pose a couple questions.
What is a CRM?
On the surface this is a silly question but I think it's an important one. If you look at CRM systems such as Sugar CRM, Highrise, CiviCRM, Salesforce, etc. you'll find that while these are all CRMs what they do and how they operate are incredibly different.
- Sugar CRM and Salesforce are for moving potential customers through a sales pipeline.
- CiviCRM is designed for working with activist organizations.
- Highrise is a tool for contractors to work with clients.
While all of these share similarities, the end goal is different in many cases. I think most CRM systems have tried to deal with this by cramming in every feature imaginable to try and cover every possible use case. Which is exactly why every CRM ends up being a tool that's OK at a lot of things, good at nothing, and requires a lot of training to use effectively.
What about other cultures?
I'm currently staying in South Korea and one of the most interesting things about Korean culture is how relationships (often) work. Korea has a society that's very hierarchical and so relationships will often begin with a formal introduction and how that relationship is carried out will depend on the relative status of the parties involved. In short, they're much more serious than most relationships in the western world.
The CRM systems I've seen are very focused on the western concept of how relationships should be. However, this isn't the only way that relationships are formed and carry on across the world. The functionality of a CRM system for Korean culture would likely be quite different from one that is made for Americans.
Thoughts
To back this up with some concrete thoughts. I think that it will be nearly impossible to do this without drawing in work from other modules especially when it comes to getting names, addresses, age and many other things correct across countries and cultures. These are hard problems in and of themselves and we'll likely have plenty of work to do without tackling these problems as well. I don't know exactly what shape the end result will take, but the package manager included with Drupal 7 could potentially alleviate some of these headaches.
Making this system so it's usable out of the box will be extremely challenging. Who exactly will this be usable out of the box for? A saleperson? A project manager? Having a way to create flexible workflows would be awesome, and we could use a wizard to set up good workflows for a number of scenarios that could then be customized if needed.
I think we'll best be served by creating a minimal and flexible data model. While I think usability should be in all of our minds having a system with awesome usability on day one isn't necessary. Rather if we can create a modular system which we can prove people can build upon then we can improve the interactions and make life easier. I'll be editing the wiki here http://groups.drupal.org/node/92294 to clean a few items up and I would love to hear some more thoughts.
Comments
Flexible intergration
I just want to point out it will be nice to have clean and straightforward integration with all existing projects. I'm thinking about e-commerce and ubercart because [online shops] should have at least simple CRM functionality for theirs merchants/admins.
Integration is implicit in
Integration is implicit in the thoughts from above. A CRM with a flexible underlying data model is one which will be integrated with other systems. On CiviCRM in particular, the APIs were very limited and the hooks in Civi were next to worthless. I think have a sane structure will make it easy to integrate this CRM with other systems.
Civi's hook structure is quite extensive ...
CiviCRM does have a fairly extensive (and also growing) hook system. check:
http://wiki.civicrm.org/confluence/display/CRMDOC32/CiviCRM+hook+specifi...
Would be good if you could elaborate a bit on why you consider it worthless. There is also a lot of work being done on the API. We are aware of limitations with the API and the community is working hard to help improve it
lobo
Ok that have sense for me..
Ok that have sense for me.. so as far I see this after all we can create some uc_dropcrm module for integration ubercart with dropCRM using solid core API (with hooks) from our CRM project.. hmm..? what do you thing?
What is a website?
My vision for the the DropCRM project has always been to answer the question "What is a CRM?" in the same way that Drupal answers the question, "What is a website?"
The answer: "Whatever you make it."
It sounds to me like you saying, "There is no one CRM to end all CRMs" and I would agree. It would be a waste of time for this group to try and build the one perfect solution. "Usuability" is entirely relative to the use case. In CRM, what is the most 'usable' for one organization may be completely wrong for another.
So while I have envision a very simply out-of-the-box CRM Drupal distribution / install profile, the heart of the DropCRM idea, in my mind, is creating a box of tools that make is easy for a moderately saavy drupal developer to easily build a "custom" CRM solution, that can be polished for usability using the standard drupal tools - FAPI, phpTemplate, Views, etc, etc.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
I agree
This make sense for me, but maybe there should be some kind of DropCRM core where we can install it and work just "out of the box". Some basic functionality, and then you can change like in drupal in the beginning you can create pages/storys and comments to them..
What's do you think..
best, sobi3ch
I like sobi3ch's idea. So we
I like sobi3ch's idea. So we would have something like a CRM interface into Drupal which can be backed by existing external CRM's or by a drupal based backend - which should work out of the box and still be a bit tweakable.
Not bit tweakable but full
Not bit tweakable but full tweakable as far as your skills allow you :)
The role of a Drupal Native CRM
The role of a CRM project should be pipes and framework. From my point of view a CRM is a system for tracking interactions. Making all interactions trackable is key to the success of this or any CRM project. We want to know how we relate to our clients, prospects, partners, competitors and anyone else we might come in contact with.
The interactions that are tracked should be able to be used by Drupal and Views or other modules and everything in Drupal should be able to be tracked. This would mean that anything that is in Drupal or connected to Drupal say social graph data from Facebook or Twitter could be used by Views and the framework built for CRM.
Further CRM's bring data from diverse sources together. This means that the CRM as a framework should help aggregate the things we track such as sales, social graph, interactions with Drupal, interactions with other sites, and anything else on the Internet let alone the things we add from our off-line interactions.
CRMs reveal relationships and a Drupal Native CRM framework must be able to build ad-hock relationships and expose these to Views and other modules in a way that a company or organization can adapt.
What is tracked and how we track it is what each organization (sector) needs to work on. If everything is trackable and aggregated then a nonprofit can decide to show donations and event data and a site selling shirts can show what shirts people buy and data about their interactions with the site.
There are general principals that this community should use, like making things very themeable, granular security, document, document, doucment and the other things that bring us to the Drupal community in the first place. Having an open community that brings in ideas from all CRMs is vital just like in the Drupal community we can learn from other CMS systems.
A CRM framework could provide tools for editing, icons for determining what things are, examples of relationships, suggested module integrations (almost like seo_checklist. If there is a framework and then ideas of how to extend that then we have built something that the world can use. We should encourage people to add their use cases and ways of integrating the framework. Integrating with modules like Features is a great way to encourage this.
Owner and Lead Consultant
Denver DataMan
Agree with @denverdataman. So
Agree with @denverdataman. So from what we should start? Should we prepare list of modules CRM need or maybe from analysing other open source CRM's to grab some ideas from them?
Usable functionality is useful functionality
First of all: I say we should just brainstorm as many as possible of: user types, even example users, use cases, desirable functionality: anything that the CRM ought to accomplish. Please don't be shy: as sbroz says here, this "specification gap" is something we really, really need to address.
Got any thoughts? Put them at the bottom of the existing wiki page. As they get clearer and more well defined then we can gradually push them up the page into the Targets, Constraints and Goals. If they're really clear, and really important, then they can even get so high up that they force the Mission to change. Imagine that the wiki page is sitting in the fog, so you can put indistinct elements at the bottom of it, and as they rise up they need to get clearer; but we need to keep the top of the structure as clear and as obvious as possible!
In answer to your specific comment, we definitely need ideas for functionality, but I think that if we focus just on that then we might end up with a fully functional but ultimately hard to use system. I'd like to see a native Drupal CRM which end users find straightforward to use, as that's a key to making the project worth while. Otherwise the smaller pool of users we'll actually attract to the finished product will either not really need a CRM or will be adept enough at Drupal configuration to bodge one together themselves with content types, views etc.
With that in mind I think it would be good to get an idea of the kind of users we expect to use the system, and what sort of things they're likely to do. (If we had time then it'd be great to create user personas with some depth, but I think that's overkill based on the number of people we've got involved: if everyone's as busy as me then we'll never get round to it!)
At the very least we need to think about the way users use the current open source CRMs, and use that to create some requirements, maybe in a "user story" format. @CitizenKane mentions South Korean cultures and how that affects CRM use. @CitizenKane, could you elaborate on that, in the wiki page? Let's also think about salesmen, secretaries, account managers, office juniors, project & resource managers etc.
@sobi3ch I think the first
@sobi3ch I think the first thing we need to do to start is decide that we are doing this in Drupal 7 so we can talk about how to do it. Feature lists are great but creating a framework is not as much about features as it is a frame.
We have a great frame provide by jp.stacey (http://groups.drupal.org/node/92294) and that is a wiki doc so we can work there. I have features in mind but I think they are beyond the framework.
Owner and Lead Consultant
Denver DataMan