[netinmate]

Customization is key, you CAN't customize. I worked on an SAP implementation, a Fortune 500 company, complexity like crazy, sub-companies, of sub-companies, of sub-companies, federal, state and local compliance for what the company did, operating in 50 states, with an International supply chain, and our integrator was nothing special.

We held firm to the NO CUSTOMIZATION rule, we re-engineered our processes to fit SAP. Other than a few hiccups when integrating all aspects of a company that has 100 sub companies, and is under federal, state and local regulation the project basically went off without a hitch.

They are still taking upgrades 6 years later, without issue.

Most companies think they are unique, and special, and feel justified in needed to customize, all those companies are wrong.

[bumholio]

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

[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?

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

[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 :)

[detuur]

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]

The space of possibility within the confines of law is very large.

[sangnoir]

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"

[jgust]

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

[dcd6406]

Excellent response - couldn't agree more!

[barrkel]

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

[mbesto]

^ 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]

potentially harder to poach people from the competition if you're both doing generic stuff but using proprietary, custom and opposite techniques?

[rbanffy]

That's a justification for writing an ERP in Brainfuck.

[alkonaut]

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.

[watertom]

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.

[JacobDotVI]

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

[muxator]

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]

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]

Agreed - great comment

[nitwit005]

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

[ghaff]

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.

[bassman9000]

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]

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?

[rbanffy]

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

[jhh]

I think Martin Fowlers remarks on customization are illuminating. https://martinfowler.com/bliki/PackageCustomization.html

[erikb]

This pretty much applies to _all_ software development as well, especially in a standard environment like ERP. There is not much need for new stuff, just learn the ropes for what already worked the last ten years, then handle the complexity of enterprise life with simply applying them. Creativity is only useful if you can handle >90% of the cases with ease already.

And for a customer of enterprise software I would so much agree. In my experience the people who manage the integration with third party software usually have no clue what the software is about. Instead of being arrogant it would be much smarter to learn from the software vendor, who's an expert in his field and has seen dozens of customer environments, how to solve certain problems.

[alistairSH]

I wish you worked for my customers.

[qubex]

I’ve rolled out SAP throughout all three of our SME-sized family companies. My mantra has always been ”we don’t install SAP into our company; we mould our company into SAP”. Ten years in and the strategy seems to have worked.

[trhway]

>we mould our company into SAP

exactly. People from "unique" camp fail to recognize that SAP isn't just software, it is "best [business] practices" coded into that software, the practices distilled from huge experience during many years with many customers. Granted, for many techies any business practices/processes and related software look disgusting - this is why we're techies, not accountants. At some point in the bright future we'll develop super AI which will take over the world and abolish business processes....

[acdha]

The psychology is fascinating. I worked at a place with a heavily customized fork of a vendor system which was almost old enough to drink. They had a stable of developers in an increasingly uncommon language, upgrades were year+ exercises with hefty consulting bills, etc. but most of the management were convinced that this was the easiest option because everyone was used to it.

[manmal]

Do you think enterprises can even profit from adapting to SAP‘s structure (streamlining etc), or do you think this does not matter anyway?

[fargozzi]

Sap brings transparency to the processes inside your company. You don't know what is happening in the mind of you accountant on the other side of the World. How bills are issues and if these are payed correctly and in-time? How do we choose credit control, who is approving purchasing spends? Internal and external audits could not see whole picture and they are not there all the time and even more - if someone would like to hide something from them it could be easily done in most cases.

[petepete]

The profit is in having the ability to upgrade on a whim, to refer to the masses of documentation and expertise without having to translate it into your own lingo and to use off the shelf components without needing to customise them too.

[manmal]

Ok, so no organizational benefits?

[rbanffy]

Perhaps you need fewer people maintaining those business apps.

[petepete]

Plus hiring and getting new employees up to speed is much much faster. This is especially useful with SAP consultants who are quite expensive. The initial cost may be high but once it's done it's savings at every step.

[manmal]

Well, adapting one‘s processes to a standard solution is a major change in your business, so I‘d expect some kind of effect..