Tangential question: how do I learn about ERP software? I went to a strong CS school but this wasn't covered. I don't think I even know anyone who knows this stuff.
- regular HN reader.
- regular HN reader.
Having said that, ERPs systems are arguably mainly accounting systems with a lot (and I really do mean a lot) of additional functionality bolted on, so learning the basics of accounting wouldn't do any harm.
I count at least 4 different kinds of organizations that work with ERPs:
- The vendors who write them (Oracle, SAP, Microsoft and loads of others)
- Vendors who write packages that integrate with ERP systems (again loads of these - e. for reporting/data warehousing, document management, bar-code handling)
- People who work for professional services companies that help customer implement ERP systems - often implementing custom code in the platform for the ERP system (often in programming languages and environments that are specific to that ERP product!)
- Customer organizations
For a developer, I would aim for one of the first two although the professional services side of things can be pretty lucrative.
Having said that, I think SAP is rather more complex than AX.
They often integrate with external systems (stock management, production equipment, third party accounting platforms, billing, user management), even when the ERP system itself offers functionality in a given area.
It's a huge subject area.
However, most ERP software itself is just a large CRUD application that calls out to third party services (via APIs, COM, libraries, etc).
If you really want to learn about ERP software, try go get a job working with it for a year or two. The technical knowledge you'll require to get such a position is fairly generic (database basics, user experience design, TCP/IP, Unix/Linux server management). What would really make you stand out as a candidate would be having an understanding of business process modelling and reengineering - that's all ERP software is, a mirror of business processes.
It's an interesting area to work in (perhaps not long-term unless you're really into the BPR side of things). You'll really understand how businesses work and how they see their processes. And when you're working at the enterprise scale, small improvements in the software people use daily to perform their main functions can make all the difference.
Source: I've build ERP software for the last 7+ yrs.
I was told by our .Net developers that JDE is for business analysts so they can do the same thing as developers without writing any code. I've only done a few minor things in JDE, but it seems very "mouse intensive". Lots of clicking this and that, joining this table to that table, looking up this record, etc.
Is this true of most ERP software, or just in the case of JDE?
There are limitations to what can be accomplished in that sort of end user programming (wouldn't enjoy integrating with an arbitrary third party service, for example).
However this tends to run parallel to the regular scripting and COM/CORBA/DLL interfaces.
I must admit that the system I've worked with most recently doesn't offer any sort of end user programming or report generation, and I miss this badly. Those facilities, while basic, really lessen the burden on software engineers and allow us to focus on the more difficult tasks which deliver the most business value.
I'm working in-house (not consulting) so would much rather see our end users creating their own reports than have to, for example, put a new supplier integration module on hold in order to have a developer pull together a critical sales report.
In many deployments, I've seen not only business analysts take advantage of a simple programmable environment but also departmental power users. It's not uncommon in some larger organisations to find sales staff writing their own reports or finance professionals scripting integration with spreadsheets (yes, spreadsheets and ERP systems usually do co-exist really comfortably!). This usually depends on sensible RBAC and a well designed schema, to keep users from making damaging mistakes.
So to answer your question (I think) - most good ERP software will offer a balance between end user programming/reporting and integration features aimed at full time developers.
After that, you'll know ERP software.
I would get hired at a company as a general dev or whatever and then try to transition to to a sys admin role (like "JDE Administrator"). Alot of guys work with me (me too) got in this way.
Get a year or two experience and then go be a contractor - just search for JDE contractor jobs. Or, get hired on full-time at one of the many small consulting firms that specialize in the app you're targeting.
You can come in with less experience if you can accept less salary, like at a full-time salary at a consulting co. if you can come in at 80-90k salary, that's low. I know guys got on with just minimal experience. Trust me on this, if you're smart, you'll pick up the skills.
Designers might have classes on how to use photoshop. Accountants might have classes on how to use quickbooks.
You might find a business-related class that covers ERP-related topics?
Moreover, folks that are experts on an ERP typically are an expert either on (a) one type of ERP (e.g.-SAP), or (b) ERPs for a specific domain (e.g.-manufacturing). You don't typically get somebody who knows many different ERPs across many different businesses. During an ERP implementation, you'll usually hire one of type A, and one of type B, and then a whole team of developers/implementers.
Each vendor gives extensive training on all sorts of different aspects of their ERPs, but really, if you'd like to get a handle on what they do, you need to know how enterprises work. And the only way you're going to do that is by working in an enterprise. I've had my exposure to ERPs by building data warehouses that have to read and interact with them. But, my college degree's in management and economics, so things like accounting and business processes were already something I had passing familiarity with. ERPs will make little to no sense if you don't understand how corproate accounting works.
ERPs are wildly complex, and each has about 1000 different packages that you can use to do...I don't even know half of what they do. The best way to get some familiarity with ERPs is to get hired in some place where they'll teach you all about it. This includes training in the classroom and on the job. These are typically consulting firms--there are a few big ones, and there are a few boutique ones that do only ERPs. Also, the vendors typically have implementation teams, so you may want to do that, as well. I will note that ERP implementers almost always are required to travel extensively, so if somebody reading this wants to go into it as a career, understand what you're getting into. Travel is insanely lucrative if you don't mind it, but if you have a family or other commitments, it can tear you apart.
I think his point was that ERPs are specific proprietary applications that are not used as tools for programming, and wouldn't ever show up in any CS curriculum. I didn't see any statement on what ERPs are capable of doing.
>But, my college degree's in management and economics, so things like accounting and business processes were already something I had passing familiarity with. ERPs will make little to no sense if you don't understand how corproate accounting works.
>You might find a business-related class that covers ERP-related topics?
I'm not sure why your response was framed like a disagreement.
They were being pedantic about something in the original post, so I edited the post so the actual point wasn't lost.
The only thing I disagreed with the parent about was that I don't consider ERPs to be a "specific domain," anymore than "all of the businesses in the world" is a "specific domain." My intent was to explain to a layman that ERPs manage a ton of different processes, and that they are very complex applications with many different options.
Apparently, I have failed to do that. So, sincerely, all apologies.
http://en.wikipedia.org/wiki/Enterprise_resource_planning
Beyond that, you'll find textbooks on the topic as well. Courses on ERP (and related topics like MRP) are usually found in degree programs with names like "Management Information Systems" or something, not "Computer Science".
http://www.amazon.com/Enterprise-Resource-Planning-Bret-Wagn...
http://www.amazon.com/Concepts-Enterprise-Resource-Planning-...
If you wanted to get your hands dirty, there are some open source ERP systems out there. One well known one is OFBiz, which is now an Apache project:
I'm not 100% sure I'd actually recommend anybody deploy OFBiz for a real business, but if you wanted to play around and get a feel for some of the concepts, it could be a useful starting point.
Finally, if you want to drink from a firehose, you could do something like this:
https://www.google.com/search?q=%22enterprise+resource+plann...