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.
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.
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 ?
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 :).
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).
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.
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.
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.