I work in Motorsports and a parts tracking database is an actual unsolved problem with each team building it's own bespoke solution. It's also kinda unique because your simulation tool is connected to the parts database and part of the tool has to work offline for running simulations in the plane.
I'm not really a database person so never really understood why off the shelf solutions aren't typically used here.
I'm guessing Williams probably just didn't have the budget to build one and didn't know any better so they used Excel.
This is why off the shelf solutions aren't typically used. I looked into creating an MRP software a few years back. What I found is that every single company has their own process that is incompatible with everybody else's and they aren't interesting in changing it (it works for us!) That's the reason MRP/ERP systems are so expensive and complicated. It has to be flexible enough to work for everybody. That takes a lot of developer time to create, generates a lot of bugs, etc. It also makes setup and integration a daunting task, which is why SAP integrators can charge $7k/hr (as somebody else in this thread mentioned). The developer time required also makes them extremely expensive, which is why most ERP packages focus on billion dollar global companies; they can afford it.
> I'm guessing Williams probably just didn't have the budget to build one and didn't know any better so they used Excel.
Ironic, because they've probably wasted a lot more time hammering Excel (or their heads on the keyboard) to get it to do what they want than if they had done some real programming.
Parts tracking is an unsolved problem in general. Everyone in manufacturing is winging it in Excel or runs into enough chaos-complexity that violates the bounds of whatever software they’re using (homegrown or bought) that they port a part of the problem to Excel.
I our company we use a CMMS to keep track of medical devices and their parts with the corresponding sub parts and so on (much like a tree). Shouldn't a system like this help with the problem?
There is an off the shelf product for what is described in the article - it’s an ERP that includes a WMS (or even possibly just a WMS plus some ordering/forecasting software).
It sounds like they were using the Excel spreadsheet for a WBS or scheduling application. There are a million and one COTS products for that. They probably used Excel because whoever did the initial task didn't know, or didn't have the time to learn about, tools like MS Project or whatever else that could have helped them, or only knew of larger scheduling tools that require a sys admin to set up and run.
The reasons Excel gets used for anything:
1. It's present.
2. It's "free". (Corporate already paid for it.)
3. It's easy at the current scale of the problem
4. It doesn't require servers to use.
5. Someone else created it 20 years ago and no one pushed to use a real DB or specialized COTS product because that takes more effort.
6. It's actually an appropriate tool for the job (very common, but not the #1 reason it's used).
I wouldn’t blame this on Excel. Williams was just grossly mismanaged for a long time. I have read some interviews with Vowles and it seems the management simply had no clue how to run an F1 team.
I’m not even surprised. I worked at a company whose bug tracking system was an excel spreadsheet mailed around. I’m not talking 2-3 engineers, I’m talking 250 engineers. There was one guy whose responsibility was to consolidate all the copies once a week. You can imagine how much information was lost there.
I put JIRA in there because even that was less shit.
Edit: also their VCS was a giant corrupted SourceSafe database as well.
I'm going to look on the bright side of this. Look at how far we've progressed in collaboration! We complain about Jira etc but it does have a lot of great features that an emailed, weekly manually reconciled Excel spreadsheet does not.
Excel is a drug, and a lot of junkies have no interest in quitting. I actually work on software that has been used to manage the development of race cars. A couple sister departments use excel for everything my app does and are too set in the ways to consider anything else.
Nearly all spreadsheet replacement software is worse though: it’s seeming clarity comes from being overly rigid or overly difficult to configure.
I don’t get the hate for spreadsheets. It has APIs, great primitives, good automation capabilities, im-/export, and is human-readable and writeable.
This particular spreadsheet from the article might have gone bad, but for centrally tracking an 20,000 item list, a spreadsheet doesn’t seem to be completely out of place.
To improve on it for a presumably very specialised use case with recurring changes and adaptive processes that might give you an edge over competitors, they probably need their own small development team. And this can of course go bad quickly too.
Many years ago, I was sent in to, incidentally, a major car-parts reseller - almost all car parts in the EU and UK pass through this firm. This was a family business, dad had built the business, retired, and the kids were running the place. Pretty much the first order of business for the kids was the modernisation of the IT systems.
My initial task was to do an assessment of who was using what, and what for, which all went really smooth, until we got to the “accounting floor”. I couldn’t get in, as the accounting team had locked the doors, and locked themselves in. Part of the modernisation was replacing the 100% Excel-based parts/accounts/supplier/customer ERP system with something that wasn’t Excel, and they simply weren’t having any of it.
We walked away from that project, a competitor gleefully took it over, got caught in a swamp of technical and legal complications, and lost a lot of time, money, and people.
And why not adopting a CMMS system? I'm missing something? Of course that you need to pay for it, monthly or one time payment, but they are made for this kind of job
[+] [-] vsskanth|1 year ago|reply
I'm not really a database person so never really understood why off the shelf solutions aren't typically used here.
I'm guessing Williams probably just didn't have the budget to build one and didn't know any better so they used Excel.
[+] [-] lylejantzi3rd|1 year ago|reply
This is why off the shelf solutions aren't typically used. I looked into creating an MRP software a few years back. What I found is that every single company has their own process that is incompatible with everybody else's and they aren't interesting in changing it (it works for us!) That's the reason MRP/ERP systems are so expensive and complicated. It has to be flexible enough to work for everybody. That takes a lot of developer time to create, generates a lot of bugs, etc. It also makes setup and integration a daunting task, which is why SAP integrators can charge $7k/hr (as somebody else in this thread mentioned). The developer time required also makes them extremely expensive, which is why most ERP packages focus on billion dollar global companies; they can afford it.
[+] [-] naasking|1 year ago|reply
Ironic, because they've probably wasted a lot more time hammering Excel (or their heads on the keyboard) to get it to do what they want than if they had done some real programming.
[+] [-] quartesixte|1 year ago|reply
This is a billion dollar problem.
[+] [-] kirkarg|1 year ago|reply
[+] [-] Closi|1 year ago|reply
[+] [-] Jtsummers|1 year ago|reply
The reasons Excel gets used for anything:
1. It's present.
2. It's "free". (Corporate already paid for it.)
3. It's easy at the current scale of the problem
4. It doesn't require servers to use.
5. Someone else created it 20 years ago and no one pushed to use a real DB or specialized COTS product because that takes more effort.
6. It's actually an appropriate tool for the job (very common, but not the #1 reason it's used).
[+] [-] rqtwteye|1 year ago|reply
[+] [-] willtemperley|1 year ago|reply
[+] [-] cjk2|1 year ago|reply
I put JIRA in there because even that was less shit.
Edit: also their VCS was a giant corrupted SourceSafe database as well.
[+] [-] civilized|1 year ago|reply
[+] [-] themerone|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] Jakob|1 year ago|reply
I don’t get the hate for spreadsheets. It has APIs, great primitives, good automation capabilities, im-/export, and is human-readable and writeable.
This particular spreadsheet from the article might have gone bad, but for centrally tracking an 20,000 item list, a spreadsheet doesn’t seem to be completely out of place.
To improve on it for a presumably very specialised use case with recurring changes and adaptive processes that might give you an edge over competitors, they probably need their own small development team. And this can of course go bad quickly too.
[+] [-] wideroots|1 year ago|reply
[+] [-] joezydeco|1 year ago|reply
[+] [-] tomrod|1 year ago|reply
[+] [-] croes|1 year ago|reply
[+] [-] justinclift|1 year ago|reply
[+] [-] mdekkers|1 year ago|reply
My initial task was to do an assessment of who was using what, and what for, which all went really smooth, until we got to the “accounting floor”. I couldn’t get in, as the accounting team had locked the doors, and locked themselves in. Part of the modernisation was replacing the 100% Excel-based parts/accounts/supplier/customer ERP system with something that wasn’t Excel, and they simply weren’t having any of it.
We walked away from that project, a competitor gleefully took it over, got caught in a swamp of technical and legal complications, and lost a lot of time, money, and people.
[+] [-] dang|1 year ago|reply
The details behind an F1 team's painful revolution - https://news.ycombinator.com/item?id=39776108 - March 2024 (8 comments)
[+] [-] auselen|1 year ago|reply
[+] [-] kirkarg|1 year ago|reply
[+] [-] timmorgan|1 year ago|reply
[+] [-] WalterBright|1 year ago|reply
[+] [-] riwsky|1 year ago|reply
[+] [-] darkhorn|1 year ago|reply
[+] [-] iancmceachern|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]