ESN Event Hub: sechs Tools, ein Event und warum wir langweilig gebaut haben
Für das Erasmus Student Network Potsdam haben wir den Eventprozess aufgenommen, modelliert und als Team eine kleine Web-App ausgeliefert. Erst verstehen, dann bauen.
Trello, WhatsApp, Pretix, Instagram, Drive und Mail. Über diese sechs Tools organisiert das Erasmus Student Network in Potsdam rund 80 Events pro Semester. Ehrenamtlich, ohne Budget, und das Team wechselt ständig.
Das war unser Praxispartner im Kurs Grundlagen von Unternehmensanwendungen. Wir waren fünf. Die Aufgabe: den Prozess verstehen, Schwachstellen finden, ein Konzept entwickeln und einen Prototyp bauen, den eine Freiwilligenorganisation ohne Geld auch wirklich betreiben kann.
Angefangen haben wir nicht mit Code, sondern mit Gesprächen. Fünf Interviews mit Leuten in ganz unterschiedlichen Rollen, vom Vorstand bis zu jemandem, der als Erasmus-Student nur zu den Events kommt, dazu Beobachtung im Alltag. Eins der Interviews habe ich selbst geführt, auf Englisch. Daraus wurde ein BPMN-Modell des Ist-Prozesses mit eigenen Spuren für jede Rolle, 27 Aufgaben und 12 Entscheidungspunkten. Dann eine Liste mit 15 Schwachstellen und 10 Stärken.
Die wichtigste Schwachstelle war nicht technisch. Jede Rolle sieht nur ihren Ausschnitt des Prozesses, verteilt auf die sechs Tools. Ein Event als Ganzes sieht niemand. Und wenn jemand geht, geht sein Wissen mit.
Unser Konzept hieß deshalb: ein Event, eine gemeinsame Prozesssicht. Das Event ist die eine Quelle der Wahrheit, und jede Rolle bekommt ihre eigene Sicht darauf. Trello fliegt raus, WhatsApp, Pretix und Instagram bleiben, weil sie funktionieren. Vorher haben wir in einer Marktanalyse geprüft, was es dafür schon fertig zu kaufen gibt.
Den Prototyp hat das Team ausgeliefert. Die Demo auf dieser Seite spielt ihn mit Beispieldaten nach. Ein Board, auf dem ein Event von Idee über Planung und Veröffentlichung bis Live und Fertig wandert. Eine öffentliche Anmeldeseite ohne Login: Ist die Kapazität voll, landet man auf der Warteliste. Und ein Ereignisprotokoll mit dem „Process Pulse”. Der zeigt Durchlaufzeiten und Engpässe und prüft, ob ein echtes Event so gelaufen ist, wie der Soll-Prozess es vorsieht. Kleines Process Mining.
Process Pulse BPM · Monitoring
Every metric is computed live from the Activity event log, the trace data the app records itself.
Mined from the event log: the path events actually took, against the TO-BE happy path. Dashed arcs are deviations.
Process Pulse rechnet aus dem Event-Log, wie Events wirklich laufen, und prüft sie gegen den Soll-Prozess (TO-BE-BPMN).
Gespeichert wird alles in einer Google-Tabelle. Das klingt nach Notlösung und ist Absicht. Die Tabelle gehört ESN selbst, der Betrieb kostet null Euro, und gehostet wird auf Vercel. KI-Agenten, automatische Mails, Gamification, das alles haben wir bewusst weggelassen, weil der Kunde keine laufenden Kosten tragen kann. „We chose boring on purpose” stand am Ende auf einer Folie.
Zum Code: Die Commits im Repo sind alle von Robert. Die Grundlagen der App habe ich mitgeliefert, entworfen haben wir das System zusammen. Mein sichtbarster Teil waren die Präsentationen. In der Zwischenpräsentation habe ich den Schluss gehalten: was gut läuft, die Kern-Schwachstelle, die Richtung der Lösung und was wir gelernt hatten, unter anderem, dass BPMN bei uns keine Deko war. In der Endpräsentation die ersten sechs Folien, von sechs Systemen zu einem Event-Datensatz.
Was ich mitnehme: Erst verstehen, dann bauen. Die Kern-Schwachstelle kam aus den Interviews, nicht aus einer Feature-Liste. Prozess und Daten gehören zusammen. Und manchmal ist die richtige Architektur eine Tabelle.
Tools und Skills: Stakeholder-Interviews, BPMN mit bpmn.io, Priorisierung von Schwachstellen, Build-vs-Buy-Analyse, Next.js, die Google-Sheets-API, Vercel und Präsentieren vor einem echten Partner.
Nachtrag: Die Modulnote ist eine 1,3.