But I also don’t understand why it’s sometimes hated like here. I’ve been in several evaluations for ERP systems where it won against plenty of competitors.
It really comes down to ease of use. For instance, I can get excel exports off of the financial reports I run from SAP. But the report takes an hour to run, and only specific subsections are exportable. The amount of data its parsing is maybe about 100k rows.
In comparison, I have worked with a custom Oracle ERP built circa 2005 - this is what I was directly comparing SAP to. It had easily 10x the amount of data as the SAP system I work with now, and was not only managing inventory for 100+ stores across multiple countries, but was dynamically pricing and shipping them from the drop-shipper with the best price. Longest time for a report parsing 1mil rows was 10 minutes (via Quicksight - and that was dynamic draw, cached was drastically quicker).
Even the oldest system I worked with, a COBOL based system called AMS, could pull reports quicker than the SAP I’m forced to use now.
In comparison to Nav - any report is laid out fully exportable in under five minutes, usually less. If I have proper access in Nav, I can go straight to the core tables within the interface itself. There’s drag and drop capability. ODBC connections are a breeze - every version of SAP I’ve worked with has had them locked down (this may be an admin issue rather than architecture, I admit here).
That being said, each install of SAP is its own beast - I’ve heard the system is extremely customizable, and it’s likely my current workplace is on an older version (because holy fuck does the interface suck - who the fuck thought a clock icon was good choice to run a report?). And I’ve only used it as an analyst / end-user.
But if I had the chance to never work with it again, I’d jump at it in a heartbeat.
If you’re parsing 100k entries for an hour, I can tell you something is very wrong. Over my career I took care of lots of SAP systems (from Basis perspective) which ranged from small ERPs/EWMs with only few hundreds of GBs of data up to massive Business Warehouse systems with tens of terabytes.
And 100k entries really shouldn’t take that much, because that’s nothing. But of course it’s possible. SAP needs administration… You need to take care of the system, you need to take care of the underlying database. You need to be sure that you’re following proper recommendations to ensure good performance. And then there’s also a question what exactly was running slowly. SAP is usually heavily modified by custom coding and while the end user might not be aware which applications are “SAP standard” and which are custom, it makes a lot of difference. It’s easy for in-house developers to customize a program only for the program to work badly.
My point is - SAP can work perfectly fine as long as it’s maintained by experienced people and if the custom development is done properly. But companies love to cut corners and their employees don’t even know if the problematic report is created by SAP, or by some random developer with lack of experience. To the end user, it’s always SAP that’s bad.
It really comes down to ease of use. For instance, I can get excel exports off of the financial reports I run from SAP. But the report takes an hour to run, and only specific subsections are exportable. The amount of data its parsing is maybe about 100k rows.
In comparison, I have worked with a custom Oracle ERP built circa 2005 - this is what I was directly comparing SAP to. It had easily 10x the amount of data as the SAP system I work with now, and was not only managing inventory for 100+ stores across multiple countries, but was dynamically pricing and shipping them from the drop-shipper with the best price. Longest time for a report parsing 1mil rows was 10 minutes (via Quicksight - and that was dynamic draw, cached was drastically quicker).
Even the oldest system I worked with, a COBOL based system called AMS, could pull reports quicker than the SAP I’m forced to use now.
In comparison to Nav - any report is laid out fully exportable in under five minutes, usually less. If I have proper access in Nav, I can go straight to the core tables within the interface itself. There’s drag and drop capability. ODBC connections are a breeze - every version of SAP I’ve worked with has had them locked down (this may be an admin issue rather than architecture, I admit here).
That being said, each install of SAP is its own beast - I’ve heard the system is extremely customizable, and it’s likely my current workplace is on an older version (because holy fuck does the interface suck - who the fuck thought a clock icon was good choice to run a report?). And I’ve only used it as an analyst / end-user.
But if I had the chance to never work with it again, I’d jump at it in a heartbeat.
If you’re parsing 100k entries for an hour, I can tell you something is very wrong. Over my career I took care of lots of SAP systems (from Basis perspective) which ranged from small ERPs/EWMs with only few hundreds of GBs of data up to massive Business Warehouse systems with tens of terabytes.
And 100k entries really shouldn’t take that much, because that’s nothing. But of course it’s possible. SAP needs administration… You need to take care of the system, you need to take care of the underlying database. You need to be sure that you’re following proper recommendations to ensure good performance. And then there’s also a question what exactly was running slowly. SAP is usually heavily modified by custom coding and while the end user might not be aware which applications are “SAP standard” and which are custom, it makes a lot of difference. It’s easy for in-house developers to customize a program only for the program to work badly.
My point is - SAP can work perfectly fine as long as it’s maintained by experienced people and if the custom development is done properly. But companies love to cut corners and their employees don’t even know if the problematic report is created by SAP, or by some random developer with lack of experience. To the end user, it’s always SAP that’s bad.