Comment by atomic_cattlepr

ERP implementer for the past 20 years. I'm an operations specialist rather than a manufacturing specialist, but do have manufacturing clients whose systems I have helped implement and continue to support alongside our manufacturing specialists.

I will preface this by saying that my initial thoughts are based solely on the website and documentation (which is fairly sparse and includes few screen shots or examples of how the software is actually used). I did not and probably will not* sign up or install this software to review further, so I'll fully admit that I'm probably missing a lot and likely not giving a completely fair review.

My first impression, looking at the documentation for the system and how some of the actual ERP-related functionality is described, is that barbinbrad is an expert in software development with a lot of experience writing software to support ERP systems, but has a fairly narrow understanding of how all of the functions of an ERP system are supposed to work. To use a tired old analogy: this can be likened to a highly-skilled heavy-duty mechanic and a veteran long-haul truck driver deciding to start their own trucking business. Between the two of them, they know a ton about the mechanics of driving and maintaining large tractor-trailors and may even know how to keep proper driving and service logs and how to train apprentice mechanics and new drivers. But their knowledge on all the other minutia of running a trucking business is just enough to give them false confidence that they know the industry. Without seeking outside help, many of these startups fail because of mistakes made on these details.

There is a lot of detail on how to set up the technical parts of the system (there are definitely two things that are abundantly clear: the database back-end is postgres and the software is open source), there is some good developer-related information on API calls and such. But the documentation on how it all works is very sparse and the functionality that is described appears very rudimentary. Accounting functionality is very simplistic (limited chart of accounts definition, unclear link between subledgers and the G/L, no apparent EFT functionality, limited multicurrency/revaluation capabilities). Similarly, inventory, purchasing, and sales appear to be similar in capability to a basic Quickbooks system. A couple of more advanced manufacturing-specific features like MRP and routing/scheduling seem to exist, but MRP will only "suggest" order - users still have to enter them manually in the system, and it is unclear whether there is any linkage with general inventory planning or sales forecasts. Basically, it looks like the software can build a BOM, and it can help run most of the assembly steps for that BOM, complete with some very strong traceability and visual cues, but all of the other business functions surrounding that BOM are very limited.

To be clear, this is not meant as a direct criticism of barbinbrad or the software itself. The software has potential, and barbinbrad appears to have a lot of experience working on manufacturing ERP systems. What is needed is more guidance from people with the expertise on the "other side of the keyboard". Preferably people who have worked in ERP systems across multiple manufacturing industries.

This a huge example of a classic problem that plagues many (if not most) "non-tech"* open source projects. Developers who are immersed in a specific type of software can see what it is they're developing and get a very good idea of what the software does and how it works (according to the specs that they've been working on). So they go about building what they see as the "better version" of what they've worked on before. In the process, they often do solve some of the glaring individual problems they've encountered in the past, but they do so without understanding the bigger picture of what the system as a whole needs to do. ERP software especially is hard, because it is very complicated, used in many different ways (even by companies in the same industry) and have to support so many different facets of a business. The experts are not developers. They are accountants, operations managers, procurement and warehouse managers, production managers, payroll managers, and the C-Level executives who consume the information that ERP systems spit out. The people guiding development have to have expertise in these areas, not the developers. And in the open source world, this is where the subject-matter expertise is often lacking.

(couple of footnotes): I'm not prepared to enter my credit card number to try it out, don't have the time to install it in my own environment just for a review, and already am a bit annoyed that I had to enter my work e-mail address just to get to the point where I realized I'd have to do one of those two things to get anywhere.

*By "non-tech", I mean that the audience for which the project is intended is a non-technical audience - ERP systems, despite being very sophisticated software with a lot of server infrastructure involved, are systems meant to serve very non-technical people.