Header image

It's full of stars

Where documentation meets reality


Probleme bei der Verwendung von LIPOKs und die Lösung via KI

By Tobias Hofmann November 5, 2026 Posted in SAP
Tags: SAP

Reading time: 8 min read


LIPOKs sind ein in der Architektur etabliertes Tool. Sie kommen zum Einsatz, wenn es um das Verstehen eines Prozesses geht. Sie helfen, um die elementaren Fragen eines Prozesses zu beantworten: Wer ist involviert, welche Daten werden warum ausgetauscht. Die Fragestellung führt dazu das hier oft die Geschäftssicht, d.h. Prozessverantwortliche und Anwender, involviert sind. Der Nebeneffekt dieser Anwendungsgruppe ist auch, dass das Tooling möglichst einfach zu sein hat. Die Diskussion und die Erfassung von Wissen und Erwartungen steht im Vordergrund. Komplizierte Tools sind damit außen vor. Im Ergebnis ist die Erfassung eines LIPOK ein einfaches Tool: 5 definierte Spalten. Mehr nicht. Das kann man in einem Workshop offline auf Papier machen. Oder in Excel. In Word. Gerne wird auch ein Wiki dafür genommen.

Woraus besteht ein LIPOK?

lipok abstrakt Wireframe

Und damit hat man dann auch schon das Grundproblem der meisten LIPOKs: Es ist Chaos. Informationschaos.

LIPOKs erstellen ist einfach

Oft denkt man, dass das Chaos daher kommt, dass unterschiedliche Leute mit jeweils einer eigenen Sicht bei der Erfassung der Informationen zu einem LIPOK zusammenarbeiten: unterschiedliche Sichten, unterschiedliche Flughöhen. Ja, die Abstraktionshöhe ist wichtig. Und ja, das ist durchaus ein Punk der die Erstellung eines LIPOKs beeinflusst. Wenn die Prozessberater bei einem LIPOK zu einem Verkauf sich eher mit konkreten Zahlungsschritten befassen - wird in Bar bezahlt, per Karte, Digital, soll ein E-Beleg ausgestellt werden, die PLZ erfasst, ein Punktebogen verteilt werden - die Anwender dagegen sich eher fragen: ist der Bezahlvorgang online oder physikalisch in einem Laden, dann liegen hier unterschiedliche Sichten auf den Prozess vor. Das löst sich aber recht schnell auf. Um etwas aufzuschreiben, muss man über den gleichen Prozess, die gleichen Schritte und gleiches Verständnis verfügen. Dies hierzu stellen ist ja auch Aufgabe des LIPOKs.

Das Chaos ist damit nicht dadurch entstanden, dass unterschiedlichen Leute zusammen gebracht wurden, oder dass diese nicht homogene Gruppe nicht unbedingt die gleiche Sprache sprechen oder gar das gleiche Verständnis zum Prozess haben. Das Chaos kommt daher, dass ein LIPOK von Natur aus einfach zu erstellen ist. Zu einem Prozess mehrere LIPOKs zu haben ist keine Seltenheit. Das ist in Ordnung so lange diese auf den unterschiedlichen Flughöhen und Sichten basieren. Von abstrakt auf konkret und dabei 2, 3 oder mehr LIPOKs zu haben ist nichts Außergewöhnliches. Wenn es jedoch auf der gleichen Abstraktionsebene mehrere LIPOKs gibt, dann ist das ein Problem. Zu oft wird einfach mal ein neuer LIPOK erstellt. Es ist ja auch eine einfache Tätigkeit. Im Resultat stellt sich dann aber auch die Frage, welcher denn dann gültig ist? Der Letzte? Wenn ja, warum wurde dann der Vorgänger nicht aktualisiert? Oder entfernt?

Auf bestehenden Aufbauen bedeutet es verfügbar zu haben: auffindbar, mit Kontext.

… Wiederverwenden nicht

Warum einen vorhanden LIPOK anpassen? Oder diesen sogar zuerst suchen? Es ist auch oft so, das gar nicht bekannt ist, dass es einen LIPOK zu dem Prozess schon gibt. Gerade wenn das alte Projektteam aufgelöst wurde, der alte Speicherort nicht zugänglich ist, da keine Berechtigung vorhanden, oder - Worst Case - gar gelöscht wurde. Ein Klassiker auch: der LIPOK existiert, aber wo denn nur? Beim externen Berater auf der Festplatte? Unter dem vor 10 Jahren abgelösten Prozessnamen oder gar nur mit dem Codenamen? In einer Sharepoint Seite versteckt, in der X. Unterebene? In einem Wiki? Aber die Seiten sind über die Jahre schon mehrmals umgezogen worden und die Links funktionieren nicht mehr alle? Gerade bei komplexen Projekte und größeren Unternehmen sind die notwendigen Informationen durchaus mal in der 10. Verzeichnistiefe zu finden. Bei der Suche werden dann noch andere Informationen bevorzugt. Oder ein weiterer Klassiker: die wichtigen Informationen sind in einem Archiv. Für das man eine bestimmte Berechtigung benötigt. Und die Daten wurden auch schon auf ein anderes Archiv-System umgezogen. Der LIPOK ist dann ein gif, das in ein PDF konvertiert wurde … das mit einem Passwort versehen ist und nur mit einem speziellen Viewer angezeigt werden kann.

Organisationen geben sich durchaus Mühe Informationen zu erstellen und zu bewahren. Die Realität zeigt aber leider auch zu oft das die Informationen verloren gehen können … und werden.

Qualität

Hinzu kommen weitere Probleme, die in der Natur eines LIPOKs liegen. Die Benennung ist nicht eindeutig. Der Einkauf heißt einmal Einkauf, dann Procurement, oder Abt-Eink., oder es wird die interne Bezeichnung FB-EK-III verwendet. Für einen einzelnen LIPOK nicht schlimm, wenn man aber mehrere verstehen will, dann ist das ein Problem. Gut für das Verständnis ist natürlich auch zu sehen welche Geschäftsobjekte verwendet werden und wie diese zusammenhängen. Indirekt sind diese über die Spalten Input und Output erfasst. Eine explizite Auflistung fehlt aber meistens. Und auch hier: eine einheitliche Benennung ist hilfreich. Ebenso ist es hilfreich sehen zu können in welchen LIPOKs die Lieferanten und Kunden denn vorkommen. Wenn man auf einen Blick sehen kann, dass ein Kunde in 5 LIPOKs vorhanden ist, so ermöglicht dies einen guten Einblick in die Zusammenhänge der Prozesse. Diese Probleme kann man aber nicht lösen, indem LIPOKs irgendwo abgelegt werden. Hierfür ist eine strukturierte Erfassung notwendig.

Transparenz

Was kann hier helfen? Bedauerlicherweise gibt es nicht die eine Lösung. Teams werden sich immer ändern. Projekte und Informationen weiterhin archiviert werden. Jemand wird immer darauf bestehen, dass die wichtigen Informationen in einem Archiv verschwinden. Leute werden sich auch in Zukunft doppelte Arbeit machen da sie gar nicht wissen werden das jemand vor ihnen die Daten erfasst hat. Was man allerdings machen kann, ist zu versuchen die Informationen außerhalb dieses Zyklus zu erfassen. Zum einen, in einem separaten Tool. Natürlich ist ein Wiki nett, ein Excel einfach zu teilen, eine SharePoint Seite leicht zu teilen.

Eine spezialisierte Software, ein Tool, das man unter einem eigenständigen Namen, einer URL, laufen lassen kann. Indem die LIPOKs zentral erfasst sind und (hoffentlich) für alle zugreifbar und auffindbar. Dies wird benötigt. Kein verschachteltes Wiki. Der Standard ist ja sich ein solches Tool einzukaufen. Am Ende hat man das Tool als Teil einer evtl. viel zu umfangreichen und komplexen EA Suite bekommen. Und hier dann wieder den Lock-in befürchten. Oder die gefürchtete Lizenz-Hürde: nettes Tools, aber man braucht eine Architekten-Lizenz um darauf zugreifen zu können. Dann ist man ja wieder bei dem Anfangs erwähnten Problem des Zugangs.

Und keiner weiß, ob die Lizenz nach 3 Jahren verlängert wird. Eine Alternative: das Unternehmen entwickelt etwas Eigenes oder man verwendet eine Open Source Software.

Make ist das neue buy

Die Möglichkeiten die man heute dank KI hat eröffnen aber neue Optionen. Eine spezialisierte Software für einen abgegrenzten Einsatzzweck 🔗 kann in kurzer Zeit erstellt werden und ist dabei individuell zugeschnitten auf die eigenen Anforderungen. Da man ja die Unternehmensrichtlinien bezüglich QA der KI übergeben kann 🔗, ist auch sichergestellt, dass das Tool nicht nur lauffähig ist, sondern auch Wartbar.

Dank AI kann sich jedes Unternehmen oder halbwegs fähige (Enterprise) Architekt 🔗 das selbst entwickeln lassen 🔗. So ein Tool kann dann alles was man in anderen Lösungen vermisst. Daten eines LIPOKs in Text, in Markdown, exportieren. Informationen manuell durch Personen erfassen zu lassen, oder automatisch von anderen Tools. So etwas kann helfen den Teufelskreis zu durchbrechen. Nicht neu anlegen, was es schon gibt. Das vorhandene wiederverwenden und verbessern. Dazu kommt, das durch die KI so ein Tool nicht mehr etwas ist, das man über einen komplexen Beschaffungsprozess einkaufen muss oder als Teil einer evtl. viel zu umfangreichen und komplexen EA Suite bekommt.

LIPOK Management App

Collage der App

Zum Beispiel die von mir mit Claude entwickelte LIPOK Management App 🔗. Man kann diese App einfach verwenden oder als Grundlage verwenden, um sich inspirieren zu lassen. Wichtig ist das man auf jeden Fall ein paar der Features der App berücksichtigt:

Gerade der letzte Punkt bietet einen unglaublichen Mehrwert. Eine Analyse durch die AI kann sehr interessant sein. Das Prozessverständnis erfasst man zuerst mit den ausgewählten Personen. Dann lässt man die KI die Prozessdokumente durchgehen und daraus den LIPOK erstellen. Oder man lässt die KI eine vorhandene Anwendung analysieren und die gefundenen LIPOKs erstellen. In der Theorie sollte in allen Fällen die LIPOKs übereinstimmen. Vielleicht nicht zu 100%, aber auch nicht nur ganz grob. Und wenn der aus der produktiv genutzten Anwendung generierte LIPOK so gar nicht mit der Dokumentation oder dem Verständnis der Personen übereinstimmt, dann hat man ein Problem. Denn was ausgeführt wird, ist ja nicht die Dokumentation oder der darin formulierte Wunsch. Sondern das, was implementiert ist. Wenn hier ein Lieferant oder Kunde fehlt, wenn ein Geschäftsobjekt gar nicht erkannt wurde von der KI: Warum? Diese Frage zu beantworten kann mehr Prozessoptimierung auslösen als die letzten Projekte vom Management zu diesem Thema.

Informationen

Die App kann man lokal oder in Docker ausführen. Die LIPOKs werden im Backend in einer DB gespeichert. Das Frontend ist über einen Browser verfügbar. Nach dem Start die App hier aufrufen: http://localhost:4200 🔗