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?"
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.
http://frontaccounting.com/
That includes network admins.
Obviously.
(Yes, this should be modded flame-bait.)
You should just drop it from your responsibilities altogether and offer up www.TrueCloud.com as an alternative. A business shouldn't *have* to worry about that stuff.
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."
Yeah, probably yelling at the other guy. Now it's OP's problem. :/
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.
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..
Why not ask your users what they need and then decide based on that rather asking Slashdot?
OFBiz is Apache's solution. http://ofbiz.apache.org/
OpenTaps appears to be a frozen version with vendor support. http://www.opentaps.org/
I've heard horror stories about supporting OFBiz on the backend, but that's likely because our job titles were "system admin," rather than J2EE. G'luck!
Solving this kind of situation has been my job for the last 12 years. Standard software (proprietary or open source) is not going to do the job. Why? The level at which you can configure the software will be wrong (more correctly: not adjusted to your bussiness needs). You will end up spending more resources configuring than would be needed by rebuilding the system.
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.
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.
Don't overlook Tustena. It is a horrible name, but good product.
http://sourceforge.net/projects/tustena/
or
http://www.tustena.com/en/
this co-worker left.
and access? seriously? anything you choose to replace it will be better. ANYTHING... even sticky notes.
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.
It's quite nice, written in python and uses Django 1.5. MIT license.
https://github.com/treeio/treeio
Of course, it is not nearly as full featured as decade old projects, but on the other hand, assuming you can program in python, it could be an excellent starting point for highly customized version for your company.
OpenERP
For the CRM stuff why bother rolling your own - sign up with Salesforce.com and pick the appropriate plug-ins to keep the coworkers happy.
Unless you are s/w developers it's a hell of a lote less ballache than roll your own
I have to agree with this. I tried (and tried and tried) to move my company's ailing VB-based CRM system to a OOTB solution, but none of the platforms I tried (Sugar, VTiger, and a few others) really did what we needed. Either too much or too little complexity and customisation with each.
In the end I gave up and spent a week designing, and then another two weeks implementing, the first version of a custom-built solution using Zend Framework (yes sorry, feel free to snarl at my framework/language choice, but it's great for quick prototyping and RAD). Obviously I've had endless feature/bug fix requests ever since, but after initially trawling the SugarCRM code it became clear that any amount of customisation on their awfully confused and verbose code would be so troublesome, and that our needs as an small business were so specific, that getting any of the other solutions into shape was going to be an entirely joyless exercise.
If they'll give you a few weeks of time to do it yourself, and you follow good coding practice, you'll end up with something far more lightweight and fit for purpose.
This is probably true, thought, not always necessarily the case. A good software review and needs assesment would need to be done, however, this is probably the case in most instances that I have been involved in.
...or some other SAAS solution. Really, there is almost no reason to do this on-prem anymore. If you are idealogically open source, then sure, you are legitimate exception. Just be sure the "you" in that case is "your organization", not "you personally".
"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."
It is absolutely possible for someone that has a clue how to work with databases to get the information from on to the other without losing anything. Unles the origional system was written in VB6 and is using some wierd ass system you cant run SQL queries or stored proceeders on.
Get the data out as a dump, and a little perl or python and you can get it into the new DB easily after a few tests.
Do not look at laser with remaining good eye.
I was always a fan of CRM114...
Will an off the shelf system meet the needs of your business?
You obviously already have a database that was built in house. It probably did what it was first meant to do well but scope creep over the years has totally destroyed the original vision (been there, done that).
Given that, could you feasibly do a re-write? Migrate to a better back end, to a better language. Can you break the current system into bite sized parts and convert them little by little?
Sugar, SalesForce etc etc etc are great IF they suit your business. There is one thing worse than a flaky database/CRM. It's one where your staff won't use it, so they have all gone to running their own spreadsheets.
If your management team is willing to invest in the project you have years of usage cases to draw upon and a 10 mile long feature list.
I have worked with a proprietary ERP system for the last 10 years, I always thought it would be cool to freelance and implement opensource ones. However a big stumbling block I have always ran into is no Opensource ERP or even Open Source Accounting package has a payroll module.
I know it is open source so I could write one but I am a horrible coder for anything complex. I just wounder why many will implement things like manufacturing and service management but no payroll? Do most companies really outsource the payroll? Very few that I work with do.
You make it sound as though you are going to make this decision on your own; if so, this is a bad idea. You need to get management and users (especially users!) involved in the decision making, and keep them involved during the implementation. If you don't do this, you will be forever blamed, criticized, and resisted for bring in "your" system, and it will always be compared unfavorably to the old system.
Involving others, especially end users, has real benefits:
1. They will see things you did not see, or did not consider important.
2. They will be much more willing to take time and effort to learn and use a system they had a voice in choosing.
3. When others start carping about how the old system was better, they will be advocates on behalf of the new system, and will have the time and knowledge to explain why the change was necessary.
If you do it right, your evaluation team will evolve naturally into an implementation support and training team. Also, be prepared to make some compromises - the system which looks ideal to you from support standpoint may have serious drawbacks to the users. Narrow your choice down to a short list which all on the team can agree will work, and then make a final choice based on consensus.
xTuple is a possibility, as are a number of midrange packages depending on your industry (e.g. Visual Manufacturing for machine shops / small make-to-stock operations). But you really need to get a handle on your requirements and budget first. Budget includes not only dollars but willingness of director-level managers to second key players onto the implementation team for as long as it takes. If you can't get that, well, time to get the resume to the headhunters.
If you tell us what your line of business is and approximate headcount (fixed + field personal) and annual turnover I/we can give better suggestions. But it isn't something that can be done offhand (I've been doing this since 1996).
sPh
SugarCRM is very mature, and has a built-in "Developer Studio" where you can create new modules, add new fields, and so on. The only downside is when you need to do complicated stuff, then you need to hire a PHP developer to write custom actions for you. Another missing feature in the Community Edition is a proper Workflow Engine.
X2Engine comes with a workflow engine which is an awesome feature when you need status that function based on a certain logical business process.
And of course for me the ultimate system is OpenObjects (formerly known as OpenERP), it's a fantastic and quite complete system, but requires Python knowledge. But it has fantastic client software (desktop) for most popular operating systems, which makes some users feel more comfortable with it (it does also have a web interface, which is also very, very good, and all clients implement the same user experience pretty much so you feel at home with all of them).
All those moments will be lost in time, like tears in rain... time... to... die...
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.
eGroupware & pERP
Let me ask it here -- just what is an ERP supposed to do?
-- hendrik
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
What software would we choose? Probably something completely different than what you need because our needs aren't your needs. You are going to have to talk to the people who use the existing system and see what their requirements are. Then you take those requirements and see what product fulfills them. Every company's requirements are different so a different company will choose a different product. No one here can help you with this as we don't work at your company and can't talk to the people who depend on the existing system.
As a small company we've been using OpenERP 7 for quite a while and it works for most of the tasks. We've been rolling out features very carefully and slowly, 'cause OpenERP is a big beast.
I just have to point out a bit of a seeming discrepancy here. From the wiki article on ERP:
> However, information tools like ERP are expensive, and not a practical method for medium or small business owners.
I suggest maintaining a good relationship with your ex co-worker involving him answering the odd email from you and you giving him beer.
Just switched to a process driven system intended to funnel requests through their workflow.
It works for what it was designed to do. But once data goes in, it stays there. What was that thing I did for that user? Don't know, can't find it. That guy who left, he wrote something that solved a problem, was there any specific error checking that made it work? No idea.
Historical data was not a selling point, and was not considered by the people who bought it, and now I'm stuck with it.
The worst case is tracking - why was this changed? Who asked for this? We have ticket references - but they were for the old system, and no way to access it, or get the data. Ticket 12345 could have been seen by the head honcho, or the janitor. A backup probably exists, but there was no migration strategy. Migration is a great selling point - but most of your data won't fit.
can anybody give some specific examples of what CRM and ERP are used for in a big company? I know what the acronym stands for, but I don't know what they mean in real life.
Definitely worth a look. Open source version of Compiere - ERP/CRM and more. You don't mention what line of business you are in, but this is a flexible system you can tailor to your needs. I am in the process of implementing it for a hobby (photography) that has recently become (if accidentally!) profitable. Postgresql backend, native client and web client. Great price, too - free (as in beer and speech)!
Support is available, as well.
When you're dead, you don't know you're dead. It only affects the people around you. Same thing when you're stupid.
pronto.net. Not Open Source although you can get a developers license that allows you to compile 4GL programs. If the business is worth running, then it's worth paying for mature software and support. Very rich suite of applications, including CRM, inventory, warehouse, project costing, POS, payroll, ARAP, plant maintenance, hire, assets, RFI, etc
You are putting the cart before the horse.
First of all, do a Requirements Analysis, write a Software Requirements Specification and get your boss to sign off on it..
Erm, why would you ever(!?) prefer hard coded IP addresses over domain names?
Openbravo is an ERP solution that is open source with premium (paid) services available. They'll try to force the premium services on you, but if you run your own server, you don't need them. I downloaded it and played with it a little a couple of years ago, but never bothered to set it up. We have a very small computer shop and it was simpler to write my own basic database interface (besides, I'm one of those idiots who enjoys coding and likes to make things 'just right', so I created my own software from scratch for our 3-employee business -- darn you OCD!)
I do, however, use their foss POS software and like it pretty well. I've had to make a few alterations to fit our business, but it's by far the best I've used. I strongly considered writing my own POS software as well, but the discomforts of using theirs were outweighed by the headache of credit card APIs and PCI certification.
For a small business, just ply your customers with whisky, that should keep them happy.
You wouldn't - but you'd really prefer to not use NetBIOS names under any circumstances. Otherwise, SERVER1 is always going to have to resolve somewhere, regardless of domain, regardless of network topology, and that somewhere better be where the database expects to find useful data.
Laugh all you want, but Filemaker has come a long way. Vendors who bid to replace ours walk away in shame.
Google Filemaker ERP CRM
An therefore is asking the wrong questions. The first questions should be:
1) What does the current system do?
2) What should the current system do?
3) What is the value in what it does?
If what the current system does has no or little value, then throwing it away without a thought is not a bad idea. If there is value in it then what is it that gives the job it does value? What is there that the system cannot do that should be done? Also, one should ask what are the potential negative consequences from migrating to another application.
Basically The first step is to analyze the business and the current system. Then and only then will the correct software become apparent. It may be that the current software is the best solution and all effort, including hiring a temp contractor, might be best spent revamping that system.
Remember, ERP migrations have a huge failure rate http://www.zdnet.com/2013-erp-research-compelling-advice-for-the-cfo-7000011619/
So be careful
putting the 'B' in LGBTQ+
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.
I built an Access database like that for an SF based client 15 years ago. It was originally written in Access 2.0 and wasn't even my system to begin with but I added so much to it that I still know it by memory. It would always fail on upgrading to newer versions of Access because it needed COM objects added to the references for things like Mail Merge. On startup it would check a server path for a preference file to see if it should replace itself with a newer version. The back end should have been migrated to SQL Server but couldn't get approval for that. The last I heard (2011?) they were migrating to Salesforce and didn't need me anymore.
The hardest part of migrating a system like that is going from having the entire recordset open on a form to the transaction method of one record at a time. The easiest way would probably be to have it periodically replicate to SQL Server, then build forms in ASP.Net, and then have Access generate links to the web forms with long random numbers in the query string for user validation.
Consider moving your access 2003 executable into a cantral server-side VM, using VMWare View. Your VM can be Win XP with Access 2003 or whatever is needed to run that app, along with whatever weird hacks are needed on the client side. You could even use a hosts file for those server names if you want. Changes to the client image happen in one place for all users. Easy. And the users get to move on to Win 7 with newer office etc etc without worry of conflicts or convoluted configurations every time someone gets a new desktop, to support this one app. Clearly you'd prefer to get rid of that app altogether. Good luck with that! But if that doesn't happen, this could be your plan B. I've had success with it.
Sugar!
My ism, it's full of beliefs.
I would bite the bullet and use SAP. I don't just say that because I'm an SAP consultant either.
Most of the open source options just aren't mature/stable/complete - and you'll have to pay for support for them anyway. Configuration and support is most of the cost of an ERP system.
On the other hand, SalesForce.com, etc. have hosted platforms that might make much more sense for a smaller company and will still be much much better designed than any Access database.
In fact - *anything* will be better than an access database (except of course, Excel). If you want a quick fix that will make things somewhat better, at least convert the Access tables into MS SQL Server and link them to Access. At least then you won't have to worry about data loss as much.
When trying to replace an in-house system for something as business-critical as ERP and CRM (basically, everything your business does, and everyone you talk to), even when that system is based on as simple a solution as MS Access, any potential solution is going to require significant customization from its out-of-the-box state to (1) work, and (2) work the way your business wants it to work - remember, that the current business workflow both depends on the way the application works and also defines the way the application has to work. :)
If you are a good coder (the complaints about coding style and quality suggest you are better (or at least more energetic, at the moment) than the previous guys, then migrating to a more reliable SQL database (maybe MS SQL, maybe something open-source, but the MS SQL option would be less complex a data schema migration, I suspect), and then refactoring the VB code so it is cleaner, smaller and more reliable, might be an option.
If you do not have the time for that task in addition to your other roles, then you will not have the time to install and configure a replacement CRM/ERP system, because that replacement will require a massive investment in time and effort to re-discover the business rules and work/data flow that the ERP system needs to support and account for, plus the "shortcuts" that employees use to get an end run around processes at 15:00 on a Friday afternoon because they need to get either a shipment or themselves out of the door asap.
Add to that the fact that business users cannot accurately tell you what their workflow is 95% of the time, or they pad things to make their roles more important, or they forget important steps, and figuring out the "what" an application does is relatively easy. Figuring out "why" it does it that way, so that you can put data validation rules and consistency checks in place is very hard. That goes for any ERP system, whether it is a paid solution with external consultants or an open source/in-house system that you produce. The difference is that with the paid solutions, those headaches are primarily the responsibility of the external consultants... you will just have the headache of figuring things out when the consultants screw up
Mod parent up; +1 funny.
It can't be anything other than a morbid kind of twisted and dark humor.
It has to be. Please. ... ... please ... /J
My security clearance is so high I have to kill myself if I remember I have it...
...you can give a try to ERP5: http://www.erp5.org/
It is loosely based on Zope, tries "scientific" approach to business analysis.
There have been some success with pure "open-source" implementations (aka: no support from company which stands behind the product).
Anyway, prepare for loooong and expensive, but really interesting project.
Good luck.
We had a similar situation years ago, and started with a web-based open source CRM (that runs on internal servers, not online). It was to early to find an existing one at that time, so we let someone program it for us, and we use it for basic stuff that hardly changes. It is made with php, and the data is in a MySQL database. Small changes we can do ourselves. Now I would use e.g. Dolibarr. But the nice thing to leave Visual Basic behind but keep some flexibility: Gambas. It is a free programming environment to make as well command-line programs as real GUI programs. We make a lot of custom programs that use the mysql-data of our CRM to do calculations, make management dashboards, special output, prints/lists etc. And even correction programs for data corrections in the database: by making small programs for it, they first can be tested on a developers copy of the dataset. Now even users can start corrections without too much risk. Manual corrections in the database .. horror ...
Oh yes, did I mention we switched to Linux on the desktop at the time we made the web-based CRM? We have some macs around as well.
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.
Before you proceed any further. I'd suggest to take a step back and start documenting your processes and use-cases. If you're currently using a homegrown solution chances are good that there are many "non-standard" specifics in your processes which aren't handled in standard off-the-shelf software. So, when choosing a solution you should look at your processes/use-cases and for each possible candidate determine if a candidate software can handle it or how much customization would be needed to make it fit. Only then you can realistically estimate the cost of each canditate and therefore make an informed decision.
Optionally invite consultants for the various candidates (be it open source or commercial) telling them you're planning to migrate away from your current system and you want an offer from them. They'll work out the many details in your processes with you to be able to make an offer and whether you accept their offer or not you will have much more information of what's really going on in your company.
Even if the Schema doesnt match, you drop the rest in the "NOTES" field that they all have, this is Databases 101 stuff.
Do not look at laser with remaining good eye.
MS has a free trial of Dynamics CRM and it's customizable and hosted. It gives Salesforce a run for the money (literally, it's cheaper).
Designed for small businesses, integrates (in an automated way!) with Quickbooks, hosted, easy to use. http://capricciofuzion.com/. Not difficult to use and the company provides very responsive support.
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!!!
You may find a list of a lot of other alternatives on sourceforge http://sourceforge.net/directory/?q=erp Sourceforge provide an infomation on "Enterprise" ready solutions. Number of download is also a good indicator of popylarity of solution. You may find the Dolibarr ERP - CRM ( http://www.dolibarr.org/ ), or OpenBravo are also a very good choice if you are looking for an easy to use software.
This is what vApp was invented for.
This seems to be a thread in which the OP included better suggestions than any of the commenters. Most people seem to be criticising the OP over something purely pedantic. Having submitted that, I will admit that I can't find any better open-source CRMs other than what the OP posted.
This is an impressive open source CRM platform that is absent from the list.
http://civicrm.org/
It can be used in conjunction with Drupal or Joomla.
It is a full feature ERP based on zope (zope.org) which is a python based application framework. ERP5 created Unified Business Model ( http://www.erp5.org/UnifiedBusinessModel) that can be used to create any business workflow using its 5A concept which underlies all functionality. It is based on the idea that there are nodes (warehouses, accounts, locations) that have paths (conditions for movements between nodes), resources (material etc) flow between nodes with defined paths and each instance of resource is an item that can be tracked. With a solid foundation of UBM which is thoroughly tested, one needs to define a workflow using these 5As and you have an application meeting *your* requirements. This is different from the idea of "best-practices" that more often than not are far from the processes that used within your organization. So, it means that organization does not have to bend itself to meet the requirements of the solution.
The first step is to migrate the data to Sql Server. Solves most of the problems in a multi-user access application.
Then you can pick off pieces to move to new environment.
There is OpenERP. It is written in Python, which means very secure and stable, and has a modular design. You can write your own module(s) and/or extend existing ones.
You get what you pay for.