Hacker News Reader

Comment by NikolaNovak | Hacker News Reader

And if it helps understand the ecosystem and its seeking oddness, this is the crucial part of article:

"Implementing ERP isn’t just a purchasing decision: it’s committing to redoing how you handle operations. Installing the software is the easy part; adjusting the whole company’s workflow is the most of the work."

Don't think of erp and implementing it as a software development challenge. Sure, Developers can fscrew up*, an erp implementation but they cannot make it succeed - it is fundamentally a business transformation endeavour and must be undertaken as such to have a chance.

View on HN

A good way for your organization to completely botch an ERP implementation is to fight the system every step of the way because your business is 'special'. Many people end up abusing customizations to the point of trying to emulate their old system in the new one, and nobody wins.

You just brought back some painful memories. At an old company of mine, I helped migrate a legacy system to SAP (of all things!), and they fought it every step of the way.

Well, management did. Every other phrase they uttered was "The old system did it this way" or "I used to just press F2". The pushback to learning something new was unreal.

Nevermind the fact that multi-step processes were reduced to a simple button click. Or that inventory and customer management were orders of magnitude better. The old system!! The old system did it another way!

I feel like you could replace "ERP implementation" with "business transformation project involving vendor software" and have a new Law.

The same with the parent commenter's thoughts, "Sure, developers can screw up [business transformation projects], but they cannot make them succeed."

> A good way for your organization to completely botch an ERP implementation is to fight the system every step of the way because your business is 'special'.

More generally, a good way to botch a business transformation project is to select technical solutions without a keen grasp of how they fit your business need, and to bullheadedly stick with those solutions as friction is revealed with the business needs.

Both distorting the business around vendor software and ending up continuously fighting with the vendor software throughout th effort (both of which are commonly cited “how to fail” routes) are clear (though superficially opposite) symptoms of that same failure occurring upstream in the process.

Written like a successful salesperson for competing ERP solution X, well done!

This is why it's important to tackle this from both ends:

- From the ERP end: you want it to be as flexible as possible so that it can reflect how the business actually operates and should operate in the future

- From the organization's end: you want to identify not only how the business currently operates, but how you would want it to operate in an ideal world

This reminds me of something I read while helping a business major friend with a case study a while back. One of the readings she had as background mentioned that companies like SAP that sell ERP are almost selling the process/workflow more than the actual software.

Part of me wonders if these things are more of a "no one ever got fired for buying IBM" thing than anything else. Are people buying the workflow because it's what they really need, or are they buying it because everyone else uses it?

1. You're absolutely right - you're buying software, a set of best practices, workflows, and a proven way to implement and use them.

2. HR, Finance, all the backoffice stuff - that's not your competitive advantage. It's not your core business. You just want to do it as efficiently and quietly as possible.

3. Therefore, in ideal case, a company realizes it is not a special snowflake, buys an ERP, implements it as vanilla as possible, and quietly goes on focusing on what IS their competitive advantage / core business... rather than spending years, millions of dollars, and tremendous risk, by trying to customize ERP to some obscure different process they just "must" have :-/

that happens a lot with enterprise software, too much customization and you end up painting yourself in a corner or run into roadblock after roadblock of platform gotchas. I do SF implementations these days and have seen it go great and have seen it turn into a total nightmare.

however, not once have I ever heard of an SAP implementation going well. It's a massive undertaking and takes total commitment from so many different people and roles in an enterprise. You need genius PMs and BAs along with a genius client team before you even talk about the actual technical people.

>>not once have I ever heard of an SAP implementation going well.

Sometimes it depends who you ask; I found that hands-on people on the ground and SMEs tend to be very negative about it, for personally valid reasons - it's a lot of work, it doesn't go smoothly, and it disrupts and changes what and how they do it.

However, there are quite a few ERP implementations where the top-level stakeholders feel the results are worthwhile the disruption and pain, and from that perspective it "went well" - the business objectives were overall met, whether it be capabilities or speed or reporting or integration/centralization or headcount or complexity reduction, all of it ultimately boiling to money at some level...

Now you're describing an implementation that is disruptive to the majority of employees "on the ground" and only worthwhile to the top-level stakeholders.

Only the top-level stakeholders felt the results were worthwhile the disruption and pain -- that they did not suffer.

But have you ever heard of one going well ?

As in, not just worthwhile to a tiny minority of the people on the top?

Yeah I bet it makes stuff more efficient, but clearly there's a disparity between the people suffering "disruptions and pain" and the ones who ultimately feel it has been worthwhile.

Another way to look at it is, the top-level stakeholders are responsible for the business and not just themselves or the lives of their employees. An effective leader is thinking about what is best for the business. Not just themselves or any one part of the business.

And maybe, just maybe, what is right for the business is bad for the majority of the staff. At least in the short term. I know that is a bitter pill to swallow, but it is reality.

> And maybe, just maybe, what is right for the business is bad for the majority of the staff. At least in the short term. I know that is a bitter pill to swallow, but it is reality.

Perhaps an example more palatable on HN would be Uber replacing all its drivers with software. Clearly better for the business.

The process often derails at exactly the “implement it as vanilla as possible” stage. Usually because someone doesn’t want to change what they do and someone else doesn’t care enough to make them change.

Another view of this - if the true purchase is of a group of workflows, are they purchasing for the things they know they need or the assurance that behemoth IBM/SAP/whatever has a process for whatever they didn't think about? Purchasing to minimise some future operational risk.

This is probably an understated benefit a lot of us in tech don't think about.

If you're selling widgets, and selling 100 units a month, there are growing pains on the path to 100 units a day and 100 units a minute that you can't anticipate, and that billion-dollar retailers have already figured out. So I think to the extent that physical B2C sales is pretty constant across industries, you know that if you're big enough to justify the investment in SAP or a similar ERP platform, there exists a process that you'll need 0.5, 1, or 5 years from now that they have and you can't really articulate today.

Sounds like Agile to me.

Some industries need your system to be certified for a software system to consume their data/services. You don't have much choice.

Reply on news.ycombinator.com