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.
It's been a long time since I took a look at it, but it's been around quite a while. I don't see it in your list, so it's probably worth you at least checking it out.
It's a little flaky, but no more than systems you pay a lot of money for..
Of course, it really depends on how well it meets your requirements..
"Just went through this nonsense. Switch to Insightly. It's easy and it works better than the open source alternatives, plus you don't have to host it."
Insightly is CRM. It doesn't do ERP.
But that brings up a good point: CRM and ERP are fundamentally different tasks. I doubt OP will find many packages that do both well. My suggestion would be to look for them separately.
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...
Go with MS-SQL Express. It is free and it has been very, very good to me. Access? Only for beginners. You have been at it 10 years now so you can move up to big boy software: MS-SQL Express. Did I mention it was free? It is free so enjoy. If you want to continue to use VB you may but I recommend also moving up to big boy software, MS .NET, and c sharp. You will need to hunker down and learn to rid yourself of your VB ways, but you need to learn new skills if you want to play with the big boys.
To cap: Stop using Access. Stop using VB. Advanced IT uses MS-SQL Express. And .NET for customization. Go with the IT pros use.
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.
OpenERP
I agree. That's why you do research. You need to bring to the table the best possible options. Users know what their job is, but they don't know how to tell a good system apart from a bad one. You don't pick for them, but you need to narrow it down to prevent the paradox of choice problem.
The road to tyranny has always been paved with claims of necessity.
I want a pony, I want a sports car, I want ice cream, I WANT EVERYTHING AND NOTHING AT THE SAME TIME!!!
And then next week all of their decisions change yet again.
Never EVER ask the users.
Do not look at laser with remaining good eye.
The anonymous reader is looking for something free. SAP is short for "Send Another Payment" which is a literal translation of the original German, "Scheiß Aufs Privatleben."
Sort of.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
Don't complain to me. I *told* you you wouldn't be happy.
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.
Forget maintaining / rolling your own. Doesn't make ANY sense, especially when this thing got dropped in your lap.
Salesforce.com for CRM.
Workday for ERP.
Sleep at night. Priceless.
There was a paper presented at a Lisp/Scheme - related conference a few years ago about how someone managed to wrestle an ERP system (whatever that was) into submission.
It started out as hundreds of thousands of lines in C or C++ (I forget which).
They decided they wanted to add a scripting language to it.
They picked Gambit/C, an implementation of Scheme that can be compiled to C, and can also be interpreted.
Gradually, when they had trouble with particular parts of their huge system, they discovered it was often easier to rewrite them in the scripting language than to fix the C code. Gradually, over a few years, hundreds of thousands of lines of C code were replaced by about 30,000 lines of Gambit. And it ran faster in the scripting language (which could be compiled, after all) than it had formerly run in C. And it had more features.
If you can accomplish a major rewrite an improvement incrementally, you can probably achieve continuity of operation that would be difficult any other way.
Now I don't know how Gambit would link with Microsoft's BASIC. But there's probably a way, and perhaps you should look into it.
You might want to communicate with Marc Feely, the Gambit/C author about the possibilities.
The Gambit/C mailing list is at https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Yes, there's a server misconfiguration that may prompt your browser to give scary messages, but that's the URL.
The main page of the Gambit wiki is at http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page
-- hendrik
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.
Assuming the schema matches. Which, by the way, is an extremely bold assumption when you're dealing with pulling data out of a custom Access solution cobbled together over the past decade and pushing it into an out-of-the-box solution.
Having seen a few custom Access jobs in my time, I can tell you first-hand that, more often than not, you're lucky if the data is normalized, much less organized in any sane, sensible way. I've seen tables where there are "Serial Number 1", "Serial Number 2", and "Serial Number 3" fields, for example, because "nobody has more than three pieces of equipment". So, now you're faced with having to get that data halfway normalized, or at least document how you could normalize it, and then you have to map it up against the new solution's schema and hope and pray they have a set of tables that are designed to hold the data you're looking for.
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
I worked for a few years early on in my career on VB6 + Access code (and actually an ERP to but that was VB6 + Oracle). There were several Daily WTF that could have come from that code too (one of the company's key production functions was 1k-odd lines with 17 levels of IF...). In general I completely agree with your recommendation that you should always think long and hard about throwing production code away, even if it creates a lot of maintenance and *particularly* if you are an SMB. However, I actually left that company many years ago because despite spending many non-paid hours coding away at home doing stuff, spending most of my day on VB6 + access was getting to be too much. You would have to pay me shitloads, really SHITLOADS to ever work with those technologies again. So you get to a point where a technology is completely obsolete and it's time to throw it away, even if it sort of works. We're not talking about a bank either with processes that could cost millions with the smallest error so the COBOL argument doesn't really fly here. There are plenty of cheap/free solutions out there, though the costs for rethinking processes and retraining would probably dwarf any acquisition costs anyway. But unless you are completely standing still as a company you *should* be rethinking processes and having a tool that can easily adapt to new needs is critical to that. Even SMBs need a bit of future-proofing and with the rate that technology is moving, unless you keep your tech moving along you risk being made obsolete by the next web startup, whatever you are doing (3d printing anyone?). My 2c.
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...
ERP software is not an out of box application. It is a development platform for creating line of business apps. It should be treated like a web app framework. It provides a user interface and workflow engine along with a set of modules that you can implement on top to provide accounting, inventory control, and other business functions. But it has to be programmed, and you also may have to modify your business procedures to better work within the confines of the framework as well.
Perhaps that is why do many implementations fail. ERP is sold as off the shelf or ready made. It is not. You must go through a proper software dev lifecycle and PROGRAM an ERP as if it was a fancy visual studio for business. ERP merely saves time by providing the framework...the boilerplate code...vs. from scratch. So it should be devoted the appropriate time and resources regardless of how you have to feed the data in from a legacy system etc.
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.
I've seen both sides of this argument. I have seen companies try to replace a system and be unable to replicate the functionality that they need in a new system. On the other hand I've seen companies decide after trying to replicate poorly documented business rules in new software that they need to take a long hard look at all the rules and jettison most of the software customization that is unique to the business. Some of it is there for reasons that no longer apply. Some customization is no longer used. Some customization is counterproductive. The trick is to identify which customizations are worthwhile and having somebody at the top who says no to customization that isn't really necessary so that it doesn't grow endlessly. Ask yourself how different your business is and how critical the customization is. An IT guy, especially a new one needs to get buy in from the top because he will not be able to say no to requests to keep and add business rules.
Sorry, but you've NEVER actually done a CRM/ERP migration have you?
Yeah. You're right. You can drop field data that doesn't schema-match into the notes fields.
However, a lot of that stuff isn't going to make sense to future users because there's no longer any context for it.
In which case, you may as well be dumping in random characters.
Also, not every setup supports raw copy/dumps in a forward-compatible manner.
Sure, the data may appear on the server. But in some cases, it won't sync because it wasn't brought in properly with the API. Meaning that if you're running a sync-user setup for remote salesguys, they don't ever see that data.
This is CRM Migration 101. While a CRM may sit atop SQL, simply treating it as "yet another bunch of SQL data" is missing the point.
Chas - The one, the only.
THANK GOD!!!