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?"
Re:Out of the box solution is going to have pushba
By Voyager529
•
2013-Sep-25 18:52
• Score: 5, Informative
• Thread
Getting the information from your old system to an out of the box solution is going to be a huge hassle, and you will probably end up losing a lot of data in the process. You should look into having a developer improve or streamline the current system instead of trying to push a one size fits all solution down everyone's throat.
I agree with this, except for a blaring situation: the existing solution is a hodgepodge of VB and Access code. I'm dealing with something very similar at work...
One of our clients recently acquired someone else. Among them was a custom Access "application". It *must* be launched from a standalone executable, which *must* be run as administrator, and as best we can tell, requires a metric ton of DNS redirects because it pulls data from all over the network using server names instead of FQDNs or IP addresses, has a wheelbarrow full of security warnings due to extensive use of macros, fails in any version of Access except 2003...and cost the company over a quarter million dollars ten years ago. The amount of duct tape and string that this thing is being held together by is ridiculous, and it NEEDS to be moved into some sort of legit server/browser situation, since it literally will not run without reordering one's entire system around it. Now yes, we could (and are) tracing out those servers so we can add DNS entries to allow for domain traversal, but it still won't run on anything except Access 2003 without extensive rewriting, and the consulting firm that made it is no longer in business so we can't just "call the vendor".
Between the two options of "add more duct tape" and "deal with all kinds of pain and agony to make it somewhat standards compliant and run in a browser using some MS-SQL and HTML/PHP/ASP.NET*", it makes more sense to invest our time in a manner that will make it continue to run long after Access 2003 fails to install anymore.
*Yes, I know, the Microsoft database/web platform situation isn't exactly "standards compliant", but remember that we're coming from a Microsoft Access database, so getting data into tables is significantly easier than MariaDB or Postgres...and even if we end up in a similar situation where we can't upgrade the database beyond, for example, Server 2008/SQL Server 2008/IIS 7.0, at least that's server-side, can live in a virtual machine (and thus the hardware can be upgraded in time), and it's an internally facing setup anyway so security doesn't need to be as crucial a focus as if it were being pounded from the outside. If we're still there in 2018, that's fine - end user desktops can be changed whenever and it won't be nearly as big of a problem.
Re:Get serious about your selection process
By msobkow
•
2013-Sep-25 19:14
• Score: 4, Insightful
• Thread
While it's true that there is a large market for CRM systems that do not require ERP, there is a significant market of ERP users that require CRM support from their ERP.
However, I do agree that the odds of finding a single solution that is good at both is unlikely. The author would be better off looking for seperate systems that support easy customization and extension so they can be tied together. While this will require some work, the odds of success are much greater.
One thing I would recommend: make sure the systems use a real database like PostgreSQL, DB/2 UDB, or Oracle. Those four support "SELECT...FOR UPDATE" syntax properly, which makes it possible to implement embracing locks between two seperate databases for a dual-system solution. MySQL with appropriate extensions and table configuration will work as well, but the odds are that either or both of the systems selected won't be coded to use those extensions, making it a very risky proposition. Sybase ASE and Microsoft SQL server do not support "SELECT...FOR UPDATE" syntax properly, so you can't implement embracing locks with those databases, despite their performance and popularity -- they cut corners and require a completely different (and more difficult) style of coding to achieve the same effect.
Ideally you want databases in the back end that can support two-phase XA commits rather than coding embracing locks, but that limits your database options even further, and comes with it's own set of technical challenges.
Of course if you can get away with generating a "report" from one system that is "imported" by the other, batch-style rather than having deep integration between the two, your job will be much easier. Don't let the wish lists of your users obstruct the focus on meeting the core needs of the business. Just because someone wants to hit a function key and be taken to the appropriate screen in the CRM system from the ERP doesn't mean that they have to have that functionality to do their job.
Remember, the most important thing to do is to get management buy-in on the risk and expense of the data and functionality migration. If you don't have buy-in from management and the ability to say no to unrealistic or unnecessary user demands, you're dead before you started.
Re:Insightly
By ShanghaiBill
•
2013-Sep-25 20:05
• Score: 5, Insightful
• Thread
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.
SFDC, Workday, done.
By nbvb
•
2013-Sep-25 20:12
• Score: 3
• Thread
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.
A successfuk ERP conversion
By hendrikboom
•
2013-Sep-25 21:18
• Score: 3
• Thread
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