Hacker News Reader

Comment by jmngomes | Hacker News Reader

Try to adapt the business processes to the ERP, instead of adapting the ERP to the custom business processes.

While I don't have hard data on this (and it would be hard to establish causality anyway), most of the ERP implementation failures I've witnessed and know about stem from line of business people who firmly believe their company's processes - e.g. collection, billing, etc - are very special and unique, when it is very rarely the case; and when it is, it shouldn't be, the process is likely overly complex due to inertia or lack of will/skills to improve or just legacy. Then, the customizations that need to be implemented to support the "special and unique processes" are so complex that the project's schedule and budget inevitably explode...

ERP implementations could actually be seen as a great opportunity to revisit, optimize and document current processes before the ERP is implemented...

View on HN

I've been working in this field for nearly 15 years, and what you said is the exact opposite of reality, in my experience.

Number one rule of change management is: keep the number and amount of changes to a minimum. Successful projects involve changing only one thing at a time: medium (where), process (how) or goal/mission (why). If you find that the process is not optimal, or maybe even total nonsense, optimizing/fixing that needs to be a separate, pre-requisite project that is started and finished before you even start to think about the software project.

If that's not an option, then we can talk about the number two rule: it is much, much harder to get people — especially large groups of people — to change the way they do things, than to implement software to make it fit the way those people are used to operating, no matter how dumb and convoluted their process is. The reason is simple: software is predictable and does not have an agenda. In contrast, people are unpredictable, and each has their own agenda.

I can't say that my experience tallies at all with yours.

You need to work the way your ERP works.

>>You need to work the way your ERP works.

All I can say is that trying to force this is, by a large margin, the primary reason why major software projects fail. Software is meant to aid, not dictate, how people work.

You don't have to take my word for it. Just look at the industry. Companies like Salesforce have become enormously successful because their products are configurable and customizable to a crazy extent, and you can make them fit into virtually any business process.

Configurable I like, customizable I don't.

My experience is that customisation gets turned off eventually, it always breaks something. Either that or it just doesn't get used. Companies are much more similar than they would like to admit. If an ERP is not going to work for you 95% out-of-the-box you should probably find something with a better fit.

Agreed - "Customizing ERP" is just a euphemism for "Breaking it in such a way that version upgrades will never go smoothly, ever."

In the case of SAP, the whole point of it is to dictate how your business should work for core undifferentiated processes. You’re buying the software BECAUSE it has business processes baked into it.

For core competencies where you do something differently from everyone else competitively, then SAP really has limited value except as a point of integration. Though I have seen some companies build entirely custom processes in ABAP for techno-religious reasons.

I view large software packages like ERP systems as different from a tool. You're adopting the metaphors of the system. Sometimes those metaphors are flexible enough to accommodate some of the nuance of the origination you're in, but sometimes you strain them too much or more likely misunderstand what the system is really doing.

People who advocate for letting the ERP dictate the rules are using the phrase as a shorthand for, "If you want to customize the hell out of it you probably shouldn't use it".

Agreed. If the ERP is not customizable to your company, then the employees will find ways to work outside of the ERP.

Then you end up with teams having their own Dropbox and a bunch of custom Excel templates. Worse yet, employees waste 20-30% of their time manually converting their custom process into the ERP.

Then if a key employee leaves, suddenly people wonder why the ERP isn’t correctly working anymore, without realizing that person was the glue, binding the actual custom process with the mandated ERP.

I totally agree. Main mistake is customizing the ERP to the company. I also noticed that what usually goes smoothly is the accounting. I believe that the reason for that is that accounting - at least in italy - is a quite standardized process and rarely companies have a special kind of accounting, so there's no need to customize it and screw it up.

That’s probably because accounting typically gets “massaged” later on with systems that are more focused on specific tasks (consolidation, reporting, analytics etc). I work in that space... numbers are typically extracted from SAP as soon as possible then handled elsewhere in whichever tool actual accountants prefer (well, all accountants would rather do everything in Excel, if they could, but beyond that they do have preferences. Sometimes the preference is whatever their boss decides to use while on a golf course with the vendor, but hey, whatchagonnado).

Reply on news.ycombinator.com