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.
Because you can either do it with excel spreadsheets or insanely expensive PDM/ERP software like SAP which is insanely expensive to setup and anyone who has ever used it will tell you is terrible. There used to be middle road options like netsuite but they were bought by SAP. There are alsoneays to do it in Catia, etc like the airplane folks do, but that's also insanely expensive.
PDM = product data management
ERP = enterprise resource planning
SAP = The name is an initialism of the company’s original German name: Systemanalyse Programmentwicklung, which translates to System Analysis Program Development.
WBS = work breakdown structure
COTS = commercial off the shelf
WMS = warehouse management system
CRDT = Conflict-free Replicated Data Type
Some of these acronyms are quite old, but continue to be used as they make sense to the people in those spaces.
Mapping physical actions (parts consumption and receiving) to digital transactions requires both tech and human behavior. Usually the behavior is the bottleneck because it's a lot easier to just take a part off the shelf than it is to create a work order, define a BoM, and post a transaction to the ledgers. At places like this -- the craftsman/engineers are usually the guys with authority -- not the process guys. So they grab a part off the shelf, and try to play catch-up in Excel later.
From my perspective and experience, the actual reality of manufacturing anything complex does not match up with the set of rules that has to constrain any given ERP platform to be a useful, data-based record. Allow too much freeform data, and start losing more and more analysis ability. Too strict, and you quickly crash against the fuzziness of reality.
All the while requiring that your data be as close to 100% accurate as possible. That's the crux of the problem. Modern, complex engineering/manufacturing requires a level of traceability that cannot be handwaved away.
Now contend with this problem against a bill of materials tens of thousands of lines long with nearly a million discrete items put in, all with their necessary interdependecies recorded.
This is totally accurate from my perspective. A lot of the comments in the article make it seem like there's an obvious solution to this problem. But in reality, manufacturing is not "solved" by any means.
My hypothesis is that this is because manufacturing is currently modeled as a list of deterministic steps in a table instead of as a stochastic set of nodes and edges.
If anyone would like to work on this problem, please reach out. Here's our (WIP) repo:
>My hypothesis is that this is because manufacturing is currently modeled as a list of deterministic steps in a table instead of as a stochastic set of nodes and edges.
YES. Someone else who understands!
I will take a look, as very few people (even experienced manufacturing engineers of the highest pedigree and skill) seem to grasp this intuition.
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).
Heh, ~10 years ago that program used to be incredibly bad, losing information and getting getting things wrong.
To the point where on some (larger) projects they'd have a separate project manager actually doing the work in a different system, but then update everything into MS Project every week just to comply with upper management directives. :/
I used it most when you did. I found it acceptable, but not stellar. I never heard of it losing data. Most of the issues were with people not adapting to it and trying to make it work like the in-house tool it replaced (which was buggy, slow, and did lose data regularly).
But yes, a lot of people didn't like it and just updated it from their separate spreadsheets or whatever on a weekly or monthly basis depending on when reports were generated.
My first instinct reading that question was a StackOverflow like "why would you do that ? do Y instead" type answer.
I've used MS Project more than a decade ago for one or two project and just gave up to do what the sister comments are describing: manage the project elsewhere, with JIRA tickets, one or two gantt charts and some more excel sheets as needed.
I never had data loss or straight bugs, it just didn't feel more useful than any of the other tools it's supposed to replace.
Project status was always more complex than what could be fed into it, so I had to keep track of it elsewhere anyway.
Task status needed deeper integration with github and other tools, we're writing tickets and epics etc. anyway so JIRA projects were better suited.
Then it lacked enough simplicity and flexibility to be used as an adhoc gantt tool.
The whole concept just feels doomed in my eyes when it comes to software projects.
Nope, everyone these days wants to use Jira or Gitlab or something so that's what I use. I'm back to an IC role (and have been for a while) and am trying to stay out of project management in general. I hated the politics of it all.
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.
That’s not apples to apples. You can host the spreadsheet online to solve the syncing issues. When doing that, Jira becomes much less advantageous.
When things need to get done, I see people writing spreadsheets for fast adaptive tracking and then once they are done, they sync it with Jira manually post-factum just because they must. Jira becomes a tax to pay, and a slow centralised versioning system.
I like https://www.redmine.org/. It’s stable, contains all features I expect from issue tracking, fast, easy to export and configure. And if you must, very easy to go into the code or database and change.
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
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.