How much do engineers have to interact with an ERP such as SAP? I have quite a bit of experience with SAP, on the logistics side, using its Warehouse Module, Material Module, Inventory Module, Light Billing. Basically, a customer would place a purchase order, in turn a sales order would be generated, from there is where I took over, until the invoice was created and EDI sent. At which point it was billing & 3rd party carriers responsibility.
I worked in a distribution center.
I always thought it was going to be useless information. I learned quite a bit about it. I actually wrote an ~200 page pdf for that job before I left. It was like a big picture kind of thing, like what transactions in the software represented in the process of the company. How I did the processes, and some that I implemented. Also some software "hacks" like using multiple unrelated transaction to obtain information for another. Quite a bit of it was a result of me being lazy, and believing that it was complete bull crap that there wasn't faster methods.
Could this actually be useful?
re: "Could this actually be useful?"
For EE engineers, it probably is not very useful. For the operational folks that ERP targets, the usefulness depends on what you mean by the word "this".
If "this" refers to ERP/SAP, definitely. SAP doesn't get to be one of the largest software firm if most manufacturers see ERP as a waste of time. But if "this" refers to the "hack", it would depends on what that SAP owner use it for.
I don't think ERP in general is a big picture thing. It is operational data: how much do I sell so far? What is my margin? Which product(s) are in my warehouse and how long?
(If not set to order automatically) What raw material do I need to order? So forth. It aims to automate all that stuff. Without a good ERP, "just in time" inventory management is darn near impossible. ERP data also is a good source for data-mining to see if one can find any information about sales, admin cost, product cost, etc. etc.
Main problem with ERP is really flexibility. One COO from a major firm once said of ERP (sorry, too far back for me to remember who), "It is like casting your operating procedure in concrete." Once you get all your procedures automated in code, changing any part of it often is a lot of work.
EDI is another matter. I don't know how the recent web related impact to EDI and I assume there would be many. My knowledge is 10 years old so likely out of date to some extend. ~10 yrs ago, world wide for many ports, you can't even dock your ship without getting an EDI manifest to the port authorities. Some ports, EDI is absolutely required, some ports, EDI merely avoid delay. An extra day in a major port costs a lot of money.
Besides shipment/order, EDI's cousin EDIFACT deals with admin/financial part of it and that is also very useful. ERP's direct connect to EDI is therefore very useful.
I think I said too much - ERP is way too far off topic. I brought it up to show a counter example that software failure could be as expensive as hardware failure and that the end user would hardly care whether it is hardware or software when the darn thing fail.
May be I am wrong, but ERP has so little to do with EE I can't see how it would affects new EE college grad's job market. So lets get back to discuss EE - new grad job market.