4 ms·

Good points, and my thoughts exactly when I left university with a business degree. My take now: The workflows of large enterprises are not really well unders

Good points, and my thoughts exactly when I left university with a business degree. My take now: The workflows of large enterprises are not really well understood at all. With lean management and how management careers work, even the lowest management levels has only a vague idea what is actually happening in their departments. Designing even a tiny system for a small number of users requires a lot of time and a lot of love. People do many more things that they could ever put into words. The new system breaks many things in ways that are difficult to describe. The users are defenseless because they are up against huge projects with a lot of momentum and are not prepared to communicate those kinds of problems. Uhm, so let's hope that your ERPs are actually succeeding.

JPKab 13y ago
I'm not sure if you are assuming that I'm a naive guy who is fresh out of university or not. In case you are, I am not. I worked for a small company (I was the 6th employee, and it grew to 150 people) whose largest project was an ERP implementation for an extremely large enterprise which I shall not name, but you would immediately know them. I was not involved on the project directly, but was frequently pulled in to advise those who were. Said organization went down a rabbit-hole trying to map out all of their workflows so that we could customize the ERP for their needs. What a nightmare. I am now witnessing a successful ERP implementation in another large organization. The first priority is to minimize customization. General Electric is a model of how to implement an ERP. They followed the minimal customization model, and forced their workers to change their workflows to take advantage of the tool. The key is to identify all of the data an org needs, and make it accessible. If your developers don't have an excellent metadata analysis/storage tool (homemade or bought) they are screwed.
- protomyth 13y ago
  > General Electric is a model of how to implement an ERP. They followed the minimal customization model, and forced their workers to change their workflows to take advantage of the tool. Yep, that's the model, but I contend it is a pretty poor model for everyone but the ERP vendor. It is basically saying the ERP or CRM vendor has a better grasp of a companies business process than the company. I have seen companies adopt a ERP and use its process, then anger customers because of the change. Since they follow a new path, many times it is IT telling the rest of the business how to run things[1] and much of the institutional knowledge is thrown out. 1) something as simple as what's on the invoice or payment voucher can have huge affects on customer experience in some industries.
- UweSchmidt 13y ago
  I was not assuming you were naive or fresh out of university. I was assuming however you came from the consultant's perspective. I am sure that you must recognize, that when people complain about ERP implementations not fitting, they refer to implementations that you describe as "model"? I come from the other end of the spectrum, making my first steps building business-process relevant tools while employed in various functions. What really shaped me was having carefully discussed the requirements, building it as specified, then being called because "it is not working", and realizing then and there what the actual business logic was, and how deep it was buried and how dysfunctional it all would have been had I insisted that I had implemented as specified. I'd say (to the consultant profession in general), grab the proverbial pistol and flashlight (http://en.wikipedia.org/wiki/Tunnel_rat http://en.wikipedia.org/wiki/Tunnel_rat), and go down the rabbit hole, because that's the only way the job can be done right.

JPKab 13y ago

I'm not sure if you are assuming that I'm a naive guy who is fresh out of university or not. In case you are, I am not. I worked for a small company (I was the 6th employee, and it grew to 150 people) whose largest project was an ERP implementation for an extremely large enterprise which I shall not name, but you would immediately know them. I was not involved on the project directly, but was frequently pulled in to advise those who were. Said organization went down a rabbit-hole trying to map out all of their workflows so that we could customize the ERP for their needs. What a nightmare. I am now witnessing a successful ERP implementation in another large organization. The first priority is to minimize customization. General Electric is a model of how to implement an ERP. They followed the minimal customization model, and forced their workers to change their workflows to take advantage of the tool. The key is to identify all of the data an org needs, and make it accessible. If your developers don't have an excellent metadata analysis/storage tool (homemade or bought) they are screwed.

protomyth 13y ago
> General Electric is a model of how to implement an ERP. They followed the minimal customization model, and forced their workers to change their workflows to take advantage of the tool. Yep, that's the model, but I contend it is a pretty poor model for everyone but the ERP vendor. It is basically saying the ERP or CRM vendor has a better grasp of a companies business process than the company. I have seen companies adopt a ERP and use its process, then anger customers because of the change. Since they follow a new path, many times it is IT telling the rest of the business how to run things[1] and much of the institutional knowledge is thrown out. 1) something as simple as what's on the invoice or payment voucher can have huge affects on customer experience in some industries.
UweSchmidt 13y ago
I was not assuming you were naive or fresh out of university. I was assuming however you came from the consultant's perspective. I am sure that you must recognize, that when people complain about ERP implementations not fitting, they refer to implementations that you describe as "model"? I come from the other end of the spectrum, making my first steps building business-process relevant tools while employed in various functions. What really shaped me was having carefully discussed the requirements, building it as specified, then being called because "it is not working", and realizing then and there what the actual business logic was, and how deep it was buried and how dysfunctional it all would have been had I insisted that I had implemented as specified. I'd say (to the consultant profession in general), grab the proverbial pistol and flashlight (http://en.wikipedia.org/wiki/Tunnel_rat http://en.wikipedia.org/wiki/Tunnel_rat), and go down the rabbit hole, because that's the only way the job can be done right.