On Friday, March 18, 2016 at 9:00:23 AM UTC+1, Jianfeng Wang wrote:
I speak here as the (only) IT guy in a SME. I think that my experiences will give you some perspective. The decision to implement ADempiere was taken by management (I'm migrating to iDempiere), to replace a very expensive custom job from before I joined the company.
The company I work with is basically an importer, manufacturer and supplier of precision mechanical transmission gearboxes. The kind of parts that go into machine tools that do precision work. It's a company that has some rather unusual needs for an ERP system:
- Number of users: 1-3. Users are expected to handle everything (no dedicated sales/warehouse/supply/etc guys)
- HUGE number of possible products: since there's no standardization in the world of servomotors, each product will need to have to be customized to fit our customer's choice of servomotor. This means that - each product will have nearly unlimited variants, and a new order will most likely require adding a new product, with all the overhead that includes. (It's possible to alleviate the pain by using attributes to handle part of this variation. This, however, comes with it's own set of challenges.) Most of these products will be used exactly once, unless the customer decides to order more, but it's unlikely that other customers will ask for the same exact configuration.
- Low or no stock levels: Since products are heavily customized, maintaining stock levels is not viable. They are built just in time by our suppliers, or partially assembled parts might be bought, from one supplier and others might be machined locally. MRP is a pipe dream.
- (Light) Manufacturing required: Some of our designs are assembled here instead of built to order by our suppliers. Sometimes, products are bought and customized here instead of fully assembled at the factories where we outsource manufacturing. Sometimes products bought for an operation that didn't pan out are disassembled and used for parts for other products.
- Accounting is outsourced: Accounting is handled by a different company that deals with all the intricacies of our tax system. As such, accounting is not handled bu the ERP, and even if it's necessary for other parts to work, users don't want to input the necessary data for even a mock accounting scheme to work.
- Company is ISO9001 certified, and standard procedures mandates by the certification predate ERP use in the company. As such, the workflows that must exist (and the paperwork that must be produced) is not optimal for automated handling. The solution is to "fake it out" ex post facto and produce the necessary paperwork so ISO 9001 audits show that we still comply to the certified processes and workflows.
- Very informal handling of the sales process: Offers are first negotiated outside the system, and only after the initial negotiation, entered into the system. The reason for this is that this negotiation is mostly a matter of gathering requirements, that, as in the software engineering world, are often not provided straight away, mischaracterized by the customer, or just plain erroneous. As such, if they were entered in the system, they would require creating products in the system that would never ever be sold.
In our case, iDempiere is really overkill. It produces great overheads. It requires complex training of the users and onsite support. However, alternatives are found lacking in some of the areas above. Built to order software would probably serve us better, except that management doesn't understand the sunk costs fallacy.
Now, not everything is hopeless. iDempiere is really extensible, and now that I had to delve in it's innards, it provides a solid foundation for adding built to order processes. However, one must be careful not to dig oneself in a hole by doing so, and cut oneself from future updates and bugfixes. Modifications should be decoupled from the core, modifications to core tables are be verboten. Changes to built in processes are not recommended, and building parallel processes that do what the existing processes do, but slightly differently should be done with utmost care, because it can be a maintenance nightmare.
IMHO one problem that is also a great strength with the *piere family of ERPs is that metadata is mixed with data. This lets you change the system structure from inside the system, and allows to do rapid prototyping, but results in both problematic maintenance and upgrades if you alter the core database too much. It also suffers from the inner platform effect (https://en.wikipedia.org/wiki/Inner-platform_effect) because of this, in that in order to maintain as much database independence as possible, and to abstract as much database operation as possible, it replicates many of the features of a database management system.
Oh, and please, remember that as an open source product, strength comes by sharing your work with others. Try to get your generally applicable changes upstreamed. Avoid doing private forks. In my case, the changes required are so unique that they're hard to decouple from the base assumptions of the company I work for, but I still try to submit as much as possible (and as much as I'm allowed - problem being that management doesn't seem to understand that sharing the maintenance burden with others by sharing your work is quite cost effective, even if it means that you must overengineer your solutions so they work in cases more general than the one that our company specifically needs).