Live data from Hacker News

Software horror show: SAP Concur

blog.plover.com

71–80 of 204 posts

Re: Software horror show: SAP Concur

#71
We actually joke around the area where SAP is located (Walldorf, Germany). In surrounding cities devs joke about the fact that there are literally dozens if not hundreds of web agencies doing nothing more than mobile/tablet ready SAP user interfaces. That's their only business model.

I'm not kidding you, there's an entire ecosystem around the fact that SAP UI5 is so crap that people cannot use it on their smartphones. And concept-wise it's built very similar to the early jquery-ui releases (remember the first iPhone's menus? Yeah, THAT old), but only in undocumented and even crappier.

I don't even know how to rationalize this anymore. At one point I ditched every company that uses SAP, but it's like the plague. You can't avoid it.

Re: Software horror show: SAP Concur

#73
post #12

These kind of bad UX problem can be easier to rationalize once we understand the money flow. Would you stop using it because of such UX? Would your stopping cause the company to stop procuring SAP? Was the search the selling point in the first place when the sales representative pitch the software to finance department? Probably no, no and no. So are all other bad UXes. And we can probably wager that a better UX does…

The is the hallmark of bureaucracy. Seperate the functions, and then let each team externalise the costs without any checks and balances.

Finance purchase Concur because it solves their problems and integrates with their existing tools. They don't care that people hate it, or that it wastes the company's resourcing when people are fighting a broken UI instead of doing their day job.

Normally engineers are shielded from this pattern in their day jobs. But I have worked at companies that have gone the other direction. In one I met with a risk averse gatekeeping team and told them that for a newly acquired product we were not going to be able to meet the (arbitrary) SLO for the glut of tickets they assigned us, and asked for help. Their suggestion was to pull the app from market.

Re: Software horror show: SAP Concur

#74
post #8

This is common for software where the people who take the decision which software to buy are far removed from the people who are going to use it. No product manager cared about this, because this feature needs to work only well enough for a sales pitch, if even that.

> software where the people who take the decision which software to buy are far removed from the people who are going to use it

As far as I'm concerned, that's the definition of enterprise software.

Re: Software horror show: SAP Concur

#75
post #8

This is common for software where the people who take the decision which software to buy are far removed from the people who are going to use it. No product manager cared about this, because this feature needs to work only well enough for a sales pitch, if even that.

100% agree with the buyer not being the end-user.

As long as the product supports the needs of the buyer (administration and reporting, rules engine for product selection, etc.), the needs of the end-user can be neglected. HRIS software (PeopleSoft, SuccessFactors, Workday, etc.) is the same way. The deals keep close and the checks keep coming in.

I don't think it's fair to say with a lot of this software that no one cares, though, just that the business as a whole adds up to a poor frontline experience.

It would surprise me exactly 0% to learn that there was a whole "improve the Concur UX for frontline users" team who repeatedly get their feature asks deprioritized in favor of something needed to close a deal.

And, also consider that when it comes to these sorts of big enterprise products, many are drowning under 20+ years of trying to support every bizarre customized customer corner case, third-party integration, and often with no ability to deprecate an old feature. Perhaps adding sort capability breaks some arcane customer scripting functionality added ten years ago which is poorly understood, but cannot be removed due to a clause in the MSA.

Re: Software horror show: SAP Concur

#76
post #8

This is common for software where the people who take the decision which software to buy are far removed from the people who are going to use it. No product manager cared about this, because this feature needs to work only well enough for a sales pitch, if even that.

[deleted]

Re: Software horror show: SAP Concur

#77
post #44

This is the least of SAP's crimes against software. Pretty much everything SAP builds is janky and awful like this. If you're lucky, "minor" UX problems like these are the only thing you have to deal with, but in the vast majority of cases, that's not going to be the case. Where I work, I also have to use a SAP system for expense reports. I can't even tell you what it's called, but the interface is basically just dir…

[deleted]

Re: Software horror show: SAP Concur

#78
post #45

Earlier quoted context omitted.

Used to use concur in a past life, now expensify. There's not even words for how much better expensify is. It wasn't _that_ bad for a lot of entry types, but for me what made it a constant problem were hotels. It wanted a daily rate and number of days. Yet our rates were different day by day, and it made you do a separate tax entry. So you're having to BS a close enough "daily rate" and adjust the tax field of a spec…

You can enter each day manually now, with fees. It’s been this way for at least 7 years. That’s how long I’ve been filing expense reports with concur for hotels.

I do remember that being a thing, but I think with the way it auto populated from our booking system meant I couldn't use it. It's been a bit, but I'm pretty sure I had to go through that realization each time too

Re: Software horror show: SAP Concur

#79
post #60
post #41

Concur's backend is typical of a slow moving industry that works with old awkward systems like airlines. It's a shitshow of business logic and 20 year old legacy code that would be a long expensive nightmare to rewrite for little actual profit so no manager would ever approve of such an endeavor. I wouldn't be surprised if there was a mess of queries involved with this search such that trying to do a real sort of the…

They need to call a sort function. It can happen in the client, because the data set is small. It should have happened when the app was first written, at which time they weren’t maintaining legacy code - they were writing a UI from scratch and could make changes easily. Sort functions are built in to every programming language I’ve ever used. I agree with the author. There’s no reason for it to be like this but incom…

I used to work in a system where seemingly trivial sort()s would break the entire stack.

It is entirely plausible that a sort is nontrivial.

Re: Software horror show: SAP Concur

#80

As the author mentions. This was a failure on and down the chain, from QA to PMs. When I see software like this, it reeks to me of contractor work. We hire them to handle something that we don’t have time for our core team, and or something not very important. The result is the devs do a minimal job to get paid. QA doesn’t care and the PMs either didn’t see it, or have bigger fish to fry.

When you say "contractor work", do you mean agencies, or the work of individual contractors?

Individual contractors in my experience tend to be very good (above average) and do care about building quality software - their reputations depend on it.

Agencies on the other hand are a nightmare. I have nothing against junior devs but in my experience agencies love to put junior devs on projects they're unqualified for and then give them bare minimum support and guidance. And obviously they'll happily cut corners because technical debt is their problem so most stuff is hacked together so it just about works, but is utterly unmaintainable.

Post reply on HN