COI-CMS

Wenn in einem Asylverfahren die Frage aufkommt, wie es um die Menschenrechtslage in einem bestimmten Staat steht, stützt sich die Antwort auf einen Bericht. Dieser Bericht muss aktuell sein, er muss belegt sein, und jede einzelne Aussage darin muss bis zu ihrer Quelle zurückverfolgt werden können. Das COI-CMS ist das System, in dem diese Berichte entstehen.

Es ist ein Dokumentenmanagementsystem für die Staatendokumentation des Bundesamts für Fremdenwesen und Asyl. Rund 30 Redakteurinnen und Redakteure und ein halbes Dutzend Übersetzer pflegen darin die Berichte zu 50 bis 80 Staaten. Genutzt werden die fertigen Berichte anschließend im gesamten Verfahren — vom Bundesamt über das Bundesverwaltungsgericht bis zu den Höchstgerichten.

Was das System kann

Recherchequellen werden im System verwaltet, zitiert und mit dem Text verknüpft, sodass am Ende jede Aussage ihren Beleg hat. Jede Änderung wird versioniert, Fassungen lassen sich gegenüberstellen und vergleichen.

Der Review-Prozess läuft wahlweise auf Kapitel- oder auf Dokumentebene: ein einzelnes Kapitel kann gegengelesen und freigegeben werden, während am Rest weitergearbeitet wird. Aus der Bibliothek lassen sich Kapitel fallbezogen zu einem eigenen Dokument zusammenstellen — samt Deckblatt, Impressum und Anhang, je nach Verwendungszweck. Maschinelle Übersetzungen werden nachträglich auf die fachlich korrekte Schreibweise gebracht.

Nicht jeder sieht alles: Zugriffsrechte greifen bis auf Kapitelebene, sodass einzelne Abschnitte eines Berichts nur denen offenstehen, die sie sehen dürfen.

Mein Anteil

Die Benutzeroberfläche. Eine Angular-Anwendung mit rund 200 Komponenten und etwa 50.000 Zeilen Code, in fünf Sprachen verfügbar. Sie bündelt Recherche, strukturierte Bearbeitung, Vergleichsansichten, Kommentare und Freigabe an einer Oberfläche — die redaktionelle Arbeit findet vollständig hier statt. Dazu gehört auch die Anbindung der Duden-Rechtschreibprüfung an den Editor: technisch überschaubar, in der Praxis vor allem eine Frage der Randfälle, die ich direkt mit Duden geklärt habe.

Der Zustandsautomat. Der Weg eines Berichts von der Bearbeitung über das Gegenlesen und das Editorial Board bis zur Publikation ist kein Ablaufdiagramm in einer Spezifikation, sondern ausführbarer Code: Zustände, ihre zulässigen Übergänge und die Kommunikation zwischen ihnen sind explizit modelliert. Ein unzulässiger Übergang ist damit keine Frage der Disziplin, sondern schlicht nicht möglich. Fristen lösen Übergänge selbsttätig aus.

Definiert war die Schnittstelle zwischen Frontend und Backend nicht immer. Wo unklar blieb, wie ein Zustand über die Schnittstelle übergeben wird und was das für die Historie bedeutet, habe ich das früh angesprochen — nicht erst, wenn’s im Betrieb auffällt.

Der Zustand gehört nicht der Oberfläche. Gehalten wird er in einem SignalStore außerhalb der UI. Die Oberfläche liest ihn und stellt ihn dar, aber sie besitzt ihn nicht. Das klingt nach einer Kleinigkeit und ist der Grund dafür, dass der Workflow prüfbar blieb, während die UI über Jahre gewachsen ist.

Was die eigentliche Arbeit war

Ein Bericht ist kein Dokument, sondern ein Geflecht: Kapitel mit eigenen Lebenszyklen, Quellen mit eigener Gültigkeit, Übersetzungen mit eigenem Stand — und über allem ein Verfahren, in dem Nachvollziehbarkeit keine Komfortfunktion ist, sondern die Voraussetzung dafür, dass der Bericht überhaupt verwendet werden darf.

Die größere Aufgabe lag aber nicht in der Technik. Das System löst ein gewachsenes ab — für rund dreißig Menschen, die alle schon eine Arbeitsweise hatten, und nicht dieselbe. Daraus einen einheitlichen Ablauf zu machen, war die Arbeit der Staatendokumentation selbst: ihr Fachgebiet, ihre Entscheidung, und es gab dort Menschen, die das gegen Widerstände vorangetrieben haben. Unsere Aufgabe war es, dafür die Leitplanken zu bauen — und ansprechbar zu bleiben: bei Fehlermeldungen, Systemausfällen und Nachbesserungen war die Reaktionszeit kurz.

Was es hingegen nicht gab, war eine Rückkopplung mit den Anwendern. Die Funktionen waren im Vorfeld festgelegt und vertraglich gebunden, direkten Kontakt zu den Redakteurinnen und Redakteuren im Alltag gab es nicht. Bei der Umsetzung zeigt sich aber regelmäßig, was in keiner Spezifikation steht — was passiert, wenn zwei Personen dasselbe Kapitel speichern wollen; wie man die Übersicht über die Kapitel behält, die noch zu bearbeiten sind; welcher Klick so selbstverständlich erscheint, dass ihn niemand gefordert hat.

Am deutlichsten wurde das beim Reporting: Die Zahlen der einzelnen Abteilungen ergaben in Summe nicht die Gesamtzahl, und je nach gesetztem Filter widersprachen sich die Werte. Zahlen also, die der ersten logischen Nachfrage nicht standgehalten hätten. Beschwert hatte sich niemand, aufgefallen war es niemandem, gefordert war die Korrektur nicht — man hätte darüber hinwegsehen können, ohne dass es je jemand bemerkt hätte.

Diese Lücke habe ich zu füllen versucht, indem ich mich zum Anwalt des Anwenders gemacht habe — auch gegen die eigene Spezifikation. Bei jeder Funktion die Frage: Wie benutzt das jemand, der damit täglich arbeitet und die Spezifikation nie gelesen hat?

Ein Anwalt entscheidet nicht, er trägt vor. Umgesetzt wurde längst nicht alles: Vieles lag außerhalb dessen, was der Vertrag hergab, und die Entscheidung darüber lag nicht bei mir. Aber die Wand, die das Budget aufstellte, war für mich nie ein Grund, gar nicht erst zu fragen. Vieles an der Oberfläche ist so entstanden — nicht, weil es gefordert war, sondern weil es sonst gefehlt hätte.