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.
> I don't even know how to rationalize this anymore.
Enterprise IT is like that because the buyer never uses it and often assumes anyone complaining is just whiny/lazy.
A previous employer had a massive outage with an expensive ’Orrible reporting application: down for weeks, developers expecting them to repair corrupted data, etc. They paid many millions of dollars to license that app and millions more for “support”, so you might naively think that someone would demand better results. What actually happened was that the regional sales VP got our VP the corporate box for an NFL game, and Monday morning the edict went out that the problem was resolved and should not be mentioned again. Dozens of people spent the next few weeks continuing to fix things up but understood the message and didn’t include it in their updates to the senior level.
It wasn’t but also I’d expect something like that to be very hard to make a case about: courts tend to be very deferential to business judgement and I’m sure they’d have very good lawyers arguing that the original problem was unforeseeable and this was maintaining an important business relationship (“the cost of switching would be astronomical!”). This kind of stuff tends not to have consequences unless it’s unbelievably blatant in writing or the higher ups are looking for a justification to terminate someone.
The goal of whoever chooses the ERP software is to have people make fewer decisions. Whether it takes you 5 or 15 seconds to figure out what to do next/record what you've done is of much lesser importance than what to do next/how what you've done is processed.
That's one facet of such software. But another facet, and by far the largest by ongoing expense (as in amount of people-hours it consumes) is just data input, with little to no decisions to be made. In SAP Concur case, one example I painfully experience is reimbursing business trips. In other cases, this may be timesheets, or inventory, or point-of-sale ordering and invoicing.
The "UI could be improved" is really understating it here - there are low-hanging fruits that could cut down the time spent on data input by factor of 5-10x. This I know for a fact, because I can compare my own experience (e.g. various timesheet & expense forms I used over the years, and the hypothetical case of me preparing the report in Emacs in some structured format, and bulk-importing it to a tool - that's easily a 20x time save), or observation (POS software used in stores today, vs. the DOS-era tools they used just a decade ago - close to 10x the difference).
We're talking extreme waste of money here. Plenty of shops I've seen are bottlenecked on the POS software UI - meaning they either have to let X% of customers go, or support extra registers and personnel. We're talking mental blocks that make people redefine workflows - every place I worked in that required timesheets and expense reports would see people doing them weekly, monthly, or quarterly, instead of daily (as they're supposed to), because the UI is such a time waster that everyone wants to put it off until HR starts complaining, and then back-fill it in bulk. And don't get me started on how shitty UI in healthcare impacts the quality of care...
> I don't even know how to rationalize this anymore.
Bad UI doesn't matter, while the company's exec is golfing with the sales rep from SAP. And after the deal is done the exec has an assistant responsible for filing expenses etc.
What then counts for the exec are the reporting features, where somebody can send them a nice report on all the expense bookings, accounted for tax and all those complicated things, and agreggated per depertment etc. and knowing that expenses which can be passed down to customers are put in the invoicing systems ... that's the area where the value of such systems lies. Not in usability.
I can't use SAP on my phone because it's rooted and they block that. I have literally no idea why. I'm not going to commit fraud, and if I was going to, having a phone I control would not help matters in the slightest compared to receipts or (more likely) a partner who gives me a kickback under the radar -- like booking.com does for people who say they travel for business, for example.
It's worth noting that SAP Concur wasn't designed by SAP. They acquired it. It's had some minor UI tweaks since, but for the most part is unchanged from the pre-acquisition product.
If by "minor UI tweaks" you mean "destroyed the platform" then, yes, it has had some work done.
Their most recent announcement is the reintroduction of the ability to drag-and-drop receipts onto expenses. Not in the list view where everyone used to do it, mind you, but maybe someday they will bring that feature back as well. Maybe they will eventually bring back their outlook program that lets you upload an email as a receipt too!
Former ABAP developer here - there are a lot of cruft and technical debt in the core but they can't easily change it because it's behaviour is certified and accountants trust it - so they wrap the old crud into sexy JS and cloud bindings but you can only go so far with that.
So they expand by buying up other companies and slapping their interfaces on it (you shall use HANA and not Oracle or anything else).
The entire sales pitch for SAP is that Oracle and Microsoft based solutions tend to fail even worse then SAP based ones, and that there is no real success stories where a smaller vendor/startup have manged to deliver anything that comes near handling the complexity the old mainframe/minicomputer systems people are trying to replace can.
Why would I use my ERP system on a phone to begin with? IMHO, this market comes from management, and other people, unwilling to work inside an ERP system. And the clout to get away with it.
Not every piece of software has to be a consumer app.
It's not that you'd necessarily want to use the ERP system as such. It just that many companies have base pretty much everything on SAP.
Perhaps you're a fields technician. Your assignments are managed by SAP, inventory is managed by SAP, the customer is managed by SAP, you, yourself is a resource managed by SAP. You venture out to fix a wind turbine, now you either need a laptop and remote in to enter things into a convoluted SAP setup and navigate the myriad of screen in that thing, or someone, perhaps SAP (the company) or some smaller company they bought attempted to bolt on a web GUI or a mobile app, as to simplify the work for the technicians.
There is an entire industry designed around building application to abstract away the SAP client and provide simpler interfaces.
The people buying the software don't have to use it, would you buy your corporate underlings the comfortable, expensive shoes or just enough rags to painfully remind them who their masters are?
SAP produce the lowest cost rags in town, and you will learn to love them.
There's nothing cheap about SAP. It is just the opposite. They sell the most expensive software ever for any given need. But they make sure to promise their victims that the software covers any possible business "need" under the sun, so the CTOs feel coerced to pay the hefty price.
SAP, at its core, is an ERP system. Those, in turn, run around MRP (Material Requirements Planning), all in xompliant and auditable manner (if used properly, that is). There is a reason why ERP systems rule the manufacturing world, and SAP rules ERP systems. All the chatter about CTOs going golfing with some SAP sales rep not withstanding, SAP is a very solid system and used by very sophisticated folks (ideally, if not, well, you cannot blame Red Bulls latest Formula 1 car if I crash it in turn one).
So, if you are a manufacturing business, MRP is a must and SAP an expensive but solid choice. If you are not, and thus don't need MRP and ERP, well, you wouldn't use a semi truck for your weekly groccery shopping neither.
People who only look at the UI, and then not even the UI of the core funtionality of an ERP system, and then dump on, e.g. SAP (all ERPs are the dame but different in that regard), just show that they have zero clue what those ERPs are supposed to do and how they are supposed to be used.
That’s for the golf course. Same as IBM: The business model is they mostly sell golf courses, and software is a side-effect so they have to save on that.
I was sysadmin for IBM software in a 50k-people company, there is no way they paid 12m$ for ClearQuest, ClearCase or RequisitePro when Git and Jira were already out. They clearly played golf to win this market.
I hate submitting expenses probably as much as the typical engineer, but Concur seems “no better, no worse” than the typical dumpster fire of these systems.
I will say that it does have good integration between the company card transactions and the expense reporting feature.
I am more mystified than the author at why my 75-mile range electric car offers a default sorted list by full street name, then by state, happily inquiring as to whether I intend to drive 225 miles to my entered street name before a matching entry that’s 4 miles away.
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 specific day to adjust for any single penny rounding errors. Then there were resort fees or other things, which it would also make you call out but I think it even had a fixed number of "extra fees" input boxes.
For a set of a few non travel expenses it was only a bit worse than any system ought to be. For travel it was practically unusable and for reasons that actually butchered your report
I use Concur and just enter the total and enter X nights in $CITY for a justification. I don't need to enter nightly total much less any sort of breakdowns. As I said in another comment, a LOT of Concur (and expense software generally) pain relates to the hoops a company makes you go through as opposed to the software itself.
When we first implemented Concur, there was a lot of kvetching. A bunch of requirements got dialed down and while there are still a few silly things here and there, they're easy to work around once you know about them and it's mostly just the very random audit thing at this point.
Disagree. I've used Expensify at a couple smaller companies and a couple versions of Concur at megacorp. The earlier versions of Concur (ca. 2015 – unsure how far behind the current version we were at the time) required you to fire up a VM and use an ancient version of IE to use it. The more modern version was a bit better in that regard.
Expensify though, that was like this interview I had where the CEO walked in at the end, introduced himself, and then explained he wanted me to make their web site "Web 2.0!!!" as they pivoted away from their core business. They hit all of the buzzwords. Ugh. Unfinished and buggy to the point where I fired off an angry email to Expensify for being so shit.
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
i had the opposite experience where i moved jobs from and the transition from concur to expensify was brutal. duplicate or blackholed entries and submissions. obfuscated mandatory policies. obtuse allocation methods, and per diem breakdowns felt as though they were being actively hostile to the user.
expensify felt like a jr. high coding project and i hated it to the point of putting a time tracking line item in for expense reports.
I'd hazard a guess that it's because it's sold to finance people that value that sort of functionality (reconciliation of bank statement events with expense claims). Not much thought is given to the end users that have to put up with these tools.
The issue is a typical moral hazard, where the people who buy the software aren't the ones who have to bear the pain of using it.
The requirements from the finance team were probably all around “expense coding is mandatory” and “pick things from a list to avoid typos”; i.e. things that make their lives easier.
When it came to user experience, it got a ¯\_(ツ)_/¯ or no consideration at all. After all, most finance people rarely if ever travel.
SAP has little incentive to put effort (money) into fixing it, because (1) they’ve got an ecosystem of third parties that do that and also probably serve as resellers or at least evangelists, and (2) complaints are going to help desk, not finance, so SAP’s paying customers aren't advocating for a fix.
Executives are just handing their EA’s a wad of receipts; they don't feel the pain either.
Of course, Google Maps seems to be equally random when it starts guessing your destination.
I reluctantly started using a corporate card for most things because I sort of had to. I don't like not getting the personal benefits but it actually does make (most) things easier with Concur. Only real issue is it's harder to split personal and company charges.
Yes. But it means that all the expenses are accounted for and added to the expense report even if I need to add receipts for some of them and may have to add some additional information, e.g. category. As I say, not my choice but it probably captures some random fees etc. that I otherwise tend to forget about.
Depends. Most companies would have you specify the project/cost centre for every purchase, but amounts/locations/etc are automatically provided by the card issuer.
We used Excel based expense reporting for years, it takes me much less time to assemble my reports on concur, I rather like it, its the least of all evils.
Could it be that by using Excel you just move complexity of reporting to someone who have to extract these data from Excel and import it into some system or analyze it?
After it was sent off, Accounting might just decide to not pay it because no receipt for the coin-op laundry machine I used, when I pointed out it was coin-op laundry, they just shrugged, and then approved it. Meanwhile, while they dicker I'm sitting on multiple thousands of dollars of expenses.
Other issues were making sure I had the correct form, multiple approvals, etc. Now before this process, we used all the same forms but printed out.
Using Concur -
A) the the app to scan my receipts
B) attach receipts to company card expenses
C) deal with some drop downs for some stuff concur has flagged out of process
D) send to manager
Now I lost my per-diem in this, but they cover everything now with the exception of tips to the housekeeper (I've just not tried it yet).
The downside is any payments from the company now take multiple weeks, lol.
Using the excel process, would take me about 1-1.5 hours per week of travel, under Concur its about a about .5-.75 hours per week of travel.
Depends on the company. If they don’t really care it’s more evidence/proof of expense than anything.
My last employer used some stupid Oracle system to audit the hell out of everything. One time I was flagged for taking a suboptimal route that increased toll expense by $3. Hilarious. I spent like 1.5 hours @ $90 on justification of $3.
Yeah, our automated system (Concur) does end up insisting on justifications for why you picked the 12 hour direct flight which is $100 more expensive than the three options with 2 stopovers and a total travel time in the 18-20 hour range (or sometimes even overnight stays in airports).
Feels like a lot of the goal in these systems is to try enforce rules that no person expense manager could try insist on with a straight face. If even 10% of the company gets scared off by the justification demand and books the inconvenient option, that's $20k/yr saved.
Which is still probably peanuts compared to what Concur costs, but that cost is somebody else's problem to the finance person who gets to claim savings on annual flight costs.
My company uses a horrible SAP interface. I then had the complexity of making an Excel sheet that actually works, and making it properly interface with SAP so I only have to use the excel sheet.
As a SAP developer there are so many ways to read Excel sheets but they all suck in one way or another - SAP itself does that but it depends on which SAP module you are programming in (MM/FICO/EWM) so each module has a mediocre implementation to read in XLS.
Somebody got fed up and did a general purpose XLS import library, but some sites forbid you using it.
Without good validation (possibly including locked sheets), people will make all fashions of inconsistent entries that “look right enough” but will stymie automated ingestion.
We had some hellish “use Excel as an interface to ‘real SAP’ process” for budgeting/headcount planning and it was almost utility-free for us as users. Even doing copy/paste would break parts of it, but invisibly to the user in real-time but would fail on import days/weeks later.
You never did this, so you dont know that even the "simplest" thing like writing an address can be done in 50 differenr ways, and then someone has to clean up the data before importing.
Of course you can partially prepare for it by making a file where users have to pick things like town name from a scroll down list (hope your list has every town), but they still can get "creative" and mess it up.
It's not so much complexity as it is removing manual process steps and reducing all the risks and overhead associated with taking data on one format and loading it in to another - at scale
The software we used before Concur was definitely better, or maybe it was the original version of the software before SAP bought them, I'm not sure. Prior to the switch, expense reports would take 5-10 minutes. After the switch, more than an hour easily. They made a lot of changes to Concur to try to help speed up the process, and fill gaps where the old software worked great. However, the final product still ended up far less efficient, and far more confusing.
I had designed a simple excel file and upload template with my piss poor accounting system years ago but, of course, head office wanted to use concur so now it's a bit of a mess and our compliance is far worse than it was...
Automating policy always ends up manifesting all of the crufty, imprecisely implemented “people” and policy issues of an organization, just using computer UIs. This often restricts these kinds of systems from UI / user delight greatness.
I've used Concur and Certify and they are oodles better than the crappy one that my company now uses that probably hasn't changed since the early 2000's and doesn't have any sort of mobile support for uploading receipts.
At my old job, I was jealous of people at other companies who got to use Concur.
Whatever Concur's flaws may be, the system we had was obviously worse.
"Wow, you take a photo with your phone and it goes in an app? Wish we had an app. Instead I have to submit it on a website, print the cover page as a PDF, collect all my receipts as further PDFs, merge the PDFs, and then send them via email with a single PDF attachment."
It had to be a single PDF, the system would reject the email if it had more than one attachment. Given it was a computer program not a human at the other end, I never worked out why we had to send it via email, as opposed to just uploading it via a web form.
At least I knew enough to merge the cover page PDF and receipt PDFs into one using Ghostscript. A lot of less technical people, they'd print them all out then scan them back in.
At one of my two career employers, to create an electronic deposit for your paychecks you had to:
1. Email payroll asking for the right form (an excel sheet would arrive via email)
2. fill out that excel sheet that had no validation at all, just formatting. you enter your bank info, amount, etc. If you needed more lines, you had to "attach another sheet".
3. Then you printed that,
4. signed it,
5. scanned it, and
6. emailed it to payroll@the_company,
7. who would call you and tell you what you did wrong, and then
8. they'd just do what you said over the phone anyway.
Yes, the excel sheet existed for no reason other than to align your typed text on the resulting printed page properly. It of course had giant "Do not edit any cells" on the top in red.
Reminds me of the time I had to fill out an expense report to get reimbursed by a company who had flown me out for an interview. It all had to be done in Excel. Unfortunately my bank account number was very long, which caused Excel to round down the last two digits. My reimbursement went into someone else’s account who then flagged it to the bank before we got it all straightened out.
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 results would require a significant degree of rewriting and touching scary code with huge amounts of bureaucratic review in order to be DOD compliant, so it gets labeled as "good enough" even if the current state drives some developers crazy.
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 incompetence - either at an individual level, system level or both.
In 30 years of programming I've worked in plenty of systems where this sort of thing is nontrivial too. But its always the result of incompetent abstractions getting in the programmer's way.
Downvotes notwithstanding, I stand by my claim that this is always the result of incompetence. Either at the small level (laziness) or at a larger scale (incompetent system design).
I would even go as far as saying the opposite - engineers too "competent" for their own good.
I've walked in to so many code based where very talented individuals have made incredibly complex systems, using all their technical know how of best practices & patterns, abstraction layers and facades ... and ignored the fact that all they needed was a three field form with a submit button.
It's not just worth knowing if you can, it's if you should.
The novice creates simple work because she isn't capable. The apprentice makes unnecessarily complex designs to impress. The master makes things simple because extra work would be unnecessary. Mastery isn't measured by much complexity has been added. Its measured by how much complexity has been taken away.
It’s also very possible this list is configured by the IT department that purchased Concur. If this list is always set by purchaser configuration, not sorting kind of makes.
The IT department does not make purchases such as Concur as it is way out of their core competency.
It is the finance department under the auspices of the CFO / the managing director that do. Those people are non-technical and don't understand the technology. Therefore, anything that is more modern than an abacus is pitched (and ususally later sold as well) to them as the best thing they will have ever seen.
You are probably right. I've just tried same query ("los a") in Concur app and it was sorted alphabetically for me. Still included Spain and Chile locations though.
SAP Concur is a complete nightmare for managing expenses. It's so bad that it will ruin your entire weekend, leaving you feeling frustrated and drained. The interface is a convoluted mess that is practically impossible to navigate, and entering expenses takes forever.
The expense categorization system is an abomination that will drive you insane with its constant mistakes and errors. The approval process is a black hole that sucks up your expenses and never spits them back out. I feel SAP Concur is the worst software ever created for expense management, and using it makes me wish I never had to do expenses again.
Expensify is so much better. The OCR isn't great though
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.
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.
Usually I would agree, but SAP and other ERP software are handled differently from most other software procurement.
Procurement is one of the core functions of the SAP ecosystem, so those most closely involved in buying it here are usually the ones who will be using it.
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 directly from SAP GUI(except embedded, very poorly, into a website) and every single interaction you perform results in a sync query to the backend, freezing the UI until you get a response.
The worst part is that no one really cares. SAP doesn't care. The users/companies that are stuck with SAP don't really care, or at least if they do, well, no one is going to spend valuable dev time on building their own internal expense registration platform(or whatever) just to fix something that sucks to use, but otherwise "works".
I also have to register my hours, being a consultant, and this also happens via some SAP system. One thing my current project manager told me recently is that the description field that we have to use to describe what work we did is just invisibly cut to 40 characters on the backend. I can freely type a whole essay describing what I did, but the pm reviewing will just see 40 characters.
Assuming that any sort of thought goes into most of SAP's software is like trying to reason about an insane person's behavior. It's completely pointless since there is no reason involved.
A reader who is a former employee of SAP has sent me a technical explanation of how this could occur. The explanation makes a lot of sense to me, and I have updated the article to include it.
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.
That’s funny. I used to work for a high-end consulting company, and we always marveled at the level of dysfunction in our clients’ IT departments. They would call us in when their devs couldn’t/wouldn’t do the work. We were pretty expensive by comparison, but at least we got the job done. I guess it just depends on the kind of contractor you hire.
Typical consultant mindset. They cant fathom how big IT got into the situation they are in due to legacy software, mergers, and periods of no investment. They only do greenfield projects and have complete disregard for IT’s processes.
What’s funny is the big consultancies are usually to blame for stupid IT or they make bean counter decisions to not invest in IT. Thus the reason we need chop shops to come in and and help. Oh, and god forbid we add an FTE with domain experience who can help us.
I didn’t sense all of that from the comment, but you’re definitely anti-consultant.
Sometimes consultants are brought in specifically to bypass whatever internal processes are in place. Those internal processes are sometimes the very reason not enough is getting done and external resources are brought in.
I would say that GP comment definitely has a “normal teams are useless until consultants come in” view, which the parent comment also seemed to pick up on. Specifically, this part bugged me:
> They would call us in when their devs couldn’t/wouldn’t do the work. We were pretty expensive by comparison, but at least we got the job done.
This makes it seem like the developers just didn’t want to do the work or it was harder than their skill level, which, realistically, isn’t the case.
FWIW I agree that consultants have their place, especially as a way to work outside of the typical system, but I’m not about to ignore that GP practically made it sound like consultants are better than regular developers.
As someone who works in big consulting I understand the frustration but have to disagree. A lot of the time we have great people doing great work but we can only take it so far. Clients have to both be willing (want to) and able (have people with the appropriate skills required) to change. If we aren't guiding implementation and leave it to the client often times it will just fall in a heap, out be forgotten about
That’s funny. I’ve recently been involved with several projects steered by high-end consulting firms. They were all complete shit shows, most of all the SAP projects.
The problem IMO is, that on the corporate side, you often don’t have any IT knowledge at all. So they hire consultants to ask them what to do and don’t have any way of confirming if what they are being told is sane advice.
I’m also really shocked by what the likes of McKinsey of Accenture get away with regarding the quality of people they send.
Edit: I guess I misunderstood “high-end” and thought of “large” consulting firms, because those are the ones that pretty much always suck. I’ve had wonderful experiences with small consultancies.
I don't think there's a logical inconsistency here. Imagine that the quality of work we can expect from a contractor with no particular investment in your long-term success is a 7. If your internal team can produce a 10 given the time, you'd look at that and think it's not very good. On the other hand, if your internal team can only manage a 4, hey, go with the contractor.
Perhaps a matter of levels. High end consultants usually have some reputation to maintain. Places like IBM and Accenture are just good at navigating large org purchasing, so as the only bidders in many cases, can put out shit.
If you work in consulting and you think you deliver good stuff, you are either incredibly lucky (lottery winner level), or you are so incompetent that you dont know you deliver utter crap.
What is your definition of getting the job done? 50% of projects run by consultants fail.
Seriously this level of smug shows how clueless you are.
I worked in few consulting firms and know the internal stats.
For ERP impelmentations, failure rate is even more than 50%. Gartner says it is 55% to 75%.
For digital transformations I think the stats are closer to 50%, but it more depends on the company and their project scope.
Maybe the poster above makes some small landing pages for micro companies.
For greenfield projects made by agencies "it depends" but usually quality is utter crap. The project "works" but no change is possible easily, so at the end of the day the projects are failures.
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.
Having once been a junior dev at an agency, I can confirm most of what you're saying. I would add that the strongest advocates for cutting corners tend to be leadership and management, who have been through this before and know that as soon as they can get the client to agree that release 1 is done, the rest is the support team's problem.
I find the quality of individual contractors can vary massively. Some are brilliant while others are borderline useless with behavioural problems to boot, yet somehow aren't being fired.
One argument I'll always make in defence of agencies/contractors is that a lot of problems stem from the fact that the client is often not engaged and believes that because they hired you, there's no effort required on their end.
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 doesn't yield the developer a better pay cheque.
The ironic thing is that if the user stops using this software the company benefits because they don't have to pay out the expense claim that the user didn't enter. This seems like a win for the company and the company would conclude that using SAP has reduced their expenses.
The key thing about enterprise software is that it's never sold to end-users, it's sold to senior managers and executives. The contact that this group will have with the software is to approve transactions (e.g., Reqs, POs, Expense Claims, etc) and maybe view some reports. You can bet that these interactions are very streamlined.
It also probably describes long lead times and lots of overhead (expensive deployments etc).
I guess the question that is often missing when these systems are specified and bought is “if we find a trivial but annoying UX papercut issue in the software which is 5 minutes of actual development time, how quickly and how cheaply would we have that fixed once we report the issue?”
Having systems people like is important. I think that often seems to get lost.
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.
I think you could also work from likely evolution of the system. Probably this was just a string and somebody at some point thought, hey, let's add suggestions and did the quickest way they could think of to do that without fundamentally reworking.
So the near universal consensus from the technical community is that SAP makes crap software. Yet here we are obsessing over monads while they laugh all the way to the bank. So what’s the lesson? Maybe good software is a waste of time and smart money just focuses on the marketing. Unfortunately that’s what I’ve seen over many years.
Opinion: SAP focused on the buyer, not the user. I see this in technical software sales all the time: vendors have an X, so they target the team that might X or currently use the inferior Y when they could be using X.
But in reality, those people are rarely if ever the buyer, as in, the person who has the budget and the authority to actually issue a PO. In the size of company that uses an ERP, that person is not going to be Raj in Accounting who likes your webified TrelloAsana travel and expense dashboard, or Sara in IT who enjoyed your demo of the JSON export to PowerBI. Its going to be a committee of Finance EVPs who give a final thumbs up to the CFO to write the check.
The other part to this story is that at this level, SAP (and peers) are using highly skilled partners as force multipliers to sell. I can honestly say after years in technology that I have never actually seen a SAP employee so to me. But I have seen a boatload of folks from Accenture and Deloitte and Tech Mahindra try to sell digital ERP transformation via a $$$$ contract that used SAP in the tech stack.
In short, SAP doesnt need to be the best. It just needs to win the CFO and make partners money.
What does better really mean, though? For the CFO, a SAP implementation solves multi-million dollar problems in inventory, sales taxation, expense management, compliance, etc. That is "better" for their organization. If it comes with a slighty cruddy travel and expense system, oh well. That piece probably represents like 1% of the deal value.
Enterprise sales at this level requires a deep understanding of what the buyer values in your product, not what you think is valuable. I dont claim that SAP delivers on these claims (ie I'm not carrying water for them) but they are good at hitting this button.
Sometimes when I feel like the worse product manager in the world, I just click that Concur link in my work computer browser’s bookmark bar to remind myself that, even if I suck, some bloke at SAP is doing their job even more terribly than me..
The assumption seems to be that the list is not sorted.
A quick search for "Concur locations" finds a config guide [1] which says that there is a location code, which should be based on the UN location codes (or at least not conflict with them). The screenshots in the guide suggest that this code is one of the primary sorting elements (which might make a lot of sense).
If the company loads locations without considering this code as a primary sort element and simply abbreviates the location name in English, then you would get the reported effect, I think.
I'm not saying this is a good choice for sorting, nor that there are not better ones, nor that Concur is good software. However, this may be incompetence from the administrator / data loading, rather than from the software developers.
I have used Concur and don't have any strong feelings about it. It is not wonderful but it does the job. I think it is a little overwrought to call it a "horror show" that the list isn't really sorted. Presumably they see typing in the place name as the primary use case and this was an afterthought. I kind of expected serious bugs from the title.
The Concur UI is a bucket of ass, classic enterprise software. Barely tolerable when it is working, and it is broken or super slow maybe 1 in 4 times I try to use it.
On the trip side, the car rental selector is something special. You can't check multiple vendors at once, so if cars are in demand, expect to spend a while discovering you can't get one.
In my experience, the far bigger complaints with corporate expense management software is the audit process which kicks back expenses often for random and trivial reasons rather than the software itself--which may not be magical but generally isn't the main source of pain.
Sometimes they work together! I submitted an email receipt and it kept getting rejected because Concur only shows the first page of a multi-page PDF unless you go through some very non-obvious navigation to see the whole thing.
I was a bit vexed when my expense report with something I bought at a retail store, with the receipt, was rejected because I did not provide an invoice with my name printed on it. But that wasn't even the software!
My favorite fight search tool was hipmunk. Their 'agony' sort was my favorite feature in any software ever. SAP bought them, and I was so hopeful that Concur would bake this into their god awful app that I had to use for work. No luck. RIP Hipmunk.
I used to work at Hipmunk, stayed until it got shot down.
SAP Concur approached us to use our auto-completion algorithm/database to power their new UI or whatever. Apparently the 2 or 3 different DB they already had for that exact use case were not good enough.
Our result were sorted by population size of the destination, The concur people could not believe it was that only that.
What gets me the most is this instance of SAP Concur to have timestamps on files of receipts being uploaded. I don't have access to the Concur app, so must use the web interface. That interface rejects smartphone photos from the company iPhone, because of unrecognized timestamps. Scanner or bust. Furthermore electronic receipts PDFs are also rejected for the same reason. So what I do is scan a blank piece of paper, Photoshop in a screenshot of said receipt and submit the Photoshopped PDF, which is recognized as having a valid time stamp.
Also, being at an international company, certain elements are in Japanese, certain elements in English and certain elements in German, no matter what the interface language is set to. Certain fields that do translate have opposite meanings after being translated. It required a company internal instruction to understand.
Never ending warnings you can't turn off and many other small things lead me to skipping small expenses and just eating them, because I can't be bothered to fight Concur.
> Never ending warnings you can't turn off and many other small things lead me to skipping small expenses and just eating them, because I can't be bothered to fight Concur.
Sometimes I wonder if this is a "feature not a bug" the company wins and saves money (in the short term)
It probably costs them via reduced employee happiness turnover etc etc indirectly but there is no KPI for that
This is true for me and I have been recently submitting many expenses each week - it always worked. Hell I even liked the itemized expense entry feature!
SAP continues because they have a great sales team that makes execs feel like they are making a choice that never gets them fired. SAP doesnt care about UX and in the 10 or so years Ive dealt with it on the periphery, its been a barely serviceable product with a terrible user interface. I especially love how the localization is so sporadic in the application. Sure the front end will be mostly english, but be prepared for a lot of tables/columns/fields to be in German. Granted, its been a few years since Ive done much SAP related work(I build interfaces between trading systems and SAP for accounting and some logistics interfaces.)
Anyway, their goal is to move into new business verticals and not really fix the product. They are actually trying to move into the trading and risk management arena in which I work. So far they have one major client that I'm aware of and they are struggling to make it work.
As an SAP dev knowing some German is a big help - not German but my home language has Germanic roots without the gender bits so close enough, so it helps if I need to read their variable names as comments are sparse or simply not there.
Remember. The usability of this tool isn't vetted by the people who sign the contracts. These people all have assistants doing the work for them. So they never see the pain points. This is all based on flashy PowerPoints and expensive dinners.
I am a bit disappointed, was expecting something way worse for "horror". Maybe the horrors are on the bugs he hasn't mentioned but had to put up with.
One possible excuse for SAP Concur here, and I am just guessing, is that the sorting is in some kind of customer-specific config setting that the admin needs to setup. I.e. they made it configurable for each client's needs. If you don't set it up it defaults to this "undefined" behaviour. Good defaults are better than this though, so alphabet sorting would come ahead.
I don't think so, I vaguely remember Concur was a big monolith with a huge MSSQL server in the back. I highly doubt they can just rip it out and replace it with HANA and "forget" the sorting. There's a good reason Concur is in Bellevue right next to MSFT, it's a really big .NET shop. They wanted to go to micro services eventually, but not sure how that ended up.
This sorting by country and city never worked, it didn't work during my time at Microsoft in 2014 (they replaced it with their own mstravel tool thankfully), nor did it work at SAP in 2018. I frequently travelled from Berlin to Walldorf (in Germany obviously) and it always picked Berlin in Arizona (IIRC?) first. Walldorf it eventually got right, but I do strongly believe somebody just hacked this into first place in the frontend.
My previous job was to develop POS software that was marketed by SAP (we were a SAP gold or platinum partner - can't remember which). The POS software did not include the part that actually runs on the POS but also all the backend stuff like order management, inventory management, etc.
So we were forced to use the crude SAP XML interfaces for data exchange (IDOCS) and it was really disgusting.
We were also forced to use SAP NetWeaver which is a PITA to manage. Also, the customer decided to use POWER9 so we were also forced to use the SAP-maintained port of the JDK for POWER9 and we have found like 4 or 5 bugs in this port.
Also, being a SAP partner, we were forced to use UI5 which is such a horrible framework.
But the thing is, SAP is a freakin' huge company and the software is quite old. They are on the right track to make things better (XSA, other data exchange format).
Another funny story is that some customers decided to host their system at SAP. The SAP department (SAP HEC iirc) that took care of updates of the systems planned with 14h per system per update - complete downtime. One customer had 3 systems at SAP, which meant that it took three Sundays until all systems were updated. Since then, most moved to OEDIV for hosting which does a slightly better job.
SAP HANA (the DB) is quite cool though. We had one with 4TB RAM and it was super fast.
I interviewed with them prior to the SAP acquisition back in 2017.
"We're looking for someone with experience with ASP and database performance improvements."
"You mean, ASP.net - not old school VB6 derived, interpreted - 'pretty cool for 1997' Active Server Pages - ASP?"
"Hey hey! You're the guy we want!"
Of course I would have taken the job if I'd known they'd be acquired.
edit: Huh, they were acquired in 2014? Ah well - it's like someone's MVP that made it out to production, then they made it big and that MVP kept being glommed onto.
I use the Concur app to scan receipts for travel expenses. It has a useful feature called "ExpenseIt" (maybe a company they acquired?) that parses the receipt photo, finds the expense amount, and automatically files it in the current expense report. The UI is a bit jarring: you select your receipt, press the button, and after a few seconds it disappears. It doesn't take you to the expense it has created for it in the expense report, or offer such a link. But there is a fixed message saying "can't find your expenses? they were placed in the report".
...except that, every once in a while, the receipt just disappears. The receipt picture is gone, but there is no corresponding expense created in any report. As far as I could figure out, it was simply deleted.
So, whenever you scan a receipt, you have to manually track it down to the report where it placed it, to make sure it actually went somewhere and did not get deleted. Or you keep all your paper receipts and spend two hours going through them after the trip.
I tried filing a bug report but quickly realized it was impossible.
I was forced to use an SAP product at an old job about 15 years ago.
Unfortunately, I find it completely unsurprising that any SAP.* product is a dis-organized mess of a kludge, with no rationality evident anywhere.
Oh, and the CIO who foisted that pile of cr*p upon my organisation? She moved on shortly after SAP was implemented -- undoubtedly to foist SAP on some other poor unsuspecting org. I sure hope her SAP stock has tanked.
This is a clear indication that the user is not the customer. The first time someone arrives at the scene catering to the users, the whole industry will be wiped out. This happened to the phone handsets when iphone arrived.
So, future investors - look at the startups that address the user problems, not the client problems, even though the latter are paying.
The two are fundamentally different. Unless you can devise a way to do BYO expense platform, you're comparing B2B to B2C product development, marketing and sales.
Do you think the PMs at Concur just woke up one day and decided to be user hostile because they're asshats? Of course not. They did what the Sales team, and Gartner, told them they needed to give to CFOs so that they would buy it. And then CFOs bought it.
Until someone can quantify the benefit of "better UX" to CFOs, or provide that and all the CFO facing features they want, crappy expense platforms will continue to be the order of the day.
It will be impossible to do any real comparison because the bad stuff is relatively entrenched at most large places.
Small quality issues for users would reduce errors, and get expense data reconciled faster. But… by how much? 10%? 20%? No one will care enough to fund a large system replacement for a 10% reduction in expense report filing.
> The first time someone arrives at the scene catering to the users, the whole industry will be wiped out.
I find it a little hard to see to be honest. Team members might push to use Slack over some other chat solution because they spend all day using that -- I've seen that happen and work. How often do you do expense reports that you're really going to nag the company to buy your favorite solution?
The people who decide that everyone in their company must use SAP Concur are rarely the people who need to file expense reports- they either don't travel much, or they have people under them who take care of it.
Instead the decision will be made based on price. Hiring bad devs and rushing poor quality software out will be a net savings for SAP.
I can see another issue in that list: for half of the entries, it displays the state but not the country, and for the other half, it displays the country but not the state (or its local equivalent). Given that there are things like cities with the same name but within different states in the same country (a quick web search tells me that, in my country, there are many cities like that), and even states named identically to an unrelated country, it's not hard to see how this could get confusing.
To give my software dev guess of the reason of the issue, I would suggest this:
Concur being based on SAP, forms are built in a kind of "no code" way. There is a generic component "list picker from data table".
Usually, for that kind of components, the order is user defined based of the row position in the data table or an index column value. Like first "N/A" then "yes" the "no".
As it is obviously too complicated to manually fill all the cities by hand, this data table was probably setup by a script that didn't mind the order. In addition, the cities data was probably not filled all in one go but incrementally, even with probable late additions when there are report of missing cities.
Concur is not "based" on SAP. Concur was acquired by SAP in 2014. The majority of it's existing codebase remains in place to this day. Even the newer more modern code base bits are reactJS based, not SAP based.
> Assume that bad technical decisions are made rationally, for reasons that are not apparent.
Actually, this example proves the rule.
Large enterprise applications like this are used by governments and large businesses that must comply with various accounting, legal, and administrative regulations. So vendors like SAP are incentivized to deliver products that take the least amount of effort and incur the least amount of risk while still meeting the twisty little maze of requirements. If bogo-sort is the least-effort way of organizing the location list, bogo-sort it is. For example it may add the locations to a map or hash table, and then iterate over them in an unspecified order.
> There is no resource constraint that is so stringent that it would prevent the programmers from replacing
> displaySelectionList(matches)
> with
> displaySelectionList(matches.sorted())
> They just didn't.
It’s quite possible that it isn’t that simple. Hypothetically: if the user selects the 13th item in the list, how do you, as a programmer, know that was the 42nd in the original list, so that you can send back “42” as the selected item to the backend?
That sorting logic may have to be more complex, and, under time pressure, beyond the means of your average programmer (did matches.sorted() modify the list in place, making a linear search in it for the text of the item not work?).
You have to remember why companies buy from the likes of SAP: compliance.
That’s the one thing that SAP excels in.
Sadly this means that usability falls by the wayside. And while SAP‘s user interfaces are exceptionally bad, their competitors do not exactly prioritise ease of use either.
In this case a subpar user experience is combined with an immature technology stack. SAP infamously stopped supporting 3rd party databases and now require their customers to use the in house HANA database instead. Problem is that HANA is not a great database. Painfully slow and lacks features. In this case, pre-sorted result sets.
Our audits were all done by interns from the big accounting firm and they just dumped some of SAP tables and ran it via some internal tool and based on that they signed off our results.
HANA - remember the first time we installed that in POSDM - it performed worse than the DB2 install we had before - we upped some settings/buffers/memorty and then they told us to turn on row indexing for one of the core tables (TLOG).
I thought columnar was the magic here - why did we upgrade to this again ???.
I would say that such relatively mature software companis carry such old products with dependencies to account for that they are overwheght and only address vunl/p0 bugs; no new features or improvement. I do use Concur where I work and it is bad, in this particular case maybe less effort was made from SAP on the front end, or your back-then-company's SAP departement did a poor job implementing it. either way such mess is also the result of poorly managed departement having 15+ years members that lost interest and that are maintainig very old products.
Like the author say in the update at the end of the text, my bet is that they used an already sorted database (to save processing power) and when SAP acquired Concur they changed the backend and never corrected the issue. Showing a total disregard for CX, they probably don't have anyone doing any meaningful UX work on that software.
My company uses Rydoo and man is that thing easy to use. Could be smarter with chargecodes, but still is lightyears away from Concur....
A few years ago, we were building somethings to integrate with multiple expense and invoice management systems. Concur's odata based APIs were by far one of the worst integration experiences I had. (Even worse than integrating with dot net SOAP APIs from AXIS and Java)
You could see that some of the older APIs were well documented and thought out and the new versions were considerably worse. What we realized was that the earlier versions were built prior to SAP acquiring Concur.
I unfortunately still end up working with contractors who produce code with similar thoughtlessness. Yes, a company like SAP should have caught it via the myriad of reviews and approvals, but ultimately if even in my small universe, this kind of issue can occur because some people just don't care to do a proper job, then it can certainly occur at a larger scale company despite many more layers or "process" to prevent this.
I used to work for SAP Concur, not by choice but after Hipmunk got acquired by them.
Concur talked to us to use our autocomplete DB in their "new" UI because we had better results. We were using the population size of the location to sort bigger place first.
In the end it never went beyond that one call. I think they already had multiple team working on this, not necessary together (there was a big rewrite going full force with micro-service going on).
Enterprise app is designed typically for CFO's who approve the purchase but never use them. I used to be enterprise app PM. Not the most pleasant experience. They didn't care about UI/UX. We created vanilla version of the app and the team ended up working mostly with consultant (professional services) who interacted directly with end users and they were paid a lot for customizing the app.
People who understand and complain about these issues usually don't work for these products as these are not critical systems for a company to function.
They serve 2 main purposes.
- Have some process in place to get things done. Speed is not important.
- Provide livelihood for hundreds and thousands of average developer ecosystems/SIs. They work hard to keep them alive.
No software is perfect. Not even the one which flew Boeing 747, thats why they had 3 services coded by 3 different teams running on 3 different brand processors and the system takes the 2 matching entries as the truth.
Even micro processors are not immune to long running bugs.
Picking one small thing and demonising a whole team is unfair for them and the company.
That would be Airbus flight controller - concern was over their new by then fly by wire control system so this was used.
The US Space Shuttle had the same concept with 4 computers that ran on the same codebase and hardware from IBM that would check each other on critical components (engine burn/flight control) and if one differed it was voted out.
There the issue was radiation induced memory corruption as the software was top tier tested and verified to be bug free as possible (they used ADA)
Even Google Calendar does this. If I'm adding an event an hour from now, why does the Location auto-complete list show locations that are impossible to reach in time at the top of the list? Is it not more likely that I would be booking an event near to my either my current location or my home?
Always sort data server-side if you don't have a good reason not to. I know nothing about this product but I have seen a lot of bugs caused by the assumption that there is an assumed default sort-order.
Concur is a million times better than what I've used at previous jobs. It now takes me mere minutes to file expense reports. Travel booking is a breeze too after you go through it once or twice.
No, neither what it is doing or what it ought to be doing is a topological sort. What it is actually doing seems like “return all matching the stem without any sort [or sorted by ID or some other non-relevant value].”
The various things the user suggest are all sorts by fairly simple functions, not the kind of dependency ordering at issue with a topological sort. Choosing the best one to use as a default might be hard, but they aren’t the kind of complex things you can’t implement as a simple order-by once you are set up for it.
