MOVIT: Wie aus einer Terminbuchung ein ERP wurde

Ein reales Problem wurde zum Lernprojekt

Ein ERP war nie der Plan. Ich wollte Termine für ein Kosmetikstudio buchbar machen, mehr nicht. Dann kam die nächste Anforderung, dann die übernächste, und irgendwann war aus einer einzelnen Funktion ein System für mehrere Geschäftsbereiche geworden.

Nebenbei lernte ich. Was ich in der Ausbildung hörte, probierte ich direkt an MOVIT aus und sah, ob es im Alltag hielt. Einige Teile schrieb ich zwei- oder dreimal neu, jedes Mal mit dem Wissen, das ich gerade hatte. Das brachte mich weiter, kostete aber auch: Manches war schwer wartbar, manches gab es längst als fertige Lösung, und manches brauchte am Ende niemand. Unklare Anforderungen und zu wenig Recherche haben einen Preis, und ich habe ihn bezahlt.

Mit den ersten echten Nutzern änderte sich der Massstab. Eine technisch spannende Erweiterung zählte nur, wenn sie jemandem eine konkrete Aufgabe abnahm. In der Diplomarbeit habe ich offen festgehalten, dass ich zu viel Zeit in Details steckte, die den Kunden wenig brachten. Heute würde ich einen kleinen, vollständigen Ablauf viel früher mit den Nutzern testen und von dort aus weiterbauen.

Was MOVIT im Geschäftsalltag verbindet

Am einfachsten erklärt sich die Idee am Weg eines Termins: Eine Kundin bucht eine Dienstleistung, das Team plant die Durchführung, die Kundendaten liegen bereit, und die erbrachte Leistung landet in Kasse und Auswertung. Jedes Werkzeug greift auf dieselben Informationen zu, weil sie im Betrieb zusammengehören.

Die vier Produktbereiche von MOVIT zeigen diesen Zusammenhang:

• Online-Buchung und Agenda: Termine vereinbaren, Mitarbeitende einplanen, Erinnerungen verschicken.
• Kundenmanagement: Kundeninformationen und Notizen für die Betreuung.
• Kassensystem: Leistungen und Produkte abrechnen, Quittungen erstellen, Abschlüsse auswerten.
• Finanzen und Reporting: Einnahmen, Ausgaben und Berichte im Blick.

Dazu kommen Schichtplanung, Verknüpfungen zu Dienstleistungen und individuelle Erinnerungen in der Agenda sowie Rabatte, Gutscheine und QR-/Barcodes an der Kasse. (MOVIT, Agenda, Kassensystem)

Genau in diesen Übergängen steckt für mich die eigentliche Architekturfrage: Wie teilen sich Module gemeinsame Informationen, ohne dass unklar wird, wer wofür zuständig ist?

Module und Navigation: Die Struktur muss den Nutzern helfen

Ich gliederte die Funktionen in Frontoffice, Backoffice, Finanzen und Administration. Einzelne Module erschienen als «Apps» und wurden über Benutzerrollen im Identitäts- und Zugriffsmanagement zugewiesen. Jede Person sollte genau die Werkzeuge sehen, die zu ihren Aufgaben passten.

Die Abbildung aus der Diplomarbeit zeigt diese modulare Oberfläche, und sie zeigt auch, wie breit das ursprüngliche Reservationstool inzwischen geworden war. Die Navigation war dabei ein eigenes Problem: Nutzer fragten mich, was «Frontoffice» und «Backoffice» überhaupt bedeuten. Meine interne Ordnung war für sie nicht selbsterklärend.

Also wurde die Bereichsstruktur zum Vorschlag. Wer wollte, konnte auf eine einfachere Navigation mit direkt sichtbaren Funktionen wechseln oder die Struktur selbst anpassen. Die Lektion nehme ich bis heute mit: Fachliche Module sind gut, um Software zu organisieren. Die Oberfläche muss sich trotzdem an den echten Arbeitsaufgaben orientieren, nicht an meinem Schichtmodell.

Originalabbildung aus meiner Diplomarbeit von 2023, S. 18: Beispiel der Module.

Grafik in voller Grösse ansehen

Der technische Aufbau im Stand von 2023

Ich wählte Technologien, die ich bereits beherrschte und die sich zwischen Web, Backend und Mobile wiederverwenden liessen. Angular im Frontend. Im Backend ersetzte NestJS nach und nach meine eigenen Framework-Strukturen auf Node.js; TypeORM verband das Datenmodell mit MariaDB. Mobile Apps liefen mit Ionic. Nx hielt Anwendungen und gemeinsame Bibliotheken im Monorepo zusammen.

Bereich	Ansatz	Gedanke dahinter
Weboberfläche	Angular	Einheitliche Struktur und vorhandenes Wissen
Backend	Node.js und NestJS	Modulare Organisation ähnlich zum Frontend
Datenzugriff	TypeORM und MariaDB	Modelle und Datenzugriff im Anwendungscode
Mobile	Ionic	Wiederverwendung des Angular-Wissens
Codeorganisation	Nx und NPM-Packages	Anwendungen und gemeinsame Bausteine verwalten
Betrieb	Linux, Nginx, Docker und Ansible	Dienste bereitstellen und Server einrichten

Die Struktur unterschied Apps, Services, Packages und Shells. Apps bildeten fachliche Funktionen wie Agenda oder Kasse ab. Services übernahmen Aufgaben wie SMS, E-Mail oder Dokumentgenerierung. Packages bündelten wiederverwendbaren Code. Eine Shell stellte den Rahmen einer Anwendung bereit und lud die passenden Apps. So sollte sich ein Modul in mehreren Anwendungskontexten verwenden lassen.

Originaldiagramm aus meiner Diplomarbeit von 2023, S. 24: Gliederung von Oberfläche, API, Services und gemeinsamen Paketen.

Grafik in voller Grösse ansehen

Bereitstellung und Erweiterbarkeit brachten neue Fragen

Alles lief auf einem VServer. Ansible richtete die Linux-Umgebung ein, Docker kapselte die Anwendungen, und Nginx leitete Anfragen über Domains und Pfade an die jeweiligen Dienste weiter. Ein Aufruf unter /api landete beim API-Server. Die Abbildung zeigt den Aufbau mit mehreren Anwendungskontexten.

Für Erweiterungen schaute ich mir Module Federation an: getrennte Frontend-Anwendungen, die sich in einer gemeinsamen Oberfläche zusammensetzen. Ich wollte Module unabhängig weiterentwickeln und später neue Funktionen einhängen. Dafür handelte ich mir neue Fragen ein: gemeinsame Dienste, kompatible Versionen, Service Worker, Updates.

Auch der Betrieb hatte Grenzen. Watchtower zog auf dem Staging-Server neue Docker-Images; Produktionsupdates löste ich von Hand aus. Spätere Änderungen an der Serverkonfiguration landeten nicht mehr vollständig in der Ansible-Einrichtung. Die Automatisierung reichte also nicht für einen reproduzierbaren Gesamtaufbau.

Ein Galera-Cluster, das ich anfangs aufgesetzt hatte, flog wieder raus, weil es niemand brauchte. Ein gutes Beispiel dafür, dass zusätzliche Infrastruktur ihren Aufwand rechtfertigen muss. Heute kommt bei mir eine neue Komponente erst dazu, wenn Zweck, Betrieb und Wiederherstellung geklärt sind.

Infrastrukturabbildung aus meiner Diplomarbeit von 2023, S. 19.

Grafik in voller Grösse ansehen

Was ich heute bei Modulgrenzen anders bewerten würde

In der Arbeit habe ich Repository-Struktur, Modularität und die Verteilung auf getrennte Prozesse an einigen Stellen vermischt. Heute trenne ich diese Fragen sauber: Wo liegt der Code? Wer verantwortet Regeln und Daten? Was wird gemeinsam ausgeliefert? Welche Änderungen müssen zusammen erfolgreich sein?

Ein Monorepo ist zunächst nur die gemeinsame Ablage mehrerer Projekte. Ein gemeinsames Deployment folgt daraus nicht. Aus einem Repository lassen sich problemlos eigenständige Anwendungen bauen und veröffentlichen. (Nx: What is a Monorepo?)

Microservices bringen unabhängige Releases und gezielte Skalierung, aber der Preis sind Kommunikation, Datenkonsistenz, Tests und Betrieb. Eine Trennung lohnt sich nur mit einer eigenständigen fachlichen Verantwortung und einem konkreten Nutzen. (Microsoft: Microservices architecture style)

Für ein kleines Team würde ich heute zuerst einen modularen Monolithen bauen: klar abgegrenzte Zuständigkeiten in einer gemeinsam ausgelieferten Anwendung. Reservation, Kundenverwaltung, Abrechnung und Benachrichtigungen wären die naheliegenden Grenzen. Ein Modul darf nicht einfach die Daten eines anderen verändern.

Der Stand von 2023 zeigt, warum das zählt: Die Module waren gegliedert, die Datenbank blieb aber gemeinsam. Die geplante Aufteilung hätte verlangt, bestehende Relationen und den Umgang mit Änderungen oder gelöschten Daten zu klären. Mehr Prozesse hätten diese fachlichen Abhängigkeiten nicht aufgelöst, nur verschoben.

Ein Termin zeigt, was Zuverlässigkeit bedeutet

Ein Architekturentwurf wird greifbar, wenn man ihn an einem vollständigen Ablauf durchspielt. Mein Beispiel: Eine Kundin reserviert einen Termin. Die Leistung wird später erbracht und erst danach zur Abrechnung freigegeben. Eine Reservation allein erzeugt noch keine Rechnung.

Wenn eine Ressource nur einmal gleichzeitig belegt werden darf, dürfen zwei parallele Buchungen diese Regel nicht aushebeln. Ein freier Termin in der Oberfläche ist noch keine verbindliche Zusage. Die Prüfung gehört dorthin, wo die Reservation verbindlich gespeichert wird.

Ein Termin kann bestätigt sein, obwohl die Bestätigungsmail noch aussteht. Dafür würde ich eine Transactional Outbox einsetzen: Reservation und Versandauftrag werden in derselben Datenbanktransaktion gespeichert, ein Worker versendet später. Wiederholungen sind möglich, also müssen Empfänger doppelte Aufträge erkennen. (AWS: Transactional outbox pattern)

Bei der Abrechnung würde ich einen stabilen Auftragsschlüssel zusammen mit der Rechnung speichern. Eine Eindeutigkeitsregel verhindert, dass ein erneut verarbeiteter Auftrag eine zweite Rechnung erzeugt. Die Oberfläche zeigt klar, was bereits gilt und was noch aussteht.

Für externe Nachrichten gibt es kein «exactly once»: Nimmt der Mailserver eine E-Mail an und der Worker stürzt danach ab, erzeugt der nächste Versuch ein Duplikat. Solche Fehlerfälle gehören von Anfang an in den Entwurf.

Prozessgrafik, neu gezeichnet für diesen Rückblick: so würde ich den Ablauf heute entwerfen.

Grafik in voller Grösse ansehen

Rechte, Tests und Betrieb gehören zum selben Prozess

Eine Aussage aus meiner Arbeit würde ich heute streichen: Die Lesbarkeit von JavaScript sagt nichts über die Sicherheit eines ERP. Entscheidend sind Zugriffsrechte, Eingabeprüfung, Abhängigkeiten und der Schutz der Laufzeitumgebung.

Die eigentliche Frage lautet: Darf diese Person diese Aktion auf diesem Datensatz ausführen? Ein ausgeblendeter Menüeintrag ersetzt keine Prüfung auf dem Server. Nutzen mehrere Unternehmen dieselbe Anwendung, muss zusätzlich die Zugehörigkeit jedes Datensatzes geprüft werden, auch bei Suche, Export und Anhängen. (OWASP: Authorization Cheat Sheet)

In der Diplomarbeit steht schwarz auf weiss: Tests gab es keine. Bei einem Neuaufbau wären das meine ersten:

• Zwei gleichzeitige Reservationen bestätigen nicht dieselbe exklusive Kapazität.
• Ein wiederholter Abrechnungsauftrag erzeugt keine zweite Rechnung.
• Nutzer erhalten keine Daten ausserhalb ihrer Berechtigung.
• Nach einem unterbrochenen Versand bleibt der offene Auftrag nachvollziehbar.

Dazu gehört der Betrieb: versionierte Konfiguration, geprüfte Datenbankmigrationen und eine Wiederherstellung, die in einer getrennten Umgebung wirklich ausprobiert wurde. Monitoring sollte erfolgreiche Buchungen, Fehler und lange offene Aufträge sichtbar machen. Ein erreichbarer Server beweist noch keinen funktionierenden Geschäftsprozess.

Was mir aus MOVIT geblieben ist

MOVIT hat mir beigebracht, wie eng Produktentwicklung, Benutzerführung, Datenmodell und Betrieb zusammenhängen. Und es hat mir etwas gegeben, das kein Kurs bietet: eigene Entscheidungen über mehrere Jahre im Betrieb zu erleben und mit wachsendem Wissen neu zu bewerten.

2018 stand ich am Anfang meiner Laufbahn, mit wenig Erfahrung. Dass ich mir damals ein eigenes Framework gebaut habe, war eine intensive Lernerfahrung, hat aber viel Zeit gefressen, die bei Standardaufgaben besser angelegt gewesen wäre. Später kam NestJS. Heute würde ich früh auf etablierte Frameworks und vorhandene Bausteine setzen und die Zeit in Fachfunktionen, Qualität und Benutzerführung stecken.

Am wertvollsten war der komplette Lebenszyklus: Anforderungen sammeln, Lösungen entwerfen, Funktionen bauen, die Anwendung bereitstellen und betreiben, Rückmeldungen aus dem Alltag in die nächste Version übersetzen. Das alles an einem echten Produkt mit echten Kunden.

MOVIT wird heute weiterhin genutzt, aber nicht mehr weiterentwickelt. Die Überlegungen in diesem Beitrag beschreiben, wie ich einen Neuaufbau mit meinem heutigen Wissen angehen würde.

Quellen

Diplomarbeit: Best Practices in der Entwicklung von Software-Architekturen für ERP-Systeme – Eine Fallstudie mit Vergleich, HF IPSO, 6. September 2023. Projektgeschichte und Module: S. 16 bis 18; Infrastruktur und Gliederung: S. 19 bis 27; Technologieentscheidungen: S. 29 bis 30; Evaluation: S. 31 bis 34. Die drei historischen Abbildungen stammen aus dieser Arbeit.

Die Produktseiten auf mymovit.com und die verlinkten technischen Quellen habe ich am 8. Oktober 2026 für diese Überarbeitung geprüft. Cover und Prozessgrafik sind neu für den Rückblick entstanden.