SoftProc macht selbst hoch individualisierte Software verständlich, denn es analysiert und visualisiert implementierte Anwendungen vom Programm-Code bis zum produktiven Prozess aus der laufenden Applikation heraus. Mit dieser lückenlosen, digitalen Dokumentation wird ihre Modernisierung einfacher, schneller und kostengünstiger.

Process Mining betrachtet Geschäftsprozesse durch die Datenbrille

Meist geht es bei einer Modernisierung nicht darum, auf eine andere Software zu wechseln. Vor allem nicht, wenn die Kernkompetenz eines Unternehmens von einer Individualsoftware gestützt wird. Die Intention dahinter ist es, die Geschäftsprozesse zu optimieren und flexibler für jegliche zukünftige Anforderungen zu gestalten, um sie den sich ändernden Marktsituationen anpassen zu können und zu erweitern, um neue Technologien einbinden zu können. Damit aber auch alle bisherigen Funktionen nach der Modernisierung noch vollständig und fehlerfrei zur Verfügung stehen, eventuelle Abhängigkeiten von anderen Systemen sowie der Einfluss von Sonderfällen berücksichtigt werden, müssen die systemtechnisch unterstützen Prozesse vollumfänglich bekannt und dokumentiert sein. Bei vielen Unternehmen ging dieses Wissen durch Fluktuation in der IT verloren oder war durch eine fehlende oder schlecht gepflegte Dokumentation nie wirklich vorhanden. Process Mining Tools lösen genau dieses Manko: Sie visualisieren durch einen datengetriebenen Blick die Geschäftsprozesse und geben die vollständige Transparenz über deren gelebte Realität. Innerhalb von Process Mining gibt es verschiedene Unterdisziplinen. Compliance vergleicht das ursprünglich definierte Prozessmodell mit dem tatsächlichen Ablauf durch den Anwender. Voraussetzung: Die Definition ist irgendwo festgehalten. Bei Process Discovery lassen sich aus Protokolldaten Rückschlüsse ziehen, wie der in der Software implementierte Prozess eigentlich aussieht.

Ein einfaches Beispiel veranschaulicht, was ein Process Mining Tool am Ende visualisiert: Ein Unternehmen möchte seine Standorte zusammenlegen und die Geschäftsprozesse im Zuge einer Software-Modernisierung harmonisieren. Bei der Compliance-Prüfung kommt heraus, dass der Klick auf den Befehl ‚Bestellung ausführen‘ bei den Mitarbeitern aus den verschiedenen Standorten manchmal unterschiedliche Änderungen im Datenmodell auslöst. Es muss also eine Abweichung vom ursprünglich definierten Prozess geben. Doch warum ist das so? Welcher ist der richtige und muss deshalb migriert werden? Die Antwort darauf lässt sich mit Process Discovery finden. Im Gegensatz zum Mitarbeiter am Standort A, betreut sein Kollege am Standort B auch Kunden aus dem Ausland, für die andere Bedingungen bzgl. Lieferzeit, Zoll etc. gelten. Hinter dem selben Befehl stehen also 2 unterschiedliche Datenmodelle, die auch nach der Modernisierung wieder genau so zur Verfügung stehen müssen.

Dem Datenmodell auf der Spur

Damit Process Mining Tools umfassende Prozessanalysen und -visualisierungen vornehmen können, müssen sie zum einen das der Software zugrundeliegende Datenmodell ‚verstehen‘ und zum anderen von den zu analysierenden Software-Systemen einen möglichst akkuraten Eventstream der Prozessdaten im Standardformat XES erhalten. Für große Standardsysteme mit konstanten Datenmodellen wie SAP, Microsoft Dynamics oder die Oracle E-Business Suite gibt es eigene Process Mining-Programme, welchen die Datenstruktur der Standardanwendungen bekannt ist. Sobald Unternehmen aber diese Standardsysteme auf ihre Anforderungen hin angepasst haben, können die für Process Mining notwendigen Eventstream-Informationen nicht mehr automatisch aus der Applikation extrahiert werden. Und damit stehen sie vor dem selben Problem wie die Nutzer einer reinen Individualsoftware oder von Legacy-Systemen: Um an die Rohdaten für Process Mining zu kommen, müssen sie selbst die Brücke zwischen Prozess und Datenmodell schlagen.
Aktuell gibt es hierfür zwei Möglichkeiten. Die erste: Key-User und Prozess-Owner beschreiben in umfangreichen Interviews den idealen Ablauf der Geschäftsprozesse. Parallel dazu wird das Datenmodell geparst, um die Auswirkungen eines Eingabeprozesses innerhalb des Datenmodells zu erkennen. Die anschließende Analyse des Datenmodells erlaubt eine Interpretation der dahinterliegenden Prozesse, also Aktionen, die durch Änderungen im Datenmodell und nicht durch direkte Eingabe hervorgerufen werden. Diese Methode ist nicht nur sehr zeitintensiv. Missverständnisse, Fehleinschätzungen oder einfach unbewusst unvollständige Angaben führen dazu, dass das Ergebnis eben nur eine Annahme und keine Tatsache ist, die zu verheerenden Fehleinschätzungen führen kann.

Die zweite – und damit aktuell die einzige softwaregestütze Methode – brachte das Projekt SoftProc hervor. Gefördert vom BMBF, haben die PITSS GmbH und die Universität Ulm darin ein softwaregestütztes Verfahren zur retrograden Prozessanalyse aus einer laufenden Applikation heraus entwickelt. Das Besondere daran: Es erkennt das Benutzerverhalten und stellt aufgrund der Kenntnis über die Tabellenstruktur den Zusammenhang zwischen den darunterliegenden Datenmodellen her. Der so identifizierte Kontext ermöglicht es nun unter Verwendung der klassischen Process Mining Verfahren einer Änderung im Datenmodell einen Eingabeprozess zuzuordnen – selbst bei einer Individualsoftware.

Darstellung: Alle automatisch von SoftProc erhobenen Informationen zu einem Prozess
Erklärung: Alle Informationen werden in dem gängigen Datenstromformat xes ausgegeben
Bedeutung: Die Gesamtheit aller Informationen zu allen Prozessen kann in ein Process Mining bzw. Process Discovery Tool eingespielt und genutzt werden

SoftProc schaut auf den Benutzer, nicht nur auf die Daten

Doch wie genau kommt dieser Datenstrom in SoftProc zustande? Wie werden das Userverhalten auf der einen Seite und dessen Auswirkungen im Datenmodell auf der anderen Seite erfasst? Und wie kann dieser Datenstrom als Transformationsglied zwischen einer Individualsoftware und einem beliebigen Process Mining Tool genutzt werden? Um die Software-Prozesse zu erkennen, beobachtet SoftProc den Anwender dabei, wie er einen Geschäftsprozess, zum Beispiel ‚Bestellung ausführen‘, über sein User-Interface abarbeitet. Dabei gibt es zwei verschiedene Aufzeichnungsvarianten. Bei der dedizierten Aufzeichnung (Dedicated Recording) bestimmt der Anwender Start und Ende des aufzuzeichnenden Geschäftsprozesses und grenzt somit exakt die ihn ausmachende Funktionalität ab. Im Endeffekt wie ein Interview – nur schneller und ohne einen Schritt zu vergessen, der quasi schon automatisch ausgeführt wird, ohne darüber nachzudenken.

Beim Silent Recording hingegen wird die gesamte Verwendung der Applikation protokolliert – von der ersten Anmeldung des Benutzers bis zum Schließen der Applikation. Machine Learning-Verfahren können in dieser Aufzeichnung Muster erkennen. Genauer gesagt: sie erkennen zum Beispiel, ob der Anwender ebenfalls eine Bestellung ausgeführt hat. Selbst wenn er dies aufgrund eines ‚Sonderfalls‘ anders verlief als bei dem Kollegen. Da hierbei nicht nach Mustern in den Datenmodellen, sondern in den Aktionen des Benutzers gesucht wird, sind diese wiederum in SoftProc zweifelsfrei mit dem Anwendungsprozess und den zugehörigen Datentabellen verknüpft. Deshalb ist in SoftProc auch ohne Interviews nachvollziehbar, warum ein Geschäftsprozess unterschiedlich ausgeführt wurde.

Die Fähigkeit zur Verknüpfung mit den Daten ist auch einer der Gründe, warum SoftProc gerade für Individualsoftware so interessant ist. SoftProc basiert auf einer Oracle-Entwicklungsplattform. Deshalb kann die Nomenklatur aus dem User-Interface einer ebenfalls auf Oracle-basierenden Software direkt übernommen werden, um Kontextinformationen aus dem Programm zu erhalten und schließlich mit den Daten zusammenzufassen. SoftProc spricht quasi die Sprache des Nutzers und deshalb kann auch jedes Stück Code, das beim Recording nicht erfasst und somit noch keinem Geschäftsprozess zugeordnet wurde, bis zur Abhängigkeit im User-Interface rückverfolgt werden. Und damit lassen sich wertvolle Funktionen, die einst aufwändig programmiert wurden, aus diversen Gründen aber nie genutzt und darum in den damit verbundenen Datentabellen keine Änderung bewirken, erkennen und erhalten.

Darstellung: Bsp Forms Flow – Userverhalten im dedicated Recording
Erklärung: Es zeigen sich viele Wechsel zwischen einzelnen Formularen
Bedeutung: User springt viel zwischen den Formularen hin und her – Optimierungspotenziale für den Prozess werden ersichtlich, um den Ablauf zu vereinfachen bzw. zu verkürzen

Darstellung:
Prozessfluss – was und wie wurden die Elemente genutzt
Erklärung:
Form, Farbe, Größe, Werte geben Auskunft über Art, Zusammenhänge und Schwachstellen
Bedeutung:
Optimierungspotenziale werden aufgezeigt

Branchenunabhängige Lösung aus der Cloud

Für wen eignet sich die nun verfügbare Lösung aus dem Förderprojekt, die Anwendungen einlesen, analysieren, verstehen und abbilden kann? Vorerst für alle, deren Anwendung in Oracle programmiert wurde. Dabei ist es völlig irrelevant, auf welche Branche die Applikation zugeschnitten wurde. Dann natürlich für diejenigen, die eine vollständige Dokumentation ihrer Individualsoftware wünschen oder benötigen. SoftProc sollten Unternehmen in Betracht ziehen, die damit rechnen, dass Modernisierungen anstehen, die sehr zeitintensiv und umfangreich werden, und die Anwendung aber so bald wie möglich den Geschäfts- und/oder Produktionsprozessen wieder zur Verfügung stehen soll.

Das Tool, das PITSS unter anderem auch als Cloud-Lösung anbietet, ist nicht nur hilfreich bei der Modernisierung von Individual- oder Legacy-Anwendungen, wenn die einstigen Programmierer nicht mehr verfügbar sind. SoftProc unterstützt auch diejenigen, die bereits verdrängt haben, wie viel Zeit, Aufwand und vielleicht auch Nerven sie investiert haben, um Hürden bei der Programmierung zu überwinden. Auch wenn er vielleicht weniger steinig ist und man dadurch hin und wieder einen Schritt schneller gehen kann – der Weg einer erneuten Programmierung ist der selbe wie beim ersten Mal. Mit SoftProc lässt er sich jedoch zuverlässig abkürzen.