MM: Great result! So take us through what the merchandiser did with page-profit analysis.

TM: One of the things that we saw immediately that was advantageous when you think about the fact that all it is – is data. You used to look at a Quark or InDesign page—and say, “Okay. That’s a design page. Type in the information. Import a picture.”

Once the mindset or paradigm shift happened, people started looking at that as data. Then you started saying, “You know what? There’s other data we might want to be able to look at on this page, after we’ve already sent the page to the printer.”

If you can populate data on a page in a price table, does there have to be a price? No.

It could be the amount of sales for that particular SKU or that particular product grouping. Or it could be the number of units that were sold that year. All you have to do is change the data field that it’s pulling to the page.

MM: In the current state, Tom, you had merchandisers that would own a particular category or categories of product. With a felt-tip pen, they overwrote on a print catalog page the quarter or the beginning inventory position, end inventory position, items sold, gross revenues.

TM: Sales and gross profits. And they would actually be looking at a green bar, writing information into a catalog—sometimes using the spreadsheet on their screen to compile data if they needed to compile it. Because the green bar wouldn’t do that.

Each of the product managers would be doing this. So there were five product managers that would spend two to four weeks every cycle populating their pages in their catalog.

All of the product managers wanted to have all of the information, so they’d switch books and they’d mark up somebody else’s book—until all five product managers had all five master books marked up with that information—hand-written.

MM: So the idea then in the future-state is, “Wouldn’t it be cool if we took a PDF or the InDesign document that had the 900-page document and simply did an automated overlay?” A data overlay from the database of beginning inventory position—end inventory position—gross revenues—profits—returns. Simply just published directly—almost as a transparency or an overlay to the actual thing on the page.

TM: Absolutely. That’s exactly what we did. We could do that in the course of a weekend.

MM: With that kind data without the effort, merchandisers could begin to understand patterns and correlate particular presentations or configurations of products that produce a “lift,” in terms of increased sales. Thus, they could begin to understand, “If I put that product here, I get a 3% bump. If I put that same product over here, then I take a 5% hit.”

TM: Yes. There are additional modules that you can get that even do more forecasting than those types of simple analyses, too.

MM: Such as?

TM: It’ll say, “If you put it in the upper right-hand quarter or the lower left-hand corner.” Or, “Is it on the first page of the section or is it on the cover, too?” “Is it on the back cover? Is it on the inside front cover?” “Are you presenting it on the web differently? Are you even presenting it on the web?” There are lots of different ways to look at that type of data.

MM: So then as you develop the future-state capability, you started to really define work-cells that enable you and your automation team to really optimize the productivity of individual workers. Did I get that right?

TM: Yes.

MM: The next thing I’d like you to talk to is the optimized workflow.

With these basic principles of accountability and no enabling bad behavior or sloppy work. Staying online. Getting it right upfront.

With that set of principles, your current-state process, as I recall from our conversation—entailed about 300 or so discrete steps. Is that right?

TM: That is correct. 300 individual steps.

MM: Then how did you start to develop the optimized future-state capability?

TM: Well, as you mentioned—the visual representation on the wall. We kind of created, after we had all of the artifacts out there, we either took pictures or put them into a document. We reduced them so that they could fit on half of that wall. Then we drew a line under that.

The top of the wall was the current. The “current,” being with a few modifications that we felt we could implement right away. Then we drew a line.

On the bottom, we started the new process. “What do we do now? What is the process that we should lead with? Look. You’re doing this on the backend, and we know that there’s pain back there. We want to move this up into the process.”

Subject Indexes in Two Hours vs 30 person-weeks

MM: So for example, there were two things that I want you to address. First, how your team builds the subject index in the back of the catalog and, second, how your ream conducted profit analysis of each page in the catalog.

Let’s talk about the index, first of all. In a 900-page catalog, creating an index can be quite the chore. It typically happens at the end of the production cycle.

So there was like a two-week period at the very end of the production cycle, where 15 to 20 people sequestered themselves into a room and basically called out names and told what page number those particular items were on. That’s now the index was built.

Again, you’re talking 10 to 15 people for 8 hours a day, for 2 weeks. That’s a lot of man-hours.

MM: Yes. That’s 30 man-weeks.

TM: It had to be done. So we recognized with database publishing how electronically that information is captured within the database, and—through a simple export—that same result can be more accurately and quickly exported within a matter of 2 hours.

But more importantly, we reduced the cycle time by two weeks.