Hacker News Reader

Hacker News

Comment by ethbr1 | Hacker News Reader

Parent Full thread

ethbr1

There are two different scenarios.

Scenario 1: You're doing something that every other business is doing. E.g. ERP/accounting, sales, contact center, etc.

Scenario 2: You're doing something few other businesses are doing. E.g. your actual customer business, creative, etc.

(1) is amenable to making your process fit software, to good results. (2) is usually a train wreck.

Unfortunately, figuring out if your thing is scenario 1 or 2 is non-trivial.

Canonical example: EMR/EHR systems in healthcare. You think they'd be the same... but actually there are so many integrations with other systems and/or different sorts of specialists, that a real world implementation has substantial functionality gaps (papered over with custom work).

View on HN

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.

Beside the lack of attention, you also have gargantuan legal requirements you need to integrate. Which change all the time. Sometimes a few per country.

This is for everything: pay, vacation, etc.

It is really complicated.

One advantage of building in house is that you're only building for your own company. This is significantly less work than building commercial software for multiple clients (which I have also done). I can't overstate how much less work this is and how much of a better experience it can be for users.

As an example, for calculating annual vacation entitlement, we have some pretty complicated rules. But every company in every country has their own set of rules so most HR software doesn't bother calculating it -- you just figure it out manually and input it every year for every employee. But because we just have one "client" our rules are just code that we can change as needed and can arbitrarily use whatever information we have. This saves HR a ton of manual work all the time. But this only works because it only needs to be one set of hard-coded rules.

The problem when building it yourself is that this is usually done by "generic" developers who discover edge cases (often together with the requester) that threaten the whole model.

A company doing payroll for us ("us" being a multinational company) asked for a "typical payroll" to start with. Fortunately we had experienced people on the pay side who discarded the company because of this question (for one they should know, and for two they should know that "typical" will cover maybe 60% of the cases -- I thought that this was an exaggeration until I discovered the reality of calculating pay in France)

A good company specializing in "pay" or "vacation" (which are very regulated over here) will know the "typical" case and the edge cases.

> has their own set of rules so most HR software doesn't bother calculating it -- you just figure it out manually and input it every year for every employee

Beg to disagree. This is the complexity that large ERP firms handle and why Oracle, SalesForce, etc are expensive to implement. They figure out the commonality (if any) and build for it. Then they add on features specific to countries they target and then they add the ability to configure for your own situation (to a certain level).

PeopleSoft did this for Payroll and workforce administration which is part of how they cornered the market for HCM.

Commercial business software manufacturers are isolated from the users and in a way isolated from consequences as long as they fulfil the contractual obligations (which practically never has a 'make the users happy' stipulation).

I think this is why you only see innovation via alternatives vs within a product.

E.g. Salesforce, Workday rising up to replace incumbents, but then themselves becoming stale.

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.

The problem is that the paper form is the interface, because the ecosystem was designed around it.

10 years ago or so, I asked a health insurance company why a specific digital form could only list up to 16 diagnostic codes (otherwise a duplicate with the additional needed to be created).

They thought about the question for a second, then said that's how many were on the paper form the digital system had been created from (35+ years ago).

Reply on news.ycombinator.com