On a scale of 1 to 10, how messy is your materials database in your ERP?
The vast majority of the shops I’ve worked with have struggled to enforce the naming conventions they’ve chosen for their materials. As a result, they end up with hundreds or even thousands of duplicate records, which creates a lot of confusion and inefficiency.
But the problem is not the naming conventions - it’s much deeper than that.
In this article I’m going to talk about the root of this problem, how it’s impacting the industry, and what we can do to solve it.
Information lost
The root issue at hand is that most manufacturing software companies have completely punted on figuring out how to store material data correctly. Instead, they provide a generic table for storing “items”.
The problem with that approach is that different kinds of items have different properties, and if you force them all into the same pile you lose a lot of information.
A sheet of metal has length, width, and thickness, and is made from a particular alloy. A round wooden bar has length and diameter, and is made from a particular wood. A box of disposable gloves has a glove size and a count.
Clearly, different kinds of items can have very little in common. The only way to provide a common representation for a group of unrelated items is to discard all of the structured data about the items. This is exactly what most manufacturing software does.
The result is that users try to organize their data by creating conventions. For example, you could decide to encode structured information about a material in the text description field in a specific format.
Having a convention is better than not having a convention, but a convention can’t be enforced by the software. If the software doesn’t provide users with fields to enter structured data, it requires active work on the part of the users to create good data.
This is totally backwards! Creating good data should be the path of least resistance.
So how did we get here? It turns out that solving this problem the right way is really hard.
In the next section I’ll talk about the origins of this problem, and why it’s so difficult to solve.
A chicken and egg problem
Modeling material data accurately is a very challenging problem. But there is huge upside potential for the entire industry if this problem can be solved.
The main reason why this problem is hard is because there are so many distinct kinds of materials to model. There are essentially endless varieties of metals, woods, rubbers, and plastics.
Each substance can also exist in a variety of form factors, including sheets, rods, bars, tubes, billets, spools, etc. Different types of materials can also have additional properties like temper, or various certifications.
The point is, modeling this accurately is a massive project
If you use a software tool that does not have a detailed materials model, there isn’t a lot of incentive to keep your material data well-organized. But if there were lots of helpful features that relied on you having well-organized material data, that would be a different story.
On the flip-side, if you’re a software company that uses the generic item-based approach, it can be challenging to justify building helpful features that rely on organized material data. These features typically require the data to be stored in a structured format, which means that users would have to clean up their existing data before they could take advantage of the new functionality.
This puts the industry in a tricky situation where change can only happen if both the software companies and their users commit to moving forward together. This is a massive challenge, but let’s take a minute to explore what the future could look like if this problem were solved.
What the future could hold
Imagine you have a software system that stores material data in a structured way. Sheets have length, width, and thickness. Round tubes have length, inner diameter, and outer diameter.
With structured data, a software application can perform logic that is specific to a material type. For example, it could find all the parts in a quote package that share a thickness and nest them together to minimize scrap. Or it could automatically filter your material list based on the inner and outer diameter of the part you need to make, to show you whether you have any suitable materials in stock.
That’s just the beginning, though. If there were a common structured format for materials that was shared across the industry, systems would be able to communicate with each other about materials. For example, you could search both your own materials list and your distributor’s catalog, all without having to switch between two different software tools.
None of this is possible with unstructured data.
Most shops have a hard time enforcing conventions within their own organization. On top of that, conventions can vary wildly between different shops. Because of that, it’s impossible to build functionality that works reliably across organizations because there isn’t a single place you can look to find the information you need.
How to move forward
The way forward is to develop a common standard that can be widely adopted by the manufacturing industry. It won’t be easy, but there are other kinds of structured data that have been successfully standardized that can serve as inspiration.
One example is addresses. You could represent an address in a single text field. As long as you put the information in the right order, the address is valid.
But the way pretty much all software represents addresses is with a common set of structured fields:
Address 1, Address 2, Address 3, City, State, Zip Code, Country
Breaking out the fields in this way allows software tools to provide valuable features like searching and filtering, but more importantly it allows different software tools to communicate about addresses in a common language. An e-commerce website can seamlessly integrate with a shipping company because they both store addresses the same way.
While researching for this article, I found very little information online about previous attempts to standardize the representation of materials in manufacturing software. If there is a standard, it certainly hasn’t found its way into common use across the industry - but please let me know if I’m missing something.
In my opinion, the best way to develop a common standard is by crowdsourcing input from the community. I’d like to get this discussion started, so if you have thoughts about this problem or would like to contribute to coming up with a solution, please reach out and let me know.
