Warum wir LockVera wie eine Stadt gedacht haben

Ich hatte irgendwann eine Liste vor mir. Rollen, Rechte, Mandanten, Freigaben, Versionen, Audit. Alles wichtig. Alles irgendwie hängend. Ich wusste nicht, wie das zusammengehört. Nicht wirklich.

Das war kein Implementierungsproblem. Das war ein Denkproblem. Ich musste etwas bauen, das ich selbst noch nicht sauber greifen konnte.

Ich komme nicht aus der klassischen Softwareentwicklung. Das bedeutet: Ich konnte Strukturen nicht einfach übernehmen, weil sie „so gemacht werden“. Ich musste verstehen, warum sie sinnvoll sind, und zwar bevor ich anfange, irgendetwas zu bauen. Sonst baue ich am Ende etwas, das funktioniert, aber nicht stimmt.

Das Bild, das plötzlich geholfen hat

An irgendeinem Punkt hatte ich Rollenlogik im Kopf, Dokumente an einer anderen Stelle und Freigaben wieder woanders. Alles gleichzeitig, nichts zusammen. Ich habe versucht, das in Tabellen zu ordnen, in Listen, in Flussdiagrammen. Hat nicht funktioniert, nicht weil die Werkzeuge falsch waren, sondern weil ich noch kein Modell hatte, in das ich die Teile einsetzen konnte.

Irgendwann, während ich versuchte, Verantwortlichkeiten aufzuschreiben (wer darf was sehen, wer darf was ändern, wer muss bestätigen, was passiert, wenn jemand geht), fiel mir auf, dass ich eigentlich über etwas nachdachte, das ich schon kannte: eine Stadt.

Nicht als Analogie für Nutzer. Nicht als Kommunikationshilfe. Sondern als Denkwerkzeug für mich, um überhaupt erst mal zu verstehen, was ich da gerade aufzubauen versuchte.

Eine Stadt hat Grenzen

Eine Stadt hat eine Mauer. Sie ist keine Entscheidung gegen die Außenwelt. Sie ist eine Entscheidung für Klarheit darüber, wo Verantwortung beginnt und wo sie endet. Hier gelten Regeln. Hier weiß man, wer zuständig ist. Und genau das fehlt in vielen Systemen, nicht weil es niemanden interessiert, sondern weil es nie explizit gemacht wurde. Die Mauer macht es explizit.

Und eine Stadt hat ein Tor. Nicht jeder kommt einfach rein. Wer reinkommt, kommt aus einem Grund: sichtbar, dokumentiert, regelgebunden. Nicht aus Misstrauen, sondern weil eine Stadt, die nicht weiß, wer in ihr ist, keine Stadt ist.

Das Rathaus ist der Ort, an dem verbindliche Entscheidungen getroffen werden. Nicht überall gleichzeitig, nicht unsichtbar in irgendeinem Hinterzimmer, sondern dort, wo es hingehört, mit dem nötigen Gewicht und nachvollziehbar. Was das Rathaus vom einfachen Büro unterscheidet, ist nicht die Größe. Es ist, dass Entscheidungen, die dort getroffen werden, Bestand haben. Sie gelten. Und man kann später noch nachvollziehen, wer sie getroffen hat und warum.

Und dann gibt es die einzelnen Einrichtungen. Das Archiv, das Standesamt, die Bibliothek, die Feuerwehr. Jede davon hat eine eigene Aufgabe, eigene Abläufe, eigene Zuständigkeiten. Aber keine davon existiert unabhängig von der Stadt. Sie teilen dieselbe Grundstruktur, dieselben Grundregeln. Und am Ende läuft alles Verbindliche durch dasselbe Rathaus. Das Standesamt entscheidet nicht, was gilt. Es vollzieht, was durch die richtige Instanz entschieden wurde. Diese Logik klingt selbstverständlich, aber in komplexen Systemen ist sie es meistens nicht.

Was dieses Bild verändert hat

Erst mit dem Modell habe ich gemerkt, dass ich manche Fragen vorher komplett vergessen hatte.

Zum Beispiel: Was passiert mit einem externen Prüfer, der temporär Zugang braucht? Er kommt durch das Tor, aber er wohnt nicht in der Stadt. Er hat eine definierte Rolle, einen begrenzten Zeitraum, einen konkreten Zweck. Das klingt selbstverständlich, aber es ist genau die Art von Klarheit, die in Compliance-Prozessen fehlt, wenn man sie nicht explizit durchdenkt.

Oder: Wenn das Rathaus der Ort ist, an dem Freigaben passieren, was bedeutet das für die Nachvollziehbarkeit? Das Archiv führt Buch. Nicht über alles, was in der Stadt passiert, aber über das, was Bestand haben muss. Das ist kein Kontrollsystem. Das ist eine Voraussetzung dafür, dass man sich später noch erinnert, was warum entschieden wurde.

Und die Gegenprobe: Wenn dieses Modell fehlt, passiert nicht nichts. Es passiert, dass Entscheidungen irgendwo getroffen werden, nur nicht mehr nachvollziehbar wo, von wem und auf welcher Grundlage. Das ist kein theoretisches Problem. Das ist der Normalzustand in vielen Unternehmen, die irgendwann merken, dass sie ihrem eigenen System nicht mehr trauen können.

Das Modell hat mir auch geholfen, Grenzen zu ziehen, wo ich sonst vielleicht zu früh zu viel gebaut hätte. Wenn das Standesamt eigene Zuständigkeiten hat, dann sollte es nicht in die Zuständigkeiten der Bibliothek hineinregieren. Diese Idee ist nicht kompliziert, aber sie ist viel leichter durchzuhalten, wenn man ein Bild hat, das sie trägt.

Was das mit LockVera zu tun hat

LockVera ist kein Dokumentenspeicher. Es ist ein System für strukturierte Dokumentenarbeit, mit allem, was dazugehört: Verantwortlichkeiten, Freigaben, Historien, Mandantentrennung, Nachvollziehbarkeit.

Und genau dafür brauchte ich ein Modell, das diese Dinge nicht als Features denkt, sondern als Grundstruktur. Nicht „wir haben eine Freigabefunktion“, sondern: Freigaben passieren an einem bestimmten Ort, durch bestimmte Personen, nach bestimmten Regeln, und das wird festgehalten. Der Unterschied klingt klein. Er ist es nicht. Ein Feature kann man ein- und ausschalten. Eine Grundstruktur nicht. Die ist entweder da oder sie fehlt, und wenn sie fehlt, merkt man es meistens erst dann, wenn es zu spät ist.

Ob das Stadtmodell nach außen hin je eine größere Rolle spielt, weiß ich noch nicht. Vielleicht bleibt es ein internes Werkzeug. Vielleicht wird es irgendwann Teil davon, wie wir LockVera erklären. Beides wäre in Ordnung.

Aber ohne dieses Bild hätte ich nicht gewusst, wo ich anfangen soll. Ich musste die Stadt sehen, bevor ich anfangen konnte, sie zu bauen.

LockVera Insights ist der Fachblog von LockVera: für Fragen rund um strukturierte Dokumentenarbeit, Compliance-Prozesse und organisatorische Nachvollziehbarkeit in B2B-Umgebungen.