| Welcome to my world:) I'm a software dev and always worked in or around sap (~13years). Sap's secret sauce was understanding that different companies have mostly the same needs. All have employees that need paying and maybe shifts to be tracked. All generate invoices. All buy stuff from suppliers, etc. So they built different solutions (HR/FI/etc.) For those needs. All running on the same technical platform with its own programming language: ABAP. All domain code is ABAP and everything is readable, you can even debug code that SAP wrote years ago but (generally) you're not allowed to change it. And it's full of comments in German so good luck :) For medium to large companies it's a no brainer to use SAP so most do. For example Sap keeps the client's systems compliant with new laws. Say some country changes laws on how employees pay taxes, sap updates the code or tells their clients what's needed to update the systems. Companies that have been around for a few years, most likely they already have SAP so makes no sense to shift to something else. SAP's ERP code is also quite generic. Tons of configurations are possible in any module. E.g. you may have employees but no shifts. Or maybe you have 200 different shift patterns across many factories to configure. Configuration is so complex it's a well paid profession in itself: the functional consultant. When that config is not enough to implement the requirements then developers can modify the system. Either changing existing ABAP code, or building new ABAP programs or (more commonly nowadays) just building webapps with the normal tools (react/node.js/java etc) in the cloud and using sap ERP as a backend to read/write data to. This last one sums up my day to day. ABAP is interesting though. Syntactically it looks like COBOL and that you've gone back 40years plus most of the DB tables/columns/data types have seemingly random names like WERKS or DMBTR. They make sense in German after you've shortened the German meaning to 5chars :). So ABAP code looks very cryptic at first sight. But semantically the language is ok. It is strongly typed, has some nice features for working with finance programs (e.g. fixed point arithmetic) and an OO model that feels familiar to anyone that knows Java (e.g. single inheritance). |
* Compliance * Standard Processes * Interoperability between companies (a lot of purchasing runs automatically through some sort of SAP Software)
What mostly fails in my experience is the customization. Everybody thinks their process is super special and important and needs 100 escape hatches. But if you ask them to draw their process on a whiteboard, they couldn't do it for one single process without drawing 100 question marks.
That is where SAP shines: The whole thing is so bureaucratic, coming from Germany, which is something you will need after your company has grown beyond a certain size.