I worked in public accounting with some major corporations as clients. Every single company I interacted with used SAP. It is the de facto software in its field and is deeply entrenched. Its UX is the most horribly wicked thing I’ve ever come across. We would conduct walkthroughs with process control owners that showed us what they would do in SAP to perform their job functions, and it would take multiple, intelligent people to capture all of the processes. The knowledge that the users at the client had built up was extensive and highly specialized. If something happened to that person, I don’t think you could quickly plug in a new person and have them take over. The initial learning curve felt far too high. I’m sure it gave those people a sense of job security.
I feel there is a lot of room to develop better tools that are not so horrid, however, the process for replacing SAP will be long and close to impossible. SAP feels like one of those businesses that’s too big to fail because it’s so entrenched in the corporate world. Somewhat jokingly, I think it would be easier to switch the US over to the metric system. Any challenger will have to be massive, accept losses for over a decade to gain market share, and have incredible support for their clients if they ever want to takeover in the Fortune 500 world. Challenges too great for a mere startup to accomplish.
It’s easier to just hire people to learn the SAP workflow and then hire external auditors to make sure the accounting policies are properly being followed.
20 years ago I was a grad assistant for a couple of professors who'd built a pretty incredible JIT supply chain platform. The US Army started using it to manage their uniform orders and it worked so well that two entire warehouses were torn down due to lack of use.
A new general came in and insisted on using SAP. 6 months later, they had to rebuild both warehouses.
EDIT: For some additional context, the system managed to basically eliminate the "bull whip effect" all the way down the supply chain. It's really a fascinating system. Developed by Dr. Bill Kernodle and Dr. Steve Davis from Clemson Apparel Research.
The government funding mechanism doesn’t incentivize cost optimization, and in my experience, does the opposite. Money is allocated to be spent and if not spent is “lost” and may be cut from subsequent budget years. This leads to massive end of year purchases to use remaining funds or starting unnecessary projects just because money was allocated, regardless of whether needs have changed.
It’s a really broken system that no one seems interested in fixing.
Seems to me that the actual "lower the budget if nobody uses it" part works just fine — the problem is that the people affected by it are aware of it and form a feedback loop with it (i.e. "the measure becomes the target.")
If you could hide the budgeting effects from anyone with the ability to 1. start projects or 2. add scope to projects, then it seems like it'd work out just fine.
(Of course, actually doing that would require splitting "planning" roles into separate, almost-adversarial "defining projects + increasing scopes for projects" and "feasibility-analyzing + cost-optimizing + decreasing scope for projects" roles. But that seems like exactly the sort of thing the DHS would be fond of. War-games for the project managers; and separate levers for both kinds of sitting presidents to pull on to satisfy their bases, where building up one capability doesn't tear down the other.)
This is a trust problem. Trust problems don't usually get better when you start hiding more shit. Isn't the real solution to make organizations feel confident that they can let unused funding go because they can get it back in the future if they need it?
If you pre-approve but not fund certain desirable projects, and allow unused funding or surpluses gained through efficiency to spent on those, you get the double-win of maintaining trust and making efficiency organisationally desirable.
I agree that trust is part of it, but I don't think it's the whole story. A lot of this is also due to cognitive biases. For example, optimism biases make public works project managers continually underestimate cost and schedule. Then sunk-cost biases make funding managers scramble to find additional money to make up the difference. Often, those funds come in the form of "unspent" funds from other projects.
That's the generous interpretation. There's also the case when project managers deliberately low-ball their project estimates to take advantage of the phenomenon. I'd put that in the trust problem category.
Then the inventive is to add $50million of unnecessary budget one year, and cut $50million the next year to get the EOY bonus.
The same dynamic can occur with hedge funds, where the incentive is to increase variance (because high volatility pays the fund managers a lot more on average) or increase risk (example swing for the fences if underwater).
That sounds like a great way to get "deciders" to override good uses of money from the people below who actually have an understanding of when it needs to be spent.
It is a trust problem because organizations generally aren't worried about losing money they don't spend that year or the next. They're worried about never getting it back. When you use a ratchet approach to budgets it doesn't allow organizations to respond to responsibilities which may be cyclical in nature. This leads to permanent worst case thinking which leads to hording.
I wouldn't go for it. Suppose my budget is Y and I could reduce it to Y/2 and get X%*Y/2 as a bonus. But in subsequent years I would only get a budget of Y/2. With half the budget I can only employ half the staff and be half as important. I don't think it works out.
edit: on the other hand: If I'm going to quit the job next year and I don't like my successor I'm definitely going to cut corners and budget.
Since the original context here is an army procurement, I don't think that hypothesis works out. Civil servants are not going to get that type of monetary incentive structure.
Then we're no longer making evidence-based policy. That's just hypothesis-based policy. And unfortunately, humans are reallllly good at rationalizing whatever hypothesis suits their biases.
The lower the budget if nobody uses it is a perverse incentive. Costs at units are variable, but the budget model does not reflect that which incurs silly expenditure so that you can ensure that next year when New variables occur (radios, weapons, etc are a year older, new climate changes, solar flares, etc) will not hinder the progress of unit affairs.
Sharepoint is similarly entrenched at DOE when I worked with them in 2009. Any project that gets a bid contract can't say specifically that it must use Sharepoint, but the requirements will be written in such a way that Sharepoint is literally the only system that fits all of them.
While SharePoint is not the best choice for many applications, it has enough features to make it work. Since there are plenty of SharePoint experts already in the organization, it could be cheaper to just leverage them to build some SharePoint site that just barely works well enough for whatever application. It would cost a lot more to bring in some consultant that knows how to setup the proper software to do whatever new thing the project needs to do along with whatever new service contracts that need to be signed and paid for to cover the software for years. Do you jump into the new software that might be better or do you just use the same old SharePoint that you've already invested heavily in? The efficiencies of both solutions are probably intangible and it would be difficult to price either of them. Eventually someone out there will be the evangelist to convince program management that the new software really is the best choice (Jira, Confluence, Teams, Salesforce, Trello, etc).
When I lived in the USSR we had the this system where money must be spent no matter what or the next year budget will be cut. I thought it is insane and borderline crime and thing like these are impossible in free Western world. Boy was I in for a surprise when I emigrated.
I suspect it happens wherever you have a centralized economy, the government sector, internal corporate divisions, and if your corporations are run by the government, as found in the ussr.
A market economy does not really help, that just means you don't have a budget to cut in the first place.
Similar story in Denmark. The army got a new procurement system, based on SAP, to help reduce cost. I believe Paul-Henning Kamp has a joke in a talk where he claim that they succeeded, because nobody could buy anything for a year.
Later I meet a former procurement officer who was reprimanded for excess purchases in the year leading up to the system launch. In the end his team was the only one able to provide equipment for an extended period of time after the new system was introduced. Everyone else had relied in JIT supply chains, but this guy didn't believe that the new system would work and spend a year building up inventory.
Are there any documents supporting this? I ask because I am curious what official documents exist around this idea of mandated return to inefficiency -- there must've been a gain elsewhere (or is that too optimistic)? Plus there must be costs documented associated with the first and second program. Genuinely curious about this type of decision (call it "inefficiency thrash"?).
Over my career I've seen it communicated as "leadership support" where people implementing different programs know that they are only as effective as the leadership support behind it.
I do some Scaled Agile Framework consulting and the implementation a good example, because it can be fantastic but if leadership at the top of the company doesn't get on board the entire process will self destruct or be bastardized.
The professors who built the system knew this about every customer they talked to and it was a big learning experience for me. New leaders will come in and often insist on tools that they already know, rather than take the time to learn about better options.
If you've ever read Skunk Works (fantastic book), you see lots of this in the military procurement process in the US. It's bad enough that you worry how much it's hurting US national security innovations.
> New leaders will come in and often insist on tools that they already know, rather than take the time to learn about better options.
I've seen this with developers. Newly joining developers, particularly junior and mid career developers, tend to insist on using the languages, libraries, and techniques they are familiar with. Senior Developers don't seem to do it as much. Either because they are familiar with many things, or because they have been on the other side of these well intentioned suggestions to know when it is actually productive.
Sounds about right, I went through the whole process, went through a big functional programming romance in the mid of my career, and after 15 years am now like “I’ll use whatever”.
I do care about using the right abstractions and high-level interactions, not as much about the language or frameworks. I’ll let others put in their political weight on that, so that I can do it in the areas I believe will really make an impact to the business goals.
My (completely speculative) hunch is that they may have been chasing efficiencies beyond the scope of uniforms, or even beyond the scope of the army.
For example, the solution may not have worked well with other procurement items and they wanted a single platform. Or the navy already had an SAP contract that could be leveraged without spending money on a separate stand-alone army solution.
So it can look like a bad decision that generated local inefficiency while globally it was a better choice. That's not to say SAP actually delivered on those promises.
Or this small company built by a pair of professors didn't have the customer support arm or continuity guarantees to service an organization as large as the US Army.
Its always good to call out corruption, but its also important to realize when a situation is actually crazy complex and while its an awesome story might not be worth formulating a summary judgement from.
That could very well be the case. I looked up the professor and the company he created for this solution and the link is dead.
However, for an organization like the army that spends $$$ on logistics, I would bet they would continually fund something like this if it showed enough promise. One thing the DoD and Congress are good at is throwing money at R&D efforts.
Another thing is requiring continuity clauses in the contract. Such as, in the case of going out of business or otherwise deciding to discontinue the project, the IP and source code needs to be turned over.
And this is why enterprise software is always so horrid to use when compared to a simplistic web app. It’s about features above all else. If someone can do their job, that’s all that matters. And tightening up the UX around that workflow falls to the very bottom priority against developing new features.
SAP, and any other ERP, is just the operating system for your organization. If you run it intelligently, the OS won’t prevent you from getting a good outcome.
In this case, it sounds like they should’ve bolted the JIT platform onto SAP
But people don't run it intelligently. For a lot of stuff the intelligent thing to do is use SAP as a plain database and program your own logic. But now what you really have is an inferior database with an inferior programming interface, and you pay through your nose for the privilege. Of course getting to somewhere useful is a battle if you have to use SAP consultants instead of real programmers.
Most use it very intelligently. I’ve seen some amazing automations and I’ve seen countless simpler businesses running vanilla SAP as they should.
Basic business logic is built into SAP - but because it covers all aspects of business, it’s a massive tangle of rules.
For instance, let’s say you get an invoice from a vendor. Now you have to update your balance with that vendor, and your general ledger. You have to record the new inventory moving in. Perhaps the inventory has a barcode, or a serial number with a warrantee date, or a batch with an expiry date. The inventory movement will be tied to the cost of that invoice - remember to take into account those exchange rates. Also, there’s a variety of ways to account for item cost. You will have had one or more purchase orders - those have to be closed. If the vendor is to be paid in a different currency, you have to do every accounting entry in your currency and theirs, and record the exchange rate differences. Your accounts payable are now in that other currency, which means that has to be updated all the time for accurate bookkeeping. You have to note which employee was the buyer. This buyer has targets and metrics to be tracked. Perhaps there are reports and alerts set up for them. You will have a budget, which may impact this transaction. Of course you also have master data for the vendor, the employee, and the items bought.
There is a lot more to this than the above, and this is for the simplest business case - one that happens hundreds or thousands of times a day depending on the business. Usually there are special considerations to program into the above as well. Now imagine what happens when a complicated situation arises, where you have complex transactions spanning months, many countries, and many other businesses. Sometimes there are legal rules built into the logic. Usually those rules only alply to one country. And I haven’t even mentioned freight or tax or landed costs from secondary invoices.
SAP is a ball of wire because it simply has to be.
Except when used like that it’s dead slow (I’ve seen time series - light, but still - put in SAP). And then you have to understand the codes…
So no, not even as a DB, maybe especially as a DB, it should not be used.
I'd have thought that the US army would be using its own solution, or at least an American one. Using a foreign made platform to handle such a critical aspect of your military (logistics) sounds a bit weird. Not that I think that those risks, if they even exist, haven't been thoroughly evaluated by tons of experts in the army!
SAP sucks for custom stuff like uniforms and clotes.
I developed a custom engine for things like aluminium rails, and thermal sensors, to generate a new product with the production tree in SAP, so it would be able to decrease the right ammount of raw materials from the warehouse.
I remember years ago a friend worked for sun, involved in SAP installs. He said corporations would overpay to install the highest-end (overpriced?) sun systems to get SAP up and running. Apparently the cost savings of something like currency conversions alone would pay for everything almost immediately. And that was just one facet - other efficiencies (taxation?) would have similar savings.
It doesn't make sense for the Army to be in the business of developing software. They should be outsourcing this, and having a well-known vendor like SAP means there's a lot of different avenues to get bids to lower prices.
Why not? They need digital soldiers. They farm spec-ops from the best grunts, so this would give them a pool to recruit their information warefare people from.
The Army isn't a business and should never be run as one.
"I feel there is a lot of room to develop better tools that are not so horrid"
Probably not. SAP is an everything-to-everyone product. Using Fred Brook's terminology for essential versus accidental, the problem with everything boxes is that even just the essential complexity of such a product is so insanely large that they are sufficient to produce a "horrid" product. Of course they don't have just the essential complexity and add a healthy dose of accidental complexity, but so would any putative "less horrid" replacement by the time it successfully solved the same essential problems as SAP.
Closer to home, "bug tracking" is an example of an everything-to-everyone product. I can't even count the number of times I've seen a "simpler, less horrid" bug tracker get started due to the perceived horribleness of the current bug tracker, but the new bug tracker simply became the old one once it tried to grow into the same niche. This may sound strange to 2022 ears, but I remember when JIRA was being pitched as the simpler solution and developers were pretty keen on it. There will never be a mature bug tracker that is any fun to use, because by the time it's everything to everyone it'll just be the same morass of being everything to everyone again. It turns out that the "less horrid" bug tracker wasn't actually intrinsically less horrid... it just wasn't everything to everyone. Instead it was a bug tracker for developers, so developers love it. But then if developers are going to be allowed to use it everywhere, it has to satisfy all the other stakeholders too, and it inevitably mutates into an everything for everyone product.
(See also: Salesforce. Letting users configure custom DB schemas is a key indicator of being an everything to everyone product. To some extent, programming languages too; there's a lot of people who pine for something simpler (such as the people who think that if we just went to visual languages, or tried to jam everything into "no code") and don't understand that by the time you have a general purpose language that is truly general purpose you've got a large amount of irreducible essential complexity whether you like it or not.)
While it's true that there's a huge amount of essential complexity in this kind of software, there's also a lot of completely unnecessary bad UX and user-hostile design. This is caused by lock-in and not selling to the end-user. If they don't think bad UX will lose them any customers, no effort will be put into it.
It can work for a long time, but eventually it does create opportunities for competitors.
You're absolutely right that there's a floor for how simple these products can be, but most of the incumbents aren't anywhere close to that.
Yes, the platforms essentially get locked-in the UX level that existed when they were initially built. Small incremental changes can be made, or they can be "reskinned" but total rewrites are basically impossibly once there are tens of thousands of customers in hundreds of distinct niches.
Yes. Reminds me of the ol' classic, "Things You Should Never Do, Part I" by Joel.
However, I do believe a (slightly) better competitor could be created, with better technology, better workflow, etc. If well-capitalized. If it had well-factored plugins. If you had a top-notch team to design all that and then build it.
That's a lot of ifs. Joel says it isn't guaranteed a brand new team will even do better than the old on the essential angle. It's risky and costly enough to prevent it from happening.
I love to read this kind of articles. The kind that clicks in your mind right away.
Experience probably has already taught you some of these ideas, but you hadn’t invested the time to reason about them and putting them together.
Then you read an old blog post, from two decades ago, putting all those ideas into words and it simply clicks in your mind.
Thanks for posting the link - funny part about his blog is coming across articles multiple times years apart. Had a hunch I'd read this particular one before and when he started talking about the 'fckedString' that was when I knew. Love the persistence of his blog as this was written decades ago.
Exactly right. Everyone dumps on enterprise software in general, not just SAP, but the truth is that enterprise software is hard. There are so many requirements and specific workflows that it becomes everything to everyone and thus “horrid”.
Sorry but have you actually used a SAP system. I worked at a company that spent $80m on a SAP system that was comically worse than the system that came before it. To the point that people left the business because it made their working days so unpleasurable. This same story has happened at multiple businesses I know. But it's sunk cost fallacy - once the CEO and board has endorsed spending $80m everyone's just going to pretend it's fine.
I’ve worked in shops that built enterprise software. It’s not that hard.
SAP and Jira are just not great software. They’ve got excellent sales teams, connections, and probably great support. That’s the key to getting user-hostile software into big orgs.
You (and maybe GP) seem to be assuming that a SINGLE competitor would theoretically try to replace SAP and fail.
But the most likely scenario, I think, is that built-for-purpose competitors will build products that peel away small pockets of SAP's customer base over time.
The irony of course is that a product like SAP is the end result of similar built-for-purpose products being hoovered up and merged together in the first place.
Bit of both. Their (SAP) Convergent Charging module, to which a lot of legacy Sales and Distribution solutions are trying to move to, was acquired. I think they even have patents on the decision trees used in this module?
How does this idea merge with the idea of "unbundling"? For example, I think of Craigslist, and its famous "unbundling" story[1]. For Aibnb, fiverr, Getaround, etc., the individual niches were enough to build a big product off of, and there was no need (or maybe no ability?) to grow that product back into the "everything for everyone" of Craiglist. What is different about SAP/JIRA/Salesforce? Why can't "not bad" niche-focused subsets of these products become big and profitable while still focusing on their initial niche/area?
Cross-functional workflows within enterprises. Developers can have their own nice, but what about working with tech-writers, oh now we need to have approval processes for third-party systems and idea-gathering from customers for pms, and integration with internal case-management for Customer support escalations and some acquisition uses a different methodology so now we merge on a single platform that contains slight variants or what really are the same states for status. And marketing needs support for the product launches, and we now integrating security scanning tools automatically filing bugs ... oh security has new process steps because we all are doing DevSecOps. And for this special process we need 3 layers of managerial approval. First it was email based, then Slack, then MS-Teams, then back to Slack. And the Old-school QA team for the hardware component has different metadata requirements and internal IT-bug tracking has different requirements than the product-engineering group. And now we want to track cloud spend so every ticket has to have a cost estimate.
The requirements change, merge, flow. In theory each department within the enterprise could have their own optimized, silo'd tool ... but then you need "enterprise integration platforms" to glue together all the workflows between them.
Likely because of B2B vs B2C. Individual users can easily switch when a better solution appears on the market. Business use cases tend to involve a little more friction in those decisions.
If you think about it, all of those niches were naturally unbundled. The people who were looking for vacation rentals had no need to also look for gig work within the same product. The same isn’t true of enterprise transactions - everything is always related, with cross-function impact. There is always a GL that needs to be updated, you need a common vendor list, budget allocation constrains procurement, and on and on.
Spot on. Also, SAP’s “everything” really does cover everything a big business is likely to encounter, which is a lot of things that all have to be interconnected
Thank you for this "everything for everyone" term.
I was not aware of it until now, and it perfectly explains those examples you provided.
It also explains why product managers are so focused on "personas". I guess that this, along with push-back on feature creep is a way to combat becoming "everything for everyone".
Of course that's true for small-medium companies, after a certain size it seems you welcome becoming "everything for everyone" as you're already entrenched in so many businesses.
The risk alone from a company switching ERP systems, or switching versions of the same ERP, is well documented in the press. Companies have lost tens to hundreds of millions on failed projects. So the pain points to switch to another platform must be so great even to think about going down this road. Like all ERP software, cost to implement is 2x - 3x the cost of the software.
Larry Ellison had a famous quote from some Oracle ERP event where he chucked every Oracle ERP consultant under the buss by saying: "It doesn't do everything you want, but it does everything your business needs". He was referring to custom workflows business take on which require massive customizations of ERP platforms, increased consulting costs and a painfully hard upgrade process.
One of the few things I remember from my IS management class in school was learning about Nike's massive ERP failure. If I remember right between the initial cost, lost sales, and money spent fixing the issue they lost $400 million and their stock price fell 20 or 30%.
Switching costs and risk are the major reasons these systems stay around forever. If you've got something that works. Even if it's sub-optimal, you're never going to move away from it. I worked at a place that used an ERP from a company that went out of business, so they would install DOS emulators for a really ancient version of DOS on every computer for people who needed access to the ERP. This was seen as a better solution than the perceived risk of switching ERPs. This was 10+ years ago, but to my knowledge they're still doing this.
Four years ago I worked at a company in the Fortune 500 that still used DOS for their main system.
As you say, the switching cost is way too high and dangerous. They moved billions and billions of dollars daily through a highly complex structures and complex laws in different jurisdictions across the USA. The business logic was built over the 40 years when the world was DOS. It's not like they are dumb and don't know linux or Windows exist and all that.
They brought in huge consulting companies all the time to see if they could get it upgraded, but no programming house, no consulting company would touch it. These consulotants turned down hundreds and hundreds of millions of dollars, because 1) it was just too f-ing complex, and 2) if they messed up, the liability would be immense because of the dollars daily transactions, and what the dollars were used for. It would be an absolute shit-show of the first order if things were to go sideways. I'm positive that these consulting companies E & O (errors and ommissions) insurance company would refuse to insure them. Doing it wrong would be catastrophic on a corporate, but also national level. It would not be a matter of some stick-it notes from 3M not getting to the stores on time, or shoes getting to the shoe stores.
Funny you have a quote from Ellison. I was at Oracle in the 90s, and "Oracle Apps" had its own building. At the same time, I was on lots of social events in the Valley and always running into Stanford IT people, and all of them could rant for hours about Oracle Financials.
Apparently Stanford had its own homebrew system, and some dean had decreed that they had to move to Oracle Financials. For literally years, these poor people struggled with it.
I never worked with that or SAP so I can't compare them, but I think both are the Full Employment Act for consultants.
They had an "apps" division because there were entire other companies with reasonably similar market cap at the time (Peoplesoft, Siebel, SAP) who basically wrote apps (and only the apps) as well (they required databases to function but were flexible on DB engine).
Apps are what organizations/people buy. Databases are just the storage engine.
The difference is that Oracle underwrote their apps with database profits and they never got the apps game.
> I feel there is a lot of room to develop better tools that are not so horrid
Most organizations have horribly convoluted organizational structures and processes, and SAP has been shaped by those customers over the years to cater to those clusterfucks.
A clean, sensible ERP system can only work if the organization it serves is also sensibly organized. It is much easier (and less risky) for a company to choose an ERP system that caters to them, warts and all, rather than overhaul the way it conducts business.
As the old saying goes, SAP and its customers deserves each other.
Basically, if your buisness process match that of SAP, everything is fine, if not, good riddance.
Or in the words of a former SAP manager about Lidl:
“They don’t have the right level of business engagement”
One of the reasons why ERP systems were ao sucessful is because they replaced the majority of administrative jobs by automating them away. One of the results is that those remaining are either highly knowledgable and skilled, or working in a function that has yet to be automated away or outsourced to a cheaper country in that specific company.
Exactly. People underestimate how much SAP is doing behind the scenes when properly configured. And beyond that, they overestimate the ergonomics of any enterprise alternative, especially ones that pre-dated SAP.
For every "We had a great internal platform that we custom built" story, there are multiple "We used a small vendor's product, and it was a nightmare."
Why is SAP successful? Because the general purpose tools (or worse, amalgamations of multiple single-purpose tools) that came before were absolute shit, and SAP is instead only difficult to use.
Progress!
(Also, a TAM that is literally every company, ever)
Having worked at companies that switched from non-SAP to SAP, I can say with confidence that this statement is false. SAP is successful because the transition is so mind-bogglingly expensive that it is impossible to admit that it was a mistake afterwards.
Not only that, but given the price tag, the organization itself will adjust its own processes to adapt even to a highly customizable SAP product, which may not be the case for smaller, cheaper, and better scoped other products.
>Why is SAP successful? Because the general purpose tools (or worse, amalgamations of multiple single-purpose tools) that came before were absolute shit, and SAP is instead only difficult to use.
The people who are hurt by it are not the people deciding to buy it.
SAP looks great for Csuite executives when it produces reports. For an engineer trying to enter their hours it's an hours long torture session every two weeks.
Don't forget the "we had a terrible internal platform that we custom built and it hampered or growth or killed the company outright" stories. Of which I have seen a few.
Workday Financials is a meaningful competitor. I used SAP Concur at my last job and "horribly wicked thing" is accurate. It reminds me of that "evil UX" thing that was making the rounds a year or two ago.
The sad thing is that Concur used to be great. It was acquired by SAP and then "SAPified", now it's a nightmare. But it does /exactly/ what the bean counters want, which is to mindlessly and stupidly apply policies against business travelers who are just trying to get their job done.
Concur the software is OK though not great. What is distinctly often not OK is the mandatory fields that companies want, often arbitrary travel policies, and often needlessly nit-picky auditing. If putting in an expense report into Concur typically sailed through unless something was clearly wrong, missing reasonable documentation, or was significantly out of policy, Concur would mostly be fine.
Yup! A previous company starting using Concur (with a shitty, minimal effort setup) around 2011. It would push employees to book a train + bus to go from LA to Palo Alto because it was some % cheaper than a Southwest flight. Thankfully we still had p-cards and accounts payable didn't have a spine, so our department ended up ignoring Concur and booking travel directly on the carrier sites.
My firm started to dabble with Concur shortly before the pandemic. I think they presented it in some way where it was through a travel agency they contracted with.
They had evidently selected one approved hotel to demonstrate the process and never bothered to go further.
The hotel was some four-star facility 40km from the office and twice the price of the economy tourist-tier hotels 5km away (which also featured free wi-fi and breakfast). So the remote workers continued to stay at those hotels and had to waste effort poking the system to do an override.
Fortunately, they still did it as "pay with your own account and we'll reimburse you" so you weren't stuck waiting for someone to approve a "can I pretty please spend less money and avoid an extra two hours of travel time per day?" request.
At my prior job, we were trying to do marketing for a SAP consultancy firm, and it was just surreal trying to get a grasp on it. How will potential customers know they're ready for SAP, or ready for your services in particular? Where do you reach out to potential buyers? What sort of messaging are you trying to target? I never got anything resembling an answer. I think they basically just wanted us to write the HTML for the terrible email blasts they sent to their existing lead pool.
After a thought, I suspect there's a particular corner of the C*O universe that treats Gartner reports as some sort of Death Note: a supernatural document where once someone's name appears in it, their entire destiny and fate is fully programmed out. I think they pretty much believed they could ride being in the Magic Quadrant for Nasal Hair Removal Advisory Services in 2006 into golden retirement.
For me it's stupid audit stuff. The date entered as the transaction is a date sooner than it posted and stupid stuff like that. I've mostly trained myself but I still get stuff bounced for little things like that. I've mostly trained myself to follow all the nit-picky rules carefully but I still miss from time to time. As I say, it's mostly not Concur itself which usually warns you of missing fields/receipts.
For me the real pain was paying vendors or freelancers. They all had to be input as an additional vendor, which is reasonable, but there were dozens of fields within each vendor, many of which were esoteric in they're labeling (likely a fault of implementation on our side). Then I would get a rejection via email that a particular field wasn't filled out (why wasn't it a required field?), and it was often hard to find where to input that field -- very unintuitive. I think I even had to go through a company admin once to add an associated email address to a vendor.
Beyond that, just the philosophy of creating a "purchase order" to pay a UX researcher who did 10 hours of work over three months seemed goofy -- purchase order is what I think of when doing something like ordering printer paper, not getting an invoice paid.
> purchase order is what I think of when doing something like ordering printer paper, not getting an invoice paid
How can you pay an invoice for a service / item you haven’t purchased? If you buy a service from a supplier, you raise a po, you pay an invoice based on the po. As a supplier, I always ask for a po.
And there's often also an approved vendor process as well. Big companies are mostly not OK with just expensing some random new supplier.
And yeah, there's a lot of paperwork but maybe you're hiring this gal because she's your sister. Maybe she's really good. Or maybe you're just funneling some money to a family member. As companies scale up they need controls for a lot of things even if they're legit 95% of the time.
And, again, not a software issue. It's a perhaps necessary bigco process issue.
the funny thing about Concur is its origin was the internal expense reporting front end that Microsoft had built on top of their own SAP implementation.
Andrew Dent and Elena Donio were consultants on the internal MSFT SAP implementation. They took what they learned about building friendly procurement and expense reporting SAP front end apps to Concur.
I was responsible for a MS dynamics implementation at a public company. I would agree.
(This was also my motivation to start my own financial reporting startup: what if we designed a system in the year 2022 to be able to support big businesses without it being as awful as big business software.)
To be honest, i think that even if they offering overlaps with SAP R/3 or S/4HANA, they overlap at the lower end (500-5k employees) and not really at the top end (> 100k employees) where MS sits.
Furthermore, AFAIK Microsoft started using SAP well before they acquired Axapta.
MS uses Dynamics for a ton of internal processes, just not all of them. I suspect the SAP installation predates the existence of Dynamics as a product.
So that's what Dynamics is...thanks for that; I feel like I never hear about any ERP software other than SAP which I found weird, though not as weird as the fact that I've never met a developer at SAP, only implementation consultants...
>I feel there is a lot of room to develop better tools that are not so horrid
It seems like it, but I don't think it is possible. Sure you can clean up SAP itself a bit, but most of the problem is custom UIs that companies develop only to the point where they are useful, but then they decide it is cheaper to train people on how to use the clumsy UI they have instead of paying developers to clean it up. They probably are not long, it only takes a few minutes to train most people on the how to find the few things they actually need, and the slow workflow costs them a couple hours per person per year (and most of them are low wage employees), while cleaning up the UI would costs several man-years of programmer effort.
I left SAP 1 year ago, they just try to add every option to their software and keep maintaining 25 years old applications that are still used by some companies. This is why their software is super bloated and a small and simple task takes so many steps to achieve.
Now they are migrating to the cloud, and loosing customers as they push them off their on prem s0lutions
Clayton Christensen has some nice youtubes about disruptive innovation where he predicts the death of SAP
It sounds crazy and there are some good points here regarding the difficulty of moving from SAP solutions to alternatives, but there is a lot going on and I agree that they are not as invincible as they pretend to be.
Customers are growing increasingly frustrated, the company has dipped its toe into political agendas and they regularly get lit up on Twitter as a result, and Bloomberg has targeted them due to questionable moral practices (most recently, silencing rape victims).
SAP is more concerned with protecting their reputation than actually developing quality software. Sooner or later that is going to catch up with them. They are constantly playing damage control. It's only a matter of time before more and more comes out (and there is plenty to come out).
SAP, Excel, and Bloomberg Terminal are applications where there such a long tail of uses that it is hard to see them being replaced in the corporate world anytime soon.
Exactly. And I'd say that the Bloomberg Terminal user experience is pretty good especially compared to other "enterprise"/expensive applications like SAP. So the only reason you'd want to switch is cost, but that's usually not a problem for clients considering how powerful of a tool it is.
> I feel there is a lot of room to develop better tools that are not so horrid, however, the process for replacing SAP will be long and close to impossible.
It tries to be pretty modular and even the cloud hosted plans can be mixed and matched, in addition to which the apps can be self-hosted for free: https://www.odoo.com/page/all-apps
Of course, attempting to compare it to something like SAP is a bit like comparing OpenProject with Jira or something along those lines: where one of the solutions is way more popular and recognizable, even if the other could be serviceable in certain scenarios. It's pretty clear which one will be picked by most of the enterprises, though.
Customizing odoo is a nightmare it is similar to "It doesn't do everything you want, but it does everything your business needs". (quote by Larry Ellison about Oracle ERP). Underneath its a mess but at least its open source.
SQL database was a large amount of tables alike and if you try to add a feature that it doesn't implement yet (such as drop shipping capabilities) I couldn't figure it out because its not as simple as creating a new set of forms like in Django you basically have to understand the whole system and I think the task would take a year.
It would have been better to integrate an existing system instead.
Hi, Vanderson. I'm doing the same thing here where I work. I would be interested in sharing experiences. You can contact me via my profile if you'd like to chat more about it. I would say from my part it's been a good choice, but so much complexity to deal with.
I actually have not touched any of the code yet as we are using a 3rd party developer to help us. (I will likely work on templates and other things down the road)
My experience when evaluating Odoo was using Studio, which I have found can really mess up your Odoo instance.
No. We are using a 3rd party developer, too. But I'm interested in eventually becoming a developer/consultant for the product. I already do python programming at my current job, too.
There are two major ERP software out there right now: SAP and Peoplesoft.
SAP is the "European" way of doing things, which means there's one right way and you need to align your business to SAP's way of doing things. If you do that, things work very well.
Peoplesoft is the "American" way of doing it, which means that you make your software fit around you. This means a lot of customizations. This makes integrations much more challenging if you're too far off kilter, and things like upgrading is much much harder, because there's too many customizations.
That's the information I had about 10 years old and not sure how much SAP has evolved since then.
Smaller companies these days have a lot more options, like Netsuite is already there for small businesses and Workday is moving in that direction. Startups come and go every day. Rippling appears to be one that is headed in this direction as well.
You mean SAP and Oracle. Oracle acquired Peoplesoft and Netsuite long ago. Oracle has its Fusion product where it attempts to fuse their acquisitions into one platform. Some call it Confusion. SAP has built most of its product to work seamlessly together, but they have acquired a few such as Ariba and Concur.
Oracle/Netsuite has an interesting approach to upgrades--they force them on you twice a year.
Upgrade windows aside, it's ok. I imagine that the sweet-spot for Netsuite are businesses that do 5MM to 100MM ARR. Possibly less if there's a heavy need for EDI, volumetric shipping, etc.
What I meant is most of the Large Organizations are now using Workday which is a SaaS based solution and generally considered modern version of PeopleSoft on the HR solutions side.
Many large companies are also moving away from SAP and Oracle on ERP side of things to Workday Financials too but at a slower pace.
I used to work at a company building software that competed directly with SAP products. The IT people in our customers’ organizations were the hardest people to convince to adopt our software. The end users loved our stuff because it allowed anyone at the factory to build forms and share data. But the IT folks would always get in the way.
“Nobody got fired for choosing SAP.”
Competing with them is super hard because of that.
I think what's often being overlooked is the complexity of the business ( or underlying processes) that SAP supports. There's this strong,yet often unsupported argument that something complex can somehow be made super simple. I work with Salesforce, which on its own approaching the complexities SAP supports, only in different areas. So we have a system,which supports a nonlinear process with tons of inputs, multiple supply chains, etc. The system is designed to support it. It takes users a few weeks to be at least somewhat comfortable with it. Can it be simplified? A little bit, but the underlying business complexities won't change because of it.
While the business problems are complex, there are precious few affordances given to the humans operating SAP user interfaces and even fewer capabilities provided to integrators. Indeed, while it may void your warranty, it's often simpler to query the underlying database directly -- and many vendors do -- than to use the trash interfaces provided by the software.
SAP will fall from a thousand cuts of the facade pattern.
To find a project on our SAP system you had to know a code. If you did a search for the name of the project you had to put a * at the start and end of the search otherwise it would show no results. What is this the 1980s?
Now that's one simple process imagine that on every single step. SAP is worst software I've ever used.
> I feel there is a lot of room to develop better tools that are not so horrid, however, the process for replacing SAP will be long and close to impossible.
Alternatives do exist. Well, one does - Oracle ERP. Migration is indeed long and close to impossible, and it’s very much out of the frying pan into the fire.
I feel this comment deeply as a child company of a parent that uses SAP and they really really really want us to use their (the same/unified) ERP system but it's really bad. 37 clicks across 7 tabs to place an order. No thanks.
We've spent 3 years refining our processes and automating our ERP system, both the data structures we need and the design of the UX. No thank you SAP
I feel like I see SAP in a US company anytime it has major business units outside of the US. I know Walmart and Honeywell use it, and they both are multinational. I have always wondered: Does SAP do something better for international finance/etc. than others or is it just an accepted standard?
> Does SAP do something better for international finance/etc. than others or is it just an accepted standard?
Yes, it does it correctly for tax purposes everywhere and can be used in a way which conforms with how these companies want to do their accountings for shareholders reporting. Also it used by so many companies that every niche thing you want to do has probably already been done.
The people here complaining about the UX for reporting their hours just have no idea of the mind boggling complexity of the problem space. There is a reason everyone use SAP and it’s not because it’s bad.
>> Its UX is the most horribly wicked thing I’ve ever come across.
A few years ago, I was working for a small, family owned industrial company. They were in the process of moving all of their ERP stuff over to SAP. Things were slow with some of the UI/UX stuff I was working on and someone asked me if I wanted to learn how to be an ERP developer.
Before I was shown anything, the SAP guy pulled me to the side and told me, "Fates, I know you could probably write a DB program significantly faster than what you're about to learn, but this is just the way the software was written."
Cue several of their SAP people dropping random stuff in my lap and me taking days and sometimes weeks to discern how to do it in their UI. It was the most maddening thing I've ever tried to learn. I just remember this graph paper like grid and having to line everything up perfectly or the program wouldn't run at all. I felt like I was working with something from the 1970's, it felt that out of date.
I finally told my boss I couldn't do it anymore, it was driving me mad.
On the flip side, I play hockey with a guy who is an SAP sales person and makes hella money selling their software and thinks its the greatest thing ever.
The blog post is written by Retool, and it is something that we (early stage startup) is adopting for internal operations. I was hoping to see Retool talk about what they see their market opportunity is, and what they think Retool is doing different, but the post only sketches out a few things on how things have changed.
I don't know about SAP, but one of the main reasons we're adopting Retool internally is because our engineering team keeps deprioritizing writing internal operational tools in favor of adding features for out customers, yet our operations are becoming increasingly more complex. Something like Retool lets our end users (our own staff) be able to work with it.
In a lot of ways, Retool is more like an MS Access, only it is a cloud native SAAS and from the get go, work with integrating existing databases. Writing about SAS, I think it's clear Retool has been thinking about how to grow with the organization, possibly where organizations can stay with Retool instead of trying to implement SAP. I'm also curious about how they are going to work with the increasing shift from "data lakes" to "data mesh".
I worked for a much smaller SAP competitor, long time ago. Our software was horrible too, but it was good in certain departments in certain markets. So it had decent market share and revenue.
Fresh out of college, with a full two week (!!!) training on the product, I was sent to a customer place, to build some forms for them. Apparently they were not important or big enough for senior people, so I had the privilege (!!!) of building forms using our software for this client. I spent two days building the perfect form, then suddenly all the layout was lost. I couldn’t recover the layout, I call my team. They casually say our layout engine can be finicky sometimes and will refuse to work if you annoy it too much. No one told me though.
Thankfully I found another job soon.
Many of these so called enterprise products are terrible. But they’re so entrenched that it is next to impossible to beat them. They’re also expensive and their business practices dubious.
This is the kind of inefficiency that used to kill companies before the "everything is a monopoly" era. Nobody will ever replace SAP on the companies that use it, and if they are safe from competition, well, nobody will replace the companies either.
I’ve heard a few CIOs say “The surest way to get fired is a security breech or replacing your ERP.”
For many companies it would be easier to do an asset sale of all their IP than to replace the ERP.
Since most ERP implementations are horrendously overdue and over budget, they are usually declared Done before they’re actually finished. That leaves a lot of crud and manual processes in their wake.
In addition, so many of these systems are on prem using hardware, operating systems and databases that haven’t been supported in decades.
Salesforce carved off a big chunk of SAP's business, and is currently valued at $155B.
I'm sure their goal was to eventually replace SAP. Instead, I think they ended up with an 80% solution that requires the customers to invest 20% as much time as a full SAP setup.
For instance, Salesforce spends a lot of effort on sales and customer facing things. SAP does that too, but it also does logistics. Logistics infrastructure is much harder to reuse across industries than sales and customer support.
Salesforce is great, but heavily focussed on Sales / CRM part of the equasion.
I'm not sure if salesforce is able to replace other parts of ERP systems like Purchasing, Inventory management, Manufacturing etc...
ERP systems are much more vast than Salesforce (which I agree, is great in what it does, but it's not ERP)
Sounds kind of like the old mainframes that airlines use. And I would think the same solution applies: rather than replacing it per se, why not wrap the SAP data model by creating bespoke "gateways" that expose a more business-domain-oriented UX — where each thing people want to do is just one obvious button, but drives all those same complex SAP processes underneath?
They protect and take care of a lot of problems, the issue is they're so flexible that sometimes people build ad-hoc things on top of them and over time it becomes a ridiculous monstrosity similar to any other system in a company with major legacy.
There is no inherent solution to this problem other than disciple (or control, which has it's own productivity issues).
A lot of things developers must build in, and decisions developers make, are built in already for these systems.
>SAP feels like one of those businesses that’s too big to fail because it’s so entrenched in the corporate world
more likely situation would be the companies stuck on SAP themselves dying and SAP eventually dying as a result of that. Obviously that's on a long term timescale, but smaller companies not burdened by legacy technologies winning is pretty much the story of modern business
> Challenges too great for a mere startup to accomplish.
It's probably also too boring for any tech entrepreneur to even try, but disrupting the space would seem to be the white whale of startups. You never know. At one point in time nobody had a computer on their desk either.
Sometimes this is why I think we'll end up with a refresh of the corporate world with digitally native businesses not running on SAP. I imagine at some point we'll run out of people who know SAP and are even willing to learn it.
Google recently implemented SAP. Microsoft, Apple, and many other big players are deeply entrenched in SAP with almost no chance of switching. There has always been a shortage of good SAP consultants which creates lucrative opportunities for those who want to learn it.
SAP has developed much better HTML5 UI's, but It is very difficult to change UX on these professional users who are accustomed to and actually have come to like the old stuff which has been around since the 90's.
What about some sort of tool that hooks into SA directly? Something that acts as a more user friendly front end and allows people to automate common tasks etc?
Its not called "hooking into", building your own UI's is the expected and proper way of working with SAP now. SAP even provides the tools for building your own HTML based (simplified functionality) GUIs. There will always be power users who will fix data in the backend directly, but working with custom GUIs is the way to work with SAP.
> It’s easier to just hire people to learn the SAP workflow and then hire external auditors to make sure the accounting policies are properly being followed.
I have a family member who has had enough professional success with SAP; when I mention projects there is a specific response he has that relates to this.
tl;dr- If you change your processes to follow the SAP happy path where they don't you are OK. The more you go out of bounds the more problems you have (be they problems of kafkaesque workflows, or paying the bills to customize it while the scope of customization keeps changing.)
I feel there is a lot of room to develop better tools that are not so horrid, however, the process for replacing SAP will be long and close to impossible. SAP feels like one of those businesses that’s too big to fail because it’s so entrenched in the corporate world. Somewhat jokingly, I think it would be easier to switch the US over to the metric system. Any challenger will have to be massive, accept losses for over a decade to gain market share, and have incredible support for their clients if they ever want to takeover in the Fortune 500 world. Challenges too great for a mere startup to accomplish.
It’s easier to just hire people to learn the SAP workflow and then hire external auditors to make sure the accounting policies are properly being followed.