What's SAP?
retool.com
retool.com
It's hideous. Hideous. My students complain it is unusable (agree), doesn't make sense (agree), that they can't see the point (agree).
When you look at the underlying database 'schema' (inverted commas deliberate) you'll find it's a massive, denormalised mess.
Much of what SAP can do can be done at the local level using intuitive software. Reports, for example, against a well-designed schema or data warehouse are easy. Power BI, Tableau, whatever your poison. You can even aggregate and present data in raw SQL if you like. Each technique is far easier than trying to achieve the same in SAP.
What SAP does do well is multinational, enterprise-wide integration. Are you a company comprised of many mergers and acquisitions? You can do HR one way, universally, across your organisation. Credit control? Replace your spreadsheets and custom apps you have deployed across your many siloed finance departments with the FI/CO modules.
I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't be, but it is. SAP is SAP. It doesn't care about your USP. Or your custom approach to business. As far as SAP is concerned all businesses are the same, they do the same things, and all must conform. Resistance is futile.
There is too much operational and human complexity to solve healthcare with software alone.
One hospital death has already been confirmed as being due to UX difficulties with the new system. Link in Finnish: https://www.hs.fi/kaupunki/art-2000006391154.html
The results apparently doesn’t favor Epic in that it costs 4-5 times as much [1] and has caused productivity loss 1.5 years after implementation [2] (links in danish)
Still don’t know if is a fair comparison though, since you probably pay the costs of adhering to process to start off with and only reap the benefits later. However the Epic implementation has also been bug riddled and I’ve also read that the procedures are designed for a litigation happy US and thus are not rational to apply here.
[1] https://www.computerworld.dk/art/248393/sundhedsplatformen-e...
Complaining about large corporate structures failing to meet individual needs is always a very appealing criticism, but people rarely seem to point out that these large behemoths need to be judged by their overall throughput.
The mass of people who benefit from standardized workflows are always anonymous, the failure cases always have a face, but it doesn't mean the trade-off isn't net positive.
Same input, but vastly different outputs.
And I don’t think their differing constraints can appropriately justify it.
It was all web-based - we even had a version for "mobile" (at the time which meant a ipaq personal assistant, running a version of Windows CE and a browser that made IE6 look sane).
The idea behind it was "patient-centricity"; the patient could manage, view, and "edit" their own healthcare records, and any physician on the system could have access to that patient's records (the patient would have to give approval to share with the provider).
It wasn't ever going to replace EPIC or any of the other large medical record systems, but the fact that a patient could control their own data was a significant part of the core marketing behind it - provided you could get other providers and support people on-board.
Things were going rather smoothly (but not very quickly) in the progress of the development of this app, until the client wanted to make the entire thing HIPAA compliant. At the time, this meant taking it off our in-house shared hosting environment, and get it on something else. What we found was, at the time the only option was to lease a full rack from Rackspace and use their services (and servers), as they were (supposedly) fully HIPAA compliant.
The client balked at the cost to implement such a system, and instead opted to roll their own. Then the client decided to hire their own developer (without telling us), and wanted us to backdate some HIPAA "compliancy documents" to say their system was fully compliant on a date when it wasn't. My employer thankfully decided not to go down that road, and instead to drop the client and contract (probably the best decision he ever made).
But yes, what changes are the business end users requirements for slicing and dicing performance data from 'subsets of this' and 'subsets of that'. I think HANA plus the move to the cloud will potentially help this.
You have a bunch of smaller companies with different products, and whichever you pick, it will have some faults, missing features bugs, etc., and you'll the the one blamed for picking the "wrong" software.
...or you pick IBM/SAP/..., which is "de facto standard" in your {industry}, and whatever is wrong, is not your fault, but IBMs/SAPs/...s.
This is a common misunderstanding. Many people miss the underlying philosophy of SAP software. The reason SAP encourages businesses to adopt SAP's way of doing things is that they did research into the optimal way of doing the common business processes that don't differentiate you from your competitors. A common industry lingo to encompass that was Business Process Reengineering. That's why implementations of SAP in the 1990s were done by Big 4 firms to rework the processes of business actions alongside the installation of the software itself. In other words, kill 2 birds with one stone: if we're already spending millions to install ERP software, let's also modernize our business processes into "best practices" because those are already the likely default configuration in SAP.
E.g. there's an optimal way to manage Purchase Orders and SAP encoded that sequence of actions into SAP's data model and GUI data entry flow. You're not going to beat your competitors by insisting that your snowflake way of handling your Purchase Orders is special and "SAP should conform to it". PO's are not your "secret sauce" to dominate the market.
An analogy might be in carpentry where the optimal process is: Measure twice and cut once. -- therefore the standard SAP data entry screen might have 2 text boxes "measurement #1" and "measurement #2"
But another custom carpentry/woodworking shop says SAP is inflexible because they want to customize SAP's system so it's: Measure once and sometimes have to cut twice because of occasional measurement error. -- and SAP's response to that is "you're doing it wrong" -- and SAP's research is often correct -- so don't spend consulting hours to customize SAP into doing the suboptimal thing. Nevertheless, the oddball carpentry shop insists they're "special" so they want the UI text boxes to be customized to be "cut #1" and "cut #2 redo". Well, say hello to expensive consulting billing hours and painful upgrades.
The bottom line is to use SAP for what it's good at: the boring back office enterprise stuff that will not differentiate you from the competition.
> It doesn't care about your USP.
But asking SAP software to "care about your Unique Selling Proposition" is out of scope for the software's intended use. For example, Microsoft and Google use SAP internally even though SAP's ERP capabilities are out-of-scope for Microsoft managing an army of programmers to develop the next Windows operating system or Office suite. Same for SAP not being suitable for Google to run the AdWords system. And yet, Microsoft and Google bought expensive SAP licenses to use what SAP is good for: corporate enterprise financial systems.
What OP is saying - Perhaps SAP 'optimal processes' made absolutely sense few decades back, but when new time came and world or best practices changed, those optimal processes were no longer optimal, but still one needs to keep using those.. because SAP.
From Micro-USB analogy - world has changed, but you still need to keep using Micro-USB for your USB-C phone... because SAP.
The underlying assertion here - made without evidence - is that business processes have changed enough to move away from the SAP-defined ones.
Have they?
But let's examine the question in this light - Today a new CEO was hired in a new company, she is smart AND has multi-millions to spend on an ERP, which she considers absolute must for smooth running of company operations.
Now since she is smart, she is aware of SAP's reputation - i.e., SAP has absolutely nailed down today's optimal business processes (never mind those are actually decades old practices), however SAP would be very inflexible when she wants to innovate on business processes due to anticipated business landscape change (Ex. manufacturing moving back to home from China, and maybe lights out manufacturing).
Being smart, what would she do - would she go for SAP?
She should look into SAP and major competitors. Maybe some cheaper ones.
Sure thing is she's not going to develop an ERP with much features for 5 million. That can cover a team of a dozen people for 1 to 3 years. They can develop some stuff but really not much.
Badly chosen example, though. Looks like a case which can be handled through configuration alone in SAP ;-) In general, automated physical processes of all kinds usually can easily be automated in software, too. Problems are often because in most companies, especially in procurement and production prioritization, lots of of manual, ad hoc decision making is at work without formalized processes.
The actual problems with ERPs are usually more a "devil in the details" thing.
To give a real life example where people run into problems with standard ERPs: (it is pretty boring actually, but boring stuff like that can make or break a company)
I for example once had a customer running SAP. Hope I still get all the details right, it was a while ago. Customer was mostly a home decor trading company which sold to chains. It manufactured parts of its products in a subsidiary in another country and also bought various products in China. I was drawn into the project to "translate" between the company's management and their SAP consultant/developer, as there were, uh, problems there.
Problems started when, after a takeover of the company, they wanted to move to a more just-in-time process for their own manufacturing to reduce warehouse sizes while at the same time their eager sales team committed for some large customers to delivery times which were impossible to fulfill if the ordered product is lying somewhere for more than a day, so they had the problem that they had like 5000 different products, were not allowed to stock them anymore, but had to deliver orders after 7 days while the product was "on the street" for at least 4 and half of these days.
Basically that meant, if an order was somewhere stuck in the process for over half a day after they accepted it, they were fucked and had to pay damages to the customer.
So, task was to tighten the schedules so everything goes smoothly, while at the same time manufacturing capacities where limited, the physical process itself also had limitations (like, even if a customer ordered 1 product of a certain kind, at least 8 of that kind had to be produced, so sometimes it was a good choice to produce something a day too early and stock it for a day to optimally use the production capacities), so it was important that an order was denied right at the start and that the estimates if it can be fulfilled at all were correct from the beginning.
Now, SAP has mechanisms for all of this. Just not the way the company needed (at least not with the ERP alone. Additional components, like SAP APO, might have improved this, but those were not licensed and implemented). Basically, there were two types of sales orders in the system, both did about 80% of what the company needed, you could either produce for stock and sell from stock like they used do when they still had their larger warehouse, but this caused problems as manufactured product sometimes was not packed optimally, so stuff had to be taken apart and repacked for final delivery (because from the manufacturing plants point of view, only an order for e.g. 50 units of product X came in for that way), or express orders came in for identical goods and because not enough could be produced in time, the less important customer got the delivery when both where overpromised.
Alternatively, as would have been the better choice, they could have used make-to-order production in the manufacturing plant and directly associate sales orders and manufacturing orders. This would have been the natural way to do it, but there were "reasons", again routed in the way labor was organized at that plant, that this could not be done.
Oh, and of course, even after solving the production orders, there was still the problem that the sales orders also contained trading goods from China, so that also had to be integrated into the final delivery to the customer at an optimal point in time.
So the company basically needed a custom cross of both methods, which the ERP naturally did and could not support, as the special circumstances could never have been foreseen (Actually, to this day, I would say this was a typical case of politics and company inertia at work. The labor processes actually would better have been reorganized in a way to make a standard process work. I warned the customer, the SAP consultancy warned the customer, but "nothing can be done about this").
So this was unfortunately the time where we had to heavily make changes to the system - custom reports for availability planning, some custom user exits to modify the production start times when orders where transferred between sales and production, lots of small detail stuff like that to make the process go flawlessly at least in software.
The software project actually was successful, mainly because the SAP consultancy was not as bad as my customer believed, they just needed someone who could actually properly describe the problem, so we got away with about 100 development hours, which is not much in an SAP context, simply because the system is so darn huge, you will probably spend 10 hours alone to find the proper location in the business process to apply your change to.
Sadly, customer still went bankrupt. Because the physical process was suboptimal still. But at least the software could model it in the end ;-)
And there's a good chance the new, improved process will make it into SAP sooner than you could develop a new software system reflecting the new process.
It is literally equivalent to forking software and merging each new release from upstream, but usually without access to something like git to help deal with this.
It doesn’t even help to skip versions because now you’ll have even more changes to merge with when you finally upgrade.
This is one of the biggest reasons I’ve seen for people sticking with old versions of software for decades. You reach a point where any upgrade will be as expensive as a whole new system, so you might as well hold out till you request quotes for replacing the whole thing, and probably repeat the mistake all over again.
Ask Rob Pike about Go vs Enterprise Java.
Also, how are these businesses supposes to hire developers if there is no one in house already with the knowledge to ensure they are actually building something useful?
They are likely to end up with a barely functioning HR and Accounting system and developers with a load of boxes checked on their CV ready for the next job.
Funny enough, this is the type of solution SAP is typically displacing. There are huge flaws in the fully-customized process you suggest.
Then there's the issue of expecting a widget-factory to become experts in their own ERP implementation.
ERP software and in particular SAP is awful, has some major limitations, and is a pain to use, but the alternatives are much worse. Only a company like IBM might manage to develop an in-house ERP based on open source technology... but more likely they'd fail.
Some "enterprise grade" software is literally that. SAP works. It sucks and it's expensive, but it works.
Back the day I worked for a couple of years as super key user for SAP, modules MM and PP (material amangement / demand planning and production planning). The one, unbeatable, benefit SAP (or similar monolithic ERP systems) offers is compliance. As every single process is connected to other processes the whole system is auditable and compliant to any tax or accounting legislation out there. Same goes for industry specific things like serial numbers (crucial in aerospace where I used to work). You will never get that by combining nieche products. Not if you aren't willing to create your own in-house developer department. And that will have to be on par with SAPs. Downside, then, is of course that you get zero benefit from improvements out of other companies. Something you will ultimately get using SAP for example.
IMHO, SAP makes perfectly sense if you are a big company with an in-house production. Than you hugely beenfit from SAPs MRP-core, which you need anyway. On-top you get the other modules integrated in the same system. Without production? I would stay away from it.
For my own company, managing logistics and service providers for clients, I opted for another software solution. There is no production to manage, and SAPs solutions for pure logistics, warehousing and transportation but also customs and such things, other providers are way better.
Hybrids can make sense. Customs can be done outside SAP. Same goes for transportation and warehousing. But then interfaces become an issue. Doable, yes. But added complexity and failure modes. It's a trade off between functionality and complexity in these cases.
For production management (classic MRP), I have yet to see something better then SAP. MS Dynamics doesn't look to bad, but I never actually worked with it.
Working with Dynamics CRM and it is an absolute joy customizing the system and building custom stuff on top of it. Very well architected under the hood. Well, it's CRM ofcourse and not ERP monster.
This isn't necessarily bad advice when moving to a new system.
If the development cost exceeds or far exceeds the retraining cost then this is sound advice. I appreciate that this could be a tough calculation to make.
Change resistance will likely be a factor here but sometimes the old processes were hated by the actual users, though not the managers, making the decisions.
That SAP charges extra for industry specific solution, aerospace, process / chemical, and so on, is a different story.
This is a great example of technical debt when adding custom features to an existing commercial platform.
I've worked in companies making decisions around which ERPs to implement. You have two options: roll your own ERP or adapt your processes to an existing one.
The first approach means that you are basically committed to becoming a software company. At a minimum an ERP needs to tie together your accounting, supply chain and inventory. So it's not a simple endeavor and it's easy to mess up. You'll need a team of people to build it and you'll need ongoing support. Compared to these costs, the price that SAP or NetSuite will charge you for their ERP is trivial.
Alternatively, you can adapt your processes to an ERP. In many cases, this is the right thing to do. It means that you can use readily-available software and have practices that are good enough.
Five years later (of which I’ve been on board for 3) they’re still trying to dig themselves out from under that with a development team of exactly four developers, and management finally got the first time today said what a horrendously bad idea it was, but refuse to move on because someone in leadership loves their sunk costs.
It´s buying what doesn´t add much value/differentiation to focus on the things that are important to the company.
Anyhow - I was essentially the sole developer of a simple ERP system written in VB6 and using an Access 2003 MDB file for storage. It was being used in-house by most of the company at that point, from billing, to shipping software and patches, to other reporting, CRM, etc. I looked bad to the bottom line because my salary was going entirely into this in-house developed product, that was producing no revenue for the company. I was a literal cost center; I don't blame them for letting me go - it was probably a good business decision...
When I was let go, I was trying to transition to postgresql for the backend (away from the MDB file), and hopefully move the frontend away from VB6 - and make the whole thing a web application in some manner.
They told me when I was let go they told me they were looking into other options to replace the software I had almost single-handedly written to manage the business.
So - I was let go, and the business was sold. Twice. Today, it's part of HP, last I was aware - about 3 years ago. That was about the time that I had to look for a new job, and talked to my former supervisor there (he'd since become VP of his department).
Yep - still using the same old software, with virtually no updates or fixes. Still running on the MDB file. And somehow, it was still all working, nearly 15 years later. I'm amazed, impressed, shocked, and also in complete wonderment how it hasn't fallen over hard since then.
As far as I know - they are still using it. I've been told that both the original company that bought them, then HP (after they bought that company), both looked at the software and wanted to monetize it - everyone who's seen it has been fairly impressed with it, from what I understand. But, because it's so tightly integrated with the business, plus that it was never designed to be modular and salable, has meant that without a major refactor, it can't be easily done.
Honestly, I'm glad it can't - I'd do so many things differently today that I didn't do then (and if done, they could probably sell it as well); it's the kind of code that I know some developer will look at, then want to track me down for a good ol' fashioned murdering - or at least to beat me with a baseball bat.
SAP was a disaster.
I have to do some maintenance or decommissioning of very old apps in an old bank. I find anything Linux and C or C++ related is the worst, because the system libraries themselves are unstable. Applications fail because of .so dependencies breaking, both system libraries and application libraries (themselves forming a tree of dependencies). It can be extremely hard to rebuild and relink the software with the whole chain of dependencies for the current platform.
Linux executables die along major OS releases every few years, but Windows binaries can keep working for more than a decade easily.
And it's against the linux packaging mantra, where you should be able to "apt-get install libqt" for example (noting that libqt package is completely detached from the release cycle of your application).
This leads to a ton of accidental dependencies and they're tied to the OS release. Even the simplest of apps might eventually depend on libc, pcre, openssl, etc...
Windows is simply different on this aspect. It's more friendly to static builds and the system libraries are more stable. If you built against some win32 API or the Visual Studio 2005 SDK, the DLL are still present and working.
When your target is a system image thats rebuilt entirely from source you can get away with the latter somewhat more easily, but its definitely no panacea. Just look at OpenSSL. (libmemcache is another personal 'favorite' of mine.)
They're obsessed with backwards compatibility and it has it's own issues.
https://www.computerweekly.com/news/2240225262/Microsoft-att...
https://www.gov.uk/guidance/using-open-document-formats-odf-...
Every ERP will be "customized". It has to be - provide your own chartfields, business units, workflows, decision points, etc.
It's the amount of the customization that makes the difference. I've been on ERP implementation projects that were 28 days long, and 5 years long.
I am the "expensive contractor", and I have never ever in 20 years met another expensive contractor who did not fight, tooth and nail, to minimize customization. From the initial business requirements and scoping, to the constant CRs likely to be encountered during implementation.
On average/as a generalization, contractors/consultants have seen many businesses and see the commonalities, seen dangers of customizations, and fight them; clients know only themselves, believe in their uniqueness, and don't have a good vision or image of themselves post-transformation - how they could possibly do things differently. Consultants want their Time & Material bills, sure; but even more want successful project and references - not to mention sanity, semblance of life, and feeling like they did good work and helped the client.
Never worked with SAP, but spent a lifetime working on other ERPs, and would agree.
Your USP is NOT how you do HR, Finance, etc. Walmart's expertise is Retail/Supply-Chain Management. SpaceX's expertise is rockets. Backoffice is a cost centre, and the assumption (validated by decades of projects) is that you are probably (exceptions do exist) not a special snowflake when it comes to HR or Financials, no matter how much Sally in Accounting or Joe in Recruitment office insist.
As I've mentioned elsewhere on this site, the #1 success criteria for ERP implementation is whether you take it as an IT, or a BT project.
- Take it as an IT project, try to adapt a COTS system to whatever gobblety-gook of disjoint processes you have right now through a myriad of customizations, and you will have a failed implementation project which will be over-budget, over-schedule, and result in dissatisfaction of all stakeholders.
- Take is as a BT (Business Transformation) project, and adapt your backoffice processes to match the industry standards and best practices as exemplified in the ERP, and you'll have a smoother implementation project and at least a chance that some stakeholders will satisfied - though more likely to be VP of Finance or HR, rather than Sally & Joe, because Sally & Joe, while experts in their field, are humans who are resistant to change, but more importantly unfortunately in most companies are not privy to the big picture results.
It is absolutely true that most ERPs are hobbled by decades of legacy code; I would agree in principle that it's theoretically possible that a company could make their own ERP that is more efficient; but in reality, company's expertise is probably not making efficient ERPs, and in the end it would be seen as an IT project and no business transformation would take place - IT in service of business, after all. Even as a techie, my jaded/experienced view now is that amongst other things, when done right, ERPs provide drive and impetus for business transformation that needs to take place.
As a techie, I would agree with your students on probably all the issues they see with ERPs. But their USP is not the brilliance of technical design - it's the proven business workflow and processes that have been standardized over decades of experience across hundreds and thousands of real world enterprises. Students are also likely to see inelegance of code or even business processes in isolation, but may not have real-world experience to understand why some business workflows are the way they are; why processes are seemingly inefficient but minimize ambiguity, or provide traceability and auditability; and myriad other unfortunate but realistic real-world constraints, scenarios, and frictions :-/
You must be much better at Excel than I am if you can ensure consistency with multiple users and millions of rows?
ERPs track inventory, and orders very well. They don't need pretty graphs to do that.
No they cannot. ERP's are beasts of expert domain knowledge hidden in shitty codebases, but don't be confused for an even a moment to think you can do it yourself. It's a fools errand, and I'd fire or not hire anyone that tried to intentionally do this rather than just build something basic to hedge time until you have to implement something more serious - be it SAP, Sage, Dynamix, BlueCherry, NetSuite etc.
Also good luck passing an accounting audit with your vastly inadequate internal tools. Did you implement GAAP? FIFO for inventory? Tools to provide receipt of goods scanning and reconciliation vs the original invoice? How about split shipments of PO's? Landed costs? Accrual accounts?
How about providing your accounting, finance, planning, and merchandising teams with the tools they need to get their jobs done? I'm sure you'll be super happy you spent a year building those internal tools only to discover no one likes them because your team lacked the context and domain expertise to understand all the nuances of how things come together and the business processes the tools and ERP modules supported.
The problems that ERP's solve are incredibly esoteric and require incredible expertise across a number of fields to appreciate why things are done the way they are (horrible code/APIs aside).
SAP isn't (just) a giant pile of steaming data model mess because of the thousands of people involved building that software, but really because it can model every tax case in every country in the world. Thought you had a great model for your sales tax that covered US and the EU? Well, enter Brazil and think again, with four slightly different taxes, some of which are applied on the net and some on the gross amount.
Then again, if your plan does not include entering Brazil, you might actually be better off using smaller or your own software, as configuring SAP to do what you want it to do is often on par with writing your own system from scratch.
There's a slight shortcut to that, which is using industry templates, but these only fit established business models like Telcos or Ad Agencies.
As our business model in the movie marketing industry was sufficiently different to everything existing, it was clear we would have to bend the limits of any COTS ERP so much that building it ourselves seemed like the saner option.
So we've dared to build our own multinational and fully integrated CRM and ERP system specifically for our industry and business model and so far, we really love the results (biggest client just saw our tooling stack and told us we're 10 years ahead of the ad agencies working in the same space).
But make no mistake, if you don't know exactly what you're doing (I have a slight background in finance, accounting and two failed SAP integrations), you're probably screwed one way or the other. I would recommend almost anyone to not build this kind of system from scratch.
Hyperbole. A lot of working with an ERP is developing middleware or custom modules that implement business-specific logic on top of an existing API and schema. It's like saying building a Facebook App is equivalent to rebuilding the entire Facebook Platform.
> So we've dared to build our own multinational and fully integrated CRM and ERP
I hear this all the time, and it's almost always wrong. Engineers and businesses are always convinced they're special and don't fit the mold. That's rarely the case, and the money used on these initiatives was probably better spent elsewhere. Usually when someone thinks they have some sort of special edge case or unique business, it's more often than not they don't understand GAAP/IFRS/IAS etc and how their finances can be modeled.
At the end of the day it's about capital investment. Either you believe you can do it better and you're willing to back it with money, or you realize it's not core to your business and buy something off the shelf because it delivers the best bang for the buck and more importantly lets you focus on other projects that are actually aligned with your business model.
> if you don't know exactly what you're doing
There's the caveat. You either find someone that's worked with ERP's for at least 20+ years, or you build your own over a decade and gain it 1st hand.
Indeed. It does, however, seem that these are developed on a system that isn't designed to intuitively express the degree of logic required - or even trivial logic. There are poor souls slogging through whichever level of hell uses SAP for customer relations, purely because that's the way it's done. That attitude worked out poorly for taxis, who's shitty UX was replaced by Uber.
I predict that millennials, who increasingly refuse to interact with anything below "app quality," won't bother with this horseshit. There will be fewer and fewer willing to subject themselves to that awful software, as developers, and everyone will build their own faulty but usable ERP systems.
ERP will be a unicorn in the next decade. The industry is ridden with complacent dinosaurs.
The poor souls are such because they usually fundamentally do not have the knowledge required across the broad spectrum of responsibilities an ERP does and how that all ties into managing a business.
> I predict that millennials, who increasingly refuse to interact with anything below "app quality,"
This makes no sense. What do millennials have to do with anything? I fail to see how a generation label makes any difference to how ERPs are involved in business management and how accounting and finance in general work. How supply chains are managed isn't going to change because of a bunch of woke millennials.
> everyone will build their own faulty but usable ERP systems.
Always said by people that do not understand what an ERP does and the complexities involved in managing a business. I used to think this way myself, until I actually had to deal with these issues in a senior management position with investors breathing down my neck. My naivety was amusing in hindsight.
Parent's point was that systems require trained and capable people.
If the job entails dealing with something arcane, and you can't pay more (because cost center), then at some point you face a labor gap.
https://documentlibrary.qad.com/documents/2370665/2368142/Da...
This is a product designed for small to medium sized businesses so it is not as comprehensive as a SAP. Take a serious look at the schema and imagine if you just had to write CRUD, it would take hundreds of man years. But it is not a CRUD app because there is business logic behind ever module.
Now imagine that there is also a whole ecosystem of vendors that sit under the QAD tree to provide niche solutions for the various use cases not covered by QAD. So not only do you have to write the ERP, but you have to write the pieces picked up by the other vendors in this ecosystem.
I mean surely there is a better way than thousands of database tables ... with separate business logic.
Do I understand correctly that for a "small to medium" business, they would only use a fraction of the functionality / database tables, but in order to support all potential "small to medium" businesses, it needs to be this convoluted mess?
https://www.pbookshop.com/media/catalog/product/cache/1/imag...
This thing will definitely hurt your foot if you drop it.
That seems like big statement given you have no context about the person making it.
I also work on a team that has built large potions of this intentionally and willingly. And the results have been great.
The reason is we don't hand off our business to a black box part way through our business process. We own it. Top to bottom.
This means when we change the products we sell, how we sell them and how we support them, we know the impact on our back office, reporting, invoicing and accounting systems. And vice versa
Yes owning the whole stack is expensive. But we also have parts of our company that rely on ERPs and other similar products.
I can tell you very clearly that our ability to develop products is an order of magnitude faster and cheaper than those relying on an ERP.
Seriously though, how do you envision a future where a leaner, better coded alternative appears?
Also honestly, why are you being so defensive about it.
If you are going to build your own ERP software, make sure that is the product your company is selling. The same goes for building a new 'web framework' for your web company. Never build a complex product from scratch if that isn't going to be your business. It never works out, because when you have to choose between revenue and improving something in your framework, you'll going to have to chose the former.
Years later, your company, if it is successful in doing what its supposed to do, is going to be paying big $ to retool and replace what you have built. The 2010s were the decade of teams replacing the custom shit they built in the 00s.
Exactly this.
At a prior startup years ago, I noticed that the accounting & finance team was always in the office late along with the engineers. I would ask them to show me the spreadsheets/models/forecasts they were working on and how it all worked because it seemed so important to the CEO & CFO.
I casually commented I could build this more effectively in code, and a half dozen people laughed at my joke. They then sat me down and showed me things like journal entries, how deferred revenue is managed or annual subscriptions are recognized. There were dozens of examples of scenarios that were completely unique from each other and required tools to allow them to capture these things and roll them up into a consistent P&L and income statement, balance sheet, and cash flow statements all adding up nicely.
And you realize that it's completely impossible for a company to capture all of this correctly "in flight", and things are going to be messy and wrong. ERP's have decades of experience capturing the nightmare that is actually managing a business and it's not sexy, but it works better than most alternatives.
which is easily made up for how condescending you get to be about it.
It's the other way around. It's totally irrelevant to re-invent the wheel and do something in a non-standard way.
> I’d rather my auditors had to hail their dreaded IT departments
That's not how auditing works. The point of GAAP is that things are done a certain way, and if you do things differently you need to provide that it isn't bullshit. Otherwise Enron & WorldCom all over again.
Hate to break it to you, but there’s other countries and other regimens out there.
> Hate to break it to you, but there’s other countries and other regimens out there.
Which country are you from that it doesn't have Generally Accepted Accounting Principles? Are you saying that in your country every company can make up what they want and the authorities are OK with that?
This is exactly expected and a desired outcome in a vast majority of scenarios. These jobs/roles are not snowflakes.
It's not a desired outcome at all.
The "not snowflakes" good people leave, and the ossified ones who really just keep their head above water and need the job, are what you have to deal with. And they have the exact same attitude to succumb to the system or else you're SOL.
I really truly think you do not understand.
It's rare but I know from first hand experience that it can be different.
Totally. My clearly poorly researched comment and seemingly lack of knowledge on the subject clearly reveals me as a fraud. You got me.
You've been sending replies to my old comments for the past THREE DAYS, and then editing and deleting them. I got "HN Replies" enabled so they do end up in my mailbox even if you edit or delete them shortly after. So I do get to see EVERY TIME you wrote me in the past couple of days that you believe I am "not qualified to have an opinion. full stop". No discussion, no arguments, not even trying to engage what I said, just attacks telling me over and over how much better you understand SAP. Just attacks or stating your credentials. Which is no discussion but I don't care any more, I want you to knock it off, now.
At this point I honestly don't care what your opinion is on ERP, that you're the Queen of SAP, or whether you think I get to have an opinion or not. You deleted that remark, but it was the straw. I just want to cease communicating with you, which I did from my end already nearly a week ago.
Now I understand when sometimes people post while in a bad mood, causing them to post things they regret. And if you delete those messages, then that is fine with me. But what I'm a little bit worried about, is that I got to wake up to a new reply from you, telling me how stupid I am and that I don't deserve to have an opinion, for the past THREE DAYS. That's not a bad mood. And I don't care what it is. Just let it go, alright?
Please don't reply to this comment with anything less than an apology.
Here is the interesting excerpt on Google decision to buy Oracle instead of building their own ERP.
"__ How did you convince them that you needed to do this? __
Well, it was actually very interesting. Larry and Sergey suggested that we should build our own, because most of the existing accounting systems weren't any good. And I said, "I'm sure that's true, but you'll never get it audited," And I thought that was a pretty clever argument. The auditors would never pass financials (generated out of software) that we built ourselves. And Larry and Sergey today will complain about the Oracle system, but they'll also say "We had to get one that was auditable.""
This was my hardest lesson to learn. Code is only as good as the domain knowledge going into it. I love games because the domain is more often than not in the realm of fellow programmers and erudites like mathematicians and 3D animators that capture their domain knowledge in physics, sound effects, motion capture, fluid dynamics, FSM AI, or combining geometric and linear algebra to improve gimbal lock.
An ERP on the other hand captures the domain of accounting, finance, procurement, manufacturing (bills of material), order management, taxes, product lifecycle management, and other considerably less sexy but equally important subjects.
let me guess, they did not captured/predicted the domain knowledge required to run the following business huh: - search engine (google) - marketplace for arranging or offering lodging ( airbnb ) - ride sharing ( uber ) - social networks (twitter/facebook)
if all businesses does everything the same way (because some german company thinks it is), all end-products will look all the same. The same way if all chefs is following the same recipe.
IMHO the tools/choices to send invoice, manage orders, product lifecycle can also be a differentiator for your business.
It's more like chefs using the same kitchen appliances, pots, pans and equipment as everyone else. And they do. You use a Salamander Broiler because it does the job.
Tesla makes hell of a great cars.
“excellent corporate governance” could be rather irrelevant.
I don't know what many of the terms mean you name, and I severely doubt that every business (or most) does. Doesn't mean they're not important, but most definitely just firing off a bunch of random terms fully expecting people not to understand most of them, is a weak way to prove a point.
I have seen however on the consumer side what happens when businesses "changes the business" to fit a particular piece of business planning software that is "Hideous. hideous". You're working with nice people, well-meaning people, doing their best for you the customer. And it everything well for a while and you place your trust in them. But then walls appear. And appointments get rescheduled. And they want to help you but they can't. Some people leave, a particular kind of person stays. Communication between peers grinds to a halt. If something goes wrong, they can't pick it up so it falls on you the customer to deal with or reschedule (or other inconvenience), every time. You want to get angry at the people, but you also see they are so very much doing their best, but something is holding them back. A particular kind of person is particularly good at merely keeping their head above water and not suffer the burnout many of their ex-colleagues did.
I'm not saying that it can't work well. I bet it's great when it works well. But when it doesn't it's a silent killer.
If you agree on all those points, why do you teach it?
That is my goto advice on buy vs build. If you buy, then you should be willing to change your business to fit. Otherwise you should build. The more you resist changing your business the more you should build. The more you don't want to build, the more you should be willing to adapt.
Years of consolidated competitive advantage went down the drain.
That's because it's not code for running your business, it's code to write code for running your business. So you have two obvious problems here. First is all the shortcuts made by SAP to get something out the door to customers. Second is all the shortcuts your business used on top of SAP to get things out the door. This is a pattern that can easily create a huge mess. I've experienced this working on a product in a similar space to SAP in the past.
Second thing: I don't find working with SAP too hard. One of the tricks is to work out how to keep SAP as out of scope as possible during the discovery phase using existing functionality or workarounds (that don't impact on sap as the source of truth).
It's free for teachers (and students), you can get boxes here: https://odoo.com/scaleup
I haven't used it in 13.5 years but when was at DHS as a contractor we used it. Fully agree, it was a steaming pile and made made my job unnecessarily difficult.
But I went from it to being in AS400/BlueZone at the next job (my current job) though so... yeah... actually my email was in AS400 from 2006-2009ish... yeah.
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...
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.
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.
I learned ABAP in a literally one weekend and was able to make stuff really quickly. For the most part, you could just "loop at <giant_table_name>" extract what you want and show it on a screen using one of their existing ui components. There was not much UI to worry about and you know the user is getting a proper input box (for example) with a working typeahead. Honestly, I thought it was a very decent developer experience. I could focus on what I needed to do and not worry about how pretty the thing looks or if I'm querying the database optimally. I ended up writing a very complex genetic algorithm implementation to calculate optimal schedules and it was a joy.
Yes, the table names were basically in german, and abbreviated, and most things were only 8 chars long for some legacy reasons, but it really wasn't that hard to learn that VBAK was sales_orders and VBAP was sales_order_items and move on.
For the most part, the users were totally fine with SAP. It was hyper-focused for the tasks they needed. It was consistent and easily documentable. It didn't crash, it loaded super fast, it didn't eat up gigs of memory. You just load up the gui application and you don't even need a mouse once you know the shortcuts.
Having spent the last 10 years building web and mobile apps, working with salesforce and others, I miss ABAP very often.
ABAP will always hold a special, quirky little place in my heart. It's very powerful, but also totally frustrating. The language is a COBOL-like language made by Germans with a keyword graveyard as big as Berlin. The ABAP community (in my experience, online and offline) is totally unacademic: algorithmic complexity is a foreign concept, "code clarity" meant "hitting the Pretty Printer button every few years" (which was a nice feature), and there's no remote concept of best practices.
On the bright side, it makes for a good income, and the debugger is a gem.
The only advantage that I see is that for the most part, every program will look almost the same regarding standard SAP tables.
Feel free to share any other thoughts on the matter
For parent maybe this would be interesting: https://open.sap.com/courses/cp7
It's easy to get into, much smaller system in both scope and complexity, and tons of free documentation. Get a couple of certifications, do the trailhead stuff, contact some consulting firms to tell them you're available for work and it should be easy to find work.
Getting into SAP and finding work can be challenging. They have a lot of new things from what I see but the majority of the SAP work you'll find is old non-cloud stuff that you'll basically need to have worked with at a company before to learn.
I went from SAP dev inhouse -> SAP dev consulting then jumped on the Salesforce wagon around 2011.
SAP work was enjoyable to me, partly because I was working in the manufacturing space, which I found interesting. Software-wise, it felt like I was 20 years behind everything, working on a mainframe.
Salesforce, I just immediately hated. It was just limits after limits and some crappy java-like language and html templating that took forever to deploy. It's gotten a bit better with lightning but you'll see the shit underneath pretty quickly. I also found the projects also extremely boring. Going from controlling machines and automated warehouses with SAP to projects about collecting email addresses and creating contacts felt like I made the wrong move.
tldr -- avoid getting locked into proprietary-land if you can help it
All in all though Salesforce is pretty accessible for learning. Plenty of resources out there, and I know SF consultants make nice money.
No offense, but this is probably a big reason for the perception that SAP is a giant slow resource hog. Developers are abstracted so far away from the hardware that they have no way of knowing that their simple little program is resulting in 1500 database queries per page load.
A piece of software that plays (at least) one sound on every user action, and the sounds are completely arbitrary and 8bit at best.
Where you have to press 5 buttons in a row to do the one thing it's meant to do.
Where you have an angry fruit salad in a time sheet.
A piece of software that takes 30 minutes to enter your worksheet time. And lets you enter a special opex code for using it.
I felt the anger and hate of the man who coded it and every Friday I felt I knew that man better than anyone else I have ever known.
I've worked places that have SAP, Oracle, and one place that had both. I've never personally used SAP, and rarely dealt with Oracle.
I would be curious though, if it makes that many sounds - how much error checking is done because something "didn't sound right"? Does doing business tasks sort of turn into a song, with an expected sequence of sounds which feels wrong when not executed correctly?
If I'm typing and talking to someone at the same time, I intuitively know "I typed f rather than g, quick backspace and keep going". Do people internalize the pattern of noises they should hear while completing their work?
The next step should be to have a database of standardised, free and open source sounds that can be used by any program, so that the same sound means roughly the same thing across all of them (assuming that this feature is not patent-encumbered).
Perhaps they should main for the larger market of making it accessible to sighted people first.
There are no words for how terrible the interface is. It is purely mouse driven and this is in no way a feature that increases accessibility to blind people.
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.
- Almost all meetings I've been in start with prospective clients mentioning to SAP consultants that SAP has a 'certain reputation'. The SAP consultants acknowledge this.
- Some of the solution pitch ideas they come up with signal they have almost zero knowledge of how some technologies actually work.
- Services we rely on with SAP frequently fail for no apparent reason.
- They are slow and uncooperative with setting up demo environments and responding to support requests.
- Their licences and consulting fees are outrageously expensive considering the lack of quality and performance when compared to alternatives.
- Tech leads in our own company frequently talk about how bad SAP solutions are.
- Their poor UIs are what they are known for in the market. They've tried to address this with things like UI5, Fiori and Fundamentals which feel like too little too late.
- Their attempts at acquiring startups (AI, chatbots, analytics etc) to stay on the edge provide hardly any real value besides propping up the credibility of the buzzwords they cram into their presentations.
Yet SAP remain entrenched in the market and companies still get into bed with them despite knowing the pain they're in for. A lot of system integration companies have tried to attack this market with open source solutions and have failed to make any real dent. The only major player that has started to eat SAPs lunch recently is Salesforce.
Perhaps I'm missing something but surely it would be better for an organisation to have a solution that can be maintained by more than one company so that the company can be replaced if they aren't performing?
The only example I can think of where this is being addressed is the UK's GDS Service Standard which mandates that all government projects should use open source tools to avoid vendor lock-in. It really is perplexing how SAP still maintains its position in today's market.
Kind of like lemmings jumping the cliff.
If these people work at a firm like Accenture that just outsources the technical challenge, coding skills become completely unnecessary.
Also, a ton of the industry is built around the risk of something unexpected happening after you push the button (as mentioned below) and distributing blame if the end-result isn't precisely what customers anticipated (the old "Nobody gets fired for buying IBM" adage)
It may seem backwards to people outside of giant organizations, but it is a necessary aspect of modern business (and there are tons of industries that make more money while generating less value for society).
Many times what is needed is to let go of a sensible technical approach and just help the organization go where it is trying to go. It may not make sense technically, but it makes sense to the org, and that sort of matters more. I find my knowledge of good architecture often just makes it more painful to watch the code go through the inevitable logjams, rewrites, and process failures that are a crucial part of an organization “feeling” it’s way through a very complex multi-dimensional domain that includes many considerations that have nothing to do with code.
I think in many ways, people with less technical skills can do that better, to live in the meta space.
My brain keeps getting dragged down into the “why can’t we just do the sensible, minimal, technically correct thing that needs to happen for this problem to go away”. But the answer is “because the org doesn’t see the problem the way you do”.
What good is it if I can solve problems no one else in the organization even recognizes as problems?
And yes SAP is bad but it is also something that will do most stuff you need to do and follow the right laws when you do it.
What do you see as the alternatives?
And a hundred other specialised systems which fit their niche markets. Not everyone needs a full stack ERP/FSM/CRM solution, their are almost as many players as variations in requirements.
The implementation of any ERP system is bound to be extremely painful. It’s big and complex and involves lots of change.
You might as well pick one of the undisputed market leaders rather than have all that pain attributed to your decision to go with a niche player.
I'm not as familiar with SalesForce, but I think it has a similar stake by focusing on CRM. If you start at the customer data, you can influence the profit centers and influence a company that way.
I mostly mention these success stories to say that a Goliath like SAP won't be taken down by one David, but by a ton of ankle-biters eating their lunch. Maybe these ankle-biters will be easily replaceable, but I wonder what an organization where Enterprise Software is constantly hot-swapped will look like, given how inefficient Application Retirement projects can be.
The Industrial Plant I work at uses Service Now (For IT and Helpdesk support) and SAP (For Payroll, HR, Purchasing, Maintenance Scheduling etc.). Service Now is much, much worse. IT department is so dysfunctional and Service Now is a big part of that.
One of my coworkers refers to it as "Service Eventually"
Nowhere I've worked that used ServiceNow encouraged solving practical problems with it. A grand total of once I took a crack at something that would have been trivial if Sumologic could alert to ServiceNow. It became hilariously obvious in 3 or 4 back and forth emails with the gatekeepers that their 3 month testing process, 45 emails, and 16 meetings requirement for a one line change was not cost effective.
My time was better spent crafting an email forwarding rule that sent the related conversations to the trash and moving on to solvable problems.
For example, they had their own language that abstracts and operates directly over a database. They had their own drag and drop UI builder, that compiles down to a HTML page or a desktop widget - which is again not an ordinary feat. They view code as data, as in even the UI is stored as a configuration and not as some Java code. They had their own VCS back when Git didn’t exist. Of course, all these weren’t best of their class, but they sure did get there ideas right.
All these must have been interesting engineering concepts back during its time, yet there hasn’t been much tech literature on how they accomplished it or what inspired them to. At least not that I know of.
Now that open source is on fire, of course a single company cannot catch up with the pace these open source softwares are racing ahead.
Companies like Zoho and Salesforce are able to catch up because they do two things right.
#1. Cloud
#2. Adopting open-source and making a clever mix of proprietary engineering
The next SAP or Oracle will certainly be companies that get those two things right.
SAP right now is making a move on cloud using SCP and as open source goes, openUI5 exists.
I don't have much to say about SCP, just that the company I'm on decided to not use it, basically because we don't see advantages and to avoid future lock-ins
About openUI5, I honestly dislike it, the most useful features of that framework are locked inside SAPUI5(a supersetof openUI5) and pull requests are managed by a branch of the company itself and they are pretty harsh on it. SAP documentation on it can be bad and is entirely biased towards deploying things inside SAP or SCP, which is pretty annoying
It was the third time the company tried to implement SAP's products. I think I may have been one of the very few people who worked on all three attempts. The winning recipe was having a business owner who threw up his hands at the failed efforts to get a larger scoped company-wide project underway and "selfishly" declared that the finance dept would do it for its own benefits. And he tooks his best people out of their day jobs, put them on the project team, and made them move offices to sit in the same open plan war-rooms as the IT staff (which took some doing...Microsoft was pretty much all unshared private offices at that time) I think we reduced the time it took to "close the books" each month from something like 3 weeks to under one week.
And we absolutely changed the business to meet the way the software worked, that's one of the key success factors for implementing any ERP software. Your "unique requirements" for fixed assets accounting and accounts payable processes are not what makes your company successful, but they are what will tank your ERP implementation if you let them.
It was a fascinating project. I especially enjoyed some of the travel to implement it in the subsidiaries, where the really big business wins were. Most of the subs didn't even have a "purchase order" process (they just paid invoices, and had no idea of their outstanding commitments) or any automation around things like employee expense reports. And we got to come up with some decent creative solutions to things like Brazil's requirements for hyperinflationary accounting, without breaking the software.
Fun fact, Concur's expense reporting business was borne out of the Microsoft R/3 implementation -- some of the best consultants and developers took what they built for Microsoft's internal expense reporting and turned it into Concur's expense reporting product.
* "[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.
I would love to see a Valley solution to the problem of sourcing raw materials including energy, storing raw materials, sourcing packaging, storing packaging, sourcing machine parts, storing machine parts, keeping track of vendors, machine maintenance labor, machine maintenance scheduling, cost accounting for the inputs, manufacturing and machine schedule management, demand forecasting, supply & replenishment planning, WIP inventory management, finished goods inventory management, inventory accounting, sourcing shipping, planning shipping, actually shipping, invoicing, printing invoices, printing all documents (manifest, bills of lading), extending credit, managing credit lines.....
oh yeah accepting purchase orders, making to order, promising inventory, managing inventory allocation in tight markets, managing in transit inventory, collecting payment, transferring cash, reporting all of this to the SEC and IRS so you don't get sued, remitting taxes, managing headcount, paying employees....
I probably forgot a lot of stuff and this is only for domestic sales. Export has so many other problems to solve like tariffs and duties, container management on the dock, steamship management, etc.
I'm not being sarcastic either, I would LOVE to see a solution that has a better UX than SAP that solves all of these problems.
For example, I know the tale of a large multinational consumer goods company who bought their supplier for X. Coincidentally, the X supplier was also the largest exporter of X goods to the world and had a team of twelve who managed operations. The multinational company, in their great wisdom, decided to move the operations from what we Turks call "bakkal defteri" (basically pen and paper) to SAP. It turns out that twelve people were not enough to run the system over SAP, and they basically had to tenfold the number of operations people just to get it running.
The answer is pretty simple actually. You make a couple of billions a year. Invest a single billion in a full UX revamp for 5 years down the line, and see how it all works out.
Throwing money at problems doesn't always work, but when you have a lot of money, and a very specific problem, it tends to work.
SAP's selling point is regulatory compliance and financial control. It doesn't matter if you have a great UX or lightweight extensible third party API ecosystem, what matters is "When the IRS / SEC / Congress / Interpol comes calling, am I clear?"
Government regulation is the ultimate "vendor lock-in" and SAP exploits that fact.
The everyday end-user of SAP software isn't the one it's designed for. It's designed for lawyers and accountants who need to organize data quickly when the shit hits the fan.
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).
So, we spent 6 months or so building a front-end that the users wouldn't refuse to touch. HTML5, responsive, attractive, flexible. I mostly worked on the toolkit side of the project to try and keep UIs vaguely standard across the multitude of screens.
And alongside us, the two highest paid contractors I've ever worked with (who seemed to be earning their money), were building what amounted to SQL stored procedures that went into a tool that let them be interfaced as REST APIs. The article talks about the amount to which businesses have to mash themselves around how SAP works - from what I saw and heard, that was even after they'd spent more customising SAP than I would expect to bill to have built very large parts of it from scratch.
So yes. I'm sure that, at a really large corporate scale, SAP has its advantages to organisations. But in a 20 year career it's probably my least favourite technology, including the email server which you could misconfigure so receiving an email would bring down the whole machine. I wouldn't be remotely surprised to see SAP disrupted into oblivion, and a bit of me would love to be part of the disruption.
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.
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.
https://www.canadianbusiness.com/the-last-days-of-target-can...
Seems to me SAP is ripe for disruption, but it would be a very challenging throne to unseat.
Business is a wild world of so many ways to structure the org down from workflows to departments which is basically the only thing that differentiates a large majority of businesses these days.
Sure, you could enforce a single cookie cutter approach for everyone, but then, how is corp A any different B anymore when everything is identical besides the people itself, heck their costs should equalize as they should in theory have the same workflow optimizations and inefficiencies.
This is an entire category of software. Closer to most of our homes, see "bug tracking software", "web frameworks" (frontend or backend), or "programming languages". Countless examples of someone getting frustrated and starting a "lightweight alternative", gets lots of attention, gets lots of customers who find various issues and features get added to address them, and before you know it, 5-10 years later, the "lightweight alternative" has become the monster the next generation of "lightweight alternatives" are being started up against.
I'm actually at the point where I consider advertising something as a "lightweight alternative" to be nearly a strike against one of those things; it likely means the author doesn't understand how the previous things got to where they are and are just going to follow them down the same road. If you've got a coherent story on how to address that, talk directly to that.
Of course, if you're a new bug tracker/framework/language author, you'd probably rather get the numbers you can get from advertising "lightweight!" rather than the smaller numbers you'll get from advertising "we're going to contain complexity by an aggressive modularization system based on the principles of ...".
The amount of good money thrown after bad on Kickstarter shows the money has no idea what it's investing in.
JSON disrupted XML. There really are ways it's strictly less capable.
https://www.cio.com/article/2429865/enterprise-resource-plan...
Given Target's original system didn't have a multi-currency approach or use UTF8, my guess is the implementer (in this case Target) is also part of the problem.
It is hard to disrupt this type of software as migration involves migrating data, which is hard, in addition to changing a lot of employee workflows. Potentially, if something like 3D printing of metal parts took off, it could mean a new type of ERP system would be necessary, allowing for a new player to come in.
I've had to use it at EU big corp, and it to this day the worst experience I had.
I've seen at techcrunch Berlin 2019 that there is something called SAP.io, somewhat opening its plateform ?
It's still hell, just a different kind of hell.
Bespoke is a genuine competitor. In the UK it's not uncommon for SAP implementations to cost several million £s, this could be used to build bespoke software.
There's a massive risk here though - there are thousands of ways bespoke ERP can go wrong. Underfunding the project causes problems, but arguably the worst projects were overfunded. Then there's recruiting the right people and developing the right culture - archaic business hierarchies are almost mutually exclusive with good software teams.
In other words, there isn't really a very good option. You can understand why business leaders, who are often not technology experts, would go with something that has 'worked' for them in the past.
Out of the box, probably nothing. Something that supports all features you will actually want to use? That depends on who you are and what you actually need to do but, then, you'll need to figure out what you want, what you need and what is available on the market. This assessment is, in itself, quite costly.
In short, it’s seen as a safe option, because it’s what “everyone else” uses, and the decision makers have typically come from businesses where SAP has been used.
Nobody actually likes it - but they don’t see any alternatives as viable.
Similarly, I’ve seen folks migrate to and from the various MS Dynamics platforms, and it’s a universal shitshow, with the exact same reasoning, just a different tribe.
ERP software generally sucks, as it has to be all things to all men, ends up customised to meet needs which are obsolete by the time the customisation is complete, and it usually either gets to the point where nobody understands any of how it got to be the monster that it is, and a long and painful replatforming happens, and the cycle begins again - either with a new supplier or a new version of the same old.
The question isn't whether it "sucks" or not, but rather to whom it "sucks".
It rightly reads as sucking to us as tech-savvy developers, but that's not the reality for the actual consumers of such products who are not programmers. To them, irregardless of our protests of inefficiency or bloat, there are only 2-3 possible platforms and the competitive advantages of each over the others are judged on entirely different criteria than we would use.
Remember the first rule of design (for better or only in this particle case, almost certainly worse): you do not represent your users.
It sucks to the people who has to use it and maintain it. It doesn't suck for the people who sign the checks that pay for the licenses and the hardware to run it.
Any company who is looking at SAP is likely doing business in the US - Sarbanes-Oxley means CFO and CEO have to personally sign off on the financial accounts and are criminally liable (am sure it's the same in other countries).
SAP at it's core is all about financial control. SAP sell SAP to CEOs and CFOs by telling them it will provide strict financial controls to their company and avoid them personally going to jail / paying huge fines. It's an easy sell
If you didn't have it a lot of money disappears without a trace.
No. SAP.io is how SAP thinks it can hit long arc innovations. It runs accelerators for „entrepreneurs within SAP“ who would otherwise have no chance against corporatized SAP.
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.
We used SAP for our incoming orders. Each order was printed on paper as some kind of report from SAP and put in our physical inbox. When we had manufactured buttons for an order, we would go to a desk with two computers, both logged in to SAP. With the first computer we would scan a barcode from the order to find it in the system, mark the order as done, and print a second paper containing the order.
Then we would proceed to the next computer, scanning a barcode from the second paper, and produce a freight order for the outgoing warehouse. This was printed to a third paper, and attached to the buttons, before they went to the outgoing warehouse.
Note that the freight order did not work as a waybill, so the process of shifting paper was probably conducted a couple of more times before the order reached the customer.
For someone really used to working with computers and not against them, it seemed rather innovative to print a paper to transfer an order to another computer two feet away. It was a learning experience and greatly motivated me to go get some higher education.
If it was filed, my guess was that it was an internal control measure. They wanted to make sure there was a paper copy of every transaction for audit purposes, and what better way to make sure of that then requiring the paper to move the order forward?
If you tossed it, then it sounds like they were just too lazy to implement something other than the default config. :)
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.
That observation aside does anyone know who writes or customises the SAP NetWeaver for Windows programs ? Is that the function of a highly paid consultant somewhere ? I have seen a few of these in different places and the common factor is they always look like they were written in Visual Basic circa 1992. The one I use makes the same beeping sound if a transaction fails as it does if it succeeds. If the transaction fails this is signalled by status box text saying so in a green font but if it succeeds then text says that in a red font. It takes a special mind to come up with that !
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.
[1] https://www.qlik.com/us/sap-analytics/sap-data-replication
Kafka can be useful for more than staging reporting data. This pattern is more about separation from core ERP (and core ERP bureaucracy) vs. ERP reporting.
I searched on Google, "What is SAP?" Here are the top three links as of today:
1) https://www.sap.com 2) https://www.guru99.com/what-is-sap-definition-of-sap-erp-sof... 3) https://en.wikipedia.org/wiki/SAP_ERP
What do you notice among the top three links? All of them are mostly talking from business-speak perspective. For a software engineer learning about SAP for the first time, all I want to know is what does SAP literally do? The top three links do not have screenshots of the software, do not simply explain the technical capabilities of SAP, and do not explain how SAP differs from competing products.
Although I never interact with SAP daily, I have always been curious about what it does, but did not want to waste a lot of time on Google searching for a real explanation. Hence, to have a section like "What ERP software actually looks like" in the parent link fulfills a certain desire to know SAP that I have had in the back of my mind.
To some extent, I can blame laziness on my part—in that I have not researched enough about SAP, but why should it be this hard for a software engineer to learn about another piece of software? This is why sometimes, it is better to have a neutral party (non-SAP affiliated) to explain a product, rather than SAP itself.
Anyway, we needed to integrate with SAP on occasion, partly because one of our biggest clients was in the middle of a HUGE SAP rollout, employing a small army of Arthur Andersen MBAs, etc.
So I went to the SAP technical education conference in Atlanta, to gather info and whatnot. I heard Hasso Platner brag from the stage in the keynote that complaints about SAP's complexity and expense were entirely overblown because "80% of our implementations now take less than 18 months, and come in under $100 million."
Y I K E S.
(Oh, and the company with the SAP rollout we were working with? Eventually, the combined cancer of SAP and AA billing destabilized them enough that agreed to be acquired by their biggest competitor. Yay SAP!)
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.
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 started working as an engineer in 1997. Every other day I would receive an email saying "SAP is down, IT is working to resolve the issue."
This continued at my job in 2005.
Last week I got an email from IT saying "SAP is down."
I still don't know what it does or really care but it sure is down a lot.
As bad as I'm sure SAP is to deal with, I crave it or anything else (Salesforce?) that has any sort of easy customization, automation API and fosters some sort of community.
A large part of my particular ERP's business model seems to be to make the data model so esoteric that you are forced to go to them for any type of customization at all. Unfortunately, they make a habit of firing any of their halfway decent employees every time they get acquired (4 or 5 times so far).
They just don't want you to plug anything of your own into it.
https://www.google.com/maps/place/49%C2%B018'00.0%22N+8%C2%B...
Oddly others thought it was great and accepted it taking 30 seconds to load a report (yes, it's just a few database queries with the output put onto a canvas...) but I think that was because they didn't understand how basic it should be, and knew no alternative (of which there was none!).
I ended up writing my own report system as I detested this so much.
Can you clear up on „several“? Are these SME or LEs? Names?
I would say we sign a 1000+ employee corporationn every month. Example, in Portugal we replaced 150 legacy proprietary software in 3 years: https://joinup.ec.europa.eu/collection/open-source-observato...
More case studies here:
SAP's success can be attributed to something similar to what Facebook and Google did, locking the data and knowledge base to itself. The much bragged "extensibility" is limited to SAP own software modules or will be acquired.
Therefore the extensibility is both the strength and the weakest point of SAP. Unlike most of modern software system, there isn't an open ecosystem for competition at its periphery, resulted in a lackluster UI and unfair challenges to non-SAP software to take advantage of those domain knowledge buried inside the SAP.
SAP's integration doctrine is originated from 1960-1970s. With limit evolution this doctrine has largely ignored the changes in computing for several decades, yet it's still growing its dominance.
I say this as someone who has no experience whatsoever with ERP. But the entire concept seems like an anti-pattern. A kludge that's only necessary when your org lacks basic technical competence.
Why does everything need to be in a single monolithic system? Does HR really need to run on the same database and software as the manufacturing plant? Haven't we learned that small modular, independent systems with well-defined interfaces at the system boundary work. If for some reason manufacturing needs to talk to purchasing, why can't they just do so over JSON/HTTP endpoints or a Kafka message bus or even direct SQL connections? Trying to integrate by just locking everyone together into a single system that tries to be all things to all people sounds like a recipe for disaster.
But, again I don't really have any direct experience with ERP. So that's why I'm really curious what orgs that are actually technically competent do. If Google or Amazon or Netflix was using ERP, despite having the engineering firepower to build alternative systems, then I'd really think that there's something important to the concept that I'm missing.
Goldratt was critical of ERP systems, not because they couldn't bring benefit; rather, because many businesses adopted through a cargo cult mentality and viewed them as magical silver bullets. Many companies never understood where their bottlenecks were (Theory of Constraints) and would make things worse with an ERP system, with some going bankrupt.
An ERP is usually sold directly into the office of the CEO. Any ERP startup hoping to get a foothold must have a founder or head of sales with a rolodex full of CEOs. Folks with CEOs in their rolodexes tend to not have the type of risk-tolerance required to go all-in on a startup.
To me this raises two key questions:
1. Isn't this harmful/limiting for your enterprise in the long run?
2. How can you at some point migrate away from SAP once you adapted to it?
Given these issues and the huge costs, why would it make sense to adopt it in the first place? At least in the year 2020 (maybe the situation was different decades ago).
The closer you stick to "out the box" ERP the more chance you actually have of moving off of it in the future.
Any ERP consulting house worth their fee will know how to move customers from one standard ERP system to their own/another. The difficulties come when you heavily modify your ERP solution to fit your business rather then follow the advice given.
This is where the tender process and requirements will bog down, developers need to be hired or entire business processes need to be rediscovered and rewitten. Since an ERP move might only happen once every 10/15/20 years a lot of business will use the project as an opportunity to reshape business processes, removing a lot of legacy stuff which no longer makes sense.
Interesting. But it still limits you to moving from ERP to another I guess.
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!
In one study after another, workers failed
to give much weight to decor in choosing,
for instance, among variously colored panels
and fixtures.
If you ask specifically about noise, privacy
and table and counter space, though,
[...] matter a lot.
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.
Disclaimer: I am a working student at SAP
(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. :) )
This is quite a limited view of our industry. I'd agree that young coders focused on the startup community may not have seen it. But it is pervasive in the enterprise world. By all means, pick it apart, analyze its strengths and weaknesses, and compete/disrupt. But pretending it is some unknown thing shows a lack of understanding of a significant market segment.
I am a bit of a maverick in that sort of environment, though. I wrote a JSON encoder [1] to ship PeopleCode objects to the browser via these webscript endpoints you could make in order to use modern web technologies. PeopleSoft actually moved in that exact same direction years later with better JSON support, 'FluidUI', and better html5/javascript support.
ERP systems are hell to work with. It was fun, but ultimately I was glad to get back to the real world. I got back to my main interest C#, but then went fully into the Clojure world :).
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.
Business decisions are usually made on exports in third party tools (Excel, Tableau...). Why is not disrupted yet then? For me it’s the same as Oracle for database engines and IBM mainframes: enterprise sales process and trust in proved decades solutions when you you bet your whole business in a software or hardware solution.
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.
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.
Infact in certain cases I would imagine that an in-house solution with maintenance etc would be more cost efficient.
When Larry starts to mention a market it is a signal is innovation can be expected from his competitors. AWS Aurora, Google Cloud Spanner that are competing with Oracle legacy solutions.
How much product/inventory/sales/etc... processes is required before you should move from FMP to something like SAP?
Is it number of users, client accounts, employees, products? What is the break point for needing ERP (Enterprise Resource Planning) software?
I'm so glad that I now work with NetSuite!
However, due to their entrenchment in various other markets (and who knows if there is any graft or other under-the-table business going on), they continue to manage to exist, and scary enough sell their products to new victims (ahem - customers).
SAP is the old-is-new-again-we're-IBM type of business; nobody ever got fired for buying SAP (but the golden parachute was nice)?
Ok - hyperbole and I don't really know what I'm talking about, so the above should probably be ignored...
...that said - I don't think I'm too far off, either.
Yes, software built form scratch can also be messy, but which is the lesser evil?
Hard to imagine even getting to that point
My experience with the application was limited mostly to expense report submissions and for that simple task, it was abysmal. It was so bad that it was hard not to conclude that it was chosen due to its horribleness: making employees think twice about sending in expense reports. And we did. If it was a small dollar amount, the time cost exceeded the monetary cost.
The UI, at the time (2005...ish), actually looked pretty slick compared to most web-based tools. It stopped there. Date fields, upon clicking, reloaded the whole page (which you waited for), to display a pop-up calendar, which when the date was clicked, reloaded the whole page. At least once while filling in the expense reports myriad of screens, the page would fail to load and you'd have to hit the refresh button, or you'd make a mistake and need to go back. Clicking any of the usual buttons in the browser for those functions invariably lead to an account DoS feature.
I don't remember the details, but it basically caused the system to get confused into thinking there were two of you and it gave priority to the "you" living in the alternate universe where you didn't click "Back" or "Refresh" and were still filling out your expense report. You had to wait for the first session to time out before you could continue, and the error message you received was placed in the "status bar" and appeared to be the name of a const variable "APP_BOWEL_MVMT_ERR" that gave no hint as to what the fsck was wrong. There was admin "unlock" feature (help desk calls were met with "just sit tight"). So you would give up and forget to return 3 hours later. A few days of this and the expense deadline passed.
There wasn't a more hated "enterprise tool" in our shop and we ran every single one of Microsoft's early attempts at web-ifying the world (early Sharepoint is the only I recall, but we had others).
It was decided to shelve it after a last-ditch effort was made to fix it. We'd put a job opening up to get a solid SAP developer and got ... someone ... after bumping the salary up several times. The rumor is that the gentleman we hired was the highest paid developer at the company. He lasted 3 months before taking a job at IBM at a substantially higher salary. A look at his job history and the circumstances surrounding it made it not unreasonable to conclude that we weren't the job he was ever interested in and talking to other SAP folks ... this sounded extremely common. The joke was "if you have to work with that crap, it better pay well".
We finally ditched it when we were acquired by another telecom; while most of the choices "our side"'s IT made were fought for, nobody advocated for keeping SAP ... even having no idea of what the acquiring company was using -- we knew if it wasn't SAP, it had to be better. It was Oracle; and it might be the only time I've heard a colleague speak positively about "Oracle" outside of The Matrix[1].
[0] Time sheet software always comes to mind. Nobody likes doing "time sheets" at any job I've ever had, but at every company I've ever worked for, we've had a home-grown time tracking tool. 30,000 employees to 100 employees. Every. Single. Company. It's such a necessary "evil" that even at those places where executives had known deadly-allergic reactions to building anything in-house, somehow a case was able to be made to build a completely custom time tracking tool tailored precisely to the businesses perceived needs. Death, taxes and time sheets, I guess.
[1] My experience with Oracle up to that point was Sun's acquisition and a perception-backed-by-coincidence that when the Oracle sales guys couldn't land a deal, their software auditors would step in to give the necessary motivation.
wonder how they have calculated that
Couldn't fine a date in the post, but it does say:
> It’s 2019, and SAP is ...
In the very last paragraph of the article they then say "...on the back-end, most modern enterprise software (e.g. Salesforce, Jira, etc.) now have good APIs for exporting data. ETL + data lakes are on the rise...".
This is a mistake I see made a lot; not because of naivete tho': usually because the concerns cut across each other so much.
The economic and efficiency incentives around integration are very delicate. SAP is so complex that (assuming you can hire great engineers, which isn't necessarily a given outside the tech sector) you can probably build most of what you need with a small team that's much cheaper than SAP. However, you can't successfully (even with good access to great tech sector talent) grow that software as quickly or as broadly as what you'd get from SAP. You also carry a lot more risk. ...and that's risk outside of the core focus of your business. The article even includes one quote, "competitive advantage in this industry might just come from doing the best and cheapest job at implementing SAP." which recognises this as an operational rather than capital problem.
...but even if you can accomplish it, it's the integration that gives you the value. You're always going to have higher operational costs for your thing if you build it out of something like Salesforce and Jira sewn together with APIs. ETL is hard to do well for anything other than reporting (and even then it's not easy). Data lakes are the epitome of loosely integrated data structures. Most of the time they're a collection of files full of data in weakly-or-stringly typed formats such as CSV, JSON and XML. Getting at the domain models of the producing software is always a pain. For all these things, your talent pool for effective support is small and gets smaller as you add more products to the mix.
So the three options are:
1) Buy (+ professional services)
2) Build
3) Integrate (e.g. "Salesforce + Jira")
3 (Integrate) is the mistake because it's less than the sum of it's parts. You carry all the risk of "Build" and don't get the brand stability and integration of "Buy". Multiple vendors gives you more risk than a single one in this scenario because you're buying different things from different vendors. So now you have more chances for failure: failure or withdrawal of one of the vendors, API changes that you don't control, etc, etc.
As the SaaS markets become more mature I'd hope to see consortiums of vendors who had products that they would certify as working together. I don't think we're quite there yet tho'.
2 (Build) is the Big Bet because you're taking a capital expenditure approach to an operational problem. You're investing in intellectual property outside of your core business. ...and you own all the risk.
1 (Buy) is difficult because it is expensive and loads of things you want are still only sold on a professional services basis, rather than as a product. It's also a market designed for the large companies with between 6 and 9 figures to spend. It's also one of those infrastructure projects that is usually shaped as something that doesn't deliver any value until it has been rolled out everywhere. However, this is the option where you hold the least technical risk and most of the risk you do hold is related to abilities that are hopefully aligned with your existing skills of management and operational delivery.
AFAIK, Tesla is the only company I've heard to have done it. Would be useful to hear their experiences on this road.
> Doesn't actually tell you what SAP is, or stands for, until halfway through the article.
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.
Interestingly, the source code of SAP is openly readable (once you have their software installed).
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