Umstellung automatisierter Prozesse

Die strategische Entscheidung der öffentlichen Verwaltung, zukünftig vorrangig auf das OpenDocument Format (ODF) zu setzen, hat Auswirkungen auf bestehende automatisierte Prozesse. Die auf dieser Seite beschriebenen Konsequenzen treten allerdings nur dann ein, wenn die in diesen Prozessen bislang verwendeten OOXML-Dateien tatsächlich auf ODF umgestellt werden. Betroffen sind in dem Fall vor allem Microsoft Word (.docx) und Excel (.xlsx). Verwendungsbeispiele sind:

• Hinterlegung von Konfigurationsdaten
• Nutzung zum Datenaustausch
• Logging-Funktionen

Bitte unbedingt beachten:

Diese Prozesse auf ODF umzustellen ist mehr als nur ein Austausch von Dateiendungen; die Umstellung erfordert technische Anpassung und strategische Planung.¹

Herausforderungen bei der Migration

Die Umstellung von automatisierten Prozessen, die auf OOXML-Dokumenten basieren, birgt spezifische technische und organisatorische Herausforderungen:

• Inkompatible APIs und Bibliotheken: Bestehende Skripte und Anwendungen, die OOXML-spezifische Bibliotheken (z.B. für das Parsen von .xlsx-Dateien) verwenden, müssen auf ODF-kompatible Alternativen umgestellt werden.
• Verlust von Metadaten: Automatisierte Prozesse, die auf bestimmte Metadaten in OOXML-Dokumenten angewiesen sind, können fehlschlagen, wenn diese Metadaten bei der Konvertierung verloren gehen.
• Unterschiedliche Datenstrukturen: Die interne Struktur von ODF-Dokumenten unterscheidet sich von der von OOXML-Dokumenten. Dies kann zu Problemen beim Auslesen und Schreiben von Daten führen.
• Fehlende Funktionalität: Einige fortgeschrittene Funktionen, die in OOXML-basierten Prozessen verwendet werden (z.B. komplexe Makros), haben möglicherweise keine direkte Entsprechung in der ODF-Welt.

Arten von automatisierten Prozessen

Bei der Analyse der bestehenden IT-Landschaft ist es sinnvoll, zwischen zwei Arten von automatisierten Prozessen zu unterscheiden:

• Prozesse mit Makros: Hierbei handelt es sich um in Office-Dokumenten eingebettete Skripte (z.B. VBA-Makros in Excel oder Word), die komplexe Abläufe steuern. Die Migration solcher Prozesse ist besonders aufwändig, da die Makro-Sprachen inkompatibel sind und die Logik oft neu implementiert werden muss.
• Integrierte Prozesse ohne Makros: Diese Prozesse nutzen Office-Dokumente als Datencontainer oder Vorlagen, die von externen Systemen gelesen oder geschrieben werden. Die Automatisierung erfolgt hierbei serverseitig oder durch spezialisierte Client-Anwendungen.

Makro-basierte Prozesse (Anwendungsbeispiele)

Die folgende Liste gibt einen Überblick über die häufigsten Anwendungsfälle, bei denen die Automatisierung direkt in der Office-Datei mittels VBA-Code umgesetzt ist. Die Umstellung auf ODF ist hier besonders kritisch, da der Code nicht portierbar ist und komplett neu entwickelt werden muss.

1. Berichte finalisieren und verteilen (PDF-Export & E-Mail)

• Beispiele: Personalbedarfsrechnung, Monats- und Jahresberichte, Protokolle
• Was das Makro tut: Nach der Dateneingabe klickt ein Anwender auf einen Button. Das Makro speichert die Datei (oft ein bestimmtes Tabellenblatt oder eine gefilterte Ansicht) unter einem standardisierten Namen als PDF und versendet es optional direkt per E-Mail an einen vordefinierten Verteiler.
• Problem bei der Umstellung: VBA-Code wird in ODF nicht ausgeführt. Die gesamte Logik für den PDF-Export und die E-Mail-Ansteuerung (via Outlook-Objektmodell) muss beispielsweise in LibreOffice Basic neu geschrieben werden, das eine andere Syntax und andere Objektbibliotheken verwendet. LibreOffice Basic steht zwar auch in Collabora Online zur Verfügung, aber mit wichtigen und wesentlichen Einschränkungen. Es ist nicht dasselbe wie die voll funktionsfähige Makroumgebung, die Sie vielleicht von der Desktop-Version von LibreOffice kennen. Beispielsweise sind keine Benutzerinteraktionen möglich, ebenso keine Zugriffe auf das Dateisystem. Für Online‑Automatisierung stellt Collabora heute webtaugliche Schnittstellen bereit (PostMessage‑API, UNO‑Kommandos, serverseitige Python‑Skripte). Diese Integrationen sind für Browser‑Umgebungen ausgelegt und werden in der Online‑SDK dokumentiert. Collabora Online kann grundsätzlich Basic- und VBA-kompatible Makros aus ODF-Dokumenten ausführen, vorausgesetzt, die Makro-Ausführung wurde administrativ freigeschaltet. Die Makros selbst werden typischerweise in LibreOffice Desktop entwickelt und gepflegt. Wichtig ist, dass Makros aus Microsoft Office-Dateien (wie .docm oder .xlsm) nicht direkt unterstützt werden. Zudem unterliegt die Ausführung in der Online-Umgebung weiteren Einschränkungen, wie dem Verbot von Dateisystemzugriffen oder dem Aufruf externer Programme.

2. Datenimport und -aufbereitung aus Fachsystemen

• Beispiele: Rechnungsprüfung, Haushaltsberichte, Auswertung von DMS-Exporten
• Was das Makro tut: Es importiert Rohdaten aus externen Quellen (meist .csv oder .txt-Dateien aus SAP, KommFin etc.), bereinigt diese automatisch (z. B. Spalten aufteilen, Leerzeichen entfernen, Datumsformate korrigieren) und formatiert sie als saubere Tabelle für die weitere Analyse.
• Problem bei der Umstellung: Während der reine CSV-Import auch in LibreOffice funktioniert, ist die nachgelagerte Logik zur Daten-Transformation (Schleifen, String-Manipulation) oft komplex. Jede Zeile VBA-Code muss „übersetzt“ und auf die Eigenheiten von LibreOffice Calc angepasst werden.

3. Batch-Verarbeitung und Erzeugung von Einzeldokumenten

• Beispiele: Massenverkehrsgenehmigungen, Erstellung von Barcode-Trennblättern, Serien-Urkunden
• Was das Makro tut: Das Makro liest eine Liste (z. B. 500 Adressen in einer Excel-Tabelle) Zeile für Zeile aus. Für jeden Datensatz befüllt es eine Word-Vorlage, speichert das Ergebnis als separates Dokument (oft PDF) und wiederholt den Vorgang für die nächste Zeile.
• Problem bei der Umstellung: Die Steuerung einer Office-Anwendung aus einer anderen (OLE-Automation, z. B. Excel steuert Word) ist eine Stärke von Microsoft Office. In der LibreOffice-Welt ist dies über die UNO-Bridge zwar möglich, aber technisch anspruchsvoller und fehleranfälliger. Der Prozess muss grundlegend neu konzipiert werden.

4. Dokumente bereinigen und für die Veröffentlichung vorbereiten

• Beispiele: Gremienvorlagen (Kommentare entfernen), Vertragsentwürfe (Änderungen annehmen)
• Was das Makro tut: Vor der Weitergabe oder Archivierung eines Dokuments führt das Makro standardisierte Bereinigungsschritte durch: Es löscht alle Kommentare, nimmt alle nachverfolgten Änderungen an, entfernt persönliche Metadaten und setzt das Dokument auf einen finalen Status.
• Problem bei der Umstellung: Die Objektmodelle für Funktionen wie „Änderungen nachverfolgen“ (Revisions) oder Dokumenteneigenschaften (DocProperties) unterscheiden sich stark zwischen Word (VBA) und Writer (Basic). Die Makros müssen komplett neu entwickelt und auf die ODF-Struktur angepasst werden.

5. Komplexe, fachspezifische Berechnungen und Validierungen

• Beispiele: Gebührenkalkulation (Friedhofsverwaltung), Berechnung von Einheitswerten (Kommunalsteuer), Zinsberechnungen gem. AO
• Was das Makro tut: Es implementiert komplexe Geschäftslogik, die mit Standard-Formeln nicht oder nur sehr umständlich abzubilden wäre. Oft werden dabei benutzerdefinierte Funktionen (UDFs) bereitgestellt, die wie normale Formeln in Zellen verwendet werden können (z. B. =BERECHNE_GEBUEHR(...)).
• Problem bei der Umstellung: Die mathematischen Funktionen sind meist übertragbar, aber die Art und Weise, wie das Makro auf Zellenwerte zugreift und Ergebnisse zurückschreibt (Range-Objekt in VBA vs. getCellByPosition in Basic), ist fundamental anders. Alle benutzerdefinierten Funktionen müssen neu deklariert und implementiert werden.

Integrierte Prozesse (ohne Makros)

Die folgende Tabelle gibt einen Überblick über verbreitete integrierte Prozesse, die OOXML-Dateien ohne Makros verarbeiten, und beleuchtet die Herausforderungen bei einer Umstellung auf ODF.

Prozess / Zweck	Dokumenttyp (OOXML)	Verbreitungsgrad	Automatisierung (Wie & Womit?)	Herausforderung bei ODF-Umstellung
Erstellung von Berichten & Auswertungen	Excel (.xlsx)	Sehr hoch	Sehr verbreitet im Controlling und für Ad-hoc-Analysen in fast jeder Behörde (Kämmerei, Personal, etc.). Power Query liest Daten direkt aus Datenbanken (SQL), Fachanwendungen oder SAP-Exporten und bereitet sie für Pivot-Tabellen auf.	Keine native Entsprechung: LibreOffice Calc hat kein integriertes Power Query. Der gesamte Datenabruf- und Transformationsprozess muss neu aufgebaut werden (z. B. durch externe Skripte).
Export aus Fachanwendungen	Excel (.xlsx)	Sehr hoch	Nahezu jede moderne Fachanwendung (Finanzwesen, Personal, GIS) bietet einen "Export nach Excel"-Button als Standardfunktion. Integrierte Export-Funktion einer Fachanwendung. Die Software ist vom Hersteller fest darauf programmiert, Berichte und Listen als .xlsx auszugeben.	Abhängigkeit vom Hersteller: Die Verwaltung hat keine Kontrolle. Der Hersteller der Fachanwendung muss beauftragt werden, einen .ods-Export zu implementieren (Kosten, Wartezeit).
Serienbrief-Automatisierung	Word (.docx), Excel (.xlsx)	Sehr hoch	Grundfunktion für jegliche Massenkommunikation, von Wahlbenachrichtigungen bis zu Gebührenbescheiden. Die Serienbrief-Funktion von Word wird durch einen Skriptaufruf angestoßen, der die Daten aus einer .xlsx-Datei zieht und hunderte Briefe erzeugt.	Fragile Datenquellen-Verbindung: Die Verbindung zwischen .odt und .ods interpretiert oft Datums-, Währungs- und Zahlenformate falsch. Der Prozess muss neu eingerichtet und intensiv getestet werden.
Generierung von Bescheiden & Urkunden	Word (.docx)	Hoch	Kernprozess in vielen Fachverfahren, die rechtskräftige Dokumente erzeugen (Bürgeramt, Sozialamt, Bauamt). Server-seitige Generierung mit Bibliotheken (z. B. OpenXML SDK für .NET, Apache POI für Java). Ein Fachverfahren befüllt eine .docx-Vorlage und gibt sie aus.	Format-spezifische Bibliotheken: Die Bibliotheken können nur OOXML erzeugen. Der Backend-Code muss komplett auf ODF-Bibliotheken umgeschrieben werden (erheblicher Entwicklungsaufwand).
Datenaustausch mit externen Stellen	Excel (.xlsx)	Hoch	Betrifft jede Kommune und jedes Land bei Meldepflichten gegenüber übergeordneten Behörden (z. B. statistische Landesämter). Standardisierter Datentransfer: Ministerien, statistische Ämter oder EU-Behörden definieren ein .xlsx-Template als verbindliches Austauschformat für Meldungen.	Verbindliche Vorgabe & Lock-in: Solange die empfangende Behörde ausschließlich OOXML akzeptiert, ist ein Umstieg unmöglich. Dies erfordert eine übergeordnete politische Abstimmung.
Auswertung strukturierter Formulare	Word (.docx)	Mittel	Eher eine Nischenlösung in Abteilungen, die Formularprozesse ohne Web-Frontend teil-automatisieren. Ein externes Programm liest gezielt die Inhalte von Content Controls (Dropdown-Felder, Datumswähler) aus Word-Dokumenten aus, um die Daten zu speichern.	Inkompatible Formulartechnologie: ODF (Writer) nutzt „Formular-Steuerelemente“, die technisch völlig anders sind. Der Code zum Auslesen der Daten muss vollständig neu geschrieben werden.

On-the-fly-Konvertierung als Zwischenschritt

Wenn eine Verwaltungsorganisation OOXML zunächst beibehält und nur für die externe Verteilung nach ODF konvertieren will, kann ein zusätzlicher Prozessschritt in bestehende Verfahren implementiert werden. Anstatt die Dokumentenerstellung im Kern zu verändern, wird die Konvertierung als nachgelagerter Service behandelt. Dieser Ansatz minimiert den Eingriff in bestehende Fachanwendungen und dient als Brückenlösung.²

Der Prozessschritt wird an das Ende der bestehenden Dokumentenerzeugung angehängt. Eine Anwendung generiert wie gewohnt ein .docx- oder .xlsx-Dokument. Bevor dieses Dokument jedoch verteilt wird, durchläuft es einen automatisierten Konvertierungsdienst, der es in ODF umwandelt. Erst danach wird die ODF-Datei an externe Partner weitergeleitet.

Für die technische Umsetzung gibt es zwei gängige Varianten:

1. Lokale Konvertierung mit Headless LibreOffice: Ein auf einem Server installiertes LibreOffice kann über die Kommandozeile gesteuert werden, um Dokumente ohne grafische Benutzeroberfläche zu konvertieren. Der Befehl soffice --headless --convert-to odt mein_dokument.docx wandelt beispielsweise eine .docx-Datei in eine .odt-Datei um. Diese Methode eignet sich für Infrastrukturen, in denen die Installation von Software auf Servern möglich ist.³

   Wichtiger Hinweis zur Parallelverarbeitung

   Der soffice-Befehl verwendet ein Benutzerprofil, das durch eine Lock-Datei geschützt ist. Der gleichzeitige Start mehrerer soffice-Prozesse unter demselben Benutzerkonto führt daher zu Fehlern, da nur der erste Prozess das Profil sperren kann. Für eine robuste Parallelverarbeitung muss für jeden Prozess ein isoliertes Benutzerprofil mit dem Kommandozeilen-Argument -env:UserInstallation=<eindeutiger_pfad> erstellt werden.

2. Konvertierung über Collabora Online API: Collabora Online bietet einen API-Endpunkt (/cool/convert-to), der für die Dokumentenkonvertierung genutzt werden kann. Dieser Ansatz eignet sich für service-orientierte Architekturen oder wenn eine eigene LibreOffice-Installation vermieden werden soll. Die Anwendung sendet das OOXML-Dokument an die API und erhält das konvertierte ODF-Dokument zurück.⁴

Warum wird Pandoc nicht erwähnt?

Pandoc ist ein universeller Dokumentenkonverter, der oft für die Konvertierung von Markdown, LaTeX oder HTML in Office-Formate (und umgekehrt) verwendet wird. Für die Konvertierung von komplexen OOXML- in ODF-Dokumente ist es jedoch nur bedingt geeignet. Der Grund dafür ist, dass Pandoc primär für textbasierte Dokumente konzipiert wurde und bei komplexen Layouts, eingebetteten Objekten (wie Diagrammen oder Formeln) und erweiterten Formatierungen an seine Grenzen stößt.

Im Gegensatz dazu sind LibreOffice, Collabora Online oder andere Office-Suiten darauf ausgelegt, die Spezifikationen beider Formate nativ zu implementieren. Dies gewährleistet eine deutlich höhere Layouttreue bei der Konvertierung.⁵ Ein Foreneintrag auf ask.libreoffice.org fasst es so zusammen: "Especially for documents with complex formatting, or tables, etc… the best way is to use LibreOffice's ‘Save as’ feature"⁶.

Weitere technische Details und ein lauffähiger Proof-of-Concept zur asynchronen Konvertierung finden Sie auf der separaten Seite Proof-of-Concept für automatisierte Konvertierung.

Empfohlene Vorgehensweise

Für eine erfolgreiche Migration von automatisierten Prozessen wird die folgende strategische Vorgehensweise empfohlen:

1. Inventarisierung der Prozesse: Identifizieren Sie alle automatisierten Prozesse, die OOXML-Dokumente verwenden, und dokumentieren Sie deren Funktionsweise.
2. Analyse der Abhängigkeiten: Analysieren Sie die technischen Abhängigkeiten der einzelnen Prozesse, einschließlich der verwendeten Bibliotheken, APIs und Datenstrukturen.
3. Auswahl geeigneter Werkzeuge: Wählen Sie ODF-kompatible Bibliotheken und Werkzeuge für die Neugestaltung der Prozesse aus. Open-Source-Lösungen sind hier oft eine gute Wahl.
4. Pilotmigration: Führen Sie eine Pilotmigration für einen ausgewählten Prozess durch, um Erfahrungen zu sammeln und die Machbarkeit zu überprüfen.
5. Schrittweise Umstellung: Stellen Sie die Prozesse schrittweise um und testen Sie jeden Prozess gründlich, bevor Sie ihn in den produktiven Betrieb überführen.
6. Schulung der Entwickler: Schulen Sie Ihre Entwickler im Umgang mit den neuen Werkzeugen und den Besonderheiten des ODF-Formats.

Technologische Alternativen

tipp

In vielen Fällen ist es sinnvoll, im Zuge der Umstellung auf ODF auch die zugrunde liegende Technologie zu modernisieren. Anstatt Konfigurationsdaten oder Datenaustauschformate in Office-Dokumenten zu speichern, können modernere und robustere Alternativen wie JSON, XML oder CSV in Betracht gezogen werden. Diese Formate sind standardisiert, plattformunabhängig und werden von einer breiten Palette von Werkzeugen und Programmiersprachen unterstützt.

Footnotes

1. Die Umstellung von VBA-basierten Prozessen wird auch im Rahmen der Umstellung auf LibreOffice in Schleswig-Holstein als große Herausforderung gesehen. Siehe z.B. Borncity: "Digitale IT-Souveränität: Schleswig-Holstein setzt auf LibreOffice" (öffnet in neuem Tab) ↩

2. Dieser Ansatz wird auch als "On-the-fly-Konvertierung" bezeichnet und dient dazu, die Interoperabilität zwischen verschiedenen Systemen zu gewährleisten, ohne die Kernprozesse sofort umstellen zu müssen. ↩

3. Eine Anleitung zur Stapelverarbeitung mit LibreOffice findet sich z.B. unter UbuntuBuzz: "How To Batch Convert DOCX to ODT" (öffnet in neuem Tab). ↩

4. Die API-basierte Konvertierung ist Teil der Collabora Online SDK. Die offizielle Dokumentation findet sich unter Collabora Online SDK: "Conversion API" (öffnet in neuem Tab). Ein Foreneintrag dazu findet sich unter Collabora Online Forum: "Document Conversion with Collabora REST API" (öffnet in neuem Tab). ↩

5. Siehe z.B. LinuxConfig: "How to convert documents between LibreOffice and Microsoft Office file formats on Linux" (öffnet in neuem Tab). ↩

6. Ask LibreOffice: "Best way to convert documents from .doc to .odt and vice-versa" (öffnet in neuem Tab). ↩