|
I led the project that replaced SAP at Tesla in 2012 (as an internal IT employee). Explaining that in detail warrants a full article, book, or movie, but in summary the project was successful, took 13 months start to finish, and took a few years off my life. Prior to that I was an ERP technical consultant. I've had the opportunity to work with many ERP systems at a deep technical level, on both sides of an implementation: the old system a company was moving off of, and the new system I was implementing. I'm neither an advocate for, nor detractor of, any particular ERP system. Each offering has things it does well, and each has pain points. Unfortunately a lot of people cargo-cult their particular system of choice and lose objectivity. Software is simply a tool and is far less important than the implementation and execution. A few SAP aspects that stood out to me from a technical perspective: 1. You are virtually guaranteed to have an existing capability available for any arbitrary business process need
2. The system architecture facilitates efficient data processing. Tables, forms, and reports tend to be narrow slices of an overall business process, and thus can reduce contention and concurrency problems. Batch jobs are utilized for background processing.
3. The user interface is lightweight and very performant over remote connections (e.g. VPN). Similar to older green-screen systems, data entry can be very fast for experienced users and does not rely on the mouse.
4. The API options for enterprise application integration are good
A few SAP pain points I observed: 1. The surface area and complexity to match the capability is crushing. Tesla's relatively vanilla SAP environment had 10,000+ reports and T-Codes in it, of which I would guess less than 1% were actively in use.
2. Optimizing the architecture for scalability came at the expense of the user experience. One would often need to perform several tasks in order to answer a single need. For example, I would observe users exporting several reports, each of which provided a narrow slice of the information, and then combine the dumps in Excel to get the answer they sought.
* For ERPs and complex systems in general:* 1. It is very difficult to find subject matter experts who can deeply understand what a complex system offers out of the box, and successfully select the optimal capabilities and implement them for business processes. Or, in the case of true functional gaps, can modify and extend the system without creating a mess.
2. It is vital that a company retains the people who have the institutional history of a system and its modifications. Many end up with a revolving door of consultants, each of whom may be an expert in the vanilla product but has no company-specific context.
3. Clarity and completeness are at odds with one another. As you attempt to drive a system or specification toward completeness, clarity and understandability will diminish.
4. The longer an ERP system has been around, the more likely it will accumulate legacy and historical impediments. If a product aspect is working and widely deployed it tends not to be changed or updated to modern patterns or technology. An example in SAP is the cluster table concept, which as I recall from the lore some years ago was a workaround because SAP needed more columns per table than Oracle allowed. Cluster tables do not spark joy in data migration and egress when ABAP is not a feasible option.
5. Also for long-lived ERP systems, from the user experience standpoint, as these systems incrementally evolve over time the standardization and consistency of behavior across modules and application areas tends to fade or diverge. AS I recall with SAP for example, some transaction forms and reports can export to Excel, while many others do not: the feature was not or could not be added as part of the architectural core but was instead bolted on later to limited areas. A young ERP typically builds this in as standard core feature which is available on all forms in the product.
|