hilfdirselbst.ch
Facebook Twitter gamper-media
NEU!
Beiträge: 172
9. Jan 2017, 15:42
Beitrag #1 von 8
Bewertung:
(2189 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

DAM "Best Practice" …haben wir uns verfranst?


Hallo HDS-Community,

ich bin für unsere Firma am Eroieren, ob unser bisher gelebter Workflow nicht eine Sackgasse/Stolperstein im Zuge der Allgemeinen Digitaliserung sein könnte.

Unsere Firma ist die letzten 20 Jahre stark gewachsen, doch jetzt fängt man erst an zu begreifen, dass zB intern alle Datenbanken miteinander sprechen müssen.

Ich selber bin Mediengestalter und betrachte den Workflow aus der Perspektive des Produktioners. Und demnächst stehen Entscheidungen an, zB welchen DAM-Hersteller (DAM = Digital Asset Management) wir präferieren wollen.

Doch mitunter beschleicht mich ein schlechtes Gefühl, unseren verkorksten IST-Zustand als Anforderung für das SOLL zu nehmen, und möchte hier gern ein paar Anregungen bekommen, wie es in anderen Firmen gehandhabt wird:


Wir sind ein Möbelunternehmen, hauptsächlich schieben wir Print-Werbeprospekte wöchentlich heraus. Wir haben zum Teil Produkte als Einzelfotografie, meistens aber auf Milleu-Fotos als Artikelsammlung. Da man es als einfacherer erachtet, statt neuer Fotos dann Retuschen anzufertigen, sammelte sich bisher ein unangenehmer Datenwulst zusammen, und Artikel kamen in x-verschiedenen Versioen auf dem Server vor. Zb gib es ein Wohnzimmer zB in den Varianten FensterSommer, FensterWinter, HintegrundBereinigt, ModelPulloverGrün, ModellPulloverBlau, AlphaMaske-Vitrine, Alpha-MaskeVitrine+Tisch, … usw.

Um diese Variantenflut zu bewältigen, einigte man sich intern auf ein neues Medienformat, um alle Optionen sofort umsetzen zu können, und die Varianten innerhalb einer Datei zu halten – die Wahl fiel auf Photoshop-PSD. Hier werden die verschiedenen AlphaMasken zum Einladen/Nachladen angeboten, und über EbenenKompositionen kann man verschiedene Varianten/Szenarien gruppieren.


Hier gibt es zwei Grundlegende Probleme:
1.) Die PSD wachsen gehörig an, zT auf 1gb pro Image, immense Transfervolumina!
2.) Unser aktuelles DAM kann kein Derivat erzeugen, bzw nicht tief genug die PSDs auslesen. Alles wird über InDesign manuell gewählt (Alpha bei Import, und LayerComp per UI). Dafür bringt unser DAM einen InDesign-Connector mit, der äußerst benutzerunfreundlich ist.

Öffne ich ein Projekt, und unsere Prospekte enthalten 300-500 Bilder, ist mein Rechner 10-20 Minuten nur damit beschäftigt, die dicken PSDs lokal zu downloaden.


Lange Rede, kurzer Sinn:
Ich suche nach einem guten Ansatz, um für die Zukunft den richtigen Weg zu wählen. Ich Kleingeist komme auf folgende Lösungen, weiß aber über deren machbarkeit nicht viel. Keiner soll hier Firmengeheimnisse preisgeben, aber vielleicht kann man ohne Namen beschreiben, wie die eigene Firma dieses doch recht häufig auftretende Problem lebt.

1.) PSDs enthalten weiterhin Varianten, dazu…
…muss ein DAM ein Derivat einer PSD mit EbenenComp und Alpha aussspielen können. Dazu gehört ein UI, das einen die richtigen LCs wählen lässt (Preview).

2.) Ein DAM kann so intelligent mit Varianten umgehen,…
…dass ein Housing aller Daten in einer PSD nicht mehr nötig ist, und die Optionalitäten als einzelne Images im DAM liegen.



Für Fragen zum Workflow stehe ich gern zur Verfügung.
Ich würde mich freuen, wenn ich diesen Freitag dem Lenkungsausschuss eine Präferenz geben könnte, wohin die technische Reise gehen könnte… Top
 
X
snafroth  M 
Beiträge: 738
9. Jan 2017, 19:30
Beitrag #2 von 8
Beitrag ID: #554797
Bewertung:
(2067 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

DAM "Best Practice" …haben wir uns verfranst?


Hallo "Neu",

Deine Anforderungen sollten wir mit Elvis DAM abdecken können.

Wir sind inzwischen der Integrator mit den meisten Installationen in Deutschland und haben auch den Connector zu Enfocus Switch entwickelt.

Infos findest Du unter www.elvisdam-plus.de , eine Demo gebe ich Dir gerne jederzeit.


Beste Grüße



--
Sebastian Nafroth +++ 3f8h.net / electronic publishing
3f8h.net offers professional services and products for the graphic arts industry.
contact details: http://www.3f8h.net/
als Antwort auf: [#554790] Top
 
Meister Propper S
Beiträge: 1283
9. Jan 2017, 19:50
Beitrag #3 von 8
Beitrag ID: #554798
Bewertung:
(2056 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

DAM "Best Practice" …haben wir uns verfranst?


Elvis ist wirklich großes Kino!

Ich denke für die Analyse bist Du bei Seb bestens aufgehoben ;-) Und wenn Elvis nicht passen sollte, berät er Dich gerne fachkompetent weiter!

Top Typ!
als Antwort auf: [#554797]
(Dieser Beitrag wurde von Meister Propper am 9. Jan 2017, 19:54 geändert)
Top
 
Uwe Laubender S
Beiträge: 4039
10. Jan 2017, 09:09
Beitrag #4 von 8
Beitrag ID: #554804
Bewertung:
(1908 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

DAM "Best Practice" …haben wir uns verfranst?


Hallo zusammen,

es sei noch hier auf die vorangegangene (oder noch laufende?) Diskussion im amerikanischen InDesign-Forum verwiesen:

DAM Best Practise? Image-Workflow Question
DBLjan Jan 6, 2017
https://forums.adobe.com/thread/2259417

Wirklich spannendes Thema hier, das mir bei meinen Kunden in der ein oder anderen Form laufend begegnet.
*****
Mit herzlichem Gruß,
Uwe Laubender
als Antwort auf: [#554798] Top
 
NEU!
Beiträge: 172
10. Jan 2017, 09:25
Beitrag #5 von 8
Beitrag ID: #554805
Bewertung:
(1903 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

DAM "Best Practice" …haben wir uns verfranst?


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)
Top
 
NEU!
Beiträge: 172
10. Jan 2017, 10:18
Beitrag #6 von 8
Beitrag ID: #554807
Bewertung:
(1861 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

DAM "Best Practice" …haben wir uns verfranst?


Hier noch ein Link auf ein paar PSD-Screenshots unserer Images, und auf Englisch erklärt, wie es dazu kommt und welche Probleme ich erwarte:
https://forums.adobe.com/message/9251648#9251648
als Antwort auf: [#554805]
(Dieser Beitrag wurde von NEU! am 10. Jan 2017, 10:18 geändert)
Top
 
Meister Propper S
Beiträge: 1283
10. Jan 2017, 20:07
Beitrag #7 von 8
Beitrag ID: #554827
Bewertung:
(1718 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

DAM "Best Practice" …haben wir uns verfranst?


Zitat 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.


Der zurückgezogene Beitrag stammt von mir – wollte nicht noch mehr für Unruhe sorgen ;-) Zurzeit sucht jeder (mal wieder) nach der "Eierlegende Woll Milch Sau". Um eine komplette Analyse inklusive Pflichtenheft kommst Du leider nicht rum – und günstig wird es auch nicht!

Wir setzen gerade auf HTML 5 und mehr workflowlastig anstatt nur das DAM zu sehen – alles muss miteinander sprechen.

Und in puncto Zeitplanung! Wir implementieren seit 6 Monaten und sehen so langsam eine solide Startsequenz ;-)

P.S. Mal ganz einfach blöde gefragt?! Warum speichert Ihr die PS Dateien nicht separat in den Varianten ab? Schon mal FlightCheck oder andere Programme ausprobiert die Dir vorab einen PDF Bericht geben und Du diesen einfach ebenfalls hochlädst?
als Antwort auf: [#554807]
(Dieser Beitrag wurde von Meister Propper am 10. Jan 2017, 20:25 geändert)
Top
 
NEU!
Beiträge: 172
11. Jan 2017, 08:25
Beitrag #8 von 8
Beitrag ID: #554837
Bewertung:
(1645 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

DAM "Best Practice" …haben wir uns verfranst?


Antwort auf: P.S. Mal ganz einfach blöde gefragt?! Warum speichert Ihr die PS Dateien nicht separat in den Varianten ab? Schon mal FlightCheck oder andere Programme ausprobiert die Dir vorab einen PDF Bericht geben und Du diesen einfach ebenfalls hochlädst?


Alles steckt in einer Datei, damit unsere Lithografie die Normalisierung über alle Varianten machen kann, auch nachträgliche Veränderungen.

Antwort auf: Wir setzen gerade auf HTML 5 und mehr workflowlastig anstatt nur das DAM zu sehen – alles muss miteinander sprechen.


Alles wird miteinander sprechen, der Scope ist mindestens auf 1 Jahr ausgelegt. Aber irgendwie muss jetzt schon ein DAM-Hersteller gewählt werden, bzw haben wir Eines, welches aber bald abläuft und sowieso suboptimal ist. Die Entscheidung muss irgendwie Ende Februar fallen. Leider kriegt der Einkauf auch eine neue Struktur, für die zwar auch das DAM schon da sein muss, aber die Funktionalität dort wird von allen Herstellern bedient.

Ich betrachte halt meinen InDesign-Workflow, wieviele Probleme wir mit diesen LayerComps haben, und wie bis jetzt sowas eher ins Customizing günge.


Aber vorgestellt habe ich mir das hier so, statt sich auf einen Implementierungspartner und die Komplexität des Themas zu versteifen, dass eher so Wortmeldung kommen wie:
"Also bei uns nutzen wir nur Tifs für Freisteller. Alles andere ist Jpg/Ai/PDF. Die Freisteller werden vom DAM ausgespielt. Unser Quelldaten sind auch PSD." oder "Unser Hersteller ist XYZ, aber wir bilden unsere Retuschen über Varianten in einzelnen Dateiversionen ab." oder aber "Definiert euch lieber ein ordentliches Look-Book, damit nicht so viele Varianten entstehen."

Je nachdem in wessen Antwort ich uns am meisten wiederfinde, würde ich Detailfragen per PM bequatschen, wie zB "Wenn eure Varianten alle einzelne Versionen im DAM sind, was passiert wenn ihr an der Quelle über alle Versionen etwas ändern müsst?"
als Antwort auf: [#554827] Top
 
X