If you search for who uses a data catalog, you'll get a neat list: data engineers, data scientists, analytics teams, maybe a governance committee somewhere. I'm going to argue that list is incomplete. The people who need data catalogs most are the ones who would never call themselves data people—quality managers, procurement teams, compliance auditors, and anyone who has ever been asked, 'Where did that spec come from?'
If you can't find your data, you don't have a data problem. You have a catalog problem.
I'm a quality and brand compliance manager in the packaging industry. I review every packaging spec before it reaches production—over 200 unique items each year. In our Q1 2024 quality audit, I rejected three incoming lots because vendors had used outdated revisions. It wasn't their manufacturing quality. It was their data retrieval. And that's a pattern I keep seeing.
Who Uses a Data Catalog? The Honest Answer
I'll admit: I didn't always understand this. I thought a data catalog was something for data teams—or rather, for the data teams at companies that were serious enough to have them. Then I started working with supplier portals. Big ones, with more logins than departments.
Here's who actually uses a data catalog in a commercial operation:
- Quality managers who need to verify a material spec before approving production.
- Procurement people who need to compare supplier documents without asking someone to email the latest version.
- Sales teams quoting a custom item (surprise, surprise) and needing current tolerances.
- Compliance and audit functions that need to prove what was approved, who approved it, and when.
- Operations people who just want the right answer at 11 pm.
If you search 'who uses a data catalog,' you'll rarely see 'the packaging quality manager' on the list. That's a gap, and it's an expensive one.
What a Data Catalog Is Not
It's tempting to think a data catalog is just a smarter folder system. But a folder system tells you where files are. A data catalog tells you what things mean, which version is current, who owns the data, and what the data can be trusted for.
The 'just put it on the shared drive' advice ignores the messy part: people don't remember which file is the source of truth. A data catalog is the difference between finding a file and knowing it's the right file.
The 'ask the person who's been here 30 years' thinking comes from an era when that person was the catalog. That's changed. When that person retires, the data goes with them—unless there's a catalog that doesn't rely on memory.
A Quality Manager's View of Berry Global and Its Many Portals
I've worked with Berry Global on several packaging programs. Whether I'm reviewing Berry Global's aluminum packaging technology or a simpler poly film, the spec is only as good as its metadata. And the larger the supplier, the more hidden that metadata can be. That's not a dig at Berry Global specifically. Integrated packaging is valuable. It just means you need more—not fewer—ways to find what you're looking for.
Take the phrase 'laddawn berry global login.' If you've ever tried to get a spec from a supplier at the end of a long day, you know why that search exists. You don't want a login. You want the spec, the certificate, or the test report behind the login. The same person might search for 'berry global oracle login' when they're chasing an invoice or a purchase order. Both searches are, in a strange way, attempts to find a data catalog. The problem is there are too many doors and not enough labels on them.
I don't expect a global packaging company to consolidate everything into one portal. I expect them to have a map. That's what a data catalog is: a map for the data you already own.
The 25,000 Atlantic Garment Bag Lesson
Let's get specific. A customer once ordered 25,000 Atlantic garment bags with a custom print, a metal hook, and a zipper. It sounds simple. It isn't.
The spec sheet had more than a dozen fields: film gauge, lay-flat width, finished length, hem size, zipper style, hook material, print ink, packaging quantity, carton dimensions, and more. Any one of those fields can sink a production run. And if the production team is reading an old version, the results are painful.
One such error cost us a $22,000 redo and delayed a launch. When I compared the approved spec against the production ticket side by side, I finally understood why data catalogs matter. The data existed. The catalog didn't.
There's also a physical packaging angle. According to USPS Business Mail 101 (pe.usps.com), large envelopes must be between 6.125 inches by 11.5 inches and 12 inches by 15 inches, with a maximum thickness of 0.75 inch. That's exactly the kind of constraint that belongs in a spec's metadata. You can't eyeball it.
And when a customer asks whether a film is recyclable, I don't guess. Per FTC Green Guides, calling something 'recyclable' means it's recyclable in markets where at least 60% of consumers have access. That claim needs a traceable source. A data catalog is the most realistic way to keep that straight across hundreds of items.
The Spectrum Remote Manual PDF Test
Here's a comparison that made this click for me. Most people have, at some point, downloaded a 'spectrum remote manual pdf' because their TV stopped responding. You don't want the manual. You want the code for your specific TV brand. You want a structured answer to a very specific question.
A data catalog is the same. Nobody cares that the data exists. They care whether they can find the piece that solves their problem without reading six documents.
The 'just use a document folder' advice ignores that people search by intent, not by folder hierarchy. That's why metadata matters.
Signs You Already Need a Data Catalog
You don't need a data catalog because you have a lot of data. You need one because you can't answer simple questions with confidence. Here are the signs:
- People search for 'laddawn berry global login' instead of bookmarking the portal. The system isn't doing the memory work.
- People ask around for 'berry global oracle login' because they don't know which system has the purchase order.
- Someone downloads a 'spectrum remote manual pdf' to answer a one-line question. They'd rather read a 20-page PDF than ask their boss.
- You have a product called 'Atlantic garment bag' and its spec sheet lives in exactly four places, none of which are linked.
The Vendor Who Says 'We Do Everything' Is a Red Flag
Here's where I get opinionated. In packaging, I'd rather work with a specialist who knows their limits than a generalist who overpromises. The same is true for data tools and data teams.
A supplier who says 'we can do everything, just log in here' doesn't comfort me. It warns me. Because the moment you need something outside their core, you'll spend three weeks waiting for an answer that should take three minutes.
Berry Global doesn't need to be the only packaging company in anyone's supply chain. A focused supplier who knows their material science is often a better choice for a specific product like a garment bag. What I value is a vendor who tells me what they're great at and, more importantly, what they're not great at. The vendor who said 'this isn't our strength—here's who does it better' earned my trust for everything else. That's the same reason I trust a data catalog that tells me where a dataset is incomplete.
So Who Uses a Data Catalog? You Do.
If you've ever searched for a remote manual, a supplier login, or a spec sheet, you've used a data catalog. You just didn't call it that.
Who uses a data catalog? Anyone who has to answer a question with confidence. The faster we stop pretending data catalogs are only for data teams, the faster we'll stop shipping 8,000 units that don't fit the carton.
If a vendor tells you they're 'one-stop' and 'fully integrated,' ask them how you'd find a spec update from last Tuesday. If they can't answer, they've got the same problem we all do—a catalog problem.
