Die in der Vergangenheit durchgeführten Initiativen zur Automatisierung von Geschäftsprozessen in Unternehmen werden zunächst von ERP-Systemen und auch von Workflow-Systemen (sogenannten BPM-Systemen, Business Process Management Systemen) dominiert. Diese Systeme und Software ermöglichen es dem Anwender, einfache Abläufe, die immer wiederkehrend sind, zu automatisieren. In der Regel sind dies Tätigkeiten und Abläufe, die innerhalb eines Systems oder Software ablaufen und stattfinden.
Dateneingaben, Auswertungen anstoßen, im Allgemeinen die Nutzung und Bedienung dieser Software erfolgt durch menschliche Bedienung. Dabei kann der Nutzer solcher Software Einzelaufgaben-oder Teilschritte als auch mehrere Teilschritte zu einem Gesamtergebnis durchführen.
Als Beispiel dazu kann der Order to Cash Prozess dienen, bei dem ein Mitarbeiter einen Auftrag annimmt, ihn im System anlegt und somit die Kundenbestellungen in ein System überträgt. Dort stehen sie dann zur weiteren Verarbeitung (dem Prozessablauf oder Workflowmanagement) zur Verfügung.
Dabei ist es unerheblich, ob wenige weitere Verarbeitungsschritte notwendig sind oder sehr viele. Die Auftragsanlage ermöglicht in der Produktion, Herstellung oder beim Großhandel die Bereitstellung und den Versand von Waren. Die Auslieferung durch die Logistik erzeugt einen Rechnungsbeleg. Diese Rechnung wird nach Zahlungseingang in der Finanzbuchhaltung gutgeschrieben und der Order to Cash Cycle (Prozess) ist abgeschlossen.
Die eingesetzte Software hilft dabei, diese Prozesse zu (Teil-) automatisieren.
Zunächst muss eine klare RPA-Strategie und ein klar definiertes und realisierbares Prozessmodell vorliegen. Dieses Prozessmodell wird dann durch die eingesetzte Software genutzt, um alle notwendigen Aufgaben und Tätigkeiten anzustoßen.
Dabei übernimmt die Software die Bereitstellung der notwendigen Daten (zum Beispiel: Stücklisten, Artikelstammdaten, Kundenstammtaten und vieles mehr). Wenn Business Process Management Systeme im Einsatz sind, dann wird diese auch genutzt, um Prozesse (Abläufe) grafisch darzustellen. Diese können mit einem flexiblen BPM-System manuell geändert werden, um sich neuen Anforderungen schnell anpassen zu können. In der Regel kennen Anwender diese Systeme auch unter dem Begriff der Workflow Systeme. Grafische Darstellungen können Prozessablaufschemen, Swimlane Diagramme oder auch bekannte populäre Prozessdarstellungen in verarbeitenden Unternehmen sein, zum Beispiel in der Lebensmittelindustrie bei der Herstellung von Lebensmitteln oder bei der Milchverarbeitung im Rahmen der Kuppelproduktion)
Workflow-Prozesse oder -Abläufe werden meist auch bei Freigabeprozessen genutzt. Zum Beispiel bei der Freigabe von Zahlungen, die eine bestimmte festgesetzte Grenze überschreiten und damit eine 2. Unterschrift benötigt wird, um den Prozess abzuschließen.
Wenn eine Prozessoptimierung über die Grenzen eines Systems hinaus definiert wird, erkennen die Prozessengineers oder Prozessdesigner relativ schnell, welche Komplexität erforderlich ist, um diese Ansprüche zu realisieren. Dies können schon im ersten Augenblick klein erscheinende Aufgaben wie den Anschluss einer Waage in deiner Ausgangslogistik mit anschließenden Versandpapieren sein. Oder komplexere Abläufe wie sie in Kieswerken oder in der Baulogistik vorkommen, wie zum Beispiel, der LKW kommt auf das Werksgelände wird auf Basis seiner KFZ Nummer identifiziert, fährt über eine LKW Waage, wird am Verladepunkt bestückt (mit einer Asphaltrezeptur speziell für diese Fahrt), wieder gewogen, und wird bei der Ausfahrt aus dem Werksgelände abgemeldet und damit eine Rechnung auf ein Projekt oder Baustelle oder Kunden generiert. Dieses kleine Beispiel ist ausbaufähig und soll nur beispielhaft zeigen, welche Komplexität möglich ist.
Eine hohe und große Komplexität in Softwareprozessen abzubilden führt meist automatisch zu hohen Aufwendungen für Programmierungen. Dies können Anpassungen im Programm selbst als auch Anpassungen und Realisierungen von Schnittstellen sein. Eine Pflege solcher Individuallösungen ist in der Regel sehr aufwändig, kostenintensiv und vor allem bei Upgrades und Updates der Kernprogramme (zum Beispiel ERP-Software oder ERP-Systeme) auch fehleranfällig. Ausführliche Teststrategien und Testszenarien sind die Folge und auch notwendig, bevor ein Programmupdate dann wirklich live gehen kann. Dies ist unbedingt zu Berücksichtigen im Rahmen einer ROI Betrachtung auch über den Zeitraum der Nutzung. Das Stichwort dazu lautet "Total Cost of Ownership). Bei Prozessabläufen, die ein sehr hohes Prozessvolumen (Anzahl von Geschäftsvorfällen) haben, ist dies sicherlich eher zu rechtfertigen, als bei geringem Prozessvolumen.
In vielen ERP Projekten kennen wir die Problemstellungen, dass komplexe Angebotskalkulationen im bestehenden ERP System nicht oder nur oft nur mangelhaft abgebildet werden können. Hier schlägt die Stunde der Schatten IT und der Excel Listen. Grundlagen der Kalkulation werden (manuell) in Excel-Berechnungstabellen ausgelagert, dort angereichert, berechnet und dann wieder in das ursprüngliche Kalkulationsmodul der ERP-Software (manuell) zurückgespielt. Mangelnde Schnittstellen zu Software für Personalverwaltung, Mitarbeiter-Zeiterfassung und vieles mehr sind nichts außergewöhnliches, um Grenzen von ERP-Systemen darzustellen.
Welches sind die häufigsten Grenzen einer übergreifenden Prozessautomatisierung (robotic process) beim Einsatz von ERP-Systemen?
Eingeschränkte Abbildung und Realisierung unternehmenssprziefischer Prozesse (meist auch Kundenprozesse, die als USP wichtig sind).
Hoher Wartungsaufwand des späteren Systems bei starker Individualisierung und individuellen Anpassungen
Hoher Aufwand bei der Abbildung systemisch bedingter Grenzen einzelner Softwarepakete im Gesamtprozess
Fehlende oder zu geringe Anzahl mitgelieferter standard Schnittstellen von ERP-Programmen
Softwareanbieter versuchen mehr und mehr ihre Kunden (Anwender) im Rahmen von Initiativen zur Digitalisierung innerhalb ihres Systems zu halten. In diesen Systemen wird dann gerne versucht, alle Prozesse zu automatisieren und die Organisationsabläufe abzubilden. Parallel wird diese Bestrebung flankiert durch die Nutzung von im ERP-System möglichen Workflows oder Robotic Process Funktionen (Best Practice RPA-Anwendungen).
Abbildung: Darstellung eines Prozessablaufs in einer Swim Lane am Beispielprozess Vertrieb
Im Gegensatz zum Versuch, alle Lösungen im ERP-System zu realisieren, versucht RPA einen komplett anderen Ansatz. RPA versucht, den Ablauf der menschlichen Tätigkeiten nachzuvollziehen und ihn so weit wie möglich zu imitieren. In der Regel ist es so, dass dies dazu führt, dass die klassischen Transaktionsprogramme wie ERP-Systeme oder Warenwirtschaftssysteme keine Änderungen in ihrer Struktur oder durch Programmierung erfahren sollten.
Kostspielige und im Lebenszyklus eines ERP-Systems wichtige Pflege und Wartung werden auf das Standardsystem reduziert. Softwareänderungen der bestehenden Funktionen im ERP-System sollen ausgeschlossen oder vermieden werden. Damit wird der Versuch unternommen, aufwändige Schnittstellen zu vermeiden und damit die Kosten für deren Programmierung gar nicht erst entstehen zu lassen.
Es werden sogenannte RPA-Bots eingesetzt. Kleine, eigenständige Programme, die nur eine einzige Funktion haben. Diese kleinen, individuellen RPA-Bots führen auf Basis von Prozessabläufen und eventuell auch Algorithmen die vorher vom Menschen (Nutzer*innen) durchgeführten Schritte automatisch durch. Algorithmen kommen meist dann zum Einsatz, wenn Entscheidungen getroffen werden müssen. Oftmals sind dies ganz einfache Sachverhalte, die im durch Boolesche Algebra wie zum Beispiel größer als (A>B) oder kleiner als (A<B) oder auch Limitgrössen (A=C) den Bot steuern und einen anderen Bot aufrufen können. Entscheidend dabei ist aber, dass der Prozessablauf eindeutig und klar ist. Es gibt verschiedene Möglichkeiten, diese Bots zum Einsatz zu bringen. Diese können vom Aufzeichnen von Arbeitsschritten bis zur individuellen Programmierung ausgestaltet werden.
RPA soll und kann kein ERP-System oder eine Warenwirtschafts-Software in der heutigen Form ablösen. Der Einsatz von RPA-Technologien dient vielmehr dem Zweck, dass ein RPA die Automatisierung vornehmen kann, die in einem klassischen ERP-System viel zu aufwändig zu programmieren wäre. Wenn es überhaupt gelingt. Das Ziel der RPA ist daher keinesfalls der Ersatz bestehender Systeme, sondern deren Ergänzung. Sie sind auch im Rahmen der IT technisch sauber voneinander abgrenzbar. Dies ist deutlich bei Fragen zu Implementierung oder zur Implementierungsmethodik zu erklären: In ERP oder Workflow Systemen wird ein Zugriff über sogenannte Business-Layer bzw. Daten-Layer realisiert, während bei RPA Lösungen die (simpleren) Presentation-Layer zum Einsatz kommen. Es ist auch möglich, mit RPA Lösungen Zugriffe auf Master Data Systeme oder Metadaten unterschiedlicher Anwendungsprogramme zu realisieren.
Es kann sich für Unternehmen mit vielen manuellen Eingriffen, Dateneingaben etc. im klassischen ERP-System lohnen, sich mit der Rapid Process Technologie RPA auseinanderzusetzen. Kosteneinsparungen durch RPA-Einsatz gegenüber Programmieraufwand an der ERP-Software oder am Warenwirtschaftssystem sind darstellbar.