Inhalt
PERSÖNLICHE EINORDNUNG
Beim Aufbau von Kaventix wurde für mich sehr deutlich, dass Probleme im Tagesgeschäft häufig nicht dort entstehen, wo sie später sichtbar werden. Eine Information kann im Produktdatensatz fehlen, aber erst im Versand oder in der Kundenkommunikation auffallen. Eine technische Änderung kann auf einer Seite richtig aussehen und trotzdem einen nachgelagerten Ablauf beeinflussen. Solange jeder Schritt nur für sich betrachtet wird, wirken solche Schwierigkeiten wie einzelne Fehler. Erst der Blick auf die gesamte Kette macht sichtbar, wie stark Daten, Zuständigkeiten und Systeme miteinander verbunden sind.
Aus dieser Erfahrung hat sich meine Vorgehensweise verändert. Ich frage nicht mehr zuerst, welcher einzelne Schritt schneller erledigt werden kann, sondern wo Informationen warten, doppelt erfasst werden, erneut geprüft werden müssen oder ohne klaren Empfänger weitergegeben werden. Genau diese Sichtweise möchte ich in diesem Beitrag zeigen: nicht nur über Prozessoptimierung sprechen, sondern an einem realen Projektbezug erklären, wie ein Ablauf so sichtbar gemacht werden kann, dass Wartezeiten, Doppelarbeit, Informationsverluste und unklare Verantwortlichkeiten überhaupt besprechbar werden.
Warum Prozesse im Alltag unsichtbar werden
Ein realer Unternehmensprozess liegt selten vollständig vor einer einzelnen Person. Jeder Beteiligte sieht vor allem seinen eigenen Arbeitsschritt, sein System, seine E-Mail, seine Datei oder seine Entscheidung. Dadurch kann jeder lokale Schritt nachvollziehbar wirken, während der Gesamtprozess trotzdem unnötige Schleifen, Rückfragen oder Wartezeiten enthält.
Prozesssichtbarkeit bedeutet deshalb nicht, möglichst viele Kästchen zu zeichnen. Entscheidend ist, den tatsächlichen Ablauf mit seinen Übergaben abzubilden: Welche Information startet einen Schritt? Wer bearbeitet sie? In welchem System oder Dokument liegt sie? Was muss vollständig an den nächsten Beteiligten übergeben werden? Und wer entscheidet, wenn Angaben fehlen oder widersprüchlich sind?
Einfach erklärt: Was bedeutet „Prozess sichtbar machen“?
Prozesse sichtbar zu machen heißt, einen realen Ablauf so darzustellen, dass Anfang, Ende, Arbeitsschritte, Übergaben, Informationen und Verantwortlichkeiten erkennbar werden. Wichtig ist dabei nicht der ideale Soll-Zustand, sondern zunächst das, was tatsächlich passiert.
Einfach erklärt: Stellen Sie sich eine technische Zeichnung vor, auf der zwar alle Einzelteile eingezeichnet sind, aber die Verbindungen fehlen. Jedes Teil kann für sich korrekt sein – trotzdem bleibt unklar, wie das Gesamtsystem funktioniert. Bei Unternehmensprozessen sind die Übergaben diese Verbindungen.
Aus der Praxis: Was der Kaventix-Aufbau sichtbar gemacht hat
Der Praxisbezug dieses Artikels stammt aus dem dokumentierten Aufbau und der technischen Weiterentwicklung von Kaventix. Das Beispiel ist kein allgemeingültiger Beweis für andere Unternehmen. Es zeigt aber nachvollziehbar, welche Fragen sich stellen, wenn mehrere Systeme, Daten und Verantwortlichkeiten zusammenwirken.
- Ausgangslage
- Der Shop musste Produktdaten, B2B/B2C-Anforderungen, Preise, Versand, Zahlung, E-Mails, Rollen und technische Funktionen als zusammenhängenden Ablauf abbilden.
- Konkrete Aufgabe
- Änderungen und Fehler sollten nicht nur an der sichtbaren Stelle betrachtet werden. Es musste erkennbar werden, welche vor- und nachgelagerten Schritte betroffen sein können.
- Vorgehen
- Die Betrachtung wurde auf Prozessketten und Schnittstellen erweitert: Produktdaten → Darstellung → Bestellung → Zahlung → Versand → Status/Kommunikation sowie technische Änderung → Test → Prüfung der Folgefunktionen.
- Entscheidung
- Nicht die einzelne Oberfläche oder ein einzelnes Plugin wurde zum alleinigen Bezugspunkt. Maßgeblich wurde die Frage, welche Information oder Funktion entlang der gesamten Kette benötigt wird.
- Ergebnis
- Änderungen konnten dadurch strukturierter eingeordnet und nachgelagerte Auswirkungen bewusster geprüft werden. Es werden bewusst keine erfundenen Zeit- oder Kosteneinsparungen behauptet.
- Erkenntnis
- Ein sichtbarer Fehler oder eine Verzögerung ist häufig nur die Stelle, an der ein Problem auffällt – nicht zwingend die Stelle, an der es entstanden ist.
- Übertragbarkeit
- Für andere Prozesse lässt sich daraus keine fertige Lösung ableiten. Übertragbar ist jedoch die Prüffrage: Welche Information, Verantwortung oder Systemübergabe liegt vor dem sichtbaren Problem?
Vier typische Verluststellen in technischen Abläufen
Für eine erste Prozessaufnahme ist ein einfaches Prüfraster oft hilfreicher als eine umfangreiche Methodik. Nicht jede Wartezeit ist automatisch schlecht und nicht jede doppelte Prüfung überflüssig. Auffällig werden Stellen dann, wenn Aufwand entsteht, ohne dass eine notwendige Freigabe, Qualitätsabsicherung oder fachliche Bearbeitung erkennbar ist.
| Verluststelle | Typisches Erscheinungsbild | Leitfrage |
|---|---|---|
| Wartezeit | Ein Vorgang liegt, weil eine Freigabe, Information, Datei oder Rückmeldung fehlt. | Worauf wartet der nächste Schritt – und warum? |
| Doppelarbeit | Dieselbe Information wird mehrfach erfasst, geprüft, übertragen oder neu formatiert. | Warum kann ein vorhandenes Ergebnis nicht direkt weiterverwendet werden? |
| Informationsverlust | Wichtige Angaben fehlen bei der Übergabe oder bleiben in E-Mails, Notizen oder Einzelwissen verborgen. | Welche Information benötigt der Empfänger – und woher erhält er sie verbindlich? |
| Unklare Verantwortung | Mehrere Personen fühlen sich teilweise zuständig oder niemand übernimmt die Entscheidung eindeutig. | Wer entscheidet, wer liefert zu und wer muss informiert werden? |
Die entscheidenden Probleme liegen häufig an den Schnittstellen
Ein einzelner Arbeitsschritt kann gut organisiert sein und trotzdem in einen schlechten Gesamtprozess eingebettet sein. Besonders aufmerksam sollte man dort werden, wo ein Vorgang den Verantwortungsbereich, das Medium oder das System wechselt: zum Beispiel von Konstruktion zu Einkauf, von Produktdaten zum Shop, vom Vertrieb zur technischen Klärung oder von einer E-Mail in ein ERP-, PDM-, DMS- oder Ticketsystem.
An diesen Übergaben ändern sich häufig Informationsformat, Kontext und Zuständigkeit. Deshalb lautet eine zentrale Leitfrage nicht nur „Was macht die nächste Person?“, sondern: „Was muss vollständig, verständlich und verbindlich ankommen, damit der nächste Schritt ohne vermeidbare Rückfrage möglich ist?“
Nicht nur den Ablauf, sondern auch Information und Verantwortung erfassen
Ein reines Flussdiagramm mit Kästchen und Pfeilen reicht für technische und administrative Prozesse häufig nicht aus. Zusätzlich sollte sichtbar werden, welche Information einen Schritt auslöst, welches Dokument oder System verwendet wird, wer fachlich entscheidet und welche Rückmeldung anschließend erwartet wird.
Gerade bei digitalen Prozessen ist außerdem wichtig, zwischen dem bloßen Vorhandensein einer Information und ihrer Nutzbarkeit zu unterscheiden. Eine Angabe kann technisch gespeichert sein und für den nächsten Beteiligten trotzdem nicht auffindbar, nicht eindeutig freigegeben oder nicht im benötigten Kontext vorhanden sein. Prozessqualität entsteht deshalb nicht allein durch Software, sondern durch klare Übergaben zwischen Menschen, Daten und Systemen.
Eine praxistaugliche Prozessaufnahme in sechs Schritten
Für den Einstieg ist keine umfangreiche Prozessmanagement-Software erforderlich. Wichtiger ist eine klare Reihenfolge, mit der der reale Ablauf gemeinsam aufgenommen wird. Die folgenden sechs Schritte sind bewusst einfach gehalten und können als Arbeitsgerüst für technische und administrative Prozesse dienen.
1. Anfang und Ende eindeutig festlegen
Zuerst wird festgelegt, welches Ereignis den betrachteten Prozess startet und wann er tatsächlich abgeschlossen ist. Ein zu großer Betrachtungsbereich wird unübersichtlich; ein zu kleiner Ausschnitt blendet wichtige Übergaben aus.
2. Den tatsächlichen Ablauf aufnehmen
Danach werden die real ausgeführten Schritte in ihrer tatsächlichen Reihenfolge erfasst. Abweichungen vom vorgesehenen Sollprozess sind dabei wichtige Informationen, weil sie zusätzliche Schleifen, Rückfragen oder inoffizielle Hilfslösungen sichtbar machen können.
3. Übergaben ausdrücklich markieren
Jeder Wechsel zwischen Personen, Abteilungen, Systemen oder Medien wird sichtbar gekennzeichnet. Eine Übergabe sollte nicht nur als Pfeil erscheinen, sondern mit der übergebenen Information und dem erwarteten Ergebnis beschrieben werden.
4. Daten, Dokumente und Systeme zuordnen
Für jeden wichtigen Schritt wird notiert, welche Daten oder Dokumente verwendet werden und welches System – soweit bestimmbar – führend ist. Dadurch werden Mehrfachpflege, Medienbrüche und unklare Datenverantwortung sichtbar.
5. Wartezeiten, Rückfragen und Nacharbeit markieren
Nun werden Stellen gekennzeichnet, an denen Vorgänge liegen bleiben, zurückgegeben oder erneut bearbeitet werden. Ziel ist zunächst nicht die Schuldfrage, sondern ein Muster: Welche Rückfrage wiederholt sich? Welche Freigabe fehlt? Welche Information muss regelmäßig ergänzt werden?
6. Ursache und Verbesserung getrennt bewerten
Erst wenn der Ist-Zustand verstanden ist, werden Verbesserungen entworfen. Sonst besteht die Gefahr, eine sichtbare Folge zu digitalisieren oder zu automatisieren, während die eigentliche Ursache bestehen bleibt. Eine tragfähige Maßnahme sollte Zuständigkeit, Datenfluss oder Entscheidung klarer machen – nicht nur einen zusätzlichen Arbeitsschritt erzeugen.
Ein Prozessbild ist kein Selbstzweck
Ein sauber gezeichnetes Prozessdiagramm kann sehr ordentlich aussehen und trotzdem wenig verändern. Entscheidend ist, ob daraus konkrete Fragen beantwortet werden können: Wo entsteht Wartezeit? Warum wird eine Information mehrfach eingegeben? Wo fehlen Entscheidungskriterien? Welche Übergabe benötigt einen verbindlichen Standard?
Deshalb sollte jede Prozessaufnahme ein klares Ziel besitzen. Das kann beispielsweise bessere Nachvollziehbarkeit, weniger Rückfragen, konsistentere Daten oder die Vorbereitung einer Digitalisierung sein. Erst wenn das Ziel klar ist, lässt sich beurteilen, welche Veränderung tatsächlich sinnvoll ist.
Was aus einem einzelnen Praxisprojekt übertragbar ist – und was nicht
Aus dem Kaventix-Projekt lässt sich keine allgemeine Aussage ableiten, dass jeder Prozess nach demselben Muster aufgebaut werden muss. Dafür unterscheiden sich Unternehmen, Rollen, Systeme und Risiken zu stark. Übertragbar ist vielmehr eine Arbeitslogik: sichtbare Probleme entlang der realen Prozesskette zurückverfolgen, Übergaben ausdrücklich betrachten und Verbesserungen anschließend über die betroffenen Folgeprozesse prüfen.
Genau diese Trennung ist wichtig: Projekterfahrung liefert konkrete Beobachtungen. Allgemeine Fachinformation erklärt, warum bestimmte Fragen auch in anderen Zusammenhängen sinnvoll sein können. Beides darf verbunden werden, sollte aber nicht miteinander verwechselt werden.
Digitalisierung und KI erst nach dem Prozessverständnis
Ein unklarer Prozess wird durch ein digitales Werkzeug nicht automatisch klar. Software oder KI kann Informationen strukturieren, Übergaben unterstützen und wiederkehrende Aufgaben beschleunigen. Wenn jedoch unklar ist, welche Information benötigt wird, wer sie verantwortet oder welche Entscheidung getroffen werden soll, wird im Zweifel nur die bestehende Unklarheit digital weitergegeben.
Deshalb ist Prozesssichtbarkeit ein sinnvoller Vorbereitungsschritt für Digitalisierung und KI. Erst wenn Anwendungsfall, Daten, Rollen und gewünschte Wirkung verstanden sind, lässt sich entscheiden, welches Werkzeug sinnvoll ist. Genau daran knüpft Artikel 012 an.
Fazit: Verbesserung beginnt mit einem gemeinsamen Bild des Ist-Zustands
Wartezeiten, Doppelarbeit und Informationsverluste sind häufig keine isolierten Einzelprobleme. Sie werden an Übergaben, unklaren Zuständigkeiten, mehrfach gepflegten Daten oder fehlendem Kontext sichtbar. Solange jeder Beteiligte nur seinen eigenen Ausschnitt betrachtet, bleiben diese Zusammenhänge schwer greifbar.
Ein sichtbar gemachter Prozess schafft eine gemeinsame Arbeitsgrundlage. Er zeigt, was tatsächlich passiert, welche Informationen weitergegeben werden, wo Entscheidungen liegen und an welchen Stellen zusätzlicher Aufwand entsteht. Erst auf dieser Grundlage sollte entschieden werden, was organisatorisch verbessert, standardisiert, digitalisiert oder automatisiert wird.
Weitere Beiträge der Reihe
Artikel 011 führt den Systemgedanken aus dem Clean-Build-Beitrag in die organisatorische Prozesswelt weiter. Der nächste geplante Beitrag betrachtet anschließend, warum bei KI und Digitalisierung zuerst der konkrete Anwendungsfall und erst danach das Werkzeug gewählt werden sollte.
Vorheriger Beitrag:
Artikel 010 – Clean Build statt Plugin-Patchkette: Warum Fehlerursachen wichtiger sind als schnelle Korrekturen
Nächster Beitrag:
Artikel 012 – KI als Werkzeug im Prozess: Warum der Anwendungsfall vor dem Tool kommt
Nächster Schritt
Wenn Abläufe in Ihrem Unternehmen durch viele Rückfragen, Medienwechsel, unklare Zuständigkeiten oder wiederholte Nacharbeit geprägt sind, kann UWM-FTBE gemeinsam mit Ihnen den Ist-Prozess strukturiert aufnehmen. Ziel ist zunächst Transparenz: Welche Schritte finden tatsächlich statt, welche Informationen werden benötigt und an welchen Schnittstellen entstehen vermeidbare Verluste? Darauf aufbauend lassen sich Verbesserungen, Digitalisierung oder Automatisierung gezielter bewerten.
Fachliche Grundlage
Dieser Beitrag basiert auf dokumentierter eigener UWM-FTBE-/Kaventix-Projekterfahrung und einer eigenständig formulierten Vorgehensweise zur Prozessaufnahme. Für die dargestellte Methodik wurden keine fremden Texte, Tabellen, Grafiken oder geschützten Prozessmodelle übernommen. Es wurden für diese Fassung keine externen Fachquellen als inhaltliche Belegquelle benötigt.
- Praxisbeleg-Status: JA – dokumentierter Kaventix-/UWM-Projektkontext.
- Eigene fachliche Grundlage: dokumentierte Projektarbeit zu Shoparchitektur, Produktdaten, Versand, Zahlung, Status-/Kommunikationsketten, technischer Fehlersuche und systematischer Projektstrukturierung.
- Veröffentlichungsgrenze: keine vertraulichen Kundendaten, Zugangsdaten, internen Sicherheitsdetails, vollständigen Konfigurationsmatrizen oder geschäftskritischen Prozessdetails.
- Externe Fachquellen: für diese Fassung nicht als inhaltliche Belegquelle benötigt.
- Rechtehinweis: keine direkten Fremdzitate, keine fremden Tabellen/Grafiken, keine Hersteller-Screenshots und keine Fremdlogos im Artikelkörper.