Hacker News new | ask | show | jobs
by hinkley 1658 days ago
I’ve hear the way to succeed with SAP is to reorganize your business to match either the default world view or some other cookie cutter variant. Essentially using it no code style.

Otherwise you’re exerting yourself doing “normal” things. That’s not sustainable.

6 comments

All ERPs are fundamentally like that.

At the end of the day you are purchasing a COTS product specifically to gain efficiency of industry best practices already coded for you.

If you take a COTS product and then try to rewrite it to fit your "unique" business processes, we'll, that's why half of them fail.

Implementation of erp is incorrectly and disastrously viewed as an IT project. It is first and foremost a business transformation project. A company should be self-aware to say "HR|Accounting|whatever is NOT our core business or competitive advantage; it's not what we are great at. It's not a thing we should be unique in. It's a cost centre and we need to standardize and minimize that cost with help of people and software that were successful with many other companies".

(Source: I've been implementing Peoplesoft, a competing erp,for 20 years for dozens of companies, as a technical resource eventually wise enough to be aware it's fundamentally not a technical endeavour :-)

This is why my company has custom applications that talk to the ERP for certain departments. Inventory control in the ERP isn’t going to work with reality. The data modeling is good enough but the interface is not.

Rather than train everyone we hire to use horrifically bad and expensive barcode readers, we purchased cheap smart phones, put them in cases, and locked them down to run an app that uses the camera to scan barcodes. Drop a phone? It’s encased in rubber. Run it over with a forklift? Toss them another one from the box and then figure out why this only happens on Tuesday afternoons.

We already need a dev team for other reasons. Adding another decent programmer to create and support internal apps isn’t that expensive in the long run. Plenty of good devs like me who are happy to work remote from the Midwest at less than FAANG rates. :)

> This is why my company has custom applications that talk to the ERP for certain departments.

This is the best approach. Inventory is a great example of something that is both very important to an ERP and needs to be modeled impeccably if you want accurate costs (think license plate numbers tracked back to manufacturing), but at the same time you sure as hell don't want your ERP to be the "system of record" for operational systems.

It was a very humbling experience working with accounting and finance to close the books and update forecasts.

My wife worked for an association that got bit badly by the one true platform bug. They had an excellent publishing platform, with features that were then incompletely implemented in whatever association-management platform it was. I couldn't imagine why a clean, limited interface to the platform couldn't have been implemented at less cost. She was fortunate to be gone before the change was implemented.
Yup there's a few approaches. These days most ERPs have nice semi-modern interfaces making mix-and-match easier, but honestly over 20 years I've seen industry go through 3-4 long cycles between preferences for single-vendor/stack homogenous solution, or "best of breed" mix (I know, buzzwords all but sometimes handy:). It seems one of those things that goes and comes around....
This outlook is actually endemic in the ERP implementation space.

The part you're not going to like hearing is that, due to laws/regulations, that "default world view" may be the best way to approach that problem for that given module/area (e.g. how to structure benefits or compensation). "Creativity" in the ERP space is costly.

Also reducing your variation to something that's configurable as opposed to custom codebase means you don't have to do extensive testing whenever a patch or upgrade to the ERP software comes out.

That's almost every ERP system....

You could customize it to match your business, but 90% of the time that would cost more than reorganizing your business.

One of my biggest customers was bought by their competitor after a big SAP implementation. The consensus amongst management was that the project weakened them so much they became vulnerable to takeover.
Yep, this is the SAP way.

Either you match your business to the SAP Way or your multi-million SAP integration project will fail. There are no other options.

You can theoretically prolong the inevitable by modifying SAP to fit your business model, but then it'll just break and fail during the next update.

Twenty-odd years ago we sat through presentations by Peoplesoft implementation consultants. When I looked through my notes, I found that all of them said, with slight variations in the wording, "you have to do it Peoplesoft's way." I'm sure they were right.