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:
This trait is the synonym of software flexibility and maintainability, which directly affects the productivity of IT personnels, integrators, and consultants.
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.
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 SAP as an counter example of designing a decent ERP software. Trying to boost its R/3 server's slow running pace, the SAP 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. Web searching key words "HANA deadlock" reveals more information regarding these troubles.
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 R/3 and HANA run so slowly?
The answer to this question is because R/3 and HANA 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:
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:
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.
PostERP client programs have two flavors:
Both types of PostERP client programs require zero deployment effort.
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 mechanism like SAP's interface 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.
Enterprises always want to avoid complicated accounting modules and to stay away from such abyss as this: Financial reporting — Prior to go-live it took National Grid four days to close its financial books. Following go-live the close took 45 days.
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,
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:
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!)
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.
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: