Slashdot Mirror
Ask Slashdot: Best Open Source CRM/ERP System For a Small Business?
An anonymous reader writes "One of my coworkers recently left the company, and I had to take over most of his responsibilities, including the maintenance and development of a homegrown CRM/ERP system. The system has evolved over more than a decade under the hands of at least four different developers and is based on Microsoft Access. Since I have been assigned this additional role, a day rarely passes without a user yelling for help because some part of the software is failing in strange and unpredictable ways, or some of the entered data has to be corrected manually in some obscure table in one of several database files. Without any exaggeration, some of the Visual Basic source code would be sufficient for several stories on The Daily WTF, and could make a grown man cry. Instead of spending further hours on optimizing this software i would rather like to start from scratch with some existing open-source CRM/ERP system that can be adapted to my companies needs. So far I have looked at and tested several CRM systems, including SugarCRM, vtiger, Feng Office (formerly known as opengoo), Zurmo and Fat Free CRM. Feng Office and Fat Free CRM look really nice and easy to use; the other ones could take a bit less bloat but are fine nevertheless. What software would you choose?"
I'm amazed it wasn't mentioned in the summary.
It's what we use. Very powerful and flexible and it covers most ERP areas. It also gives you easy path to running in the cloud if you want to do that, though we're running it on our own machines.
"Politicians and diapers must be changed often, and for the same reason."
Any out of the box solution that you try and move everybody to is going to have a lot of pushback. Since this was developed in house, it is most likely that every user's needs were catered to in a very specific manner. What you will probably find in trying to push something that you want to install and use, is that people will expect you to have the ability to change things very rapidly. You will hear a lot of "Well this is how it worked before you switched it."
Getting the information from your old system to an out of the box solution is going to be a huge hassle, and you will probably end up losing a lot of data in the process. You should look into having a developer improve or streamline the current system instead of trying to push a one size fits all solution down everyone's throat.
Granted, every organization and every situation is different. I would stay away from anything that you can't host in house, because you'll be blamed when the company goes belly-up and loses all of your information.
Sig: I stole this sig.
That's just mean.
Sure he's a poor unlucky sap but you don't have to yell it.
No brain, no pain.
You write "CRM/ERP" like the two are related in some way, but apart from both using a database they do extremely different things.
A true ERP system is orders of magnitudes larger and more complex than any CRM system, and while you can find examples of ERP systems with embedded CRM modules the reverse is not true. No CRM vendor - free or otherwise - has produced an ERP system.
Don't mix the two. It is like comparing a train with a motorcycle. They both have wheels and transport people, but beyond that ...
Before you proceed any further I strongly suggest you read up on the meaning of those two TLAs. And you need to analyze your needs - not just pull a new IT system out if your (or slashdots) a**.
Here is what you should be doing.
1.) Understand what these systems do. Wikipedia and the various vendors own descriptions are a good place to start.
2.) Make a list of your business needs. Do you need Marketing functionality in your CRM? Or Sales Forecasting? How about ERP - do you need product life cycles agent? Shop floor time registration? Production management? And what about support? Hosting?
3.) Make a list of your technical requirements. Like if you need toolbars that plug into MS Office, integrations with other systems, and your options for management reporting tools.
4.) Collect information about the system vendors and products you think mach your needs.
5.) Make a gap-fit analysis between the vendors you have identified, and your list if business requirements.
6.) You end up with a winner.
This will take a few days; but at least you'll be doing things right. Your company will be stuck with your choice of system for yet another decade so you need to be professional and serious about all this.
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
I take it you've never worked with end users.
"Think about how stupid the average person is. Now, realise that half of them are dumber than that." - George Carlin
Getting the information from your old system to an out of the box solution is going to be a huge hassle, and you will probably end up losing a lot of data in the process. You should look into having a developer improve or streamline the current system instead of trying to push a one size fits all solution down everyone's throat.
I agree with this, except for a blaring situation: the existing solution is a hodgepodge of VB and Access code. I'm dealing with something very similar at work...
One of our clients recently acquired someone else. Among them was a custom Access "application". It *must* be launched from a standalone executable, which *must* be run as administrator, and as best we can tell, requires a metric ton of DNS redirects because it pulls data from all over the network using server names instead of FQDNs or IP addresses, has a wheelbarrow full of security warnings due to extensive use of macros, fails in any version of Access except 2003...and cost the company over a quarter million dollars ten years ago. The amount of duct tape and string that this thing is being held together by is ridiculous, and it NEEDS to be moved into some sort of legit server/browser situation, since it literally will not run without reordering one's entire system around it. Now yes, we could (and are) tracing out those servers so we can add DNS entries to allow for domain traversal, but it still won't run on anything except Access 2003 without extensive rewriting, and the consulting firm that made it is no longer in business so we can't just "call the vendor".
Between the two options of "add more duct tape" and "deal with all kinds of pain and agony to make it somewhat standards compliant and run in a browser using some MS-SQL and HTML/PHP/ASP.NET*", it makes more sense to invest our time in a manner that will make it continue to run long after Access 2003 fails to install anymore.
*Yes, I know, the Microsoft database/web platform situation isn't exactly "standards compliant", but remember that we're coming from a Microsoft Access database, so getting data into tables is significantly easier than MariaDB or Postgres...and even if we end up in a similar situation where we can't upgrade the database beyond, for example, Server 2008/SQL Server 2008/IIS 7.0, at least that's server-side, can live in a virtual machine (and thus the hardware can be upgraded in time), and it's an internally facing setup anyway so security doesn't need to be as crucial a focus as if it were being pounded from the outside. If we're still there in 2018, that's fine - end user desktops can be changed whenever and it won't be nearly as big of a problem.
But that brings up a good point: CRM and ERP are fundamentally different tasks.
Yes, but the poster probably doesn't really know what he wants, and has probably never managed any sort of big project before. I have been working in the software industry for 30 years, and I can assure you that a "new guy" confronted with a complex system always recommends throwing everything away and starting over. But that is almost never the correct answer. Real world implementations don't look like the textbook examples that college students are used to, but doesn't make them "wrong". The existing implementation looks complex because it codifies hundreds of special business rules, such as discounts for the boss's friends, special commission arrangements with a particular salesperson, etc. You can't just throw out those rules, so you end up maintaining the old system simultaneously with trying to implement the new system. But your resources are split between these two tasks, so requests for fixes get backlogged, while the new implementation drags on for years. Meanwhile the "new guy" has left the company in frustration, and when the new ERP/CRM/WTF system is finally ready, it is a complete mess, and a fresh new guy recommends throwing it out and starting over. I have been around this loop many, many times.
ERP is used for tracking all internal transactions and workflow within a company. For instance, you type in information about what you're buying to make widgets into a Purchase Orders form, and this allows you to print a report version of the purchase order that you can email over to your vendor. Then, when the stuff shows up at the doc, you enter in the quantity of all the stuff that showed up, and your inventory goes up by that amount. When the invoices arrive, you can check to make sure you're not paying for anything that didn't show up.
Every time you enter a transaction, it appears in your financial ledger as a pair of transactions - a debit and a credit. This way, the accountants constantly know where you're making money and where there might be cost savings.
The idea is that by journaling all work in a structured data kind of way, it cuts down on lots of work required to reformat and communicate that information and generally speeds up the pace of business.
CRM is a smaller piece of this where you're entering details about conversations with customers and track the status of sales proposals. It's often disconnected from the general ledger and financial statements.
The answer is "it depends on the nature of the business".
Generally speaking, CRM covers front office business processes, while ERP covers back office business processes. However, these kinds of software are often vertically integrated (i.e. targeted at specific kinds of organisations/industries), and so at times the terms are used interchangeably.
CRM is primarily focused on the sales & marketing processes. ERP is commonly is primarily focused on getting the things you need to sell ready to sell (e.g. purchasing, manufacturing, hiring/developing employees/contractors) and managing the ordering/billing/delivery aspects of the sale. Both typically overlap in capabilities around sales.
CRM and ERP typically have different perspectives. CRM is typically customer-oriented, intended to create and build/maintain relationship with customers through managing the interaction with the customer, both directly and through sales/service partners. ERP is typically product-oriented, intended to make sure the organisation and its suppliers work together efficiently and effectively (from the point of view of being ready to meet market demand).
As a result, while large organisations typically have both, smaller organisations will have a variant of one or the other as their primary system. Smaller organisations where systemising the prepation and delivery of product is the focus will use an ERP (e.g. manufacturing), while smaller organisations where the relationship is the focus (e.g. close collaboration with the customer is required to get the sale and/or deliver the right product so the customer will become a repeat customer) will use a CRM (e.g. professional services).
Getting back to vertical integration, if a particular CRM is targeted at the professional services industry, it may include personnel/project management even though that's normally an ERP function; conversely, if an ERP is targeted at FMCG distributors, it may include sales partner program management so you can manage you distribution channels even through that's a CRM function.
Hope that helps.
The existing implementation looks complex because it codifies hundreds of special business rules, such as discounts for the boss's friends, special commission arrangements with a particular salesperson, etc. You can't just throw out those rules, so you end up maintaining the old system simultaneously with trying to implement the new system.
The issue isn't that setting up a new system is wrong; the issue is that there is no documentation or specification for the existing setup, therefore it's not actually possible to do anything with it. Generally, nobody in the business that is supposed to be responsible for or understand the business requirements are prepared to spend any time formulating them. What's left is for the implementers to determine business rules as best they can, due to apathy from management. Which turns into scapegoating when the system doesn't function according to the spec that existing in people's heads, but never anywhere the implementers could see it.
I've been around that loop many times, too.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face