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.)
My mother works for a fairly large textile lab. For decades, they used an internally developed system for lab reports (they had a few programmers and admins they called the "nerds" that did nothing else than extend and maintain the system). The company switched to a SAP solution a few years ago. Chaos ensued. The SAP solution missed so many edge cases that a huge number of lab reports were either inaccurate or completely wrong because information was lost in SAP translation between different labs. Sometimes clients (huge international players) noticed the mistakes, which then led to costly product delays. It became so bad that communication between labs eventually had to be done on two levels - within SAP, and "informally" by mail, telephone, or by simply walking to the other lab, adding a huge time overhead to every report.
SAP removed virtually every automation advantage of the old system, and added the additional complexity of navigating the SAP GUI. Because of this additional workload and the reluctance of the company to hire more people to counter it (after all, SAP was implemented to streamline everything!), employee turnover suddenly skyrocketed. Everytime I talk with my mother, she complains about the system and tells me that another colleague has quit. She only stays because she only has 2 years until retirement.
I see a lot of comments here saying a company should adapt their business processes to their ERP, and in my experience they are wrong - with the exception of accounting(Good luck trying to customize accounting modules within ERPs to fit your process).
I don't work with SAP, but I've been working with Microsoft's ERP(Dynamics NAV/Business Central) my whole professional career(almost 5 years).
When it comes to shipping, manufacturing, HR, supply, sales, planning, quality assurance etc... every big company is going to have a million edge cases which are impossible to cover with the standard functionality of an ERP. And most importantly - hundreds, or maybe thousands of employees that have gotten used to working a certain way.
When you try to make your process fit to a standard ERP functionality you are fighting two dragons:
1) Working your way around edge cases - with the right consultants/developers this doesn't have to be a big pain.
2) Getting your employees to change the way they have been working for years, or even decades. And in addition giving them an overwhelming UI - I've never seen this work as planned. This is also probably the reason the company your mother works for had so many pains.
On the other hand, if you try to make the ERP fit to your processes, there's only one dragon you need to slay - extending the ERP's functionality.
I can only speak for Microsoft's ERP, but everything that is impossible or hard to extended within the ERP itself can easily be extended through an outside application. And by doing so, you can probably even make the employees job easier by keeping the process the same, but giving him an UI that isn't overwhelming.
>should adapt their business processes to their ERP, and in my experience they are wrong
That depends. I’ve seen a lot of adaptation to processes that are legitimately & measurably better in time & accuracy ignored in favor of costly customizations out of nothing more than “not created here” syndrome. If a customer doesn’t like that then an off the shelf product is the worst choice they can make unless they are prepared to hire a significant in house dev team.
Otherwise, if you have been adapting your current business processes to deal with the limitations of a legacy system first deployed in the early 80's then there's an excellent chance that at least some of those things can be done more easily in a more modern system. (Though SAP may not always be the best place for that to actually be the case).
>If a customer doesn’t like that then an off the shelf product is the worst choice they can make unless they are prepared to hire a significant in house dev team
Correct. This is the problem my company solves. We are ERP consultants/dev's who also know web development. Through the years we've made 50+ web apps to extend Microsoft's ERP, most of which can be used in most companies with similar needs with slight modifications.
And, of course you don't blindly follow a process. There's always some improvements to be made to the process before developing an app for it.
EDIT:
Drastically changing workflows for employees within huge companies will ultimately almost always cost you more... It all depends on the company of course, but we have to generalize a bit.
This is the same niche I fell into - building applications to standardize the work happening parallel to SAP because it didn't cover the edge cases, and people created their own workflows using mostly spreadsheets passed around. Which, comically, our client eventually bought another enterprise piece of software to cover our niche. We figured the gig was up...that was 5 years ago. Turns out the new enterprise software covers only a tiny fraction of the edge cases, so ours just keeps chugging along, paying the bills.
It's possible you might not have worked in erp space, especially sustainment / maintenance (as opposed to implementation) long enough to see true customization price. I certainly didn't my first 5 years - to mis paraphrase, I was excited at all the things I could do, so I didn't bother to truly consider whether I should :). ERP's lifetime at large company is frequently decades, and their roi vs cost is similarly long.
Every. Single. Customization. You make, which makes so much sense to seemingly eagerly satisfy the user during implementation, will be a massive pain, forever, with every patch and upgrade and new functionality released by vendor in perpetuity, and will inevitably cause performance and failure issues eventually. And will only be getting more expensive and painful to maintain exponentially over many years.
Yes, you should customize erp for your very specific edge cases that you a absolutely need. But:
A) number of processes Bob from accounting or Fatima from HR believe are absolutely crucial and immutable and special and unicorn and mandatory, is way way higher than processes which actually are special and must be preserved. Personal inertia is huge. More often than not, special ways of doing things which are not your core business are an unnecessary cost, whether through erp or not.
This may seem like I'm a traditional grognard IT head who disregards users and their needs, but it's quite the opposite so let me clarify with
B) The threshold of customization at which erp no longer makes sense is in fact very very low.
If you actually, really properly are a special snowflake of a company and your convoluted hr or finance or pay processes are your key immutable competitive advantage, then don't get an erp. Other name for erp is cots, commercial off the shelf, which strongly hints as to how its meant to be used. With erp, customizations should be fought tooth and nail on every level,and that's a largely accepted industry wisdom.
>It's possible you might not have worked in erp space, especially sustainment / maintenance (as opposed to implementation) long enough to see true customization price.
I haven't, but some of my colleagues have been in the space for 20+ years.
>Every. Single. Customization. You make, which makes so much sense to seemingly eagerly satisfy the user during implementation, will be a massive pain, forever, with every patch and upgrade and new functionality released by vendor in perpetuity, and will inevitably cause performance and failure issues eventually. And will only be getting more expensive and painful to maintain exponentially over many years.
Wrong. Upgrades almost never break your customizations, because in the ERP space backwards compatibility is verry much a thing with the exception of a few extreme cases now and then. I've migrated customizations from a 2004 version of NAV to a 2022 version of Business Central - even the name of the software changed, and the language in which it is written, but the customizations were almost plug and play after running the code migration tool provided by Microsoft.
>A) number of processes Bob from accounting or Fatima from HR believe are absolutely crucial and immutable and special and unicorn and mandatory, is way way higher than processes which actually are special and must be preserved.
I never said employees wishes should be blindly followed, you still have to do the consulting part of the job...
>B) The threshold of customization at which erp no longer makes sense is in fact very very low.
>If you actually, really properly are a special snowflake of a company and your convoluted hr or finance or pay processes are your key immutable competitive advantage, then don't get an erp. Other name for erp is cots, commercial off the shelf, which strongly hints as to how its meant to be used. With erp, customizations should be fought tooth and nail on every level,and that's a largely accepted industry wisdom.
Wrong. The benefit you get on the accounting side, and the all data being in one place side(reporting) outweighs almost any customization that needs to be done - because, good luck making those 2 things from scratch. And good luck living without those 2 things if you're a mid/big company.
> and in my experience they are wrong - with the exception of accounting
> I don't work with SAP ..
Yeah.. that's just it. Your experience doesn't matter. Adjusting your business to fit SAP nearly as much as an unspoken requirement. It's not just a smart bit of wisdom people throw around. It's literally what you have to do if you want to have any hope of implementing SAP successfully, because it is such a colossal, messy charlie-foxtrot that there is no hope otherwise. Not even SAP's own people understand their own mess.
You're right, for some reason I just assumed all ERP's are as easily extendible as Microsoft's. It just makes sense they would be oriented that way due to the complexity of the world. I often hear horror stories about SAP, and can't for the life of me figure out why it's so popular(except it's more oriented than other ERP's to non-tech savvy people).
I work in this industry(though thankfully very rarely directly with SAP) and I cannot fathon why it is popular either. As I explained in my other answer in this thread, everything they touch turns to garbage.
I think it's really a case of a self-fulfilling prophecy, of a sort. They are the biggest in the business, so people go with them, which makes them bigger, which attracts people.. and so on. It probably helps(SAP) that they also decades worth of man-hours implementing all sorts of insane business logic(like for accounting, as you mentioned, which is something you definitely don't want to get wrong) where other players are likely to be behind.
If you dig you find as much screwed up ERP projects for SAP as you find for Microsoft or for any other system. Differences in absolute numbers are caused different market share of the systems in question.
As someone who has also worked with Microsoft Dynamics - mostly the other products, which are IMHO at least an order of magnitude more complex from NAV/BC - you can customize it heavily, but the high complexity will get to you. Some things are actually rather difficult to do (e.g. anything to do with Ledger or BOM calculations).
Adapting Dynamics ERP to business process is a challenge of its own, and not every company can do it. At least it's possible in Dynamics, SAP is a mess - most customers I know with SAP have to use external software and import/export for significant customization.
> I can only speak for Microsoft's ERP, but everything that is impossible or hard to extended within the ERP itself can easily be extended through an outside application. And by doing so, you can probably even make the employees job easier by keeping the process the same, but giving him an UI that isn't overwhelming.
But then, did you really gain anything by using an ERP instead of just a dumb database, which would have worked just as well as backed for those applications?
> Each of the old IT staff in the old system you can replace with 3-5 SAP consultants.
Is this facetious, or unintentionally so? Do you mean you need to replace one in-house staff with between 3 and 5 and presumably very expensive consultants?
For the duration of the ERP project, SAP is not different to any other vendor in that regard, from preparation through hyoer care after go live, yes. Yes, you have 3-5 expensive SAP, or other ERP system, consultants sitting next one internal IT guy and another 3-5 internal business people with a very deep understanding of the business processes in question and solid basic knowledge about ERP systems. Otherwise you set yourself up for failure.
"'sitting next one internal IT guy and another 3-5 internal business people with a very deep understanding of the business processes in question and solid basic knowledge about ERP systems"'
Where do you think the customer is going to find that army of hyper competent experienced staff ideling around their premisess waiting for the day an SAP project drops?
Yes. I have been one of those. Where do you think the externals get the expertise needed that is particular to the business? We can be professional about it and try to point out the real exceses or answer generic questions, redress and inform on specific knowledge traps or consequences of answering choices placed in front of the customer, but in the end it is still a business that is running 'right-sized' being required to drop everything for a few years to assist an IT transitioning project?
Overloading the customer is one of the simplest ways to make sure ít is not your fault when things most often go south.
I think key part is "for duration of project". Savings, if successful, then come for the lifetime of erp.
One thing I've seen frequently is treating erp implementation as IT project. I'm a technical team member doing erp implementations for last 25 years (not sap) but I'll freely admit erp implementation is not about me or technology. It's primarily a business transformation project. You need those erp business process experts to guide and customize, AND you need thorough willingness to change your internal processes to fit the industry best practices you're buying. "successful erp project" empathically does not mean "installed it and it runs". It means thorough and detailed understanding of requirements, mapping to new processes, customization where absolutely positively necessary, substantial and organized and embraced business transformation, extensive training, and thorough testing including user acceptance testing.
If you think is erp as something you just install and life will be the same but magically better, you're gonna fail hard. Missed requirements and edge cases, and or significant internal resistance to change, are frequent challenges.
Because SAP is what most other companies in the sector use and because there are few alternatives. And because everyone else is m uses it, it must be good. Right? Right?!
Also, because leading employees usually have no idea about the intricacies of the "old" system and think it's easily replaceable with a solution from the shelf.
Yeah, I can't see any better argument against contracting an ERP package. This is exactly true, and those 3-5 way more expensive new developers you are hiring through a 3rd party won't create anything better than the original one that knew your company. (They are not temporary either, because the duration of the ERP project is forever.)
I work for a large telco in the tech support side. We had a bunch of internally-developed tools that were clumsy but worked and fitted our workflow.
We've been fed an off-the-shelf solution with modern tech like Angular and the like.
And even without the SAP burden the company is basically destroying our departament. I guess they don't care to lose us poor peasants but they're basically losing al know-how and one of the only two edges they have against competition.
I can't say I care too much at this point, but it's amazing how easy can companies destroy themselves for not caring about their employees.
This is intentional and part of the business model of most companies selling ERP solutions. They deliberately (or incompetently) make their product so overcomplicated that noone outside of their consultant team can make heads or tails of it. Then they can charge big bucks or consulting fees.
One of my first recruiting jobs was hiring ERP consultants (SAP, Siebel, PeopleSoft, Oracle) and even 15 years ago, these people were easily making $100/hr, and if you were specialized (esp. with the supply chain modules), you could get up to $200/hr. They rarely had programming skills outside of SQL and Linux understanding.
From experience, the factor is more like 5-10. Depending on the complexity of the existing solution, and depending on the wealth of custom implementations, of course.
SAP is better though as a set of libraries than a solution, and it's worth a lot precisely because it will fit whatever whacky process an organization has so that the org doesn't need to change itself while adopting the software.
The most obvious failure modes are going for the lowest bidders incentivizing them to deliver with a skeleton crew, trying to nickel and dime the budget cutting features or their scope or straight up coming at the table with no documentation of how orgs own internal processes actually work.
I know of no project failing because of sap or their consultant on its own without any of the above comorbidities.
I taught enterprise systems for a while and SAP's ethos is very much 'change your business processes to fit SAP, because if they don't fit SAP, they're probably wrong'. This is actual advice (in slightly different wording) that comes from their training materials.
It's probably both. If you fit the standard pattern you'll have an easy time to adopt. But they also support edge cases with extra work. A small company with many non-standard processes will need so much extra work that it's not worth it. Then it is cheaper to redesign the company and reshape the company processes.
I find it very difficult to fight for sensible defaults in a company when everybody only sees their area and has a very strong opinion about that. Only a strong force like the SAP transition can break up with those encrusted structures.
I mean compliance IMHO is their selling point: If you are working internationally you make sure that you correctly handle taxation/reporting or whatever to the standards. Other even trust you because you run SAP (which must be correct by definition). And because SAP is so big I think a lot of regulation/reporting requirements will be even done a way that it can be done with SAP. We are a university/research center hybrid and use SAP. As a state entity or funds are limited. Being in a 'nieche' with tons of strange accounting requirements, a very heterogeneous IT and without the money to get the reports/etc fixed quickly I can tell you how much hell SAP is on the other hand.
A few of old IT guys with no fucks to give and a few "up and out" junior devs working over time can whip up a one off abomination build out of LAMP stacks and CGI scrips with a little perl thrown in and an unusable set of websites to handle all the data entry and exit and it WILL ACTUALLY WORK. It will be clunky and the onboarding time will be comical but it will work.
That is a low bar. Your "lowest bidders" should at least be able to equal that. It just has to accomplish the business processes and do so within the software. It doesn't need to be fast, intuitive or look good doing it, it just needs to do it.
Funny considering in the 80/90s SAP sales/management was known for saying that you don't adapt SAP to fit your company, you adapt the company to fit SAP. There was another company (was it Baan or JDE? I think Baan as I had too many meetings at the time with those religious fruitcakes) that said they were better than SAP because you don't need to change your processes; you change the software.
The thing with an SAP introduction is that one has to analyze and understand how the business actually works to adapt the system to it. However in reality nobody really knows. There is a general idea, hopefully, but over time there are more and more shortcuts and side processes and things. Unless you analyze them an introduction of any new business software (be it SAP or Oracle or whatever) will fail.
Whether it is worth it depends a lot and is hard to say. It will certainly demotivate many employees who are used to the old way, but might lead to streamlining (partially due to software, but norendue to analysis) and more insights (with risk of then optimizing the wrong metric)
>It will certainly demotivate many employees who are used to the old way
In my experience, what demotivate them is that a lot of the features in the marketing materials for these types of products are lies and they are filled with bugs. The executive who chose the product typically don't use it so they think it's a great tool. When you report major problems or workflows that makes no sense, they brush it off like it's just small details that need to be ironed out in the future because aren't the ones dealing directly with them on a daily basis.
The exec get sold on an AI feature and it's the intern who is then forced to deal with a search bar that take 2 minutes instead of 0.5s to search and gives you vastly inferior results.
I'm one of those employees and it just makes my life miserable. To the point I want to quit.
It's been one year of this BS and it's clear no one cares or listens to our complains, so we just pretend to work and execs are angry because of KPIs, clients complain, etc.
But seriously, we can't do it anymore. Their idea is that with this new software everything will be taken care automatically and so they won't have to educate employees anymore and technical knowledge will no longer be needed, and we'll become you regular brainless contact center but magically better because we have such good software!
Agree, except one point. You adapt your system to SAP, not the other way round. And tgat is actually a much better thing than it seems, because SAP is used in so many comoanies that you get a load of best practices out of the box. Adapt those core competitive advantages you have, take the rest as is.
By the way, edge cases, if if they work in a legacy system, are a thing to get rid of during a SAP / ERP implementation. Most people see ERP systems as IT projects and fail. ERP projects are at least as much business reengineering projects as they are IT projects.
First part what you mention is a bit arrogant, no company wants to do that, and by doing it would lose most of competitive advantage which can very well be in those edge cases and their handling (and often they do lose their edge by going SAP way and sometimes collapse because of it). Like hearing SAP sales guy.
Second part is actually correct - you have to change your way into how SAP works, its just a typical crappy legacy rigid mammoth software that requires overpriced army of devs/analysts, not much more. If it would be marketed that way, they would go bankrupt very quickly because no company willingly wants to do that, and certainly not at that cost.
But anytime some c-suite manager picks up SAP, you can be sure there were some nice meetings done in ultra luxurious places and more often than not some bribes went that way, in one form or another. This is the way, if your system sucks so much it destroys companies
>But anytime some c-suite manager picks up SAP, you can be sure there were some nice meetings done in ultra luxurious places and more often than not some bribes went that way, in one form or another. This is the way, if your system sucks so much it destroys companies
The drive to ERP is understandable. The issue is that homegrown solutions suck too - most businesses aren't IT companies and can't properly maintain a custom solutions. Using a third party makes sense, and allows you to hire outside devs with experience. SAP is however usually not the best solution...
As a rule of thumb, take 80% of an ERP system as is adopt max. 20%. If said edge cases are truely your competitive advantage by all means get them working in your ERP system. More often than not, people consider edge cases competitive advantages when they usually are just legacy stuff that doesn't really matter.
>The thing with an SAP introduction is that one has to analyze and understand how the business actually works to adapt the system to it.
Anyone who's ever worked with ERP software knows the entire system pushes you to do the reverse - adapt the business to the ERP. Going against that flow is possible, but expensive. This is especially the case with SAP which was always even more difficult and expensive to customize.
I think most bang for the buck one would get if you start with SAP - so to say you start shipping company and you get people with knowledge that configured other such systems and you build process on top of SAP from start.
Unfortunately I don't think this is realistic scenario because when you start a company you probably don't have time/money or need for SAP or anything like that.
Shipping is actually one of those cases, well logistics in general, where SAP actually isn't that good. Still usable if those are supporting functions, if thosr domains are your core business I'd use something different. If you are creating a production company some lite version SAP, there was one back the day that was light and easy (for ERP standards), wouldn't be the worst choice long term.
I work on a home grown solution at work, but they are considering abandoning it for a third party system that everyone we talk to says is inferior in every way. For some reason, the higher ups trust software built by someone else rather than their own people.
I worked on home grown internal apps a long while ago and saw the same happen. Upper management gets sold on some ERP system (SAP, Oracle doesn't matter) and believe it will save money, streamline things, etc. whatever the marketing/sales people of the ERP say it will do. The yearly expense for licenses on the ERP was enough to fund a team of 5-10 developers and QA.
Here are things upper management doesn't consider:
* Picking the same ERP solution everyone else in your industry uses means you have zero competitive advantage now. Homegrown solutions with teams staffed to run them could give you an advantage.
* You need to pay expensive consultants to do things with ERP. If you want any customizations they will be a bottleneck for all future updates, possibly having to bring in expensive consultants every time you need to upgrade.
* The culture shift for employees is usually negative across the board. The IT people supporting it, the end users inside the company, basically the choice implies that management doesn't value its people or their thoughts on how to do their work.
* Vendor lock in. Switching from one ERP to another isn't likely to happen. They can raise their licensing/cloud costs when contracts are up and your company is likely stuck.
Marketing is a helluva drug. People are trained to trust big companies and the bigger the company the more they trust it. I think the issue is the variance in solutions if you compare all the homegrown solutions against all the big company solutions. And that gets managers into the mindset that there's less risk in a generic big company solution. But of course that misses all the details for a specific case like yours.
It would be like interacting with other people who knew based on the average of everyone on Earth as opposed to dealing with the person you knew based on their own personality.
But it's easy to manage based on these kinds of broad generalities and, as the saying at least once went, no one gets fired for choosing IBM.
In this case, the third party company is tiny. And they keep screwing up. Even something as simple as right to left language translations they can't get right, even when we walked them through how it should work and shared code with them.
>Everytime I talk with my mother, she complains about the system and tells me that another colleague has quit
I used to be a consultant for a big non-SAP workflow product. Had a long time employee quit specifically because of how bad the product was. That was not an easy thing to explain away.
AFAIK, they introduced SAP elsewhere in the company, and it became difficult/too expensive to manage the communication between the old system and the SAP system. I can imagine too well how the conversation between the SAP people and the company went because I also took part in similar conversations with clients in a previous job a long time ago: client asks you if software X can do thing Y. Both you and the person representing the client have only superficial domain expertise on Y. "Oh, you mean enter data into a form? Of course software X can do that, it was designed exactly for that purpose!"
The complexity of the task is eventually discovered in production.
> The complexity of the task is eventually discovered in production.
I’m amazed that this is what happens every. Single. Time. And yet we plow ahead with this kind of projects like we have no idea it’s the usual outcome.
A couple years and millions over budget later, we rediscover this axiom. I really don’t get it. And try to warn about this, you’re labeled as not a team player or whatever and paint crosshairs on your back for the next round of layoffs. It’s just soul sucking.
> I’m amazed that this is what happens every. Single. Time.
The details about the day-to-day operations disappear quickly as you move up the hierarchy.
My boss recently had a meeting with a large customer of us, we deliver a product used heavily by one of their departments. Here's roughly how that went down:
My boss: "Well, what about when you do orders of type X?"
Manager: "Oh we don't do those"
My boss: "Really?"
My boss brings up the order list and filters on type X, finds at least one entered each day by user ABC
Manager: "Oh... so that's what she does"
So that information was lost in just one level.
This is why we try our best to get the actual users involved when discussing requirements with a customer. I don't think I've ever experienced a project where at least one of the users haven't brought up some edge case the manager wasn't aware of or had completely forgotten.
On the flip side, the projects where the users are left out of it until it goes live never goes well. We'll get it fixed eventually, but there's always pain for far longer than necessary.
Isn't this story rather a strong sign that many managers are simply incompetent? I mean: how can you seriously manage things if you don't even know what kind of tasks you actually manage?
At a certain level, managers have to delegate broadly. I think this is best illustrated by the US Army. In an ideal situation, the commander general guidance about his intent. Then his subordinates plan how to accomplish it. I wouldn't expect a Colonel to remember how to fire a mortar properly, and it's the same in IT. My manager expects a well run, secure and efficient datacenter. He expects his SMEs to take care of the details and bring issues to his attention if they exceed the ability of the SMEs to resolve.
Eisenhower was in charge of D-Day, arguably one of the most complex human endeavors. He made the majority of the decisions surrounding it, of course influenced by outside factors (De Gaulle, Churchill). He chose Normandy, he decided which units would go where, who would lead the campaign on the ground. Incredibly important decisions, yet he left the tactical decisions to those on the ground. Delegating broadly, as a good commander should.
General Marshall, Eisenhower's superior also delegated broadly, while making key decisions as to the timing of the invasion, which units would be involved, and making sure all the disparate organizations involved were used to the best effect. Again, delegating broadly, as a good commander should.
This goes on and on up to Roosevelt himself, the Commander in Chief at the time. Does he know jack about the tide tables on Omaha beach? The range of a German 105mm howitzer? Of course not. Yet he clearly mandated the important decisions.
All three of these leaders were clearly EXTREMELY competent.
It's human nature. I do this rote task so frequently that I don't know the steps.
Most of my work right now is trying to eke information out of customers about their ERP system so we can get it connected via EDI or to their Ecommerce system (shopify whatever).
So we go live, with a whole process revolving how payments are accepted - and then within an hour there's a problem. Nobody mentioned that certain customers have a different payment workflow!
Back to the drawing board, except we're already live.
The guy making a deal with SAP and their revolutionary solution is a few steps removed from the poor technician/engineer that is aware of how many corner cases the business runs on. This is why every company with at least 2 levels of hierarchy is doomed to repeat this costly mistake.
This is what big corp suppliers like IBM, Oracle or SAP thrive on. CEOs and executives not actually knowing the intricacies of their company, and underestimating the risk of creating a very expensive second system effect.
I guarantee the CTO has a much more realistic view of these projects and understands how hard it is to deliver these things successfully than the average engineer. There's a metric ton of complexity and their jobs depends much more on their ability to deliver the project at a whole without knowing all the details.
The fact is the higher you go the concerns separate. I think the army motto was "go 2 levels up". You're a grunt, you need to know what your platoon and your company are up too and what the goals are so that if you can't follow the plan directly, you can still hit the objective. This is good because no plan army or business, survives reality without changing.
In the same way, you can only go so many levels down.
On an individual decision making scale, there are no repercussions for the bad outcome. The people who decide on plowing ahead get another bullet point on resume for “accomplishing” something, since the outcome is impossible for an outside entity to verify, but doing “something” is verifiable.
The short answer is that a sales guy in a nice suit took some execs out for steaks and more than a couple cocktails.
The long answer is that management, these days, is trained to outsource everything while still being clueless about what the people they're replacing actually do.
In-house tooling requires a dedicated team, not just developers but also analysts, testers, etc. Often a company inside the company.
If the software needs to change due to industry changes or regulations or something like that, it will probably be a lot more expensive to implement it yourself compared to using an off-the-shelf tool developed by a company who's sole purpose it is to respond to those kind of changes.
>it will probably be a lot more expensive to implement it yourself compared to using an off-the-shelf tool developed by a company who's sole purpose it is to respond to those kind of changes.
If your company is small or at least in a field with lots of competition sure.
I work in a >100person company that encounters loads of regulatory changes due to food safety and lots of international trade and 2 people developing is good enough. The part doing the accounting and such is largely outsourced to an ERP but is honestly simpler yet just as costly if not more.
What's more things go wrong. That's a given and the absolute best way to deal with it is with someone as close to the processes as possible. you don't want to be calling vendors that are generally absent to see in which part the software lies.
Even for industrial equipment that is a lot more single process it is kind of accepted that we people on the ground need to know a good bunch to troubleshoot ourselves rather than paying someone to come over. After all if we wait for that we get a bottleneck that has dozens of people twiddling their thumbs.
The idea that the SAP solution will be "off the shelf" is just not true. You will need as many of those roles, probably many more, to keep the SAP based solution running.
This happens because the people working below senior management are usually not slick talkers and many people in senior management do not understand IT. So a savvy salesman who knows the right words can convince the guys at the top to do what he (its almost always a he) says.
> . The SAP solution missed so many edge cases that a huge number of lab reports were either inaccurate or completely wrong because information was lost in SAP translation between different labs.
Is this the story of every migration, every rewrite though?
The job of the implementation project and team (generally comprised of power users and staff from the vendor or certified partners) is to find those edge cases and automations so they can be dealt with. Most ERP has halfway decent workflow automation tools and development tools that make small modifications easy and large ones at least possible, though for huge gaps an organization might just choose a best of breed 3rd party tool and write bidirectional ETL jobs using APIs.
The real problems are
1) organization staff on the implementation who don’t actually know enough edge cases etc. This can be through poor requirements gathering ir because the power users are considered too important to take off their normal work and the company is too cheap to hire enough temp staffing to cover their absence.
2) A bad “fit-gap” analysis the maps old system functions to the new system to find the gaps. This is the vendor/partner (consultants) job so that’s on them. Failing here sets the project up for failure or major cost overruns or just years of people pissed if that they can’t do what they need to do. It also breeds shadow systems and work arounds that make knowledge transfer after staff departures vastly more difficult.
3) vendor/consultants looking to maximize $$ by either sandbagging hours of work with unnecessary things like customizations that are just not needed. I’ve seen plenty of examples where vanilla functionality is much faster than the old system but “that’s not how we do it here” . The vendor doesn’t care to push back because they’re getting paid for the extra work, and when the customer runs out if its 1,000 hour block of custom dev time and still has essential work undone the customer has no choice but to pay up or suffer. Meanwhile the vendor has every email and change request order signed off in their records where the customer approved the work so they just shrug their shoulders.
4) A general unwillingness by the customer to actually pay the $ required to do these things right. There seems to be a sense in higher level leadership that “it’s software, how hard is it to install software?” and have no clue and don’t care to hear it until the sky is falling that there’s a lot more to it.
There’s more too, but I’ve been on a few of these and never seen one that didn’t include some combination of the above. They absolutely can go smoothly with a minimal amount of the above but it takes real work and a dedicated procurement & vetting process just to find the right outside implementation partner (going with the vendor itself is sometimes okay, sometime not. I wouldn’t touch Oracle Consulting ever ever.)
Even then it will not always be as smooth as using a legacy erp with roots in the early 80’s that has been customized for decades. But that sort of tech debt is massive. New functionality can be a nightmare, causing more tech debt and raising maintenance costs non linearly. If it needs regular updates for things like federal compliance (tax systems or other regulated areas) a vendor might when it finally EOL’s a system it first released before you were born still provide those updates to remaining customers of their legacy product to give extra time to transition but then you need to either role your own dev team to do it or pay outside consultants to do so: Retirees from places like SAP often make a nice bit of extra income doing dev work like this.
SAP embed in the software knowledge and enforcement of the organization the company should have. This knowledge that build in the last 30 years by working in logistic, manufacturing, retail... When you install SAP, you should obey SAP, like I don't know, rust (don't try to do c++ in rust ;-) ... If SAP has nothing to say about organization at a Lab, just don't by SAP.
I am sorry, but anecdotal cases of hickups in the transition between a bespoke system to an SAP one do not mean that SAP is useless. I don't understand why you don't blame the internal IT guys who did not nail the specifications for the SAP to work exactly as wanted in the first place?
And what is the take-home-message here? Should they have stayed with their (admittedly not good enough) internally developed system? Should they have gone for an Oracle solution (plagued with its own set of anecdotal catastrophes)?
> I don't understand why don't you blame the internal IT guys who did not nail the specifications for the SAP to work exactly as wanted in the first place?
Often times it's very difficult to correctly specify a system. This is one of the problems with lock files and why some people have gone over to docker for development.
IMO, the people to blame are management, who needed to appropriately staff the transition for enough time to get it right.
> Should they have stayed with their (admittedly not good enough) internally developed system?
What evidence is there that it wasn't good enough? Sometimes management gets sold on a "better" system, only to find out that it isn't actually better.
I am an SAP developer since kind of forever, my first job after university (since 2009). First I hated it, but the deeper I am entrenched, the more I see why you choose SAP: Because there really is no alternative. The data model is so complex because it is growing iteratively since the 80s. Hacker News is valuing businesses that adjust to the customer instead of going for some kind of purity. Another complexity especially now is the different paradigm changes in between. ABAP, the programming language of SAP, is quite nice nowadays. CDSViews are a great invention, and so on. There's really a lot of innovation buried in the bad documentation, it's getting better. In summary as bad as it is, I don't see an alternative for all of the backoffice work. SAP is really flexible and supports a lot of different processes. A thing that makes it so costly is a lot of time culture, no small releases, MVP, and so on. But you can be agile with SAP, especially if you move to the cloud.
Speaking of purity, the first thing Hacker News would do is try to run SAP on a Kubernetes cluster, refactor crucial bits in Rust and shard the database into sqlite3.db files on per user basis. We'd also recommend you restructure your office for a more open space, bring down the cubicles and make sure the conference rooms are glasswalled and have funny names. Bringing pets to work is mandatory.
And ironically, the end result would be worse and more complicated, but the people that worked on it would get to write a blog and put it on their CV about it, and move on elsewhere without having to live with their own decisions.
This is so true! As the author of a (small) ERP/MRP SaaS, I am often amused when I read HN and observe the thundering herds of fashion followers — today it's Kubernetes and Rust, Postgres and sqlite have a longer lifespan, but tomorrow it's going to be something else entirely, and you necessarily need to use those :-)
I am always thinking about Vinge's "A Deepness in the Sky" and computer archeology: there is an accumulation of the code base and at some point most code will be some kind of legacy.
It is not feasible to rewrite it in the fancy language/technology du jour - huge waste of resources for things which already work fine and at the moment you are done you have to start again, since the IT-pendulum is traveling in the opposite direction.
We, as an industry are really bad at working with legacy code, but for a lot of us it may be the main task if we endure this line of work for some decades more.
I think there's a bigger issue at play that at some point I want to write on.
Small problems benefit from small tools. Large problems benefit from large tools. However, small problems grow and your bet as a small problem is that your tools will grow with you.
In practice, they usually do. If they don't, you end up extending the tool or rewriting it in a larger tool.
So, our tools start small, and small companies use small tools, and the ecosystems grow together. Then, the successful ecosystems end up the next large problem toolkit.
As you're a small ERP SaaS, you're banking on growing with your customers, I presume. And you can make an argument to start on the large tools at the cost of initial velocity, but that's your tradeoff.
I really think the innovation that needs to happen is a system that has a prescribed growth path. Retool/Excel/similar that can compile to a simple app that can adapt to more complex patterns as the need comes.
Same here, all the hip trends of the day, and then back to the same Java, .NET and C++ that I have been touching for several decades, Boring Technology™.
Yep. If I ever read an article/post about my competition using Kubernetes to run microservices, I'll be quite happy, because it will mean I don't have to worry about them.
> We'd also recommend you restructure your office for a more open space, bring down the cubicles and make sure the conference rooms are glasswalled and have funny names.
This is a genuine question, I don't mean to rip on you: Why is everything SAP I've used terrible? From payroll, employee/student management to industrial control systems - the UX is horrible and it seems so brittle that you're happy if you're out of there as quickly as possible. I've had to reach out to my school's IT multiple times over the years since random parts of the SAP tool they used break.
a) Engineering: Nobody will rewrite 20 year old views just to improve the UX. In many cases, nobody even dares to touch the 20 years old spaghetti code.
b) Sales: The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying.
c) Management: There is a solid economical rationale in not giving a fcuk about UX. Over the years, SAP outcompeted and absorbed many competitors that were more interested in UX than golf. Golf won every single time. Nobody at the top understands or cares about UX because it does not bring more revenue, it is a cost.
> The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying
I see this trotted out a lot but are all large companies really that oblivious? Do none of the decision makers talk with the people that work for them? Surely those executives aren't so divorced from reality and common sense that they don't see a problem when people complain that things don't work or if they do, it takes an order of magnitude more time and effort?
Surely there must be some other explanation for the proliferation of these systems other than "execs dumb and bad"?
It’s not “execs dumb and bad,” it’s that execs have different priorities than you think they do, which I think is partially dandare’s point.
Executives at a large company are divorced from your reality at your level of the job.
Incidentally, that’s part of the fun of working at smaller companies, though the variance is higher there’s also the potential to work more closely with good earnest executives who also want the company to succeed.
that's a problem and we're going to have to fix it
>it takes an order of magnitude more time and effort
that's not a problem
the fact that Jane the accounting drone has to do twice the amount of work, or has to hire an intern to help her out, or even wants to quit because the job is so awful now is not a problem
it's a rounding error in the overall cost of implementing an ERP system
a new screen with some new data to show for the exec is worth 20 Jane's and her opinions on the new system
you can't even call the new system unethical or fraudulent because 10 people other then Jane can now stop using broken excel sheets to organize their work
This sounds about right to me. In particular, it tends to partiton the organization into (A) the people whose job it is to plug away at the ERP system (orders, invoices, tickets, etc), and (B) the people who actually do whatever it is that the company does.
(C) - License costs can also play into this partitioning.
Then you hope (and work to ensure) that the benefit achieved for B, by having consistent org-wide information systems to work from, is enough to cover the overheads of A and C.
The simplest explanation is a mis-alignment in incentives.
Executives want to have successful projects to show to their value to an organization. But usually the board members are unable to comprehend the details of a project. So the herd mentality kicks in. The CTO will seek approval for SAP and provide Gartner magic quadrant BS to give the board a level of comfort.
Now whether SAP is the right tool, or if it inconveniences users doesn't matter a whit to the CTO. All that matters is budget and timeline. The CTO wants to be able to speak to the board and say that the project timeline was met and under budget. All else is a complete non-factor.
I hate how bad UX has become the standard due to management/executive negligence, and there is so little the actual users can do about it. Even small players tend to neglect UX because of the financial incentives.
I find smaller companies can have a more direct connection to their users, so the outcome is usually better UX. The disconnect from the user in enterprise software regularly results in poor UX, and the incentives to improve it just don't make their way to the people who need to hear them.
I don't see why you'd split the two. Actual good functionality is UX. Lack of good functionality implies the user has a bad experience given the intended goal.
Big players tend to do the minimum, either attracting with shiny red herrings or barely doing anything at all. Both are bad UX.
From talking to actual end users though I am convinced there is no universally good UX. Someone will not understand it no matter how perfect you think it is.
Now I favor ugly but robust UX for business applications. The user doesn't have to love it, it's their job to use it. It just has to be efficient and comprehensive, not pretty
I am so thankful to be working in an organisation which is reshaping its delivery teams into product teams. Our users are customers and if they want a better UX, they get a better UX.
> It's actually terminal software, that's translated into a GUI from a text interface on the fly
I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it?
E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
Historically, yes. It was basically like translating an ncurses (semi-GUI command line thing) into a UI. There were attempts to move away from that model, but at least when I worked for SAP, most actual deployments were still text-to-UI. It was basically a way of slapping some varnish on what was fundamentally an old-school mainframe system.
It's the same today - S/4HANA is still accessible from the GUI and DIAG is still used. Web applications (which SAP is pushing customers towards) are freed from this, of course (they talk native http to the SAP application server).
Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.
Agreed! SAP's GUI is generally terrible for occasional users (luckily most have now been moved to web-based applications, of varying levels of user friendliness), but in the hands of experienced back office staff it works well. Not pretty, but very functional and with shortcuts for everything.
> the issue of listboxes only having the currently shown items loaded
I challenged this design decision when Fiori was introduced and the thing is that statistically the lists are either small or huge. When they're huge, they got touched in less than 10% cases, so by not loading the whole content you save a lot.
I'm not actually sure, because I feel like most of the things people do with SAP are very repetitive. Their UIs are mind-bendingly bad, but you mostly learn to do the 3 things you have to do all of the time, and then do them over and over again. I'm not sure how much having a nicer UI would make that easier.
It's absolutely not something you just randomly explore. I think that's a more interesting question: what sort of empowerment of employees could you create if the UI wasn't so terrible?
But SAP's moat is elsewhere. You put up with its terribleness because nothing else can do what it does. Beating SAP would require you to reach that, and do something else, part of which could be a nicer UI.
Every business software is at least as complex as the business process it models. That's the thing you training for.
Every detail of the business process is now explicit. Employees have to be forced to work according to actual process. You need quite a bunch training for that. Then employees will find shortcuts to make their own job a bit faster/easier, which will fuck up some cases. You need even more training for that and possibly some redesigns. And all you get from that is depression
No, because the training is about the core functionalities of those ERP systems, what action triggers what and so on. Training is not about how the UI works, this knowledge is gained on the job.
They wrote you can be agile if you move to the cloud. Did you try that?
I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition.
A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry.
To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies.
Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp.
Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do.
But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.
I think you don't see the full picture here. The developers working for SAP usually don't need any certifications. They are regular computer scientists/physicists/mathematicians etc. who write code / design systems.
There are of course the certified consultants that work for clients of SAP. I can however understand why they need certifications. It's probably impossible to configure these systems without some kind of special education in them.
And as for the quality of SAP devs.. I work for SAP and I have met many very qualified developers at the company. Far more than I anticipated before joining the company. Quite a few have been poached by Google et al but that is another topic.
I think they were talking about "front end" SAP devs that are hired to work on custom solutions by a client. Not the core devs that actually work for SAP on building the product itself.
I think ERPs are a basket case category generally. I've worked with SAP for a few years (or more accurately work hard to keep it out of scope for what I do) in my day job. I've also worked for a company providing ERP stuff for SMEs (mostly S).
Anyway SAP/ERPs aren't code for running your business. They're code for running code to run your business. Now you have all the shortcuts SAP made to get stuff out the door, and on top of that you've got all the layers of shortcuts your business has made to get things out the door too. Therefore lots of nasty difficult complexity.
And finally I've seen evidence that in SAP people treat it like the fundamental abstraction layer is the spreadsheet[1]. So like in unix everything is a file, in SAP everything is a spreadsheet. This is a nasty complicated fundamental abstraction without the natural elegance of Unix's one.
[1] Maybe it really is, maybe it isn't but that's how a large chunk of the ABAP code I've seen treats it.
I remember SAP circa 2003. The only think that used XMLHttpRequest (AJAX aka dynamic html) was Outlook web frontend, and SAP web UI. GMail that widely popularized dynamic html did not even existed yet.
"SAP developers" can mean two different groups of people. The developers who build SAP, and the developers who build the custom stuff that clients need. The former can be quite innovative, but the situation with the latter is pretty damn grim (and I say this having worked in the industry, and my dad still works on it)
The UI isn’t just terrible, it’s hostile to the user. The rare times I am forced to interact with it I feel like I’m using software that was meant for some other purpose. I’ve worked in the industry for 25 years, I’ve never come across worse UI.
My favourite bit of the SAP UI is whenever you scroll a listbox, it goes back to the server to load the rest of the list. It only has data for the exact 5 items it's showing; the other 1 above or 3 below each need a server hit. And it forgets the data it loaded before.
It isn't use for you as a user, it is meant to run your company. You are not the user, you are the one feeding data into the system. And that is actually perfectly fine in case of ERP systems.
It definitively is neither pretty, discoverable nor intuitive, but in the hands of experienced power users (who have spent a lot of time learning the UI), it works really well. I have seen people (who have used the system probably for > 10 years) dig the most arcane information out in seconds, navigating through about ten different views without ever touching a mouse.
It's a UI from another era, but if you take the time to learn it properly, it can be very efficient.
I kinda feel like SAP is the ultimate in checkbox checking. If you ask every department what they need, and write it all down, then find the product that matches all the checkboxes, SAP is it.
SAP checks most of the boxes of almost all industries you need to run a modern business. Some specifc domains better than others, sure, but none are actually bad or unusable. And all tjose functions are integrated with each other. That alone is tremendous value.
Some weaknesses I see with SAP compared to dedicated solutions are in logistics and warehouse management, process industries (e.g. continious chemicals production, SAP is way better for discrete products and still it works just fine for the pricess industry), aerospace MRO (SAPs aerospace and defence package is more geared towards production) and eCommerce (eCommerce as a business is not that complex).
Basically, if you are a manufacturing company SAP is easily among the best solutions out there. Added benefit of using an ERP that litterally everone else is usong as well: you have a way larger pool of people to recruit from that know the system. The less market pebetration an ERP has, the harder it is to get people who prwviously worked with it. That means higher training efforts, more need for external cobsultants and performance issues until your emoloyees adapted to whatever ERP you have.
I think part of it is the problem space to be honest. SAP basically gets used to glue all the fiddly bits of organisations together and I don't know that there is an approach to that set of problems that doesn't get tangled up in corner cases.
With a lot of the nice looking web based apps we're used to looking at, the UX and the target domain evolve together and if there isn't an elegant way of doing a particular operation then there's going to be pressure to drop that operation entirely. SAP deployments always have to do everything in the organisation so complicated corner cases either get dropped (bad) or end up with suboptimal interfaces (also not great!).
Why did AWS, a group probably fairly technical savy and a direct competitor to its vendor, take so long [1] to migrate from Oracle?
Why does Google, as of today, have job openings for SAP in its Rev Rec division [2], and more widely in areas touching [3] “ SAP ERP domains (e.g. Finance, Revenue/Cost Management, Billing, Materials Management, Sourcing, Procurement and/or Inventory Management)”?
Granted you could say, and I believe in one of the many google “corporate biography” books Eric Schmidt allegedly worked through this same problem: hey is an ERP a product for us? A core competency? Should we build it? [Seems HN discussed this in 2021 already, 4]
Conversely, given the wide ranging scope of random things Google has built and how naively simple accounting and something like a fixed asset ledger looks at first glance…why did they never do it? Surely not because building 7 conflicting chat tools was a priority.
My guess (as a non developer) would be it’s crazy hard to build SAP. From personal experience even QB Online has a daunting level of “backwards compatible” complexity [5] in its data scheme even coming from an accounting background. The API keeps versioning up incrementally and you’ll find gems like “XYZ local French Tax” and other accumulated baggage. As an anecdote, using arguably a knowledgeable vendor, as of a year ago it wasn’t possible to populate a full simple profit and loss statement via Fivetrans ETL tool [6], even though they did a phenomenal job in mapping out the ERD compared to anything else that existed imho [7]. CDATA let you run SQL queries, but the complexity of scripting some of the reports was much more fragile. The community even built a DBT layer [8] and given how cumbersome it was to generate even just the “Revenue” line on the P&L out of a simple non-enterprise tool like QBO, SAP seems 1000x harder.
That’s probably why everything in-market, post-sales cycle is garbage. But hey, someone in a dorm room might be working on replacing SAP right now :)
Note: this excludes versioning, which I believe Workday does every six months, which is also a bunch of work twice a year.
> ABAP, the programming language of SAP, is quite nice nowadays
I took a brief look at the ABAP wikipedia article and this insanity [1] stood out to me.
I think after a decade of SAP you are too brain-washed to give an objective opinion anymore.
Wow. That is pretty insane. I hope there is a tooling to surface a warning when it detects this.
But lots of domain specific languages have idiosyncrasies. The Apex language used to program Salesforce is a half-implemented clone of Java from a decade ago. And they didn't cherry pick the best parts.
Some companies will be forever scarred by the past trend to create an entirely new programming language for their product when an existing one could‘ve been entirely sufficient
For a regular software developer, ABAP is pure insanity. But it has powerful data manipulation procedures, it's easy to just create and manipulate all your data tables in any way you want.
>, but the deeper I am entrenched, the more I see why you choose SAP: Because there really is no alternative. The data model is so complex because it is growing iteratively since the 80s.
Yes, the scope of ERP and SAP is so immense that even other software companies that have competency in the business of programming also buy SAP licenses instead of coding their own home-grown ERP system.
E.g. Microsoft, Apple, Amazon, Google all run SAP.
Microsoft even has their own ERP software (Dynamics GP acquired from Great Plains Software) and yet they run SAP. Microsoft sells Dynamics GP to mid-tier businesses but they don't use it internally for the consolidated financial accounting of their complex
multinational business.
And in an interview about Google's early days, one of the employees recommended that they install ERP system like SAP and co-founder Sergei Brin was skeptical saying "Why would they need to buy that when their programmers could just code it themselves?!?" Well, Google did eventually buy Oracle Financials ERP and then eventually switched to SAP: https://www.google.com/search?q=google+migrates+oracle+finan...
If you're a brand new YC startup, you're not going to need a complex behemoth like SAP ERP. Maybe Quickbooks or some SaaS service for accounting & HR/Payroll is all you need. However, if the business grows enough (i.e. multinational), you'd be wasting money by paying your own staff programmers to re-invent what SAP already does. Just pay the millions in SAP licenses. It's expensive but still cheaper than trying to do it yourself.
After participating in the hiring of an SAP developer I realized -- financially speaking, anyway -- that I picked the wrong thing to specialize in.
The first time we brought in someone truly experienced in SAP development, we paid him more than any other developer on staff[0]. I appreciate the different take on SAP. Can I ask -- is it still as lucrative to be an SAP developer?
[0] This was a global multi-national telecom who ran an in-house developed audio conferencing service (written entirely in C++, interacting with a lot of hardware) ... the skillset of some of our devs was incredible, which made this all the more surprising.
SAP developers aren't paid because they're more talented than other developers, they're paid because the niche in which they're deeply embedded extracts extreme business value.
It may take just as much talent to write interfaces for obscure audio hardware and deal with janky bluetooth edge cases, but that doesn't mint the same $$$$ as a SAP guru who refactors a business process to be more efficient.
Depends what you're comparing it to. Even in Germany it's a niche skill set, that has a higher payment than the average Java guy, but with enough skills you can get paid the same for any specialization, e.g. security, cloud-computing. I changed to solution architect recently, which is a bit removed from SAP work itself.
I am a project manager and a SAP user. First I hated it. And the more I used it, the more I hated it. It's like a really, really uncomfortable chair, strong, but designed with zero attention to ergonomics.
Hey, I worked for SAP for ten years and I don't agree with you. ABAP is still ugly with all its improvements, version control system and developer experience is awful. CDS views are great until they aren't, then we had this newest feature where you build apps with metadata on top of CDS views and that's where I decided that it's not a software development anymore.
I do see how Fiori launchpad is a great thing, how HANA is extremely powerful if you know what you're doing. At the same time I couldn't stand the corporate culture, QA processes and etc anymore. There're innovations and innovative teams but for the most things SAP is doing, software development is not the core competency.
Fun fact: I work with Datapath now (if you know what it is then you get an irony)
This should be the SAP tagline. I swear I've heard this since I started working with SAP in maybe 2009(?) as well - I had a brief stint as an ABAP developer.
Indeed, for a long time it seemed like SAP didn't "get" cloud. Having to sign long contracts and speak to an account executive to get access to their cloud platform (rebranded every few months, now "Business Technology Platform", BTP) was the way they did things. Contrast with Google, Amazon, etc.
I've not yet used S/4HANA Cloud (only the on-premise version), but it looks to me like it's just a hosted version of standard S/4HANA but with various restrictions on what you can customise etc. No real elasticity, cloud scaling, etc. SAP ERP has been multi-tenant since at least R/3 in 1992 (I never used R/2) so "Cloud ERP" smells to me like "we host it for you and call it cloud".
There are two versions, the on-premise landscape and the cloud version. The on-premise version makes sense sometimes. You can even deploy SAP platform to cloud foundry.
maybe this one: https://open.sap.com/courses/abap1 In general open.sap.com is the site where you can learn stuff. but depending on your customer's stack it might be different.
Again, as I noted elsewhere in the thread, I worked in R&D at SAP for 4 years (16 years ago), but I have no deep love for it. But I do have some understanding of where it fits in the landscape.
What you've said is absolutely true, but it's mostly a feature, not a bug. Once you get big enough to need SAP, it's actually useful to put your business processes on a standardized platform. It's painful, always mind bendingly expensive and often fails. But few companies want to be innovative in their business processes. It's actually better to move to "the standard" since it makes processes more understandable across different ginormacorps, which is useful for the upper management sorts that tend to move between them. There's virtually no competitive advantage to having unique business processes. There are many folks that even will say that that's the advantage of moving to SAP is it makes the internal mechanics of the company work a lot like every other giant company.
I have to disagree here strongly. You are just saying, that a company that became big enough, so it can afford SAP, should drop their way of doing business, drop the processes that made it big in the first place and go through a painful and expensive process where it will become just another SAP shop, with zero competitive advantage.
Telling that losing your uniqueness and being like “everyone else” will actually become your competitive advantage is something that only SAP can come up with.
If you already grew big, you won't grow bigger by adopting SAP. You can stagnate at best, as shown a million times in the real world. Companies that still want to grow just don't use SAP. Period.
> drop the processes that made it big in the first place
This is pretty much never the case, and more often than not the company is successful despite those process, not because of.
Many processes evolve on an ad-hoc and as-needed basis, with some tweaks here and there over time as the company grows and staff turns. You eventually reach a point when no one can remember how a process came to be, or why Sarah has to export four files from three web interfaces and copy/paste data across two Excel files to send to John over in accounting that was just trained last week on how to use this file to true up actuals.
There's only so many ways a company can track inventory, or manage purchase orders, or calculate product costs, or represent sales order and invoices. An ERP acknowledges that a vast majority of businesses operate with the same set of industry-specific operational primitives, and businesses have learned that it's both more time-and-cost effective to adapt your business to the expectations of the ERP than the other way around.
In the rare case you're doing something novel, you can still build your bespoke solution on top of those existing ERP primitives without having to re-invent how the numbers come together so your company can spit out the three financial statements.
Not the OP, but my feeling is that you use standardised processes when they are not your core. For example, if you produce a widget using various raw materials, is the way you pay your staff delivering any competitive advantage? Or the MRP process you use to re-order engineering spares? Probably not - standardise those. Implement unique processes where they differentiate you from your competition. Standardise everything else.
Sorry, but that's just not borne out by data: almost all of the Fortune 500 companies use SAP (something like 80-90%; probably the rest use Oracle, which isn't significantly less painful to move to).
A company I once worked at was taken private by a private equity firm. One of the first initiatives this firm kicks off upon closing an acquisition is moving the company to Oracle for ERP. It can take years and many millions of dollars (as it did in this case--the company was built around an in-house sales and order system), but it's part of their playbook. I have no idea if it's truly worth the cost, but that equity firm surely believes so.
That needs some nuances. There are some processes that are just well-known by research to be standardized - like supply-chain, regardless if JIT-style or forecasted stockkeeping.
SAP does not need to touch the "unique" detailed processes that makes a company great, nor it's culture. But if you e.g. manufacture a product, the design process can still be relatively unique to your company, but most often, the manufacturing processes should follow the high-level blueprint of manufacturing companies.
Is it the business processes that make a company successful, or is it the product, employees and business culture that make a company successful?
If its the former, than conforming to SAP is giving up what made you good. But if its the latter, then conforming to SAP is just making the basics more standard and easier to maintain.
Successful companies are rarely leading their industry because they have competitive advantages across their HR or Accounting or CRM or Inventory or manufacturing (etc etc) processes. Large company requirements are typically the same or very similar across industries for these standard business processes. It makes sense to standardise on your ERP for these. The typical problems come when companies think they are special and start to customise.
Standardise the mundane (with an ERP, with minimal customisation) business processes so your company can focus on innovating where they have true competitive advantage. This is the recipe for a successful ERP implementation.
Lidl is a private and entirely family-owned business. They tend to have more idiosyncratic business processes compared to public companies. That might partially explain why they struggled with SAP so much.
> There's virtually no competitive advantage to having unique business processes.
I'm not intending to take this sentence out of the context of the rest of your post (on its own, I don't think you agree with that[0]), but I think even in context of "specific to resource planning" there are many competitive advantages that companies pursue.
Take "Time Accounting" for example. I'm not referring to tracking hourly employee hours for payroll, I'm referring to tracking salary employee "project time." Every past salaried position I've had at a company with more than 90 employees had its own custom time tracking software[1]. The first company to do this was a multi-national telecom that I worked for. It was done so that each project could be broken out into its stages and the portion of the employees' salary could be itemized among "Capital Expenses" and "Operational Expenses". This was so important to the company that it warranted a massive development effort along with a corporate initiative to get 100% of time reporting in "on time." They did this as you'd expect a huge company would -- fail to hand in a time sheet on time a few weeks in a row and you'd get dinged more for that mistake than anything else.
The second and third companies ended up "accidentally developing time tracking software" specifically because there was competitive advantages to improving "Resource Planning". It was most helpful to my last employer. Their businesses was creating new products (often hardware/software combinations) for companies. This involved hiring a large number of people specialized in things that had limited cross-over. Resource Planning was predicting when what skills at what level would be available. This, necessarily, involved tracking what time was spent on projects in the past to improve those predictions and ultimately ballooned into a full time management and accounting application for the business (they sold "our time" to customers at the end of the day so it helped them to plan what to charge).
I'm curious -- from your perspective, is it that the competitive advantage is lost "because the tools that everyone is stuck with won't work" if you stray too far from "standardized" or is there another advantage to this standardization?
[0] Unique business processes and marketing are frequently the difference between the #1 and #2 company in a given space.
[1] In one case (about 250 employee global company), the company wrote it as a concept for a future product but once it was available, the existing solution was tossed primarily because the business side really liked the flexibility. In another it grew out of a pet project and became entrenched. At the remaining two, a decision was made to develop something from the ground up.
I've known one place that did bend SAP to their will, and they were stuck on a soon to lose support version despite having almost 100 SAP developers on staff (almost half their entire IT)
With 100 mildly competent developers on staff (although not with SAP developers) a company can develop in house everything they need to run a business in a period of time that is shorter than what is needed for a typical "SAP adjustment".
It really boggles the mind. What can be so complex that you can not do it in 300 person years of development time plus the cost of SAP.
Specially with the tools that exist in open source. Amazing databases, data modeling systems, libraries to integrate into literally everything.
It think the bigger problem might actually be to define the process you want to implement. What are the specifications, what of your existing system is actually needed and what isn't. Rather then the actual implementation of those processes in some digital process.
I have a friend who work himself up from worker in a warehouse to team leader and now SAP something something manager. And from the story he tells me I am mostly constantly confused. The whole environment feels incredibly foreign.
> It really boggles the mind. What can be so complex that you can not do it in 300 person years of development time plus the cost of SAP.
Build a inventory planning and tracking system for a company that operates in every country in the world and has to issue and receive invoices, customs documents, waybills etc in hundreds of formats, currencies, languages and accounting standards.
And you are right that the biggest problem is definining processes and data types. Whatever waybill system a 100-head HN Rust and JS crack commando comes up with, you can rest assured that there's some authority somewhere that wants an item displayed differently, so you either patch this and many other edge cases until your codes becomes an unworkable spaghetti, or you go back to the drawing board countless times and ship nothing, or you outsource it to SAP and the likes who have spent decades coming up with a working solution (even if it's not that elegant).
Its a fair point the amount of differences of the external world really does force an absurd amount of configuration complexity on your system however well you do on your internal processes.
You really don't just need 100 programs but you need 30 people defining the processes and 200 configuration experts.
This really seems like something the world would profit from creating a huge amount of open libraries for all this stuff. There are so many old apis in all these old systems. I work in banking and when switching company and then you re-implement the same shitty format again.
You would obviously need some people who have done ERP systems experience, not just 100 random developers.
I think, at least I have heard, that Tesla does its own internal system, would be interesting to see how many people they have working on that if its true.
Yeah because developing business practices from scratch for a giant company is a coding problem so 100 developers should solve it... probably as difficult as making the next Uber for rikshas, right?
Posters in this thread are so clueless it hurts to read.
For one, it's similar to the "nobody ever got fired for picking IBM" saying. Especially in Germany. As far as I remember, one of the managers involved was former SAP too.
But also, SAP has a lot of accounting and legal process knowledge baked in that is reusable even if you customize everything about it. That's what "mildly competent" developers are missing.
> Respectfully, the way you affirm such a thing with such certainty gives me the feeling that you might be pretty far left on the Dunning-Kruger graph on this topic right now.
No, writing "Respectfully" at the beginning of your comment doesn't make you respectful. You are just one of those people who want to show they are smarter than anyone else without adding anything useful to the discussion. Hide your insults better next time. Or better, don't insult at all. Or even better, shut the fuck up.
Please don't respond to such a comment by breaking the site guidelines yourself. That only makes everything worse, and "shut the fuck up" is the kind of thing we ban accounts for. Please don't post like this again.
Saying that you seem to be a novice in a certain field is not an insult. I myself don't know much about SAP and that's fine. But I don't have the pretention of saying with confidence that all the customers of a $100B+ company are idiots for paying millions when they could hire 100 developers for a year and be done with it.
Reminds me of large government departments where some idiot in the IT architecture team says: "Woah there buddy! Why do you think it's safe to assume that Microsoft Office is what we're going to use? What if we decide to use Open Office?"
That's maybe one or two words away from a literal conversation in a huge meeting with dozens of high-level IT staff overseeing an org with 30K staff and a petabyte of existing Microsoft Office documents.
Boggles the mind that some people think this way, but they do.
Like... imagine an electrician wiring a new office building having a debate about which frequency and voltage to use. "Don't make assumptions!"
Pretty amazing that some people still believe that choice exists rather than submitting to the monopoly. That's a petabyte of files locked into a proprietary format. The smart thing to do is bow down to the monopoly. Only an idiot would try to shift the balance of power back to the users.
Imagine what wiring an office building would be like if all the wires, circuit breakers and tools could only be bought from a single vendor. Boggles the mind.
There have been tons of innovation in the field of electrical engineering since the standard voltages and frequencies were fixed. New installations are made to a better standard than older ones, while still maintaining interoperability. They don't blindly stick to the status quo without ever questioning if there's a more cost-efficient option like big-corp IT departments tend to do.
So if you were building a 40-storey high rise office building and the sparky you hired decided to install electrical outlets that were all 400 Volts and 30 Hz, you'd be fine with that?
I think a better analogy would if the sparky decided to use a new type of wire with better conduction than standard copper.
As GP comment said, there has been innovation in the electrical engineering space that maintains backward compatibility.
So if Open/LibreOffice could actual deal well with MS Office formats, for example, whilst removing the annoying bits (cost, telemetery, UI[0]), then yes, it might be wise to move on from the status quo.
[0] in practice I don't think the OpenOffice UI is better than the MS Office, but in theory some people could prefer it
My first job out of college in the late 90s was in a large division of a larger company (about 80k employees at the time) that was being spun off in the hopes of selling it. As they were going to be made a stand-alone company they needed their own ERP etc and went with SAP. After two years and $50M the dotcom crash killed any chance of selling the new company and it was absorbed back into the mother ship and SAP was thrown away.
> Lidl based its inventory management system on purchase prices. The standard SAP for retail software uses retail prices, and fearing the group could lose a competitive edge by compromising, Lidl declined to change, so the software was instead adapted.
That article says Lidl/Schwarz has abandonded SAP and gone back to their custom system. That surprises me because I have a friend who does SAP consulting for them.
No, as in the article mentioned, there is so much configuration that you can do. It has it's own programming language, and nowadays a lot is processed in the backend. It helps a lot when implementing new things on top. It provides for you already an entity model, and you can easily add your own tables (which most customers do). Migration to a new schema is my favorite part that I miss when I develop in other systems. For everything there is a tool that grew many years and is really battle tested.
You can customise it, but you do need to stay within limits.
If you go too far, a SAP version upgrade is no longer a drop-in operation, but rather a year long project of porting all your changes to the new version.
If you stay as vanilla as possible, upgrades are a lot easier.
This. SAP has no restrictions on how much you customise it - you can customise and extend to your heart's content. The problems come during upgrade - SAP has very mature tooling to manage upgrades but a customer who has veered too far from standard will need to rework their customisations to fit the new version.
Many many customers have been burned by this over the years - being too trigger happy and customising/building their own extensions rather than using the out-the-box functionality. Packaged software exists for a reason, don't use it like a PaaS to built your own solutions.
SAP is now pushing customers to "keep the core clean" and stick to standard as much as possible, which is definitely a move in the right direction.
It's the same reason why Jira is so popular. CIOs recommend it to each other, because nobody wants to admit they made a mistake and that it wasn't as easy to integrate in the end after all. It's like getting a nose surgery and telling all your friends to get one as well. In most cases people look worse afterwards.
It's funny to see people here defending SAP, because the way I see even the smaller shops that did bend to SAP's will ended up with much of the same problems but with less much to address them and on top of that, much like other enterprise grade ERPs they had to spend a lot of money on infrastructure to process only a few RPS while struggling with high availability.
Jira is perfectly fine, especially if you self-host it so you're not limited by the crappy Atlassian cloud server capacity.
BUT the problem is that Jira is infinitely configurable. Add 20+ projects with 20+ project managers/leads who want to do things Their Way and you've got a clusterfuck on your hands. Every project has different terminology, different workflows and different ways of handling the same types of projects.
What Jira needs is a single (benevolent) dictator who is the gatekeeper of adding new workflows, tags etc. Then it works.
No, Jira is popular because it's flexible. You can customize Jira to fit any process. That flexibility comes with a price tag, which is performance. SAP is a complete opposite, a truly inflexible “my way or highway” type of system.
One very large video game studio has tons of automation for Jira. Imagine someone deciding to add new weapon. The automation creates 100s of tasks for concept artists, 3d artists, animators, sound artists, software developers with complex dependencies better those. Most importantly, automation creates multiple QA steps for each element of completed work.
The same exists for levels, enemies, quests and tons of other elements.
I would not be surprised if a lot of studios had similar workflows.
That may be true for certain industries, but a lot of shops work on CRUD apps and use Jira in its fairly stock configuration. Linear or something like that could do the same job for them just fine.
> Why is SAP still in business? Is it solely customer misinformation?
The lock-in is huger than huge. I don't think a single company on earth managed the art of locking in customers as well as SAP. Does anyone ever drop SAP? I don't know: the cases have to be exceptionally rare.
It's a racket. Highway robbery. This kind of behavior brings in a lot of revenues.
I personally do think the sale to the customer is complete and total misinformation. And once you've fallen for it, there's no way out.
I once consulted for a place that had one seperate ERP for each acquisition or merger they’d had in the past few decades. They all had projects in progress to decommission/merge them back down to one, but they were never able to turn a single one of them off.
The competition is generally worse. I tell it as someone who saw few different products offered by the competition. This doesn't mean that SAP is good. Also this doesn't mean that there isn't space for someone who could do it better by starting with a clean state (what sounds easy, but is actually very, very hard to pull off).
First you should know that the market for ERP systems is very wide. There are LOTS of various companies that offer their ERP systems. Also a lot of those "ERP" systems are "enterprise resource planning" in name only.
The smaller ones often are focused on one thing only: bookkeeping, warehousing, invoicing, purchase management, salary calculation. Often they started as something that does one thing (usually: bookkeeping) and then more and more stuff was added on top -> as requested by customers. There was this old theory, that at some point each peace of popular software becomes so big that it can handle email. And guess what, SAP can send emails too. Tons of those other ERP systems can send email too. Different thing is if they really should.
The smaller ERP solutions often dont scale well (they cannot handle too many "things" e.g. millions of invoices, millions inventory SKUs, 20 different countries..) or are too simple / not flexible enough to actually customize. With those smaller systems, you can understand them (e.g. the whole system has few thousand tables), but this comes at the surprising cost of lower flexibility, because in order to handle the complicated business cases you have to recreate the complicated logic as well.
SAP was used by so many big companies that a lot of the complicated logic is already there in its 'standard' (and as others pointed out: if you want your life easy, you should adjust your company to the standard, instead of trying to customize). Different thing is that you need a consultant to even know that those features exist. And as you can imagine SAP is so big that even the consultants can only focus on a certain part. [also I personally knew a situation where consultants wrote a custom extension for something that was available in standard -> they didn't know standard SAP standard well enough..]
I kind of disagree that a typical configuration of SAP has 20 000 tables. The ones I knew usually had 50 000+ and those were just few "modules". Using SAP terminology you have modules like FI (finance: bookkeeping), CO (controlling - financial reporting), FI-AA (asset accounting -> think list of assets the company owns), SD (sales & distribtion - e.g. issuing invoices). There are lots of those modules and usually the consultants know "their" module + the finance module. Because at the end the FI (finance) and CO (controlling) modules are always on the top -> you want to register the things that happen in financial ledgers and make some reports out of it.
For example: the consultant that sets up invoicing for you will know SD module (to set up the actual layout of invoices - how it looks like when you print it, the process flow etc) and FI (to help you configure that the invoices land on correct sales accounts). Someone else sets up the PM (plant management) module. Someone else handles access rights / authorization (small ERP systems often struggle at this part - and often "everyone can see everything" what is a big no-no in times of GDPR and just batshit insane when we think about corporate espionage).
A lot of complication with SAP comes from the fact that it can do things as per laws of different countries (please note: not necessarily out of the box, usually you need configurations and external add-ons). For example if you want the taxes calculated by the system for USA, Germany, Poland and Japan - then SAP can do it for you. The system (after painful configuration) will calculate the sales tax / VAT tax and also provide data to calculate CIT (I am not sure if any company calculates corporate income tax out of the box, I always saw an expert from SAP to some data/warehouse and a magic Excel file on top). Also laws change all the time, so system has to change all the time.
Even the basic stuff gets complicated once you need to handle it at scale + for many countries e.g. you want to issue the invoice, you need to use the correct tax type (e.g. VAT in Europe), the correct tax rate (e.g. like 50++ rates per each country), then you need to handle things like invoice corrections, exchange rates, handling exchange rate differences, withholding tax. And it is like this with >everything<. Every business activity that can be handled can be cancelled/reversed, what makes the logic of everything convoluted (e.g. when you reverse the invoice 3 weeks after it happened you need to use the correct exchange rate as per each country's law), because the bigger the company the more probable is that they will do something that shouldnt happen.
SAP can handle this at scale.
Other thing is that there is a big moat. The process of setting up any ERP system takes at least months and generally years. The article explained it quite well. You need to migrate data to the system, check if it works, see if can handle your cases, train the users (the training part often is ignored, so lots of features are not used). Often the companies also dont have anyone to help with customization AFTER the migration, what is another big problem.
It is public knowledge that more than 50% of ERP implementations fail.
There is also some degree of economy of scale. People who used SAP at one company have it easier to use at another. Although devil is in the configuration details. But at least they dont need to relearn the interface (that is awful in most ERP systems).
In a typical big company at some point you need to have your own in-house ERP administrators, who outsource parts of requirements to external sources and deal with the easier stuff on its own. The smaller systems are often inflexible for that - source code is not available. Different thing is if you want to handle the SAP source code with comments in German (yes, that's how it looks in some places; table and column names are German abbreviations too).
Speaking about incumbents: I read that there is some "magic" open ERP system (forgot its name - maybe it was OpenERP), that has just under 20 tables that supposedly can handle everything, but I never looked much into it.
Perhaps 20 tables with 1000+ columns each (maybe still better than 50 000 tables with 10 columns each).
And to end it: ERP systems are like elephants. Once you set it up and it "kind of" works, then you dont want to touch it. You dont want another few years spent putting lots of effort on your tooling. You want to deal with actual core business part of the business. The article also pointed it out -> the quote that in some markets being able to implement the ERP better than the competition is the competitive edge is quite true.
There are lots of companies with very very bad ERP, or multiple systems that dont talk with each other. What makes reporting hell. (not that reporting in SAP is easy) And without good reporting, the decisions are taken too late, or not at all.
> table and column names are German abbreviations too).
This was the craziest part of doing SAP development. (I'll admit this is an America-centric viewpoint.) But the codes to get to various screens were (to me) totally random. e.g. to create a purchase order, the code is ME21N. Only after 6 months, did my German boss let me in on the secret that all the codes "made sense" if you knew the German phrase for "purchase order" or whatever.
I guess it's fair for the world having to deal with .cfg .txt .exe and all the other English that's essential for modern computing.
Going away from SQL Tables based storage to RDF type store (that can model graphs) with a powerful scheme validation system seem like it would make sense given the insane complexity of the data models involved.
I have done work with some subsystems like you would also find in SAP and usually I found the SQL Databases weren't that amazing at modeling what I wanted.
But I don't know enough of how these systems work. Does every location or subsystem have its own db that get some compared in the software layer or is there usually a single source of truth db somewhere?
SAP has changed its architecture from "old" SAP R3 / ECC to "new" SAP HANA. The "new" HANA is not that new -> it was made few years ago, but when it first came out it was quite undercooked. In addition due to the nature of ERPs, it takes often few years to upgrade from one version to another.
SAP HANA basically sits on a custom server and (as far as I know) just uses a column database. The hardware is setup/customized by SAP. Perhaps they want to squeeze some margin here too. The conspiracy theory is that it is not for speed, but to spy on their clients. Or that they dont want to deal with customers mis-configuring their servers.
As for the table structure, then most stuff sits in just big tables. I dont know if the system shards them internally; from user point the tables are just one entity, not divided by anything. You can query them without having to glue anything. For example the table AUFK has order data for all orders, in all entities, in all years. (on a side note: many other ERP systems make separate tables for each year, what is a pain in the butt for reporting, but also allows to shard the data easier).
SAP also has this concept of "MANDANT" which is kind of abstract concept of access rights, that can be compared to entity, but it is not really a financial entity (there is a field for that too). Perhaps internally the databse somehow shards the data on MANDANT level, but from user perspective you just see one big table.
And boy, some of those tables are big that you only extract deltas to your business warehouse.
>Does every location or subsystem have its own db that get some compared in the software layer or is there usually a single source of truth db somewhere?
The idea of SAP ERP (and I'd argue the idea of most ERP systems) is the ERP system is your source of truth. All its subsystems sit on one database, that (if you stay within standard) shouldnt ever break.
Many companies have other systems that "feed" data to SAP -> e.g. you do some inventory planning in some super-nice stuff, but the actual "bookkeeping" (source of truth, orders, financials) is in SAP.
Isn't it the most rational thing to assume that a company that is extremely experienced and successful at analyzing business processes and digitalising them will know better than any newcomer with less resources and less experience who operates mainly on "we're disrupting for the sake of it" swagger?
Telling SAP that you want them to change their ways to accommodate your brilliant idea is akin to a layman telling a brain surgeon how he wants his surgery done.
SAP is sold to the C=suit, never to IT or business operations, nor any of the people that will ever come onto contact with the software.
SAP is priced based on your company's revenue. In industry X typical spend on IT is y% of revenue, so SAP will charge you a project for an amount equal to y% of your revenue.
SAP project often fail (this is not specific to SAP but common for large projects). Making sure that in case the project fails it is the customers fault will be strategically taken into account from day 1.
SAP's revenue is for the large majority based on consultancy and education revenue, not on software sales.
SAP's data and business process model maturity varies extremely depending on the industry and business segment. This will not be clear in the sales trajectory and not easy to discover upfront.
SAP is a fairly closed ecosystem. Typically consultants are recruited straight out of school and never leave the stack as it is very different from the rest of the industry. It has it's own cultute and habits that do not travel well outside of it's niche.
> SAP is sold to the C=suit, never to IT or business operations, nor any of the people that will ever come onto contact with the software.
Plenty of terrible corporate software works like this. Precurement has a checklist of features, and that list never includes "Has great UX", because only the people on the floor has to use it.
I'm looking at you JIRA...
> SAP project often fail (this is not specific to SAP but common for large projects). Making sure that in case the project fails it is the customers fault will be strategically taken into account from day 1.
I was a consultant at a major software consultancy for the better part of three years. No matter what, it is always the costumor's fault, even when it isn't.
Paying a customer back some 100 billable hours worth of payments is simply just not feasible, when a large part of consultants have less than a years worth of work experience.
While you sit down and talk about the project with senior and managing consultants, you are being deluded with a completely skewed perception of the base level competence of those that will carry out the work.
The higher hierarchical "level" a consultant is at, the less implementation work they'll do, because associates will take longer time doing the same tasks and will therefore sell more billable hours.
The entire T&M consulting industry is economically incentivized to produce organisations that shirks responsibility, while simultaneously work on "too big to fail" projects, because that's where the money is at.
> SAP is a fairly closed ecosystem. Typically consultants are recruited straight out of school and never leave the stack as it is very different from the rest of the industry. It has it's own cultute and habits that do not travel well outside of it's niche.
Not to mention that it has its own programming language. I had a colleague that worked as a SAP consultant, and she said it was horrible. Features like "variables names can consist of at most 8 characters" certainly didn't help.
Agree 100%. The whole "management consulting" industry is rotten and all of the "Big 4/5" accounting firms suck. There are boutique consultancies that do excellent work but so many CIOs will go with Accenture et al. because of their name and perhaps because they perform their annual audits, etc.
BTW, on the last point - ABAP (SAP's proprietary language) has improved a lot over the years. Variable names are no longer so short (a vestige of the R/2 mainframe days) and the language has adopted a lot of features from Java and JavaScript. Not always the best (OOP like it's Java in 1998, woo!), but definitely a lot better than in the past.
Work for a small consultancy. Our project's manager at our customer fought with others so they don't force him to get Accenture. Their argument was "when the project fails and we have taken Accenture, then it is not our fault". The project would most probably fail with Accenture..
Currently the customer is very happy with our development speed and unhappy with their Accenture project's speed
"The definition of successful SAP migration is one where the company remains solvent."
The company I work for maintains and has built some custom ERP solutions. While we've never dealt with SAP directly, almost universally the mindset of the IT departments at these businesses is that they are the last defence against the dark forces of SAP.
ERP migration is a terrifying thing and they seem to fall into the same pattern every time. Company has their way (workflows, processes, strategies, philosophies) of doing things. New ERP consultant promises the tool will adapt. Company spends $50M with consultant and product trying to make the tool adapt. Pain loop of "Well, it can't really do X like we said, but we can make it do Y which is close!". Company either a) bends to the opinionated process of New ERP, b) cuts their losses and runs, c) spends years and millions more trying to fight the opinionated process and then cuts their losses and runs, and/or d) goes bankrupt.
It seems to me that the only way to do this right is to spend as much time as it takes nailing down your processes and workflows, being honest with your company about what you need to change, what you want to change, and what can functionally change. Then use the broadest technology possible and create a custom solution. I feel like there's room for a broad business logic framework/library.
Welcome to my world:) I'm a software dev and always worked in or around sap (~13years).
Sap's secret sauce was understanding that different companies have mostly the same needs. All have employees that need paying and maybe shifts to be tracked. All generate invoices. All buy stuff from suppliers, etc. So they built different solutions (HR/FI/etc.) For those needs. All running on the same technical platform with its own programming language: ABAP. All domain code is ABAP and everything is readable, you can even debug code that SAP wrote years ago but (generally) you're not allowed to change it. And it's full of comments in German so good luck :)
For medium to large companies it's a no brainer to use SAP so most do. For example Sap keeps the client's systems compliant with new laws. Say some country changes laws on how employees pay taxes, sap updates the code or tells their clients what's needed to update the systems.
Companies that have been around for a few years, most likely they already have SAP so makes no sense to shift to something else.
SAP's ERP code is also quite generic. Tons of configurations are possible in any module. E.g. you may have employees but no shifts. Or maybe you have 200 different shift patterns across many factories to configure. Configuration is so complex it's a well paid profession in itself: the functional consultant.
When that config is not enough to implement the requirements then developers can modify the system. Either changing existing ABAP code, or building new ABAP programs or (more commonly nowadays) just building webapps with the normal tools (react/node.js/java etc) in the cloud and using sap ERP as a backend to read/write data to. This last one sums up my day to day.
ABAP is interesting though. Syntactically it looks like COBOL and that you've gone back 40years plus most of the DB tables/columns/data types have seemingly random names like WERKS or DMBTR. They make sense in German after you've shortened the German meaning to 5chars :). So ABAP code looks very cryptic at first sight.
But semantically the language is ok. It is strongly typed, has some nice features for working with finance programs (e.g. fixed point arithmetic) and an OO model that feels familiar to anyone that knows Java (e.g. single inheritance).
This needs to be higher up. Big points that SAP has going:
* Compliance
* Standard Processes
* Interoperability between companies (a lot of purchasing runs automatically through some sort of SAP Software)
What mostly fails in my experience is the customization. Everybody thinks their process is super special and important and needs 100 escape hatches. But if you ask them to draw their process on a whiteboard, they couldn't do it for one single process without drawing 100 question marks.
That is where SAP shines: The whole thing is so bureaucratic, coming from Germany, which is something you will need after your company has grown beyond a certain size.
Gartner has at least one thing down that I believe is “the way” - they call it “postmodern ERP”. [0]
In a postmodern ERP there is no ERP.
It’s a strategy where you accept that different domains and companies know their business and processes best and you integrate best of breed systems & services with homegrown solutions.
You trade the convenience of letting SAP or Salesforce own your processes against flexibility and actual agility.
The cost is competence - you’ll need developers working in stable, dedicated domain teams, even within the administrative/cost-center areas such as HR & Finance. But there is a massive potential in this approach. It forces ownership of processes and allows for rapid changes of digitized processes, integrations and technology.
I must stress stability of the teams: agility comes from building domain knowledge and continually working on contracts between organizational units over time. This is the complete opposite to classic project management.
SAP caters to non-tech savvy businesses people striving for control, which is something they think is achieved through “one system”. I personally call it the “one system trap”.
In the end what matters is data, and that data do not have to reside in one database. In fact, it’s better for everyone if it doesn’t - this is what ELT is for.
Well, this is possibly the only one thing they have down, IMO.
It’s a strategy. No products. No quadrants. Just a more reasonable way of looking at business IT and enterprise development.
It happens to mesh well with my experiences and it’s sometimes nice to be able to whack “Gartner” about in certain settings - especially when someone’s trying to get traction for a magic quadrant product! :)
And to be fair - this is a thread about SAP and ERP…
It's a standard publication read by upper management at tons of large companies. Being in a quadrant is basically marketing to exactly the people you want to reach.
Because there are many large companies who's entire purchasing procedure seems to be to select whoever's furthest in the top right of Gartner's quadrants
What's the problem with Gartner? According to them we would be out of work and biz peps high on milky-way charts can accomplish anything with mouse clicks.
I'm glad I'm seeing some SAP post on HN frontpage. Why?
When my sister started to working at SAP working on documentation, I had to look at some of those. I noticed something like SAPUI5 and thought: hey, this looks pretty modern and nice and something that competes with Microsoft offerings! https://sapui5.hana.ondemand.com/#/topic/8b49fc198bf04b2d980...
I went onto HN to learn how people feel about the development tools they provide and found... nothing. I was like: what? How can they have slick documentation, processes, tools, frameworks, cloud offerings, database (SAP HANA?). So basically I thought - so much competitiveness for Microsoft there. How come HNers don't mention this? What are the people working with this tech? Germans mostly or what? But navigating their documentation, tutorials feels something that could be evaluated as a modern development platform.
For all the documentation you see surrounding SAPUI5, it is very incomplete when you have to actually use it do develop something.
It is built on top of jQuery and extremely slow. They are very adamant on MVC with two-way databinding (the opposite of React or most other frontend libraries that have been around for almost 10 years). The backend request is geared toward OData (think graphql but table-oriented), and adding logic between the UI and the OData endpoint is hard.
SAPUI5 is hard to use even for a mediocre screen need. It aims to get the simple apps really simple to write (to lower development cost), but at that it kills the productivity of all the other apps.
Getting back to documentation, after your app is not just some components living in logical islands but have to interact with one another (think getting data from one place to drive another component) most of the time the documentation did not help with that, and I had to resort to debug the whole library internally to understand it.
Add all that to the fact that they don’t even care to support firefox for non-windows users bah
It is really understandable why no one but SAP uses this library. It was made for one use case by sap for sap and that’s it.
> Add all that to the fact that they don’t even care to support firefox for non-windows users bah
Might not have official support, but personally I've never had problems with Firefox on Mac using UI5.
I currently work on a UI5-app at SAP and even though we don't use odata, I honestly don't find the process of developing it all that unpleasant. I found it really quite easy to onboard (being productive within like 2 weeks), though it may have helped me that I didn't really have much relevant frontend experience beforehand.
Some decently cool stuff is happening behind the scenes though. I believe they're working on getting rid of the jQuery dependency, and typescript support is also coming (though still somewhat in its infancy).
I will agree that it's pretty slow though, and very heavy as frameworks go. You can do a good bit to make it quicker, but it will never win any speed awards in its current form.
SAP targets ERP, and basically nothing else. You will never[1] see SAP HANA used outside of a SAP deployment, even though it is a general purpose in-memory database with some nice features. Similarly, you never see SAP ABAP used outside of a SAP deployment.
Microsoft targets the most generic use-cases possible, even more so than, say, Linux. You can do anything[2] with Windows, SQL Server, ASP.NET, Azure, etc...
[1] For some values of never.
[2] For some values of anything.
It's an interesting observation. SAP has opened up some of their offerings (like OpenUI5) but there's been very little buy-in. Perhaps it's also partly due to the earlier comments from then-SAP CTO Shai Agassi claiming that open source stimulates innovation? Maybe it's because the products aren't great (I'm no fan of UI5).
FWIW, I'm a massive HANA skeptic - I think it's overpriced and SAP betting the farm on it a few years ago wasn't necessarily the best option. It's a product that was put together from various disparate components - TREX, P*TIME (from Transact in Memory), etc - and that shows. It hangs together like something made of brown paper and string, with so many tuneables it puts Oracle to shame.
I have 'one' exception to that. I worked with a medical data analysis company that had implemented SAP HANA as a data warehouse/analysis platform for tons of treatment records.
My current workplace has implemented a custom SAP HANA-based solution for forecasting (code is written in a mixture of Python and R). I wasn't involved in the project but I'm not convinced it couldn't have been architected completely differently - perhaps a suite of microservices running on K8S with a PostgreSQL backend. Having an in-memory database licensed by RAM usage quickly gets mother-f'ing expensive as Nathan Fielder would say.
Suburban Philadelphia has a very large SAP office with a lot of developers. The ones I've spoken to are a normal mix for enterprise places of good and bad developers but they mostly speak positively of it.
2)
Because ERP is immensely complicated, and encompasses features that would be useful for almost anyone coordinating any organization, and ERP systems are really hard to change, so they have acquired a user base with lots of zeroes and a thick moat to keep them in.
Though they have many competitors. A consultant who works on integrating SAP told me once that what gave them a competitive edge is that they let 3rd party consultants integrate SAP while others insist on in house consultants. That means that 3rd party consultant have a clear preference when it is time to advise the client on which system they should pick. That was 20y ago, not sure if it is still the case.
Indeed, to SAP the "partner ecosystem" is a big thing. I think they realised early on that if they were to succeed, their success would be driven by consultants with "business expertise" who were recommending SAP as "best of breed".
Of course, the reality is that many of those consultants who are being charged to customers at eyewatering rates just finished the training course last week and are now "senior".
Don't know if it's still the same, but I suspect it will be - another insidious part of the 3rd party consultant relationship is (was) that customers would hire one of the big 5 to help them evaluate and select ERP systems. And that consultancy would also be in a consortium with one of the suppliers (usually SAP), to do the implementation. Isn't that a conflict of interest you would ask? Oh no, the two parts of the consultancy are behind strict Chinese walls, and the evaluation was strictly independent of the bid team. But surprisingly, the vendor they were in bed with always won the contract.
As a sales rep with Oracle, I declined to bid on a project. I offered the CFO to write the name of the winning consortium in a sealed envelope, that he could open when the selection was announced.
Ah yes, I remember when Lidl tried to integrate SAP in 2015. No one really knows why and after already having spent €500,000,000 in 2016 they pulled the plug and just dropped the project because obviously it wasn't done at that point and they still would have to pay more to finish it. The initial offer never went public but I overheard someone once saying it was like €75,000,000 "only" ... They went back to further develop their own ERP system which is still in use today as far as I know.
The issue there was that Lidl did not adapt to SAP.
They tried to adapt the SAP system to Lidl. Everyone tells you that this is a really bad idea. Everyone.
To be honest, I had so many SAP implementations in my career, and it was most likely not that one. Everybody adapts the software to the real existing business processes. Especially in Germany we are not yet there yet, that tech people can tell business people how to work. I think that Lidl most likely did the upfront design approach instead of building a reliable MVP, and moving forward from that. You have to integrate then a lot more with the old system, but more space to move forward and agile. Funny because it mimics a German military concept of Führen mit Auftrag ("mission type tactics").
You would think so, but all of the large consulting firms (Accenture, Deloitte, etc) are driven by billing and people wanting to climb the corporate ladder. What the customer needs comes a distant second. Many projects are staffed with 90-95% juniors or people who have no industry knowledge.
I've worked alongside consultants from Accenture, Deloitte, IBM, etc over the years and, while many of them are very competent, I would /never/ engage one of those large system integrators (SIs) on any project I was involved in. There are many excellent individuals working for those companies, but the companies themselves are terrible and you will struggle to get any of the excellent people involved during your implementation. The experts will appear during the early stages of the consulting sales cycle but will be nowhere to be seen during the implementation.
Unfortunately this is the dirty little secret of SAP implementations. Many SAP customers think "I'll pay top dollar and get a good SI" but they end up getting the latest round of juniors doing the implementation. Seen it many a time.
fully agree, think what you're saying is a misread of my comment. GP said "literally everyone says this thing is bad." My comment was "Well, clearly there were people not telling them [or else they'd probably have stopped short of $500,000,000 in expenditures]".
Your comment is a mechanistic explanation of the failure mode, which again, I quite agree with. I worked at PwC for a couple of years; quite corrupt incentive structures and quite a dysfunctional organization because of it.
Yes, fair point - I didn't explain myself clearly (I've been commenting too much in this thread as it is!). My thinking is that why would they speak up? Lidl has deep pockets so the thinking was probably "another $5/10/20 million will get the project over the line". Not looking at the project and saying "we've billed you so much already, we've delivered something that's not fit for purpose so we'll absorb some of that and get something that works".
For all its faults, SAP is the market leader ERP. Without knowing anything more than what I've read in the general press, I'm fairly confident that the implementation could have been a success.
Implementing SAP in retail has its own challenges. The large number of products ("articles") sold, locations ("sites"), handling POS data etc.
My first ever SAP implementation was for a large retailer and the project was cancelled (they later implemented SAP ~10 years later after the product matured somewhat) and another project 8 years later was also cancelled. Only two SAP projects I've been involved in that have been cancelled and both were retail (and using IS-Retail, SAP's solution for retail industries).
A guy I interviewed a little while ago observed that SMB SaaS software always tends to become an ERP system on a long enough timeline. It can’t be categorically true but it seemed like a very astute generalization.
Whenever I read about SAP (which I hate, so don't mistake this for an objective take) it reminds me of the discussion about self-hosting your email: "Oh, no, it's too complicated, you are better off paying someone else to do it for you". The problem being, I host my own email and it works fine, which makes me suspicious of the common takes about ERP too.
Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into? You may not be paying with accountant salaries, but you are still paying with yearly contracts you can never get away from and with a horrible user experience for every employee that has to interact with it (oh, P69, how much I hate you).
Some people dream of being a superhero. I dream of being one day big enough to have an SAP salesman come to me so I can tell them "no".
So, full disclosure, I worked 4 years in SAP's LinuxLab (ending 16 years ago). I also hated interacting with their interfaces, but I do understand why they exist:
Comparison with hosting your own email is like a dozen orders of magnitude off in complexity. SAP really only makes sense for ginormous corporations, but up in that range, Oracle's ERP is the only real competition. Just the kernel of SAP is on the order of 100 million lines of code, and that's not counting the even more hundreds of millions of lines of business logic.
It'd be more like saying, "I'm going to reinvent email, write all clients, servers, and try to get everyone to adopt it." Except that would still be a few orders of magnitude off.
SAP has modules that handle regulatory issues in virtually every country in the world. There's so much business complexity that's encoded into its systems that it's literally hard for mere mortals to grasp.
I mean I'm pretty confident that if SAP was rebuilt from scratch today, one could reimplement its core functionality within a tenth or less of that amount of code you mentioned.
But there's literally decades of use cases and experience contained in that code. That's one major issue with people thinking about rewriting software, they vastly underestimate the amount of things in there.
I mean on the surface SAP is just a database with a UI and some business rules - 99% of software is - but that in itself is so often underestimated.
(Source: anecdotal, I underestimated 'just' a configuration interface, except that it had hundreds of models and thousands of fields. In hindsight I should've looked for an off-the-shelf data management thing where all I would have had to do was configure the fields and validation rules and some rough layout. Instead I tried to build it in naive Go, sqlite, a REST API and a React/bootstrap front-end. It's a great solution IMO, but not if you're a solo developer working on a domain that big).
Almost all software could be rewritten to be more concise. But SAP's actually too big to have one architect get an overview of everything and then conceive of an optimal solution. Anything with its level of complexity will have to have evolved to get to that point.
And if you managed to get it down to only 10% of its current size, it'd still be several times larger than the Linux kernel.
SAP makes copious amounts of money, so naturally people have tried to replace it. So far, they have not succeeded.
>> Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into?
It may work using an open source model. However you don't really want to invest into non-core business(es). It takes away money, talent and energy that you would better put into doing what you do best.
I've experienced this first hand developing an invoice system(not my core business). I still use it but if I were to do it again I would develop only the functionality that I was missing in the commercial offering and try an integration. Time spent on the none core business is time wasted.
> However you don't really want to invest into non-core business(es)
The problem is who gets to decide what is "core" to your business?
Look at airlines, once the McKinsey types were let loose it turned out none of the stuff we think is core is needed at an airline; no need for in-house staff, catering, baggage handling, check-in, maintenance or even [owning] any actual aircraft. So much easier to operate without all that stuff to look after!
Taken to the extreme presuambly one would end up with nothing but an airline's name and trademarks, a handful of overpaid management types, and maybe a bunch of lawyers to look after all the outsourcing/subcontracting and licencing deals.
> Time spent on the none core business is time wasted.
Except there are many businesses that have and are doing very nicely precisely because they ignored what would labeled as non-core activity by many. Take Apple for example, where would it be if it had stuck to making Macs? Or more recently spent billions moving to their own chips. What about Amazon?
Truth is more subtle. And with SAP, it's easy to understand both why businesses buy it - and at the same time - why most competent software developers believe if they were given the same investment they could do better.
Apple is a bad example - they make computers, that is their core business. From chips (ok, they don't own any chip fabs, iirc they used to have their own manufacturing but later outsourced to China, but they do design) up to software, plus marketing and distribution (which is always where the money is - eg Nike makes boatloads selling shoes while the sweatshop workers are paid pennies). The iPhone? It's a computer with access to cellular networks. The iPad? It's a computer. Everything Apple has made since OS X in ~2000 is a Unix computer. Even, if I'm not mistaken, watchOS and tvOS are Unix based.
It's like when Mercedes/BMW et al started making SUVs after years of making sedans and coupés. It's a different form factor, but still the same basic product.
As an example of this, I was at a large government department that was in the middle of a mainframe operating system upgrade project. Not the hardware! The applications were also largely staying as-is. Their budget was two billion dollars, which just blew my mind.
I was chatting with a member of the small army of project managers involved, and I was trying to explain to him that for that kind of money I'll build them a whole new mainframe from sand. Silicon, circuitry, operating system, applications, everything.
For two billion dollars you could literally afford to build a dedicated foundry just to stamp out the sheetmetal for the case and still have 1.9 billion left over for everything else.
>Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into?
Because it's a complex legal issue that isn't in the competency of most companies, getting it wrong has consequences. Since most companies have similar legal requirements, there's enough scale for a large 3rd party. Also, some countries require the local IRS-alike to approve your software if you wish to file certain tax reports. Bad UX pales compared to these requirements.
"but why wouldn't you consider that a core part of your business worth investing into"
Yes, that's true, and every organization of any size (one sufficiently large enough to implement SAP) will have experts in those domains. The problem is that implementing them in software is a large task - definitely not impossible, or even extremely difficult (it's just CRUD on a grand scale), but you need software that can change quickly when new legislation is implemented, etc. Painful, and the reason why so many do implement a COTS ERP. Hell, even Google run SAP S/4HANA these days (they migrated off Oracle ERP AFAIK).
ERP industry is so hard(painful) that I wouldnt want to work in it unless they paid top of the top
Good luck competing in that industry
> basic installation of SAP has 20,000 database tables, 3,000 of which are configuration tables. In those tables, there are ~8,000 configuration decisions you need before even getting started.
My little pet theory is that the old "Do as you told" buisness-culture is to blame for germanys inability to produce great software. Software needs developers with agency, who refuse "idiotic" tasks and fight back to improve the product.
Know an israeli who complained about "endless arguing" in israeli software projects, while not recognicing the strength of that.
If its not fought over, all things are developed, all things become meh, teams exaust themselves doing all the things and the product fails, internally unoppossed, but externally years to late, bloated and mediocre to the core.
> My little pet theory is that the old "Do as you told" buisness-culture is to blame for germanys inability to produce great software. Software needs developers with agency, who refuse "idiotic" tasks and fight back to improve the product.
This I have experienced first hand where this junior product manager who wrote some ticket whose requirements when got challenged says "it's mentioned here so you have to do it and you don't have to challenge it". I lost it and I said, "everything needs to be challenged, we are not just going to follow it like a machine". I did apologize to him for my tone. But it bothered me so much.
Its really tough to change that mindset though, once it takes hold, its so deeply ingrained. ("Ober sticht unter").
Basically the whole education system needs to push discussions more, were you have to argue a point, proof you are right and stick to your guns. Something regarding this is going right in some education systems and cultures, and fails utterly in others. Its a education to lead, instead of education to be led.
On the other hand you could argue too many people that stick to their guns are wrong and this too would be a failure of the education system. The scientific method is what we all need to learn and appreciate: form theories, find evidence for but also against that theory to test your thesis. Improve and refine on this basis or drop a disproved thesis.
Complacency, top heavy companies with aged decision makers and the immense difficulties and bureaucracy and risk to personal assets that come with founding a company in Germany are largely to blame.
Software is seen as a necessary evil in Germany, not as the main focus for profit. You can directly see this in most medium to large companies which sell ERP or management software (like Scheer) pay their sales reps a lot more than their developers, even though the latter produce their value.
it's a pretty good field to compete in when the rest of your economy is large or middle scale industry. There's no point for Germany to built "great consumer software tm" in an economy that isn't consumer centric (or so small to largely compete in foreign markets from the beginning).
I worked for a software company in Aachen for a while that supplied software for local manufacturing and this is necessarily "meh" and largely consists of doing as your told and building to specification because that's what industry-adjacent work is like. Doesn't mean it's not good software.
But thats the point. Doing as you are told, often includes reimplementation after remimplementation in germany, not improving upon pre existing software. Not resisting useless usecases, you already know are doomed by experience, but are specified anyway. 5 versions of the same object, collected on a usb and even copied back down (remote) from customer machines.
Exampletime:
A thousand versions of a cylinder valve controller software for a plc floating around a machine builder.
Instead of writting one for each version of statefullness and interfaces to encapsulate the different usecases. (Can be done with TC3) shared by all collagues via Git.
IOpenCloseable {} and that then can be used for example for a drive home routine
DrivePointHome()
{
foreach (IOpenCloseable cylinder in allElementsInHomestateInOpeningOrder)
{
cylinder.open()
wait(cylinder.isOpen())
}
}
And there you have it. Configuration instead of programming. Reusability instead of Recreating. Testability (https://tcunit.org/).
It could all be done. It is done, good, elsewhere on the planet, daily.
In my last career we fought this mentality, to exaustion.
Now im out of it, im just waiting for someone with the mindset to swoop in, disrupt and clean that space out with the effectiveness of good software. There really is no reason to employ half a million electricians to program subpar software when you can have it better for cheap.
We need to look at ERP software in positive light. Fab guy here, there is another beast like this that runs the whole fab. It's made by Applied Materials, called FAB300. It connects to inventory systems, SAP & finance, all the fab tools and process data, automation control through interfaces like SECS/GEM, monitors fab output and wafer starts, material systems and movement of wafers, recipe management, copy exact audits, etc.
ERP/MRP systems are complicated because businesses and factory management is complicated. The fact that we have such pieces of software is a testament that however shitty you think they are, at least we have them. They run real businesses and fabs in prod. They bring revenue and are responsible for running multi-billion dollars of turnover. Whole nation states depend on them. That's kind of amazing.
Idk, I have much respect for SAP and such as I grow older. I feel like if I were to design such a thing with 10k engineers at my disposal, it'd be much worse. It can certainly improve, of course.
Microsoft at one point wanted to become a full featured IT department for companies. From managing their infrastructures, active directory, issuing laptops, but also providing basic erp, kind of salesforce like. I am not sure where they went with that but it certainly an idea that has merit. A small or medium size company should probably outsource its IT department except for the parts that are specific to their business.
ERP are the mother of all vendor lockin for large companies. Not only you need to configure it, but you need to integrate it with the thousands of internal systems.
> but also providing basic erp, kind of salesforce like. I am not sure where they went with that but it certainly an idea that has merit
Microsoft has a suite of ERP software – Microsoft Dynamics. They got it by acquiring a bunch of companies – Great Plains, Navision, Solomon, Axapta. Originally on-premise, now they encourage SaaS but some of it is still available on-premise for those who prefer that. Generally focuses on the small-to-medium enterprise sector, although they've been trying to make inroads on larger enterprises; but large enterprises are still dominated by SAP, Oracle, Salesforce, etc.
I always wondered, why wouldn't an in-house developed lean, ERP system would not trump a behemoth like SAP. A few reasons seem plausible.
- No one gets fired for hiring SAP
- Getting an in-house software developer team that can develop an easily extensible / modifiable ERP system is neigh impossible
It is one of my dream to build an alternative ERP system. But it looks like sub-ERP functions (payroll, HR, etc) have been tackled by many companies and they are wildly successful.
Not just developers, but lawyers, accountants, analysts... I think you grossly underestimate complexity of this thing.
We implemented relatively simple income tax reform a few decade ago in small EU jurisdiction. But law makers were very vague in some important details, and there were about 8 different interpretations. We had to implement, run and support all 8 versions for couple of years, until they decided on final interpretation. Non compliance would be fine of couple of million euro.
And that was tiny country of 5 million people with clean newly written laws. Not babylon with 300 years of baggage like US.
> But it looks like sub-ERP functions (payroll, HR, etc) have been tackled by many companies and they are wildly successful.
That's true but TBH, even those that are wildly successful aren't actually that great. I've implemented Workday as a replacement for the user-facing portions of SAP's HR and while it looks good, it's nowhere near as flexible. There's a lot of stuff I would expect to be available in Workday and just isn't. That surprised me as Workday is pretty much the HR market leader.
TLDR; Opportunities are there for new companies to do ERP better. It's not easy though...
The main reason is a third one: You need to have smart and capable business process owners to work with you the right things to build and what to ignore. Most software projects fail because you're giving inadequate or the wrong scope.
I saw a lot of SF projects budgeted and staffed in roughly the same way as you would SAP.
SF started with CRM and has been expanding to ERP, SAP is the other way around. Both are mainly Cloud/Platform-based offerings today, both feature multi-month certifications, high rates for contractors and lots of effort administering/configuring/customizing.
I expect in a couple of years they either turn out exactly the same or swallow each other.
> I wouldnt want to work in it unless they paid top of the top
Anecdotally I knew a few people in the mid nineties that did SAP work and they were paid multiples of everyone else, literally hundreds of thousands of dollars a year. Since then lots has been outsourced and offshored so its the opposite, but for a few glory years before dotcom boom it was definitely the place to be.
In effect, SAP is like a franchise system for running certain industries.
SAP sells you a software system that includes ready-made workflows and battle-tested instruction manuals. Plus they can synchronize your purchasing and sales departments with everyone else that also uses their software. So if you want to start a small company working with the big car manufacturers, you buy SAP and suddenly you can send quotes in precisely the format that VW expects, because you and VW now both use the SAP specification. In that regard, signing up for SAP is quite similar to signing up to be a Subways location.
SAP plays the long game.
Friend of mine worked in Uganda to introduce a mobile coffee-farmers-(over-lots-in-between-steps)-national-(to-international)-markets app.
the goal was to create some transparency for the producers and to fight coffee-loss (every step taking a bit coffee away and sells it otherwise).
the project was a huge success. With fast adoption and immidiate benefit for the farmers and village collection centers.
the software behind it is SAP! and they do not even charge for it, they sponsor it - together with Deutsche Entwicklungszusammenarbeit.
Why?
Even though Uganda is not yet a profitable market for SAP.
> ERP isn’t cheap. A large multinational company may spend $100 million to $500 million in total on implementation: $30 million in software license fees, $200 million in consulting fees, millions for hardware, and millions more to train managers and employees. A full implementation takes four to six years. A CEO of a large chemical firm was quoted as saying, "competitive advantage in this industry might just come from doing the best and cheapest job at implementing SAP.”
At these kinds of numbers, I've got to ask a genuine question here: what's the benefit of using SAP as opposed to rolling your own solution?
From reading some of the other comments here, it sounds like getting your business to integrate with SAP involves trying to fit a lot of square pegs in round holes and doesn't always succeed in the end anyways.
At these levels of stratospheric costs, it seems like it would often be cheaper and less risky to simply use your standard software stack of choice and build a custom web app over a database that mirrors your existing business processes perfectly, and then transform/integrate those processes over time as needed for increased efficiency.
It's funny I have the exact same instinct / reaction as you do (and I certainly would do that if it were my company I were building). But I think we're probably both naive.
Some thoughts:
* Most companies are not software companies, and most c-level managers are not tech leaders. They treat IT as an annoying expense, like taxes. The idea of hiring software engineers to gather requirements and run a lean process to build efficient software from the ground up on a modern web stack is as foreign to them as setting up a chemical processing pipeline and logistics management network is to me.
* Rolling your own solution takes time, and more importantly, energy and involvement of the whole company. I would argue that it might take less time than a big SAP implementation, but with the latter you can just hire a big consulting firm (there's that cost center again...) and they'll deal with everything for you so your people can just work.
* This is a bit of a chicken and egg thing, but: A lot of SAP's customers aren't startups. If you're hired in the be the CEO of an oil company running major pipelines, you've already got SAP running everywhere. And you do your first big move and acquire a small competitor, and THEY have SAP running too. So why are you going to embark on a huge software development project when a) you're not a software company, b) you're not a startup leader, etc. etc. etc.
Although to be honest, the success (?) the US Government has had doing basically what you propose via the USDC / 18F does give me some hope. But alas, much of the world is too far gone already (sigh).
It's been said before: you don't customize SAP to fit your company, you customize your company to fit SAP.
"We held firm to the NO CUSTOMIZATION rule, we re-engineered our processes to fit SAP. Other than a few hiccups when integrating all aspects of a company that has 100 sub companies, and is under federal, state and local regulation the project basically went off without a hitch." [0]
This is exactly what I was thinking. Spin up a whole new department that focus solely on internal tooling. Have multiple product teams that use strict agile methodologies iterating and releasing quickly. Sure it would be time consuming and expensive but so is Sap! Plus you would have much more control and flexibility over your tools
Former SAP employee here.
The ERP market is ridiculously complex. Legislation, TAX, complex organisational structures and a million things to get wrong.
One of SAPs hidden superpowers in my opinion was and probably still is ABAP and the GUI Builder. The combination of the two enabled consultants to create dynamic internal applications with little effort smoothly integrated into the whole system. So they were doing low-code way before it was a thing in our industry. As you can see the blog authors (retool) try to achieve something similar 40 years later and it is still a challenge.
All of these kinds of systems are the same, from financial systems, like SAP and Oracle, to things engineering systems, like Teamworks and Integrity/Windchill. (I've worked on Oracle and SDRC.) Their size makes them impervious to change, and their complexity leads to ridiculous workflows.
I've made a living writing custom software for engineering, embedded with engineers, that fixes problems with these monstrous systems, and which IT could never implement in 100 years.
So, yes, companies with CIO's who want to make a name for themselves (and probably collect a kickback in the process): PLEASE continue to implement these hundred-million dollar IT systems. You MAKE a lot of extra work in the process, guaranteeing job security for everyone who has to use them, and work around them.
You'd think that Fortune 100 companies would put people into positions like the CIO or CTO who are sharp enough to understand how this REALLY works out, but I guess those kinds of people aren't politically savvy enough to reach that position.
I was a parts department manager in the early 00's when Mercedes USA decided to switch all their systems over to SAP. It was an absolute nightmare for 6 months. The entire UX (at that time) was unfathomable. Even our regional representative couldn't figure out how to use the software when he was trying to train us.
At the end of that year, Mercedes hosted a "we're sorry" conference in San Diego and paid for all parts and service managers across the nation to travel and drink at the open bars for a week. I guess that part was okay.
Curious: does SAP have modules for illegal activities, both dealing with it e.g, official bribes, internal corruption, employee theft, cyber ransoms etc, and for actual illegal stuff like money laundering, or for "off the books accounting", special operations etc.
Not SAP, but ERP developer here. The project I worked on included a logistics module which stock-keeping and accounting.
When you tell a warehouse worker to pick up an iPhone from row A4-143-X and it's not there, you need to figure out why. So yes, doing the accounting for that involved a "status" flag to figure out what happened. If another iPhone is later found in A5-143-X, great.
If not, at the end of the year you do the math how much stock dissappears "for unknown reasons" and you have your number on "possibly employee theft". To balance the books you can't just put an amount and "IDK what happened to it".
> and for actual illegal stuff like money laundering, or for "off the books accounting",
It would be quite hard to write such things for SAP (it's too monolithic, even if you find people to write such things the moment they come for you they would have the access to all your illegal data) , but I knew of people who ran two sets of accounting bases, though that was mostly for tax evasion purposes.
First of all this post is a joke and dont treat it as advise. Tax evasion is illegal.
In Germany, for a long time you could write-off bribes made in foreign countries as a tax expense. It was handled just like any other expense (e.g. telephone cost goes to "telephone costs" account, bribery went to a "bribery costs" account). Also you had to provide some proof that the bribe was actually made. It was ok to cheat foreign countries by bribing their officials or bribe purchasers from other countries to purchase your stuff, but it was illegal to cheat the state of Germany by making a non existant tax expense (for a non existand bribe). After EU was formed this practice became illegal
For the rest of your question, SAP allows you to keep multiple ledgers. One ledger can be official, others unofficial. Those ledgers are conceptually something like "views". Some managers look at different stuff.
For example you can have one ledger ("view") done as per local accounting regulations, another as per US GAAP, another per international accounting standards, another just to calculate local tax.. and yes "local tax ledger" is often different than "local bookkeeping ledger" (mostly different way depreciation is calculated).
Why would you make self incriminating evidence I dont know. Probably you are sarcastic. But usually the cheaters misclassify stuff in their books (e.g. revenue recognition - like Enron), or not show it at all (e.g. financial derivatives). I saw also something made of nothing (inventory movements that increased value).
Employee theft is just generic FI-AA accounting. When you have many employees sooner or later someone will steal something valuable that the company kept on its books (say an expensive laptop). Other thing is if you catch them.
If your company stole something, you can supposedly just recognize it as unusual gain and pay tax on it. I am not a lawyer so I dont know if your corpotation can go to prison ;), but some say that the tax office wont care if you paid the tax on the stolen goods (this is not tax advise). I heard about a construction company that got some tools from other company (that didnt want it back - they were shipped far away) and they just recognized it. Not sure how the other company dealt with it, sounds like criminal negligence. But maybe they didnt write it off from tax point of view. Was just a cost of running business that ate their result, but not a cost that decreases tax.
I heard that corruption is just handled by giving a bonus to the sales person. Then the sales person just cashes it out and uses this cash as a bribe. Of course such practice is illegal in civilized world. Also illegal if your parent company is in civilized world - they will even make you take those obligatory trainings about that.
If you are interested in reading about tax crime then search for articles about samen dividend used multiple times to change tax scandal. What has the very unfortunate name "cum-ex" ( https://en.m.wikipedia.org/wiki/CumEx-Files ). Some argue that the practice was legal in Germany for many years. Some say it wasnt.
Also you can read about money parked in Bermuda, Irish sandwich, treasure islands... many of those big companies seem to do those tricks.
What I do remember is that it seems to be down a lot. I started working in 1997 and about twice a week we would get emails from IT saying "SAP is down" and then a few hours later "SAP is back up"
After a few months of this spam I set up an email filter.
I was on the engineering side. I still don't know what SAP is and I've never needed to learn but it doesn't seem like a great product for how unreliable it seemed to be.
It's your company's central administration, basically.
As for downtime, that's probably not down to SAP itself; it's core business, if it goes down, companies can no longer operate and will lose millions. But, with so many moving parts, there's a lot of things that can and will go wrong if handled uncarefully.
When software becomes popular enough, it begins to have its own gravity, and rather than only being shaped by its users' needs, it starts to shape its users' needs.
Let's say there is some common business task that needs to be done. Maybe it's a legal filing with the local government, or tracking how many people at the company are using a particular piece of software for licensing purposes, or records-keeping for equal opportunity employment questionnaire responses. There are many ways to accomplish each of these goals, but most people will be familiar with the SAP way. The laws on the books will be written by people who have used SAP before, and public comments on the law will be made by people who have used SAP before. Ancillary tools to do niche features that SAP doesn't cover will work best if you've adopted the SAP way.
And so, SAP becomes enshrined into the law and society in a way that's impossible to duplicate. Even if you mimicked SAP's features 1:1, there would still be obscure quirks and bugs that you didn't capture but are nonetheless somehow beneficial to users' workflow, because those quirks and bugs have been imprinted onto the standard business practices in our world.
I've worked as SAP consultant and Developer for around 10 years. Past couple of years Ive moved to Microsoft ERP's and enjoy them better since theres more SMB's using Microsoft products which makes work more variable.
Indeed it is. Even when using other development tools (eg, ABAP in Eclipse or the third-party addons for VS Code), the code is still stored in the database and executed from there by the ABAP VM. There's no such thing as "offline development" with SAP ABAP, although people are working on it...
for anyone wondering, erpnext.com is a good "alternative" and it is very active on github with lots of people working on it each and every day.
they have hosted plans as well as allowing users to selfhost and only pay for "support and customization" for anyone needing which works out pretty well for many....
SAP is well and good but you have good alternatives
I have been pretty impressed with with what erpnext has achieved till date.
Underdog IMHO.
I think that its founder should consider scaling installed base more.
If anyone thinks about going for odoo - which I did for a customer - do yourself a favor and try anything else. Here's why:
The developer experience is terrible, simple template changes need a your modules to be "upgraded" which means every change takes several seconds at least.
The quality of the app ecosystem is so bad you almost can't install any non-core apps if you want to be able to maintain your project. And apps are incredibly expensive (250€ for a GDPR compliant cookie banner).
Most apps have quite few downloads so you don't know if you get what you're paying for.
The documentation is partially non-existing and you're supposed to read odoo's code to know how things works - which is true, but quite time consuming.
If you google technical questions you find odoo forum entries (which could be ok) that often contain just links to youtube videos or simply bad and out-of-date answers.
These issues are just the tip of the iceberg. I honestly wonder how people working on/with odoo deal with this.
Things literally take multiples of the time they should and the whole process is a PITA.
Funny sidenote:
If you google odoo developer experience and try to find what others have to say about this, you get their conferences since they're called "odoo developer experience".
Thanks for the great report! I also encountered it at a client's place but didn't have to dig in too deeply, which I count myself lucky for after reading this :-D
My very first job when I was 16 was helping Canada Post move data from their old VAX mainframe system into SAP. This was over 21 years ago. The answer to the second part of the title question is: because it is now so deeply entrenched in huge corporate infrastructure.
Aaah yes, SAP, also often called Satan's Accounting Package by the people who are forced to use it.
I've had the pleasure(?) of doing some elearning work for some clients that used SAP... I feel sorry for anyone who has to interact with their software on a daily basis.
SAP software is the Jira for non-IT software. A slow corporate mess nobody wants to log in to until your boss complains you haven't fill out the SAP thing, so you sigh and try to accept the fact, go in there and try to get it done before life becomes totally dark and unbearable.
Most are only exposed to SAP software for time allocations, travel arrangements and expense management, but I imagine there's some poor souls in the account department who have to spend a large part of their day suffering it. It's something you probably won't encounter in small companies, but seems inevitable in large companies and organisations at least in Europe.
My biggest frustration as a small business. Each month you need to deep dive in website of every service you use to find your invoice. Big company like Facebook and Google need 20 click to find your invoice. No way to automate this. I dream about a standard or a service that just collect all invoice on your google drive/dropbox.
And yet has solved none of those. I was involved in the big effort to modernize EDI decades ago to use XML, then JSON, then REST-based approaches to simplify and encourage adoption of electronic invoicing, and yet none of it really had any effect. Emailing PDFs it is. Now the best solution is using RPA tools to automatically extract information from emailed PDFs to get them into the system. Yes, it's ERP to PDF and back to ERP using NLP and automation. Such as it is.
I hear You - I took part in many projects where the most important part was OCR for invoices. I have even seen a inner process in some local bank where they were OCR'ing their own documents that were printed first by other part's of this bank.
But here in Poland the government apparently found a solution to this problem - it's called KSeF and it will force all local entities to send invoices as XML through their portal first (there will be no other legal way to invoice, because the KSeF number which is generated by the portal, is required for every legal invoice, without they won't be able to deduct VAT).
Only time will tell if this will bring new era of electronic invoicing or just another failed government project.
Interestingly, the Hebrew word for money is "Kesef". Coincidence? Probably.
As for whether or not it will work, I think as long as Polish companies need to invoice non-Polish companies and vice-versa, trying to standardize in this manner will be challenging.
It could, if it was offered to small customers. Big buyers can insist on EDI. Small ones usually cannot and their systems are not expecting it, because EDI is "Enterprise scale" and not SME-scale.
Do you know of a QuickBooks-scale accounting system that does EDI easily?
As does AWS. Of course, they have to be Certified (TM).
OTOH, the general principle of "just have a giant in memory DB" isn't actually that crazy. In fact, a lot of the complex distributed data storage systems that a lot of services use might just be better off with a system like it. See also: Stack Overflow.
Just wanted to say there are Opensource alternatives to SAP that are used by organizations with large velocity not just in transactions but also in business process changes. For example, Zerodha one of the leading stock brokers in India seems to be using ERPNext. This is just from advertising data, but their CTO is frequently on HN and could probably provide more details.
My father worked for a company that had its own in-house system and migrated to SAP as their CTO made them. Everyone views it as vastly inferior as apparently SAP doesn't do anything out of the box and requires a zillion customs to do anything. At the end of the day you get locked into a very expensive system that has to replicate everything you were doing before.
SAP, Oracle, Salesforce. They all have absolutely awful UX. They dominated their spaces because they bought tons of companies and bolted crap onto their main offering. Then they have the snakiest and most aggressive sales teams. They are just AWFUL and it’s a real shame that no startups have been able to challenge their dominance.
I think the mistake with SAP, as with that other article about a modelling pyramid at Ikea, is assuming that it is possible to create one system to rule them all without it being extremely inefficient and expensive.
It mirrors a dysfunctional business run on command-and-control rather than, like AWS, you have a large set of loosely affiliated teams and although you risk some duplication, it makes for much more agile work.
Imagine you have a supplier who supplies "products" but your system calls them "items", SAP would say that you have to standardise the nomenclature. Agile says, let them call them whatever works for them and lets build small systems with just the interfaces we need.
Sure, the senior management don't get their dashboards but it is still possible to get metrics from disparate systems and form pretty basic cashflow and inventory reports.
This seems like an easy way for money and stuff to start going "missing".
One has to remember that many large companies don't have an in-house set of software engineers to kludge things together, or a set of people to audit and make sure problems aren't accumulating silently somewhere because of some bug or some vendor changing their API or whatever. Even if they did, the supposedly "agile" solution proposed here just sounds rather fragile. You even see this in codebases that are built on a "microservices" mindset -- you start getting weird emergent patterns in internal dependencies that start bogging things down.
For a smaller or even medium-sized business, sure, maybe a custom solution works. But it looks like for the scale of organization SAP works on, it seems difficult for an individual to even understand all the components of that organization, let alone build something maintainable for themselves and their eventual replacements.
I think part of the problem is driven by the desire to create a slick UI and wizards. These systems then underperform. I wonder if you could instead expose more of the underlying computer science stuff to the user. Give them an interface to push transactions. And a set of widgets to pull data. Keep every operation seperate and discrete even when part of a process. And let documentation and training teach the business process.
I used to think this, but then I started interacting with actual end users (normal, non-engineering people). There are 2 main problems with exposing more barebones stuff to non-engineers:
1) Problem solving (thinking about how to compose the raw primitives) takes a lot of creativity. Most normal people only know what end outcome they want, not how to engineer their way there*. The reason wizards are so common is because they address this exact need. Wizards try to figure out what you want to do via a series of questions (and then do it for you) rather than have you come up with how to do it yourself. They are so common because when designed correctly they work very well!
2) Understanding errors is also very hard. Just because something didn't fail doesn't mean it worked correctly. Sure, anyone can file a transaction into a database, but they can just as easily file an incorrect one either by mistake or due to inadequate understanding. The complexity of the systems are their to catch problems before they become problems.
Sure, sometimes there will be corner cases that aren't accounted for by the existing system. And these will be frustrating. But taking away both the end users' guide and also removing their guardrails just so they can maybe solve the problem themselves is not generally a great idea.
*: This is not meant to disparage the normal users, but different people just have different interests and goals. Not everyone should be forced to know exactly how a machine works just to operate it.
My SAP experience in a nutshell (working for two large organization who has deeply entrenched SAP software)
1. It is extremely challenging to integrate with. Your basic option is to overhaul your existing software to at least match the available integration options.
2. It requires constant care. SAP Expert Consultants hired by the companies initially for two years, which was supposed to be the timeline when SAP would have been fully adopted (and turned over), still works as the complexity and evolution of updating the software itself is tantamount to a new system adoption.
3. Users (Majority I would say) hate it. The only reason they live up with it is because someone higher up the decision and authority chain imposed the software after being sold to the premise that it is a game changer to the organization.
Perhaps one problem is the term “ERP” software. Its an opaque and to some degree confusing description. Consider instead that we are simply talking about the business software key to an endeavor.
Many of those systems might be somewhat standard, covering account receivables, payables, inventory, sales, production, planning, supply chains, payroll/hr, relationship management and general accounting. Many may be versions of these customized to a specific industry or business. Others are unique and require a customizable platform to implement a custom system.
SAP offers such software that scales to the worlds largest corporations and organizations. How well it does that is of course contentious. That reflects its market worth.
I work in the SAP industry as a consultant, but I hardly ever work directly with SAP. In fact, I work in a dept. whose primary purpose is to do all the non-SAP work, so 99% of the time I'm working with your typical modern stack(that I get to pick myself, usually), like nodejs/graphql/typescript, etc.
I do however often work adjacent to SAP or have to integrate with it, and since I've been at this for a few years now, I've gotten to try a bunch of their stuff.
SAP's biggest problem is honestly just that they are absolutely terrible engineers, while they suffer from the worst Not Invented Here syndrome I've ever seen. They nearly always want to build their own thing instead of using something that already exists.
Do you want to build web applications that interact with SAP systems? Well, SAP uses OData almost exclusively for all of its backend stuff, and practically no one else uses it. This means all developer tooling, like libraries and such, are almost non-existent. So what do you do? You use SAP's UI5.. which is easily the worst-made UI library out there that anyone has ever built. It's technical debt personified.
No one knows UI5 except people who work in this business, so companies are forced to hire consultancies like mine, because no normal web developer has ever worked with it(nor would they want to look at it in their spare time). I can scarcely begin to imagine how many man-hours SAP has wasted on building out this gigantic turd, or how many hours they could have saved by going with, say, React, and instead building libraries and tooling around that.
This sort of thing permeates everything SAP does. Everything they do is some of the worst stuff I've ever seen.
But hey, it pays great money, and the company I work for has great benefits and lots of freedom. All other things equal, I don't think there are many tech companies out there that could offer me a more rewarding job. But that doesn't change the fact that observing SAP from close-up is like watching an on-going technical trainwreck that never ends.
Agree 100% - NIH is a huge thing with SAP, along with very often picking the wrong horse (Silverlight anyone?). They've also built their new PaaS using Cloud Foundry, which I'm not certain about...
I'm glad that someone else feels the same way I do about OData and UI5. I've used both extensively (initially to learn more about them and then because I need to develop solutions that can be supported by customers) and neither is, well, ideal. The worst is that the SAP ecosystem is a massive echo chamber, filled with fanboys saying how wonderful OData and UI5 are. Really, they're not - UI5 is open source and yet no-one uses it. Why? And let me not get started with CAP (WTF did you give a product the same name as Brewer's theorem?).
There have been some attempts to extract some of the UI5 controls so that they can be used with React/Angular but I can't see those ever being adopted. I've worked with UI5 development teams that struggle with even getting the basics of Git and love using that godawful WebIDE, so I have no hope for customers being dragged away from SAP solutions to anything vaguely "industry standard".
Sorry for the negativitiy, but after 20+ years of SAP paying my bills (and paying them well), I'm even more cynical than ever.
A big part of my recent consulting work for fortune 500 companies is to, in a sense, put a new UI on top of SAP. Not just SAP but several other big IT systems. My team maintains a large data warehouse with web and Tableau reports delivered to hundreds of business users.
I don't know the internals of SAP. I really don't have to. For us, SAP is a collection of OLAP cubes that have a highly curated view of that part of the business that the SAP system manages.
And there's a clean API to this data since SAP supports the XML/A SOAP interface standard to those OLAP cubes. It is a very chatty API to extract the data from the cube - but it gets the job done. It allows us to leverage all of the business logic that goes into the cube schema, and the huge investment that the business makes in SAP. I could instead run extracts of the underlying source data but that would lack all of the business logic that goes into the cube definition. I do occasionally have to use their desktop UI to better understand the cube schemas. It is like a trip down memory lane to use the SAP user interface screens. Harks back to the 90s for sure.
Anyway, if anyone's interested in interfacing with SAP through a relatively clean programmatic interface, I highly recommend using the XML/A soap interface to the cubes. My client company's SAP team does a great job of building cubes that expose what is relevant to the business. The SAP data is merged with lots of other business data in our data warehouse and the business gets a modern web and Tableau reports. Problem solved.
> Data processing – an outdated term whose lasting legacy is
Automatic Data Processing, Inc’s name – is what we’d call IT today.
Ha!
"This International Standard does not specify — the mechanism by which C programs are transformed for use by a data-processing system;" [ISO C, every version]
SAP is successful because they've spent over 50 years learning how businesses work and somewhat successfully implemented reasonably configurable processes within their software. You need to handle MRP? Check. Multi-country payroll with complete integration to finance? Check. Even things as esoteric as downstream oil production (think ARAMCO). Check.
I'm not sure why in the early days they were more succesful than the competitors (JD Edwards, BAAN, etc) - all of the others were doing something similar but SAP overtook them all. Perhaps it was because the system was very flexible - if you needed to enhance the SAP-delivered functionality or build your own to integrated with SAP, they delivered tooling to do so (very crude in the early days, a lot better now).
Related to this is that almost all application souce is available to customers (not open source, but available to view and modify if required). For those who've never worked with SAP, the majority of the application code in their on-premise systems is written in a proprietary COBOL-like 4GL called ABAP. One of SAP's key differentiators in the early years was that customers had access to all of this code and, with the required access, could extend/modify as needed. A masterstroke IMHO.
Source: I've worked as an SAP consultant for 20+ years (including a fair number of those working for SAP) and I'm no fan of any of their products. For the number of extremely intelligent people who work there (and I mean that sincerely - a lot of their employees are /extremely/ smart and forward thinking), the code quality and quality control of their products is abysmal. It's like the majority of the code is written by people who did a training course last week and they /love/ overengineering things, reinventing the wheel or backing the wrong horse. SAP went all in on Silverlight at one point and these days they love OData, which NO-ONE really uses. It also took them years and years to officially support a browser other than IE.
At times they have done some pretty forward-thinking things though. In the late 80s they adopted three-tier before most (R/3, the first three-tier release came out in 1992) and they cleverly have a very portable application. Back in the days of the Unix wars SAP ran on pretty much every OS and all the major databases (heck, Microsoft had to convince them to port to NT and SQL Server, primarily so that Microsoft could run SAP on NT in their own back office).
Rambling a bit here but SAP still pays my bills (and fairly well at that), but I'm no fan and I'm always looking for a way out. Unfortunately, for me the situation is like many SAP customers - once you've checked in, it's hard to leave (apologies to The Eagles).
Most companies stick with a single ERP provider for 20-30 years. And 80% of attempts to swap in one ERP for another fail. Usually after customers waste millions of dollars and years of engineering work.
The underlying complexity of the physical processes managed by ERP is enormous. ERP systems are digital models of a company's physical operations.
Platform lockin and platform innovation are inversely proportional. Companies like SAP in ERP, and Epic in EHR, simply don't have to innovate to make lots of money.
That's one reason why technological change in those industries is so slow.
I remember when the company I worked for, switched to SAP. It was a huge pain, and a lot of folks lost their jobs, or had their duties drastically changed.
In our case, it was, basically a "success." I don't think that our customers saw too much of a change. I have heard nightmare stories of organizations, basically grinding to a halt, for months (I think HP lost about $400M when they switched).
It did result in the company hiring a bunch of programmers. Most were women, and they drove nice cars.
The first business application to be run on LEO was Bakery Valuations, which computed the costs of ingredients used in bread and cakes [and] LEO took over Bakery Valuations calculations completely on 29–30 November 1951
Excellent content strategy by Retool team to write about SAP. Retool is for every organisation who do not think of SAP but get the fast internal tools ready to be deployed.
Former SAP ABAP developer here with 11 years of experience in Retail/FICO/MM/HR/CRM/POSDM.
The software is rather shit esp the old HR and MM stuff ported over from R3 but there is a HUGE ecosystem around it of consultants and consulting companies - nobody is going to get fired for choosing SAP.
It is a huge money hole - take any proposed budget and multiply it by 3.
But heck it transaction flow works and all the modules tie in with each other and the accountants are very happy.
I led the project that replaced SAP at Tesla in 2012 (as an internal IT employee). Explaining that in detail warrants a full article, book, or movie, but in summary the project was successful, took 13 months start to finish, and took a few years off my life.
Prior to that I was an ERP technical consultant. I've had the opportunity to work with many ERP systems at a deep technical level, on both sides of an implementation: the old system a company was moving off of, and the new system I was implementing.
I'm neither an advocate for, nor detractor of, any particular ERP system. Each offering has things it does well, and each has pain points. Unfortunately a lot of people cargo-cult their particular system of choice and lose objectivity. Software is simply a tool and is far less important than the implementation and execution.
A few SAP aspects that stood out to me from a technical perspective:
1. You are virtually guaranteed to have an existing capability available for any arbitrary business process need
2. The system architecture facilitates efficient data processing. Tables, forms, and reports tend to be narrow slices of an overall business process, and thus can reduce contention and concurrency problems. Batch jobs are utilized for background processing.
3. The user interface is lightweight and very performant over remote connections (e.g. VPN). Similar to older green-screen systems, data entry can be very fast for experienced users and does not rely on the mouse.
4. The API options for enterprise application integration are good
A few SAP pain points I observed:
1. The surface area and complexity to match the capability is crushing. Tesla's relatively vanilla SAP environment had 10,000+ reports and T-Codes in it, of which I would guess less than 1% were actively in use.
2. Optimizing the architecture for scalability came at the expense of the user experience. One would often need to perform several tasks in order to answer a single need. For example, I would observe users exporting several reports, each of which provided a narrow slice of the information, and then combine the dumps in Excel to get the answer they sought.
* For ERPs and complex systems in general:*
1. It is very difficult to find subject matter experts who can deeply understand what a complex system offers out of the box, and successfully select the optimal capabilities and implement them for business processes. Or, in the case of true functional gaps, can modify and extend the system without creating a mess.
2. It is vital that a company retains the people who have the institutional history of a system and its modifications. Many end up with a revolving door of consultants, each of whom may be an expert in the vanilla product but has no company-specific context.
3. Clarity and completeness are at odds with one another. As you attempt to drive a system or specification toward completeness, clarity and understandability will diminish.
4. The longer an ERP system has been around, the more likely it will accumulate legacy and historical impediments. If a product aspect is working and widely deployed it tends not to be changed or updated to modern patterns or technology. An example in SAP is the cluster table concept, which as I recall from the lore some years ago was a workaround because SAP needed more columns per table than Oracle allowed. Cluster tables do not spark joy in data migration and egress when ABAP is not a feasible option.
5. Also for long-lived ERP systems, from the user experience standpoint, as these systems incrementally evolve over time the standardization and consistency of behavior across modules and application areas tends to fade or diverge. AS I recall with SAP for example, some transaction forms and reports can export to Excel, while many others do not: the feature was not or could not be added as part of the architectural core but was instead bolted on later to limited areas. A young ERP typically builds this in as standard core feature which is available on all forms in the product.
We are deploying autonomously controlled greenhouses in America and then overseas. We need to decide on our ERP strategy. Would love to consult with you on this. If you’re up for it then please ping me on my email: david [at] optimal.ag.
I should have clarified: the project required careful re-architecting of system interactions and flows to split the responsibilities. The commercial ERP system that I led the implementation of assumed only the responsibilities and functions of the top layer financial modules. The higher-volume operations transaction processing was fully assumed at go-live by the in-house developed ERP system you refer to. Prior to and during this implementation I was a contributing member of the in-house ERP development team but that project was envisioned and led by others. The in-house ERP system has been mentioned previously by others on HN and other sites. I consider it a success and was proud to be part of that team.
I left a number of years ago and I'm certain things have evolved since, but the cost/benefit calculus is similar to any make vs buy decision.
In my opinion the primary benefit of an in-house developed ERP system (or any purpose-built system) is that it does only what it needs to do and nothing else. Thus, some types of accidental complexity are reduced, business user cognitive load can be lower, and performance and scalability can potentially be higher. Also of course there is no application licensing cost and hence user count is constrained only by infrastructure and code quality.
Now the difficult part: you spread the cost and risk of development over one customer, and ERP software is not a simple matter to build: essential complexity inherent in modeling business processes in software remains unchanged. You also have challenges finding subject matter experts as most of the folks who understand the internals of ERP systems are already working for one of the commercial vendors and will scoff at your audacity.
To be successful it requires leadership with vision, commitment, and patience; as well as a team of talented analysts and engineers.
Back in school (probably the year 2000), I did an internship at our local (German) utilities company. They used SAP. Everyone told me how bad it is, how much it sucks, etc. I read comments like here, full of stories of how bad it is and how much worse it makes things.
And yet. They thrive and grow. I always leave with the impression that it really does do things well after all, just not in obvious ways.
SAP, and many competing products from companies such as Oracle, are frameworks and programming languages, although not very good ones, sold to customers as if they were applications. You need just as many people to "customize" (actually 'program') after you convert to SAP, as they needed before, but now they have the illusion of using a standard application.
Oh yeah I remember when they brought SAP in at my old work and no-one knew how to search for parts anymore. They distributed an Excel spreadsheet exported from the old system along with the SAP part number so we could find things.
Absolute joke of a UX/UI. And don't tell me it can't be done better. The dated, out of support one we had prior had a better UI.
There’s a really great novel called Red Plenty by Francis Spufford which is set in the USSR of the 1960s. The protagonists are mathematicians and economists who build a computerized planning system, not so different from SAP, to support of Kruschev’s goal of fully automating planning and manufacturing by 1980. Beautiful prose, too.
The reverse survivorship bias. No happy human user will praise SAP, since most of the time they might not even be aware they are using it. All they know is click this, type that, click this other thing and job done.
My parents won't ever praise Delphi, yet they (probably) still use that piece of software I wrote with Delphi 20+ years ago.
Interestingly, SAP is used by the metal health services/psychology of my local District Health Board. It gets a hilariously bad rap for its usability, but I presume it gets the job done well because they're still using it!
It does, notably, have an integration problem because the rest of the DHB services don't use it.
As an outside company without a relationship with SAP, what's the best way to build integrations with it? What's the path? How do we get access to sandbox environments, and will it cost money? I figured I'd selfishly ask while this is number one on HN and all the SAP gurus are here!
(For those who don’t know Sybase supports an SQL implementation which is seemingly used nowhere except sales and trading for Wall Street banks, who largely adopted it in the 90’s and have been slow to move off. MS SQL Server was originally a port of Sybase.)
I've seen Sybase being used by a product sold to telecom operators. If I understand correctly it's most important feature was doing distributed in memory analytics before stuff like Spark or Presto existed.
Well they do also have a columnar product SybaseIQ that actually has some adoption. But if that was ASE, their SQL server that would be the first I’d heard of in like 15 years.
Back in the 90s Sybase was the only "major" database that SAP didn't support, ostensibly because it didn't support row-level locking, only page-level. Support for SQL Server 6.5 was added in 1993/1994 with the assistance of Microsoft (SQL Server also only supported page-level locking at the time and was still based largely on Sybase). Sybase ASE was only supported by SAP many years later, after they'd bought the company (primarily, I believe for the now-discontinued mobile products).
The problem I have with SAP, as someone who works in a service desk environment, is that it seems universally slow to migrate/replicate to user’s devices once they’ve had it allocated. I don’t know why this is, but it’s a pattern I’ve noticed.
SAP is bizarre. It's like the Objects Anywhere obsession in the late-80s carried on, and here you go.
The rest of the world went one way, and SAP another, and believers are obsessed with it. Despite every other thing they do going an entirely different direction.
SAP is like nicotine. It doesn't give you anything back, you start it because it looks like all of your friends are doing it. It stinks like hell, but you get used to it. And once you become a user, it is fucking hard to leave it.
I reviewed the article, people pay for SAP? And ... "Developers can create their own database tables using the SAP interface." - everything is fine though because users can create their own forms!
(This was 20y ago) None, they wanted to go into knowledge management and we should be key to build this up + social tools, but I didnt want to leave Berlin
/or fly twice a week to SAP HQ which was the requirement.
Just looking through the comments made me almost avoid adding to the hatred of SAP but I don't know ... SAP is special to those of us who have had to deal with it.
I worked at a global multi-national telecom that used an ancient version of the software. You suffered with it. I'm convinced -- because we were always cash strapped (having been through bankruptcy and back) that part of the motivation for keeping it was that it made doing expense reports so difficult that many abandoned them.
SAP looked cool at the time[0]. The web UI had an appearance of a web app and attempted to behave like one. It had many flaws, but they all went unnoticed because of one massive flaw -- it failed to handle the Back button in the browser ... and the UI often put you in a state that "instinct" made you want to click it. When you did click the back button, the web app would see two of you. As this was not an allowed state for a user, the new "you" couldn't access the system until the old "you" timed out ... an hour later. This meant a sufficiently complex expense report could take two days to complete since, on average, hitting the back button (by accident) twice per line wasn't unusual. So if it resulted in less than $40 coming back, it often wasn't worth the effort to do the expense report.
My entire experience with SAP was limited to integration with downstream (simple) internal applications and expense reports. Others spent all day within it. It was bad enough to warrant a special launch page that popped the thing up in a window that lacked the back button[1] but that was a pretty inadequate solution.
The worst part was hiring SAP developers. Having not looked at the product since the mid-00s (and being far from huge-company-land), I don't know if it's still the case, but I suspect so -- SAP was basically a custom setup everywhere it existed. It had the same graphics, similar UI, but requires substantial development to tie everything into it and tie it into everything else. I ended up participating in the interview when the company "got serious" and decided to put some money toward hiring a solid SAP developer/lead to get everything upgraded and solve some of the worst problems we had. We brought on a guy and paid him 25K more than the highest paid developer on staff[2]. He, like the previous four (under-paid) employees, lasted about three months before he left for substantially more money. We tried "paying some third party", too. The problem there was similar -- whomever was contracted to us was either incapable of doing the work or didn't last long enough to get past initial planning.
The end result was SAP existed in our organization at the same version it was when it was setup, initially, until we got rid of it ten years later when we merged with a competitor. The competitor ran Oracle for ERP and had a team of people to manage/develop/maintain it. Personally, I'm not an Oracle fan, but I wanted to buy Larry Ellison a beer.
[0] This was the mid 00s.
[1] This idea, I think, was tried -- IIRC, the more frequent case was accidentally running into the Backspace key on a non-text field and having the browser hot-key back which isn't solved by taking the buttons away.
[2] This was saying a lot considering we had software actively developed in C++ that managed a pretty massive audio-conferencing service (and set of related bridges/hardware). I met with several on that team -- they were geniuses. The "SAP Guy" had to know Java and SAP. I interviewed him. I wasn't impressed.
SAP is a peddler of trash software and obscene contracts to support it. It has been around for decades, making routine business tasks nearly (or sometimes literally) impossible to execute.
Even better is that it's written in some bullshit language that nobody else uses.
SAP is a mystery to me. Customers hate it with the passion of a burning sun. Yet they don't switch. Why? Is what they are doing so hard no competitor has managed to dethrone them? It's the only company I know that is universally hated by their customers.
I have worked in places where they didn't have a real ERP, and things were a mess. Hard to get anything done, hard to understand, a decent amount of time wasted.
Then I worked places with SAP. And if they were lucky and just "did things the SAP way", the result was easy to understand, actually worked, and saved time.
Can you do that without SAP? Of course. Can a SAP system also suck? Of course. I have no argument to make here, other than it's sometimes good and sometimes not. If I had to compare it to anything it'd be IBM.
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.