Ask Slashdot: Best Open Source CRM/ERP System For a Small Business? 163
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?"
Why, Opentaps, of course! (Score:5, Informative)
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.
Re:Out of the box solution is going to have pushba (Score:5, Informative)
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.
Re:CRM and ERP (Score:4, Informative)
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.
Re:CRM and ERP (Score:5, Informative)
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.
Re:A successfuk ERP conversion (Score:4, Informative)
Actually you are mixing 2 stories.
JazzScheme backend was redone in Gambit/C and Cairo about 5 years ago, that was the "hundreds of thousands of lines of C code were replaced by about 30,000 lines of Gambit." The project owner is Guillaume Cartier, but Marc Feeley and some of his students were involved.
The ERP project build using JazzScheme flopped some time ago for the usual reasons.
Tryton is a better choice (Score:4, Informative)
OpenERP has issues that you might not want to deal with. Some technical like using floats where decimals should be for example, and some political, similar to what SQL Ledger went through (OpenERP is commercially backed and some fundamental needs as well as developer/integrator participation requires $$$). The real pain point is that it has no supported upgrade path between major releases, and the people who run the project actively interfere with community efforts to provide upgrade tools that are open. Upgrading seems to be seen as a primary part of their business model.
Tryton is a fork of OpenERP community edition managed by a nonprofit group of developer-users. It's code base has diverged a fair bit by now and is much more solid, and I've been able to upgrade between releases without the hassle as testing and migration abilities are considered important core priorities.
Might be worth considering...