33 ms·

I teach enterprise systems at a university, with emphasis on SAP. It's hideous. Hideous. My students complain it is unusable (agree), doesn't make sense (agr

I teach enterprise systems at a university, with emphasis on SAP. 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.

kmarc 7y ago
Sounds like my experience with the Avaloq core banking system. Lowest quality crap I ever had to touch.
organsnyder 7y ago
That's similar to Epic's value proposition in the healthcare space. Sure, their software is above average (with "average" being barely functional or vaporware), but their main selling point is their ability to assist leadership in strongarming an organization to adopt standardized workflows.
- swampthinker 7y ago
  As someone working in healthcare, I can attest to the value in getting an healthcare org to adopt standardized workflows. I'll take an org that follows process over better software that isn't used in a consistent manner. There is too much operational and human complexity to solve healthcare with software alone.
  - lonelappde 7y ago
    What happens when the disease in my body declines to adapt to Epic's standardized workflow?
    - inkeddeveloper 7y ago
      Enterprises don't care at the micro level. There's near infinite more that do and that's where they make money.
      - organsnyder 7y ago
        There's also a lot more suffering to be averted. Simple standardized things like following basic protocols to reduce errors (handwashing, surgical instrument inventory) or encouraging better patient compliance (taking meds regularly, for instance) save tons of lives.
    - pavlov 7y ago
      Helsinki recently adopted Epic (under the local branding “Apotti”). 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 https://www.hs.fi/kaupunki/art-2000006391154.html
      - organsnyder 7y ago
        Not to downplay that tragedy, but we don't have any information on how many deaths were prevented by switching away from their old system.
        mads_ravn 7y ago
        In Denmark, a country of approximately 6 million people, there are three different regions running the public hospitals. Two of the three regions choose a custom system, whereas the third choose Epic. 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-er-fem-gange-dyrere-i-drift-end-jysk-udgave-af-systemet https://www.computerworld.dk/art/248393/sundhedsplatformen-e... [2] https://www.rigsrevisionen.dk/media/2104845/sr1717.pdf https://www.rigsrevisionen.dk/media/2104845/sr1717.pdf
- chapium 7y ago
  Cerner does pretty much the same thing. They are trying to approach the hospital market pretty broadly. Much of the software is pretty rigid and if you sign up for them, you are customizing their software and meeting in the middle by reorganizing your business. Many integration issues between vendors are conflicts about where this midpoint is.
moron4hire 7y ago
To be fair, most businesses never designed their processes and don't really have a need to be "different" from other companies. And if you've ever tried to build a single system for more than one client, you know how frustrating little, tiny differences between companies can be. At least big differences can be charged as a new module!
triggercut 7y ago
When it comes to Financial Accounting for asset heavy and inventory heavy businesses who need audit ready financial reporting (IFRS/GAAP), most are going to have pretty standard Order-To-Cash, P2P etc. workflows with similar controls. 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.
ajsnigrutin 7y ago
I work in some other industry with some other software which is "our SAP"... and i look at it as "another IBM". 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.
- carwc 7y ago
  Which industry?
  - grimjack00 7y ago
    ...most of them.
- smichel17 7y ago
  The Ticketmaster value proposition.
jasode 7y ago
>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. 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.
aardvark179 7y ago
I’m not sure I agree with your finally point. There is a lot of software out there that can be customised extensively to fit any particular business, and it’s awfully tempting to do so because you incur a financial cost rather than a social one. But while the social cost of changing how you do things might have been a one off thing the financial cost will turn into a recurring thing every time you want to upgrade. 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.
- lonelappde 7y ago
  Or instead of being trapped a monstrous framework, you can integrate off the shelf libraries (no forking needed) into your architecture. Ask Rob Pike about Go vs Enterprise Java.
cryptica 7y ago
SAP, IBM and Oracle mostly rely on free fiat money straight from the government or other artificial monopolies to keep their businesses going. They don't need to deliver anything. What they do is beyond inefficient. Companies would be better off using open source solutions and hiring developers to integrate various systems from scratch.
- phatfish 7y ago
  Maybe, but I feel like boring business processes are exactly the area where open source solutions are severely lacking. 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.
- take_a_breath 7y ago
  ==Companies would be better off using open source solutions and hiring developers to integrate various systems from scratch.== Funny enough, this is the type of solution SAP is typically displacing. There are huge flaws in the fully-customized process you suggest.
- kube-system 7y ago
  I'm not sure any comparable open source enterprise ERPs even exist. They almost all target small and medium businesses. Enterprise ERPs are gigantic pieces of software. Then there's the issue of expecting a widget-factory to become experts in their own ERP implementation.
- Accujack 7y ago
  Wow... that's.... nope. 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.
tootie 7y ago
Ooo, this is fascinating. What's your syllabus? I'd love to understand the economics of buying this kind of software, versus buying lots of niche software versus hiring a services firm to build versus hybrid approaches.
- hef19898 7y ago
  Not the Op nor teaching in this field. 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.
avra 7y ago
This is exactly the experience I had with MS Dynamics. Hideous. So hideous I refuse to work in that field anymore.
- jve 7y ago
  You should specify which MS Dynamics you mean. Because Dynamics has AX/GP/CRM, everything under Dynamics 365 umbrella. 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.
reallydontask 7y ago
> 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. 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.
- hef19898 7y ago
  And while not every single SAP strandard might fit every single edge case in a given business, SAP standard processes are pretty much a condesation of best practices across hundreds of businesses. So they aren't that bad. That SAP charges extra for industry specific solution, aerospace, process / chemical, and so on, is a different story.
- m-p-3 7y ago
  It's also a good practice to keep a massive system as close to the original as possible and tweak it to business needs only when absolutely necessary, otherwise it becomes a beast of its own to support and upgrade later on. This is a great example of technical debt when adding custom features to an existing commercial platform.
  - kochthesecond 7y ago
    I have seen such customizations go badly soooo many times..
- pmart123 7y ago
  It likely should be a combination. If processes are so different than the "standard" vendor approach, is there a good reason? Step two would be answering what is the key 10% that is different to customize.
lonelappde 7y ago
Why is that taught at a university? It seems a junior college topic.
- SonOfLilit 7y ago
  College for undergrads vs University for graduates is a UK and US thing, in most of the rest of the world you just have universities (or, like in my country, you have non-profit state-funded research universities that also teach undergrads and graduates and you have for-profit private colleges which are a lot lower quality who also teach undergrads and a few graduates, probably because a university degree is considered worth more so all the talented students go there and therefore you have to tech much slower in a college).
chadash 7y ago
> 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. 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.
- gfs78 7y ago
  Agree. It´s buying what doesn´t add much value/differentiation to focus on the things that are important to the company.
- dvtrn 7y ago
  A few years ago the company I’m at now tried doing the former while also trying to launch a SaaS application while also also trying to be a service provider. 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.
- cr0sh 7y ago
  I once worked for a company that let me go because I looked bad on their bottom line and they were looking to sell the company, around 2003. So, severance package in hand, and one week later I had a new position at another company making much more than I was originally. 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.
NikolaNovak 7y ago
>>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. 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 :-/
adaisadais 7y ago
Wow I couldn’t agree more! I studied business analytics at Clemson and we used SAP products because they were “best in industry”. Clunky UI, 20th Century Runtimes, and horrible UX... the market is ready for a change.
jimnotgym 7y ago
I think your comment trivialises what ERP does. Analytics is trivial compared to standardizing processes. I like that when I create a BOM and routing I can be sure that all the inventory created using it will have the correct cost absorbed, and I can prove it to my auditor so I don't get a qualified audit, and a SOX violation and lose my company. You can't do that in a spreadsheet. I like the way I can have hundreds of people involved, I can have hundreds of sales orders, hundreds of production orders, hundreds of picks, hundreds of goods receipts, hundreds of purchase orders from hundreds of suppliers, entered by hundreds of people, and yet I still know my stock level and value, my back orders, my revenue to a very high degree of certainty. And I can audit every one. 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.
tomnipotent 7y ago
> SAP can do can be done at the local level using intuitive software 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).
- endymi0n 7y ago
  The correct answer here is "it depends". 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.
jedberg 7y ago
> I teach enterprise systems at a university, with emphasis on SAP.... My students complain it is unusable (agree), doesn't make sense (agree), that they can't see the point (agree). If you agree on all those points, why do you teach it?
huherto 7y ago
> I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. 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.
tomc1985 7y ago
I remember having to pull data from SAP for some university courses. It was misery incarnate
philjohn 7y ago
The company my dad worked for went through the migration to SAP in the 90's and he said the same thing about not changing SAP, but changing the company as well.
cosmodisk 7y ago
I worked for a 500 people Swiss company that had this big,fat,custom built thing based on Lotus Notes.It was ERP of sorts. We hated it. change backlog was 2-3 years.It took us a year to get a single button added. Then I moved on and ended up in a position where I was no longer the end user but rather the one behind the system.5 years later and I still keep "borrowing" design ideas from that system we all hated. Shortly after I quit, a 5000 people US company acquired it and decided to migrate all the data to their own,more modern system. 6 month later and the project was still in Excel only with no hopes of completing it at all. Don't underestimate what SAP can do.
qubex 7y ago
When I was overseeing a deployment of SAP into the family business (a really inane decision taken on a whim by my father and his trusted CFO) I was told, to my utmost horror but with utmost seriousness by an earnest SAP consultant, that “a company does not install SAP, a company conforms to SAP’s best practices”. Years of consolidated competitive advantage went down the drain.
singingfish 7y ago
I integrate my work systems with SAP. It's not just SAP that's a mess, I think it's a property of ERPs in general. 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).
pinky07 7y ago
We made a business game, scale-up, to teach ERP differently in universities. It's a role play game based on Odoo. It's free for teachers (and students), you can get boxes here: https://odoo.com/scaleup https://odoo.com/scaleup
ryanmercer 7y ago
>It's hideous. Hideous. My students complain it is unusable (agree), doesn't make sense (agree), that they can't see the point (agree). 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.

kmarc 7y ago

Sounds like my experience with the Avaloq core banking system. Lowest quality crap I ever had to touch.

organsnyder 7y ago

That's similar to Epic's value proposition in the healthcare space. Sure, their software is above average (with "average" being barely functional or vaporware), but their main selling point is their ability to assist leadership in strongarming an organization to adopt standardized workflows.

swampthinker 7y ago
As someone working in healthcare, I can attest to the value in getting an healthcare org to adopt standardized workflows. I'll take an org that follows process over better software that isn't used in a consistent manner. There is too much operational and human complexity to solve healthcare with software alone.
- lonelappde 7y ago
  What happens when the disease in my body declines to adapt to Epic's standardized workflow?
  - inkeddeveloper 7y ago
    Enterprises don't care at the micro level. There's near infinite more that do and that's where they make money.
    - organsnyder 7y ago
      There's also a lot more suffering to be averted. Simple standardized things like following basic protocols to reduce errors (handwashing, surgical instrument inventory) or encouraging better patient compliance (taking meds regularly, for instance) save tons of lives.
  - pavlov 7y ago
    Helsinki recently adopted Epic (under the local branding “Apotti”). 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 https://www.hs.fi/kaupunki/art-2000006391154.html
    - organsnyder 7y ago
      Not to downplay that tragedy, but we don't have any information on how many deaths were prevented by switching away from their old system.
      - mads_ravn 7y ago
        In Denmark, a country of approximately 6 million people, there are three different regions running the public hospitals. Two of the three regions choose a custom system, whereas the third choose Epic. 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-er-fem-gange-dyrere-i-drift-end-jysk-udgave-af-systemet https://www.computerworld.dk/art/248393/sundhedsplatformen-e... [2] https://www.rigsrevisionen.dk/media/2104845/sr1717.pdf https://www.rigsrevisionen.dk/media/2104845/sr1717.pdf
chapium 7y ago
Cerner does pretty much the same thing. They are trying to approach the hospital market pretty broadly. Much of the software is pretty rigid and if you sign up for them, you are customizing their software and meeting in the middle by reorganizing your business. Many integration issues between vendors are conflicts about where this midpoint is.

moron4hire 7y ago

To be fair, most businesses never designed their processes and don't really have a need to be "different" from other companies. And if you've ever tried to build a single system for more than one client, you know how frustrating little, tiny differences between companies can be. At least big differences can be charged as a new module!

triggercut 7y ago

When it comes to Financial Accounting for asset heavy and inventory heavy businesses who need audit ready financial reporting (IFRS/GAAP), most are going to have pretty standard Order-To-Cash, P2P etc. workflows with similar controls. 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.

ajsnigrutin 7y ago

I work in some other industry with some other software which is "our SAP"... and i look at it as "another IBM". 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.

carwc 7y ago
Which industry?
- grimjack00 7y ago
  ...most of them.
smichel17 7y ago
The Ticketmaster value proposition.

jasode 7y ago

>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. 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.

aardvark179 7y ago

I’m not sure I agree with your finally point. There is a lot of software out there that can be customised extensively to fit any particular business, and it’s awfully tempting to do so because you incur a financial cost rather than a social one. But while the social cost of changing how you do things might have been a one off thing the financial cost will turn into a recurring thing every time you want to upgrade. 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.

lonelappde 7y ago
Or instead of being trapped a monstrous framework, you can integrate off the shelf libraries (no forking needed) into your architecture. Ask Rob Pike about Go vs Enterprise Java.

cryptica 7y ago

SAP, IBM and Oracle mostly rely on free fiat money straight from the government or other artificial monopolies to keep their businesses going. They don't need to deliver anything. What they do is beyond inefficient. Companies would be better off using open source solutions and hiring developers to integrate various systems from scratch.

phatfish 7y ago
Maybe, but I feel like boring business processes are exactly the area where open source solutions are severely lacking. 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.
take_a_breath 7y ago
==Companies would be better off using open source solutions and hiring developers to integrate various systems from scratch.== Funny enough, this is the type of solution SAP is typically displacing. There are huge flaws in the fully-customized process you suggest.
kube-system 7y ago
I'm not sure any comparable open source enterprise ERPs even exist. They almost all target small and medium businesses. Enterprise ERPs are gigantic pieces of software. Then there's the issue of expecting a widget-factory to become experts in their own ERP implementation.
Accujack 7y ago
Wow... that's.... nope. 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.

tootie 7y ago

Ooo, this is fascinating. What's your syllabus? I'd love to understand the economics of buying this kind of software, versus buying lots of niche software versus hiring a services firm to build versus hybrid approaches.

hef19898 7y ago
Not the Op nor teaching in this field. 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.

avra 7y ago

This is exactly the experience I had with MS Dynamics. Hideous. So hideous I refuse to work in that field anymore.

jve 7y ago
You should specify which MS Dynamics you mean. Because Dynamics has AX/GP/CRM, everything under Dynamics 365 umbrella. 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.

reallydontask 7y ago

> 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. 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.

hef19898 7y ago
And while not every single SAP strandard might fit every single edge case in a given business, SAP standard processes are pretty much a condesation of best practices across hundreds of businesses. So they aren't that bad. That SAP charges extra for industry specific solution, aerospace, process / chemical, and so on, is a different story.
m-p-3 7y ago
It's also a good practice to keep a massive system as close to the original as possible and tweak it to business needs only when absolutely necessary, otherwise it becomes a beast of its own to support and upgrade later on. This is a great example of technical debt when adding custom features to an existing commercial platform.
- kochthesecond 7y ago
  I have seen such customizations go badly soooo many times..
pmart123 7y ago
It likely should be a combination. If processes are so different than the "standard" vendor approach, is there a good reason? Step two would be answering what is the key 10% that is different to customize.

lonelappde 7y ago

Why is that taught at a university? It seems a junior college topic.

SonOfLilit 7y ago
College for undergrads vs University for graduates is a UK and US thing, in most of the rest of the world you just have universities (or, like in my country, you have non-profit state-funded research universities that also teach undergrads and graduates and you have for-profit private colleges which are a lot lower quality who also teach undergrads and a few graduates, probably because a university degree is considered worth more so all the talented students go there and therefore you have to tech much slower in a college).

chadash 7y ago

> 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. 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.

gfs78 7y ago
Agree. It´s buying what doesn´t add much value/differentiation to focus on the things that are important to the company.
dvtrn 7y ago
A few years ago the company I’m at now tried doing the former while also trying to launch a SaaS application while also also trying to be a service provider. 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.
cr0sh 7y ago
I once worked for a company that let me go because I looked bad on their bottom line and they were looking to sell the company, around 2003. So, severance package in hand, and one week later I had a new position at another company making much more than I was originally. 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.

NikolaNovak 7y ago

>>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. 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 :-/

adaisadais 7y ago

Wow I couldn’t agree more! I studied business analytics at Clemson and we used SAP products because they were “best in industry”. Clunky UI, 20th Century Runtimes, and horrible UX... the market is ready for a change.

jimnotgym 7y ago

I think your comment trivialises what ERP does. Analytics is trivial compared to standardizing processes. I like that when I create a BOM and routing I can be sure that all the inventory created using it will have the correct cost absorbed, and I can prove it to my auditor so I don't get a qualified audit, and a SOX violation and lose my company. You can't do that in a spreadsheet. I like the way I can have hundreds of people involved, I can have hundreds of sales orders, hundreds of production orders, hundreds of picks, hundreds of goods receipts, hundreds of purchase orders from hundreds of suppliers, entered by hundreds of people, and yet I still know my stock level and value, my back orders, my revenue to a very high degree of certainty. And I can audit every one. 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.

tomnipotent 7y ago

> SAP can do can be done at the local level using intuitive software 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).

endymi0n 7y ago
The correct answer here is "it depends". 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.

jedberg 7y ago

> I teach enterprise systems at a university, with emphasis on SAP.... My students complain it is unusable (agree), doesn't make sense (agree), that they can't see the point (agree). If you agree on all those points, why do you teach it?

huherto 7y ago

> I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. 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.

tomc1985 7y ago

I remember having to pull data from SAP for some university courses. It was misery incarnate

philjohn 7y ago

The company my dad worked for went through the migration to SAP in the 90's and he said the same thing about not changing SAP, but changing the company as well.

cosmodisk 7y ago

I worked for a 500 people Swiss company that had this big,fat,custom built thing based on Lotus Notes.It was ERP of sorts. We hated it. change backlog was 2-3 years.It took us a year to get a single button added. Then I moved on and ended up in a position where I was no longer the end user but rather the one behind the system.5 years later and I still keep "borrowing" design ideas from that system we all hated. Shortly after I quit, a 5000 people US company acquired it and decided to migrate all the data to their own,more modern system. 6 month later and the project was still in Excel only with no hopes of completing it at all. Don't underestimate what SAP can do.

qubex 7y ago

When I was overseeing a deployment of SAP into the family business (a really inane decision taken on a whim by my father and his trusted CFO) I was told, to my utmost horror but with utmost seriousness by an earnest SAP consultant, that “a company does not install SAP, a company conforms to SAP’s best practices”. Years of consolidated competitive advantage went down the drain.

singingfish 7y ago

I integrate my work systems with SAP. It's not just SAP that's a mess, I think it's a property of ERPs in general. 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).

pinky07 7y ago

We made a business game, scale-up, to teach ERP differently in universities. It's a role play game based on Odoo. It's free for teachers (and students), you can get boxes here: https://odoo.com/scaleup https://odoo.com/scaleup

ryanmercer 7y ago

>It's hideous. Hideous. My students complain it is unusable (agree), doesn't make sense (agree), that they can't see the point (agree). 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.