Menschmaschinen machen müde Mitarbeiter marode

Web-Publishing zwischen automatisiertem Chaos und mechanischer Manpower

Kaum zehn Jahre nach dem hochvirulenten Grundgedanken, Hyptertext-Publishing durch HTML extrem zu vereinfachen und dadurch zu vermenschlichen, erzeugt der kommerzielle Zwang im WWW die Sehnsucht nach dem berühmten einen roten Knopf. Ein gekrümmter Finger soll genügen, und die Daten suchen sich fehlerlos und ohne Verzögerung den Weg ins Internet. Theoretisch. Aber dieser fromme Wunsch ist so abwegig wie die Suche nach der Gralsburg.

Egal, ob man nun über die Internet World in Frankfurt oder die Internet World in Berlin zu schlendern pflegt: Der berühmte rote Knopf für das eigene Webpublishing gilt als Wunsch aller EDV-Profis und erzeugt deshalb Aufmerksamkeit auf beiden Messen. Glaubt man den Promotoren, so ist die Zeit der mit Maus und Gottvertrauen werkelnden Webmaster vorbei. Was zählt, sei die Automatisierung in Redaktions- und Ecommerce-Systemen. Da lacht der Profi. Fast scheint es, als hätten diese beiden Konkurrenzveranstaltungen sich gegenseitig die großen Blender in die Messehallen gejagt, um das jeweilige Publikum mit falschen Heilsversprechungen zu verprellen.

Eine apodiktische Behauptung an dieser Stelle: Das fehlerlose Tool für grenzenlose Automatisierung im Web gibt es nicht. Weil es keinen luftleeren Raum und keine Engel auf Erden gibt.

Das ist amtlich und dem Spiegel eine Geschichte in Ausgabe 18/98 wert: Schlimmer als es die Polizei erlaubt, gestaltet sich die digitale Erfassung von Protokollen durch ein zentrales Tool. Etwa eine halbe Milliarde Mark wurde bisher ohne Ergebnis verplempert. Und wenn es den Ordnungshütern im Land schon nicht gelingt, wie soll eine herkömmliche Webredaktion hier besser sein?

So einfach ist es nun einfach nicht, denn der Einsatz von Publishing-Automaten wird zuerst einmal auch deswegen angeleiert, daß tumbe und unerträgliche Arbeiten von Menschen ferngehalten werden sollen. Nur verselbständigen sich diese Tools dann, wenn sie versuchen, den Rubikon zu überschreiten, der sich im klassischen Tweety-Beispiel der Formallogik ausdrückt.

"Tweety ist ein Vogel. Alle Vögel können fliegen. Tweety kann nicht fliegen."

Ist Tweety krank? Nicht unbedingt! Die Lösung dieser scheinbaren Unlogik lautet "Tweety ist ein Pinguin", und der Fakt, daß Weltwissen nicht-monoton schließt, treibt schon einmal Programmierer in die Verzweiflung. Immer taucht noch eine neue Wissenskomponente auf, die eine bereits sicher geglaubte Basis ins Wanken bringen kann. Tools mögen einmal auf dem Papier sehr klar gewesen sein. Durch sich ständig erweiternde Anforderungen in der täglichen Praxis werden sie zum Kartenhaus, das in sich zusammenstürzt oder durch zum Teil widersinnige Anweisungen gezinkt werden muß.

Beispiele aus der Praxis gibt es genug. Eine fiktive Situation in einer Phantom-Redaktion einer beliebigen Website gibt das Dilemma aber neutraler wieder:

Redakteur X hat es satt, mit seiner Maus immer und immer wieder wie ein Verrückter am Pad entlangzuscheuern, um jeden Abend gegen 18.00 Uhr die firmeneigenen News des Tages zu publizieren. Der Weg, die Daten ohne hilfreiches Tool hineinzuklopfen, ist hoch fehleranfällig. Mal funktioniert ein Link nicht sauber, mal sind die Texte nicht auf dem Bildschirm zu sehen, weil ein Tag fehlt, und im Streß wurden aus Versehen die alten Files noch einmal live gestellt. Chaos. Da ist der Schrei nach einem digitalen Mitdenker nur zu verständlich. Redakteur X geht also an eine ihm empfohlene Agentur heran, die diesen Weg automatisieren soll.

Stufe 1 - Sehnsucht

Die ist wirklich stark bei der Sache. Der bisherige Arbeitsweg wird von den Beratern genau unter die Lupe genommen und soweit in ein Workflowchart gebracht, daß daraus ein Publishing-Tool entstehen kann, das zumindest in der Theorie einen einfachen Publishing-Weg verspricht. Die Texte werden den Tag über in ein Formular eingegeben, daraus soll zur Deadline gegen 18.00 Uhr eine Liveversion entstehen. Die alte soll ein Archiv bilden, das automatisch umbenannt und neu verlinkt werden soll. Der Redakteur ist glücklich, reißt einen so hohen Etat los, daß er damit einen zweiten Mitarbeiter ein Jahr lang hätte bezahlen können, und freut sich auf die Installation des Tools, das dann wie ein Perpetuum mobile Webseiten erzeugen soll.

Stufe 2 - Frau Welt (Gute Seite)

Nach mehreren Terminverschiebungen - ("Wir wollen noch auf ein weiteres Update des Betriebssystems warten, neue Programmiertools scheinen uns noch ein wenig weiterzuhelfen, das dauert aber noch 2 Monate...") - wird das Tool installiert ... und funktioniert erst einmal nicht. Das ist nicht dramatisch, es mag daran liegen, daß der Computer des Redakteurs nicht genügend (bitte nach Wahl ankreuzen) Arbeitsspeicher, Festplatte, Prozessorleistung oder Modem-Connect besitzt. Eine weitere Maschine schmälert den Etat, aber nach ein paar Abstürzen und dem kompletten Verlust der bisherigen Website im ersten Einsatz des Tools scheint alles zu laufen. Zwar sind die Links immer wieder tot, und die News tauchen anfangs auf den falschen Seiten auf, aber das Tool scheint jetzt zumindest wieder das an Qualitätsstufe zuzulassen, was mit händischem Einsatz auch schon erreicht war.

Stufe 3 - Frau Welt (Die verdorbene Seite)

Abteilung Z kommt nun immer häufiger zu spät mit den Texten und bittet den Redakteur, doch schon einmal ohne diesen Input zu publizieren, diese Contents aber dann gegen 18.30 Uhr einfach auf die Website nachzuschieben. Das muß doch mit so einem Tool zu machen sein. Soll man sich einer Maschine unterordnen, die nur für einen Publishing-Vorgang am Tag konzeptioniert ist? Nein. Da kein weiterer Etat zum Umbauen des Tools vorgesehen ist und ja eigentlich alles laufen würde, wird Redakteur X die Agentur nicht mehr einbinden können.

Er entschließt sich daher, die Nachzügler mit der "Newsflash"-Funktion zu bedienen, die von vorne herein für Sondermeldungen vorgesehen war und es ermöglicht, jederzeit zu publizieren. Allerdings beginnt so der Tanz im härteren Takt. Die Sondermeldungen werden in Rot dargestellt und auch als Sondermeldungen archiviert. Da das die anderen Abetilungen sehen, wollen sie hier nicht mindere Qualität im Netz stehen haben. Sie beginnen immer wieder verspätet mit der Zulieferung an Texten, so daß der Redakteur schon nach wenigen Wochen eine komplett rote Page publiziert, da zum automatisch startenden Publishing-Prozeß alle Abteilungen erst einmal abwarten und dann senden. Und um diese Meldungen nicht als Sondermeldungen zu archivieren, geht der Redakteur dazu über, diese Meldungen am nächsten Tag noch einmal zu publishen und damit im Archiv zu überschreiben. Konsequenz: Plötzlich sind alle Meldungen 24 Stunden älter als sie sein müßten.

Stufe 4 - Orde Mufti

Der Vorgesetzte des Redakteur X bittet zum ernsten Gespräch und fordert vom armen, inzwischen nervlich etwas belasteten Mitarbeiter, daß alle Nachrichten wieder aktuell, in einer Farbe und zur passenden Zeit publiziert werden sollen. Nun hat der Redakteur außer seiner Kündigung noch zwei Möglichkeiten. Entweder wirft er das Tool einfach in den digitalen Orkus (format c:) oder er bittet um einen Sonderetat, der diese Fehler entfernen soll. Angenommen, dieser wird ihm mit der hochgezogenen Augenbraue wirklich gewährt, dann wird er nur mit der bereits bekannten Agentur arbeiten können, weil niemand sonst sich in den Source-Code einlesen kann und will. Diese Agentur ist aber leider auch ein wenig teurer geworden, da sie die Ersterstellung als Akquise-Angebot zum Selbstkostenpreis kalkuliert hat. Nun lassen sich eben nur noch bestimmte Arbeiten durchführen oder diese nur sehr roh, um den Termin und den Pflichtenkatalog im Budget-Rahmen doch noch einzuhalten.

Stufe 5 - Wahnsinn sei mein Gefährte

Es gelingt, eine beliebig oft zu startende Publikationsroutine zu installieren, die der Redakteur dadurch in Gang setzt, daß er zuerst ins Archiv publiziert und durch (automatisches) Umkopieren der Files in den Live-Bereich wirklich stündisch live sein kann. Das kommuniziert er nicht unbedingt an die Verantwortlichen im Haus, weil er eh nur noch als Running Gag durch die Abteilungen läuft und deshalb um seine Person etwas Ruhe entstehen lassen will. Burgfrieden breitet sich aus. Das Tool tut seine Pflicht.

Eines Tages geht der so Gestreßte in den Urlaub. Seine Vertretung ist eingelernt, aber nicht im Haus vorgestellt. Erst nach drei Tagen bricht das Chaos aus, denn die EDV-Abteilung muß den heruntergefahrenen Server neu aufsetzen und verlegt das Archiv der Website dazu in ein neues Verzeichnis. Die Publikationsroutine bricht zusammen, die Vertretung kann die Seiten nicht händisch einfügen, da sie kein HTML beherrscht. Und beim Versuch des gutmütigen EDV-Spezialisten, das Tool doch wieder zum Laufen zu bringen, formatiert der die Festplatte des Redaktionscomputers und damit - unwissentlich - die einzige Version des Tools (Die Sicherheitskopie war auf einem nicht automatisch gebackupten Verzeichnis des Servers zu finden - aber woher hätte das der Redakteur wissen sollen!).

Am besten, der Redakteur X hat sich zu diesem Zeitpunkt bereits mit der Portokasse in die Mongolei abgesetzt. Die Website darf auf jeden Fall als verloren gelten.

Was hier wie ein Slapstick-Drehbuch klingt, ist ein Zusammenschnitt bereits geschehener Crashes in Web-Publishing-Systemen. Was sie alle auszeichnet, ist ein zu starres Design, um das Publishing kinderleicht zu gestalten. Die Sehnsucht nach dem einen Handgriff erfordert hochkomplexe und für alle Zeiten normierte Abläufe, in denen keines der Rädchen auch nur für einen Moment zum Stillstand kommen darf.

Anstatt aber auf den Zauberspruch zu hoffen, der die eigene Plagerei für immer verhindert, sollte man sich vom Zauberlehrling eher zum ABC-Schüler verwandeln. Systeme, die sich als Vokabeln in einem Gesamtsystem verstehen, besitzen weitaus größere Chancen, dem grausigen Vogel Tweety zu entgehen. Das eierlegende, vollflugfähige Tool ist dem Programm, das sich wirklich nur als Werkzeug versteht, entschieden überlegen. Ein Webmaster, der für jeden der von ihm vorzunehmenden Arbeiten eine autarke Software besitzt, wird immer noch eine Hölle an Arbeit vor sich haben, die Schnittstellen zueinander sauber zu halten, aber der Begriff "Tool" drückt bereits aus, worin der Trick hier liegt. So würde ein Mechaniker ebenfalls nicht auf einen universellen Schraubenzieher hoffen, der mit einmal Ansetzen ein ganzes Automobil repariert. Es geht ihm vielmehr um das Werkzeug, daß er im passenden Moment genau für diese Aufgabe aus seiner Tasche ziehen kann.

Redakteur Y hat vielleicht deshalb seine Arbeitsvorgänge noch einmal zusammengestellt, hat für jeden der Schritte ein Tool gesucht, das ein bestimmtes Teilergebnis erzeugt, und kann so dynamisch auf alle schrägen Vögel reagieren, die von ihm zur unpassenden Zeit etwas anderes wollen. Das mag auf den ersten Blick aufwendiger klingen, aber es verhindert die Katastrophe. Das universelle Tool, das mit einem Mal nicht mehr funktionieren mag, erinnert mehr an den Generalschlüssel, den man verliert. Im schlimmsten Fall kommt man vielleicht nicht einmal mehr an die Daten, die man umstrukturieren möchte.

Einfache Merkregeln hätten dem Redakteur X vielleicht weitergeholfen - und die sind vielleicht auch schon zu starr:

1. Ein Tool ist gut, ein Bündel an Tools ist besser
2. Jedes Tool ist nur so stark wie es variabel ist
3. Alles, was händisch schneller geht als mit Tool, geht damit besser.

Das hört sich so besserwisserisch an. Aber Präsentatoren auf Messen werden den Teufel tun und genau erklären, wo derselbige im Detail liegt. Dafür werden sie nicht bezahlt. Webmaster übrigens auch nicht. Die lösen solche Crashes meistens über Nacht - in freiwilligen Überstunden.

PS: Der Untertitel sollte eigentlich "chaotische Automatisierung" lauten, aber Helmut Beck