Hallo Sebastian,
Danke für deine Empfehlung. Leider sind wir zeitlich etwas in Verzug, bzw. haben uns schon mit Firmen getroffen (zB OpenText, Celum, Cantus, SAP), und bei der Prozessanalyse festgestellt, dass unser jetziges Handling suboptimal ist.
Entweder suchen wir nach einer DAM-Software, die LayerComps und Alphas gut handeln kann (Preview + Derivat aus LC/Alpha), oder wir suchen nach einem veränderten Ansatz für unsere Printproduktion.
Zur Zeit haben wir sogar eine DAM-Lösung im Einsatz, so halb-implementiert seit 5 Jahren: Die Ambitionen waren groß, doch anstatt der automatisierten Ausgabe mit priint:comet kam die ganze Architektur nicht ins Rollen, und es scheiterte sowieso am CRM.
Nichtsdestotrotz begann man die DAM-Datenbank mit Assets zu füllen, man erdachte sich einen neuen Image-Workflow mit unserer Lithografie, hauptsächlich fokussiert aus der Ecommerce.
Aufgrund unseres sprunghaften Geschäftsführers müssen wir, auch mal 1 Tag vor Abgabe Druckdaten, hier und da flexibel auf seine Launen reagieren können – und haben deshalb nur die Möglichkeiten der Retusche. Folglich weisen Bilder unterschiedliche Varianten auf, zB dass der Pulli eines Models als Freisteller nicht mehr zur Hintergrundfarbe passt, und deshalb umgefärbt wird. Dazu kommt noch, dass man aus Bildern Retuschen als neuen Artikel generiert, sprich "deutsches" Label wegretuschieren und schon ist das Bild gültig für andere Länderversionen…
Meine Sorge ist einfach:
Wie soll man diese nicht erfassten Daten in einer Datenbank produktzugehörig umgehen? Kann man überhaupt einen Bezug zu einer Ebenenkomposition in einer Datenbak abbilden?
Deswegen: Müssen wir als Firma weg von diesen ganzen Varianten innerhalb einer PSD, weil ein, z.B. Euch bekanntes DAM, Varianten und 1:n und n:n-Beziehungen, aus diesen Fotoshop-Layercomps referenzieren kann?
Oder aber behalten wir diese dicken PSDs im DAM, denn ein pfiffiges DAM erkennt die Optionen des PSD-Assets und kann diese, durch eine UI zur Auswahl der Layercomp und Alphamaske, konvertiert ausspielen, sodass mir zB in InDesign ausgedünnte Tifs zugespielt werden.
Soweit ich das bisher auf den Präsentationen gehört habe, unterliegt den meisten DAM-Herstellern zur Bild-Konvertierung ein Produkt namens Image-Magick. Wer weiß denn hierzu, wie powerful eigentlich die Engine zum Auslesen aus PSDs ist?
Gestern stand hier noch ein zurückgezogener Beitrag, der genauer die Schnittstellenproblematik und das große Projekt beleuchten wollte – dazu nur: klar soll das DAM dazu ein SAP-CRM und ECommerce bedienen, und die typischen Features aufweisen, wie Up- und Download-Portale, Versionierung, Freigabeprozesse, Workflows. Das führt etwas zu weit und wird von wichtigerer Stelle geplant und ausgeführt, da stecke ich nur als Mediengestalter in InDesign drin, der sein Workflow für die Zukunft etwas "gängiger" machen will.
Wir sind noch in dem Prozess, dass der "Einkauf" vor seiner Haustür kehrt und überhaupt eine zu beschickende Datenbank bekommt, bzw die Anforderungen definiert. Derweil wird eine IT-Architektur aufgebaut, an die vielleicht jetzt schon in Bezug auf Image-Server gedacht werden müsste. Oder wäre hier wiederum eine Cloud-Lösung denkbarer, wenns DAM kleinere Daten auspielt?
…und deswegen auch nicht der Wunsch einer großen Beratung mit Gesprächen und Terminen – dafür sind wir jetzt eigentlich schon zu spät. Aber ich würde mich freuen wenn hier Stimmen wären wie "Hey, wir haben das mit den vielen Varianten so und so und ähnlich gelöst, weil…"
Danke im Vorraus.
Jan
als Antwort auf: [#554798]
(Dieser Beitrag wurde von NEU! am 10. Jan 2017, 09:30 geändert)
