Rethinking Digital Asset Management

Im Jahre 2015 wurde die langjährige Picturepark-Mitarbeiterin Olivia Schütt zur Produktmanagerin des Picturepark-Systems ernannt. Schütt übernahm eine schon länger eingeführte Applikation mit einer beträchtlichen Benutzerbasis gerade zu einem Zeitpunkt, als die Digital Asset Management-Branche eine längst überfällige Selbstbeschau durchführte. Analysten berichteten über die niedrige Zufriedenheit der Benutzer von DAM-Software mit ihren Lösungen, die Industrie hatte sich nicht so explosionsartig entwickelt wie prognostiziert, und Blogs begannen auf einen Mangel an Produktinnovation hinzuweisen.

In diesem Spannungsfeld entschied sich das Team von Schütt, nicht nur das Picturepark-DAM zu verbessern und dabei Kundenwünschen zu entsprechen, sondern auch die Branchen-Erwartungen zu übertreffen und vor allem das Produkt für das nächste Jahrzehnt im Digital Asset Management vorzubereiten.

Die Vorbereitung dauerte ein ganzes Jahr, bevor das Team überhaupt mit der Programmierung begann.

Was geschah während des ersten Jahres der Entwicklung dessen, was Picturepark 9 werden sollte?

Picturepark 8 war und ist eine großartige Applikation für Digital Asset Management. Aber DAM basiert auf einem Dateimanagement-Ansatz, der mittlerweile älter ist als die meisten unserer Mitarbeiter!

Wenn es Nutzern um das bloße Management von Dateien geht, funktionieren Picturepark 8 und einige andere DAM-Systeme ziemlich gut. Organisationen wollen aber heute mehr als nur Dateien verwalten. Social Media-Posts, Dokumente aus Google Docs, Unternehmensbotschaften – all das sind Beispiele für Inhalte, die Sie nicht erst in einer Datei ablegen wollen, um sie in ein DAM hochzuladen.

Aber natürlich müssen Unternehmen auch diese virtuellen Inhalte verwalten, von denen viele in Web-Anwendungen erstellt und vorgehalten werden. Sie wollen Links zu Archiven und zentralen Zugang zu dialogorientierten Vertriebsinhalten tweeten – nicht nur Preislisten und Präsentationen, sondern Messaging. Was sagen wir, wenn ein Interessent X, Y oder Z fragt? Wo sind diese Inhalte zu finden?

Und was ist mit der Verwaltung und der „Wiederfindbarkeit” wertvoller Inhalte, die Sie gar nicht besitzen? Beispiele sind YouTube-Videos, die für Trainings nützlich sind; oder irgendwelche Websites, die für Ihre Vertriebsteams hilfreich sind. Oder stellen Sie sich vor, dass Sie Ihre eigenen Metadaten für Bilder oder Videos verwalten können, die Sie online bei Agenturen wie Getty oder Shutterstock finden. Diese verwenden vielleicht den Tag „Menschen unterhalten sich” für ein Bild, das für Sie für „Kundenevent 2017“ steht. Sie wollen nicht all diese Bilder gleich kaufen, um sie in Ihr DAM hochzuladen, aber Sie wollen sie auch nicht wieder aus den Augen verlieren.

Wenn Sie all diese Inhalte verfolgen und die von Ihnen benötigten Metadaten hinzufügen können, dann werden sie für Ihre internen Teams findbar und somit wertvoll. Es geht nicht mehr nur um Dateien, die Sie speichern und hoch- und herunterladen können, sondern um Dateien, mit denen Sie auf den verschiedensten Wegen in Kontakt kommen.

Und dann haben Sie diese zusammengesetzten Inhaltstypen wie die Inhalte auf Ihren Landing Pages, in Ihren Pressemappen oder alle Details zu Ihren Produkten. In diesen Beispielen geht es um Inhalte verschiedener Typen, mit und ohne Dateien, neu erstellt oder wiederverwendet, die alle sicher verwaltet werden müssen – eine Aufgabe, die immer komplexer wird.

Sie können diese Seiten in einem Content Management-System für Websites erstellen wie etwa WordPress oder Sitecore – aber es ist nicht einfach, diese Raw- und Live-Inhalte über das Backend des Website-CMS zu verwalten. Die Nutzer sind gezwungen, Inhalte von einem System zu exportieren und sie in ein anderes Format zu bringen, um sie auf der Website verwenden zu können. Das ist eine Menge Arbeit und es fällt schwer, die Website synchron mit Ihren Stammdatensystemen zu halten.

Zudem: Wenn Sie ein solches System aufsetzen, dann ist es nur ein System. Tatsächlich müssen Sie diese Inhalte aber wahrscheinlich auch in anderen Systemen verwenden. Wollen Sie wirklich solch komplexe Verbindungen zwischen all diesen Systemen aufbauen? Natürlich nicht.

All dies führte zu unserem Grundgedanken – dass wir aufhören müssen, uns darum zu kümmern, wo Inhalte sind, wo sie gebraucht werden und in welchem Format sie vorliegen. Picturepark sollte eine Drehscheibe für Inhalte werden, die für reale Applikationen wirklich einfach zugänglich ist – nicht nur in der Theorie.

Eine echte Herausforderung waren dabei die Beziehungen zwischen all diesen Inhalten. Ein Tweet kann sich auf ein Produkt oder ein Event beziehen, oder eine Landingpage enthält vielleicht Bilder oder Texte, die separat im System abgelegt sind.

Es ging also nicht nur darum, den Nutzern die Sorge darüber zu nehmen, wo Inhalte abgelegt sind oder woher sie kommen – es war noch wichtiger sicherzustellen, dass sie die Beziehungen zwischen all diesen Inhalten verfolgen können. Dabei geht es nicht nur darum, in welchem Projekt sie verwendet wurden, sondern in welchem Kontext.

Im Jahre 2012 haben wir die Technologie der adaptiven Metadaten erfunden, weil wir gesehen hatten, dass diese „One size fits all“-Metadatenschemas traditioneller DAMs einfach nicht mehr praxisgerecht waren. Wir konnten damals gar nicht erahnen, dass dieser neue Ansatz perfekt war für das, was wir als nächstes tun müssten. Stellen Sie sich semantische Metadaten als „adaptive Metadaten 2.0“ vor.

Okay, es war also klar, was wir anbieten wollten – nun untersuchten wir, in welcher Form wir dies für Picturepark 8 entwickeln konnten. Wir testeten alles, was wir uns nur vorstellen konnten – in jeder denkbaren Kombination.

Mit einem klaren Ziel vor Augen begannen wir unsere Research – die Suche nach Möglichkeiten zur Erweiterung für Picturepark 8. Größtmöglicher Nutzen einer Content Plattform mit geringstmöglicher Veränderung für bestehende Kunden. Wir haben wirklich unzählige Kombinationen und Möglichkeiten durchgespielt und getestet.

Ehrlich gesagt ist es uns vorgekommen als würden wir versuchen einen LKW zum Fliegen zu bringen. Natürlich kann man Flügel anbauen, aber am Ende hat man weder einen perfekten LKW noch ein Flugzeug und es sieht auch recht hässlich aus.

Wir kamen zu dem Schluss, dass es zwei mögliche negative Ausgänge gäbe bei dieser Art von Funktionserweiterung in Picturepark 8. Am Beunruhigendsten war dabei die Gefährdung der Stabilität von Picturepark 8. Darauf wollten wir es nicht ankommen lassen, bei einem System, dass weit verbreitet eingesetzt ist, in unternehmenskritischen Anwendungen. Die zweite beunruhigende Tatsache war, dass nicht alle unsere Kunden und Interessenten bereit wären für die Funktionsvielfalt der neuen Picturepark Content Platform. Daher wäre eine Update in dieser Größenordnung mehr als störend.

Als wir dann weitere Prognosen erstellten und herausfanden, dass ein kompletter Neustart auf Basis neuester Technologien mit einem klaren Fokus auf API (API-first) nicht viel länger dauern würde als die Änderungen, entschieden wir uns für das radikalste Vorgehen, aber mit weniger Kompromissen, die auf lange Sicht zu Problemen führen könnten.

Zudem wurde bei Picturepark 8, sowie nahezu jedem anderen etablierten DAM System auf dem Markt, die API jeweils nachträglich hinzugefügt. Aber Kunden und Partner heutzutage haben mehr Anforderungen an ein System und uns war ganz klar bewusst, dass wir diese Anforderungen nur erfüllen können, wenn wir ein System entwickeln, dass die API als zentralen Bestandteil in den Mittelpunkt stellt und zwar von Anfang an – API-first wie man sagt.

Das war also der Anfang der Picturepark Content Plattform.

In welchen weiteren Punkten unterscheidet sich die Picturepark Content Plattform von traditionellen Digital Asset Management-Systemen?

Unser Managementansatz des „any content, anywhere“ und die semantischen Beziehungen der Inhalte untereinander sind die wichtigsten Unterscheidungsmerkmale. Um diese neuen Technologien aber optimal zu unterstützen, haben wir einige neue Tricks angewandt, die richtig cool sind.

Für die Erstellung und Verwaltung virtueller Inhalte in Picturepark haben wir zum Beispiel auf dem auf APIs basierenden „headless CMS“-Konzept aufgebaut. So kann Picturepark eine Plattform für die Erstellung der genannten komplexen Inhaltstypen sein und gleichzeitig als Stammdatenquelle für nachgeschaltete Systeme für Product Information Management (PIM), für durchsuchbare Datenbanken von Websites und mehr dienen.

Bei der bestehenden Picturepark Port Architektur haben wir uns konzeptionell bedient, um virtuelle Inhalte auch via API oder einfachen Code Snippets so zur Verfügung zu stellen, dass diese dann je nach Kundenwunsch formatiert und präsentiert werden können. Dadurch können Web-Agenturen oder Web-Entwickler auf einfache Art dynamische Microsites erstellen, mit den Masterdaten aus Picturepark oder einem nachgelagerten System, wie ein PIM oder ERP.

Um die semantischen Beziehungen zu ermöglichen haben wir dann mehrdimensionale Listen entwickelt. Sie sind vergleichbar mit kontrollierten Vokabularen, jeder Begriff kann aber sein eigenes Set von Attributen haben. Diese Attribute können sogar zu anderen Listen verlinken.

Was ist der Nutzen mehrdimensionaler Listen?

Sie können Beziehungen zwischen Begriffen aufbauen, womit die Zuweisung eines Tags zusätzlichen Kontext bietet, der sonst die Zuweisung mehrerer Tags erfordern würde.
Nehmen wir als Beispiel ein Foto einer Veranstaltung. Mit den heute in Picturepark 8 verfügbaren adaptiven Metadaten können Sie eine Metadatenebene hinzufügen, die spezifische Felder für Events bietet wie etwa den Namen, das Datum und den Ort der Veranstaltung oder die Produkte, die Sie auf der Veranstaltung präsentieren werden.

Mit der Content Plattform wird dies noch einfacher und effizienter. So kann die Veranstaltung selbst ein virtuelles Objekt sein, das Namen, Datum und Ort enthält. Das Feld für den Veranstaltungsort kann zu einer Liste von Ländern verlinken. Diese Länderliste kann wiederum mit einer Liste der in jedem Land gesprochenen Sprachen verbunden werden.

So können die Inhalte durch die Zuweisung eines einzigen Tags – zum Beispiel den Namen der Veranstaltung – all diese zusätzlichen Metadatenwerte erben. War die Veranstaltung in Berlin können Sie also Eventbilder aus Berlin finden, auch wenn „Berlin“ nicht explizit zugewiesen wurde – einfach, weil das Feld „Ort“ den Tag „Deutschland“ enthält, der wiederum einen Bezug zu Berlin herstellt.

Oder Sie suchen nach Datensätzen für Produkte und sehen die Veranstaltungen, auf denen die jeweiligen Produkte vorgestellt wurden. Sie können auch die Inhalte sehen, die dafür verwendet wurden, wie etwa Beschilderungen, Broschüren und mehr. In Beziehung stehen auch die Inhalte, die aus der Veranstaltung resultierten – Beispiele sind Fotos oder Kontaktlisten.

Wie wird die neue Plattform bestehende Picturepark-Kunden betreffen?

Im Rahmen der Überlegungen zum Design der Content Plattform machten wir uns auch Gedanken über die Migration. Wir haben einfach so viele Kunden, die wir natürlich nicht im Regen stehen lassen wollen. Auch der Wechsel „von Hand“ auf einer Fall-zu-Fall-Basis ist keine Option. Daher haben wir uns schon während der Entwicklung der neuen Version auch mit der Entwicklung und dem Test von Werkzeugen für die Migration befasst.

Zudem entwickeln wir die Content Plattform stufenweise. Damit haben unsere Kunden Zeit, das neue System abzuwägen, dafür zu planen und Mitarbeiter zu schulen. Sie werden nicht gezwungen sein, über Nacht auf das neue System zu wechseln. Wir sind aber fest davon überzeugt, dass Sie schnell erkennen werden, was Ihnen die Content Plattform ermöglicht und wie viel einfacher sie zu nutzen ist – und dass Sie ziemlich bald wechseln wollen.

Andere Interviews in dieser Serie:

• David Diamond, Direktor von Global Marketing bei Picturepark, spricht darüber, ob Produkte wie die Picturepark Content Platform der Tod des Digital Asset Management sein werden. Lesen Sie dieses Interview »
• Stefan Seidl, Technology Program Manager bei Picturepark, erläutert Änderungen des Picturepark APIs und welche neuen Möglichkeiten der „API-first“-Ansatz bietet. Lesen Sie dieses Interview »
• Urs Brogle, Direktor für Engineering bei Picturepark, berichtet über die Entwicklung der Content-Plattform – welche Technologieentscheidungen getroffen wurden und die Herausforderungen, denen das Team ausgesetzt war. Lesen Sie dieses Interview »

Erfahren Sie mehr über die Picturepark Content Plattform »