421–430 of 622 posts
SAP implementation basically sunk Target's huge investment into operations in Canada 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.
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…
>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…
Earlier quoted context omitted.
The problem nobody wants to admit is that any competitor to SAP will just become SAP. SAP grew to what it is because it was made to fit everybody's workflow to make sales to businesses wanting ERPs. 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 s…
"The problem nobody wants to admit is that any competitor to SAP will just become SAP." 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…
Earlier quoted context omitted.
"The problem nobody wants to admit is that any competitor to SAP will just become SAP." 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…
I think the big difference is that you can re-implement your website in a new web framework, open source it, and then get traction, etc. You can also do this with ETL frameworks (i.e. Airflow) too. Disruptive software is easier here as developers can run this new framework in parallel, or even as a side project to test it, provide feedback, or even help implement changes upstream. If something goes wrong, it usually…
JSON disrupted XML. There really are ways it's strictly less capable.
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…
> 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 se…
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.
Earlier quoted context omitted.
As an employer, it felt equally as hostile. Every process was riddled with more process. Approvals were miles deep. Getting appropriate hardware and software that wasn't on The List was nearly impossible. Good times were had by all.
How industry dependent is this? Is this an artifact of the needs of a particular industry (aerospace, automotive) that has a lot of process to cover supplier quality concerns?
"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.
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…
> 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 decisio…
Earlier quoted context omitted.
> 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 decisio…
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…
SAP has enabled/mandated an army of people at my company who manage it and ruthlessly control even read access to it. The software is user-hostile, intentionally obscure, and all requests for slightly customized reports have to go through a multilayered approval process - often up to corporate - where it competes for funding against other survivors. Needing something custom invites constant questions of why the stand…
> The software is user-hostile, intentionally obscure This a million times. I don't know if good interfaces can not be built in SAP, or if it's very difficult to do, or if the developers of apps on SAP platform just don't care. It's a real headache to use and completely confusing. It's 2020 and one would hope software companies realize the value of a good, clear, effective user interface.
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.
Earlier quoted context omitted.
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.
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.
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).