Comment by tqi

My impression is that most people don't understand just how awful most commercial business software actually is.

One thing our business does that every other business does is vacation and overtime tracking. We have a custom in house application for that and we've yet to find a commercial replacement that is, in anyway, half decent. For most Payroll/HR systems, this is merely an add-on feature and doesn't get much attention.

For overtime, integration with our financial system allows overtime to be charged to the correct files and this is something that nobody does (or does well). Probably doing just this little bit makes this project pay for itself.

I think most moves to EMRs were insufficiently disruptive, e.g., electronic orders recapitulate the old paper orders without using the opportunity to reduce ambiguity and insert constraints to prevent common errors.

That’s a legit issue. What’s the value of changing a deep seated process?

I have definitely seen examples on both sides of that question. Especially in a place like a public university with multiple collective bargaining agreements. The unions aren’t going to accept significant change without some sort of cost.

Typically, since processes are built around the system, nobody understands the actual business needs.

Nearly all our long-term tech debt come from having to work around limitations in the commercial software we use.

Personally I hate software customizations. I prefer to build from scratch using proper software development tools than use whatever piss-poor customization system commercial software typically provides.

I recently sold my director on building some software from scratch rather than try to combine two commercial products together for some Frankenstiened solution. The motivation for Frankenstiening it is that we are paying for both services so we should use them (and at least one is very customizable). Only after 6 months of failing to get these systems to play together in an acceptable way, I finally asked a team member to spend 3 days building a mock up of a new app. From there it was quickly approved and we hope to roll out next month. I only wish I had done that sooner; we would have had way more time for development.

On "retooling SAP": SAP deliver their systems with all source code and dev platform included, and that may help convince some customers to go for SAP.

However, those that embark on deviating from the well-trodden path are going to be in trouble soon: after every update, potential changes made need to be re-done or edited or at least tested. So as the parent suggests it's really better to adjust the business process if you can.

There's a ton of variety out there in the real world such that you'll always find a few businesses that match almost any scenario you can imagine. So, yes, for some business doing a process a certain way is a competitive differentiator or advantage ... or even a necessity for their particular industry. For these businesses banging the SAP square peg into their special BP round hole is worth attempting. Even better might be just building their own custom round peg. I'm suggesting that many (not all) businesses are doing a BP a certain way for no compelling reason whatsoever other than that's the way they (almost randomly) picked to do it decades ago and could easily change to a standard practice without loss of competitiveness (maybe even gain by focusing on what does).

> There's a bit of selection bias going on there though. The reality is that SAP and similar products are designed for a business that works a certain way

ERP products are designed following "standard" or "best" practices/processes. It's common to see companies first contract a consulting company to "re-design" their processes before they then try to implement an ERP system.

I use as much off-the-shelf as possible. But there is real work involved in adapting software to a company's culture.

If you do it right, 99% of the work has already been done for you by an existing SaaS or FOSS project, and "all" you have to do is customize it. And generally this doesn't mean "change the config" but rather assemble different building blocks into the right shape.

This can still be a multi-year project, even when you're writing almost no code. It takes a long time to understand an existing company's culture, processes, and needs.

"IT will tell you what the new process has to be" is usually a pretty tough sell.