What exactly is an “ERP”? Virtually everything I read about them or on the website of products, is so vague and broad that it sounds like “it’s everything”. How would a business know they need this product? For the big ERPs out there, is there a clear guide with screenshots that show what they concretely do?
Basically the core functionality is to track inventory, manage purchase orders in, and sales orders out. Generally that's also linked to accounting so basically as you buy and sell stuff everything is linked to your accounting ledgers.
Then there's MRP (M for manufacturing) which is usually an option - for when stuff that you're selling isn't the same as what you're buying.
So the ERP/MRP manages bills of materials for items (basically parts lists), when you want to sell something you make a sales order, it sees if you have the inventory on hand to actually make the things, and if not you can generate purchase orders, and then once you have everything it can create work orders which basically tell your factory people to go and turn the input parts into a product so you can sell it. Invoices are created from sales orders, and workers time is tracked on the purchase order, so the cost of goods and labour is automatically tracked in your financial reports as well as the revenue etc.
Not all materials are parts. For instance, if you run a soup factory you don't order 'soup parts' but bulk ingredients in the same proportions that you end up selling, but there are many other things that you need to worry about in the process of preparation and there are things that don't even make it into the end product at all that you still need during the manufacturing step (for instance, cleaning products, various chemicals). So 'basically parts lists' is a bit of a shortcut.
Yes. Most ERP's also handle 'ingredients'. Really, it is any 'inputs' to the product. And potentially, byproducts produced and also sold. All In's/Out's, and how to track them.
The M is for “material”. Material Resource Planning.
They do lots of things that’s the problem… The key items in my experience are: 1. Finance/accounting processes 2. Supply chain processes (for product companies) 3. Project/Services processes (for consulting companies) 4. Procurement They can have other things like: sales, customer service, order management, payroll, HR, projects, warehouse or factory management, materials management and so on. A key decision in very large companies is whether to go with one ERP that does most things and they having to integrate the rest (tedious, expensive), or many smaller apps that might be best in class for their niche then having to integrate them (also tedious, expensive)
And ERP is Enterprise resource planning.
Thank you for expanding the acronym. I’m always surprised the acronyms aren’t expanded in projects website. This gives me the impression the developers are embedded in the status quo of the problem domain.
This blog post from Retool was really helpful for answering that question: https://retool.com/blog/erp-for-engineers
That was a good read! Thanks
I've worked on a erp for a short while and I genuinely still don't know. The amount of bullshit surrounding them is certainly staggering.
I now work on a large company that is about to introduce a large new erp system and is not only investing billions into that change with the mother of all vendor lock ins; but we're also internally transforming the company so that the erp will work. But no, we can't afford the two days of estimated work to upgrade to c++20 as it's not necessary right now.
> internally transforming the company
I'm not sure how things are now, but I once worked tangentially on a mid-sized corporation ERP rollout. At that time it was not unusual to have an entire department at the ERP-adopting company called "Change Management." Any company-wide process change was managed by the Change Management department.
Oh that brings memories! Been in quite a few of those.
Basically the ERP vendor sells you the software and estimates that you need a couple months and a couple consultants for the migration and integration, plus a few users of your product as guinea pigs. It is expensive as heck but well, at least it is only two months (plus hotels, plane and food).
After two months you’re halfway done according to the vendor but you need some extra helping hands for the harder features, so you get more consultants, and a department to handle change. You get a few posters.
After a couple years you have eight consultants and a consulting product manager still doing the migration work, plus eight more freelancing ERP experts, and about four engineers from your own team working full time on apis. The work is halfway done, though! Your non-tech staff is juggling between two products and dissenting voices start to appear. You make and distribute t-shirts with texts like “Project Evolution” or “Project Future” to ensure everyone is on board.
After two more years you are almost halfway there, but staff turnover guarantees that people don’t remember the productivity of yore, and the new ERP is judged as good enough. People have gotten used to it, the jokes aren’t as vicious as before, and only a handful of people were fired in the previous years due to the company going severely over budget. But hey nobody gets fired for buying IBM so the boss who decided to blow 15 million on it is fine.
I've seen this balloon to hundreds of consultants. It can break a company. You get huge sunk cost into you're continually 90% done ERP and management either doubles down to spend one year to just get it barely working and stop, or cancel it.
In my experience companies end up paying as much money as they can.
The companies themselves are to blame, too: they absolutely refuse to change their processes, so the software must adapt to them, no matter what the cost.
> Oh that brings memories! Been in quite a few of those.
Hey! I was just on the receiving end of that. Twice! Its still the same.
Even my grandfather once told me stories of this happening in the 70s when the company he worked for was sold and the new management brought new software, or my parents telling similar stuff from the early 90s.
The major ERP vendors do not price based on product or services delivered, but they will just make a price based on your revenue.
The reasoning is that a company in a certain vertical with a certain size will spend x% of revenue on IT, and they want all of that.
ERP platforms are ridiculously hard to customise, and maintainance of customisations across version upgrades is even worse. So they will rightfully advise business operations adapt to the ERP template, rather than the other way around. They know full well in advance you will end up not following that advice as the changes would be enormous and lost functionality as compared to the previous system beyond tolerable from a business point of view, but they also know you will only discover the scale of this after the project has been committed.
Speaking about committing: they will leave no room, basically execution a denial of service to the whole of not just your IT departments but also all your business analyst interactions. Any non ERP transformation project will grind to an absolute halt.
Many of not most of these huge ERP migrations fail. The ERP vendor has been covering there ass from before the contract was even signed, and you will find their real expertise was building an airtight very well documented case showing you, not them, were at fault. These cases are nearly always settled and kept out of the press because neither party wants to lose face.
And you are right about the mother of all lockins if the project should succeed and actualy move into production (which they will try to force long before it is ready). They will leave you no room to ever go back. You'll have to commit even a lott more to leave than you needed to get in.
And as for all those business and IT people now trained on the ERP, wich is part of the project from day 1, good luck holding on to them. Their poaching will be not overtly but discreetly facilitated by the ERP's channel.
First day of first 'course' by the ERP vendor for the ERP transformation team, the opening sentence of the instructor litterally was: "I congratulate you all for being here. Next week after completing this course, walk into your manager's office and demand a 20% pay rise, as you are now worth that".
I myself have turned down very lucrative monetary offers, as the downside of working in those projects, whether at vendor or client side, is that the amount of unhappiness you create and are perpetually surounded by in those positions is just to mindnumbing that at least for me the money does not buy you out of that daily misery. But if you thrive on conflict, you can make some great money there.
I worked on an ERP system for construction/architect firms in the 00s. The company was about 15 people when I joined, 40 when I left.
We consistently delivered migrations, but we hand crafted SQL extraction scripts, with data cleaning, etc. You could fully customize it, branding it with your own logos/colours/custom css, etc. There was just a clause that the "powered by" link had to stay visible.
I can't remember a single failed migration, though we were split into three "teams" each covering a different set of customers, so might have not seen one.
I suppose we were fairly small scale, and maybe those were the days where some serious attention to detail and care of the customer were still possible as generally we were replacing paper based workflows, not trying to migrate existing electronic workflows with huge data volumes.
But it's perfectly possible to do (and we worked with some fairly big companies in the space).
One of the funniest, yet saddest, support calls I remember getting was being asked "What do we do with Sue now, we don't have anything for her to do anymore?".
So it entirely depends on your implementation team I think. It's possible to do it well. But you probably need a very good set of consultants. If your ERP trainer is coming in and immediately setting up conflict with your company, that's definitely not a good sign.
Small scale is definitely another world entirely. My experience was not in the Billion dollar range as the parent, but in 20M+ (probably 50M in today's dollars) project territory.
> So they will rightfully advise business operations adapt to the ERP template, rather than the other way around. They know full well in advance you will end up not following that advice as the changes would be enormous and lost functionality as compared to the previous system
There's an additional catch to that old argument as well. If you actually do what they say, and stick to all the templates. Well guess what, they're all going to change with next update as well and now you need to change all your business processes at the same cadence as they happen to update their software. You still have to adapt to the changes of the system, it's just not the IT departments problem.
Can you say who? Curious who in todays market is spending billions on a new ERP. I'd think the market is pretty dry right now.
I mentioned the cost, which is probably not a public info. A well known player in the semiconductor space.
It's a type of software that lets business manage and automate core processes in one integrated system. Typically linking finance/accounting with operations like sales, inventory and manufacturing.