Imagine this situation:
- You're a F500 pipe manufacturer and a sales person needs to enter an order for 100 pipes to be manufactured and sent to a customer in the US
Now imagine you need to:
- Order your materials from your Brazilian plant
- Procure raw materials from your Chinese plant to be sent to your Brazilian plant
- Ship the raw materials from your Chinese plant to your Brazilian plant
- Ship the 100 pipes from Brazil to the client's plants, 50 to their plant in the Indianapolis and 50 to their plant in Canada
Now imagine from a systems perspective your software needs to:
- Determine import costs for sending raw materials from China to Brazil to the USA
- Integrate with a 3PL to calculate shipping across all 4 sites
- etc. etc.
Oh and your software needs to:
- Be extensible to adapt to any modifications and user exits.
- Have a beautiful interface that anyone from the age of 22-65 can use.
- have full audit capabilities to adhere to local/regional compliance
- have capabilities for reporting and analytics
The real world is messy, especially at scale.
For the record - I started my career as a millennial at SAP and was appalled that most F500 use it. I've learned a lot about the "real world" since then.
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
> The first time I walked into the bakery I couldn’t believe what a mess it was. The sides of the ovens were yellowing, machines were rusting, there was grease everywhere.
> “Is it always this messy?” I asked.
> “What? What are you talking about?” the manager said. “We just finished cleaning. This is the cleanest it’s been in weeks.”
> Oh boy.
> It took me a couple of months of cleaning the bakery every morning before I realized what they meant. In the bakery, clean meant no dough on the machines. Clean meant no fermenting dough in the trash. Clean meant no dough on the floors.
> Clean did not mean the paint on the ovens was nice and white. Painting the ovens was something you did every decade, not every day. Clean did not mean no grease. In fact there were a lot of machines that needed to be greased or oiled regularly and a thin layer of clean oil was usually a sign of a machine that had just been cleaned.
No need for naming conventions that have to be taught to everyone and half of the people keep forgetting. Of course that doesn't take away the responsibility to teach people why there are two types, but even if they don't know and just copy-paste, it's better than someone mislabeling a variable name and thus not making it any easier to track down a bug because of it.
This is key. It's the make or buy decision, which is also the "adapt software to process or process to software decision". Building something custom in order to get rid of SAP is a project that would take years and probably fail because different departments spread across countries won't agree on a way of work.
SAP allows C-level to say "just deal with it" and force people to adapt rather than try and get everyone happy with the software. This is the definition of use hostile, but it's also a way to get things done, in stead of just discussing what to get done.
Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it.
Your PC operating system complexity and the International Network of computers is so complex you cannot figure it all with your brain alone. Yet you write your email everyday with it and your colleague in China get's it in seconds.
Your supply chain is a nightmare so SAP must be a nightmare to use ? Why ?
I feel the failure of extrapolation between Stripe and Banking is exactly the failure of imagination most IT folks have between "single or multi purpose application" and "Enterprise Resource Planning Application".
One of the implementations I've worked on had 128 labour agreements. That's like 128 companies or ways of handling employees, in one. 10's of thousands of time and labour rules. Across 50+ government departments. A smart, focused company like Stripe would not touch that project with a 10,000 foot pole - but it still needs to be done :).
1. Budgetary restrictions
2. Quality of engineering teams
3. Lack of autonomy to make and enforce product functionality (or even UI) decisions
4. Competing stakeholders
5. Inconsistent workflows
The chasm between product development at a "digital native" and how business software is created in captive IT are worlds apart (and my list doesn't even touch the added challenges when it's outsourced IT).
Oh man, where do I start with this one. Calling Stripe banking is like calling a porpoise a fish. Sure they both swim in an ocean, but they are very different types of animals.
Strip only handle a tiny fraction of what banks do.
In this analogy the ERP system is the Stripe plumbing that simplifies it for the endpoints (factory logistics manager, salespersons etc) just like Stripe does for its endpoints (merchants and customers).
You might find that re-implementing Stripe is not so simple because of the nightmares of naturally-grown international payment networks. Similarly, implementing an ERP system over an F500 company's logistics/manufacturing/sales pipeline that grew in a complex nightmarish fashion through M&A and diverse international legal/tax/regulatory frameworks.
I discovered that Lidl spent 500 millions $ for nothing (literally) trying to implement SAP.
Give 500 millions euros to a talented group of Stripe - like engineers and, maybe, you will have something sorted out and maintained for a few decades.
Half a billion dollars....
50 engineers well paid (5000$ net after taxes / month) cost 6 millions a year (France)
With 500 millions your system can be build and maintained for a century.
You need tax lawyers to ensure you're doing that right. You need employment lawyers to ensure your termination process follows the law. You need accounting experts to ensure you're reporting correctly. In every legally distinct market.
How many laws, regulations and reporting requirements does your average chemical plant comply with?
As indicated elsewhere, ERP implementations can go spectacularly badly - and I maintain my claim that treating them as an IT project, which your estimate/equations are doing, is the #1 way of setting them up for failure.
In fact, I would imagine that the key work done at Stripe is not by talented engineers/coders with IT/systems knowledge (not to in any way put them down), but by business/financials/law/banking experts (who ideally would have some or lots of IT knowedge or background so as to not be dangerous). Again, think of our friendly neighbourhood patio11 as a perfect example of technical skills and hard-earned real-world business experience.
So we're already starting at almost double what you planned for and there are much more costs to cover than just staff. Large scale projects are insanely expensive and hard. It's not just mismanagement.
Up until some 5 years back, UX really was afterthought to them. Why? Answer is in how enterprise software was (and largely still) sold. Buying was done by CIO, based on all parameters (account relationship, FOMO, $$$ discounts, functional reliability etc.) except user acceptance.
SAP simply didn't have incentive and KPI to see UX as focus. Users were "trained" to use SAP after rollouts.
With what is fancy termed as "consumerization of IT", SAP has been forced to change. They've been trying their best with Fiori v1, v2, v3 since then. Change takes time to get hold in SAP world, specially given large on-premise installed base, where customers take years to adopt a release upgrade.
So the UI design of SAP is user hostile. Even by embracing modern web components and openUI toolkit SAP will continue to be user hostile design.
SAP will need to change the foundations completely to change it and also re do things. But then it will put them in direct competition with modern software makers who can beat them.
So I am doubtful things will change, SAP will go the path of IBM in times to come.
It's what happens when the users have no choice in the matter, there is no reasonable alternative or competition - therefore no incentive to change or improve.
Whether it's intentionally designed to be user-hostile, I've suspected (and doubted) that myself.. There might be a logical explanation how that's desirable or even profitable, as a kind of moat or gate-keeping.
With its legacy and massive complexity, SAP would require a visionary to re-architect it from the ground up. Unfortunately, that rarely happens in enterprise software.
We can only hope that scrappy startups arise to replace and evolve.
It is certainly not true that SAP does not care about UX (in fact the reason why SAPgui has it's decidedly non-native look is result of some UX research in late 90's), only the UX they care about is not about easy onboarding, but about efficiency of use. And by the way in my opinion SAPgui manages exceptionally well to combine power user features with discoverability (on the UI toolkit level).
This generation has options for creating full custom software faster than one can configure an ERP.
No we can't do that, because the real world is messy. I currently work on a SAP system and the amount of localization and customization that was done for you is inexpensive for big corp. And you know that SAP will last the next 30 years, you don't know that about your Framework of choice.
Those are birth pains as felt from inside. It's a beginning of a new sentient life; your company is acquiring its own mind. You and your coworkers are now just nodes in the network. Individual reports don't make intuitive sense for the same reason a random block of machine code doesn't tell you much about the purpose of a program, or why a random neuron doesn't know what the brain is thinking. You're part of something greater now. You're compute incarnate, the process made flesh. Welcome to the collective. Resistance is futile.
(Honestly though, this applies to many corporations in general; I think SAP is a kind of parasite that thrives off corporate life forms, exploiting popularity as a reproduction vector. After infecting a corporation, SAP keeps it alive and makes it display the signs of infection, which is used to encourage other corporate life forms to get infected themselves.)
Yeah. Kind of like 'Aliens' when one bursts through a chest cavity.
Kind of like the ant colony being sentient but the individual ants not (see Gödel, Escher, Bach).
You and I may not agree with this approach, and the formula is somewhat different for creative industries, but numbers don't lie. It's always a compromise between agility/adaptability and cost when in a production line.
A main function of an ERP system like SAP is to maximise this extraction.
Or a hospital
Or a drug manufacturer
This isn't a problem with a standardized process, this is a problem with leadership not explaining to those doing the work how they fit into the whole and why their actions are important.
"Process driven" does not have to mean rote, mindless, automaton-like action. It should be more about thoughtful action conscious of how those actions have downstream effects rather than intuitive "do what feels right" methods
Nope. Forget about it! :-)
I think another problem with these horrific ERP's is that their tentacles are everywhere in the org.
Oracle EBS, my personal "favorite", runs PLM (product lifecycle management), inventory, order management, work orders, customer install base, finance, purchasing, AND PTO entry, F.M.L. !
We can't have nice things in, say, PLM because the whole damn system is tied up tight as "modules" in Oracle EBS. Any kind of change or request involves, at a minimum, harassing a overworked guy in India who is constantly dealing with battle-axe personalities in finance and order management.
Things that SHOULD be taken for granted, like being able to create a hyperlink to the bill of materials for any part number-- that's seriously impossible, it's like a freaking moon shot for them (or so they say).
It might still be bad but for them it works pretty well after they have learned it. As a counter they think my writing commands in a shell as an incredibly bad interface while I think it is very efficient because I've learned it.
One of pain points I was talking about. I'm not sure how a screen/module is developed in SAP, but there are huge inconsistencies in various interactions I come across. I am inclined to believe that the third party developer of the screen ought to do some wiring to, say enable hyperlinks, or do logical linked screens but somehow the QA is so bad that it's frustrating.
For example, in our company, when I search for a Material code, there is no way / menu / system to automatically list all Purchase Orders, that contain that Material Code, sorted by date / department. I am guessing that the 3rd party developer ought to have built that functionality, but then what would be the point? After so many years in the ERP domain, shouldn't SAP have an automated system to do that?
Input boxes behaving as buttons, tabs either changing behavior of UI components that are clearly drawn as being outside of the tab, or outright behaving as buttons that cause random actions, loads and loads of nested modal dialogs...
SAP is not the only one; ever tried the enterprise software from Oracle? Or the open source ERPs/CRMs? Painful.
But everything has API's these days, so lot of departmental work is done on top. Small budgets so they have small, simple LoB apps made on top which are 'idiot proof'. These apps are very localized though; they cannot translate to other verticals, or even other companies, or even other countries because they are tailored exactly to how that department works.
Each and every one of these systems suck. Sometimes they suck in creative and extraordinary ways. But, one thing you can count on is that there's a real reason that they suck. It turns out that the real world of business is complicated and messy. So, as you say, businesses build their own solution on top of these systems to simplify it for their users while keeping the capabilities of the underlying system intact. Of course, nobody is ever happy with the end result - it's always just the least terrible option.
On a slightly related topic since this may be seen by folks who can benefit from this information.
A lot of "Open Source" systems these days are not what you could honestly call open source. Odoo is the example I'll use, but what I'm about to say applies to a lot more than just Odoo. Most of the organizations behind these solutions are predatory. I've seen features get taken out, hidden, intentionally broken, or have fixes released that are only available in the 'pay us' versions. [0-1]Odoo's accounting functions are one such example.
[0]https://www.odoo.com/forum/help-1/question/is-accounting-fea...
A close second is Vienna Advantage. IIRC the development actually came from former SAP devs who have real-world exposure to the problems ERP is supposed to solve.
I know a few colleagues who enjoy that kind of work, slapping a much better and intuitive UI on top of their own services integrating with SAP, Salesforce and so on.
You improve overall productivity and can show that data comparing how much faster someone using your interface is versus the likes of SAPgui, etc.
ERPNext is not open core like Odoo.
Disclaimer: I am the founder of ERPNext
I think rushabh's point was that the Odoo model is an open source core with closed source paid components, whereas ERPNext is fully GPL'd.
ERPNext monetize via a SaaS model, but you are free to self-host.
One system had three completely different, supposedly equivalent, client UIs. Each was equally undiscoverable, and had its own set of arcane, non-standard and inconsistent UI conventions that was completely different fron the other clients. So even if you knew how to enter a certain record in one client, your knowledge was almost wntirely useless with confronted with one of the other two. I am not even getting started on the server implementation and the myriad of bugs in the system.
Not with SAP but having been a part of a project to modernize the UI an enterprise software solution, it usually isn't worth it. Users don't care about how it looks, they just want to get their jobs done as quickly and efficiently as possible. Any changes to what is displayed on what screen or location of buttons etc. causes a major disruption to the way they work.
You could say the same about Vim.
I suspect there are workflows and shortcuts heavy SAP users have learned over time that make them highly effective, and they are now resistant to change.
It's fine to have an inscrutable, beginner-hostile power tool as an option.
Our product has been so successful, I think, because people on the floor of the factories like using it. Our developers visit the sites, talk to users, and we take everything into account in the design of our UX.
I talk with a lot of our users and their biggest frustration is SAP. It's only available on particular work stations, you have to manually enter your forms from the paper ones (data entry in 2020 is still a job), and the interface is arcane and painful. When it doesn't work nobody knows how to fix it and it can lock down the release of millions of dollars worth of product. You can't get any reporting out of it without IT approval and it can take years and millions of dollars to get anything done with it.
Our stuff is mobile-first, easy to use, and we deployed it in months instead of years. We met resistance from our customers' IT departments who were irate that the factories weren't waiting for their SAP solution to roll out (it had been several years by the time we came into the picture). So, there's a big win there in UX alone.
We do more than UX but it's still such an important part of software.
If your business model is being a gatekeeper who requires expensive training and long adoption periods just for users to do basic shit, and then never switch because they think ALL software is that complicated to learn, then....
What I'm trying to say is, the intricacy is intentional. They thrive on their consultant/contractor money.
No one will make a trillion dollars disrupting them. But they will be disrupted.
See, using an SAP system requires a lot of unnecessary cognitive load, so much to remember, so much to digest. So un-intuitive.
I am sure people would be more productive with a UI that is not complete crap.
But I guess the reason products like SAP survive is because in a corporate environment, people have the "No one was fired for buying IBM" mentality.
If an SAP implementation is thrust upon the organization, then there will not be anyone particular to blame. Just the 3rd party devs perhaps.
This a million times. I don't know if good interfaces can not be built in SAP, or if it's very difficult to do, or if the developers of apps on SAP platform just don't care.
It's a real headache to use and completely confusing.
It's 2020 and one would hope software companies realize the value of a good, clear, effective user interface.