11 ms·

> we re-engineered our processes to fit SAP. That sounds just about like the most revolting and negative endorsement you can make for a business solution. Eve

> we re-engineered our processes to fit SAP. That sounds just about like the most revolting and negative endorsement you can make for a business solution. Every company is special and the flexibility to adapt to a changing environment is what keeps a company alive during those times of crisis, that always come. "We can't do this because the system does not allow it" is great and expected at the warehouse worker level, annoying at the branch manager level and catastrophic at senior management level.

barrkel 8y ago
Competitive advantage is rarely in processes that a company is trying to replace or automate with third party software.
- mbesto 8y ago
  ^ this. Coca Cola does their financials the same way Pepsico does. Yet both companies have tried to implement them in unique ways and subsequently have cost them a great deal in terms of IT implementation costs that offer little to no competitive advantage.
  - mgkimsal 8y ago
    potentially harder to poach people from the competition if you're both doing generic stuff but using proprietary, custom and opposite techniques?
    - rbanffy 8y ago
      That's a justification for writing an ERP in Brainfuck.
d_e_solomon 8y ago
As a former consultant in SAP - Most companies aren't that unique in how they execute most processes. For instance, AP payments generally looks the same at a high level. For the variations of business processes, SAP gives you lots of room to modify configuration to fit your process. If you're in a specialized industry like Aerospace or Oil and Gas, they have unique industry specific solutions. I've seen the flip side where people custom code the heck out of the system. That becomes impossible to upgrade and impossible to take advantage of new features. I've also seen lots of bad processes continued that could have been re-engineered to be good processes if the implementer and business had an honest conversation. SAP for better or worse forces these conversations by limiting the ways that you can implement the solution. SAP failed implementations are not unique from other software failed implementations. It doesn't fail because of the product; it fails because of the people and politics of the organization. SAP tends to make the headlines because of the size of the implementations and the eye watering costs.
- dragonwriter 8y ago
  > SAP failed implementations are unique from other software failed implementations. No, they aren't. > It doesn't fail because of the product; it fails because of the people and politics of the organization. Essentially all project failure are for that reason. (Including ones where one intermediary step on the route to failure was that the people and politics in the organization ended up selecting a solution that was a poor fit for the problem.)
  - d_e_solomon 8y ago
    Yes, that's what I meant - they're not unique. Sorry for the typo :)
  - freehunter 8y ago
    The last big project failure I had was due to the company selecting the right technology for the problem, but the wrong one for the company culture. The company's engineers were young and viewed themselves as a startup, which means they like to use bleeding-edge solutions. The company themselves were an old enterprise with well-worn problems, and picked exactly the technology they should have. Unfortunately a newer, sexier product was part of the selection process, and the engineering staff didn't like that management picked the "wrong" one. They stonewalled the project until it failed, management complained about how inflexible the product was, and they switched to the other, newer, sexier product (I work for a vendor-agnostic consulting organization, so I stayed on for both products) and we ended up developing custom solutions for every problem we encountered with the new sexy product. Solutions that were solved out of the box with the older and more mature product. It was $110m down the drain on the first product, then another $80m to purchase the second, plus the cost of my consulting time to create custom solutions. People and politics are the hardest part of any technology implementation. Any article I see blaming SAP, IBM, Oracle, HP, etc of botching a multi-million dollar public project, I always have to wonder: who went wrong... not what went wrong.
    - dragonwriter 8y ago
      > The last big project failure I had was due to the company selecting the right technology for the problem, but the wrong one for the company culture. The company culture is a central piece of any business problem you are addressing, if your solution doesn't address it, it isn't addressing the actual problem, but at best a lower-dimensional projection.
detuur 8y ago
No, your company isn't special. Look at it from an engineering perspective. The law, by which I mean all laws that you operate under—local, regional, state-level, federal, international alike—is really not much more than a specification that you have to adhere to. More active markets and more rules and laws you're bound to just means a more complex set of specifications. Just like in the software world, we need a process, an implementation to adhere to that specification in order to do business by it. And at the end of the day, if two different implementations are compliant to the same specifications, the complexity of moving from one to another is always going to be minimal. One particular caveat is even similar to software engineering: if you're doing special, non-standard stuff outside of the spec, you should probably not be doing that at all. This is a fun analogy, but in the world of enterprise-level business, the business often is software. Entire businesses today are ran by software, and that software is written according to the same set of specifications: the law. The small particulars that don't have to do with law or common business practices are pretty much reducible to implementation details. SAP is one such very comprehensive implementation, that is very possibly the only software suite that has a nearly full coverage of the entire "spec" for business purposes. If you can't translate your business operations to SAP, beg your pardon for my abrasiveness but you're doing things wrong.
- nawitus 8y ago
  The space of possibility within the confines of law is very large.
  - sangnoir 8y ago
    This is true, with the caveat that most points are clustered. It is possible to translate from one point to another (the "one SAP true way", for instance) within this space by re-engineering processes. Parent's point is - this is easier than most people assume - especially those who say "our business is unique"
JacobDotVI 8y ago
The book Softwars spends a lot of time on this topic, where Larry Ellison blasted all of his integration partners for over-customizing their solutions when the correct approach was to update the business processes to match the software: https://www.amazon.com/Softwar-Intimate-Portrait-Ellison-Oracle/dp/0743225058/ref=sr_1_1?ie=UTF8&qid=1531763411&sr=8-1&keywords=softwar+an+intimate+portrait+of+larry+ellison+and+oracle https://www.amazon.com/Softwar-Intimate-Portrait-Ellison-Ora...
- muxator 8y ago
  So, let's say you manage to update your client's processes to the ones that best fit the SW you are selling. Eventually, the time for upgrading will come. Magically the specification for the new system will be: "it has to work exactly like the last one", and the last one will naturally happen to be yours. Who wins? The customer? Maybe (how clumsy it may be, he now has a stable, supported process, after all). The vendor? A thousand times this: he has successfully locked-in yet another client, foraging on its inertia.
  - Aloha 8y ago
    I make custom systems for a living, I also support a CRM/ERP solution for SciFi conventions which often has custom enhancements for customers. The real answer is to meet in the middle - sometimes the you have to be willing to tell the customer no - its just how it goes - and sometimes you need to go back and bang on the developers to go get it to work the way the customer thinks it ought to, because the customer is correct, and the devs do not understand the use case. The key is, dont tell the customer no too often, and dont bang on the devs too often - you gotta strike the balance, and only experience can tell you where that magic line is.
    - dcd6406 8y ago
      Agreed - great comment
ghaff 8y ago
There's usually some happy or at least less unhappy middle ground. Yes, businesses often have unique needs and sometimes they're so unique and so critical that they're worth heavily customizing for. On the other hand, I like telling a story from not that many years ago when a very small business (I'm talking like 10 people) wanted to get off running their own Exchange server. Exchange made sense when they set it up but Gmail and the like had come on the scene since. The CEO eventually had to mandate it because the person who ran the business side of things was incredibly strongly opposed because they were used to storing emails associated with contracts in a hierarchical folder structure and, at the time, Gmail didn't support nested labels. In that case, change how you do things to match the software was absolutely the right answer.
jgust 8y ago
Something I learned in ERP 101: Don't customize software to your process unless the process is your competitive advantage.
- dcd6406 8y ago
  Excellent response - couldn't agree more!
alkonaut 8y ago
There is a bit of uniqueness that companies actually have, and the rest of “how we do things” and “what our processes are” is basically a symptom of inertia and - how the last system worked. It will turn out that every process and every structure is influenced by the system that is used. They are one. So the idea of customizing a business system to fit a business doesn’t exist - in reality it’s often customizing it to fit whatever the last system did (to processes and structures), which is something else, and not nearly as great sounding an ideaas “tailoring a system to our unique business” The key is to identify what parts of the process are “how we always did things, but for no apparent reason” which probably turns out to be a lot of things. It’s painful because it causes a lot of turmoil when everyone has to question every process. But it’s good pain. I’m strongly agreeing with the GP: it’s both better and cheaper to at least meet half way with software like this. It’s simpler to change processes than to customize business systems. What becomes painful is that the deployment of some new business system now became a massive reorganization and a complete overhaul of all business processes. But this is still less painful than customizing SAP to any large degree.
rbanffy 8y ago
> Every company is special A company must consider whether its business processes are a competitive advantage. In well established businesses, chances are they aren't. In that scenario, it really doesn't make much sense to stick with them.
nitwit005 8y ago
> That sounds just about like the most revolting and negative endorsement you can make for a business solution. A lot of these larger software packages support different levels of customization, and they usually press people to use the simplest stuff. It's not completely possible to guarantee reliability once the customer is writing their own code. You can guarantee the app doesn't fall over, and data isn't lost, but ultimately the customer is free to shoot themselves in the foot, and they will.
bassman9000 8y ago
Every company think it's special FTFY. There's huge benefits in using standardized solutions, like faster upgrades, and fixes to bugs you even didn't know you had but that were solved for other customers.
derefr 8y ago
Yes, every company is special. That doesn’t mean your company has any valid justification for being special, instead of adhering to standards that business technologies can be targeted toward. Most ways that companies are special are just ways that those companies are broken. (Calling to mind the classic “Happy families are all alike; every unhappy family is unhappy in its own way” quote.) Look at it like any other utility infrastructure: if you want your factory to hook up to the same power grid as everyone else, it’s your factory that’s got to change, not the power grid. Or do you want to spend half of every new factory bring-up winding your own three-phase-220V-to-five-phase-39.2V transformers to meet your “unique” needs?
watertom 8y ago
Frankly doing an SAP installation with no customization is no different than using a SaaS platform, there are a lot of options, but no code customizations. All the processes had become "unique" over time, not because the company was special, but because they were coding their own solutions and either the IT staff or the business wanted something done for the benefit of the specific department. Once the processes were evaluated with a critical eye toward what actually needed to be accomplished, the uniqueness of the existing process couldn't stand up to scrutiny. Luckily the CIO and the CEO had the courage to face down the IT staff and business leaders, the rank and file cheered for adopting standard processes, they knew the existing processed sucked.

barrkel 8y ago

Competitive advantage is rarely in processes that a company is trying to replace or automate with third party software.

mbesto 8y ago
^ this. Coca Cola does their financials the same way Pepsico does. Yet both companies have tried to implement them in unique ways and subsequently have cost them a great deal in terms of IT implementation costs that offer little to no competitive advantage.
- mgkimsal 8y ago
  potentially harder to poach people from the competition if you're both doing generic stuff but using proprietary, custom and opposite techniques?
  - rbanffy 8y ago
    That's a justification for writing an ERP in Brainfuck.

d_e_solomon 8y ago

As a former consultant in SAP - Most companies aren't that unique in how they execute most processes. For instance, AP payments generally looks the same at a high level. For the variations of business processes, SAP gives you lots of room to modify configuration to fit your process. If you're in a specialized industry like Aerospace or Oil and Gas, they have unique industry specific solutions. I've seen the flip side where people custom code the heck out of the system. That becomes impossible to upgrade and impossible to take advantage of new features. I've also seen lots of bad processes continued that could have been re-engineered to be good processes if the implementer and business had an honest conversation. SAP for better or worse forces these conversations by limiting the ways that you can implement the solution. SAP failed implementations are not unique from other software failed implementations. It doesn't fail because of the product; it fails because of the people and politics of the organization. SAP tends to make the headlines because of the size of the implementations and the eye watering costs.

dragonwriter 8y ago
> SAP failed implementations are unique from other software failed implementations. No, they aren't. > It doesn't fail because of the product; it fails because of the people and politics of the organization. Essentially all project failure are for that reason. (Including ones where one intermediary step on the route to failure was that the people and politics in the organization ended up selecting a solution that was a poor fit for the problem.)
- d_e_solomon 8y ago
  Yes, that's what I meant - they're not unique. Sorry for the typo :)
- freehunter 8y ago
  The last big project failure I had was due to the company selecting the right technology for the problem, but the wrong one for the company culture. The company's engineers were young and viewed themselves as a startup, which means they like to use bleeding-edge solutions. The company themselves were an old enterprise with well-worn problems, and picked exactly the technology they should have. Unfortunately a newer, sexier product was part of the selection process, and the engineering staff didn't like that management picked the "wrong" one. They stonewalled the project until it failed, management complained about how inflexible the product was, and they switched to the other, newer, sexier product (I work for a vendor-agnostic consulting organization, so I stayed on for both products) and we ended up developing custom solutions for every problem we encountered with the new sexy product. Solutions that were solved out of the box with the older and more mature product. It was $110m down the drain on the first product, then another $80m to purchase the second, plus the cost of my consulting time to create custom solutions. People and politics are the hardest part of any technology implementation. Any article I see blaming SAP, IBM, Oracle, HP, etc of botching a multi-million dollar public project, I always have to wonder: who went wrong... not what went wrong.
  - dragonwriter 8y ago
    > The last big project failure I had was due to the company selecting the right technology for the problem, but the wrong one for the company culture. The company culture is a central piece of any business problem you are addressing, if your solution doesn't address it, it isn't addressing the actual problem, but at best a lower-dimensional projection.

detuur 8y ago

No, your company isn't special. Look at it from an engineering perspective. The law, by which I mean all laws that you operate under—local, regional, state-level, federal, international alike—is really not much more than a specification that you have to adhere to. More active markets and more rules and laws you're bound to just means a more complex set of specifications. Just like in the software world, we need a process, an implementation to adhere to that specification in order to do business by it. And at the end of the day, if two different implementations are compliant to the same specifications, the complexity of moving from one to another is always going to be minimal. One particular caveat is even similar to software engineering: if you're doing special, non-standard stuff outside of the spec, you should probably not be doing that at all. This is a fun analogy, but in the world of enterprise-level business, the business often is software. Entire businesses today are ran by software, and that software is written according to the same set of specifications: the law. The small particulars that don't have to do with law or common business practices are pretty much reducible to implementation details. SAP is one such very comprehensive implementation, that is very possibly the only software suite that has a nearly full coverage of the entire "spec" for business purposes. If you can't translate your business operations to SAP, beg your pardon for my abrasiveness but you're doing things wrong.

nawitus 8y ago
The space of possibility within the confines of law is very large.
- sangnoir 8y ago
  This is true, with the caveat that most points are clustered. It is possible to translate from one point to another (the "one SAP true way", for instance) within this space by re-engineering processes. Parent's point is - this is easier than most people assume - especially those who say "our business is unique"

JacobDotVI 8y ago

The book Softwars spends a lot of time on this topic, where Larry Ellison blasted all of his integration partners for over-customizing their solutions when the correct approach was to update the business processes to match the software: https://www.amazon.com/Softwar-Intimate-Portrait-Ellison-Oracle/dp/0743225058/ref=sr_1_1?ie=UTF8&qid=1531763411&sr=8-1&keywords=softwar+an+intimate+portrait+of+larry+ellison+and+oracle https://www.amazon.com/Softwar-Intimate-Portrait-Ellison-Ora...

muxator 8y ago
So, let's say you manage to update your client's processes to the ones that best fit the SW you are selling. Eventually, the time for upgrading will come. Magically the specification for the new system will be: "it has to work exactly like the last one", and the last one will naturally happen to be yours. Who wins? The customer? Maybe (how clumsy it may be, he now has a stable, supported process, after all). The vendor? A thousand times this: he has successfully locked-in yet another client, foraging on its inertia.
- Aloha 8y ago
  I make custom systems for a living, I also support a CRM/ERP solution for SciFi conventions which often has custom enhancements for customers. The real answer is to meet in the middle - sometimes the you have to be willing to tell the customer no - its just how it goes - and sometimes you need to go back and bang on the developers to go get it to work the way the customer thinks it ought to, because the customer is correct, and the devs do not understand the use case. The key is, dont tell the customer no too often, and dont bang on the devs too often - you gotta strike the balance, and only experience can tell you where that magic line is.
  - dcd6406 8y ago
    Agreed - great comment

ghaff 8y ago

There's usually some happy or at least less unhappy middle ground. Yes, businesses often have unique needs and sometimes they're so unique and so critical that they're worth heavily customizing for. On the other hand, I like telling a story from not that many years ago when a very small business (I'm talking like 10 people) wanted to get off running their own Exchange server. Exchange made sense when they set it up but Gmail and the like had come on the scene since. The CEO eventually had to mandate it because the person who ran the business side of things was incredibly strongly opposed because they were used to storing emails associated with contracts in a hierarchical folder structure and, at the time, Gmail didn't support nested labels. In that case, change how you do things to match the software was absolutely the right answer.

jgust 8y ago

Something I learned in ERP 101: Don't customize software to your process unless the process is your competitive advantage.

dcd6406 8y ago
Excellent response - couldn't agree more!

alkonaut 8y ago

There is a bit of uniqueness that companies actually have, and the rest of “how we do things” and “what our processes are” is basically a symptom of inertia and - how the last system worked. It will turn out that every process and every structure is influenced by the system that is used. They are one. So the idea of customizing a business system to fit a business doesn’t exist - in reality it’s often customizing it to fit whatever the last system did (to processes and structures), which is something else, and not nearly as great sounding an ideaas “tailoring a system to our unique business” The key is to identify what parts of the process are “how we always did things, but for no apparent reason” which probably turns out to be a lot of things. It’s painful because it causes a lot of turmoil when everyone has to question every process. But it’s good pain. I’m strongly agreeing with the GP: it’s both better and cheaper to at least meet half way with software like this. It’s simpler to change processes than to customize business systems. What becomes painful is that the deployment of some new business system now became a massive reorganization and a complete overhaul of all business processes. But this is still less painful than customizing SAP to any large degree.

rbanffy 8y ago

> Every company is special A company must consider whether its business processes are a competitive advantage. In well established businesses, chances are they aren't. In that scenario, it really doesn't make much sense to stick with them.

nitwit005 8y ago

> That sounds just about like the most revolting and negative endorsement you can make for a business solution. A lot of these larger software packages support different levels of customization, and they usually press people to use the simplest stuff. It's not completely possible to guarantee reliability once the customer is writing their own code. You can guarantee the app doesn't fall over, and data isn't lost, but ultimately the customer is free to shoot themselves in the foot, and they will.

bassman9000 8y ago

Every company think it's special FTFY. There's huge benefits in using standardized solutions, like faster upgrades, and fixes to bugs you even didn't know you had but that were solved for other customers.

derefr 8y ago

Yes, every company is special. That doesn’t mean your company has any valid justification for being special, instead of adhering to standards that business technologies can be targeted toward. Most ways that companies are special are just ways that those companies are broken. (Calling to mind the classic “Happy families are all alike; every unhappy family is unhappy in its own way” quote.) Look at it like any other utility infrastructure: if you want your factory to hook up to the same power grid as everyone else, it’s your factory that’s got to change, not the power grid. Or do you want to spend half of every new factory bring-up winding your own three-phase-220V-to-five-phase-39.2V transformers to meet your “unique” needs?

watertom 8y ago

Frankly doing an SAP installation with no customization is no different than using a SaaS platform, there are a lot of options, but no code customizations. All the processes had become "unique" over time, not because the company was special, but because they were coding their own solutions and either the IT staff or the business wanted something done for the benefit of the specific department. Once the processes were evaluated with a critical eye toward what actually needed to be accomplished, the uniqueness of the existing process couldn't stand up to scrutiny. Luckily the CIO and the CEO had the courage to face down the IT staff and business leaders, the rank and file cheered for adopting standard processes, they knew the existing processed sucked.