There are two polarized types of ERP software - the one that facilitates its enterprise customers' success, and the other one that creates jobs for the society at the expense of its enterprise customers.

The quality of an ERP software will eventually be precisely reflected to its customers' profit and loss financial reports, as well as balance sheets in several instances as reported in these, these, these, and this stories. It also heavily impacts on its producer's operation costs, dynamics of growth, industry image, and the morale of R&D, customer supporting, and PR teams.

This is rule number one a developer must follow when he or she is designing a high quality ERP system: building a simple software rather than the opposite - a complicated one. A simple ERP software adapts to enterprises' businesses, runs at high speed in mediocre hardware, can be easily maintained, customized, expanded, and quickly ported to multiple environments, while a complicated one is like a gigantic dinosaur: It crawls even on top-notch infrastructure; It does not listen to people's orders and refuses to be tamed; It consumes much energy.

A decent ERP software must be designed to possess the following traits:

The system can be easily expanded, customized, and maintained.

This trait is the synonym of software flexibility and maintainability, which directly affects the productivity of IT personnels, integrators, and consultants.

The only skills a developer needs to possess in order to expand, customize, and maintain PostERP are: PostgreSQL and elementary accounting concept. None of C++, Java, Javascript, C#, .NET, Node.js, HTML, CSS, Delphi, the proprietary COBOL grade programing language, etc. skills is required.

The productivity of PostERP developers is second to none: Equipped with the aforementioned two skills, any PostERP developer creates a CRUD screen, report, or business logic processor in minutes, not days or even weeks. Technical people's unprecedented high throughput enables IT personnel and consultants to provide the highest service quality to their users because they always swiftly respond to their customers' service requests.

The server program runs at high speed.

As the number of clients grows and the complexity of business logic increases, ERP server's response time can become an issue. An crawling ERP server wastes its users' precious time and hurts enterprise customers' performances.

The information systems industry has historical delusional hypothesis suggesting "the bigger a software is, the more powerful it is." Every time I see an ERP system run in a large computer room, I draw my conclusion from that scenery that that ERP server program is poorly designed and it continuously costs its user more money than it should.

Because ERP server programs crawl, some ERP vendors require its customers to invest top-notch hardware to host their slow moving server programs. However, because the major bottleneck of the system's overall performance often lies in ERP software instead of hardware, ERP enterprise users investing money on better hardware helps improving ERP systems' response times a little, but not much.

Take the well-known ERP software as an counter example of designing a decent ERP software. Trying to boost its ERP software slow performance, the vendor added yet one more layer of its so-called "in-memory database" to its already complicated server elements only to make the bloated new server consume even more resources and to add system management and diagnosis difficulties.

It is a common sense that these money-wasting investments improve server program's running speed little to none. The bloated in-memory database only complicates the already crawling and complicated interweaving server program, deteriorates its overall performance. Besides, the more complicated a system is, the more hidden bugs it has. . An even more complicated system in essence brings more drawbacks than benefits to its customers, while it asks its customers to pay the bill for its "innovative" design.

The key question arises: What makes that software server run so slowly?

The answer to this question is because it process business logics in their application servers. Such ERP system is doomed to crawl and consumes networking bandwidth between application server and DBMS. There is no cure for such architecture. This is how such system works:

Having received a request for MRP run from a client program, the application server program first pulls in data set from DBMS. The DBMS then reads database tables and returns some or all records to application program depending on how the application program is designed. The application program then iterates this data set. For each iteration, the application program pulls in yet more data set from other tables via DBMS and perhaps in turn iterates these data set. Such cascade data set retrieval repeats itself for multiple times. Processing data in this way is apparently very inefficient:

• Application server program pulls in much data set from DBMS. Therefore it requires much RAM and CPU power.
• Because large amount of data are sent from DBMS to application server, the system demands an infrastructure capable of handling heavy traffic between application server and DBMS if these two components do not run in the same hardware.
• Processing data set in application server is often far more inefficient than processing data set in DBMS. The reason for this argument is simple - all modern DBMS', PostgreSQL in particular, highly optimize their data set processing activities. They just know how, when, and if data set should be read in and written out with lowest costs in terms of CPU, RAM, and storage, while application server programs have little to no control over these resources.

Simplicity is the best. It is futile for anyone trying to solve simple problems by introducing large number of complicated devices. The only productive way of designing a high performance ERP server is making the server act as a simple delegate between clients and DBMS. We follow these straightforward guidelines when designing PostERP server so that it runs at unbeatable lightening high speed:

1. PostERP processes business logics such as MRP run, financial book closing, and payroll calculation, exclusively in DBMS - PostgreSQL.
2. Upon the receiption of each request from clients, PostERP server performs authentication and privilege checks.
3. PostERP server looks up its cache for the possible result. If the result is found in its cache, PostERP server simply responds the result to the requesting client without second thought.
4. If PostERP server does not find the result in its cache, it forwards the request to the world's most advanced open source DBMS, PostgreSQL, and then waits for the result. Having received the result from PostgreSQL, PostERP server immediately sends the result back to the requesting client.

This is the exact simple role PostERP server plays, no more and no less. PostERP server performs little calculation. Its architecture is straightforward and simple. It therefore is capable of running at lightening high speed in a VPS with only 1GB RAM, and responding to massive number of clients within very short period of time.

PostERP's simple and straightforward architecture also brings a huge bonus to its users - it introduces little to no management work to its system administrators. PostERP users simply start the server program and leave it alone, and focus solely on designing PostgreSQL database to satisfy their colleagues' requirements.

The client consumes minimal resources.

PostERP client programs have two flavors:

cloud

It comprises only one Javascript, which is 700KB in size as of the time this article is written, and a few small CSS files. This client program runs in all major modern browsers from PC, Apple, and smart cell phone, any time and anywhere.

desktop

It consists of only one executable file tc.exe 1.8MB in size. This client program alone runs directly in Windows without any .DLL file.

Both types of PostERP client programs require zero deployment effort.

The system provides simple yet efficient API.

It goes without saying that an decent ERP software is capable of interacting with outside world in simple, efficient, and secured way. For productivity consideration, technical people want to avoid complicated proprietary interface mechanism that works with Windows ActiveX, which comes with steep learning curve and heavily requires programmers' trial-and-error efforts.

Once properly and simply configured, PostERP server automatically provides RESTful API to outside world and performs CRUD on any specified database tables as called by peripheral devices such as IoT and those in MES. It will provide the publish-subscribe style of API very soon.

PostERP client program allows all data set retrieved by its user from database to be saved to users' local storages.

The accounting module is elegantly designed.

Enterprises always want to avoid complicated accounting modules and to stay away from abyss.

The design of accounting journal in PostERP is simple, clean, powerful, flexible, innovative. Its accounting module comprises about 7 database tables. Because of its simplicity, journal can be easily accessed and seamlessly integrated by all other modules. Developers easily generate (post) accounting journal from the transactions initiated by all other modules.

PostERP's accounting journal is an unprecedented innovation. The journal accommodates on a single screen all the key transaction details in addition to traditional double-entry journal system. Many monetary reports can be generated by reading only PostERP journal. For examples,

• Sales report containing columns customer#, item#, and serial# in addition to amount.
• Purchase receiving report containing columns supplier#, item#, serial#, and bin# or warehouse#, in addition to amount.

Given the clean, flexible, and simple accounting journal module, PostERP's users close their financial books with just two or so steps by executing a few (two, as of the time this article is written) business logic processors (i.e., PostgreSQL functions). As for daily business activities, PostERP always instantly and perpetually posts each and every monetary transaction to accounting journal, meaning that the accounting module always gives up-to-date information:

• The existing inventory cost and quantity of each item stored in each warehouse/bin/cabinet/box/drawer is up-to-date.
• The current sales cost and purchase cost of each item is up-to-date.
• The present account receivable and payable is up-to-date.

Given PostERP, the management can always access to their business performance information at any time point. There is absolutely no need for them to wait until financial book being closed next month.

PostERP leaves few daily and month end jobs to accounting personnels. Accounting personnels simply harvest any time they want the fruits grown by their colleagues working in other departments. (my thoughtful reminding to accounting personnels: Never let your boss know this fact!)

Users can easily manage data.

To retrieve data set from database and display them to a screen, PostERP users set query conditions on any fields. Then they can scroll back and forth the retrieved records and edit each field or delete the focused record. All pulled-in records can be exported to user's local storage.

The client software's user interface has simple and uniform look.

It takes time for a user to be accustomed to a new client software's interface. It is annoying to work on a client software having heterogeneous looks among various CRUD screens, tool buttons, dialogs, and pop-up windows, etc.

Nearly all PostERP's CRUD screens, tool buttons, dialogs, and pop-up windows, etc. have the same looking.

The number of screens is minimal.

For working efficiency consideration, users do not want to open multiple screens and jump back and forth just in order to get a simple job done. PostERP users spend most of their time working on a single screen during office hours. This is why PostERP contains only a few screens.

How does PostERP realize this? Some explanations follow:

• Each screen accommodates all information required by both users and the system itself.
• Related reports are attached to screen. For example, all sales reports can be obtained by the user working on sales screen. As such, PostERP has few menu items pointing to reports.
• Related business logic processors are attached to screen. For example, a user working on journal screen can close financial book by running a PostgreSQL function attached to journal screen. As such, PostERP has no menu item pointing to business logic processor.
• Related data quick views, a simpler format and design than reports, are attached to related screens.