Jeden Tag dasselbe Ritual. Die mechanische Bebaubarkeitsanalyse, kurz mech. BBA, landet frisch aus dem System im Ordner. Und bevor irgendjemand in der Disposition wirklich mit ihr arbeiten kann, beginnt die eigentliche Arbeit. Spalten sortieren, überflüssige Zeilen löschen, Kostenstellen farblich hervorheben, negative Fehlmengen gelb markieren, Rahmen setzen. Von Hand.
Die Ausgangslage: Zwei Formatierungsrunden für dieselbe Datei
Der erste Blick in den bestehenden Prozess hat mich stutzig gemacht. Es lief längst ein Makro über die Rohdatei aus dem System, bevor sie überhaupt bei der Disposition ankam. Die Datei, mit der die Kollegen jeden Tag arbeiteten, war also technisch gesehen schon einmal automatisch formatiert. Trotzdem wurde genau diese Datei danach nochmal komplett von Hand nachbereitet. Zwei Formatierungsrunden für ein und dieselbe Datei, eine davon jeden Tag manuell.
Für mich war damit klar, dass ich kein zweites Script obendrauf schreiben will. Ich wollte das alte Makro ablösen und nur noch einen einzigen automatisierten Schritt am Ende haben.
Die Knacknüsse unter der Haube
Auf dem Papier klingt “Formatierung automatisieren” simpel. In der Praxis stecken in so einer Datei mehr Fallstricke, als man beim ersten Hinsehen vermutet.
Die Datenmenge ändert sich täglich. Wie viele Zeilen die mech. BBA an einem Tag hat, wie viele Kostenstellenblöcke, wie viele Fehlteile, das ist nie gleich. Ein Script, das feste Zeilennummern annimmt, wäre nach spätestens einer Woche kaputt gewesen. Also musste der relevante Datenbereich dynamisch erkannt werden, unter anderem daran, wo im Text tatsächlich “Kostenstelle:” steht. Nur so funktioniert das Script an einem Tag mit 200 Zeilen genauso wie an einem Tag mit 2000.
Kostenstellen sind in der Rohdatei alles andere als sauber. Da steht dann sowas wie “Kostenstelle: 3xyz0 …,3xyz0 … – 6 items” in einer einzigen Zelle. Bevor überhaupt irgendetwas hervorgehoben werden kann, musste das Script lernen, diese Strings zu zerlegen, weitere Kostenstellen nach dem Komma zu entfernen und den Zusatz mit der Item-Anzahl abzuschneiden.
Office Scripts und Excel sprechen bei Spaltenbreiten nicht dieselbe Sprache. Das musste ich erst lernen. Ich wollte die Spaltenbreiten angeben, wie in Excel. Also zum Beispiel Spaltenbreite 6. Nun, wenn ich das im Script mache, gebe ich damit eine Spaltenbreite von 6 Pixeln ein, nicht von 6 Standard-Excel Breiten. Dies habe ich über einen Multiplikator im Script gelöst.
Die Reihenfolge der Formatierungsschritte war nicht egal. Die wichtigste Erkenntnis kam erst gegen Ende der Entwicklung. Rahmen müssen als allerletzter Schritt gesetzt werden. Setzt man sie früher, überschreiben spätere Formatierungsschritte wie das Einfärben oder Ausrichten sie wieder teilweise, und am Ende sehen die Tabellentrennungen zerschossen aus.
Für die Umsetzung selbst habe ich gezielt mit Copilot gearbeitet, vor allem um die Eigenheiten der Office Script Syntax schnell zu validieren, ohne mich stundenlang durch die Dokumentation zu wühlen.
Das Ergebnis: Aus einer Datentabelle wird ein Arbeitsdokument
Aus einer technisch erzeugten Rohdatei wird jetzt auf Knopfdruck ein sofort nutzbares Arbeitsdokument. Kritische Fehlmengen, Materialflüsse und Qualitätsstatus sind auf einen Blick erkennbar, ohne dass vorher jemand zehn Minuten in Formatierung investiert.
Die tägliche Arbeitszeit der Disposition reduziert sich dadurch um etwa 10 bis 15 Minuten pro Tag. Klingt erstmal nach wenig. Hochgerechnet sind das aber 50 bis 75 Minuten pro Woche und damit 40 bis 65 Stunden im Jahr, die nicht mehr in Formatierung, sondern in eigentliche Dispositionsarbeit fließen. Ganz nebenbei sinkt auch das Risiko für Fehlinterpretationen, weil die Darstellung jeden Tag exakt gleich aussieht.
Der Ausblick: Vom Script zur vollautomatischen Kette
Aktuell muss die formatierte Datei aus technischen Gründen noch manuell oder per PowerShell ins Ziellaufwerk abgelegt werden. Der nächste Schritt liegt schon auf dem Tisch. Die Rohdatei landet künftig automatisch in einem SharePoint-Ordner, Power Automate erkennt die neue Datei, ruft das Office Script auf und legt das fertige Ergebnis direkt ins Archiv. Ganz ohne Benutzereingriff.
Ganz gelöst ist das noch nicht. Lokale Ausführung eines Office Scripts in Excel und serverseitige Ausführung über Power Automate verhalten sich nicht immer gleich und genau da muss ich noch tiefer rein, bevor die komplette Kette zuverlässig automatisch läuft. Hier sind meist leichte Anpassungen am Script nötig.
Man muss aber nicht auf die perfekte End-to-End-Lösung warten, um schon heute Zeit zurückzugewinnen. Man fängt mit dem Teil an, der am meisten wehtut, und baut von dort aus weiter.
Martin Reichelt ist Spezialist für Microsoft-Automatisierung und Verfechter der Citizen Developer Bewegung. Bei XelUp zeigt er, wie man das volle Potenzial von Excel ausschöpft und durch Power Automate effiziente Cloud-Workflows schafft, um wertvolle Lebenszeit im Job zurückzugewinnen.


