It’s extremely easy to confuse people with subject matter expertise with people who really only have business process expertise. In other words, it’s easy for a person who knows nothing about hammers to mistake a hammer salesman for a carpenter. This type of mistake is common, and is detrimental to data and software projects.

As a Data Scientist, one popular piece of career advice is that you should have business domain experience (or expertise) and not just technical skills. But what is “domain experience” exactly, and why does it help differentiate one person from another? In this post I’ll talk about the different kinds of domain expertise I’ve seen at all the different companies where I’ve worked.

When you develop solutions for predictive maintenance, one of the challenges is being caught between the people who design/build the machines, and the people who service machines. Whatever you build has to provide business value without stepping on the feet of either of those parties. In this article I’m going to try and provide insight into what it means to walk this line.

Predictive Maintenance is fundamentally about two goals - keeping your machines running, and making them run in the best way possible. In other words, focus on reducing downtime and continuously optimizing how your machines run. The concept of downtime is easy to describe and understand, but calculating it can be much more complex than people realize. In this post I’ll walk through calculating downtime for a factory machine, and how the complexity of the calculation reveals why using predictive models for predictive maintenance is so challenging.

People often underestimate how false alarms from predictive models can erase all the business value you set out to create from those models. In this post we will explore how label noise can drive up your service costs instead of decreasing it, and how a small fraction of incorrect predictions of impending machine issues can erase all the benefit created by correct predictions.