Ende 2016 hatte ich das Vergnügen, gemeinsam mit Gregor Fellenz, dem Autoren des Buches „InDesign automatisieren“, ein nicht ganz triviales Projekt einer Preislistenautomatisierung umsetzen zu dürfen.
Am Ende wurden etwas über 20 Preislistentypen auf Basis von drei Musterseitentypen viersprachig auf Basis strukturell identischer Datenabzüge aus Microsoft Dynamics erzeugt und in InDesign mit statischen Inhalten zu Buchdokumenten zusammengeführt, um sie von dort für Print und Web ausleiten zu können. Dabei wurden auch Symbolschriften eingesetzt, die eigens für diesen Zweck in Fontographer geschaffen wurden.
Weil diese Zusammenarbeit äußerst effektiv und das Ergebnis so erstaunlich fehlerfrei war, fragte ich Gregor, ob er sich vorstellen könnte, auf unseren Blogs jeweils aus unserer Perspektive die gleichen Fragen zu beantworten: In der Hoffnung, darüber unseren Lesern einen Eindruck davon zu vermitteln, wie man in die Lage kommt, solche Projekte innerhalb eines definierten Timings und mit definiertem Budget erfolgreich umsetzen zu können.
Und los geht’s mit meiner Sicht:
Wann sollte ich eine Aufgabe automatisieren?
Es gibt eine ganze Reihe von Gründen, weshalb es sich lohnt, bestimmte Aufgabenstellungen bei der Umsetzung von Produkten im Printbereich nicht manuell, sondern besser über eine Form von Automatisierung zu lösen. Manche dieser Gründe sind, je nach Perspektive und eigener Verortung im Prozess, offensichtlich – andere hingegen überhaupt nicht.
Als Faustregel mag gelten: Wenn die Umsetzung extrem viel Zeit frisst oder außerordentlich große Seitenumfänge liefern muss – dann wird eine Teil- oder Vollautomatisierung immer eine Erleichterung darstellen; sei es durch Zeitersparnis – oder durch weniger Fehler im Endprodukt.
Häufig kann man sich gar nicht vorstellen, dass die Aufgabe automatisierbar ist. Daher ist es durchaus sinnvoll, sich mal aus dem Tagesgeschäft auszuklinken und zu überlegen, ob durch kleine Veränderung im Prozess die Automatisierung möglich oder sogar äußerst effektiv werden kann.
Was benötige ich für eine Anfrage?
Zunächst muss geklärt werden, ob die Aufgabe tatsächlich geeignet ist, über eine Automatisierung gelöst oder unterstützt zu werden. Wann immer manuelle Eingriffe in Datenexporte erfolgen – und diese Pflege nicht direkt an der Datenquelle durchgeführt werden kann – stellt sich schnell die Sinnfrage.
Auf der anderen Seite sollte man, wenn darüber massive Zeitersparnisse oder deutliche Reduktionen von Fehlerquellen realisierbar sind, auch dann eine Automatisierung ins Auge fassen, wenn schon vollkommen klar ist, dass der Prozess auch künftig immer manuelle Anteile enthalten wird.
Ein Datenbestand als Basis für die Automatisierung, der strukturell nicht gepflegt ist und aus diesem Grund manuelle Nacharbeit erfordert, ist allerdings keine geeignete Quelle für ein Skript oder ein datenbankgestütztes Tool. Ohne saubere Daten keine Automatisierung.
Wie gelingt die Umsetzung?
Kommunikation ist Trumpf. Wenn ich meine Anforderungen klar formuliert habe und in der Lage bin, fehlende Informationen an nachgelagerte Stellen weiterzuliefern, wird es selten zu echten Problemen kommen, die am Ende nicht lösbar sind. Aber als Auftraggeber (oder –überwacher) muss immer voll und ganz bei der Sache sein und nachfragen, wenn irgendwelche Details haken.
Ich unterstelle mal, dass auf Seiten der Auftraggeber selten klar ist, dass die Umsetzungsseite nur dann wie gewünscht arbeiten kann, wenn ich als Initiator meine Hausaufgaben gemacht habe und stets bereit (und mit der notwendigen Zeit ausgestattet) bin, neue Hausaufgaben anzunehmen und zügig zu erledigen. Dazu muss ich aber auch in der Lage sein einzuschätzen, ob die zurückgeworfene Aufgabe denn tatsächlich dem Endziel dient – oder ob darin bereits erkennbar ist, dass die Umsetzung vielleicht Felsen abtragen möchte, um die man auch einfach herumlaufen könnte.
Wie kontrolliere ich das Ergebnis?
Es gibt keine „zufällige“ Ausgabe, wenn eine Automatisierung am Start ist. Jede Ausgabe ist das Ergebnis einer gesteuerten Übersetzung von Daten in etwas visuell Erfassbares – wenn dabei etwas anders aussieht, als man es erwartet hat, muss man kontrollieren, ob die Abweichung von der technischen Umsetzung herrührt. Oder ob das unerwartete Ergebnis die Konsequenz von unzureichenden Voreinstellungen oder Lücken im Anforderungsprofil ist.
Je besser Auftraggeber und –überwacher die Macken der beteiligten Software kennen, desto besser kann der Umsetzer auf seine gestellte Aufgabe vorbereitet werden und erst so wird es möglich, gemeinsam mit ihm klären, was als Ergebnis erwartet wird. Die Menge der Dinge, die durch diese intensive Zusammenarbeit und enge Abstimmung nicht umsetzbar sind, ist erfahrungsgemäß sehr gering. Grenzen setzen eher Timings und Budgets.
Tests sollten in Stufen stattfinden – prüfen Sie zunächst immer mit einem kleinen Datenbestand, der alle Aspekte der Automatisierung abfragen und nutzen sollte. Wird dazu immer der identische Datenbestand genutzt, fallen Änderungen an der Ausgabe schneller ins Auge – und man kann sich besser eine Meinung bilden, ob die Veränderungen erwünscht oder unerwünscht sind. Im zweiten Schritt weitet man Umfang und Ausprägung der Daten aus, um möglichst viele verschiedene Eingaben daraufhin zu überprüfen, ob sie eine gleichförmige Ausgabe erzielen.
Ein häufig zu beobachtender Kardinalfehler ist, dass „kleinere“ Ungereimtheiten in der erzeugten Ausgabe hingenommen und nicht kommuniziert werden. Oft wird so etwas über manuelle Nacharbeiten aufgefangen. Kommt es im Fortgang zu weiteren Veränderungen in der Steuerung, addieren sich diese Fehler nicht nur, sie multiplizieren sich – oft bis hin zur völligen Eskalation. Daher ist es so wichtig, möglichst zu Beginn des Projektes schon genau zu wissen, wie das Endergebnis aussehen soll; und die Lieferung des Umsetzungsdienstleisters immer wieder gegen dieses vereinbarte Ziel zu prüfen um auch kleinste Abweichungen zu erkennen, zu kommunizieren – und dann effektiv abstellen zu können.
Budget? Das wird doch eh’ nie eingehalten
Gregor und ich haben in unserem konkreten Projekt den Gegenbeweis angetreten; das Budget kann durchaus eingehalten werden. Der Trick besteht einerseits darin, des Scope des Projektes stets im Auge zu behalten und andererseits beidseitig zuverlässig und zügig zu kommunizieren.
Grundsätzlich ist das ganz einfach. Ganz sicher implodiert ein Budget aber immer, wenn einzelne oder Kombinationen folgender Dinge passieren:
- Unklare Aufgabenverteilung
- Offene oder verdeckte Kommunikationshindernisse
- Fehlende Detailausarbeitung der zu erzielenden Lösung (beidseitig)
- Problematische Datenlieferungen
- Unzureichendes Testing (beidseitig)
Je komplexer ein Projekt ist, desto teuflischer können sich unerkannte Probleme im Fortgang des Projektes auswirken. Es ist daher ungeheuer wichtig, stets festzuhalten, an welchen Punkten Unerwartetes passiert, damit beide Seiten einen für beide geeigneten Ausweg festhalten können. Bei umfangreichen Aufgabenstellungen ist zu Projektbeginn selten wirklich definierbar, was die Lösung am Ende alles leisten können muss. Die Gründe für dieses Fehlen von Informationen sind vielfältig und oft genug gar nicht im Projektteam zu verorten. Fakt ist jedenfalls: Ist der Auftrag nicht klar genug umrissen, kann die Umsetzung nur scheitern; weil immer mehr Punkte eingefangen werden müssen, die als vermeintlich unverzichtbar gelabelt sind. Die Konsequenz daraus: mit kleinen Schritten anfangen, Zusammenarbeit prüfen, Kommunikationsmuster erkennen und dann langsam ausbauen. Und zwar möglichst ohne Teams und Kommunikationswege zu verändern. Denn dann fängt man wieder von vorne an.
Wenn Sie das beherzigen, werden auch Sie am Ende dem Endkunden das Ergebnis einer Automatisierung zur Begutachtung vorlegen und anschließend den Satz hören:
„Wir haben alle Inhalte intensiv geprüft. Wir konnten keine Fehler finden.“
Gregor liefert seinen Beitrag unter dem Titel „InDesign erfolgreich automatisieren“. Beide Perspektiven erweitern den Horizont ungemein.