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

109 of 163 comments (clear)

  1. Insightly by Anonymous Coward · · Score: 1

    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.

    1. Re:Insightly by Jane+Q.+Public · · Score: 3, Interesting

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

    2. Re:Insightly by Nerdfest · · Score: 1

      They all suck for specifics. _All_ of them. If it's not written specifically for your business, you're not going to be very happy. If you want something that's not perfect pretty much by definition, you might as well consider something from Apache.

    3. Re:Insightly by Jane+Q.+Public · · Score: 1

      Interesting. Apache's Ofbiz site gave me an invalid certificate error.

    4. Re:Insightly by Jane+Q.+Public · · Score: 1

      Just wow.

      AFTER taking half of forever to compile, OFBiz took about 5 minutes just to start! I could have rebooted my Mac 3 times or more in the same amount of time.

    5. Re:Insightly by Nerdfest · · Score: 2

      Don't complain to me. I *told* you you wouldn't be happy.

    6. Re:Insightly by ShanghaiBill · · Score: 5, Insightful

      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.

    7. Re:Insightly by tibman · · Score: 1

      Fine for me in FF.

      The cert MD5 fingerprint is: 85:A3:B9:6E:6D:98:CB:FA:6B:E8:DB:3F:0F:88:F3:BC (typed by hand because FF won't let me copy/paste, blah)
      SHA1: bc 5f 40 92 fd 6a 49 aa f8 b8 35 0d ed 27 5e a6 64 c1 7a 1b (woo, chrome lets you copy paste)

      --
      http://soylentnews.org/~tibman
    8. Re:Insightly by Anonymous Coward · · Score: 1

      See, /. gets bought out by Dice, and suddenly someone looking for advice gets hammered by some idiot salesman from "Unsightly". Oh and it work better than all the open source alternatives, not just brand A or brand B, but all of them altogether!

    9. Re:Insightly by Jane+Q.+Public · · Score: 1

      I was using Firefox too. But it's not doing it now, so maybe it was only a temporary error.

    10. Re:Insightly by Jane+Q.+Public · · Score: 1

      Haha.

      I wasn't complaining. Just making the observation. :o)

    11. Re:Insightly by LordLucless · · Score: 4, Interesting

      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
    12. Re:Insightly by Antonovich · · Score: 2

      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.

    13. Re:Insightly by bigalzzz · · Score: 1

      I think it was a bug in the last version, a recent update sorted it out - it was bloody annoying though!

    14. Re:Insightly by dotancohen · · Score: 1

      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.

      You are recommending an American hosted solution for someone to trust his business secrets to? You haven't been paying attention lately.

      --
      It is dangerous to be right when the government is wrong.
    15. Re:Insightly by mrego · · Score: 1

      Then there is the case where the "new guy" wants to replace the old system just because he thinks his solution is more elegant somehow even when the old system works almost perfectly. Or when the "new guy" just wants to use XML because it is newer even though it is completely unnecessary for the application (and actually will degrade its performance). To all the "new guys": maybe the old guys were not as stupid as you think.

    16. Re:Insightly by davidannis · · Score: 2

      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.

  2. Pay for what you get by asmkm22 · · Score: 1

    That includes network admins.

  3. SAP by Anonymous Coward · · Score: 1, Funny

    Obviously.

    (Yes, this should be modded flame-bait.)

    1. Re:SAP by drainbramage · · Score: 4, Funny

      That's just mean.
      Sure he's a poor unlucky sap but you don't have to yell it.

      --
      No brain, no pain.
    2. Re:SAP by PolygamousRanchKid+ · · Score: 2

      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!
    3. Re:SAP by mysidia · · Score: 1

      The anonymous reader is looking for something free. SAP is short for "Send Another Payment"

      SAP is decidedly not "free", BUT zero licensing cost is not free either.

      Sometimes the most expensive option you can pick will be the free one!

      The important thing to remember is software license cost is not your only cost.

      Time and energy have to be invested in deploying whichever solution you pick and making it work; in other words, shoehorning the software into the role, customizing as necessary, and forcing the employees to adapt to the requirements imposed by the software.

      If you're not familiar with the software then probably you are not up to it yet. Your company should probably be hiring other organizations to assist; Know your limits and seek outside help when appropriate.

      Now there are plenty of commercial solutions; some of them may be a more appropriate fit for your organization than any one of the free ones.

      They're worth investigation --- because whichever one you pick; your company will be investing and committing significant resources to the choice.

      Being so enamored with a certain license cost, or distribution model is not appropriate for most businesses; these are "nice to haves" from a geeky point of view.

      But the selection of which CRM application to use is a business decision that should not be constrained by trivialities like "free" --- whichever offering will benefit the company the most, seems the right choice. (It's probably not SAP)

  4. Why, Opentaps, of course! by Prune · · Score: 4, Informative

    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."
  5. Re: Who is to blame? by Anonymous Coward · · Score: 1

    Yeah, probably yelling at the other guy. Now it's OP's problem. :/

  6. Out of the box solution is going to have pushback by ModernGeek · · Score: 5, Insightful

    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.
  7. OpenERP? by div_2n · · Score: 2

    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.

    1. Re: OpenERP? by jordg · · Score: 1

      I have a similar situation. I use dbconvert to put what useful data from
        access to postgres. export spreadsheets from Recon/quickbooks. Read data into OpenERP massaging on the way. I have had to modify OpenERP to suit our specific needs. I would recommend using version 7.0. The doco is better and the API is also much improved. There is a steep learning curve but that goes to all ERP systems.
      OpenERP handles both CRM and ERP, which falls within your requirements. But don"t be naive and think that porting these in house apps is easy. It is not.
      Plan well, get expert help and training and OpenERP will cost less than many alternatives.

  8. Sugar CRM by brokenin2 · · Score: 2

    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..

  9. Get serious about your selection process by SplatMan_DK · · Score: 5, Insightful

    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...
    1. Re:Get serious about your selection process by msobkow · · Score: 3, Insightful

      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.

      --
      I do not fail; I succeed at finding out what does not work.
    2. Re:Get serious about your selection process by msobkow · · Score: 2

      Typo: "those three" databases, not those four.

      The selection of a database is key to success when dealing with systems integration. Don't let the rah-rah fanbois and sales reps tell you otherwise.

      --
      I do not fail; I succeed at finding out what does not work.
    3. Re:Get serious about your selection process by mtutty · · Score: 1

      Came here to say essentially the same thing - GET REQUIREMENTS. No matter which road you end up choosing, the requirements will make choices much clearer, and their objective nature will give you a buffer against the business folks who agreed to them, but want the flaming logo on Wednesdays.

      I did this a few years ago for a decent-sized telecom, that wanted to get rid of dozens of home-built systems in favor of telecom-specific ERP type software (usually called OSS for this industry). The RFP was a bust (no vendor selected), but those requirements guided the next 18 months of systems development, COTS adoption, integration and legacy retirement. In the end, even the business folks acknowledged that without the written requirements, they would not have been able to make any of the advances we made.

    4. Re: Get serious about your selection process by SplatMan_DK · · Score: 1

      If it is a proper system then integration is done through an application layer and not directly on the storage layer.

      Hacking two systems together using the storage area is a method from the 70s which you really should abandon if at all possible.

      Few scenarios may still warrant that approach. But they are few. Very few. And probably not present in a small company.

      - Jesper

      --
      My security clearance is so high I have to kill myself if I remember I have it...
    5. Re:Get serious about your selection process by MariusBoo · · Score: 1

      To achieve this in SQL Server do this:
      BEGIN TRANSACTION;
      SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
      //update your table here
      //.. wait as long as you want
      COMMIT TRANSACTION; //when ready


      Alternatively you can use the WITH( REPEATABLEREAD) table hint when you select (but you still have to use transactions).
      There are also implicit transactions and a lot of other ways to control concurrency...

    6. Re:Get serious about your selection process by msobkow · · Score: 1

      I'll have to look into that. I've never heard of an UPDLOCK clause.

      Figures Microsquishy would have some incompatabible syntax for doing the same thing as the standards. :(

      --
      I do not fail; I succeed at finding out what does not work.
    7. Re:Get serious about your selection process by msobkow · · Score: 1

      Repeatable read is not the same as SELECT...FOR UPDATE.

      Select for update lets you pin the data, analyze it, and then update it consistently with the values you read. While delta id's can let you detect update collisions with SQL Server and Sybase ASE, you have to write very platform specific code that updates the record, does it's analysis, and if no update is actually required, either rolls back the transaction or updates the delta id back to it's initial value.

      What really sucks is that both SQL Server and Sybase ASE document the "FOR UPDATE" clause -- they just barf at runtime if you try to use it.

      --
      I do not fail; I succeed at finding out what does not work.
    8. Re:Get serious about your selection process by msobkow · · Score: 1

      i.e. With SQL Server and Sybase you have to do something like:

      UPDATE mytable SET deltaid = last-known-value-of-delta-id + 1;
      SELECT * FROM mytable;
      // do analysis and calculations
      UPDATE mytable SET deltaid = last-known-value-of-delta-id // To undo the lock without changes, or
      UPDATE mytable SET foo = updated-value;
      // Repeat for any other records you need to update
      COMMIT;

      This is an absolute HACK of a way to code around the lack of SELECT...FOR UPDATE which lets you far more concisely do:

      SELECT * FROM mytable FOR UPDATE;
      // Do calculations
      UPDATE mytable SET blah = foo; // Only if necessary, there is nothing to undo
      // Repeat for any other records that need updating
      COMMIT;

      There's a reason every database I've ever encountered other than SQL Server and Sybase ASE implement "FOR UPDATE". It's part of the standard for SQL, and it was created because it's useful and necessary to implement consistent code in anything vaguely resembling a concise fashion.

      --
      I do not fail; I succeed at finding out what does not work.
  10. Go with with the pros use by Anonymous Coward · · Score: 2, Funny

    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.

    1. Re:Go with with the pros use by idunham · · Score: 1

      Clueless fellow who doesn't even understand what he's replying to.
      The OP did not write it. He inherited it. VB was not his choice.
      This isn't "How do I go rewrite this crap" but "I'm all for tossing every vestige of this out the door; does anyone have a replacement?"

      And while we're at it:
      SQL Express?
      Go with Postgres or something else that scales in terms of systems rather than wallets.

    2. Re:Go with with the pros use by kermidge · · Score: 1

      I thought it was satire.

  11. Re:TrueCloud / NetSuite by epyT-R · · Score: 1

    Uh yes they should worry, if they want autonomy as a business. While the current system sucks, replacing it with some remote company that doesn't give any more fucks than it has to to keep the contract is not the answer either. The 'cloud' is a not a magic fix-all no matter what the idiotic hype says.

  12. Re:Obvious by cusco · · Score: 4, Insightful

    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
  13. Re:Out of the box solution is going to have pushba by Voyager529 · · Score: 4, 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.

  14. OpenERP by liquidcable · · Score: 2

    OpenERP

  15. Re:Out of the box solution is going to have pushba by thechanklybore · · Score: 1

    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.

  16. Salesforce.com by BaronM · · Score: 1

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

  17. Re:Obvious by Bacon+Bits · · Score: 2

    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.
  18. Re:Out of the box solution is going to have pushba by Lumpy · · Score: 1

    "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.
  19. Obvious choice by wagnerrp · · Score: 1

    I was always a fan of CRM114...

    1. Re: Obvious choice by BaronM · · Score: 1

      Masochist.

    2. Re: Obvious choice by shikaisi · · Score: 1

      I was always a fan of CRM114...

      Masochist.

      Yes, I think he's some kind of deviated prevert. I think General Ripper found out about his preversion, and he's organizing some kind of mutiny of preverts.

      --
      No left turn unstoned.
  20. Re:Obvious by Lumpy · · Score: 2

    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.
  21. Depends on your resources and your requirements. by Harlequin80 · · Score: 1

    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.

  22. xTuple by sphealey · · Score: 1

    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

    1. Re:xTuple by idunham · · Score: 1

      I'd say +1 on xTuple, but you've got far more insight than I.

      I was about to suggest that myself; my brother demonstrated it recently at a smallish manufacturing company he works for. IIRC, they ended up going for the commercial version.

    2. Re:xTuple by ixidor · · Score: 1

      Man Visual Manufacturing is a Beast. the last upgrade we aided with, cost the company somewhere around $4000. This was for a minor point release, not even the quarterly Service pack type release. It has a terrible instal procedure. is not centrally manageable. Compared to E2, night and day.

  23. X2Engine or OpenObjects by skaag · · Score: 1

    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...

    1. Re:X2Engine or OpenObjects by sobolwolf · · Score: 1

      I thought the project was still called OpenERP with OpenObject being the type of API/framework it uses. Also as of Verson 7.0 I believe they are doing away with the Desktop client in favor of a pure browser based system.

    2. Re:X2Engine or OpenObjects by skaag · · Score: 1

      I am always confused about the OpenERP vs. OpenObjects naming. I once went to their channel on Freenode and was told from now on it's called OpenObjects. So I don't know what to make of it.

      Too bad about the desktop client going away. It felt much more responsive to users, and they absolutely loved that last time I tried the app a few years ago. But a very well written web based system can feel very fast too.

      My only concern with it is as someone in this thread noted, that once you go into the guts of it to make customizations, that it's a nightmare.

      --

      All those moments will be lost in time, like tears in rain... time... to... die...

  24. SFDC, Workday, done. by nbvb · · Score: 3, Interesting

    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.

    1. Re:SFDC, Workday, done. by nbvb · · Score: 1
    2. Re:SFDC, Workday, done. by erp_consultant · · Score: 2

      I've implemented on premise solutions for ERP and CRM. While SAAS is the flavor of the month at the moment there are some real issues with it. Let's start with Workday. You cannot customize it in any way....outside of simple mods like changing field labels. You cannot create your own custom pages, records, fields, or code. Period.

      In 15 years of implementing ERP systems I have never been to a client that didn't have a need to customize something to fit the way they do business. Not one...in 15 years. For a small or perhaps a medium size company this might be an acceptable compromise. For a big company - which is your typical ERP customer - no way. The truth of the matter is that there is no one size fits all solution when it comes to ERP. Pick just about any business process you like - hiring an employee, creating a voucher, enrolling a student - and I can almost guarantee that there will be variations from company to company. Not being able to customize the software is a serious drawback. Serious.

      Now Salesforce, on the other hand, does allow you to customize the software. It's fairly easy to use and administer and the interface is pretty slick. For my money, if I'm looking at a SAAS solution I would take Salesforce over Workday in a heartbeat.

  25. The obviously stupid question. by hendrikboom · · Score: 1

    Let me ask it here -- just what is an ERP supposed to do?

    -- hendrik

    1. Re:The obviously stupid question. by cdrudge · · Score: 1

      An ERP system allows you to run your business. It's generally a suite of applications or modules that cover production, ordering, inventory management, accounting...all the things that make the business run. The system can be something relatively simple and generic that can apply to almost any company in a basic way, or it can be extremely complex and highly customized, specific to only a single company.

    2. Re:The obviously stupid question. by hendrikboom · · Score: 1

      Thanks. That's the first straightforward explanation I've seen. Most explanations I've seen consist of acronym soup.

      There are presumably well-known, generic applications in the prepackaged ERP systems, and they have enough hooks that it's possible to add code that changes their sources of data, their results, and enables you to write completely new applications that use their output and provide their input.

      -- hendrik

    3. Re:The obviously stupid question. by Tetch · · Score: 1

      Once upon a time, all organisations of any significant size had an in-house 'Computer Department', with systems analysts, and programmers, and computer rooms, and operations teams ... which provided bespoke custom-developed applications suites to perform all the business functions that organisation depended upon. These custom applications worked more or less well.

      Then, along came the Big Bad articles in CEO magazine, which convinced the CEO to liberate herself from the need to employ all those IT weirdos (with their strange clothing, incomprehensible jargon, and salaries that offended the HR department), by simply outsourcing the organisation's IT needs - usually by buying an off-the-shelf ready made suite of software (often from SAP Corporation) that allegedly could perform any conceivable kind of business function ... all you had to do was write a few configuration files that specified the parameters that defined the actual business needs of that organisation, press the 'Run' button, and hey presto.

      This off-the-shelf ready-made software is known as Enterprise Resource Planning (ERP) software, and it never does exactly what you need it for, but the CEO and the ERP sales consultants all get to have huge bonuses, and three holidays a year, and the actual end-users get to 'blame the computer' for the rest of their lives. Only a few old-timers still whisper in the canteen about the days of The Mainframe when Things Just Worked.

      Oh, and the redundant in-house IT staff, who used to work on the bespoke custom application systems, get to have no cookie :)

      These days I dust and polish my old COBOL-74 manuals in the shrine in the attic, tell my nephews and nieces lurid tales of paper-tape punches and systems that were taken down every Wednesday morning for hardware maintenance, shake my head in disbelief at all the J2EE-framework websites that litter the Interwebs, and stare into the distance a lot.

      Did I ever tell you about the time th..[][][][][]..NO CARRIER

      --
      If you don't pray in my school, I won't think in your church.
  26. A successfuk ERP conversion by hendrikboom · · Score: 2

    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

    1. Re:A successfuk ERP conversion by bidule · · Score: 3, 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.

      --
      ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
    2. Re:A successfuk ERP conversion by hendrikboom · · Score: 1

      Thanks for the update. I stend corrected. Maybe the typo in the subject "successfuk" for "successful" wasn't all that wrong.

      -- hendrik

    3. Re:A successfuk ERP conversion by bidule · · Score: 1

      Yeah, the typo was perfect.

      --
      ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
  27. We've been using OpenERP 7 by Anonymous Coward · · Score: 1

    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.

  28. ERP for "small business"?! by ebyrob · · Score: 1

    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.

    1. Re: ERP for "small business"?! by SplatMan_DK · · Score: 1

      I might head over to Wikipedia to correct that error.

      It is really not the size of the company that matters, but the complexity if it's business processes.

      A well-implemented ERP can do miracles for a production company with as little as 30 employees, as long as the production is sufficiently complex to warrant the kind of investment (both economically and time) that an ERP systems requires.

      Hell, I've helped implement ERP for an 11-man business; though I will admit they were a very special and specific case.

      - Jesper

      --
      My security clearance is so high I have to kill myself if I remember I have it...
  29. Re:Out of the box solution is going to have pushba by Bite+The+Pillow · · Score: 1

    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.

  30. CRM and ERP by noh8rz10 · · Score: 1

    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.

    1. Re:CRM and ERP by Anonymous Coward · · 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.

    2. Re:CRM and ERP by WiPEOUT · · Score: 4, 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.

    3. Re:CRM and ERP by afidel · · Score: 1

      If your systems are any good your ERP and CRM will be linked, often with a content management system thrown in as well. For instance you want to be able to look up your customers orders, invoices, etc when you're talking to them so those will get pulled from the content management system and you might want to be able to pull their current balance so you'll need to be able to talk to your ERP system. If all these systems are islands it's a LOT harder on the customer rep. The fact that most of these systems are web enabled today makes this integration fairly easy (certainly much easier than the old backend processes of syncing the data between systems and customizing each piece to fit your businesses mix of systems).

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  31. ADempiere by Holistic+Missile · · Score: 1

    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.
  32. Pronto.net by DeathElk · · Score: 1

    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

  33. Re:FrontAccounting for ERP by coastwalker · · Score: 1

    Oh do tell us what makes something that looks like it came from 1998 "shit". I presume you have some problem with anything from before your birth. Most business software looks like "shit" of course and with good reason - its not used to play games.

    --
    Facts are history now plebs have politics for religion on social media.
  34. Re:TrueCloud / NetSuite by coastwalker · · Score: 1

    Its definitely not free, but it seems to work as well as any other ERP I have ever come across. The cloud means the support is outsourced but availability and functionality are fine. Frankly I am surprised by how well it works, I am very suspicious of IT bullshit - having worked on both sides of the fence.

    --
    Facts are history now plebs have politics for religion on social media.
  35. Re:Out of the box solution is going to have pushba by Splab · · Score: 1

    Erm, why would you ever(!?) prefer hard coded IP addresses over domain names?

  36. Openbravo by Zibodiz · · Score: 1

    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.

  37. Re:Out of the box solution is going to have pushba by oatworm · · Score: 1

    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.

  38. Filemaker by Anonymous Coward · · Score: 1

    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

  39. The poster is looking for a magic bullet by plopez · · Score: 1

    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+
  40. Re:Out of the box solution is going to have pushba by oatworm · · Score: 2

    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.

  41. Re:Out of the box solution is going to have pushba by bdo19 · · Score: 1

    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.

  42. Just ask System of a Down by MrKaos · · Score: 1

    Sugar!

    --
    My ism, it's full of beliefs.
  43. There generally isn't a "best alternative" by Stolpskott · · Score: 1

    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 :)

    1. Re:There generally isn't a "best alternative" by Joey+Vegetables · · Score: 1

      I've just read at least 3 comments to the effect that migrating the DB from Access to SQL Server will be easier than to, say, PostgreSQL. I would respectfully disagree. This might be true if you did not need schema changes or normalization. There are tools to make that specific use case effortless. However, you *will* need to normalize and make schema changes. Thus, there is going to be some custom coding and/or ETL work involved, regardless of which DB backend you choose. So why not spend the few minutes necessary to support standard SQL, which every decent backend is going to understand, and then choose the backend based on its own merits since the "automated migration" tools are not going to help much anyway?

  44. Mod parent up; +1 funny by SplatMan_DK · · Score: 1

    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...
  45. Re: Now you know... by SplatMan_DK · · Score: 1

    Actually it is a decent tool nowadays.

    You can use it as the presentation layer for a SQL server (including non-MSSQL servers).

    I used to hate it as well, but if you just use it without storing data locally it's not half bad. Not anyone anyway.

    --
    My security clearance is so high I have to kill myself if I remember I have it...
  46. Re: Dont waste your time by SplatMan_DK · · Score: 1

    Because SF is extremely expensive once your requirements leave the nice little cheap basic package they push on you - and you always end up with a gazillion added costs?

    Marketing and BS is the only way they ever became a successful business. Their product isn't so bad; just extremely overpriced for what it does. Really. In a big way. /J

    --
    My security clearance is so high I have to kill myself if I remember I have it...
  47. Re:Honestly? by vikingpower · · Score: 1

    Wow. An SAP consultant posting as AC. Is it that bad, dude ?

    --
    Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
  48. Open Source CRM + Custom-made code in Gambas by webgang · · Score: 1

    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.

  49. Tryton is a better choice by WebCowboy · · Score: 3, 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...

  50. Since when is ERP out of box? by WebCowboy · · Score: 2

    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.

  51. Document your processes by pater+noster · · Score: 1

    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.

  52. Re:Obvious by Lumpy · · Score: 1

    Take time to look and see what they are doing. It's a silly secret technique used only bu ninjas and shadow operatives. It's called research.

    --
    Do not look at laser with remaining good eye.
  53. Re:Out of the box solution is going to have pushba by Lumpy · · Score: 1

    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.
  54. Re:Why no payroll in Open Source ERP systems by RattFink · · Score: 1

    OpenERP does. Probably doesn't have the right rules for your state/province/territory but only took me less then a week of work to take nothing to a working system and the company has been using it for around 9 months with anything more then tweaks.

    --
    "I don't necessarily agree with everything I say." - Marshall McLuhan
  55. Capriccio Fuzion by Techbum · · Score: 1

    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.

  56. Re:Out of the box solution is going to have pushba by Chas · · Score: 2

    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!!!
  57. Take a look at sourceforge list by eldy · · Score: 1

    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.

  58. Re:Out of the box solution is going to have pushba by Drewdad · · Score: 1

    This is what vApp was invented for.

  59. answered by OP by bitterblackale · · Score: 1

    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.

  60. CiviCRM by perlstar · · Score: 1

    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.