Why?
Why ERP Systems Must be Hacked
ERP systems seemed like a good idea at the time.
Enterprise Resource Planning is a fancy way of describing a monolithic computer system to run an entire business from top to bottom, from raw material to finished product. The advantage stems, in part, from the fact that all the data involved in running a business is available within a single system and can be leveraged to make rational decisions. ERP systems expose relationships between disparate parts of the business that might not even occur to managers without access to such a rich source of data.
As it has turned out, ERP systems have not delivered on these promises. One problem is the requirement not only that the system support the entire enterprise, it must potentially support every enterprise. It has to be so generic in design that it could be used in a wide variety of businesses. In order to achieve this, it has to be customizable — and massively over-engineered. Any particular implementation of an ERP was unlikely to use every part of the system, since different businesses have different needs.
As a result, the database schemas for these systems consist of severely de-normalized tables, often with a hundred or more columns. Many, if not most, of these columns go unused.
I have yet to see an ERP system that uses the principle of command/query separation. In order to accommodate the fact that reporting must be done on the transaction database, further de-normalization becomes necessary. Aggregate entities must duplicate data from their parents, leaving the door open to data quality issues.
Because ERP systems must be customizable, it is common to see database schema abominations like columns labeled “misc_data_1”, “misc_data_2”, “misc_data_3”, etc. The schema looks suspiciously like data structures from an old COBOL application. The end result is that the application requires additional complexity to manage data integrity. The system grows larger and larger, and increasingly fragile.
This is all theoretical, though. Sub-optimal design doesn’t necessarily translate into failed software. The proof is in the real-world practical application of these systems.
The real-world has spoken: ERP implementations fail on a spectacular scale. One estimate has revealed that only one-third of attempted ERP installations are ever fully implemented. Many are abandoned altogether, while many more are only utilized partially and never provide a return on the investment.
Consulting companies make a fortune feeding the ERP beast. It is difficult to imagine that these consultants are unaware that when they agree to implement an ERP, in all likelihood the effort will fail. Imagine a surgeon who continues to perform an operation that fails over 60 percent of the time…would he keep his license?
I’m not here to lecture on the ethics of ERP system economics, though. I am merely providing the background needed to understand the work I often find myself doing – hacking ERP systems.
ERP systems must be hacked because there is almost always a gap between what it promises and what it delivers. It is possible for an independent developer to bridge that gap, but the ERP design does not make it easy in most cases.
The challenges are different for each ERP. If an undocumented and poorly implemented API is available, the developer should count himself lucky. Much of the time, neither the company that sells the system, nor the consultant that implements it, is particularly interested in exposing its inner workings to outsiders. There is more money to be made keeping these secrets within the family.
Sometimes there is an elegant solution to interfacing with an ERP system, but often it is an ugly hack. There is little that can be done about this, short of replacing the system with another, slightly less poorly designed system that will certainly come with a whole new set of issues to be dealt with.
Or, better yet, designing a new system from the ground up whose architecture is based on the actual business. Unfortunately, most companies simply don’t have the resources to do this.
So, I am left with writing some ugly code and covering it with enough layers of abstraction that I will, hopefully, never have to look at it again.
It’s a living.
