RPA-Anwendungsfälle: Energiewirtschaftliche Kernprozesse – Teil 1

10. März 2022

Robotic Process Automation (kurz RPA) hat sich in den letzten Jahren zu einem wesentlichen Markttreiber für Energiemarktdienstleister entwickelt. Doch welche Prozesse können mit RPA automatisiert werden, um für Netzbetreiber, Messstellenbetreiber und Energielieferanten der Sparten Strom und Gas gewinnbringende Mehrwerte zu realisieren? Dieser Frage widmen wir in den nächsten Wochen mehrere Blogbeiträge, in denen wir für unterschiedliche Geschäftsbereiche der Energiewirtschaft beispielhaft aufzeigen, welche Prozesse sich für die Automatisierung mithilfe von RPA besonders gut eignen.

Robotic Process Automation

RPA ist eine innovative Technologie zur Automatisierung von Geschäftsprozessen. Durch den Zugriff auf das User-Interface bestehender Applikationen imitieren sogenannte Software-Roboter die Bedienung durch einen Menschen und führen so strukturiert Prozesse aus, die sonst manuell bearbeitet werden. Durch das Nachahmen von Benutzereingaben können Prozesse schnell und kostengünstig automatisiert werden, denn Veränderungen an bestehenden Applikationen oder die zeitaufwendige Entwicklung von Anwendungsschnittstellen sind nicht notwendig.

Es handelt sich bei RPA also nicht um einen physischen Roboter, sondern vielmehr um einen virtuellen Mitarbeiter. Die Software, die iterativ regelbasierte Aufgaben durchführt, ermöglicht system- und anwendungsübergreifende Automatisierungen, die minimalinvasiv, also ohne Veränderungen an bestehenden Applikationen und Systemen, umgesetzt werden können. Auf diese Weise können Mitarbeiter von monotonen, sich wiederholenden Aufgaben entlastet werden und die Bearbeitungszeit von Geschäftsprozessen sowie die Fehlerquote reduziert werden. Im Gegensatz zu großen Softwareprojekten bei herkömmlicher Automatisierung lassen sich RPA-Roboter schnell und daher kostengünstig umsetzen. Sie schaffen bei den entlasteten Mitarbeitern freie Kapazitäten für komplexere und somit wertschöpfendere Tätigkeiten.

Energiewirtschaftliche Kernprozesse

Diese Woche schauen wir auf energiewirtschaftliche Kernprozesse und geben einen Überblick über Geschäftsprozesse aus den Bereichen Marktkommunikation und Energiedatenmanagement, die sich für eine Automatisierung mithilfe von RPA eignen und die die items bereits mit RPA automatisiert hat. Gleichzeitig bieten wir einen Einblick, wie die RPA-Roboter in den speziellen Fällen arbeiten und zeigen auf, welche Entscheidungslogik und Prozesskomplexität abgebildet werden kann.

Für die Automatisierung mit RPA eignen sich wiederholende und regelbasierte Prozesse mit niedrigen Ausnahmeraten und elektronisch lesbaren Eingaben, unabhängig vom System, in dem diese ausgeführt werden. Dabei sind auch system- und anwendungsübergreifende Automatisierungen möglich. In diesem Blogbeitrag zeigen wir beispielhaft drei Automatisierungen in SAP-Systemen, die sich in andere ERP-Systeme übertragen lassen.  

In den nächsten Wochen geben wir darüber hinaus einen Einblick in RPA-Automatisierungen im Bereich Customer Relationship Management und Personalwesen. Außerdem beschäftigen wir uns mit dem sogenannten RPA 2.0, also der Einbindung von KI, zum Beispiel zur automatischen Texterkennung (OCR), in RPA-Automatisierungen sowie der Schnittstellenanbindung von Business Process Management und Ticket-Systemen. Abonniert unseren Blog, wenn Ihr diese Themen nicht verpassen wollt!

Die folgenden Prozessdarstellungen sollen einen Einblick in die implementierten Geschäftslogiken gewähren und haben keinen Anspruch auf Vollständigkeit, eine vollumfängliche Darstellung würde einen eigenen Blogbeitrag pro Prozess erfordern. Die IFTSTA-Klärfallbearbeitung wird etwas detaillierter beschrieben, aber auch hier sorgt die Komplexität der Fallbearbeitungen dafür, dass die Geschäftslogik nicht vollständig dargestellt werden kann. Bei vertiefenden Fragen zu diesen Prozessen steht Ihnen die Fachabteilung der items gerne zur Verfügung.

IFTSTA-Klärfallbearbeitung

Mit der MaKo 2020 wurde der elektronische Lieferschein eingeführt, der dem Lieferanten vor der eigentlichen Netznutzungsabrechnung zur Prüfung vorgelegt werden muss. Hiermit übermittelt der Verteilnetzbetreiber die aufsummierten Energiemengen im Abrechnungszeitraum. Der Lieferant erhält so die Möglichkeit, die Energiemengen zu prüfen, bevor es zur eigentlichen Netznutzungsabrechnung kommt und kann bei fehlerhaften oder abweichenden Energiemengen ggf. Einspruch einlegen, indem er den Lieferschein mit einer Negativ-IFTSTA-Nachricht ablehnt. Hierbei ist zu beachten, dass die vom Netzbetreiber bereits übermittelten Energiemengen zu den Daten im Lieferschein passen müssen, d. h. die Ablehnung kann auch in zuvor übermittelten, fehlerhaften Energiemengen begründet sein. Es gibt vielfältige Gründe für eine Ablehnung:

  • Die dem Lieferanten bereits vorliegenden Daten zu Energiemengen stimmen nicht mit den im Lieferschein gesendeten Energiemengen überein.
  • Es wurden mehrere Energiemengen für denselben Zeitraum versendet.
  • Der Lieferschein wurde mehrfach versendet.
  • Der Lieferschein bezieht sich auf einen falschen Zeitraum.
  • Energiemengen, die bereits Teil des Lieferscheins sind, werden erst nach dem Lieferschein versandt.
  • Und einige mehr…

Mit einer Negativ-IFTSTA lehnt der Lieferant den Lieferschein ab und verhindert somit die Abrechnung der Energiemengen im Lieferscheinzeitraum. Damit der Netzbetreiber die gelieferten Energiemengen abrechnen kann, muss auf diese Negativ-IFTSTA adäquat reagiert werden. Wird eine Negativ-IFTSTA vom Netzbetreiber als unberechtigt eingestuft, beispielsweise weil der Lieferschein korrekt erstellt wurde und korrekte Daten enthält, hat der Netzbetreiber wiederum die Möglichkeit, die ungerechtfertigte Negativ-IFTSTA mit einer COMDIS-Nachricht richtigzustellen.

Stellt der Netzbetreiber jedoch nach Prüfung aller vorliegenden Daten fest, dass tatsächlich ein Fehler im Lieferschein oder den dazugehörigen Energiemengen besteht, so führt er punktuelle Korrekturen aller fehlerhaften Energiemengen im Lieferscheinzeitraum sowie anschließend eine Stornierung und einen Neuversand des Lieferscheins auf Grundlage der neu versendeten Energiemengen durch.

Weil es jedoch viele Gründe für eine Negativ-IFTSTA geben kann, muss der Netzbetreiber unterschiedlichste Bedingungen prüfen, um adäquat reagieren zu können. Diese Prüfung bedeutet einen hohen manuellen Aufwand, da die eingesetzten ERP-Systeme die automatisierte Bearbeitung von Sonderfällen (bspw. rückwirkende Zählerstandkorrekturen) nicht abdecken. Nicht wenige Netzbetreiber haben täglich eine große Anzahl an IFTSTA-Klärfällen zu bearbeiten und je nach Größe des Netzgebietes kann täglich eine hohe Anzahl an zu bearbeitenden IFTSTA-Klärfällen aufkommen. Um den Netzbetreiber an dieser Stelle zu unterstützen, lässt sich die IFTSTA-Klärfallbearbeitung mithilfe von RPA automatisieren. Doch wie genau funktioniert diese Automatisierung und welchem Regelwerk muss der Software-Roboter hier folgen?

Automatisierte IFTSTA-Klärfallbearbeitung

Zunächst prüft der Roboter, für welche Klärfälle er überhaupt zuständig ist. RLM- und Pauschalanlagen werden beispielsweise für eine manuelle Bearbeitung durch den Sachbearbeiter ausgesteuert. Auch wenn die laufende Nummer des Lieferscheins eine konfigurierbare Grenze überschreitet, werden die Fälle ausgesteuert, weil dies darauf schließen lässt, dass der Lieferschein bereits mehrfach versendet und abgelehnt wurde. Es ist also davon auszugehen, dass eine bilaterale Kommunikation zwischen Netzbetreiber und Lieferant nötig ist, um diesen Fall zu klären. Bestimmte, in der IFTSTA-Nachricht angegebene Ablehnungsgründe werden vom Roboter ebenfalls ausgesteuert, weil bei diesen aufgrund ihrer besonderen Beschaffenheit eine Bearbeitung durch einen Sachbearbeiter notwendig ist.

Letztendlich hat der Roboter genau die Fälle identifiziert, die er verarbeiten kann und soll. Die Erfahrung hat gezeigt, dass etwa 80 % der Fälle vom Roboter verarbeitet werden, während die restlichen 20 % an einen Sachbearbeiter ausgesteuert werden.

Vereinfachte Darstellung des IFTSTA-Prozesses

Vorgehen des Roboters

Der Roboter beginnt nun mit der Verarbeitung der identifizierten Fälle. Zunächst sammelt er notwendige Daten. Er identifiziert den im Lieferschein angegebenen Abrechnungszeitraum und prüft die im System hinterlegten Ableseergebnisse der entsprechenden Anlage. Jeder Zählerstand muss genau einmal in Form einer MSCONS-Nachricht an den Lieferanten übermittelt worden sein. Ist ein Ableseergebnis nicht übermittelt worden, kennt der Lieferant den Zählerstand nicht und die Negativ-IFTSTA beruht sehr wahrscheinlich darauf. Ist ein Zählerstand mehrfach übermittelt worden, ist davon als Grund für die Negativ-IFTSTA auszugehen. Die wenigen Fälle, in denen Zählerstände entweder gar nicht oder mehrfach versendet wurden, werden zur weiteren Verarbeitung an einen Mitarbeiter ausgesteuert.

Sind alle Zählerstände korrekt übermittelt worden, werden anhand der Ableseergebnisse sogenannte Soll-Energiemengen berechnet. Hierbei wird eine Vielzahl möglicher Kombinationen aus Ablesegründen und Ablesearten berücksichtigt. Bei einem Umzug, einem Zählerumbau oder einer temporären Abmeldung können die Zählerstände beispielsweise nicht eins zu eins in auswertbare Energiemengen übersetzt werden. Der Roboter kennt die unterschiedlichen Kombinationen und ist in jedem Fall in der Lage, auf Basis der Ableseergebnisse die korrekten Energiemengen zu berechnen.

Die ermittelten Soll-Energiemengen vergleicht der Roboter im Anschluss mit den tatsächlich versendeten Energiemengen. Die versendeten Energiemengen werden vom Roboter bei Bedarf selbstständig punktuell korrigiert, wenn auf Grundlage der ermittelten Ableseergebnisse Fehler identifiziert wurden. Der Roboter identifiziert den Fehler, beispielsweise mehrfach versendete Energiemengen, falsche Energiemengen, falsche Zeiträume, sich überschneidende Zeiträume oder fehlender Energiemengenversand, und reagiert entsprechend. Dazu werden bereits versendete Energiemengen storniert und neu versendet oder, wenn notwendig, Erstversände eingeleitet. Der Roboter führt hierbei stets die minimale Anzahl an Anpassungen durch, die zum korrekten Ergebnis führt.

Daraufhin prüft der Roboter die Lieferscheine. Wenn diese beispielsweise mehrfach oder gar nicht versendet wurden oder es zu einer Überschneidung von Zeiträumen kam, korrigiert der Roboter diesen Fehler, indem er je nach Bedarf die Lieferscheine storniert und/oder neu versendet. Auch hier wird die minimale Anzahl an Aktionen durchgeführt, die das gewünschte Ergebnis zur Folge hat. Darüber hinaus prüft der Roboter, ob die Summe der versendeten Energiemengen identisch ist mit der Gesamtmenge, die im Lieferschein übermittelt wurde. Ist das nicht der Fall, wird der Lieferschein ebenfalls storniert und neu versendet.

Sollte der Fall eintreten, dass alle Lieferscheine korrekt, keine Korrekturen der Energiemengen nötig und alle Zählerstände korrekt versendet wurden, ist von einer unberechtigten Negativ-IFTSTA auszugehen. Der Roboter verschickt eine COMDIS-Nachricht mit entsprechender Bemerkung an den betreffenden Lieferanten. Die Erfahrung hat gezeigt, dass der Großteil der Negativ-IFTSTA tatsächlich ungerechtfertigt ist und mit einer COMDIS-Nachricht beantwortet werden kann.

MSCONS-51

MSCONS-Nachrichten werden im Regelfall vollautomatisiert vom ERP-System verarbeitet. Ist eine automatisierte Verarbeitung nicht möglich, wechselt die zugehörige MSCONS-Nachricht in den Status 51. Der Roboter liest also alle MSCONS-Nachrichten im Status 51 ein und prüft den Meldungstext. Über den Meldungstext erkennt der Roboter, wie mit der vorliegenden MSCONS umgegangen werden soll. In einigen Fällen sollen die MSCONS-Nachrichten nicht ins System eingespielt werden und werden daher vom Roboter als erledigt gekennzeichnet. In anderen Fällen identifiziert der Roboter die Problematik, die zu einer Einordnung in den Status 51 geführt hat. Je nach Meldungstext wird mittels individueller Logik geprüft, ob die MSCONS-Nachrichten ins System eingespielt werden dürfen oder als erledigt gekennzeichnet werden sollen. Bei einigen Meldungstexten müssen spezifische Aktionen durchgeführt werden, damit die MSCONS-Nachrichten vom System verarbeitet werden können.

Bei Zählerständen in einem bereits abgerechneten Zeitraum geht der Roboter beispielsweise wie folgt vor: Zunächst ermittelt der Roboter die MSCONS-Nachrichten im Status 51, die zu einer Anlage im System vorliegen. Hier prüft er, ob die Zählerstände eingespielt werden dürfen. Dafür werden die bereits vorhandenen Zählerstände, deren Ablesegründe- und Arten sowie Ablesegründe- und Arten der Zählerstands-MSCONS berücksichtigt. Für den Fall, dass zu einem Ablesedatum bereits ein Zählerstand im System ist, werden darüber hinaus notwendige Storno-MSCONS beachtet. Wenn der Zählerstand eingespielt werden darf, führt der Roboter nun einen rekursiven Rechnungsstorno durch. Er ermittelt also die Rechnung, die korrigiert werden muss und gegebenenfalls auch diejenigen Rechnungen, die danach erstellt wurden, und storniert diese. Falls Ausgleichsbelege vorhanden sind, werden diese für die Verarbeitung berücksichtigt. Auf Wunsch des Anwenders kann der Roboter Vertragskonten sperren und Kundenkontakte anlegen.  Im Anschluss wird die Verarbeitung der MSCONS-Nachrichten erneut angestoßen. Die neue Rechnungslegung wird dann der nachgelagerten Massenprozesskette überlassen (Energiemenge, Lieferschein, Abrechnung und Faktura). Falls ein aktiver Vertrag von der Rechnungskorrektur betroffen ist, kann der Roboter abschließend auch noch den Abschlagsplan anpassen.

Diese Automatisierung lässt sich sowohl für Netzbetreiber als auch für Lieferanten implementieren. Die unterschiedlichen Vorgaben und gesetzlichen Anforderungen können korrekt und wie gewünscht dargestellt werden.

Vereinfachte Darstellung des MSCONS-Prozesses

APERAK-Bearbeitung

Im Zuge der Marktkommunikation zwischen Netzbetreiber und Lieferant werden vom Netzbetreiber Marktnachrichten im ERP-System (bspw. SAP) erzeugt, die über ein B2B-System an den Lieferanten geschickt werden. Werden diese Nachrichten vom Lieferanten beanstandet, antwortet dieser mit einer APERAK-Nachricht. Der Empfänger der APERAK-Nachricht ist gesetzlich dazu verpflichtet, in einem bestimmten Zeitrahmen adäquat auf die APERAK zu reagieren. Bei großen Mengen an APERAK-Nachrichten ist es vielen Netzbetreibern nicht möglich, diese Frist einzuhalten. Eine RPA-Automatisierung ermöglicht die Einhaltung der zeitlichen Vorgaben und reduziert den manuellen Aufwand erheblich.

Der Roboter geht dafür wie folgt vor: Zunächst exportiert er die nötigen Daten aus dem B2B-System in ein Excel-Dokument. Ein Großteil der APERAKs kann vom Roboter verarbeitet werden (Z10, Z14, Z17, Z18, Z19, Z20, Z24). Die übrigen APERAKs werden zur manuellen Verarbeitung an einen Mitarbeiter ausgesteuert. Dieser muss den Fall prüfen und lediglich die gewünschte Antwort an den Marktpartner in das Excel-Dokument eintragen. Die Übermittlung der Antwort erfolgt am Ende der Verarbeitung durch den Roboter. In den Fällen, die automatisiert verarbeitet werden, füllt der Roboter das Excel-Dokument mit Antworten an den Marktpartner. Hierbei bezieht er sich auf den Ablehnungsgrund und gibt, im Falle einer ungerechtfertigten Ablehnung, den genauen Grund an, warum die Ablehnung als ungerechtfertigt eingestuft wird.

Wenn der Marktpartner beispielsweise die Energiemenge mit der Begründung ablehnt, dass er für den Zeitraum nicht für den Zählpunkt zuständig war, prüft der Roboter zunächst, ob die Ablehnung gerechtfertigt ist oder nicht. Bei ungerechtfertigter Ablehnung wird der genaue Zeitraum, in dem die Zuständigkeit des Marktpartners ermittelt wurde, als Antwort in das Excel-Dokument geschrieben.

Abschließend werden die Fälle pro Marktpartner gesammelt und beispielsweise in einer Mail verschickt. Auch die von den Mitarbeitern in dem Excel-Dokument eingetragenen Antworten werden an den Marktpartner übermittelt. Beim Fehlercode Z20 werden zusätzlich die zugehörigen Zählwerksdaten aufgelistet.

Beispiel (frei konfigurierbar):



Maximale Transparenz

Mit jeder Prozessausführung erzeugt der Roboter eine Logdatei, die alle Roboteraktivitäten festhält und am Ende jeder Ausführung an den zuständigen Sachbearbeiter übermittelt wird. In dieser Logdatei kann der Sachbearbeiter Informationen über alle verarbeiteten Aufgabenfälle einsehen und für jeden Fall nachvollziehen, ob dieser erfolgreich war oder was der Grund für einen Misserfolg war. Auf Wunsch kann der Kunde einen Monats- oder Wochenreport für seine RPA-Prozesse anfordern, der eine statistische Auswertung aller im Einsatz befindlichen Roboter enthält. Somit lässt sich die Wirtschaftlichkeit und das Einsparpotenzial von RPA-Automatisierungen eindeutig ermitteln.

Meldet Euch gerne bei uns, wenn Ihr Fragen zu diesem Beitrag habt. Wenn Euch der Artikel gefallen hat und Ihr auch die nächsten Beiträge unserer Themenreihe „RPA-Anwendungsfälle“ nicht verpassen wollt, abonniert gerne unseren Blog.

Marvin Kaltmeyer

Produktentwickler RPA
Marvin Kaltmeyer ist Produktentwickler im Bereich Robotic Process Automation und Social Media Manager bei der items. Er entwickelt Automatisierungen für unterschiedlichste Kundensysteme und interne Abteilungen, um den Kunden und seinen Mitarbeitern lästige und zeitaufwendige Aufgaben abzunehmen. Darüber hinaus beschäftigt er sich kreativ mit der Content Planung, aber auch mit Community Management und Performance Management. Nach der Arbeit fährt er gern Ski oder Inline-Skates, segelt, hört viel Musik oder schaut einfach nur Fußball.

Maximilian Gerhards

Entwickler und Administrator RPA
Maximilian Gerhards ist Entwickler und Administrator im Bereich Robotic Process Automation bei der items. Er verantwortet die Entwicklung von Prozessautomatisierung, Frameworks und Klassenbibliotheken, den Aufbau und die Administration der RPA-Infrastruktur und die Koordination der Entwicklungstätigkeiten. Nicht nur beruflich, sondern auch privat konzipiert, entwickelt und konstruiert er. Nur weniger Roboter und eher analoge Elektrogeräte wie Audioverstärker.