Until you know the internals of SAP ;). They have/had an own programming language (ABAP) which is the worst combination of BASIC and SQL you could imagine. Do not know the status in 2020, 2007 it was still a combination of ABAP and Java.
Interestingly, the source code of SAP is openly readable (once you have their software installed).
SAP is effectively open source, IIRC there were/still are options to install local development stacks for free... but without an army of experienced consultants it's gonna be useless for you and they won't touch a pirated/cloned system with a 10 feet pole.
I consulted for a company once that had made several attempts to migrate from their ERP (as well as having made several acquisitions and mergers over the decades). When I was there the state of things was 3 ERP systems that they had built, and another 2 that they had gained through mergers, all still operating and ERPing between each other. No matter how many enormous multi-year migration projects they started, they never managed to turn a single one of them off.
I used SAP at work to keep track of monthly working hours. The GUI had this... feature that doesn't allow you to resize the form you're working with. And you can scroll vertically, but the first columns are frozen in place. As a result, only 15% of your screen is usable, showing 4 out of the 30 columns you need to fill at a time and requiring constant scrolling.
As a user, I would have been happy to dump it and use anything else. But who am I going to complain to? I'm not the customer, my company was. And it's not like they are going to switch ERPs just because employees hate it (which we all did). Even if they wanted, the cost of switching now would probably be astronomical - not only on migration, but also on training and support.
It's no surprise that SAP is worth that much, seeing as they have the perfect captive audience: the wealthy kind.
I love the SAP UI - yea, its the 90's when UI was far superior than today's whitespace filled, shadow-less buttons, complete lack of skeumorphic elements, magenta gradients and huge typography - See Windows 95 UI: https://twitter.com/tuomassalo/status/978717292023500805
It is dense, extremely clear and consice. I agree with the slowness though.
I feel like there continues to be a huge disconnect between UI designers and their users.
I'm a power user so I am not the best person to ask for UX advice, but I talk to people all the time that just wish they still had the classic Windows 9x UI's and things more or less were "boring".
Reminds me a little bit of a statement about how Taxi drivers can tell you what works architecturally better than an actual architect when it comes to ground floor interaction.
That's because contemporary designers are obsessed with trends, frameworks and aesthetics. When Dieter Rams designed Braun products, he didn't have a UI framework. He deeply thought about interaction and feedback to the user.
Contemporary UI trends bother me except one: websites like drewdevault.com and text.npr.com are refreshing.
That’s the problem with software. There are two categories of software: software that their developers use themselves, and software made for other people. Visual Studio is the prime example of a software made by people who use it, it continuously improves (minus a few hiccups), it is made for the most used functionalities to be at your fingertips, it doesn’t hide stuff in layers of submenus, etc. The list is long of software made for others, and the general rule is “fuck it, good enough”.
This is also why I believe the Windows 8/10 developers must be working on macs.
What language do you write in using Visual Studio?
I use it with C++ and C# and I can't say stress enough how amazing it is to use with C++, compared to the teeth-pulling experience of using xcode for the same tasks (some of which are impossible in xcode, edit-and-continue for example, set next statement).
It might be just me, I use Visual Studio to write C# (not my "first" language) plugins for an older (non C# core) tool.
Sometimes I also use Visual Studio to manage SSIS ETL packages, but I need an older VS version because they are not always backwards compatible - this leaves me with three versions installed on my computer - 2015,2017 and 2019 - each for something else.
To be honest what I don't like is the neverending march of tiled frames for everything - the whole program is one frame, then i have one frame for the code, one frame for the solution explorer, two more frames for error list and output, another one for properties and so on.
A lot of screen space is taken by just blank spaces or dividers.
Another thing that I didn't like was that the 'Comment selection' option is hidden in Edit -> Advanced -> Comment selection. You also have to use two keyboard shortcuts in succession to comment something (Ctrl+K, Ctrl+C) and the uncomment shortcut is different (Ctrl+K, Ctrl+U). All this while Ctrl + / does nothing and could do both at the same time.
I often need the whole VS solution and not just the code when I need to copy paste the project to a different folder or a different machine.
Have you tried moving the frames around a bit? I normally dump all the frames down the bottom particularly for debugging.
The double-keystroke thing is a bit odd yes, and the menu is hidden a bit far away for ease of navigation. Still, it could be worse - it could be a RIBBON!
From my own experience interacting with Microsoft developers, there are more using Macs (with Boot Camp dual boots) then you might expect.
But it's hardly a majority (or even that many at all). If you're developing primarily on the CLR or for one the the many Microsoft sub platforms, the first-party tooling is actually quite good. It's only when you need to do both, or stray from one a bit too much, that things become arduous.
Generally however, the Mac users are almost always essentially Microsoft developers who have to target both Windows and Linux and don't want to deal with managing/maintaining a Linux daily driver. MacOS is "close enough". It's pretty representative of the non-Microsoft developers in similar situations.
And no: the Linux Subsystem isn't enough for them either.
SAP suffers from the same issue as all other universally-malleable systems: at best, they're only as good as the designer allows them to be.
However, just because it resembles 90's UI (which I'm a massive fan of) doesn't mean it follows it philosophically. It regularly breaks its own rules and is deliberately designed to be obscure as possible.
I wasn’t talking about mere resemblance. I’m talking about functionality, density of information, layout, hierarchy of importance exemplified by various aspects of the UI, clarity and intent, feedback and signaling, on and on. The whole thing. The only thing that bothered me about SAP was how clunky it felt, simply because it was slow.
I’ll quote myself: “It is dense, extremely clear and consice.”, yep it’s great to use. I also love JMP statistical software UI and Cinema4D UI. They’re a pleasure to use.
The UI /elements/ of the 90s were fine. That doesn't mean that anyone will necessarily build a good UI using them.
SAP and software designed to offer high levels of customization in general leave the task of building a complete UI to middle managers familiar with business processes. They do not generally have any understanding of UI design and are quite happy to add a 50x50px, non-resizable text box for content that will often span multiple paragraphs.
I don’t know if we are using the latest versions but the UI has many other sins, not the least having buttons in odd places (submit is often at the top), many many screens to get to a place, slow as you say.
I don’t care so much that the UI looks from the 90s. For an internal application, a battleship grey winform is perfectly fine, as long as the workflow is simple, fast and intuitive.
Honestly when I work, I focus on the content. Bloomberg Terminals command based UI is a designer’s nightmare, but you get anywhere you want to go in a few keystrokes, and as far as I can tell, most other users love it too.
I have heard same argument for command line interface in yester years, why switch to Graphical User Interface, when CLI is so much more faster and I love it (and so do my other friends around me).
Attrition (so new employees), interns, fresh campus hires, I guess does not happen in that universe.
No it's not that bad, it has auto-complete, it has search functionalities for both commands and data, and there has been a help button to chat with a bloomberg support person for as long as I have been in this industry.
The Bloomberg terminal does two things which make it much more approachable for beginners than you suggest. Don't know which function you need to do something? Type in what you want (and possibly hit HELP if it doesn't autocomplete for you) and you'll find it 9 times out of 10. The 1 time out of 10 that doesn't work, you start a chat with support and they'll point you in the right direction pretty well immediately.
The one slightly annoying thing is that for a lot of things there are at least 5 different ways to do the same thing/5 different screens with very similar functionality, and everyone seems to use a different one.
But it's also worth saying it's a tool specifically aimed at specialists - it's not going to hold back on giving you a huge number of options over which data you want and how you want it presented, and it's not going to warn you that some data might be incomplete or not the one 'everyone' uses.
Agree with all of this. But the color scheme, screens that distort when resized, US date formats shown to European users, text based graphics, textual commands, etc, would make more than one graphic designer physically sick.
The book Peopleware had a section about this subject.
In one study after another, workers failed
to give much weight to decor in choosing,
for instance, among variously colored panels
and fixtures.
But then:
If you ask specifically about noise, privacy
and table and counter space, though,
[...] matter a lot.
The whole thing about both office space and software is: design matters in the aspects where it gets work done. After that, nobody cares. Your working environment should help you, support you, and then get out of your way.
This corresponds with my personal experience: the win95-ish software design was my peak for daily productivity. Besides, you generally get a main window with grey widgets and colored icons at the sides, and a white working area full of colored items. So the end result isn`t all that boring.
Beautiful visual design is not necessarily correlated with beautiful functional design (i.e. being a joy to use, or - as the parent post put it - simple, fast and intuitive). I think the latter is more important for a lot of software (especially software you use every day in your work) but often sacrificed for the former.
Too many designers, maybe a majority, make "beautiful" software that is a pain to use.
Are forms today better than they used to be? I don't think so. Most "web based" or "web inspired" apps today are slow, unintuitive, and have idiosyncratic behavior.
How often have you had a form that didn't work right because some Javascript request failed and/or it decided your entry wasn't correct? How often did tabbing through fields actually work as you expected?
While your statement is technically correct, it leads to software that just isn't a joy to use. We get used to having bad usability, and we take for granted that forms just don't work 100% and so we take the safe route - for example writing long text in an editor and copy-and-pasting to be sure. Have you never done this?
Having beautiful interfaces is nice, but it should be an afterthought and not a priority. Because it is difficult to optimize everything at the same time, and beauty is lexicographically unimportant compared to efficiency.
In some of the repetitive data entry areas, like forms to enter purchase invoices, it used to have the most productive UI I have ever used. The cursor started in the right box, tabbed to the right places etc. I would swap that screen for my current modern one any day
This is the feedback I've got while working on a customisation project based on a different ERP (red one). Users actually expect your interface to behave in the exactly same way as their ERP does (TABs and keyboard shortcuts included).
TBH SAP is almost required for big corporations as they usually are publicly traded companies, require external audits from BIG4(and these guys know how to get data from standard SAP models, not so much from you self-developed system) and have to report their financials in consistent way.
For example Apple, Microsoft, Amazon and Google all can use SAP internally. But it would be false to state that all their businesses are run on SAP...
Every respectable ERP provides ways to export/access the data in a way that covers all national/international requirements for audits and reporting. This is not SAP-specific.
I didn't say that there are no other factors (like for example that CTO won't be fired when SAP/Oracle implementation fails, but will be 100% fired when ERP_X implementation fails)
I only pointed out that the statistics in parent post can be skewed due to the sample of top 500 corporations which can implement SAP for reasons different to running the business.
I would be interested to know if they are actually using SAP. These companies are so much better at software development and they are swimming in so much money that they could even implement something by themselves.
Why would they? It's none of their core business and SAP already has everything covered. Think of all the legal/financial stuff. The UI is not that important in that field, your domain expert in that area knows how to navigate stuff.
It wasn't Amazon's core competency to offer IaaS/PaaS, before they did.
GCP and AWS are closely playing in SAP's enterprise customer base. There is huge addressable market there. They've innovated better than SAP in technology space, on parts other than business software.
If they can succeed developing their own ERP, better than SAP, they could even redeploy the development teams from being cost center to profit center.
If I am SAP, I see them as strategic long term risk.
Established ERP systems take so long to configure that sometimes, it makes more sense to write your own in-house. Tesla did just that. And in only 4 months.
That's impressive. Of course Apple distributes hardware, so it makes the most sense to me. Microsoft, I suppose, had to distribute Windows boxes at some point, so it makes some sense to me.
But I definitely wonder at which point Google started seeing a need for SAP. As soon as they started selling gadgets? Before then, to generally manage finances?
> These companies are so much better at software development
That's like saying "why doesn't Tiger Woods win Wimbledon? He's so much better at sport than anyone else". There are lots of different types of software development, and lots of different types of software engineers. Corporate IT projects don't succeed or fail on algorithmics - it's a completely different job, where 90% of the difficulty is managing people and politics
I always wonder about the reality of these kinds of statements. The truth ranges from the optimistic version "we're heavily making use of this software" through "we made use of it a few years back, and are now phasing it out" and "we use it for one or two core services, but everything else is run on Y" all the way to "we have a single instance somewhere we forgot to switch off and we still pay for", etc. This is a bit of a special case, but still, the reality is probably somewhat different than the face value.
> "[SAP] customers distribute 78% of the world’s food and 82% of the world’s medical devices"
That sounds wrong, as I am pretty sure the majority of the worlds food is distributed in places that can't afford or need SAP (and is essentially sold black market). I doubt that street markets in India use it for example.
A bit unfair. In fact most of the SAP books unfortunately are a waste of money because 99% of the content just repeats the help on their webpage.
If there is something I would complain about, it is that their help pages are a convoluted mess of years of content with broken links galore, lots of duplicated content between help pages between different versions and an on site search which is just not very good.
So basically you have to Google stuff, then unfortunately come out on the help pages for an edition you do not actually have and then will have trouble finding the corresponding help page for the thing you actually run.
If you're a big enough organisation to need an ERP like SAP, it would cost more to manage your data with spreadsheets than it would cost to just license SAP.
I mean, that's literally how you price enterprise software.
Interesting. Was thinking that some startup could exactly do this, but realized that given how deeply integrated SAP/Oracle is (as mentioned in the article) it's very hard to do.
Basically: Make a really bad product + make it mission critical = a product that people are literally glued to using
Ridiculous to even suggest that the stock management, ordering, billing and delivery tracking for companies like Adidas and their partners worldwide could run on some Excel spreadsheets. Shows stunning disconnect from how much heavy lifting enterprise software like SAP does.
"A 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."
He's conflating SAP (a company) with the ERP system, but reality is a little different. There are 133,000 tables in a system I just checked, and 40,000 are flagged as configuration.
I suspect an awful lot. I worked at a place that did their own ERP software and that had thousands of database tables, many of which were simply enum fields.
The entire system required magic numbers to be put into various columns in different tables, simply to modify the behaviour of the "logic" code as it resolved to a C++ enum once extracted from the database.
It was horrible, and nobody knew how the entire system worked, so there was a vast disconnect between what it actually did (and the hundreds of auto-generated SQL statements it ran, very slow) and what they thought it did.
As expected, this created wildly different expectations of what was possible from the internal "implementation" team versus developers.
Of course, this was interpreted as the developers' fault, and there was a constant stream of new developers that would stay for a year or two, then leave. Toxic.
What the HN crowd might find interesting is that SAP does not support any kind of containerization technology to run their products in, despite the fact that certain components, like the dialog instance or saprouter, are prime candidates for just that. Let's give them a few more decades, they'll get it.
(From randomly perusing their help portal, it seems that there are one or two modern - and quite exotic - software products from SAP that do support Docker and I think also LXC, so it looks like they're slowly moving ahead in this regard. :) )
There are pockets in various parts of the company that are on more modern stacks (building on K8s/part of CNCF), but the old stuff is still the bread + butter, and the first thing anyone thinks of when they hear SAP.
Would someone kindly differentiate between the ERP vs ITSM (IT Service Management) industry in perspective for me? I would in ITSM and often wonder if I would had been better off staying in ERP like SAP?
Secondly, how does ERP fare in terms of complexity between game development vs ERP Software development? I understand the target base is totally different (Gamers vs Enterprise clients)
SAP has a separate product for ITSM: Solution Manager. Everything else is beyond that scope.
What is important to understand is that SAP is standardized way to do business for ALL departments in big corporation. You probably can't be "expert is SAP". You can be expert in SAP treasury system, SAP data warehouse, SAP ITSM, SAP data analysis, SAP call center etc.
I heard that SAP consultants are paid very well and I think it will stay that way. But I guess this thread sums it up perfectly: it is due to the complexity that these implementations bring to organisation and lack of elegant solutions from modern software development world. So in terms of money it is good, but the trade offs are quite big.
Regarding the second question, it is not comparable at all. ERPs are still "standard" software, despite what the article implies. The difficulty is not so much on the software side, but on getting the software actually agree with the business processes and often the fault is less the software, more a convoluted business process which is simply not truly automatable. Then you run against the whole organizational inertia while implementing.
I can only speak from a bit of SAP experience:
So usually, implementing an ERP, at least SAP, first means "customizing" it, that means adapting the thousands of configuration parameters to the organization. This is no programming task, in fact you "just" operate a GUI. The difficulty is more in finding the proper the option.
True development tasks are often very restricted in scope - most often it is just the development of a new report or custom data export (one of the annoying things of SAP ECC always was, that it really really really loves to keep its data to itself. While theoretically everything is open - you can even browse the underlying the database directly from the UI, with appropriate rights, and can also quite comfortable run even DDL statements against it - often you are back to ABAP very soon for any kind of interfacing tasks simply because SAP likes to live in its own world with its own standards for data import/export (Idocs for example or its proprietary RFC interface). Things might have gotten better recently with e.g. the OData support, but I haven't yet worked with a system which had that.
A colleague just switched from a game development company to our gig, which is selling Field Service Management Software which integrates with SAP.
So we talked a bit about the differences and I hope this answers your second question.
1. Constant Updates/Upgrades
Most games are a one time effort with some patches and maybe a add on and if it’s really successful a sequel.
Business Software runs for years in a company and needs to be supported. So the customer needs to sign a service contract besides the initial payment and licenses. Games are usually a one time buy. Exceptions are MMOs. Game companies noticed this mishap and are trending to service games now, which would create a steady inflow of money from loyal customers.
2. Complexity
It depends on what the game company focuses on. If you only build games, you need to master a game engine or build your own. It doesn’t need to be customizable if it stays in your company.
With ERP software you need a lot of configuration switches and cover a lot of similar but not same use cases. A standard product is almost never bought my businesses. They want you to build something for THEIR process.
So what SAP did is maximize on this need and they built so many customizations, that you need special training to even begin to understand one of their modules.
ERP is definitely more complex in the realm of more stuff to learn and to remember to get it right.
In terms of complexity defined as difficult I can’t really tell because of my lack of experience with game development. But I guess mastering a game engine is difficult, but less “complex” than ERP software.
Funny side note: I did a SAP training one and half years ago at their HQ in Walldorf, Germany. And they own pretty much the small town. There were so many foreigners in town to visit SAP. The SAP campus had the same size as the town :)
On your second question - as an enterprise software developer and hobbyist game developer of ~8 years, I'd say they're complex in different ways...
ERP software is mostly a giant CRUD app/database, with APIs, reporting functionality, and a ton of relatively simple code for automating the system/business processes attached to it. These parts taken alone are usually fairly simple, however the complexity really stems from the enormous scale, interfacing elements, moving requirements, and mutability of everything. It’s easy to knock SAP, but it’s difficult to keep software nice when you're dealing with these attributes.
As for game development, I tend to find it more computationally complex, but that can depend on the game and tools you use. By computationally complex, I mean the code itself is generally more complicated. However, what’s easier in game development is the amount of control over things you have. In comparison, you largely dictate how much mutability your game will end up dealing with, the data it will use, and how large the game will be. Players aren’t going to be dictating this. Not to say game development is easy, but it’s easy to make slick software when you have complete control over the nature of things.
So in short, ERP software is complex (and crappy) mostly due to the enormous scale and the complicated nature surrounding the software - whereas games are complex in regards to the nature of software itself.
SAP has enabled/mandated an army of people at my company who manage it and ruthlessly control even read access to it. The software is user-hostile, intentionally obscure, and all requests for slightly customized reports have to go through a multilayered approval process - often up to corporate - where it competes for funding against other survivors. Needing something custom invites constant questions of why the standard process is not enough.
It was sprung essentially overnight with no training and expectations to show immediate positive results with no criticism tolerated. The rollout was preceded by a couple of years of secretive process reworking where the business was modified to the way SAP said it ought to be done. We expand it to "Stop All Progress" because it marked the formal transition from a technology influenced company to an integrator focusing on acquiring tech from others.
> The software is user-hostile, intentionally obscure
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.
It brought the "swim lane" mentality to my outfit. There is a "process is king" mindset where people exist to run some report or the other with a completely impenetrable abbreviation and set of unmarked mandatory fields also with no intuitive signifcance. Grab the next item on the work list, do your thing, and mark it complete. If some project asks what's required on either end or how to move their need forward, that's not your problem. That project has to divert someone to first figure out the unpublished process and then contact everyone in the chain. If you can't run reports yourself, you're at the mercy of others. And the first rule of SAP is that there is no mercy.
> There is a "process is king" mindset where people exist to run some report or the other with a completely impenetrable abbreviation and set of unmarked mandatory fields also with no intuitive signifcance. Grab the next item on the work list, do your thing, and mark it complete.
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.)
Process is king in mature industries where profits are extracted from scale and volume. Anything outside of standard process is expensive. If there is no external entity to bear the cost, then this cost is to be minimised.
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.
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
> It's a real headache to use and completely confusing.
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.
Except vim does not take over your process and data, and is happy to sit there and wait out your tryst with nano, sublime, vs code or frigging notepad.
It's fine to have an inscrutable, beginner-hostile power tool as an option.
Except that instead of getting high powered modal editing actions where editing text behaves like executing code, you're stuck in insert and can only move by arrow keys, one at the time.
> 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.
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.
SAP is designed based on priority of the requirements by people in a company who will never use it but will ask their staff to extract the data and present them in PowerPoint or excel.
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.
While the first thing is in itself bad enough, it becomes just dangerous when these powerpoint higher-ups refuse to, and don't, understand how SAP, and thus an integral part of their business, works. Saw that more than once. Which is also one big reason why the SAP instances I worked with at multiple companies are that bad. Not necessarily bacause of SAP, but because of tech-iliterate old-guard managers trying to work with "computers" and "software".
Not having much experience with SAP (but having dealt with frustrating enterprise software), I know what people mean by user-hostile UI/UX. It's a symptom of a systemic issue commonly seen in corporations, government, public administration, any large institution.
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.
one has to differentiate between SAP the product and SAP as implemented by random big-co. The parts that are user actively confusing and user hostile are usually result of customization done during the implementation (and motivated either by requirement to keep some existing ad-hoc process or by requirement to have some report contain something that is otherwise irrelevant for its contents).
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).
In my previous company, there is a senior worked on SAP for a long period of time. In his point of view, the UI of SAP was nice in 90s, but they are outdated now. And you can’t customise the user interface with what you want. He also thinks we should not put too much effort in learning SAP product as a developer because he thinks ERP is not not for this generation. He suggested We can learn the integration with SAP, but don’t waste most our time to learn the SAP configuration from the top to the bottom, SAP programming etc.
> 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.
I take a very neutral position to this. Enterprise software at the scale SAP is operating (mainly its core ERP) at a Fortune 500 enterprise level. This characteristic (needs at that level) are user-hostile, not the software.
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.
> I've learned a lot about the "real world" since then.
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.
This should be higher up. Everyone here thinks a simple shinny crud app to order materials for a fancy start up would be so much easier. In reality anything that starts like this will need to face this complexity at some point. Turns out the SAP way is a compromise between usability and extensibility that worked for a long time.
While I sympathise with the frustrations expressed by other commenters, especially the ones you are replying to, this kind of illustration of the complexity the system deals with is super valuable and eye-opening to me in the same way the original article was. Thank you for sharing.
> 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.
The provided example is a bit questionable. Sure it "works", but this is a perfect example for using a typed language, so the compiler/transpiler/static analyzer can immediately tell you that type EncodedString can not be implicitly converted to string.
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.
My experience with Oracle's products is similar. At these kinds of scales simple tasks like paying someone or restocking widgets become user hostile because of all the process complexity required to capture all the cases.
I don't buy the "real world is complex deal with it" explanation.
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 ?
You're asking the wrong question, really. SAP is a result of what's built when a software company is started to solve megascale business process automation problems. It is literally impossible to create a great user experience when developing software in or for enterprise IT departments, for a lot of reasons.
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).
Traditional mortgage lending is actually a great example of 'adapt the business to the process'. Whereas you used to have local branch managers approving mortgages who knew their customers, now you have a credit score (and a thousand other metrics) and the job of the people in the branch/on the phone is to help their customers tailor their mortgage applications to meet the computer's requirements. It's literally the reverse of how it used to work.
> Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it.
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.
Please note that I am not saying it is easy ! Far from it. I say it is possible to obtain something friendly that actaully help you get the job done.
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?
The press headlines of how much was spent on an IT system; as well as how much actually went to "coding" portion; in my experience can be sensationalized and wrong by several orders of magnitude.
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.
Even if you're in France working for the worst staffing companies, the lowest bill for a developer is 400 E a day, times 218 working days per year so roughly $100k a year.
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.
> Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify 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.
My understanding was that Stripe only does a very very small, specific portion of what "Banking" does, for a fairly specific subset and type of customers, for clearly defined types of transactions and needs. They were successful specifically because they would take well-defined, well-understood bites of the overall "Banking" problem that could be simplified, even at the cost of excluding the 1% or 0.1% "edge cases". I'm sure people here or Patio11 could correct me :)
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 :).
> It's 2020 and one would hope software companies realize the value of a good, clear, effective user interface.
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.
I have to agree. I've had the massive misfortune to have to implement and test (almost?) every open source ERP/CRM system out there from vTiger, Odoo, SuiteCRM, Yeti, NextERP, Dolibarr, ...and more that I can't recall from the top of my head.
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.
If forced, I'd say Dolibarr is probably the best for 'real' ERP use-cases. I say 'real' because ERP is a buzzword that has been beaten to death to describe things that don't even approach what it's intended to mean.
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.
We actually tested Axelor as well! At the time, their documentation was quite lacking (in English at least) to the point that their installation instructions didn't result in a working system. (We got it working using a windows system and an older version, but weren't able to do so on a Debian?? system with the latest version at the time) I would be very happy to hear that things have improved because Axelor is probably the most 'user-friendly' and 'pretty' system we tested - assuming it's functioning.
At least as a software engineer for such kind of integrations you can take fulfilment by knowing you are helping real people do their job in a less painful way.
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.
Absolutely. I think that it's a necessity for businesses to periodically review their processes and see how 'tool x' fits in, and whether it can fit better. Filling in the gaps or improving workflows can unlock treasure troves of hidden value that are often left unnoticed. Fortunately, I think awareness about what is possible in that department is growing and that we'll see a lot more focus (rather, jobs) on such optimizations over the next 5-10 years.
From my experience, to integrate with SAP may not be that trivial with just calling SAP’s RFC. Companies may need to workaround SAP issues, for example, user license, slow RFC response. And also need to consider the case of error recovery, otherwise you will suffer from data inconsistent. What you end up actually are a set of “micro service” to build on top of SAP
Odoo was the worst experience I ever had. Granted, processes at that company could only be described, on a good day with a lot understatement, as st. But still, it felt like half of it was missing and the other half wasn't working properly. That and that the external developers had no idea how to manage inventories.
I have only been exposed to SAP a long, long while ago, but back then it was leaps and bounds better than the two ERP systems the company had used previously. If you think SAP is a nightmare, these other systems would probably drive you clinically insane.
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.
Absolutely. I am thinking that a reasonably efficient system can be built with that 100 million put in a bank and pay the interest (4%, 4 million), to about 10 - 15 developers and use standard practices and open source systems for a custom erp system.
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.
Neither of these things are directly connected to the SAP relationship with your company. The people feeling the pain from the bad user experience are multiple steps removed, and generally powerless to do anything. When they complain, they get presented with an improve UI versus implement thing that auditors need argument. Normal people are going to pick the latter.
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.
> It's 2020 and one would hope software companies realize the value of a good, clear, effective user interface.
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).
> 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).
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?
If you think, that SAP's UI is inconsistent then you haven't seen the above mentioned EBS ;)
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...
I won't disagree with you when you say they are horrible but there is also a difference between lets say the user interface of something you rarely use and something that is your job. I've never worked in SAP myself but I've seen others do things very quickly in that ugly user interface just because they have learned how to jump around quickly and what fields to fill in.
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 important factor is that folks who use SAP (or other enterprise software) get really good and fast at using it. Any changes to the UI and you have a major revolt on your hands.
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.
This is what we hear from our customers all the time.
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.
HR data is necessarily controlled though, there are pretty stingent controls in law around that. I understand the pain of not being able to report on stuff, but there is probably a sound reason. However, the delivery you describe sounds like a broken organisation tbh
No, this is the SAP business model. If people think that Apple, Sony, or Microsoft try to lock you in to their 'walled garden' then these people have never seen an SAP installation/integration.
It's almost its own industry. There are fleets of consultants charging ~$1000 a day just to install the system. Then, as the OP said, they charge by the hour for customised reports which means that businesses have to choose their report very carefully, and will probably need several more hours consulting when one aspect didn't work quite how they thought.
I would be surprised if the commenter here was someone who didn't already have access to the data. They are being frustrated by consultants who want to keep their billable hours up, and extraneously restricting access under guises such as "this person doesn't have enough training to touch the system," because it keeps them in paid work.
I'm not sure comparing walled gardens is that benefitial here. Most larger firms will either have consultancies on retainer or in-house personnel that can generate these reports anyway.
> They are being frustrated by consultants who want to keep their billable hours up, and extraneously restricting access under guises such as "this person doesn't have enough training to touch the system," because it keeps them in paid work.
I'm not sure why there's quite a few people pointing these aspects out in here. As opposed to the person using that data to keep their own billables up? "this person doesn't have enough training to touch the system," seems like a perfectly valid thing to say given what these systems do and is certainly not unique to SAP. The learning curve might be steep, the documentation looks ancient, the ecosystem might seem unapproachable, but at the end of the day this isn't that different to similarly scaled products from players like AWS or MS for example. They might have more approachable lower tiers and are nicer in quite a few technical aspects but other than that? It's often consultants and "certification or gtfo" as well. It's not like the consultant costs come as a surprise to anybody in these industries. Sure, it's their own little sub industry but you could say the same about these other ecosystems as well, that's not special - it is just how a few of these sub sectors are structured.
The difference between an SAP consultant, even on retainer, saying someone else can't do it because it's "too hard for them", and an employee being on the receiving end of that remark, is that the employee is an investment on the part of the company, the consultant is an expense. One is the equivalent of the programmer obfuscating his code to keep himself in a job, the other is an employee learning something new and becoming more valuable to the business.
I work in infrastructure an automation on the AWS/MS platforms and work with just about every level of their technical capabilities. I don't have any certification. I don't even have a university degree. I can work with the documentation, which is more often than not up to date and worthwhile. Though the curve is often steep, this doesn't mean it is beyond people with a careers worth of experience around the subject.
I have also learned a small amount about the sort of work involved in these custom queries from my friend. For the most part it's no more difficult than basic database administration; i.e. it's a query language, akin to SQL. It's difficult enough that I can see why someone would want training in it before touching a production DB. But from what I hear these consultants often work straight on Live and then rack up more billable hours fixing the mistakes they made with the customers' live data.
All of this is anecdotal, but the business model (essential monopoly) makes me squirm at the best of times.
Reminds me. I once wanted / needed a KPI to monitor consignment stocks. So I needed agregated inventroy numbers fo the past. Quite a simple calculation, SAP has stock movements and the current stock. So just plus / minus, right? The external devs wanted 70k € back in 2011/12 to put that into SAPs Business Warehouse. Not being able to programm ABAP myself, I went to my manager. He came up with a report, in the prodcution system, after 2 hours, half of it during his lunch brake.
It exactly feels like you are telling the story of my previous company. Although they started using SAP because company was going public and it E&Y advised company to implement SAP. Implementation was never successful. Day to day productivity greatly suffered. You had to do things SAP way, regardless of it being right or wrong. There were training sessions every weekend. Even trainers were confused. Everyone was mad.
Soon after our company went public, we gave up on SAP and started doing things old ways.
my friend works ata company that is an sap partner and they are required to use some sap software (i think some helpdesk component) and they use some external software and import stuff into sap later. afaik the reason is partly how bad it is and how the licensing does not make sense.
When my organization (20k+ employees) started its process to migrate many systems to SAP, this project filled a seven-story building. Cost: 2 billion NOK, so far.
The last paragraph is the core issue, IMHO. SAP, while as software is cumbersome, user hostile and the opposite of intuitive, has some really great standard processes. Stick to them and SAP as an ERP system will run, almost, like a charm . When your company has the scale to benefit from it. And sticks to 90% of the standard processes.
Try to implement it without the necessary scale of operations, with sticking to standards and without training at your own peril.
That being said, without any production going on I would never even consider SAP. When don't have any use for their MRP-functions, forming the very core of SAP, you are better of with different solutions. And their licensing schemes are just aweful, not to even to talking about pricing yet...
What would you say is the right scale for something like SAP? We are only at a few million right bald and around 250 people and are starting to think about it.
I would not recommend it at that scale. You’ll grind your sales people down for no good reason, and flush several million dollars down the toilet on a project that will most likely get canceled and several people fired (gotta have fall guys at that level...). The right time to implement an ERP is at the last possible second that you are legally or contractually obligated to, or a make or break $50-100M sales contract is in play. And in the latter case, losing the contract and flushing the SAP project down the toilet are real risks. I’ve lived this project at a company the size you describe and it ended very poorly.
As the other comment stated, I would say you're not there yet, sclae-wise. Hard to tell without further details, so. If you decide to the SAP-route in the future I would advise the following (no complete list by far, so):
- Stick to the standard, the smaller you are the less customization you do. ususally I'd say 90% standard, if you're small aim for 100%. makes it faster and easier to implement. And cheaper, because you need less external resources.
- Wait. SAP is deprecating SAP APO by 2023 (IIRC, something like that). So implementing before that could be a problem. Either you end with a legacy system and have your first release change right after, or during, implementation. And release changes are unique kind of hell themselves. or you end up with a new system that is yet untested. I wouldn't want either of that.
- Try to model your business already now along SAP-processes. First, these processes aren't that bad. especailly for the back office side of things as other pointed out already. Plus, it makes and future SAP implementation a lot easier. Same should be true for other ERP-systems, but I have not that much experience with those. Aside Odoo, which I wouldn't touch with a ten feet pole ever again in my life.
- get external consultants. Really, get them. get the good ones. A lot of hours. At least one for every module of SAP you want to implement. And have one of your own devs sitt on the consultants lap during the project. One per consultant. It's expensive, sure. But less expensive than an aborted SAP-project.
- Invest hours, days, weeks and months in user training. From day one, ideally as soon as you have a test envioronment. Start with key-users, experienced, smart peolple open for change. And work from ther to every singel user of the system. You need their buy in, without even the best SAP-project will fail. These people are alos the backbone for the future, trea them well and listen to them.
In case you want to hear more of my rambling, just shoot me a mail, adress is in my profile.
Definitely some truth to this buf, also a bit different for highly specialized software which people are using to do the same things consistently. Almost like looking at an airplane cockpit and thinking it's too complicated.
On prem software is notoriously hard to keep modern. Every customization makes upgrades that much harder. SAP’s approach is “We know best.” Oracle is even worse. At least with SAP if they say the App does something, they aren’t lying.
All big ERP Software is like this.
SAP is not unique in this regard, it is just everywhere in this market segment.
Studies show that ERP user dissatisfaction grows exponentially with project / company size for all systems / implementation partners.
As an employer, it felt equally as hostile. Every process was riddled with more process. Approvals were miles deep. Getting appropriate hardware and software that wasn't on The List was nearly impossible. Good times were had by all.
How industry dependent is this? Is this an artifact of the needs of a particular industry (aerospace, automotive) that has a lot of process to cover supplier quality concerns?
I've been in the ISP, MSP, Fed'Gov, and Manufacturing sectors in one way or another, and dealt with SAP in most/all of them. Some were worse than others about this, but it was a universal problem.
"CYA is SOP", hence millions of layers of approvals, QA, and change controls. Feddy'Gov was actually the fastest moving, in my experience, but they also didn't have to worry about manufacturing defects or breaking BGP nationwide.
There have been several high-profile cases of German companies migrating to SAP (from their home-grown zoo of different software for different purposes) that have gone spectacularly wrong. They are way over budget, way over time, and sometimes abandoned completely, like with Lidl: https://www.consultancy.uk/news/18243/lidl-cancels-sap-intro...
I have heard (anecdotally, and third-hand) that the only way to successfully introduce SAP (or Oracle, for that matter) is to completely succumb to it and restructure your business along the lines that SAP assumes as default.
You try to keep your little company-specific process for buying christmas gifts to employees? Fine, but it'll cost you several hours with an SAP consultant. You try to keep your non-standard terms with one supplier? Fine, another bag of money.
You do that more than just a very few times? Your migration has failed.
The best advice about SAP I've had is that when a company is starting to use SAP, the company must adjust its processes to match the SAP model - not the other way around.
If you do it the other way, you'll first spend millions and millions customising SAP and then your project will fail at some point. It will also make all SAP upgrades completely impossible and they will cost millions and millions.
All of the successful SAP stories have been about companies who either match the SAP model already or reconfigure themselves to match it.
While I share your general notion that companies better adjust to the process of SAP, I still want to comment on the "impossible to upgrade" part, as that is simply not true.
First off, in SAP speech, "customization" is the act of simply adjusting the vast configuration options. This does not affect your upgrade possibilities at all. Even if you go so far as to add custom programming, as long as you (lowest complexity) just have programmed additional "transactions"/reports, you will usually not run into a problem.
The system also provides various mechanisms to extend standard transactions via hooks or to extend standard tables and still be able to upgrade without additional effort. I was actually astonished how much customization SAP allows in that regard while still staying compatible to the standard codebase - probably one of the reasons everything is so damn resource hungry, because there are multiple layers of indirection at work to allow this. From a development point of view, the major annoyance here is there are so many different options to extend stuff from different decades, so for some use cases you will use BADIs (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...), for others "exits" (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...) and it is all a pain to lookup and locate.
The one thing which will get you into trouble is if you manually patch standard programs - which you are able to, the whole business logic comes with sourcecode - and which is usually not necessary.
That "customization" definition is not quite right. Configuration is not typically called customization. A lot of companies use "Z" programs (a prefix indicating something is custom) to front-end or augment existing SAP functionality. Companies may also create user-exits in SAP programs, or additional code to run when something happens ("send xx an email when the first sales order for a customer is created", for example).
When they upgrade, these additional programs require regression testing. Those programs make upgrades risky, and those programs may need to be rebuilt. Historically, companies built a ton of these customizations, then had issues during upgrades. The most recent model (since S4 and HANA emerged) is to do as much as possible in configuration, and limit customization.
Configuration IS typically called customization in SAP. "The Customizing" is SAP speech for the sum of all configuration settings and it IS DEFINED THAT WAY IN THE OFFICIAL DOCUMENTATION, even in the english version (the difference is more blatant in the german version, as "customizen" and "customizing" are not german words, but still used in the german docs to specifically refer to the configuration section of SAP)
Let me quote:
"The term Customizing refers to the process of system configuration during which the members of the project teams make the required system settings. In the SAP System, Customizing activities are performed through the Implementation Guide (IMG)."
And no, this leaves no room for interpretation. The IMG is basically the centralized config setting catalogue of SAP and does not allow programming.
It may not be, what is typically meant with customization or with other systems, but in SAP "customization" refers by definition to anything which can be configured WITHOUT programming.
All documents clearly differentiate between "customizing" = using the configuration, "extending/programming/development" which would be Z-reports etc., "enhancement" with user exits, BADIs and the like and "modifying", which would be patching the standard programs.
And yes, of course upgrades still require testing. But saying it is "impossible" to upgrade just because you have z-reports and the like is plain wrong. Most of the time, especially if we do not speak about a full blown ECC to S4 migration, which involves large scale changes to the underlying database structure of the ERP unlike upgrades within the ECC line itself, you will not require updates to your z reports at all.
I work for a competing ERP software house and this is the first bit of advice i give after introducing myself.
Customising an ERP can be interesting, keeping it supported and updateable 5/10 years after the guy who wrote the mods retired is a nightmare i've seen one too many times before.
>Unlike many of their competitors, Lidl bases its inventory management system on purchase prices. The standard SAP for Retail software uses retail prices. Lidl didn’t want to change, so the software had to be adapted.
It is very possible but then that system is not for you. These systems are incredibly complex already and while there will always be some customization you should question yourself if this is where your competitive advantage is?
Is Lidl earning more money than their competitors because they base their inventory management system on purchase prices while others do not? Then build/buy a system that handles that and it could very well be worth it if you look at the business case
But if it is like that because that is how we started out and we cannot quantify how much better it is...then maybe you should just change your process.
I believe, that the difference between purchase price and retail price is a major and tricky one, if you set for retail, but if you can't solve it for 500 million, then there is something wrong with your software.
Also
"Critics inside Lidl say that KPS was too slow. But Matthias Nollenberger, a senior manager at KPS who was responsible for overseeing the eLWIS project, says his company was working too short deadlines compared to other similar projects"
I belive when you have the choice between aborting 500 million and increasing some deadlines, I doubt they were the problem. It simply was not possible to adobt SAP with reasonable amount of money. And the consulting company or SAP should have said that at some point clearly.
Years ago I was involved in a project to scrape certain info out of a SAP system with a web interface. It would have been easier to do it with a API but my conversations with the SAP people at work were going nowhere (is it me or do SAP IT people have no concept of how things are done outside the world of SAP ?).
Anyway I started looking through the Javascript the browser automatically downloads and found there was 10s of MBs of un optimised code only a tiny percentage of which was being used. It was horrific and it was easy to understand why the system was so mind blowingly slow.
We figured out how to get at least some reports to export into Excel. Some others implemented MS Access dbs to postprocess exported SAP data. Browser tricks were also part of the mix. Then the directives came down that working outside of SAP was not acceptable and amounted to criticizing SAP.
I think SAP views APIs as a threat. That COBOL-like ABAP language is part of their lock in.
> I think SAP views APIs as a threat. That COBOL-like ABAP language is part of their lock in.
This bit is changing now.
They're still not there, but internal engineering teams are slowly getting it.
There are high priority API first development projects underway.
While I get that sentiment I don't really see the ecosystem much worse than vendor lockin at any of the modern PaaS providers from a tech perspective. They always allowed integrators relatively extensive API access to their table model, last time I had to integrate that years ago the only hurdle was a bit of interfacing between the report / ABAP world and exposing it as a web service. Even management / security facilities were, albeit usually clunky, what you expect from a modern ecosystem. These days they seem to offer relatively modern and off the shelf APIs for quite a few of these tasks, especially for their cloud based offerings. I'm not sure that they see it as a threat, rather they want to be the single point of truth and lots of projects (completely separated from any tech aspect) would circumvent that.
Now was that a pain? Yes, sure. Especially the whole legal/certification/consultant crap you need to buy into alongside the software. But honestly, at least here in Germany, SAP ABAP/Java developers and consultants are easy to come by. Most of the problems I've seen in SAP related integrations are process related, not as much tech. If you're dealing with a customer that's already up and running in that ecosystem chances are that they already know their pain points, it's not really any different than any other large B2B integration in the space.
Working outside SAP for things you are using SAP is one of the worst ideas, ever. You create data redundancy, jeopardize compliance, erode user trust and make migration and even simple changes near impossible. So yes, forbidding that is a good idea. One I enforced more than once. Well, at least I tried. Might even have worked once or twice.
Reasons why people started working outside of SAP:
- because they didn't know the system well enough and didn't receive proper training. Sometimes also out of pure spite.
- sometimes because SAP didn't have that functionality yet. Ship planning for example was an issue in the early 2000s IIRC
- because people wanted and had to use a SAP-standard process, but couldn't because somepone else ripped that standard appart to do something differetn. Either because the original standard for that was itself ripped appart by someone else. Or because people refuse to follow the standard out of reasons. Misusing standards is beast in SAP. Once you start with a single process, that spirals out of control and cannot be stopped. Part of the reason a lot SAP implementations just suck. Not purelySAPs fault so.
> because they didn't know the system well enough and didn't receive proper training
A lot of the interactions that simple employees have with SAP shouldn't require training though.
I shouldn't have to get a training to be able to fill a small list of hours, and it shouldn't take me 30 minutes to do so. I shouldn't have to get a training to be able to read a received request and validate it.
> is it me or do SAP IT people have no concept of how things are done outside the world of SAP ?
SAP has strong NIH syndrome. They could get away with it due to their dominance.
So these guys are in echo chamber of own. It reflects and explains the observation you have here.
> 10s of MBs of un optimised code only a tiny percentage of which was being used
frameworks!
they try to scale development with frameworks, and end up in dilbert-esque side effects like these.
There are/were 5 different Web technologies over the years you could use to make Web apps for SAP. There are also standard WebService (XML SOAP) and REST interfaces over HTTP. There are also SAP native interfaces for specifically transferring data.
There are ways to do stuff in SAP, lots of implementation problems arise from the fact that people don't know how to do it right, and just try to apply whatever they do know. There is documentation and there are books.
The problem with SAP APIs and services is that each user that uses the system is billed individually. When you try to build an app that helps one department you have to pay for each of the user accounts despite the fact they just use your app, not all the other stuff. On top, there are no real pricing schemes to know what is coming at you. Either 100$ per user per month or 5000$. Depends. The cloud solution doesn't make that easier.
I think the logic is that the Web API's are for apps doing things you would otherwise do in SAP's own GUI.
But i agree, SAP is not for those who are sensitive to license prices. Most commonly the solution is a third-party custom built software, that interfaces the data into the back-end SAP system.
The OP's comment was about scraping data from pages generated from SAP Web apps. I tried to point out that it make little sense, as there are proper ways of interfacing data (even over HTTP).
We did that, with one technical user to share data between our backend and SAP, but got the news that it's not legal and must be licensed per user that's using our app. Even over http you can't access data in SAP without paying your fees accordingly.
It is legal to do that. Its the question how tight your app was doing it? If you just send user actions and answers over HTTP back and forth using a technical user, that's like sharing the user. But if you have your own billing software (for example), and submit finished bills with a SOAP request (for example) to SAP, that is completely ok.
ehh if you have access throught http(hopefullly)s into a webbrowser and consume it with your eyes, can't i just puppeteer it ? heck event print screen and OCR ?
A best case scenario looks like Cisco’s ERP implementation, which took them 9 months and $15 million. In comparison, Dow Chemical’s implementation, for example, took $1 billion and 8 years;
At the last SAP site I worked at the general feeling was implementing SAP had left the company weak. This lead to them being taken over by one of their competitors.
I used to work in a research project where I went to some UX conferences in Germany (not really my field). The big irony/running gag is that SAP seems pretty good in UX-research, Hasso Plattner Institute is fairly recognized for their UX work and yet SAP-UX is a nightmare.
The HPI is a faculty of the public University of Potsdam, it is not a research unit of SAP or anything similar. They have projects with Oracle just as they do with SAP and a ton of other companies.
Also, HN is a hacker crowd with a particular axe to grind re: UI, since all the cool new UI shit makes insta-billionaires, or at least thats the dream.
Whereas with a SAP-using business, the computer isn't the product - the products that the computer allows the company to manufacture/distribute are the only thing that matters - and the SAP UI is intentionally set up by bean-counters.
Once you go SAP, like get into the SAP Zone, you can be quite productive - but like another poster said, SAP is like vim.
ABAP developer ... after looking at some of the code it is amazing that it actually works.
I recently did something called a BDC since the API call did not work so you resort to stuffing values into some internal tables and replaying keystrokes to enter the data into the system.
People complaining about how user-unfriendly SAP is or how companies adapt to SAP instead of the other way around are missing the point of SAP.
The point of SAP is that the module for your type of business is being implemented at the market leader in your area, because they are the only ones who can afford it. SAP will come to the market leader and put their processes into software.
Then everybody else adapts to SAP not because adapting SAP is impossible but because SAP implements the processes that made the market leader successful (at least that's the idea).
So it is very intentional that you adapt to SAP and not the other way around. You do it to emulate the market leader.
And the user friendliness is also on purpose. If you go visit a company using SAP, you will find that you have a certain job in the company and it needs two or three things from SAP. Jobs are very specialized, so SAP is, too. Nobody is supposed to just wing it with SAP. You are supposed to learn how to do your transaction with SAP, and that transaction is then meant to be super efficient.
If you actually go visit a somebody from an enterprise environment interact with SAP, you will be astounded how quickly they can do what they are supposed to do. It's almost as if the software was optimized for frictionless efficiency.
Also note that user friendliness is a subjective and mysterious area. If you go look at an airplane cockpit, where actual research was done into how to optimize user interfaces so that the pilot will not be confused under stress, you will see that there is a separate button for everything. There is no "shift key", no different modes. If you need to use it, there is a button for it. To someone who has not learned how to use that UI, it appears alien and unfriendly. But the the trained pilot it is the pinnacle of perfection.
It seems super strange to adopt the market leader’s processes. You’d think the spirit should be that you can outdo/outcompete then instead of adopting what they’re doing...
The key is to figure out what to copy and what to innovate. This is usually captured by the idea of "core competency": figure out what your company's unique competency is, innovate in that area, and avoid trying to innovate in other areas in order to save time.
This is like assuming that Microsoft or Google is successful because of the version control software they use, rather than because of the actual software they wrote. It may be a useful hint about good practices, but it's quite possible that it's not the best solution for you and it is certainly not THE way to be successful.
The other way to look at it is that if you truly believe your strength is your product (the software you write), you might as well not risk in other areas where you could either make a right or a wrong decision, and just standardize on every other process so you're on a level playing field. This way you lose the chance of innovating on how to do payroll more efficiently, but you focus your innovation efforts on your product (your software).
You mean like stack rating, the microservices crazy, massively parallel cluster for dealing with 1GB of data, letting an army of very competent developers to unproductive companies because all you care about is brain teasers, creating user-hostile interfaces because of "design", and other things like that?
Actually yes. I saw numerous teams adopting monorepos, k8s, microservices and other buzzwords, and either suffering infinitely or putting enormous effort into dragging those to the point of sheer mediocrity. Because they are not Google and will never be.
Corporations running at the scale where SAP operates are so huge that basically nobody fully understands them or really know what they're doing (but they're also big and entrenched enough that they don't need to - inertia, institutional memory, brand awareness and existing product-market fit will do the job as long as the market doesn't radically shift from under their feet, cf. disruption). Seen through that lens it's no surprise that cargo culting is so widespread, or that huge businesses like SAP, Oracle and McKinsey can make massive profits off of essentially giving upper management in big corporations the reassurance that 'they are doing what everyone else is doing' so hopefully the good times will keep rolling.
Competitors cannot outsmart the leader in every facet of business. They creatively optimize some processes, but for the rest of the business their choices are wing it or purchase the Commercial Software solution.
Even a bleeding-edge company will hit an obstacle they cannot improvise through (like in QA or Compliance). That's when enterprise software creeps into an otherwise lean operation.
You say this, but I can think of two large market leading electronics corporations who are using a big pile of excel spreadsheets to bridge gaps in SAP, as the regulatory environment is moving faster than their development cycle.
I integrate into SAP for manufacturing and the users can certainly do every transaction they need to do to account for cost and shipping product and keep finance / supply chain happy.
But yes, to actually plan and run their manufacturing area, that's where the software I write comes in... as well as a ton of spreadsheets :)
As lng as the data in these spreadsheets goes back into SAP. If it doesnt' you can kill SAPs MRP. I saw that happen. Which is then kind of hell's hell. And then the spreadsheet-users complain about SAP.
Yeah - one of the outfits I mentioned had a bit of a catastrophe due to this - BOMs in SAP and XLS were different, they made a medical product (for children) that exceeded RoHS and REACH lead and mercury thresholds. They made millions of units before the mistake was realised. Oops.
You see SAP SMM effect in action – they trick IT guys into vocalizing their mantra in this exact form, since they know who their real threat is. SAP+IBM is a most powerful combo. The total price is so astronomical that IT guys who know how to manage it can have stellar salaries and still look like small happy asteroids floating around this SMBH.
I once worked for a company that uses SAP for several important business processes. The software provides great support for well defined areas like payroll, benefits, accounting and so on. It does not work well for things that are unique about the business (i.e. how it sells to- or services customers). For those things custom built software is usually a better choice.
"If you go look at an airplane cockpit, where actual research was done into how to optimize user interfaces so that the pilot will not be confused under stress, you will see that there is a separate button for everything. There is no "shift key", no different modes. If you need to use it, there is a button for it. To someone who has not learned how to use that UI, it appears alien and unfriendly. But the the trained pilot it is the pinnacle of perfection. "
My design professor used cockpits as a example of bad UI. Grown over the years and understood only by repetive drill and not at all intuitive.
So there might have been research to better it, but I doubt there was a major redesign, or was there?
> Nobody is supposed to just wing it with SAP. You are supposed to learn how to do your transaction with SAP, and that transaction is then meant to be super efficient.
But many employees have to interact with SAP only from time to time. They're not supposed to be specialists at it, just get one action done from time to time.
Everyone in my company has to enter their hours in SAP monthly. The interface is terrible; is everyone supposed to learn how to enter a few numbers in a table once a month?
Or say there's a process I need to approve. I just need to read the attached PDF, and click I'm ok with it, maybe a couple of times a month. Where is the benefit of making me learn a complete new and arcane way of validating a task?
> People complaining about how user-unfriendly SAP is or how companies adapt to SAP instead of the other way around are missing the point of SAP.
> The point of SAP is that the module for your type of business is being implemented at the market leader in your area...
I understand that SAP apparently delivers an insane range of good defaults, complex business transactions and covers any imaginable niche use case. That's valuable.
However why does that rule out friendly, accessable and sane UI? Excellent form design, intuitive navigation and generally things that enable efficient work without weeks of training? That seems like low hanging fruit to me. Something as boring as lists and forms can still be a joy to use if done right.
Maybe ERPs are the ultimate test of an agile culture. Sounds weird right? But bear with me.
Most ERP projects fail. They end up over-budget and delivered really late.
Why? They are sold like custom implementations, promising the stakeholders they’ll be adapted to their specific needs. It's rarely the case. The reality requires the whole business to change: its processes, its workflows, its traditions.
Therefore, only companies flexible enough can survive such deep transformations. Companies that are agile.
That judgment is based on the premise that the processes mandated by the ERP software are more effective than the company's current processes.
If a company terminates its adoption of an ERP solution, it does not necessarily mean that the company is not "agile" enough. The company's leadership may simply be concluding that changing its processes to the ones mandated by the ERP would make the company run less efficiently, a consideration that could outweigh the benefits of using a centralized piece of software to manage its operations.
All in all an interesting article, although some PR piece alarm bells just went off.
I would have loved to have additional information that might not have been provided due to the fact that Retool is a very early stage competitor in the ERP space.
With all the SAP bashing that is happening, there must be some advantages that the SAP software suite has, right? I would love to hear about them.
The rigid nature of the SAP software - and the crazy costs that come with it's customization - is a known problem. I still wonder if this is the real reason why the migrations and implementation projects with big customers fail, or if these are, generally speaking, just really big projects that carry a huge risk. The truth is probably somewhere between both extremes.
What long term structural disadvantage do you see in applying the Retool software model?
Congratulations for getting your product out of the door!
SAPs magic is the integration: A company I worked for rolled out SAP for a Production and supply chain distributed across about a dozen countries in Europe and went from 3+ weeks order commitment time (Not lead time) to immediediate including sourcing from external suppliers, logistics Partners and Production facility allocation.
A lot of this is just plain pointless bravado. Eventually a lot of people have to outsource their payroll and other admin work, it's just cheaper that way.
Then you just discover your are doing many things unique to your company so you kind of have to retrain a lot of finance and office management staff. And keep retraining them. Then also maintain teams of programmers to do maintain your software.
You don't want a car company to focus its resources on payroll software.
So Tesla is again loosing focus? man, if they would just focus on a) developing EVs and b) mass-produce them traditional car makers wouldn't stand a chance by know. That hybris can kill them one day...
Not necessarily true.
The place I work at does the payroll with some cheaper payroll ERP. Most other things...well let's just say a programmer to make the entire thing was cheaper and more effective.
The ERP has to interface with various NFC and barcode scanners, ticket printers, etc other companies appliance interfaces, the consultancy costs to adapt and existing erp and make it keep track of the entire production process and it's unique quirks would be trough the roof and make any subsequent version upgrade unmanageable cost and time wise.
My understanding is that SpaceX built their own ERP system in-house and then shared it with Tesla. So it's possible that "4 months" was really about forking/customizing it for their needs.
621 comments
[ 2.1 ms ] story [ 337 ms ] threadInterestingly, the source code of SAP is openly readable (once you have their software installed).
As a user, I would have been happy to dump it and use anything else. But who am I going to complain to? I'm not the customer, my company was. And it's not like they are going to switch ERPs just because employees hate it (which we all did). Even if they wanted, the cost of switching now would probably be astronomical - not only on migration, but also on training and support.
It's no surprise that SAP is worth that much, seeing as they have the perfect captive audience: the wealthy kind.
It is dense, extremely clear and consice. I agree with the slowness though.
I'm a power user so I am not the best person to ask for UX advice, but I talk to people all the time that just wish they still had the classic Windows 9x UI's and things more or less were "boring".
Reminds me a little bit of a statement about how Taxi drivers can tell you what works architecturally better than an actual architect when it comes to ground floor interaction.
Contemporary UI trends bother me except one: websites like drewdevault.com and text.npr.com are refreshing.
This is also why I believe the Windows 8/10 developers must be working on macs.
I use it with C++ and C# and I can't say stress enough how amazing it is to use with C++, compared to the teeth-pulling experience of using xcode for the same tasks (some of which are impossible in xcode, edit-and-continue for example, set next statement).
To be honest what I don't like is the neverending march of tiled frames for everything - the whole program is one frame, then i have one frame for the code, one frame for the solution explorer, two more frames for error list and output, another one for properties and so on. A lot of screen space is taken by just blank spaces or dividers.
Another thing that I didn't like was that the 'Comment selection' option is hidden in Edit -> Advanced -> Comment selection. You also have to use two keyboard shortcuts in succession to comment something (Ctrl+K, Ctrl+C) and the uncomment shortcut is different (Ctrl+K, Ctrl+U). All this while Ctrl + / does nothing and could do both at the same time.
I often need the whole VS solution and not just the code when I need to copy paste the project to a different folder or a different machine.
The double-keystroke thing is a bit odd yes, and the menu is hidden a bit far away for ease of navigation. Still, it could be worse - it could be a RIBBON!
But it's hardly a majority (or even that many at all). If you're developing primarily on the CLR or for one the the many Microsoft sub platforms, the first-party tooling is actually quite good. It's only when you need to do both, or stray from one a bit too much, that things become arduous.
Generally however, the Mac users are almost always essentially Microsoft developers who have to target both Windows and Linux and don't want to deal with managing/maintaining a Linux daily driver. MacOS is "close enough". It's pretty representative of the non-Microsoft developers in similar situations.
And no: the Linux Subsystem isn't enough for them either.
However, just because it resembles 90's UI (which I'm a massive fan of) doesn't mean it follows it philosophically. It regularly breaks its own rules and is deliberately designed to be obscure as possible.
I wasn’t talking about mere resemblance. I’m talking about functionality, density of information, layout, hierarchy of importance exemplified by various aspects of the UI, clarity and intent, feedback and signaling, on and on. The whole thing. The only thing that bothered me about SAP was how clunky it felt, simply because it was slow.
I’ll quote myself: “It is dense, extremely clear and consice.”, yep it’s great to use. I also love JMP statistical software UI and Cinema4D UI. They’re a pleasure to use.
SAP and software designed to offer high levels of customization in general leave the task of building a complete UI to middle managers familiar with business processes. They do not generally have any understanding of UI design and are quite happy to add a 50x50px, non-resizable text box for content that will often span multiple paragraphs.
I don’t care so much that the UI looks from the 90s. For an internal application, a battleship grey winform is perfectly fine, as long as the workflow is simple, fast and intuitive.
Aesthetics matter. Make software that is beautiful and a joy to use.
I have heard same argument for command line interface in yester years, why switch to Graphical User Interface, when CLI is so much more faster and I love it (and so do my other friends around me).
Attrition (so new employees), interns, fresh campus hires, I guess does not happen in that universe.
The one slightly annoying thing is that for a lot of things there are at least 5 different ways to do the same thing/5 different screens with very similar functionality, and everyone seems to use a different one.
But it's also worth saying it's a tool specifically aimed at specialists - it's not going to hold back on giving you a huge number of options over which data you want and how you want it presented, and it's not going to warn you that some data might be incomplete or not the one 'everyone' uses.
Everyone seems to think that, and then they produce software that looks beautiful and is horrible to use.
Gray buttons and scrollbars at least make it obvious which part of the UI you can click!
This corresponds with my personal experience: the win95-ish software design was my peak for daily productivity. Besides, you generally get a main window with grey widgets and colored icons at the sides, and a white working area full of colored items. So the end result isn`t all that boring.
https://books.google.be/books?id=TVQUAAAAQBAJ&lpg=PA74&ots=O...
Too many designers, maybe a majority, make "beautiful" software that is a pain to use.
Are forms today better than they used to be? I don't think so. Most "web based" or "web inspired" apps today are slow, unintuitive, and have idiosyncratic behavior. How often have you had a form that didn't work right because some Javascript request failed and/or it decided your entry wasn't correct? How often did tabbing through fields actually work as you expected?
While your statement is technically correct, it leads to software that just isn't a joy to use. We get used to having bad usability, and we take for granted that forms just don't work 100% and so we take the safe route - for example writing long text in an editor and copy-and-pasting to be sure. Have you never done this?
Having beautiful interfaces is nice, but it should be an afterthought and not a priority. Because it is difficult to optimize everything at the same time, and beauty is lexicographically unimportant compared to efficiency.
We must have not used the same SAP forms.
* "[SAP] customers distribute 78% of the world’s food and 82% of the world’s medical devices"
* "[SAP] customers include 98% of the 100 most valued brands"
* "77% of the world’s transaction revenue touches an SAP system"
Wow!
For example Apple, Microsoft, Amazon and Google all can use SAP internally. But it would be false to state that all their businesses are run on SAP...
I only pointed out that the statistics in parent post can be skewed due to the sample of top 500 corporations which can implement SAP for reasons different to running the business.
It wasn't Amazon's core competency to offer IaaS/PaaS, before they did. GCP and AWS are closely playing in SAP's enterprise customer base. There is huge addressable market there. They've innovated better than SAP in technology space, on parts other than business software.
If they can succeed developing their own ERP, better than SAP, they could even redeploy the development teams from being cost center to profit center.
If I am SAP, I see them as strategic long term risk.
That's like saying "why doesn't Tiger Woods win Wimbledon? He's so much better at sport than anyone else". There are lots of different types of software development, and lots of different types of software engineers. Corporate IT projects don't succeed or fail on algorithmics - it's a completely different job, where 90% of the difficulty is managing people and politics
SAP has a reputation to take down businesses
*edit: mistook aldi and lidl
https://www.linkedin.com/pulse/lidl-cancels-sap-introduction...
That, er, ought to be exactly 98 of the 100 of them, shouldn't it??
That sounds wrong, as I am pretty sure the majority of the worlds food is distributed in places that can't afford or need SAP (and is essentially sold black market). I doubt that street markets in India use it for example.
If there is something I would complain about, it is that their help pages are a convoluted mess of years of content with broken links galore, lots of duplicated content between help pages between different versions and an on site search which is just not very good.
So basically you have to Google stuff, then unfortunately come out on the help pages for an edition you do not actually have and then will have trouble finding the corresponding help page for the thing you actually run.
I'm so glad that I now work with NetSuite!
I mean, that's literally how you price enterprise software.
Basically: Make a really bad product + make it mission critical = a product that people are literally glued to using
Wow, really?
If so, how many of those tables just exist to define enumeration cases?
The entire system required magic numbers to be put into various columns in different tables, simply to modify the behaviour of the "logic" code as it resolved to a C++ enum once extracted from the database.
It was horrible, and nobody knew how the entire system worked, so there was a vast disconnect between what it actually did (and the hundreds of auto-generated SQL statements it ran, very slow) and what they thought it did.
As expected, this created wildly different expectations of what was possible from the internal "implementation" team versus developers. Of course, this was interpreted as the developers' fault, and there was a constant stream of new developers that would stay for a year or two, then leave. Toxic.
(From randomly perusing their help portal, it seems that there are one or two modern - and quite exotic - software products from SAP that do support Docker and I think also LXC, so it looks like they're slowly moving ahead in this regard. :) )
Would someone kindly differentiate between the ERP vs ITSM (IT Service Management) industry in perspective for me? I would in ITSM and often wonder if I would had been better off staying in ERP like SAP?
Secondly, how does ERP fare in terms of complexity between game development vs ERP Software development? I understand the target base is totally different (Gamers vs Enterprise clients)
Let me know if I am too vague
What is important to understand is that SAP is standardized way to do business for ALL departments in big corporation. You probably can't be "expert is SAP". You can be expert in SAP treasury system, SAP data warehouse, SAP ITSM, SAP data analysis, SAP call center etc.
I heard that SAP consultants are paid very well and I think it will stay that way. But I guess this thread sums it up perfectly: it is due to the complexity that these implementations bring to organisation and lack of elegant solutions from modern software development world. So in terms of money it is good, but the trade offs are quite big.
I can only speak from a bit of SAP experience:
So usually, implementing an ERP, at least SAP, first means "customizing" it, that means adapting the thousands of configuration parameters to the organization. This is no programming task, in fact you "just" operate a GUI. The difficulty is more in finding the proper the option.
True development tasks are often very restricted in scope - most often it is just the development of a new report or custom data export (one of the annoying things of SAP ECC always was, that it really really really loves to keep its data to itself. While theoretically everything is open - you can even browse the underlying the database directly from the UI, with appropriate rights, and can also quite comfortable run even DDL statements against it - often you are back to ABAP very soon for any kind of interfacing tasks simply because SAP likes to live in its own world with its own standards for data import/export (Idocs for example or its proprietary RFC interface). Things might have gotten better recently with e.g. the OData support, but I haven't yet worked with a system which had that.
1. Constant Updates/Upgrades Most games are a one time effort with some patches and maybe a add on and if it’s really successful a sequel. Business Software runs for years in a company and needs to be supported. So the customer needs to sign a service contract besides the initial payment and licenses. Games are usually a one time buy. Exceptions are MMOs. Game companies noticed this mishap and are trending to service games now, which would create a steady inflow of money from loyal customers.
2. Complexity It depends on what the game company focuses on. If you only build games, you need to master a game engine or build your own. It doesn’t need to be customizable if it stays in your company. With ERP software you need a lot of configuration switches and cover a lot of similar but not same use cases. A standard product is almost never bought my businesses. They want you to build something for THEIR process. So what SAP did is maximize on this need and they built so many customizations, that you need special training to even begin to understand one of their modules. ERP is definitely more complex in the realm of more stuff to learn and to remember to get it right.
In terms of complexity defined as difficult I can’t really tell because of my lack of experience with game development. But I guess mastering a game engine is difficult, but less “complex” than ERP software.
Funny side note: I did a SAP training one and half years ago at their HQ in Walldorf, Germany. And they own pretty much the small town. There were so many foreigners in town to visit SAP. The SAP campus had the same size as the town :)
ERP software is mostly a giant CRUD app/database, with APIs, reporting functionality, and a ton of relatively simple code for automating the system/business processes attached to it. These parts taken alone are usually fairly simple, however the complexity really stems from the enormous scale, interfacing elements, moving requirements, and mutability of everything. It’s easy to knock SAP, but it’s difficult to keep software nice when you're dealing with these attributes.
As for game development, I tend to find it more computationally complex, but that can depend on the game and tools you use. By computationally complex, I mean the code itself is generally more complicated. However, what’s easier in game development is the amount of control over things you have. In comparison, you largely dictate how much mutability your game will end up dealing with, the data it will use, and how large the game will be. Players aren’t going to be dictating this. Not to say game development is easy, but it’s easy to make slick software when you have complete control over the nature of things.
So in short, ERP software is complex (and crappy) mostly due to the enormous scale and the complicated nature surrounding the software - whereas games are complex in regards to the nature of software itself.
It was sprung essentially overnight with no training and expectations to show immediate positive results with no criticism tolerated. The rollout was preceded by a couple of years of secretive process reworking where the business was modified to the way SAP said it ought to be done. We expand it to "Stop All Progress" because it marked the formal transition from a technology influenced company to an integrator focusing on acquiring tech from others.
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.
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
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.
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.
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.
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.
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.
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 ?
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).
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.
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.
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 :).
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...
[1]https://github.com/odoo/odoo/issues/27386
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.
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.
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.
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.
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).
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...
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.
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.
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.
It's almost its own industry. There are fleets of consultants charging ~$1000 a day just to install the system. Then, as the OP said, they charge by the hour for customised reports which means that businesses have to choose their report very carefully, and will probably need several more hours consulting when one aspect didn't work quite how they thought.
I would be surprised if the commenter here was someone who didn't already have access to the data. They are being frustrated by consultants who want to keep their billable hours up, and extraneously restricting access under guises such as "this person doesn't have enough training to touch the system," because it keeps them in paid work.
Source: Friend of mine. Man on the inside.
> They are being frustrated by consultants who want to keep their billable hours up, and extraneously restricting access under guises such as "this person doesn't have enough training to touch the system," because it keeps them in paid work.
I'm not sure why there's quite a few people pointing these aspects out in here. As opposed to the person using that data to keep their own billables up? "this person doesn't have enough training to touch the system," seems like a perfectly valid thing to say given what these systems do and is certainly not unique to SAP. The learning curve might be steep, the documentation looks ancient, the ecosystem might seem unapproachable, but at the end of the day this isn't that different to similarly scaled products from players like AWS or MS for example. They might have more approachable lower tiers and are nicer in quite a few technical aspects but other than that? It's often consultants and "certification or gtfo" as well. It's not like the consultant costs come as a surprise to anybody in these industries. Sure, it's their own little sub industry but you could say the same about these other ecosystems as well, that's not special - it is just how a few of these sub sectors are structured.
I work in infrastructure an automation on the AWS/MS platforms and work with just about every level of their technical capabilities. I don't have any certification. I don't even have a university degree. I can work with the documentation, which is more often than not up to date and worthwhile. Though the curve is often steep, this doesn't mean it is beyond people with a careers worth of experience around the subject.
I have also learned a small amount about the sort of work involved in these custom queries from my friend. For the most part it's no more difficult than basic database administration; i.e. it's a query language, akin to SQL. It's difficult enough that I can see why someone would want training in it before touching a production DB. But from what I hear these consultants often work straight on Live and then rack up more billable hours fixing the mistakes they made with the customers' live data.
All of this is anecdotal, but the business model (essential monopoly) makes me squirm at the best of times.
Soon after our company went public, we gave up on SAP and started doing things old ways.
Wow.
If the original was billed at 1.3 billion NOK and we're at 2 that's still very high, but it's a different discussion from a 400K NOK estimate.
"Take whatever you think you need and double it" comes to mind.
Try to implement it without the necessary scale of operations, with sticking to standards and without training at your own peril.
That being said, without any production going on I would never even consider SAP. When don't have any use for their MRP-functions, forming the very core of SAP, you are better of with different solutions. And their licensing schemes are just aweful, not to even to talking about pricing yet...
- Stick to the standard, the smaller you are the less customization you do. ususally I'd say 90% standard, if you're small aim for 100%. makes it faster and easier to implement. And cheaper, because you need less external resources.
- Wait. SAP is deprecating SAP APO by 2023 (IIRC, something like that). So implementing before that could be a problem. Either you end with a legacy system and have your first release change right after, or during, implementation. And release changes are unique kind of hell themselves. or you end up with a new system that is yet untested. I wouldn't want either of that.
- Try to model your business already now along SAP-processes. First, these processes aren't that bad. especailly for the back office side of things as other pointed out already. Plus, it makes and future SAP implementation a lot easier. Same should be true for other ERP-systems, but I have not that much experience with those. Aside Odoo, which I wouldn't touch with a ten feet pole ever again in my life.
- get external consultants. Really, get them. get the good ones. A lot of hours. At least one for every module of SAP you want to implement. And have one of your own devs sitt on the consultants lap during the project. One per consultant. It's expensive, sure. But less expensive than an aborted SAP-project.
- Invest hours, days, weeks and months in user training. From day one, ideally as soon as you have a test envioronment. Start with key-users, experienced, smart peolple open for change. And work from ther to every singel user of the system. You need their buy in, without even the best SAP-project will fail. These people are alos the backbone for the future, trea them well and listen to them.
In case you want to hear more of my rambling, just shoot me a mail, adress is in my profile.
Never used it but it does not have to be SAP/Oracle at that size. Could still be the best solution though, I'm no expert.
"CYA is SOP", hence millions of layers of approvals, QA, and change controls. Feddy'Gov was actually the fastest moving, in my experience, but they also didn't have to worry about manufacturing defects or breaking BGP nationwide.
Never attribute to malice what can equally be explained by stupidity.
There have been several high-profile cases of German companies migrating to SAP (from their home-grown zoo of different software for different purposes) that have gone spectacularly wrong. They are way over budget, way over time, and sometimes abandoned completely, like with Lidl: https://www.consultancy.uk/news/18243/lidl-cancels-sap-intro...
I have heard (anecdotally, and third-hand) that the only way to successfully introduce SAP (or Oracle, for that matter) is to completely succumb to it and restructure your business along the lines that SAP assumes as default.
You try to keep your little company-specific process for buying christmas gifts to employees? Fine, but it'll cost you several hours with an SAP consultant. You try to keep your non-standard terms with one supplier? Fine, another bag of money.
You do that more than just a very few times? Your migration has failed.
If you do it the other way, you'll first spend millions and millions customising SAP and then your project will fail at some point. It will also make all SAP upgrades completely impossible and they will cost millions and millions.
All of the successful SAP stories have been about companies who either match the SAP model already or reconfigure themselves to match it.
All failures are the opposite.
First off, in SAP speech, "customization" is the act of simply adjusting the vast configuration options. This does not affect your upgrade possibilities at all. Even if you go so far as to add custom programming, as long as you (lowest complexity) just have programmed additional "transactions"/reports, you will usually not run into a problem.
The system also provides various mechanisms to extend standard transactions via hooks or to extend standard tables and still be able to upgrade without additional effort. I was actually astonished how much customization SAP allows in that regard while still staying compatible to the standard codebase - probably one of the reasons everything is so damn resource hungry, because there are multiple layers of indirection at work to allow this. From a development point of view, the major annoyance here is there are so many different options to extend stuff from different decades, so for some use cases you will use BADIs (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...), for others "exits" (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...) and it is all a pain to lookup and locate.
The one thing which will get you into trouble is if you manually patch standard programs - which you are able to, the whole business logic comes with sourcecode - and which is usually not necessary.
When they upgrade, these additional programs require regression testing. Those programs make upgrades risky, and those programs may need to be rebuilt. Historically, companies built a ton of these customizations, then had issues during upgrades. The most recent model (since S4 and HANA emerged) is to do as much as possible in configuration, and limit customization.
https://help.sap.com/viewer/521cd184dd2f491a9a4179edb66951c3...
Let me quote: "The term Customizing refers to the process of system configuration during which the members of the project teams make the required system settings. In the SAP System, Customizing activities are performed through the Implementation Guide (IMG)."
And no, this leaves no room for interpretation. The IMG is basically the centralized config setting catalogue of SAP and does not allow programming.
It may not be, what is typically meant with customization or with other systems, but in SAP "customization" refers by definition to anything which can be configured WITHOUT programming.
All documents clearly differentiate between "customizing" = using the configuration, "extending/programming/development" which would be Z-reports etc., "enhancement" with user exits, BADIs and the like and "modifying", which would be patching the standard programs.
And yes, of course upgrades still require testing. But saying it is "impossible" to upgrade just because you have z-reports and the like is plain wrong. Most of the time, especially if we do not speak about a full blown ECC to S4 migration, which involves large scale changes to the underlying database structure of the ERP unlike upgrades within the ECC line itself, you will not require updates to your z reports at all.
Customising an ERP can be interesting, keeping it supported and updateable 5/10 years after the guy who wrote the mods retired is a nightmare i've seen one too many times before.
English article: https://www.handelsblatt.com/today/companies/programmed-for-...
Key quote:
>Unlike many of their competitors, Lidl bases its inventory management system on purchase prices. The standard SAP for Retail software uses retail prices. Lidl didn’t want to change, so the software had to be adapted.
What if the business model of Lidl is way better than the standard? Then Lidl is very wise not to follow how SAP works.
Is Lidl earning more money than their competitors because they base their inventory management system on purchase prices while others do not? Then build/buy a system that handles that and it could very well be worth it if you look at the business case
But if it is like that because that is how we started out and we cannot quantify how much better it is...then maybe you should just change your process.
Also
"Critics inside Lidl say that KPS was too slow. But Matthias Nollenberger, a senior manager at KPS who was responsible for overseeing the eLWIS project, says his company was working too short deadlines compared to other similar projects"
I belive when you have the choice between aborting 500 million and increasing some deadlines, I doubt they were the problem. It simply was not possible to adobt SAP with reasonable amount of money. And the consulting company or SAP should have said that at some point clearly.
Anyway I started looking through the Javascript the browser automatically downloads and found there was 10s of MBs of un optimised code only a tiny percentage of which was being used. It was horrific and it was easy to understand why the system was so mind blowingly slow.
I think SAP views APIs as a threat. That COBOL-like ABAP language is part of their lock in.
This bit is changing now. They're still not there, but internal engineering teams are slowly getting it. There are high priority API first development projects underway.
Now was that a pain? Yes, sure. Especially the whole legal/certification/consultant crap you need to buy into alongside the software. But honestly, at least here in Germany, SAP ABAP/Java developers and consultants are easy to come by. Most of the problems I've seen in SAP related integrations are process related, not as much tech. If you're dealing with a customer that's already up and running in that ecosystem chances are that they already know their pain points, it's not really any different than any other large B2B integration in the space.
Reasons why people started working outside of SAP:
- because they didn't know the system well enough and didn't receive proper training. Sometimes also out of pure spite.
- sometimes because SAP didn't have that functionality yet. Ship planning for example was an issue in the early 2000s IIRC
- because people wanted and had to use a SAP-standard process, but couldn't because somepone else ripped that standard appart to do something differetn. Either because the original standard for that was itself ripped appart by someone else. Or because people refuse to follow the standard out of reasons. Misusing standards is beast in SAP. Once you start with a single process, that spirals out of control and cannot be stopped. Part of the reason a lot SAP implementations just suck. Not purelySAPs fault so.
A lot of the interactions that simple employees have with SAP shouldn't require training though.
I shouldn't have to get a training to be able to fill a small list of hours, and it shouldn't take me 30 minutes to do so. I shouldn't have to get a training to be able to read a received request and validate it.
SAP has strong NIH syndrome. They could get away with it due to their dominance. So these guys are in echo chamber of own. It reflects and explains the observation you have here.
> 10s of MBs of un optimised code only a tiny percentage of which was being used
frameworks! they try to scale development with frameworks, and end up in dilbert-esque side effects like these.
There are ways to do stuff in SAP, lots of implementation problems arise from the fact that people don't know how to do it right, and just try to apply whatever they do know. There is documentation and there are books.
But i agree, SAP is not for those who are sensitive to license prices. Most commonly the solution is a third-party custom built software, that interfaces the data into the back-end SAP system.
The OP's comment was about scraping data from pages generated from SAP Web apps. I tried to point out that it make little sense, as there are proper ways of interfacing data (even over HTTP).
At the last SAP site I worked at the general feeling was implementing SAP had left the company weak. This lead to them being taken over by one of their competitors.
They just can't/won't roll out new things.
Also, HN is a hacker crowd with a particular axe to grind re: UI, since all the cool new UI shit makes insta-billionaires, or at least thats the dream.
Whereas with a SAP-using business, the computer isn't the product - the products that the computer allows the company to manufacture/distribute are the only thing that matters - and the SAP UI is intentionally set up by bean-counters.
Once you go SAP, like get into the SAP Zone, you can be quite productive - but like another poster said, SAP is like vim.
:wq
I recently did something called a BDC since the API call did not work so you resort to stuffing values into some internal tables and replaying keystrokes to enter the data into the system.
The point of SAP is that the module for your type of business is being implemented at the market leader in your area, because they are the only ones who can afford it. SAP will come to the market leader and put their processes into software.
Then everybody else adapts to SAP not because adapting SAP is impossible but because SAP implements the processes that made the market leader successful (at least that's the idea).
So it is very intentional that you adapt to SAP and not the other way around. You do it to emulate the market leader.
And the user friendliness is also on purpose. If you go visit a company using SAP, you will find that you have a certain job in the company and it needs two or three things from SAP. Jobs are very specialized, so SAP is, too. Nobody is supposed to just wing it with SAP. You are supposed to learn how to do your transaction with SAP, and that transaction is then meant to be super efficient.
If you actually go visit a somebody from an enterprise environment interact with SAP, you will be astounded how quickly they can do what they are supposed to do. It's almost as if the software was optimized for frictionless efficiency.
Also note that user friendliness is a subjective and mysterious area. If you go look at an airplane cockpit, where actual research was done into how to optimize user interfaces so that the pilot will not be confused under stress, you will see that there is a separate button for everything. There is no "shift key", no different modes. If you need to use it, there is a button for it. To someone who has not learned how to use that UI, it appears alien and unfriendly. But the the trained pilot it is the pinnacle of perfection.
Unless your company has thousands of employees and billions in revenue, Google/Microsoft/Apple processes are probably not for you.
Then you probably don't need and shouldn't buy SAP.
Even a bleeding-edge company will hit an obstacle they cannot improvise through (like in QA or Compliance). That's when enterprise software creeps into an otherwise lean operation.
But yes, to actually plan and run their manufacturing area, that's where the software I write comes in... as well as a ton of spreadsheets :)
My design professor used cockpits as a example of bad UI. Grown over the years and understood only by repetive drill and not at all intuitive.
So there might have been research to better it, but I doubt there was a major redesign, or was there?
But many employees have to interact with SAP only from time to time. They're not supposed to be specialists at it, just get one action done from time to time.
Everyone in my company has to enter their hours in SAP monthly. The interface is terrible; is everyone supposed to learn how to enter a few numbers in a table once a month?
Or say there's a process I need to approve. I just need to read the attached PDF, and click I'm ok with it, maybe a couple of times a month. Where is the benefit of making me learn a complete new and arcane way of validating a task?
> The point of SAP is that the module for your type of business is being implemented at the market leader in your area...
I understand that SAP apparently delivers an insane range of good defaults, complex business transactions and covers any imaginable niche use case. That's valuable.
However why does that rule out friendly, accessable and sane UI? Excellent form design, intuitive navigation and generally things that enable efficient work without weeks of training? That seems like low hanging fruit to me. Something as boring as lists and forms can still be a joy to use if done right.
Most ERP projects fail. They end up over-budget and delivered really late.
Why? They are sold like custom implementations, promising the stakeholders they’ll be adapted to their specific needs. It's rarely the case. The reality requires the whole business to change: its processes, its workflows, its traditions.
Therefore, only companies flexible enough can survive such deep transformations. Companies that are agile.
If a company terminates its adoption of an ERP solution, it does not necessarily mean that the company is not "agile" enough. The company's leadership may simply be concluding that changing its processes to the ones mandated by the ERP would make the company run less efficiently, a consideration that could outweigh the benefits of using a centralized piece of software to manage its operations.
I would have loved to have additional information that might not have been provided due to the fact that Retool is a very early stage competitor in the ERP space. With all the SAP bashing that is happening, there must be some advantages that the SAP software suite has, right? I would love to hear about them.
The rigid nature of the SAP software - and the crazy costs that come with it's customization - is a known problem. I still wonder if this is the real reason why the migrations and implementation projects with big customers fail, or if these are, generally speaking, just really big projects that carry a huge risk. The truth is probably somewhere between both extremes.
What long term structural disadvantage do you see in applying the Retool software model?
Congratulations for getting your product out of the door!
(Disclaimer: I have no affiliation to SAP etc).
Some? It's 100% PR. Nothing else. 1st ad I see this year, courtesy of HN, cause otherwise uBlock Origin would've stop it.
I love this story, it really isn't that hard to replace SAP once you know the requirements.
Then you just discover your are doing many things unique to your company so you kind of have to retrain a lot of finance and office management staff. And keep retraining them. Then also maintain teams of programmers to do maintain your software.
You don't want a car company to focus its resources on payroll software.