Christoph Pacher spricht im State of Process Automation mit Samuel Farag, Solution Consultant bei Frends, über das spannende Thema “Lean Automation”.
Das Gespräch beleuchtet, wie eine schlanke, wartungsarme Automatisierungsstrategie erfolgreich implementiert werden kann und welche Vorteile dies für Unternehmen in verschiedenen Branchen, einschließlich Energie, Einzelhandel und internen Service Providern, bietet.
Samuel Farag erläutert, wie Frends iPaaS Unternehmen dabei unterstützt, ihre Prozesse effizient zu automatisieren und zu integrieren, und welche Rolle eine strategische Herangehensweise dabei spielt. Erfahren Sie mehr über die Herausforderungen und Best Practices im Bereich der Prozessautomatisierung und wie Frends dazu beitragen kann, Ihre Automatisierungsziele zu erreichen.
Christoph Pacher: Hallo und herzlich willkommen zu einer neuen Episode von The State of Process Automation. Mein Name ist Christoph Pacher und es freut mich, dass du auch heute wieder mit dabei bist.
Mein heutiger Gast ist Solution Engineer bei Frends und das heutige Thema Lean Automation, wie eine schlanke, wartungsarme Automatisierungsstrategie erfolgreich implementiert wird. Hallo und herzlich willkommen, Samuel Farag.
Samuel Farag: Hallo Christoph, ich freue mich auf die Folge. Vielen Dank, dass ich hier sein kann.
CP:Samuel, es freut mich, dass du dir ein paar Minuten Zeit genommen hast und ich habe dich jetzt ganz kurz vorgestellt. Du bist Solution Engineer bei Frends, erzähl gerne mal. Was machst du als Solution Engineer bei Frends ganz genau und natürlich auch, was steckt hinter Frends?
SF: Ich fange mal damit an, was hinter Frends steht. Das ist eine Integrationsplattform, in unserem Fall as a Service. Das heißt, auf der Plattform deckt man seinen kompletten Integrationsbedarf ab, den kompletten Lebenszyklus von so einer Integration.
Wir erstellen die Integration, wir deployen diese, managen und monitoren alles von Anfang bis Ende hin zum Retirement, wenn es dann vielleicht eine neue Integration gibt oder ein neues Automatisierungsprojekt. Im Rahmen dessen bin ich bei unseren Kunden tätig, die Bedarfsanalyse, Anforderungsdefinition zu machen, die Lösungsdemonstration natürlich zu übernehmen und grundsätzlich einfach als technischer Berater in diesem Automatisierungs- oder Integrationsprojekt, das der Kunde umsetzen möchte. Ja, an seiner Seite zu sein und den Kunden zu betreuen.
CP: Super spannend und ich würde sagen, wir tauchen am besten gleich in unser heutiges Thema ein, Lean Automation. Viele denken wahrscheinlich so jetzt gleich, okay, Lean Startup oder ähnliches oder generell an "Lean". Erzähl gerne mal so aus deiner Perspektive, aus deiner Erfahrung heraus, was verstehst du unter Lean Automation?
SF: Ich habe unter Lean Automation eine ganz klare Vorstellung und zwar ist das die strategische Anwendung von Automatisierungstechnologien und –prozessen, heißt, dass wir Abläufe darin schlanker, effizienter und agiler gestalten.
Das glaube ich ist bekannt und ist jetzt nichts Neues, aber dass wir eben auch innerhalb dieser Automatisierungsprozesse leane Prinzipien beachten und diesen treu bleiben. Das heißt, Sachen wie das Schaffen eines Flusses, das Beachten, dass es immer ein wertschöpfen der Prozess ist und dass wir diese kontinuierlich durchgängig und reibungslos gestalten.
CP: Und ich würde da noch hinzufügen, weil was man bei vielen Unternehmen natürlich beobachtet ist, die fangen mal mit einem Tool an, wie zum Beispiel mit Robotic Process Automation, wo viele davon auch überzeugt sind, andere weniger, andere mehr, hat seine Daseinsberechtigung definitiv.
Aber auf was ich hinaus will ist, dass diese Unternehmen mal mit Robotic Process Automation zum Beispiel starten und sie denken eher kurzfristig und sehen die schnellen Erfolge, bedenken aber gar nicht, was passiert eigentlich, wenn ich jetzt zum Beispiel 100 Use Cases umgesetzt habe und all diese Use Cases mit Robotic Process Automation automatisiert habe. Sie vergessen dabei, dass diese 100 Use Cases dann auch gewartet werden, bedeutet, ich habe keine Leane herangehensweise, weil ich schaffe eigentlich mir trotzdem wieder einen großen Aufwand oder einen großen Wartungsaufwand, den ich bewältigen muss, weil ich Prozesse automatisiert habe und je mehr ich automatisiere, desto größer ist der Wartungsaufwand.
Das heißt, zusammengefasst, eine leane herangehensweise ist, dass ich diese Ressourcen die ich habe, so effizient wie möglich einsetze, dass ich, wenn ich automatisiere, natürlich am Ende wirklich den größten Erfolg herausbekomme, oder?
SF: Genau. Also ein Grundsatz ist es ja, das habe ich auch in einer vorherigen Folge bei dir tatsächlich gehört, dass wir Prozesse automatisieren möchten, die mit dem Wachstum des Unternehmens skalieren. Und so ein Prozess, wie du jetzt angesprochen hast, mit einer RPA-Solution umgesetzt, der skaliert ja ganz stark mit dem Unternehmen. Je mehr das wächst, umso mehr solcher Prozesse bräuchten wir im Einsatz. Aber umso größer wird auch dieser Overhead, den diese Prozesse kreieren.
Wenn wir sagen, die Unternehmen haben da keinen leanen Gedanken gehabt, als sie diese Automatisierungsstrategie umgesetzt haben, dann hört sich das an wie ein Vorwurf. Ich denke aber, in der Regel fangen Automatisierungsprojekte ganz organisch an. Man hat da ein konkretes Problem und überlegt sich, okay, in dem derzeitigen Ist-Prozess, den ich gerade habe: Wie könnte ich da jetzt ein digitales Tool benutzen, um mir dabei zu helfen? Eine RPA ist natürlich sehr gut übertragbar, weil die hilft uns, den Prozess so zu bewerkstelligen, wie wir ihn derzeit meistens auch als Mensch machen, indem die RPA zum Beispiel über das Interface geht und dort die Daten anlegt oder die Aufgaben erledigt.
Aber wir überlegen uns nicht von Grund auf den Prozess, was ist der Input, den ich habe. was möchte ich mit diesem Prozess bewerkstelligen und was soll der Output sein, wofür soll dieser Output genutzt werden? Weil dann fangen wir an, digitale Prozesse auch wirklich als solche wahrzunehmen und umzudenken. Und dann überlege ich mir vielleicht nicht, wie bekomme ich Daten von A nach B mit einer RPA, sondern ich überlege mir, hey, das sind beides Softwareprogramme, die haben bereits Schnittstellen, wo die Maschinen technisch miteinander kommunizieren können. Warum nutze ich das nicht und transformiere diesen halbdigitalen Prozess in einen komplett digitalen Prozess, der dann wirklich nur noch Maschine zu Maschine-Kommunikation ist, bei dem kein Mensch mehr seine Hände drin hat.
CP: Wir können uns da, glaube ich, eigentlich so drei Szenarien vorstellen, weil es gibt Unternehmen, die sind noch komplett am Anfang. Das heißt, die beschäftigen sich gerade mit Automatisierung, haben vielleicht die ersten Use Cases mit Robotic Process Automation zum Beispiel umgesetzt, sehen da die ersten Erfolge. Das ist so das Unternehmen, das gerade am Anfang steht.
Dann gibt es natürlich die Unternehmen, die schon fortgeschritten sind. Die haben ein Send-off Excellence. Da sitzen vielleicht so zwei, drei Mitarbeiter in diesem Send-off Excellence. Die haben schon einige Prozesse mit diversen Tools automatisiert und die treiben die Initiative in dem wirklich voran.
Und dann haben wir so das dritte Szenario. Da sind die. wir sie Profis. Ich habe vor kurzem mit dem Orhan zum Beispiel gesprochen. Orhan Kotzsch ist verantwortlich für das Thema Prozessautomatisierung bei Bosch Mobility. Er hat erzählt, sie haben schon 1330 Use-Cases umgesetzt. Sie haben auch einen sehr bunten Blumenstrauß aus diversen Tools, aber haben diese wirklich im Griff, können diese orchestrieren. die würde ich dann eher so als Profi einordnen.
Lass uns mal jetzt bei diesen drei Szenarien auch so genau herausarbeiten, weil es gibt natürlich überall unterschiedliche Herausforderungen und starten wir mal bei den Anfängern. Welche Herausforderungen beobachtest du da konkret, wenn es ums Thema Automatisierung geht?
SF: Ja, jemand, der ganz am Anfang von einer Automatisierung steht und da brauchen wir noch gar nicht von Automatisierungsstrategie reden. Weil meistens geht es da dann doch eher um das konkrete Umsetzen von Problemen oder Herausforderungen, die man jetzt gerade hat, wo man sich denkt, hier möchte ich vielleicht was automatisieren aus unterschiedlichen Gründen, weil mir die Leute fehlen oder ähnliches, weil einfach die Komplexität überhand nimmt, wie auch immer. Auf jeden Fall überlegt man sich dort meistens erst mal, was ist der Case?
Und dann fängt es oft damit an, wir brauchen irgendwelche Arten von Daten. Am Ende vom Tag ist eigentlich ja ein digitaler Prozess einer, der Daten von A nach B bringt, diese verändert oder irgendwas mit Daten auf jeden Fall anstellt. Und ein Thema, das da dann meistens aufkommt, ist Datenverfügbarkeit. Die haben dann verschiedene Software, verschiedene Systeme im Einsatz, wissen aber nicht genau, wie sie dort an die benötigten Daten herankommen. Die Hürde, an diese heranzukommen, ist zu hoch, weil man vielleicht ein altes On-Premise-Legacy im Einsatz hat, weil man intern nicht das Know-How an verschiedene Schnittstellen zu kommunizieren oder Ähnliches.
Oder man hat diesen Case, man hat zwei Systeme, die man gut beherrscht, aber die Systeme sprechen eine unterschiedliche Sprache, sei es eine andere Schnittstelle oder ein anderes Format und muss dort dann erst mal übersetzen können. Und da fängt es dann an, dass man sich Gedanken macht, ja, Wie bewerkstellige ich den Case dann eigentlich? Und die eigentliche Funktionalität der Automatisierung ist dann oft nicht das Problem, sondern mehr dieses Drumherum. Wie kann ich eigentlich eine Umgebung schaffen, in der ich automatisieren kann?
CP: Wenn wir jetzt bei Beispiel Robotic Process Automation im Vergleich zu einer Integration zum Beispiel bleiben, kann ich dann natürlich auch, weil du gerade gesagt hast, den Use-Case zu bewerten. kurzfristigen Möglichkeiten mit Robotic Process Automation, weil ich kann innerhalb von einer Woche, zwei Wochen, drei Wochen den Use Case abbilden und auf der anderen Seite gibt es aber die Möglichkeit eine Integration zu machen, aber dies dauert vielleicht etwas länger. Wie würdest du das gewichten oder wie siehst du generell so Robotic Process Automation als Quick Fix und auf der anderen Seite Integration als Mittel bis langfristige Lösung?
SF: Ich bin jetzt durch meinen Hintergrund natürlich etwas biased und bin großer Fan von durchgängigen Integrationen. Das kann eine RPA natürlich nicht schaffen, aber das heißt nicht, dass RPA kein legitimes Tool ist, das einem wahnsinnig bei einer Automatisierungsstrategie helfen kann. Aber man muss eben von jedem Tool den richtigen Kontext betrachten. Und da kommt es dann zu so einer ja eigentlich best of breed Strategie, von der man oft redet. dass man für jeden Case, den man hat, das bestmögliche Tool benutzt, um diesen Case dann umzusetzen. Und oftmals ist es so, dass man mit RPA natürlich wahnsinnig schnell starten kann.
Hier ist die Implementierungsgeschwindigkeit natürlich enorm. Es kann eigentlich jeder User, der den normalen Prozess durchführen kann, mit sehr wenig Aufwand diesen mit einer RPA auch automatisieren. Da muss man klar sagen, die Hürde eine Integration zwischen den zwei Systemen dann zu schreiben, die ist deutlich höher. Allein auch was das Know-how angeht, wobei wir hier ja mit No-Code-Lösungen, Low-Code-Lösungen schon deutlich nutzerfreundlicher mittlerweile unterwegs sind, als das vielleicht früher mal war. Aber wir haben eben auch den Nachteil, dass dieser Quick-Fix nicht so gut skalierbar ist. Da kommen wir dann in die Situation, wenn wir jetzt merken, hey, Das war cool, das hat uns Mehrwert gebracht. Wir möchten gerne mehr damit machen. Dann kommen wir in diese Situation, die du zu Beginn angesprochen hast, dass wir einen Overhead kreieren. Weil diese ganzen Prozesse, die wir erstellen, die müssen wir up to date halten. Wir müssen die Hoheit über diese behalten. Und irgendwann ist das Ganze nicht mehr wirklich nachhaltig.
Dann haben wir im Prinzip eine Schattenwirtschaft, statt dass wir Aufwand haben, der sich mit den Prozessen, die wir bewerkstelligen, beschäftigt. haben wir jetzt nebenher einen Overhead, der sich mit den Prozessen, die diese Prozesse bewältigen, beschäftigt. Und ob ich jetzt drei Leute habe, die diese Aufgabe wältigen oder drei Leute habe, die diese Prozesse managen, das macht ja eigentlich keinen Unterschied. Dann bin ich eigentlich wieder bei Punkt 0 angekommen.
CP: Das heißt, du beobachtest, wenn man von Anfang an, wir bleiben jetzt beim Unternehmen, das noch ganz am Anfang ist, wenn man nicht mittel- und langfristig denkt, schafft man das eine Problem aus der Welt und erzeugt eigentlich mit der Lösung das nächste Problem.
SF: Genau, das sehen wir oft und das sind dann oft die Fälle, wo im Prinzip Leute wie ich dann hereinkommen und dann sind wir an dem Punkt bei der Bedarfsanalyse oder der Anforderungsdefinition, wo man sich überlegt, okay, wie ist denn jetzt gerade die Umgebung im Moment und wie hattet ihr euch das eigentlich vorgestellt, was wäre eigentlich die Situation, wie wir sie haben möchten? Und da merkt man dann, hey, Quickfixes sind cool. Die helfen einem auf die Schnelle. Aber wenn man jetzt wirklich nachhaltig automatisieren möchte, dann benötigt das eben auch eine langfristige Strategie, die auf nachhaltige Werte und nachhaltige Möglichkeiten setzt.
CP: Was nimmst du da konkret wahr? Weil du gerade so beschrieben hast, wenn du dann mit den Unternehmen zusammen arbeitest und in die Analyse gehst und du stellst fest, es gibt so die zwei unterschiedlichen Welten. Die eine Welt ist so, wie sie ist, der Status Quo, und das, wie sie auch aus der Perspektive von den Unternehmen sein sollte. Wie sehen diese zwei Welten dann konkret aus und wie sieht die Lücke dazwischen aus?
SF: Ich denke, was man oft sieht, ist, dass die Komplexität dann doch unterschätzt worden ist. Dass unterschätzt worden ist, wie vielleicht die eigene IT-Landschaft aufgestellt ist. Dass unterschätzt worden ist. Wie viel möchten wir automatisieren? Wie angesprochen, es fängt meistens mit einem kleinen Anwendungsfall an. Man merkt, das bringt Erfolg und möchte mehr und mehr machen. Und irgendwann merkt man dann, hey, wir setzen hier auf einmal sehr viel auf Automatisierung oder auch digitale Prozesse, aber wir haben gar nicht wirklich die interne Struktur dafür, um das umsetzen zu können, um das nachhaltig umsetzen zu können. Und da braucht es dann Tools, die einem helfen können.
CP: Das heißt, die haben da eben in dieser Situation nicht mittel- und langfristig gedacht. Und gehen wir aber jetzt mal einen Schritt weiter. Jetzt haben wir über die Situation eines Unternehmens gesprochen, das noch relativ am Anfang ist. Die nächste Situation sind die Unternehmen, die schon einige Use Cases umgesetzt haben. Die haben wahrscheinlich auch nicht nur ein Tool im Einsatz, sondern ein ganzer Werkzeugkasten. Und auch da ist ja wieder der Punkt, dass ein Werkzeugkasten ist gut. Weil ich möchte natürlich nicht mit einem Tool alles erschlagen, sondern ich möchte einen Werkzeugkasten haben.
Das Problem wird nur wieder, wenn mein Werkzeugkasten unaufgeräumt ist und übergeht, dann habe ich wieder keinen Überblick und weiß gar nicht, welche Werkzeuge generell im Einsatz sind. Erzähl gerne mal. Gehen wir von so einem fortgeschrittenen Unternehmen aus. Welche Herausforderungen haben die konkret?
SF: Ja, die haben die Herausforderung, dass meistens die Automatisierung oder die Automatisierungsstrategie auch wieder sehr natürlich gewachsen ist, wie du das ansprichst. Verschiedene Toolsets, vielleicht sogar deutlich zu viele Tools, das merkt man dann irgendwann, dass die Subscription-Kosten irgendwie explodiert sind, weil man hatte hier den Anwendungsfall und wollte ja das bestmögliche Tool dafür nutzen und hier wieder ein anderer und da auch wieder das bestmögliche Tool. Da ist dann zwar eine Auto aber diese ist nicht von Anfang an auf Nachhaltigkeit ausgelegt worden, sondern die ist auch organisch gewachsen. Und da muss man dann oft erst mal her der Lage werden.
Und man muss sich in der Landschaft zurechtfinden können. Was bei solchen Unternehmen dann doch oft fehlt, sind Themen wie Datenkonsistenz, konsistente Datenverfügbarkeit, dass wirklich ein Governance Modell für Daten oder für APIs, interne APIs und ähnliches besteht. Also wir haben fortgeschrittene Automatierungsprozesse aber unbedingt eine einheitliche Strategie, die wirklich eine Sprache spricht.
CP: Und so wie du angesprochen hast, dass es organisch wächst, ist natürlich auch ein Problem. Hängt natürlich stark mit jetzt der Unternehmensgröße zusammen, auch mit den verschiedenen Standorten. Also ist ein Unternehmen vielleicht nur auf einen Standort aktiv, oder gibt es da internationale Standorte? Aber wenn wir jetzt mal ein Unternehmen hernehmen, das international unterwegs ist, diverse Standorte hat, dann kann es ja sein, und es ist sehr häufig so, dass in Deutschland zum Beispiel fünf verschiedene Tools eingesetzt werden und in Frankreich fünf andere Tools.
Und am Ende hat man, so wie du erwähnt hast, höhere Kosten von der Lizenzseite, man hat auch wieder höhere Wartungskosten, man hat auch wieder höhere Kosten bezogen auf personelle Ressourcen, weil ich brauche natürlich überall die Experten für den einzelnen Tools. Gibt es da noch andere Herausforderungen, die du hier beobachtest?
SF: Ja, absolut. Da geht es dann darum, dass wir eine sehr heterogene Landschaft vorfinden, die auch wieder organisch gewachsen ist. Und das soll alles kein Vorwurf sein, sondern das sind natürliche Prozesse, die entstehen.
Unternehmen sind dynamisch, sind lebendig und sind immer im Wandel. Es ist ganz natürlich, dass wir irgendwann an einem Punkt ankommen, wo wir vielleicht mal wieder etwas gerade ziehen müssen und uns auf eine gemeinsame Homogene Strategie und Arbeitsweise einigen müssen. Und da ist es dann eben notwendig, dass man klare Strategie etabliert, dass man klare Governance-Modelle etabliert und dass man diese auch beherzigt.
Ich glaube, in der letzten Folge wurde angesprochen, oft hat man dann lokale Versionen von Ist-Prozessen. Ja, also man folgt dem Prozess, wie er sein soll. aber doch nicht so 100 Prozent ganz und das ist nirgendswo dokumentiert. Und da sind dann schon so Sachen wie, dass Daten vielleicht auf andere Art und Weise beschafft werden oder auf minimal andere Art verarbeitet werden. Und das kreiert schon Diskrepanzen, die im Großen und Ganzen dann eben wieder zu fehlender Datenkonsistenz führen, aufgrund der wir wieder nicht automatisieren können oder nicht sauber automatisieren können.
Hier muss man dann zusammenfassen. Also konsolidieren, was man hat. Man muss wahrscheinlich wieder eine Bedarfsanalyse machen. Was brauchen wir eigentlich? Und wie laufen unsere Prozesse nicht nur ab, sondern benötigen wir diese Prozesse? Was möchten wir eigentlich erreichen mit diesen ganzen Prozessen? Können wir das vielleicht auch ganz anders denken und viel, viel effizienter, viel leaner umsetzen? Und da kommen wir dann an den Punkt, wo man wirklich große Lean Automation Projekte im Prinzip betrachten würde.
CP: Und so wie du angesprochen hast, es wächst organisch. Man hat unterschiedliche Tools bei den unterschiedlichen Standorten im Einsatz. Und ich habe mir auch im Vorfeld so diverse Studien angesehen. Es gibt natürlich von verschiedenen Anbietern Studien, es gibt von verschiedenen Unternehmensberatungen Studien. Immer zu dem Thema natürlich, wie viele Applikationen sind denn so in einem Unternehmen im Einsatz.
Hängt natürlich auch wieder stark damit zusammen, wie groß ist das Unternehmen. Aber die Zahlen sind so zwischen 100 und 900 Applikationen in einem Unternehmen. Und wenn man sich da einfach mal die Frage stellt, wenn ich das konsolidieren würde, quasi alles zusammenführen würde und dadurch weniger Tools im Einsatz habe, was wird mir das alleine schon an Kosten ersparen? Da können wahrscheinlich viele Unternehmen sehr viel Kosten einsparen, oder?
SF: Absolut. Die Kost sind an der Stelle natürlich enorm. Aber es geht vielleicht nicht unbedingt um Sachen wie Lizenzkosten, sondern es geht um den ganzen Overhead, den sowas kreiert. Um da mal ein Beispiel zu nennen, wir hatten jetzt letztens mit einem Unternehmen gesprochen, das auch recht organisch gewachsen ist, jetzt aber ein starkes Investment in den letzten Jahren erfahren hat und durch M&A sehr stark gewachsen ist. Und gerade bei M&A-driven Firmen hast du ja die Situation, dass in den zugekauften Firmen Da sind natürlich schon Systeme im Einsatz. Und da muss man trotzdem schnellstmöglich hinkommen, eine konsistente Art und Weise zu haben.
Wir brauchen eben diese Integration, um von CMA zu CAMB zu synchronisieren, um zumindest eine gemeinsame Datengrundlage zu haben. Dass wir von heute auf morgen das alles umkrempeln. Diese Vorstellung ist utopisch und nicht machbar. Heißt, wir müssen auch immer mit diesem lebendigen und dynamischen Umfeld leben. Und wir müssen dieses Umfeld einbinden können.
Das machen wir eben dadurch, dass wir sicherstellen, dass die Hauptprozesse, die wir haben, an die wir sozusagen dann von außen anschließen würden, ja das Trittsystem, das vielleicht die zugekaufte Firma benutzt, dass wir hier etablierte Standards innerhalb unserer Hauptprozesse haben, dass wir klare Governance-Modelle innerhalb dieser haben, die Integration dann zu schreiben vom Drittsystem in unsere Hauptsysteme. Das ist keine große Arbeit mehr und dann können wir Stück für Stück diese Drittsysteme eben überführen, bis wir wieder alles auf einer Linie haben und dann wird vielleicht eine neue Firma zugekauft, bei der der ganze Prozess wieder beginnt.
CP: Und lass uns da jetzt gleich weitermachen, weil wir haben jetzt schon ein paar Mal über Lean Automation gesprochen und wartungsarme Automatisierung. Deswegen lass uns jetzt davon ausgehen, dass wir genau diese Strategie umsetzen. Du hast auch schon ein paar Mal angesprochen, Governance ist wichtig, man muss eine Linie haben und ähnliches. Jetzt gehen wir da wirklich in die Tiefe, dass am Ende wirklich völlig verständlich ist, okay, ich möchte Prozessautomatisierung bei mir im Unternehmen vorantreiben. Wie gehe ich da ganz genau vor, um Lean Automation zu betreiben? Was ist der erste Schritt?
SF: Indem wir zum Beispiel Konnektivität und Interoperabilität herstellen. Das sind jetzt ganz große, tolle Worte, unter denen sich bestimmt jeder sehr viel vorstellen kann. Kleiner Spaß in der Stelle.
Konnektivität heißt Anbindbarkeit. Haben wir die Fähigkeit, an unsere Systeme anzubinden, an die ich anbinden möchte? Ja oder nein? Wenn wir verschiedene Schnittstellen in den Systemen haben, dann brauche ich irgendwas, das dazwischen vermittelt. Hab ich das? habe ich die Interoperabilität, heißt, behandle ich zum Beispiel die gleichen Daten an Stelle A und B gleich. Wenn ich eine API habe, die uns Daten gibt, habe ich eine konstante Art, wie ich Daten aus meinen APIs herausgebe, auch intern. Das sehen wir ganz oft, dass man zum Beispiel an externe APIs, da macht man das, weil der Kunde soll eine gute Erfahrung haben und die Nutzererfahrung der API, die soll herausragend sein. Und bei internen APIs, da sind wir einfach froh, wenn wir die Daten verfügbar gemacht haben, aber achten nicht wirklich auf die Nutzererfahrung.
Wobei es ja vollkommen egal ist, ob ein Nutzer intern oder extern ist. Der hat ja den Sinn, dass er diese Daten gerne nutzen möchte, einfach nutzen möchte. Heißt, herstellen von Interoperabilität. Dann müssen wir natürlich Sicherheit und Compliance-Standards etablieren und gewährleisten, gerade in komplexen hybriden Umgebungen. Ich möchte vielleicht gewisse Daten, die auf einem On-Premises-System vorliegen, auf irgendeine Art und Weise in einen Prozess einbinden, der am Ende diese in die Cloud gibt oder sogar extern verfügbar macht. Wie stelle ich sicher, dass der Zugriff am Anfang des Prozesses gesichert ist, ohne dass ich hinten raus dem Endnutzer Zugang auf mein On-Premises-System gebe? Also solche Sachen, wie kann ich eine hybride Umgebung dann managen, wie kann ich diese beherrschen. Da geht es dann um solche Themen.
CP: Und das ist ja zu dem ersten Schritt. Und Schritt zwei, wo sich dann natürlich auch viele Unternehmen eigentlich schon befinden, weil die ganze Systemlandschaft in den letzten Jahren organisch gewachsen ist. Ich habe eine große Komplexität und die Frage ist, wie kann ich die auf der einen Seite beherrschen? auf der anderen Seite natürlich auch reduzieren.
SF: Da geht es dann darum, dass wir diese erst mal beherrschen möchten. Das heißt, wir gehen hin, überlegen uns, haben wir diese Interoperabilität? Wenn nicht, dann müssen wir diese herstellen. Auch rückwirkend gewissermaßen herstellen.
Da sind wir in der Situation, wir können jetzt nicht jedes etablierte System einfach von heute auf morgen ablösen. Das funktioniert nicht. Was wir aber machen können, ist, wir könnten diese zum Beispiel anbinden und dann eine API dafür erstellen, über alle Systeme hinweg, die einem konstanten Modell folgt.
Heißt, wir haben ein kleines Dach über unsere Applikation, über unsere Systeme gebaut, die diese Interoperabilität schon mal herstellt, die diese Konnektivität schon mal herstellt. Und dann können wir den nächsten Schritt machen, dass wir eben Stück für Stück hier die Komplexität dann reduzieren, weil uns das neue Setup das erst mal erlaubt.
CP: Und was kommt danach?
SF: Ja, danach überlegt man sich, okay, jetzt habe ich meine Systeme anbindbar. Jetzt habe ich meine Systeme interoperabel. Jetzt kann ich doch anfangen zu automatisieren. Und das ist vollkommen richtig. Jetzt sind wir nämlich endlich an dem Punkt, wo wir das auch in so großen Projekten dann machen können. Da überlege ich mir, welche Prozesse brauche ich eigentlich, um meine Geschäftsprozesse abbilden zu können, die ich möchte.
Ich finde auch digitale Prozesse sind Geschäftsprozesse. Ich verstehe nicht, warum wir da teilweise unterscheiden. Setze diese in Gesamtkontext und dann setze ich diese um. Nachhaltig wieder, heißt: wir möchten Modularisierbarkeit innerhalb dieser Umsetzung. Wenn ich eine Authentifizierung schreibe für System A, dann möchte ich die einmal schreiben und jeder Prozess, der diesen nutzt, greift bitte auf dieses Modul zu und ich schreibe die nicht. 500 mal in 500 unterschiedlichen Prozessen. Ich möchte das Packen und wieder verwenden können. Das erlaubt mir einmal, dass ich die Komplexität reduziere. Ja, ich habe dann vielleicht 500 Integrationsprozesse oder Automatisierungsprozesse die aber vielleicht nur aus 10, 15, 20 einzelnen Modulen wirklich bestehen und dazwischen sind vielleicht kleinere Transformationen oder Ummapping von Datum oder ähnlichem. Aber das hört sich schon deutlich beherrschbarer an, wenn ich sage, hey, du hast 20 Prozesse, die du eigentlich wirklich managen musst.
Also wir stellen diese Modularisierbarkeit her, wir parameterisieren diese am besten und dann können wir diese wiederverwendbar machen. Zweite Effekt, dass wir deutlich schneller natürlich automatisieren können. Wenn ich mir erstmal vielleicht halbfertige Prozesse nehmen kann, diese nur noch teilweise verändern muss. oder ich habe einen komplett neuen Automatisierungsprozess aber ich weiß, ich kann die Schnittstelle schnell ansprechen.
Ich habe die Hauptfunktionen, habe ich direkt schon bereit, kann mir das eigentlich nur noch zusammenbauen und muss minimale Veränderungen dazwischen noch bewerkstelligen und habe sofort einen neuen Automatisierungsprozess, Heißt, ich kann wahnsinnig schnell automatisieren. Und das ist der Punkt, wo wir hinkommen. Und das ist Lean Automation, in dem wir eben auch innerhalb der Automatisierungsprozesse gucken, dass wir nach Lienprinzipien handeln.
CP: Das heißt, wenn ich das so ganz kurz zusammenfassen darf, wenn wir uns jetzt vorstellen würden, wir denken kurzfristig, wir führen Robotic Process Automation ein und wir automatisieren sehr viele Prozesse, schaffe ich, wie bereits erwähnt, ein Problem aus der Welt und mache mir ein nächstes Problem, weil wenn ich es nicht richtig angegangen bin, dann durch mir schwer das Ganze zu überwachen, zu orchestrieren, zu warten. Wenn ich aber sage, ich gehe das ganze lean an und ich baue mir auch Bausteine, die wiederverwendbar sind, dann bedeutet das eigentlich, je mehr ich automatisiere, desto schneller werde ich jedes Mal bei der nächsten Automatisierung, weil die Wahrscheinlichkeit sehr hoch ist, dass ich schon einen Baustein habe, der die nächste Automatisierung beschleunigt.
SF: Absolut richtig. Je mehr Lego-Bausteine wir sozusagen haben, umso schneller und schöner können wir unsere Lego-Häuser bauen, um jetzt mal in so einer übertragenen Sprache zu sein. Aber ja, vollkommen richtig. Und dein RPA-Tool, das du dir vielleicht am Anfang dann eingekauft hast, das ist auch nicht für den Schrank und musst da jetzt verstauben, sondern das findet Anwendung in Systemen, die vielleicht schwer ansprechbar sind.
Wir reden zwar von Maschine zu Maschine-Kommunikation Aber das heißt nicht zwangsweise, dass alle Systeme gut maschinell ansprechbar sind. Heißt, wir haben dann vielleicht den RPA-Bot, der über unserem Legacy-System hinweg die Daten einträgt oder besorgt. Aber hinten raus ist diese RPA wieder angebunden an unsere Integrationsprozesse und dadurch auch an unsere Automatisierungsprozesse und fügt sich wieder in die gesamteinheitliche Struktur ein. Und genau das machen wir eben auch mit allen anderen Teilen. Wir setzen dort Tools ein, wo sie wirklich benötigt sind und dort, wo wir maschinell miteinander kommunizieren können, automatisieren können, dort machen wir das auch.
CP: Über ein Thema möchte ich noch ganz kurz sprechen, bevor wir dann zur letzten Frage kommen, weil was man bei manchen Unternehmen auch beobachtet, ist, dass sie dann zum Beispiel einen Prozess automatisieren, egal mit welchen Tool. Die Automatisierung aber nicht wirklich dokumentiert wird. Das heißt, es wird gemacht, aber die Frage ist, wie ist es gemacht worden?
Und dann geht die Person und am Ende weiß niemand mehr, wie es eigentlich automatisiert worden ist und es wird unübersichtlich. Und ich muss mich wieder reinarbeiten, reindenken, um generell mal die Automatisierung zu verstehen. Wie wichtig ist die Dokumentation auch bei der Automatisierung und auch nicht nur wie es automatisiert worden ist, sondern generell wieder Prozesse abläuft.
SF: Das ist enorm wichtig. Es ist der Klassiker. Wir haben einen Senior Developer, der ist seit 15 Jahren im Unternehmen, kennt das Unternehmen wie seine Westentasche und automatisiert fleißig hin und her. Das ist der Prozess-Zauberer und er hat das Know-How. Der hat schönen Code geschrieben, aber die Großteil der Dokumentation findet in seinem Kopf statt.
Wenn dieser Developer uns jetzt aus unterschiedlichen Gründen wegfällt, dann hat erstens niemand mehr die Fähigkeit, diese bestehenden Automatisierungen, wenn sie mal nicht funktionieren, wieder zum Laufen zu bekommen. Noch haben wir wahrscheinlich die Möglichkeit, weitere Automatisierungen wirklich umzusetzen, weil wir nicht wirklich wissen, wie wir zuvor automatisiert haben.
Heißt, Dokumentation ist ein ganz großer Teil einer nachhaltigen Strategie. Nachhaltig heißt ja, dass wir auch weiterhin darauf aufbauen möchten und dafür brauchen wir eben Dokumentation. Wir wollen außerdem, ich hatte es vorhin angesprochen, digitale Geschäftsprozesse auch als grundsätzliche Geschäftsprozesse beachten. Das heißt, wir wollen auch Leute aus dem Business, aus den Abteilungen, die nicht unbedingt die IT sind, die Möglichkeit geben, digitale Prozesse zumindest mitdenken zu können, verstehen zu können, was dort passiert. Weil dann können diese Leute, die sich in ihrem Bereich ja am besten auskennen und die Experten sind, weiter überlegen, hey, was kann ich eigentlich automatisieren? Die wissen dann erst, was eigentlich alles möglich ist. Und das reizt so ein bisschen die Kreativität dann auch an.
CP: Und da wir jetzt zum Ende kommen, was ist so dein Top-Tipp, wenn es darum geht, Prozessautomatisierung leaner zu gestalten?
SF: Ja. Dass wir leane-Prinzipien beherzigen.
Das ist so ein bisschen wieder back to the roots. Heißt: wir überlegen uns, hey, sind wir durchgängig? Schaffen unsere Prozesse eigentlich Wertschöpfung? Ist dieser Prozess, von dem ich denke, dass er gerade Wertschöpfung generiert, wirklich so wie er ist notwendig?
Hab ich diesen Prozess genommen und einfach ins Digitale übertragen oder habe ich diesen Prozess digital gedacht?
Das sind tatsächlich so die einfachsten Dinge, auf die man dann zurückkommt. Es sind meistens die Basics und die Basissachen, die den großen Unterschied machen. Weil wenn wir ein Fundament haben, auf das wir aufbauen, dann wird es nach oben hin immer wackeliger, wenn dieses Fundament nicht solide ist. Und dann kommen wir wieder bei den Sachen an wie beherrschen der Komplexität, herstellen von Datenkonsistenz, Sicherheit und Compliance gewährleisten und Konnektivität. und Interoperabilität herstellen.
CP: Samuel, das ist ein perfekter Schluss. Ich habe jetzt so ein Haus im Kopf, wo das Fundament komplett instabil ist und kurz am Zusammenbrechen ist. Das bleibt definitiv negativ in Erinnerung und das möchte man definitiv nicht haben und deswegen sollte man ein starkes Fundament bauen, dass das Haus auch sehr, sehr lange steht. An dieser Stelle, das war ein super spannendes Gespräch. Danke Samuel, dass du dabei warst. Alles Gute.
SF: Ich danke dir, Christoph. Vielen Dank.