Getting it right up front really sped up the time-to-value. Thus, your end-to-end visual depicted the future-state of the workflow AND training modules with the right individuals already up-to-speed mentally and experientially on the new workflow—because they helped define their new workflow in analog on-the-wall fashion.

Finally, I recall for our conversation, you had the winning vendor train your operators to the specific workflows as defined by—initially—the rough draft user manual.

TM: Yes. So we wrote our own training manual.

MM: Yes. Fabulous. This gets the central idea of process maturity, where from the get-go you started off with a documented workflow, and then built training into the workflow.

TM: Yes. Well, training was definitely a part of the change-management.

MM: It’s also a part of the mindset called, “There’s no such thing here any more as an undocumented work.” And documented work without training is only half the solution.

TM: Yes.

MM: In the few remaining minutes that we have—as I recall—you installed your team installed the software on a Saturday and went live four or so days later. Take us through the startup process.

TM: Oh, boy. Originally, I think, we were going to do a pilot. But since we were working on live data, there were only a few minor mess-ups in the first two weeks, and we decided to keep everything live. I believe that within 60 days, we were already producing new catalogs. I forget the exact, right now, Michael. But it was one of those things where you go, “Okay. We’re going to take a short step,” and we ended up running.

MM: So from our previous conversation, you indicated that installed the software on a Saturday and started working on live data four days later, using the five days or so as to conduct final quality assurance and training. So in two weeks, you pretty much had operators in workflows producing commercial product.

TM: Yes. They were producing. They were in production flow.

MM: The hand-over process was relatively painless and fast.

TM: Yes. I think that we ran into some obstacles the first month or two, but nothing that was a showstopper.

MM: Excellent. Thanks so much.

Tom Marine holds a BA in Journalism from Marshall University, and has been involved in publishing/pre-press environments since 1977. He is currently the Special Consultant to the Owner of Johnson Ventures, Columbus, IN. Tom has been involved in DAM implementation for multi-channel marketers since 1997, including a 1,000-page catalog and 300+ page catalogs.

Then as you selected the finalists and went through more of a formal RFP process that entailed them taking data and mocking it up in their system…

TM: Yes. That’s when they quoted on the system, as well.

MM: So you had vendors quoting on how to automate your workflow, as opposed to simply how to install their code and then shoehorn existing current-state users to their system?

TM: Correct.

MM: As a function of having created the user manuals, did you then have the vendor basically rewrite or augment the manuals? Take us through that.

TM: Yes. We had additional meetings, after we chose the vendor. We had a meeting where they went through how they normally train. We said, “Well, that’s very nice. But here’s how we want you to train us.”

It was more focused, but just as intense. In other words, they had a certain number of days that they had allotted, to cover every feature. We said, “Well, we don’t want to cover every feature, because we’re never going to use these. So we want you to focus more intensely on these particular features here—based on the particular jobs that are out there.”

MM: You just introduced another little gem.

TM: Okay.

The 0.1 Percent Solution

MM: Typically, enterprise systems have 30,000 or 50,000 function points—where each function points represents basic unit of work of a software application. When organizations deploy enterprise systems, they may only activate 500 or 600 of these function points.

Moreover, a power user at any one point in the workflow or process may only use 80 to 100 of these function points. And, a typical user may only use 20 or 30 of function points.

Another way of saying that is that if you take the 500 to 700 function points, that’s less than one percent—actually, a tenth of one percent of the entire set of 50,000 function points of the application.

This disparity calls into question the inherent silliness of magic quadrants or waves from these various research firms. I mean who really cares about, “Completeness of vision” if user end up only using tenth of one percent of that so called complete vision.

And “Ability to execute” represents another bogus, hackneyed concept: If 49,000-plus function points remained unused, they represent more than just overhead or potential—unused function points just become sand in the gears of execution. Someone in the implementation and others in the maintenance process have to manage all this unused functionality. Argh!

So, Tom, by getting it right up front and in analog on-the-wall fashion, you and your team identified the needed 500 or so function points that would deliver economic value. You could then focus on the workflow and quality outputs instead of al the silliness of 49,000-plus unused function points.

MM: Then you said, “Okay. Let’s go find vendors, then, who can automate this new idealized workflow.”

TM: Yes. Well, you know, a lot of that was going on simultaneously, too. By then, I knew who the vendors were.

MM: Right.

TM: Yes.

MM: As I recall, you started off with 15 or so vendors, in terms of your not short-list, but your medium-list. Right?

TM: Right. So I probably looked at 100, and we cut it down to 15 for a more thorough review.

MM: At that point, as I recall, you brought them in and showed them the current and future states. You asked them to speak to how they would automate the future state. Is that right?

TM: We only brought in four. We sat them down in the room after they gave their presentation. We set them down in the room and said, “Okay. Here’s our flow. Now we’re going to leave you here for a while. When we come back, we want you to present to us how you can affect our flow.” So we really put them on the spot.

MM: Not just “affect our flow,” but implement it.

TM: Implement your solution. How is your solution going to integrate with our flow?

MM: So what came out of that?

TM: Well, some things that we were able to gauge. To say, “These people are telling us the truth. These people speak our language and understand what we do. These people are not trying to fit a round peg into a square hole.”

For instance, one group would say, “Oh, yes. We can do all of that. We’ll just make it work.” That’s not what we wanted to hear. We wanted to hear the truth.

One person would say, “You know what? You’ve got a pretty good solution here. We can automate this and automate this and automate this. We’re not sure about this automation here. You may have to keep this as a manual process for a while, until a new version comes out. Or we can implement it as a part of our software.”

Then there were people that would talk about heuristic attitudes and speak a different language. We knew that they didn’t understand the catalog business. So when we started talking to people that not only talked our language and understood what product groupings and SKUs were—and making sure that there was an image that could be saved in a directory as a JPG and the high-res image in a similar place. We understood that they knew what they were talking about.

So it was almost an interview, as well.

MM: Yes. And then you selected a vendor.

TM: Well, we actually went through two stages of that. We had them back to. We actually took some partial data and then presented to us. We cut it down to two, then, after the four. Then each of those two came back and presented to us with our data.

MM: Then at that point, you applied activity-based costing. We already identified that the current-state workflow entailed 300 steps. How many steps did the new, enhanced workflow—entail?

TM: 200.

MM: So clearly, a third of the steps went away?

TM: Absolutely.

MM: Now activity-based costing allowed you to calculate with fairly good accuracy the economic value of eliminating those 100 steps.

TM: That’s correct.

MM: And do you recall what that was?

TM: I couldn’t put my finger right on that number, but I know it was more than the cost of the software.

MM: Right. So in the course of that, you also were able to estimate gains in cycle time. Is that right?

TM: Yes. In fact, that was a major thrust. We knew that we wanted to produce the catalog twice. At that point, we were only producing it once a year.

MM: So basically, you were going to be able to double your cycle time. Not double, but cut it in half.

TM: Cut it in half.

MM: So once you identified that that was a change worth making, the pain associated with the gain would be that there were 100 steps missing with economic value of $500,000 or $400,000. And halving the cycle time would produce incremental sales—as a function of being able to get refreshed content out there.

TM: Yes.

Ancillary Benefits

MM: The other benefit is that now you had your website and your catalog more closely synchronized.

TM: Right.

MM: So you didn’t have one price one place and another in another.

TM: Right.

MM: That would reduce a certain number of customer service cycles. Or discounts that were more like “make-goods,” as a function of satisfying the customer. Right?

TM: Right.

MM: Brilliant! So then, that gave you an optimized workflow that you could visually depict—probably using pretty standard workflow diagrams. Right?

TM: Yes. Sometimes there would be a written step. Sometimes it would be a screenshot with the new data. Sometimes it would be a screenshot of a directory.

MM: So these are basically the artifacts that went into the user manuals.

TM: Correct. That’s exactly what they were. Yes.

MM: So now in the course of then developing this optimized workflow—creating it one screenshot at a time.

TM: Yes.

MM: In the course of developing these screenshots, you had the operator—the intended operator—come in and interact with you and ultimately say, “Yes. That’s what I want my screen to look like.”

TM: Partly. Remember that we really hadn’t chosen the vendor, yet at that point. There were basically mockups that were just done in Excel that showed a basic idea of what it would look like from a data standpoint. But not what it would look like visually in the application.

MM: Perfect! So you developed the wire frame or the exposed data model for that particular screen or activity?

TM: Yes.

MM: Then, how long did it take you to develop that idealized workflow model?

TM: I was trying to think about that—how we broke that down. It was nine months for the total. My guess is that it was like six months for the current workflow and three months for the optimized.

MM: So take us through how you begin to develop a visual depiction of Sally’s engagement with the workflow vis-à-vis an online get-it-right-upfront workflow process.

TM: One of the things that we did that we felt was very important was—and this was typical with all the vendors that we talked to—they wanted to do their training based on their features of the software. Is this where you’re headed? Is this what you were thinking about wanting to get at?

MM: Yes.

TM: The classic analogy is this. Let’s say you’re working in Microsoft Excel. Somebody tells you they want you to write a formula.

Well, how are you going to write that formula? You could type it in. You could click on cells. You could do one of their automated things. There are probably about eight different ways you can write a formula in Excel. Well, with these database-publishing solutions, there are probably about eight different ways you could create a product manager’s role.

But what we did was—we had a core team. We learned the features. We said, “Okay. We’re going to populate the database. We’re going to have our information in there. We’re then going to create a training manual using our information, based on what we feel the optimal way to use that system is.

That’s what we trained on.

MM: So, before you actually configure the software—much less buy the software—you create a training module for an operator.

TM: Right.

MM: In this training module, you described the performance of that job—the job function within work cell. You described that work cell as a trainable, repeatable process…

TM: Absolutely.

MM: In the course of doing that, you documented for Sally what her job looks like—and using the training manual to really mock up the user experience.

TM: And making it real for her. Because when she’s looking at the data and the examples in the screenshots, it has information that she’s familiar with.

MM: So this also then entails you mocking up screenshots, because that’s what you would need in the training manual. Is that right?

TM: Correct.

MM: So in essence, what you did was to design at the level of business process, workflow and accountability. You defined the user experience not just as screenshots, but also as a user manual.

TM: Yes.

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.

MM: So when you looked at this visual depiction and then started to create an interim optimized workflow—at what point did you start applying activity-based costing to the workflow?

TM: Actually, the activity-based costing came after that. I’ll tell you why. It came when there was recognition of how much indeed the new process was going to be able to change the workflow.

MM: So let’s use this as an opportunity to shift into the optimized workflow.

TM: Sure.

MM: Over the course of nine months in this War Room, you developed a visual end-to-end depiction of the messy current-state operation.

TM: Yes.

MM: Out of this precipitated a number of interim changes that you could make, because they were easy, self-evident, and everyone said, “Let’s do it.”

TM: Yes.

MM: Then you developed a new workflow. An optimized workflow embracing some core principles—one of which you identified as, “Right upfront.” And enter data once and only once.

TM: Yes. Enter once, publish many times.

Getting the Right Job Done

MM: Yes. And “stay online.” So, as much as possible, keep the work online as opposed to going offline in an analogue or physical work activity. Is that right?

TM: Yes. Although I think you might cover accountability and enabling within the “right upfront,” the enabling thing was kind of a sticky point, there. It was important for people to do what we called, “Staying out of somebody else’s backyard.”

You can’t do their job for them. If they’re going to fail, they’re going to fail.

MM: So it’s kind of, “You’re accountable for your work, and you’re not your brother’s keeper.” Or—what’s the psychological term? “Enabler.” What do they call that when you enable somebody else’s addiction or bad behavior?”

TM: We call them “enablers.”

MM: Enablers. Okay. So, “Stand on your own two feet and get your job done,” is another core principle.

TM: Right. That doesn’t mean you can’t be helpful. But you can’t do somebody else’s job for them.

MM: Perfect. So that was your principle around enabling. No more enabling bad behavior or enabling shoddy work.

TM: Yes.

MM: You’re accountable for producing high-quality work now in this increasingly transparent self-evidently accountable workflow process.

TM: Right. Because people recognize that if nobody else is doing this…

MM: It ain’t gonna get done.

TM: Right. You can’t hide any more.

MM: So this has actually two dimensions to it. You just described the downside of it. That is fear of recrimination and ridicule and maybe some lost jobs.

But the upside of it is, I am now an acknowledged contributor. I’m needed. I make a difference. I contribute here in a very direct and now transparent and accountable way.

TM: Yes. We are dependent on you.

MM: Yes. And we are inter-dependent—that sense of being part of a team in and of itself provides a sustainable motivation for getting it right upfront.

TM: Yes.

MM: Let’s get to another idea that you had shared with me. Tom, Hubert remains fairly unusual in that that they use activity-based accounting. Would you explain “activity-based accounting?” And how that clarified the cost of the current-state operation?

TM: Activity-based costing at Hubert involved an exercise that was completed every year that depicted the different activities cross-referenced with percentage-of-time-spent on those activities for each position in the company.

Then, as an additional caveat, there was an activity that was called, “IT Involvement.” You could gauge how much IT or technology needs were being done for that, as well. Another piece of that, of course, was how much building space you used—and different things like that.

On a yearly basis, we would look at the different activities, define different numbers to those, and then the accounting group would take those percentages—knowing what the overhead was, and additionally knowing what money you spent. For instance, in the catalog piece, you spent so many millions of dollars to print the catalog and to buy the paper. So those pieces were applied to that activity, as well.

Then you were able to say, “Well, if it takes us this much time activity-wise to produce a catalog and we need to produce another catalog, how much activity would that take?”

Then, apply that to the timesavings that you would anticipate to enhance that or to decrease that activity—based on a particular software like database publishing. Then you have a “soft dollar ROI.”

However, as everybody knows, once you commit to a soft-dollar ROI, it becomes a hard-dollar ROI.