>>I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. Never worked

>>I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. Never worked with SAP, but spent a lifetime working on other ERPs, and would agree. Your USP is NOT how you do HR, Finance, etc. Walmart's expertise is Retail/Supply-Chain Management. SpaceX's expertise is rockets. Backoffice is a cost centre, and the assumption (validated by decades of projects) is that you are probably (exceptions do exist) not a special snowflake when it comes to HR or Financials, no matter how much Sally in Accounting or Joe in Recruitment office insist. As I've mentioned elsewhere on this site, the #1 success criteria for ERP implementation is whether you take it as an IT, or a BT project. - Take it as an IT project, try to adapt a COTS system to whatever gobblety-gook of disjoint processes you have right now through a myriad of customizations, and you will have a failed implementation project which will be over-budget, over-schedule, and result in dissatisfaction of all stakeholders. - Take is as a BT (Business Transformation) project, and adapt your backoffice processes to match the industry standards and best practices as exemplified in the ERP, and you'll have a smoother implementation project and at least a chance that some stakeholders will satisfied - though more likely to be VP of Finance or HR, rather than Sally & Joe, because Sally & Joe, while experts in their field, are humans who are resistant to change, but more importantly unfortunately in most companies are not privy to the big picture results. It is absolutely true that most ERPs are hobbled by decades of legacy code; I would agree in principle that it's theoretically possible that a company could make their own ERP that is more efficient; but in reality, company's expertise is probably not making efficient ERPs, and in the end it would be seen as an IT project and no business transformation would take place - IT in service of business, after all. Even as a techie, my jaded/experienced view now is that amongst other things, when done right, ERPs provide drive and impetus for business transformation that needs to take place. As a techie, I would agree with your students on probably all the issues they see with ERPs. But their USP is not the brilliance of technical design - it's the proven business workflow and processes that have been standardized over decades of experience across hundreds and thousands of real world enterprises. Students are also likely to see inelegance of code or even business processes in isolation, but may not have real-world experience to understand why some business workflows are the way they are; why processes are seemingly inefficient but minimize ambiguity, or provide traceability and auditability; and myriad other unfortunate but realistic real-world constraints, scenarios, and frictions :-/