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?"

Comments

Out of the box solution is going to have pushback

[ModernGeek]

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.

You're screwed.

[Anonymous Coward]

What software would you choose?"

You don't have the manpower to move to anything else. You implied it.

If you don't have the manpower to support what you have, what makes you think you can move to something else? It's a LOT of work.

And we're talking about F/OSS stuff here - you know: download, install, curse, run, curse, set up, curse, ask for help and told to "RTFM". curse some more, reinstall, ask a questions and then told to "RTFM", reinstall, curse, port, merge, ask a question and told to "RTFM", curse, and then say "Fuck IT!" and go back to your old solution or hire a professional firm to do it - i.e. NOT F/OSS.

Get serious about your selection process

[SplatMan_DK]

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

Re:Get serious about your selection process

[msobkow]

While it's true that there is a large market for CRM systems that do not require ERP, there is a significant market of ERP users that require CRM support from their ERP.

However, I do agree that the odds of finding a single solution that is good at both is unlikely. The author would be better off looking for seperate systems that support easy customization and extension so they can be tied together. While this will require some work, the odds of success are much greater.

One thing I would recommend: make sure the systems use a real database like PostgreSQL, DB/2 UDB, or Oracle. Those four support "SELECT...FOR UPDATE" syntax properly, which makes it possible to implement embracing locks between two seperate databases for a dual-system solution. MySQL with appropriate extensions and table configuration will work as well, but the odds are that either or both of the systems selected won't be coded to use those extensions, making it a very risky proposition. Sybase ASE and Microsoft SQL server do not support "SELECT...FOR UPDATE" syntax properly, so you can't implement embracing locks with those databases, despite their performance and popularity -- they cut corners and require a completely different (and more difficult) style of coding to achieve the same effect.

Ideally you want databases in the back end that can support two-phase XA commits rather than coding embracing locks, but that limits your database options even further, and comes with it's own set of technical challenges.

Of course if you can get away with generating a "report" from one system that is "imported" by the other, batch-style rather than having deep integration between the two, your job will be much easier. Don't let the wish lists of your users obstruct the focus on meeting the core needs of the business. Just because someone wants to hit a function key and be taken to the appropriate screen in the CRM system from the ERP doesn't mean that they have to have that functionality to do their job.

Remember, the most important thing to do is to get management buy-in on the risk and expense of the data and functionality migration. If you don't have buy-in from management and the ability to say no to unrealistic or unnecessary user demands, you're dead before you started.

Re:Obvious

[cusco]

I take it you've never worked with end users.

Re:Insightly

[ShanghaiBill]

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.