So I wanna develop my own ERP software...

June 10, 2009 5:11 PM

I'm a freelance software developer and I have a customer contract for building a software product that supports their manufacturing business.

After digging for ERP open source solutions I couldn't find a clear match for my project. It seems to me that existent solutions are overcomplicated for my costumer needs, and my end users are not at all accustomed to ERP complexity.

So my approach is to start a small software package, with a clear focus on real customer requirements, and eventually improve the product into an ERP-like solution for small manufacturing businesses.

I know there are already common data models for ERP systems and the common business processes are already defined. But I don't know where to learn about this stuff. I don't have any experience. So where can I find information to get me on the right track and build this software package the way it should be build. (I do not want to re-invent the wheel.)

Another way to put this question is: What would you do if you decided to develop your own ERP software package? How would you do it?

posted by dfreire to technology (6 comments total)

To misquote Home Simpson: "Uh, what does the E stand for?"

I don't wish to sound negative but you're probably biting off more than you can chew and potentially doing your customer a disservice in the long run. ERP is big. Enterprise big. I started my career writing SCM and warehouse management modules for a soft goods oriented ERP web application, we were over a dozen people including several business analysts on a tightly knit team and it took us about five years, while there were another 70 or so working on the other aspects of a complete ERP solution (manufacturing, financials, CRM, project management, data warehousing/reports, etc.).

You may think you're doing the customer a service by starting them off with something simple, but unless they're willing to pay for a reasonably sized team to build an ERP solution from scratch (and why on earth would they want to do that?) there will be some major disappointment when your product doesn't scale to meet enterprise needs due to a lack of enterprise resources.

I'm not familiar with the open source ERP solutions out there, but there seems to be a few. Couldn't you start out your client on just some of the modules, and work their way up?
posted by furtive at 8:59 PM on June 10

"... What would you do if you decided to develop your own ERP software package? How would you do it? ...
I'd rethink all my assumptions, after studying in detail, the pre-sales literature of even 10% of the 15,000+ or so independent ERP packages that already exist, worldwide.

furtive is absolutely correct in saying "... ERP is big. Enterprise big. ..." So robust and highly profitable a company as Oracle, as recently as 2004, decided to enter the ERP product space by purchasing Peoplesoft/J.D. Edwards for $10 billion, instead of tackling the project of writing an ERP product of their own. Larry Ellison is a very smart guy, and he already knew he was sitting on Oracle, the leading commercial DBMS, and had working G/L, AR, and AP apps in the Oracle family. And still, with all that, and his huge customer base, he bought his way into ERP. He was right, and he bought about 160 million lines of source code, and about 3,000 consultants and software developers for his $10 billion. Not that Peoplesoft/J.D. Edwards is the be-all and end-all of ERP systems. One of the major competitors to Peoplesoft in international businesses running ERP systems is SAP, and it is estimated by many ERP consultants that SAP, for all its modules and options (necessary to cover the complexity of multi-unit internation business organizations), is probably 3x the amount of source code as Peoplesoft.

"I know there are already common data models for ERP systems and the common business processes are already defined."

Really? How do you "know" all that? Even at a high level, the very basics of commercial accounting practices are ill defined, subject to constant regulatory change, and likely to be getting a huge amount of revision in coming months, thanks to post-credit crash regulation initiatives. Just in the U.S., FASB continues to try to define basic accounting concepts and practices for U.S. firms, and yet fails to reconcile U.S. practices to those promulgated by IASB. And you can't suppose that process frameworks like ISO 9000 provide an actionable model, however abstract, upon which you could actually code some ERP system product.

In fact, the very lack of universal accounting standards and business practices has forced successful ERP vendors to both restrict their offerings to supporting their own 'best practices' files, and to still, even with such restrictions, support a huge number of process and accounting structure variables, through complicated parameterized setup logic. Fully 50% or more of the initial cost of installing most commercial ERP packages is paid for consultants to properly select and configure the thousands of operational choices coded into the ERP packages they are selling, to configure them for use by a given client company, doing business in a given legal and accounting environment.

So, many people have already taken a run at "simplified" ERP systems, trying to write uncomplicated packages for small businesses. Generally, the functions are so limited that even the basic accounting functions are not particularly useful, outside of the limited scope of the product's home market. As an example, there are more than 50,000 sales tax authorities in North America, so that companies selling inventory product nationwide in the U.S. and NAFTA areas generally require annual tax rate updates to their software, to stay abreast of changing taxation for their invoice modules. Are you, as a single developer, prepared to supply all that, in perpetuity? If not, your system could quickly build insurmountable tax problems for your clients, with thousands of tax jurisdictions in which they would be expected to remit sales tax. Ultimately, your client's liability becomes yours, if not in court proceedings directed against you for faulty software, then when they fail to renew your licenses and support contracts in order to move to better functioning and more broadly supported commercial ERP systems.

But good luck with your project, should you decide to press ahead.
posted by paulsc at 11:21 PM on June 10

I'm not entirely sure from reading your question, but it sounds like you have a client for whom you're building this for.

Ask them. If they're paying your bills, they're the only one that matters. Their needs are almost certainly typical of their industry.

And while yes, this is generally done with the resources of billions of dollars, don't let that dissuade you. I have a good friend who is making money hand over fist developing a similar thing for a niche market. It meets the niche so well that going with a Big Name isn't even a consideration.
posted by Ookseer at 11:37 PM on June 10 [1 favorite has favorites]

The answers so far clearly express the way I'm thinking about this problem.

In one hand building a full blown ERP software package takes a lot of resources and know-how. There are a lot of existent ERP solutions out there, some of them are even open source. There are still extra complications specific to each country like the tax regulations. So why do it all over again?

On the other hand, if one is working for a niche market with specific problems in mind, and the customer wants to avoid the big name / high cost / high complexity solutions, why not do it? The customer is paying for a specific project, so let them have one.

Indeed my customer represents a niche market, and their needs are not overcomplicated. The total number of end users will be between 10 and 15 persons. My approach is to build want they want, feature by feature, but if I'm doing it, I don't want to grow the product into the wrong direction. I don't want to find out two years from now, that I cannot grow the product anymore because of some stupid mistake I did today.

If people already thought about the common ERP problems, I want to know about it and follow their steps as I build feature by feature what my customer wants. (Why open doors that are already open?)

So, where to find out about alread known common ERP problems and their solutions?
posted by dfreire at 3:42 AM on June 11

"... So, where to find out about alread known common ERP problems and their solutions?
posted by dfreire at 6:42 AM on June 11 [+] [!]

Most, if not the majority of commercial ERP systems began as GL/AR/AP packages. That's because the core accounting functionality is typically called constantly by other modules, such as inventory control, purchasing, forecasting, job costing, etc. A feature rich, fully parameterized accounting base is the "guts" of a commercially viable ERP system, so you can begin your comparison of competitive solutions there - the more you know about the accounting implementation of any particular package, the better you will understand its philosophy and broad applicability.

But accounting is probably the only thing "common" to all ERP systems. Inventory management is frequently a focus, perhaps for 70% of the several hundred commercial packages I've looked at personally, but there are many ERP systems for industries such as the construction business where "inventory" doesn't actually exist, and the system is used as a job cost tracking/disbursement/change order tracking system. Because the market is already so broad, there isn't, as far as I am aware, a comprehensive comparative resource for existing packages, but there are a few consultancies who publish there own limited comparisons of some major packages, sometimes charging for the full research they claim to have assembled. You can also start with lists of major ERP vendors, and do your own research and feature comparison. ERPGenie is a heavily SAP-centric Web portal for ERP consultants, but you might register there, look over their list of readings, books and seminars, and lurk the forums for pointers, as well.
posted by paulsc at 5:56 AM on June 11 [1 favorite has favorites]

"... On the other hand, if one is working for a niche market with specific problems in mind, and the customer wants to avoid the big name / high cost / high complexity solutions, why not do it? The customer is paying for a specific project, so let them have one. ..."

I've commented on the reasons why an enterprise might go with a well known commercial ERP package, even if that requires a fair amount of business process re-engineering previously. I stand by those opinions now, even more, with an additional 3 or so years of experience.

Not to say that there aren't significant SAP/Oracle/Baan implementation failures reported fairly often. I've personally seen a number of such projects go awry, or, even better, been called in to work on projects in trouble in implementation. The #1 reason for this is customization based on claims by the target business that "their way" is the "right way" and that software has to incorporate/accomodate their particular approach to some business process/method that is "unique," or that they want a custom solution because of the "bloat" of commercial solutions like SAP/Oracle/Baan etc. The major vendors have long had "lite" packages for smaller sized businesses, where the installation is "canned" with most of the underlying functionality masked off by option pre-selection templates that rapidly configure the software for simplified operation by smaller organizations. MySAP is SAP's entry, Genesis was the J.D. Edwards entry level package, etc.

Too often, I find that business management that is insisting on "custom" software solutions is simply unable or unwilling to fully understand or process engineer their methods. I suppose there are some genius entrepeneurs out there, who can rightly claim to be special snowflakes whose ideas and methods deserve custom solutions, but I've yet to run into one such.

Therefore, my wish for your good luck in pursuing this. You'll need it.
posted by paulsc at 6:30 AM on June 11 [1 favorite has favorites]