My thoughts exactly. Knowledge transfer in manufacturing / industrial environments is something that I'm working on. - Language models / NLP applications for processing large amount of technical text data (SOP, documentation, technical data, machine text logs, voice to text, video data processing for speeding up corrective action, training, onboarding and highlighting areas of improvement / bottlenecks), digitising d…
- Your team is out on the floor. Their hands have grease on them. Using tablets sounds great until you're trying to use it with a glove on it, or your hands are dirty, and it's hard to get grease off tablets. But they need the info out on the floor. Also, it can be noisy on the floor.
- The team tends to be very visual. They don't like tapping on computers a lot. Literacy ranges from pretty good to kinda OK. Sometimes they refuse to get (or wear) reading glasses for whatever personal reason.
- They're working on proprietary hardware, but technicians with the right knowledge are not nearby to come in and look at it. You really need to be able to see the issues visually. Sometimes even hear them. AR might be interesting here. (I spend $10k to fly a tech out for a few days to look at a machine. The bigger issue is that I lose $10k a day from one machine being down, and a tech might not be available to fly out for a week.)
- Predictive maintenance. The fancy sensors and whatnot mostly don't work. Tech people try it in a clean, quiet office and it works, and they can raise money on it from clueless VCs, so money keeps getting set on fire with smart AI machine learning magic motor sensor companies.
- Preventative maintenance. How to schedule, how to verify it was done, how to check whether it revealed an issue that needs a follow-up. Getting people to do it, and verify it was done, can be a challenge, but there are huge returns to preventative maintenance (for example: checking gearbox oil levels, verifying lubrication line function, checking valve temperatures.)
- Diagnosing machine problems. Using prior problem documentation helps team members see most likely issues. But many of these people don't really want to sort through a database of prior similar issues because they "know" what the problem is. How do you provide this information to them in a way that feels more approachable to them?
I could go on forever. Manufacturing is an interesting environment because downtime is usually hundreds to tens of thousands of dollars of hard cost per hour, depending on the operation, and they will spend quite a bit of money to stop it from going down, but culturally there's a vast gulf between the white collar SF tech bros and what actually happens in manufacturing plants, so innovation tends to be more limited.