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.
DB: Well I think the big challenge with them overall is that people don't necessarily see importing assets into a DAM as part of their workflow. That's always been part of the Holy Grail for us, of DAM. To devise a system and workflow where people just see it as part of their job. More specifically, where people are interacting with the DAM without even knowing it. That's the ultimate workflow.
I think over the years, we've made a lot of headway with that, where people understand that this is part of their job. But yet it is still oftentimes an extra step they have to perform. Even if they know they have to do it. They still have to do that extra step of putting that file one extra place instead of just having it on their departmental share on a server. They also have to put it into this DAM.
It's those extra steps outside their workflow that we're trying to minimize.
MM: I'm curious, David. What sort of incentives or job definitions or weekly reporting requirements management may have put in, so as to make the creation and tagging of assets more just a seamless part of peoples' work?
DB: Well, over the years, some of it has been a matter of training. Something we did quite a while ago, actually — I think it's probably something like five or six years ago — we got all the managers together. We told them, "All right. We've had our system for about a year and a half and we need to create more commitment and accountability for people utilizing the system".
We pointed out to them that there were some inconsistencies in people getting content into the system. In our workflow, we don't have the luxury of what some other companies have, where they have a dedicated squad of librarians who are sitting there all day importing assets and tagging them with metadata. Here it's the content owners that are doing it.
These are people who have — in effect — real jobs to do in creating the content of the company. Putting content on the DAM is part of their process, but still, it's not the primary reason they're here.
So when we brought the managers together, it was partially to get their buy-in to this. Also, following that, we started doing some reporting for assets that we could predict when they needed to be in the DAM, based on the stage of the publishing cycle of a book. We could say, " These cover images are due as of this date or as of this point in the publishing cycle, or these production files are due as of a month or a week before the book publishes." Something along those lines. In effect we were creating a compliance process.
So at least then we had a mechanism to track how people were doing, and to make sure that at least people would be able to find what it was they were looking for. Then we could chase people down and say, " You missed this import," or something along those lines. That's one of the most direct things we tried to do.
I should also note that it's not all about getting content in the system. The consumers of the content are just as liable for the success of the system. We can't ask for our art department to import cover images if the next day they get ten calls from people in sales or editorial asking them to send them the same cover image. So everyone has to buy into using the system as their primary source for the relevant content or it just doesn't work.
Over the years, we've had what we call "super-users." Each department in effect has a representative who's supposed to be both the knowledge expert on our system — which we refer to as the "Vault." They're the knowledge expert in our Vault system. They're supposed to also advocate it and whenever we're collecting the requirements — like when we did this assessment process — they represent the department as far as voicing what their needs are, in raising any issues, and making change requests.
That's another one of the things we've done to try to reinforce processes and identify any new tweaks that need to be made to peoples' workflow or the system itself.
MM: One of the things in our other interviews that we've heard is that some of the more mature advanced DAM installations have — one — made the creation of files to a particular standard part of the technical definition of an asset-creator's job. Part of the job definition entails a description of their role and responsibility in producing assets.
The second one was a weekly or a monthly managerial reporting system from the front line. It included the number of files created and the number of assets that were tagged. Its just basically counting, "What did you do and what was the activity associated with it?" It seems that just the act of counting something changes the behavior associated with it.
The third thing that we've found — and only in a few cases — this is where you had multiple divisions within a larger corporation. They created an internal stock-media market where divisions basically bought and sold graphics or artwork from other divisions, but usually at 1/10 the fair market price.
In so doing, they monetized the value of a particular piece of file, and created an economic incentive — at least at the level of whoever owned the P&L for the division. They created a financial incentive to make sure that all the troops were — one: creating assets, two: tagging it, and three: promoting them for reuse. And they even went so far as to create an incentive system. A bonus program, whereby the individuals that were creating the highest-quality assets that were most-tagged got special awards and acknowledgments and even some cash bonuses and things like that.
DB: That's an interesting program.
MM: Yes.
DB: I was going to say, for us, the reporting that we've had was more focused on what people are putting in. Trying to enforce it from that side. Doing more tracking in terms of usage is something we haven't had in the past. That's something that I think we'll be doing in the near future.
We're hoping that in the new system, at least at an asset level, the North Plains system allows you to see what usage a particular asset has. For enforcement of intellectual property protection, that's a good thing to have. But since that information is floating around in there somewhere, we're hoping we'll be able to do more robust reporting on that to track usage.
Then, in terms of the individual users and the jobs they're doing — we have formalized somewhat more our super-user program. It's not considered a job unto itself, but now it is considered a formal aspect of these peoples' roles. They're not the only people putting content into or pulling content from the system. But their role has been more formalized, and their role as a super-user requires approval from their manager so that there's awareness and approval that they are taking on this additional responsibility. This role extends beyond just our DAM. These super-users are also provided with some additional reward for their services.
MM: Yes. That's great. We've found that the super-user or ambassador or master practitioner — a lot of different labels for the same thing — for calling out individuals that are the in-department peer. They lead the other people in the department to good use of the system. Those have all been really great programs.
Whether you institute a formal incentive program or not, at least you have the social network part of that in place, and that's great.
Another thing that we've seen in a handful of mature DAM sites has been convening user groups. The user groups get together once a quarter or twice a year. It's generally an off-site, one-day thing where they review the current state of the system, what they like and what they don't like. What they want to do next.
In some of these cases, we've seen — using some ballots — kind of a rating on a scale of 1 to 10 of the kinds of new features they'd like to see. In some cases, they'll bring in subject matter experts. Say, for example, in color-managed workflows. Kind of taking it to the next level in terms of ICC color management — or script automations, be they AppleScript or Adobe Actions or whatever.
Again, all these little short-stroke tactical enhancements to the workflow and the quality of work life. Really creating what we now call an academy of peers, so that we start having cross-fertilization of a bunch of these little process innovations that are usually just a pocket of excellence in one part of the group, but never really propagate because that group never really interacts with the rest of the enterprise. Does that make sense?
DB: Yes.
MM: How would you see that working out at — say, for example — Hachette?
DB: Well, we do try to convene user groups in-house. The only offsite we did was the one I mentioned earlier with the managers. That was more of a buy-in session than a refining of processes or anything like that. We do bring together our super-users, though, to talk through process issues or change requests and things of that nature.
In our company, there are different divisions. They don't compete against each other or anything like that, but just because of the "organic evolution" of the company — because we used to be separate companies that merged over the years — there are different workflows.
So while we haven't pushed too hard...
MM: David, not only are there different workflows — there are different tribes with their own cultural norms. Right?
DB: Some of these mergers happened quite a long time ago. It's not quite that bad. But there are definitely differences in how the different divisions work. The thing is, in publishing, as I'm sure in any company — but certainly in any media company — you're dealing with creative people. Sometimes you can't really standardize a creative workflow, because some workflows aren't quite meant for that.
Nevertheless, some process issues that some people experience when we get these user groups together and people talk about how they're doing a particular process. Sometimes there are those a-ha moments where people hear how another group is doing their process, and say, "Oh, well, maybe we should consider doing it that way." Sometimes that sort of thing does happen.
MM: There are things that we've seen as a function of having researched creative users since 1991. The creative user, whether they're a Mac or PC user, basically thinks of him or herself as a "craftsperson" first. They've invested a tremendous amount of care and concern and time into developing his or her craft. That is how to take an idea through an iterative process and bring it to full realization or fuller realization.
In many respects, that sense of tradecraft and mastery of his or her toolset becomes a filter that repels anything that's not directly related to his or her craft. Oftentimes, the fastest and most direct way of introducing new ways of working or changes in workflow among tradecraft professionals entails, "Look at this." It's a sort of watch-do.
It's almost like watching kids learn to dance. You can't read about it. You can't talk about it. You just have to do it.
So then what we've found in terms of change management programs that entail lots of creative people — it really almost has a Sadie Hawkins Dance vibe to it. That is to say you expose them to new behaviors. New ways of working. Not as a top-down managerial fiat or mandate, but as a peer sharing with other peers, "Look what I'm doing, here."
That's also one of the other aspects of an academy of peers. You get this peer-led learning process of common tools in a shared context. That's what we've found to be the most-effective way of instituting a significant organic change with a minimum of disruption.
DB: That makes sense.
MM: One of the things I'd like to shift to here, David, is — as you did this bottom-up user requirement in advance of either upgrading the Artesia system or deploying the new system, which you subsequently decided on North Plains... At some point, you began to correlate those user needs. User-feature requirements and/or workflow issues... with larger business requirements.
You inasmuch said that — that there's a shift going on in the book industry. Both in terms of its business model and the nature of the market. Then, how we align our workflows and creative processes to these new economic realities.
Could you give us a quick survey of some of the changes you've seen in the book industry, per se? And maybe even address things like social media and social networks becoming part of the bookmaking or authoring bookmaking process?
DB: Sure. When you mentioned business goals, I guess there was one step in our decision-making process I forgot to mention. We took the feedback we got from our super-users, and then we presented that to our senior management — which included representatives of managers from all of our various departments.
We basically put it all in front of them and said, "What should we be focusing on?" This is before we even started any kind of vendor selection. This was just purely, "Here's what people are asking for. What should we focus on?"
We are fortunate to have senior management in place who are very much behind technology projects — recognizing how important having best in class capabilities is to the functioning of the company. Basically, they told us, "If you're telling us that making this system easier to use and making ways for people to get content in there more quickly or more easily and making it easier for people to search for content — if that's important — then let's just do it." If the content's not in there consistently or people can't find it, then what's really the point of the system?
They were behind it. We didn't really have to twist a lot of arms. That then served as the kickoff of our vendor selection, where we said, " Let's go and examine what's out there."
In terms of the book industry — to answer your question — certainly when we first started with our Artesia system, we were already thinking in terms of electronic content — at the time — e-books were emerging and people were expecting them to explode. We had an e-publishing program of sorts, where we set up a program online for soliciting manuscripts and establishing discussion forums. But I don't think the technology was quite ready to support that sort of interaction yet.
We were very early adopters of that sort of thing. But it took some time I think for a lot of that type of online content to shake out. Now there are a couple of new e-readers out there. Sony has their new reader. And of course, Amazon has their Kindle product. So we are very much focused on making the supply chain that supports those products as easy as possible.
We are behind and have committed to the e-pub format for e-books. The idea is that we're able to produce one industry-standard version of an e-book that can then be repurposed for reading on any device.
As far as social media and social networks go, we are about to launch our new corporate website. There is going to be — I believe — some focus in there on giving people more ways to find out where we're having a publicity event such as readings or book signings.
Also with our digital warehouse project, known as OpenBook™— which I mentioned earlier — where we are posting up portions of our content on the web. We have the option for people to use a widget that's basically a piece of code that would allow them to post a snippet or a link to that snippet on a MySpace page or their own blog or wherever they like.
If someone says that they like the new James Patterson book, for example, they can say, "Hey. I just read this great excerpt from the new James Patterson book. Go check it out." Someone can post that on their blog, and it'll have a little cover image or something like that from the digital warehouse. This actually combines social interaction and digital content.
We're certainly trying to get more into the viral marketing aspect of our books, to build some word of- mouth, there. That's perhaps a bit outside of the DAM, but certainly as efficient as we can make the process of getting the content up there, the better off we'll be.
MM: I had a conversation with Steve Sauder, the CTO of North Plains. I was asking him what were some of the new things — innovative things — he's seen his users do. He mentioned the fact that the telescope product always had this yellow sticky note capability. You could attach a yellow sticky note to an asset to tag it with unstructured content.
He said, "Really, now, we're beginning to think about using a wiki or a forum discussion board-like approach for users to comment, to tag, to put a story around the assets. Using that textual data that users put in. The story or the back-story. Using that to enrich the search function.
So, now social media blog forum discussion threads — using social media has a new class of metadata. One: for putting an asset or a class of assets into context. And, two: to facilitate their retrieval by more sophisticated search functions, as you've described.
Does that make sense to you? If so, could you expand on that idea in terms of how it might play out in your particular business?
DB: Yes. We haven't looked into that North Plains function too much. I can see, though, the value of that type of interaction, as in the YouTube model. From what I've been told, they use a similar concept. Rather than trying to force people to "tag" a particular video clip when you do a search, it's really searching the comments people make on the video clips. There's this recognition that the people who are making the comments are the ones that in effect are inadvertently tagging the video.
MM: There's actually a term they use to describe that. They speak of it as a "folksonomy."
DB: Right. Yes. That makes sense.
So for us, I can certainly see that publishers who are doing a lot of repurposing of assets... Let's say an educational publisher or someone who's publishing cookbooks or something like that... where they say, "Okay. I want to find a picture of a bird or a picture of General Custer, or something like that." I can certainly see how that sort of thing would be valuable. People just within the network are putting in comments and you're able to search that sort of thing to identify assets that might meet your conceptual search criteria. This also alleviates some of the burden for tagging assets with metadata upfront.
That does make a lot of sense. For us, just within Hachette Book Group, we don't do too much educational and reference kind of publishing where this sort of thing can have a major impact. I think it may have more limited use for us. We have talked about it somewhat, because we do do some collections like short stories and poems. We also do some cookbooks and things of that nature.
So there is the potential to have that sort of reuse down the road. I have seen the notes function in North Plains. The project we've undertaken has had a pretty rapid timeline. So we haven't gone too much into that sort of advanced workflow. But it is something that I think once everyone's gotten their hands dirty with the new system and there's a comfort level with it, I think we will have to circle back and start looking at the more advanced function that we might want to utilize for the workflow here.
We also don't necessarily consider the DAM as the best tool for this sort of feature where people are sharing ideas and feedback. There are other tools like SharePoint that are more well equipped and that can be integrated with DAM so that people are using one portal for finding content and sharing ideas.
MM: This brings me to another idea that I wanted to float by and have you comment on.
In a conversation or actually an interview with another very sophisticated DAM site, this was done in the area of pan-regional localization of content. Their CTO basically said to me that the mark of a good workflow system or the mark of a good system is that if you have a deadline and it looks like you're going to be pulling an all-nighter, does the system help you get through the project? Or is the system primarily an impediment to making the all-nighter work?
It was a really crisp distinction. A lot of the DAM systems are "additive." They create more work for the primary workflow, as opposed to removing or easing the burdens associated with the primary workflow. Does that make sense?
DB: Yes.
MM: I'm curious as to how you have or how you anticipate using DAM-enabled capabilities to ease the workflow burden of the primary business of creating books.
DB: Well, I would say that for the actual creation of the physical book — the actual thing that's manufacture and shipped out of our warehouse or the audio production and so on... Yes. For that, I'd say in the near-term, that's a little outside of what we're doing right now.
I think once we start looking at integrations with Adobe Bridge — which we're hoping to do later this year — that's where we might start seeing more pickup in making it easier to create the final product. Then people would be able to have the assets in earlier. People would be able to work on them as if they're working on it off of a share, or something like that. That's where perhaps it will become easier.
I think where we get the greatest benefit is more downstream — where people are reusing assets to create catalogues and to create sales materials and marketing materials. Let's say our sub-rights department wants to sell to licensees, knowing that they can just get our book files right out of our system and send them off to a licensee who's halfway around the world. That's where we really see — I think — improvements in the workflow. There, people are getting "instant gratification" for the content they need, rather than having to call up a printer and have them send a disk out to somebody. They can just get it right out of the system and send it on its way.
I'd say it's more on the consumer side that we see improvements in the workflow. I think improvements in the actual production of the book files takes more than just a DAM. Something that we've resolved after seeing some attempts by vendors to incorporate workflow into their systems is that we don't really think DAM is the greatest vehicle for workflow. It can certainly support it. It can be a backend for it. But I wouldn't say we'd want to build workflow directly into it.
So I think right now, we're looking at a lots of ways to improve the workflow of the company — XML-based workflow and things of that nature that will hopefully speed up the creation of the product, and the DAM behind that. But I don't think the DAM in and of itself will — with the exception of what I said before about Adobe Bridge and integration with Adobe Bridge, will really speed the workflow. The creation side of it, at any rate.
MM: When you speak about an XML workflow, you're basically saying the textual material of a book will be tagged with XML content in some sort of an XML database. And that the physical assets — whether they're the style sheets or the graphic or multimedia assets — are also similarly tagged. So that as the book goes through its work in process, you're basically dealing with material that's all tagged XML content in a database. Therefore, it's all fluid and easy to manipulate. Easy to reflow. Is that what you're talking about?
DB: Yes. In effect, we're looking to work within templates. Both so that we can pull out content more easily down the road — let's say to our digital warehouse or to support some sort of e-commerce, if we ever want to chunk up our books. But also, just to speed up the process. Not so much downstream, really — but in the production process. Tagging it in such a way that you can go straight to a printable PDF file that we're sending to our printers, based on that tagged file.
You're sort of cutting out some of that middle work of what you were saying — having to worry about the flow of the text in the book and things of that nature. That's what we're looking to make improvements in.
We actually do, right now though, have tagging of our book files. So we can pull out promotional excerpts and reading group guides and things of that nature. But that's tagging that is done later as part of the composition process. It's not currently part of the initial creation and editing process. I think that's what we're looking to do, now. To move the tagging more upfront in the process, so people who are working in these templates from day one can create the print-ready files more easily.
MM: Fabulous.
As we begin to conclude our interview, what sort of things do you intend to present at the upcoming Henry Stuart DAM and [MOM] symposia?
DB: We're going to talk about our journey in the past year. It was a little less than a year ago that we started this assessment, where we recognized that the time was really due for us to do something with our DAM — to upgrade it. Where we started bringing our users together.
I'll be talking through how we got them involved, what we asked them, what kind of feedback we collected from them. Where we asked them to identify — in effect — what's the content you are using? What's the content you want to use but can't find or can't find when you need it? What are the barriers you're facing to getting the content in for the people who are the owners of the content?
Then once we collected that feedback, how we were able to summarize it and put it in front of them and in front of our senior management, to set our overall goals for the project — and then moved into our vendor selection phase. Again, how we went through that process and had the users involved and had them evaluate the vendors.
I wouldn't expect us to be presenting anything in terms of real details there with ratings and so on, but at the very least, talking about the process we went through. Then with the actual project itself, we've had an accelerated model for this process. So how we scoped it out and figured out what was most important to get out of this initial deployment. And how we've moved through that.
Right now, we're still in the final month of our project. But I would expect that certainly by the time Henry Stuart rolls around, we'll have been live for a couple of months, and can hopefully have a little more to say about the actual deployment itself, and how that went.
MM: Excellent.
As you begin to imagine yourself delivering this presentation, who would you describe as the ideal delegate or participant/attendee to your presentation in terms of job function, technical skills and so on and so on?
DB: Right. Anyone who I suppose is managing a DAM system or process. So, people who are in a similar role to the role that I'm in and that the people in my department are in. Those who are trying to juggle the needs of the business and the users using the system, and the IT side.
Even people who are first starting out with DAM, but also people who perhaps have mature DAM systems and are struggling with or think about where they're going to go next with it. Because that's where we've been at it for a while. We implemented our first DAM in 2000. So I think even though there's sometimes a lot of emphasis on people who are just getting started, I think now that space has matured to the degree that anyone who's got a mature DAM and is trying to wrestle with, "Well, okay — now what do we do and how do we get started?" I think that it would be applicable to people like them.
Then anyone who's probably in the print or publishing business, certainly — who's just curious of what we're doing with our DAM — would probably also find it interesting.
MM: Excellent. David — thank you again very much for spending the time with us today. I look forward to seeing you in person there at the Henry Stuart Event in New York, and perhaps beyond.
