It was a beautiful few days along the Riverwalk as another record crowd attended this year’s conference. The theme was “Content Without Borders” and included an informative end-user panel with countermen from Mexico (yes, print is not dead).
Other highlights included a wonderful keynote by John Washbish and a view of the future from Activant’s Paul Magin.
Doug Winsby presented an overview of PIES and why it matters at one of the Knowledge Sessions. That presentation was titled “Delivering PIES Product Content with XML” and is available (with notes) at the right.
Continuing our winning tradition, AceMapper customers were recognized with 3 awards from the 7 receivers giving Electronic Data Excellence Awards this year.
My “assigned” topic this year was “Delivering PIES Product Content with XML”. But XML is really just the “tip of the iceberg” when it comes to delivering PIES data.
In fact, I’m not going to talk about xml at all. That’s boring stuff only techies should worry about. I wanted to talk about real business issues…
Clearly, then, I needed to come up with a better title for my talk.
When Scott and Robert asked me to present a breakout session on PIES this year, I have to tell you, I wasn’t too excited about it. I mean, PIES has been covered really well in the past by Ryan Vernon and Scott O’Toole. What could I possibly say that hasn’t already been said before?
Besides, I didn’t have any great real-life horror stories about huge fines for improper use of harmonizing codes. Although, I’m pretty sure incorrect package weights caused this to happen…
In any case, I needed a better title. And then it came to me. Since this is my seventh time presenting at NCMA, it seemed only natural to call it…
It’s too bad it wasn’t my sixth presentation. Then I could call it “Winsby Vista” and expectations would be really low…
Thinking about a topic, I wanted to come up with something of interest to me that wouldn’t put everyone to sleep.
And I came up with the answer while taking a shower one day…
I had to make PIES understandable!
Well, I’m not really a part number…
So, why should you care about PIES? The answer is simple.
If your customers aren’t asking for it yet, they soon will. And most of the time, that’s a good enough reason by itself.
But there is another reason why it should become a priority. Just as when you converted application data to ACES and found your data wasn’t as pretty as you thought it was. Producing a PIES file gives you the opportunity to consider data quality.
So, where do you start?
One of the biggest challenges is just the enormity of the task. Product data is all around us, in “data silos” spread throughout your organization.
They are often in different systems managed by different technologies.
You need to get help. The company’s database administrator is your friend.
There’s no getting around it, it’s a big job. Here are just a few of the categories of data you’ll be asked to locate.
In the past, I said mapping your application data to the ACES standard had the added benefit of improving data quality. This is because it forced you to validate against industry data tables.
That is not the case for product data and PIES.
Just because you put your data into the PIES elements doesn’t mean it is correct.
There are plenty of studies that show huge losses caused by data problems.
But just in case the marketing executives need another reason to get behind this effort, it has been shown that poor data damages your brand.
So, I’m going to talk about different ways you can use to generate a PIES file.
An Enterprise PIM contains a central set of product data that’s used to feed consistent, accurate and up-to-date information to multiple output media such as web sites, print catalogs, ERP systems, and electronic data feeds to trading partners.
Note that this is a two-way relationship with other systems within the organization.
If this PIM is not industry-aware, PIES specific outputs might need to be customized.
A PIES-specific publishing tool is very similar to a the Enterprise version, except it is a one-way pull from the enterprise data sources and contains PIES capability right out of the box.
This solution is also much less expensive and easier to implement than an Enterprise PIM.
Data is not “sourced” in the tool. Instead, it knows where to go to get your product data wherever it resides. Scheduled updates keep the the central repository current. Partner-specific outputs with net changes are then generated as required.
There are also on-line PIM systems. They make sense to me if you have very little data to maintain and don’t mind doing it twice (once in your business systems and again in the cloud).
But otherwise, as I understand it, you must prepare your data according to their requirements and upload them. So these systems become simply an xml translation and delivery service.
(2024 Edit: As cloud-solutions matured, on-line PIMs became more full-featured.)
Developing it yourself is also an option, but there are some definite challenges.
I want to concentrate a few minutes on those “Product Attributes.”
Every industry has its own language. I did a quick google search and found dozens of them. From farming to plumbing to landscape architecture and more.
I like to make a distinction between “insider” terms like the ones used to define the standard and those required by the consumer to make an informed purchase.
It’s really important that we do a good job of defining those consumer terms.
AutoZone has over 6,500 terms in its glossary. That’s amazing!
To put that in perspective, the average educated person knows about 20,000 words
This is an initiative with the AAIA Technology Committee which was started several years ago, but hasn’t gotten any real traction yet.
The idea is to define a template of product attributes to track for each Part Type in the PCdb.
So, for example, Car Mats might have “color”, “material” and “quality”. Then each of these attributes could have valid values defined for use.
(2024 Edit: this initiative was finally accomplished and resulted in the PAdb)
Water is a beautiful thing, unless it’s in your basement. We had a flood this summer. Being the glass-half-full type of guy, I thought, what a great excuse to re-finish the basement!
We took out everything… started with a “clean slate.” So now I had the chance to build that home theater I’d always wanted.
I had an image in my mind, and it looked like this…
I didn’t know the first thing about home entertainment systems, but how hard could it be? I love technology.
So, I dug right into google and started my journey.
This is one of the first things I saw. I didn’t understand a word.
But I quickly got up to speed.
I found plenty of “rich media” content.
Their web sites were designed to educate the consumer, make them understand the differences and let them do their own product research.
In my opinion, the ability to compare products based on attribute data is really the “killer feature” of these web sites.
But we can’t do this in our industry.
Now remember, this is what I had in mind.
And this is what I ended up with…
Okay, not quite the same. But that’s not the point. By becoming educated, I actually spent MORE than my original budget. But I was happy with paying more because I understood the differences.
And I can tell you that that little box thing on the floor is a 400 watt down-firing subwoofer that will really rock the house.
Our industry does a nice job of educating the consumer too.
The problem is incorrect or missing data from the suppliers.
Here is an example of a water pump. It has an excellent image (but only one) and a nice description.
When I press on the “Specifications” tab, however, I see…
Nothing!!!
Here’s an example of using a “representative” picture incorrectly. Clearly, the mat is neither tan nor for the “front”.
And do I really want to see a part that I can’t buy (i.e. NOT AVAILABLE)?
One more real-life story.
My lawn mower tractor battery was dead, so I took it to my local retail parts store. They had a very nice lawn and garden display of batteries and a great device to test and charge the battery.
The sales person couldn’t have been nicer. The first thing he asked was…
Being in the business, I knew what he was asking for, but had no idea what the answer was. There was no helpful information printed on the battery other than the competitor part number. Hmmm.
So I said, “I’m not sure. What can I do?”
And he answered, “Can’t help you. I’d try the lawn and garden store down the street.”
WOW.
Now, I understand this is not car/light truck, but how hard can it be to have competitive interchanges loaded.
As a side note, when I went home, a quick web search on the part number found the Cold Cranking Amps information he asked for…
Digital Assets are really the key to rich content, and PIES has a segment dedicated to delivering the “metadata” for each asset.
EXIF is a standard that stores metadata in the actual image file itself.
This program will read a directory of images and create a spreadsheet of EXIF metadata. It’s not all the ones that could be stored, but it’s a start.
Here are some of the PIES fields that match up with the EXIF standard elements.
Here is a PIES-specific commercially available tool to manage digital assets. It will extract metadata from the images or logical pathnames and manage all of the fields required by PIES.
It will also package up the digital assets for delivery along with a manifest file and receiver-specific names etc.
PIES 6.2 is the result of many people working with the Standard to make it better. There were some design problems that needed fixing, though.
For example…
On the surface, it looked like a good idea. Strip out spaces from your part numbers. But then, someone wanted to deliver OE interchanges.
Can anyone tell me the problem with that?
While spaces in part numbers is probably not a good idea, you have no control over the format of someone else’s part numbers.
Here are five things I’d personnally like to see us work on.
How can you help? (1) Use the standard (2) Get involved (3) Provide feedback to make it better
(Edit: It’s 2024 and we still don’t have Related Parts!)
This is the part of the talk where I get to voice my opinion.
Initially, the method for delivering net changes in PIES was defined as a “best practice”. This has since been corrected, but it managed to confuse the industry.
Another example is the naming of digital asset files.
A standard must be black and white.
There can be no middle ground.
Also, we must be vigilant to protect the standard.
You’ve probably seen a diagram like this when talking about the failure of many-to-many data delivery.
The argument is that you only “do it once.” But it’s still “garbage in, garbage out”. There is no “silver bullet” here, you still need to do the hard work of identifying, gathering and understanding your data.
What is the real “value add” if you are already using the standards to send it in the first place?
All you’ve done is move the control to a central location.
It feels like these guys… happily putting themselves in a box!
What’s wrong with the Internet model?
We don’t need to store our websites in a central repository so people can see them.
All we need are well defined “end points” and ways to request the data we want. AAIA could take the lead in defining and developing these web services for all to use, just as they have for IPO.
2024 Edit: sounds a lot like Sandpiper! Maybe it will actually happen one day…
We have many receivers, all with their own specific requirements aimed at gaining a competitive advantage.
Product data is the real challenge in this environment since PIES allows custom fields.
Centralizing the data doesn’t solve this challenge.
Thanks for all you do.