Posts by Simplicity is good 13 publicly visible posts • joined 18 Dec 2019
Does it justify to buy an ERP software that is so complicated that managers and directors must spend hours or days to learn, and to forget in a week, the procedure of getting monthly analytic figures from that ERP software?
Is it possible that the ERP software in question just cannot give Elsie the correct and up-to-date day-to-day data and she is therefore forced to manually compile the data with LibreOffice Calc?
Issuing from my HP EliteDesk 705 G3 SFF PC the command lspci -v produces the following messages:
-----BEGIN-----
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wani [Radeon R5/R6/R7 Graphics] (rev e1) (prog-if 00 [VGA controller])
DeviceName: Onboard IGD
Subsystem: Hewlett-Packard Company Wani [Radeon R5/R6/R7 Graphics]
Flags: bus master, fast devsel, latency 0, IRQ 44, IOMMU group 0
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at e0000000 (64-bit, prefetchable) [size=8M]
I/O ports at 2000 [size=256]
Memory at e0c00000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: amdgpu
Kernel modules: amdgpu
-----END-----
After I had upgraded from kernel 6.7.5 to kernel 6.8.8, Linux randomly crashed causing my monitor to black out and CPU fan to turn at highest possible speed. The only way I could cool down my CPU was turning off its power.
I choose to stay with kernel 6.7.5 becasue I guess the problem lies in the video card driver in newer kernels.
Skilled developers are not enough.
I doubt all these governments are using paper or spreadsheets software to manually process their data. Instead, they most likely all have applications written in COBOL or the like running on mainframes or mini computers.
It's not quite cost effective in terms of time and money for in-house IT staffs to rewrite legacy applications in another "modern" programming language.
They will have a better chance of success with a decent low-code ERP applications development and execution framework.
Even better would be if the governments have the option to obtain the source code of the framework so they could completely cut ties with the ERP vendor if they want to.
Governments should do everything they can to avoid being locked in by enterprises.
'it will go for a "fit to standard" principle by which it will "embrace modern technologies, methodologies, and changes rather than merely modifying the solution to fit with their current ways of working."'
Decision makers have quickly learned from the ERP software vender's salesmen these many buzzwords which can be translated into, "Your organization is supposed to adapt to our ERP software rather than our software will be developed and customized to adapt to your process."
What large private enterprises and public organizations really need is a low-code ERP application development and execution framework that is simple enough to allow IT engineers to master and start developing ERP applications in the shortest possible time.
These organizations should build their own IT teams to permanently customize ERP applications to support their ongoing operational changes.
The quality of service from outsiders will never be better than the quality of service from an organization's own IT staff with proficient ERP skills.
I have always advocated for IT staff in large organizations to implement information systems from the ground up on a high-quality "ERP development and execution framework."
This strategy comes with premise.
1. A bunch of code is not even an ERP framework, but just a pile of software programs, such as those so-called "big ERP" written in Python or Java, that only a large number of experts can possibly maintain or extend.
2. The recipe for failure is to buy a German-made ERP framework that is so complex that few people in the world fully understand it. Even for a large number of programmers, building applications on this framework using ABAP, cousin of COBOL, would be nearly impossible within ten years. When I looked at IDES about ten years ago, its database contained 12,000 (obsolete? contradicting?) tables if my memory serves.
If these IT decision makers and government officials adopted PostgreSQL and the pay-for-value strategy known as a "zero-failure ERP implementation strategy," citizens would not have to bear this financial loss.
1. Let your IT staff implement your project.
2. You hire only one consultant to train your IT staff in all the necessary skills to implement your project on top of a quality ERP development and execution framework. Try to limit the total training days to 5, unless your IT staff does not have PostgreSQL, basic accounting, and large database design skills.
3. If the majority of your IT staff or end-users who are mainly civil servants are not satisfied with the above ERP software during the implementation process, you will not buy that ERP.
Last time when I reiterated on my mobile phone the importance of IT security to an officer serving in IT department of Taiwan military and defense ministry and mentioned that rumor circulates that "Windowz 10 is a spyware or malware", he replied, "We purchased special edition of Windows."
"We now contorted our business processes and organizational structures until they fit ERP's inbuilt, mainframe era business rules and processes."
Your convoluted business process gives them the opportunity to announce to the world: "We have yet another happy customer". If you didn't convolute your process and abandoned the unusable software, you would be verdicted guilty for "being not abiding by our universal best practice".
"Should have stayed with IBM. And, yeah, they suck too."
I coded IBM MVS JCL and understand what you are saying.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
