Tweet
SugarCRM has been very successful, and marketing has been a very big part of that. The technology is very old, however, and that has led innovation to fall by the wayside over the years. I think they understand this now, which is why they have closed the doors on the Open Source side and are desperately trying to refactor their code base and change the way it basically works. Some would argue that the problem is not one of technology, but I would strongly disagree - their codebase has gone as far as it can, and has reached so many road blocks that it is extremely difficult to advance it without pulling a lot of it down and rebuilding it from the ground up. By today's standards, the code is a pile of excrement, in short.
So this is where Espo can come in. You are starting with a great code base, a great number of open source libraries, and dependency management (composer) and decent templating systems, and SugarCRM as a prototype. However, if you base the design too closely on SugarCRM, you may start running into some similar limitations. I think you just need to be aware of these as you move forward.
For example, SugarCRM puts contact and account addresses onto the contact and accounts records, and ultimately the contact and account database tables. That immediately knocks out a whole community of potential use-cases. It may be fine for one purpose only - selling stuff to companies - but Customer Relationship Management is a universe bigger than that, and is VERY poorly served by the CRM systems available, all of which base their internal data structures off the same old SugarCRM. It is maddening and frustrating.
Addresses are entities in their own right, and can have many different formats and layouts around the world, and different ways of validating, and drop-down lists for countries, and lookups for counties/states/regions/provinces - addresses are complex. A few fields on the contact record is a poor way of representing them. Contacts can also have many addresses - a work address, and home address, a temporary address, an invoice address when they are purchasing a service or product personally - the list is limitless.
And then what are contacts? They are people, simply, people. As a person, they may be employed by an organisation. They may be employed by several organisations. They may go to a university, be a member of an organisation, or several organisations, have their post delivered to another, and be seconded for a project at yet another. Relationships between people and organisations are complex, and every use-case introduces more relationships and *reasons* for those relationships. SugarCRM does not allow you to put properties onto a relationship, and that has been faithfully copied here.
So, my intention was not to come here and criticise. It is me venting that nowhere - and I mean NOWHERE - is there a decent Open Source CRM that truly models relationships in a generic fashion, and does not start with the same basic set of promises that it will be used only by salespeople on a phone, talking to contacts, each of who represent a single company who will be doing the buying. It is a shame, and I was hoping EspoCRM would help to fill this gap. As a framework it may be able to, but it does not appear this is a direction that the project is taking.
I have have this all wrong, but it is difficult to see where the project is going, with so little guidance, no public git repository (or a very hard to find repository).
So, best of luck, the product looks great in what it does, and is smooth and easy to use and install. I just feel that it is trying to follow in the exact steps of SugarCRM and is missing some incredible opportunities that are just off the linear path that SugarCRM took, and that could meet the needs of many organisations that are still having to manage all their relationships with spreadsheets and bits of paper. The data model is a big part of this, because the data model you start with is going to hold you back.
I hope you take this in the right way - meant with the best of intentions. This [turned into a] rant is just the result of not being able to find that perfect CRM for member organisations that do more than just sell to companies through contacts.
-- Jason
So this is where Espo can come in. You are starting with a great code base, a great number of open source libraries, and dependency management (composer) and decent templating systems, and SugarCRM as a prototype. However, if you base the design too closely on SugarCRM, you may start running into some similar limitations. I think you just need to be aware of these as you move forward.
For example, SugarCRM puts contact and account addresses onto the contact and accounts records, and ultimately the contact and account database tables. That immediately knocks out a whole community of potential use-cases. It may be fine for one purpose only - selling stuff to companies - but Customer Relationship Management is a universe bigger than that, and is VERY poorly served by the CRM systems available, all of which base their internal data structures off the same old SugarCRM. It is maddening and frustrating.
Addresses are entities in their own right, and can have many different formats and layouts around the world, and different ways of validating, and drop-down lists for countries, and lookups for counties/states/regions/provinces - addresses are complex. A few fields on the contact record is a poor way of representing them. Contacts can also have many addresses - a work address, and home address, a temporary address, an invoice address when they are purchasing a service or product personally - the list is limitless.
And then what are contacts? They are people, simply, people. As a person, they may be employed by an organisation. They may be employed by several organisations. They may go to a university, be a member of an organisation, or several organisations, have their post delivered to another, and be seconded for a project at yet another. Relationships between people and organisations are complex, and every use-case introduces more relationships and *reasons* for those relationships. SugarCRM does not allow you to put properties onto a relationship, and that has been faithfully copied here.
So, my intention was not to come here and criticise. It is me venting that nowhere - and I mean NOWHERE - is there a decent Open Source CRM that truly models relationships in a generic fashion, and does not start with the same basic set of promises that it will be used only by salespeople on a phone, talking to contacts, each of who represent a single company who will be doing the buying. It is a shame, and I was hoping EspoCRM would help to fill this gap. As a framework it may be able to, but it does not appear this is a direction that the project is taking.
I have have this all wrong, but it is difficult to see where the project is going, with so little guidance, no public git repository (or a very hard to find repository).
So, best of luck, the product looks great in what it does, and is smooth and easy to use and install. I just feel that it is trying to follow in the exact steps of SugarCRM and is missing some incredible opportunities that are just off the linear path that SugarCRM took, and that could meet the needs of many organisations that are still having to manage all their relationships with spreadsheets and bits of paper. The data model is a big part of this, because the data model you start with is going to hold you back.
I hope you take this in the right way - meant with the best of intentions. This [turned into a] rant is just the result of not being able to find that perfect CRM for member organisations that do more than just sell to companies through contacts.
-- Jason
Comment