Nabeel S. Qureshi: belief

Transcript context

…So how much of that does becomes a part of this core product versus stays this one-off thing? Is it elements, that's a cool innovation, let's put that into Foundry. How does that work? This was a really interesting story actually. So the initial problem that we came into with Airbus was that they had a new aircraft called the A350 beautiful aircraft. By the way, if you get to, I think if you fly New York to Singapore, it's often in that A350. Really nice. So it was a relatively new aircraft at the time, and their mandate to us was, "Okay. We need to ramp up production of this really fast," much faster than we've ever done it before. So it's like the numbers are very approximate, but it's like, "Okay. We're producing 4 this month, we need to do 8 the next month, 16 the month after, and so forth, and you are going to help us do it." So this goes back to what I was saying earlier is the mandate wasn't like, "Hey, we need to upgrade our data infrastructure. We thought you guys would be met the list of requirements." It was much more just like, "Please help us accomplish this mission. This is the big thing." So we went in, scoped out the problem. There were a bunch of different things that we could build that helped accelerate this, but one of the basic problems that we figured out was that without getting too much into the weeds, the way the factory would work, is that there's a bunch of stations and you can think of the plane as literally moving between each station and then each station would do a certain set of work on it. So initially, it's literally a big fuselage and the fuselage is sitting there and then people are doing a bunch of work orders against it. They need parts in order to do that work. And then at some point they say, "Okay. This is ready to move to Station 31, and the plane is physically moved to the next station and then Station 31 does its next thing." So in order for the next station to do its work properly, they need to know, one, what work was done at the previous station and what work is remaining? Two is just like, if you think about this problem, not all work is going to get done on time. So things carry over to the next team, and the next team then has to... So when I'm describing this problem to you can start to visualize, okay, maybe I need some Gantt chart to this, and I need the ability to click in and say, "Okay. What did Station 30 do and what work orders remained undone?" And then it's like, "Okay. For those work orders, what parts do I need and where in the factory might they be?" So this was very, very hard to do as it is. A lot of it was just relying on people going and having conversations with other people on the factory floor, and coming from tech where it's maybe not as complicated as building aircraft, that is a phenomenally complicated process, but it is easy to see, okay, you can actually improve this problem with software. All that data was stored in SAP and SAP is like established software. It's good at what it does, but it's not the most user-friendly necessarily, especially if you're not an expert in how it stores data. The table names are very hard to understand and read. ed software. It's good at what it does, but it's not the most user-friendly necessarily, especially if you're not an expert in how it stores data. The table names are very hard to understand and read. So one of the things we figured out was just if you can pull in these tables that may as well be written in completely alien language, the table name would just be like S3, F1_Z or something like that. And you'd have to know, okay, this is the table where the part ID is stored or something. If you could pull in those tables and join them in the right ways, and then just map them to human concepts that humans can understand, so things like a part a work order, an aircraft, et cetera, and basically build a hierarchy or mapping between them, then what you can do is, a user can just log in and say, "Okay. Aircraft 79, where is that? Okay. It's at Station 31. All right. These are the work orders, et cetera." So you've translated it into a more human-legible thing. So the thing we built, I slightly flippantly described it as Asana. It's a little different. But basically that's what it did, was it gave you a unified view of, okay, this is what's going on inside the factory. This is the work that needs to be done on this particular plane. And then me today going to my job at Station 31, what work orders do I need to fulfill and where are the parts that I need to do that? So did this directly become a part of Foundry? Not exactly, because the way that other companies work is not going to be using this same set of concepts, but the overall idea of taking a bunch of tables, and then mapping them to human understandable concepts was a very powerful one. So this actually resulted in a big piece of Foundry now, which they call Ontology. You've probably heard this term as you've seen... If you see Palantir presentations, they always talk about Ontology. This is what they actually mean by that, is it is a set of concepts that is understandable to you as a human and you are not having to go and dig around and do. You're just able to say, "Where is the aircraft now and where is it going next?" So the ontology became a huge piece of Foundry. It was directly informed by the learnings that we had from building that application inside that factory. And I would say it's still a very big differentiator today. I don't think too many other companies ship this kind of stuff yet.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.