4 ms·
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
by 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 agoI 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 agoConfigurable 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 agoAgreed - "Customizing ERP" is just a euphemism for "Breaking it in such a way that version upgrades will never go smoothly, ever."
- parasubvert 7y agoIn 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.
- deleted 7y ago[deleted]
- nickpeterson 7y agoI 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".
- throwaway707765 7y agoAgreed. 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.
- deleted 7y ago[deleted]