5 ms·

I take a very neutral position to this. Enterprise software at the scale SAP is operating (mainly its core ERP) at a Fortune 500 enterprise level. This characte

by mbesto 7y ago

I take a very neutral position to this. Enterprise software at the scale SAP is operating (mainly its core ERP) at a Fortune 500 enterprise level. This characteristic (needs at that level) are user-hostile, not the software. Imagine this situation: - You're a F500 pipe manufacturer and a sales person needs to enter an order for 100 pipes to be manufactured and sent to a customer in the US Now imagine you need to: - Order your materials from your Brazilian plant - Procure raw materials from your Chinese plant to be sent to your Brazilian plant - Ship the raw materials from your Chinese plant to your Brazilian plant - Ship the 100 pipes from Brazil to the client's plants, 50 to their plant in the Indianapolis and 50 to their plant in Canada Now imagine from a systems perspective your software needs to: - Determine import costs for sending raw materials from China to Brazil to the USA - Integrate with a 3PL to calculate shipping across all 4 sites - etc. etc. Oh and your software needs to: - Be extensible to adapt to any modifications and user exits. - Have a beautiful interface that anyone from the age of 22-65 can use. - have full audit capabilities to adhere to local/regional compliance - have capabilities for reporting and analytics The real world is messy, especially at scale. For the record - I started my career as a millennial at SAP and was appalled that most F500 use it. I've learned a lot about the "real world" since then.

donkeyd 7y ago
> 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.
simlan 7y ago
This should be higher up. Everyone here thinks a simple shinny crud app to order materials for a fancy start up would be so much easier. In reality anything that starts like this will need to face this complexity at some point. Turns out the SAP way is a compromise between usability and extensibility that worked for a long time.
notkaiho 7y ago
While I sympathise with the frustrations expressed by other commenters, especially the ones you are replying to, this kind of illustration of the complexity the system deals with is super valuable and eye-opening to me in the same way the original article was. Thank you for sharing.
oblio 7y ago
I really like this industrial parallel: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ 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.
- eXpl0it3r 7y ago
  The provided example is a bit questionable. Sure it "works", but this is a perfect example for using a typed language, so the compiler/transpiler/static analyzer can immediately tell you that type EncodedString can not be implicitly converted to string. No need for naming conventions that have to be taught to everyone and half of the people keep forgetting. Of course that doesn't take away the responsibility to teach people why there are two types, but even if they don't know and just copy-paste, it's better than someone mislabeling a variable name and thus not making it any easier to track down a bug because of it.
dsfyu404ed 7y ago
My experience with Oracle's products is similar. At these kinds of scales simple tasks like paying someone or restocking widgets become user hostile because of all the process complexity required to capture all the cases.
BlobRunner 7y ago
I don't buy the "real world is complex deal with it" explanation. Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it. Your PC operating system complexity and the International Network of computers is so complex you cannot figure it all with your brain alone. Yet you write your email everyday with it and your colleague in China get's it in seconds. Your supply chain is a nightmare so SAP must be a nightmare to use ? Why ?
- eitally 7y ago
  You're asking the wrong question, really. SAP is a result of what's built when a software company is started to solve megascale business process automation problems. It is literally impossible to create a great user experience when developing software in or for enterprise IT departments, for a lot of reasons. 1. Budgetary restrictions 2. Quality of engineering teams 3. Lack of autonomy to make and enforce product functionality (or even UI) decisions 4. Competing stakeholders 5. Inconsistent workflows The chasm between product development at a "digital native" and how business software is created in captive IT are worlds apart (and my list doesn't even touch the added challenges when it's outsourced IT).
- tomatocracy 7y ago
  Traditional mortgage lending is actually a great example of 'adapt the business to the process'. Whereas you used to have local branch managers approving mortgages who knew their customers, now you have a credit score (and a thousand other metrics) and the job of the people in the branch/on the phone is to help their customers tailor their mortgage applications to meet the computer's requirements. It's literally the reverse of how it used to work.
- MagnumOpus 7y ago
  > Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it. In this analogy the ERP system is the Stripe plumbing that simplifies it for the endpoints (factory logistics manager, salespersons etc) just like Stripe does for its endpoints (merchants and customers). You might find that re-implementing Stripe is not so simple because of the nightmares of naturally-grown international payment networks. Similarly, implementing an ERP system over an F500 company's logistics/manufacturing/sales pipeline that grew in a complex nightmarish fashion through M&A and diverse international legal/tax/regulatory frameworks.

by mbesto 7y ago

donkeyd 7y ago

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

simlan 7y ago

This should be higher up. Everyone here thinks a simple shinny crud app to order materials for a fancy start up would be so much easier. In reality anything that starts like this will need to face this complexity at some point. Turns out the SAP way is a compromise between usability and extensibility that worked for a long time.

notkaiho 7y ago

While I sympathise with the frustrations expressed by other commenters, especially the ones you are replying to, this kind of illustration of the complexity the system deals with is super valuable and eye-opening to me in the same way the original article was. Thank you for sharing.

oblio 7y ago

I really like this industrial parallel: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ 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.

eXpl0it3r 7y ago
The provided example is a bit questionable. Sure it "works", but this is a perfect example for using a typed language, so the compiler/transpiler/static analyzer can immediately tell you that type EncodedString can not be implicitly converted to string. No need for naming conventions that have to be taught to everyone and half of the people keep forgetting. Of course that doesn't take away the responsibility to teach people why there are two types, but even if they don't know and just copy-paste, it's better than someone mislabeling a variable name and thus not making it any easier to track down a bug because of it.

dsfyu404ed 7y ago

My experience with Oracle's products is similar. At these kinds of scales simple tasks like paying someone or restocking widgets become user hostile because of all the process complexity required to capture all the cases.

BlobRunner 7y ago

I don't buy the "real world is complex deal with it" explanation. Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it. Your PC operating system complexity and the International Network of computers is so complex you cannot figure it all with your brain alone. Yet you write your email everyday with it and your colleague in China get's it in seconds. Your supply chain is a nightmare so SAP must be a nightmare to use ? Why ?

eitally 7y ago
You're asking the wrong question, really. SAP is a result of what's built when a software company is started to solve megascale business process automation problems. It is literally impossible to create a great user experience when developing software in or for enterprise IT departments, for a lot of reasons. 1. Budgetary restrictions 2. Quality of engineering teams 3. Lack of autonomy to make and enforce product functionality (or even UI) decisions 4. Competing stakeholders 5. Inconsistent workflows The chasm between product development at a "digital native" and how business software is created in captive IT are worlds apart (and my list doesn't even touch the added challenges when it's outsourced IT).
tomatocracy 7y ago
Traditional mortgage lending is actually a great example of 'adapt the business to the process'. Whereas you used to have local branch managers approving mortgages who knew their customers, now you have a credit score (and a thousand other metrics) and the job of the people in the branch/on the phone is to help their customers tailor their mortgage applications to meet the computer's requirements. It's literally the reverse of how it used to work.
MagnumOpus 7y ago
> Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it. In this analogy the ERP system is the Stripe plumbing that simplifies it for the endpoints (factory logistics manager, salespersons etc) just like Stripe does for its endpoints (merchants and customers). You might find that re-implementing Stripe is not so simple because of the nightmares of naturally-grown international payment networks. Similarly, implementing an ERP system over an F500 company's logistics/manufacturing/sales pipeline that grew in a complex nightmarish fashion through M&A and diverse international legal/tax/regulatory frameworks.