4 ms·

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 woul

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...

J_cst 7y ago
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.
- toyg 7y ago
  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).
enraged_camel 7y ago
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.
- jimnotgym 7y ago
  I can't say that my experience tallies at all with yours. You need to work the way your ERP works.
  - enraged_camel 7y ago
    >>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.
    - jimnotgym 7y ago
      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.
      - tqi 7y ago
        Agreed - "Customizing ERP" is just a euphemism for "Breaking it in such a way that version upgrades will never go smoothly, ever."
    - parasubvert 7y ago
      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.

J_cst 7y ago

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.

toyg 7y ago
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).

enraged_camel 7y ago

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.

jimnotgym 7y ago
I can't say that my experience tallies at all with yours. You need to work the way your ERP works.
- enraged_camel 7y ago
  >>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.
  - jimnotgym 7y ago
    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.
    - tqi 7y ago
      Agreed - "Customizing ERP" is just a euphemism for "Breaking it in such a way that version upgrades will never go smoothly, ever."
  - parasubvert 7y ago
    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.