David Bercovici, Project Manager, Strategic Publishing Operations, Hachette Book Group

MM: Okay. Let’s start off, David, with a brief introduction to you and your role in this project. And a little bit about your company.

DB: I’m a project manager in the strategic publishing operations unit of Hachette Book Group USA (HBG). HBG is one of the largest trade book publishers in the US, publishing a range of literary fiction, nonfiction, illustrated and books for young readers. Some of our authors include James Patterson, Nelson DeMillo, Nicholas Sparks, David Baldacci and Stephenie Meyer. We are a division of Hachette Livre, which is currently the world’s second largest publisher.

My department is responsible for managing and guiding technology projects. We collect business requirements, document them, manage projects, run testing and overall ensure that the needs of the business are being served with whatever technology projects we’re undertaking.

Right now, we are in the late stages of implementing North Plains as our new DAM solution. We previously were using Artesia, which was first implemented in 2000. We’re expecting to roll out our new system at the end of March.

We’re using North Plains professional services resources. So in effect, on this project, I’m co-PM along with our North Plains project manager. Internally, I’m coordinating the efforts of different teams as well as collecting requirements from the business, running testing and so on. But overall the project is my responsibility.

MM: Excellent.

Could you give us a little background in terms of what you had deployed the Artesia teams to do? And how that had contributed to the business? And then what led to the need to upgrade or change that?

DB: Sure. We first implemented Artesia back in 2000. A lot of the reason for it was focused around both eliminating waste — whether it was people printing things out, or burning CDs and passing them around — and on reducing costs such as having our production files in house rather than paying our vendors to get additional copies sent to us. Things of that nature. Also, just having one secure repository for what — at the time — we were referring to as the “final truth archive” containing the intellectual property of the company.

That’s been successful. We implemented it back in 2000. It was late 2000 — about seven and a half years ago. Since then, the products have changed. The industry has changed. Certainly there’s a lot more focus now on electronic products like e-books, downloadable audio and so on.

We also have our own digital warehouse initiative known as OpenBook™. That started late last year and it allows us to post browsable portions of our books online.

Last year we recognized that we hadn’t upgraded our Artesia system in a few years. Before we embarked on an upgrade — because that’s always a time-consuming and not cheap process — we wanted to find out what the business saw as its needs related to DAM and how our system was doing in meeting those needs and identifying where the gaps were. We came out of that process with recognition that people wanted to have a system that was more seamless — where importing was easier. Where searching for assets had more flexibility such as having access to Google-style, powerful searches. We also wanted to do a better job handling our more-complex assets like InDesign and Quark files, which we use for the layouts of our books. That we’d have an easier way to handle all of that.

MM: When you say, “An easier way of handling that,” does that necessarily mean that you wanted to have a fat client that you could drop out of, as opposed to a browser or Java-based client?

DB: We were more concerned about even just getting those files into the system properly. Some of the reuse of that content is for our publicity people. If we have a book with illustrations or an insert, we want the people promoting our books to be able to peruse the preview of that book, and pull out specific pictures, rather than just having to scan through 100 or 200 loose images to find the one that was on page 23. They want to have a way to identify that page and pull out the image quickly. So it is more of an issue of how the system handles and presents the content of those files.

MM: If I understand you right, they were using the book almost for context — a navigational context — for a class of users to identify an asset.

DB: Right. Yes. Each image in the book, in effect, is an asset unto itself. But by perusing the book preview they’re able to or will be able to pinpoint that one specific image that they want, rather than having to go searching through page after page of images, and trying to eyeball which one is the one they’re looking for.

We wanted to have a better way to handle those kinds of files, in terms of ingest. Basically, when the files are ingested this preview would get created. Those were some of the main things we were looking for.

Also, we’re trying to build for the future. Perhaps we’ll build some integration between our DAM system and our digital warehouse; so that we’re putting the book files out on our DAM and then building integration between the DAM and the digital warehouse, in effect making the digital supply chain more cohesive. Then it’s easier to get files from Point A to Point B and we’re not duplicating effort.

Similarly, I’d think that down the road, we’ll also be using a similar model to support any kind of e-commerce. Whether it’s for audio files or e-book files. That’s the sort of thought that went into it.

But initially, when we did our assessment, it was very much user-focused. Just trying to understand their needs. We didn’t embark on that assessment process with any real expectation that we were going to switch to a whole new system.

After we had the assessment and identified our goals, we just decided that since it had been at least a few years since we’d upgraded, we’d better see what was going on in the DAM industry with all the leading products that were out there, and all the leading vendors. To see which one was really going to meet our needs the best.

Even doing an upgrade of a system you already have, it again takes time and money. If we were going to spend the time and money, we thought, “Let’s just make sure that we’re using the product that we think is going to best meet our needs.” That led to a vendor selection, and ultimately a decision to implement North Plains.

MM: Sure.

When you say that you did your business requirements and specifically focusing on user requirements, can you describe some of the thoughts and methodologies that you used in terms of conducting that research?

DB: Sure. For that initial assessment, we were, in effect, coming up with our high-level goals for the project.

There were two things that we did. One was, we just ran some reports in our current system to look at the assets that had been put into the system. So we could get a sense of what assets are getting in there regularly and what assets we think should be getting in more often and are not because maybe there’s some obstacle preventing consistent importing. The second thing we did to flesh out the picture was get our super-users together and get their opinions on what was working for them in the system. We brought them in a room with stack of sticky notes and had them categorize the assets they used most and least, and also had them indicate the assets they most want but couldn’t find when they needed them. This helped us validate what we saw from our reports and also helped us identify asset types there are that maybe just aren’t getting in because they aren’t created often or aren’t much sought after. This helped us weed out asset types that might not be needed in the DAM anymore. After seven years it made sense to look back and make sure that our content was being put in the right place.

For our high demand asset types we were most concerned with identifying any obstacles people were having — or some of the perhaps even confusion they were having about what process they were supposed to be following for putting the assets in, and when they were supposed to be putting them in. That was one piece of it.

MM: What sort of obstacles?

DB: If someone says, “I can’t get that asset in regularly,” or, “I’m delaying putting that asset in because it just takes me too long and it’s too complicated.” I’m not saying that happens quite that way. But if people were saying that the import process was too cumbersome, and therefore maybe they were procrastinating in putting certain assets in, or they were only putting in a subset of the assets they were supposed to be putting in. That’s the kind of thing we wanted to identify. We wanted to be able to put some numbers in front of our key users to say, “Okay. We were expecting this many of this particular asset type, and we only got this many. There is demand for this content so there seems to be something wrong.” From there we tried to figure out what the stumbling blocks are that are keeping the content from getting into the DAM when needed.

MM: Would it be fair to characterize this as a kind of workflow management problem? Or a workflow management symptom of an underlying problem?

DB: It’s a little of both, honestly. In some cases, its just people…

MM: Getting lazy.