[d_e_solomon]

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.

[freehunter]

>Most companies aren't that unique in how they execute most processes

As a current "big expensive system" consultant (not for SAP, completely different company and line of work), I 100% agree. Every single client I've worked with has shown me a network diagram and with a grin asked if they're the most unique company I've ever worked with. The answer is almost always no. There's just not that many unique ways to do things, and it always comes down to two or three very similar processes done by two or three very similar pieces of software done in almost exactly the same way that produces almost exactly the same result.

The only thing that sets "unique" companies apart is a lack of culture, or a negative culture. Like you said, bad processes that could be re-engineered into good processes if only the company was able to be honest with itself. Unfortunately changing people and process is harder than changing technology and vendors, so if something doesn't fit perfect you just throw away hundreds of millions of dollars, throw a fit in the press, and never address that your company culture is so inflexible that no major project involving an outside vendor could ever possibly be a success.

[dragonwriter]

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

[freehunter]

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]

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

[derefr]

Usually there’s no interface to addressing such problems.

Interacting with the cultures of some companies is like trying to treat the mental illness of someone in a dissociative fugue state. You might have a solution that fits how things are on the inside—but how are you going to even get through to them to communicate that, when they can’t hear or see you and are instead lost in their own little world?

[dragonwriter]

> Usually there’s no interface to addressing such problem

I think you mean correcting culture to some preferred ideal, and that's likely true.

But what I'm saying is that institutional culture is a factor of every problem facing the institution, whether is a thing to fix as part of the solution or a constraint on viable solutions.

[cerberusss]

> It was $110m down the drain on the first product

What happened afterwards? Did this trigger management to consider why the purchase was the wrong one? I.e. was it a $110m lesson? Or was it really wasted money?

[freehunter]

The $110m spent on the first product was the cost of the product plus the consultant time to implement it. Both of those were sunk at that point and could not be refunded. The decision was made that Product A was not working for the company's needs, and listening to the engineers, the executives decided to switch to Product B. The blame went to Product A and the company that makes Product A, because it's pretty fashionable to hate them right now. "The product is outdated, it's inflexible, it's not able to be customized" and so on. Product B was brought it and it's so much more flexible since it includes absolutely nothing out of the box, so more money was spent on custom development to build the batteries that Product A includes by default.

My company did cut a deal on the consulting for Product B since we had already been working for them on Product A, but the products were charged at full price and to my knowledge none of the cost of Product A was returned to the customer.

As far as management was concerned, Product A was a failure because it was old and inflexible. Management was super happy to see every screen of Product B with their logo on it, which we put on there because we had to develop those screens from scratch anyway. Product B didn't have their logo in the upper right corner, it only had their logo on the printed output.

The only lesson learned was "ask your engineers what product they recommend", which I guess is an important lesson regardless.

[cerberusss]

Thanks, extremely insightful. I've never worked on projects worth more than, say, 5 million euros so these 100+m projects have a sense of scale that's hard to comprehend.

[orlovs]

Each problem have got name and surname

[rbanffy]

> selecting a solution that was a poor fit for the problem

In the specific case of SAP, if the problem is "we want to automate our processes" then it's probably a horrible fit.

If, however, the problem is "we need good automated processes", then it can be a great fit.

[d_e_solomon]

Yes, that's what I meant - they're not unique. Sorry for the typo :)