Drei unterirdische Speicherbecken in einer Stadt. Die beiden kleinen sind fertig. Das große, das den größten Teil des Wassers aufnimmt, das der Stadt zugesagt wurde, steht bei 74 %. Mittelt man die drei, meldet die Stadt 91,33 % Fertigstellung. Gewichtet man jedes Becken nach der Kapazität, die es bereitstellt, lautet die ehrliche Zahl 75,70 %.
Diese Lücke von fast sechzehn Punkten ist das ganze Argument für ein Projektmonitoring-System. Eine Tabellenkalkulation mittelt Prozentwerte klaglos, die zuständige Stelle liest das Ergebnis in gutem Glauben, und niemand merkt etwas, bis jemand neben dem großen Becken steht.
Dieser Leitfaden richtet sich an alle, die solche Systeme spezifizieren, beschaffen oder erben: Projektdirektoren in einer PMU oder PIU (Projektdurchführungseinheit) und die Berater, die deren Leistungsbeschreibung (Terms of Reference) verfassen. Wir schreiben aus der Sicht des Betreibers. Seit Juli 2026 hat NexGenix das PDP Executive Monitoring Dashboard für das Punjab Development Program migriert und überarbeitet und betreibt es; das System verfolgt Kanalisations-, Entwässerungs- und Pumpwerksarbeiten in 52 Städten. Das Beckenbeispiel stammt aus der Methodendokumentation dieses Systems.
Warum Berichte per Tabelle und WhatsApp im Programmmaßstab scheitern
Die meisten Programme beginnen gleich. Jede Baustelle schickt eine Zahl, Fotos landen in einer WhatsApp-Gruppe, und jemand in der Zentrale überträgt vor der Wochenbesprechung alles in eine Arbeitsmappe. Bei fünf Baustellen funktioniert das. Bei fünfzig Städten scheitert es, und zwar immer an denselben Stellen:
- Niemand kann ein Foto belegen. Ein weitergeleitetes Bild sagt nichts Verlässliches darüber, wo oder wann es aufgenommen wurde. Derselbe halbfertige Kanal kann drei Wochen hintereinander auftauchen.
- Prozentwerte werden eingetippt, nicht gemessen. „Kanal 60 %“ ist eine Meinung. Sechzig Prozent welcher Länge, gemessen von wem, an welchem Tag?
- Die Verdichtung mittelt Ungleiches. Siehe die Becken.
- Die Historie verschwindet. Eine Arbeitsmappe zeigt die Zahl dieser Woche, selten aber, dass die der Vorwoche höher war oder wer sie geändert hat.
- Der Bericht kommt systembedingt zu spät. Zwei Tage Konsolidierung bedeuten ein Briefing über das Programm, wie es vor zwei Tagen stand.
Plattformen auf Provinzebene machen das nicht überflüssig. Punjab betreibt bereits Smart Monitoring of Development Projects, über das Behörden seit 2016 monatliche Fortschrittsberichte einreichen, sowie ein GIS-gestütztes Monitoring Observatory for Development Projects. Diese Systeme blicken über Hunderte von Vorhaben. Das System eines einzelnen Programms arbeitet eine Ebene tiefer: je Bauwerk, je Tag, mit beigefügtem Nachweis.
Was ein Projektmonitoring-System leisten muss
Leistungsbeschreibungen verlangen erstaunlich ähnliche Dinge, wer auch immer die Arbeiten finanziert: ein web- und mobilbasiertes Monitoring- und Informationssystem, ein MIS mit GIS, eine Android-App, die eine zentrale Plattform speist, Dashboards, Handbücher und Schulungen. Die KfW Entwicklungsbank hat sogar einen Leitfaden zu Remote Management, Monitoring und Verifizierung (RMMV) veröffentlicht. Die Bezeichnungen sind weniger wichtig als das Verhalten. Auf diesen zehn Fähigkeiten würden wir bestehen.
1. Feldnachweise, die Manipulation erkennbar machen
Ein Foto sollte in dem Moment zum Nachweis werden, in dem es den Server erreicht. In der PDP-Feld-App brennt der Server ein Banner in die Pixel jedes Fotos ein: Programm, Stadt, Außendienstkraft, Koordinaten, pakistanische Uhrzeit und ein kurzer Prüfcode, der durch Hashing von Außendienstkraft, Zeit und Position entsteht. Der Server stempelt mit seiner eigenen Uhr, sodass ein Telefon, das auf letzten Dienstag eingestellt ist, das Datum nicht fälschen kann.
Eine Einschränkung: Telefone bekommen unter einer Betondecke oder in einer engen Gasse nicht immer ein GPS-Signal. Erfassen Sie dann „keine Koordinaten“, statt welche zu erfinden.
2. Eine Offline-Feld-App, die nie doppelt meldet
Baustellen verlieren das Netz. Eine App, die eine Live-Verbindung braucht, gewöhnt Außendienstkräfte daran, Einträge abends aus dem Gedächtnis nachzutragen. Die App PDP Field Progress speichert Meldungen und Fotos auf dem Telefon zwischen und synchronisiert später, und jeder Eintrag trägt eine eigene Referenz, sodass ein erneuter Versuch denselben Fortschritt nie doppelt meldet.
Messen Sie, wo immer möglich, statt zu fragen. Der Kanalisationsfortschritt in der PDP-App ergibt sich aus der Linie, die die Außendienstkraft mit dem GPS des Telefons über der Entwurfstrasse zeichnet. Niemand tippt einen Prozentwert ein.
3. Gewichteter Fortschritt statt gemittelter Prozentwerte
Zurück zu den Becken, Schritt für Schritt:
- Jedes Bauwerk erhält einen Stand in seiner eigenen Einheit: ausgeführt im Verhältnis zum vertraglich Zugesagten. Becken A fasst 1.000.000 Gallonen und steht bei 74 %. Die Becken B (40.000 Gallonen) und C (30.000 Gallonen) sind fertig.
- Der einfache Durchschnitt beträgt (74 + 100 + 100) ÷ 3 = 91,33 %.
- Nach Kapazität gewichtet: 1.000.000 × 74 + 40.000 × 100 + 30.000 × 100 = 81.000.000.
- Geteilt durch die Gesamtkapazität von 1.070.000 Gallonen ergibt das 75,70 %.
Die kleinen Becken sind fertig, aber der Großteil des neuen Speichervolumens der Stadt steckt in dem einen, das es nicht ist. Im Code sind das wenige Zeilen:
// Drei unterirdische Speicherbecken in einer Stadt (Kapazität in Gallonen, Fortschritt in %)
const tanks = [
{ capacity: 1_000_000, progress: 74 },
{ capacity: 40_000, progress: 100 },
{ capacity: 30_000, progress: 100 },
];
const naive = tanks.reduce((sum, t) => sum + t.progress, 0) / tanks.length;
const weighted =
tanks.reduce((sum, t) => sum + t.capacity * t.progress, 0) /
tanks.reduce((sum, t) => sum + t.capacity, 0);
console.log(naive.toFixed(2), weighted.toFixed(2)); // "91.33" "75.70"
Die vollständige Verdichtung im PDP hat vier Stufen. Bauwerke werden innerhalb einer Stadt zu einer Komponente zusammengefasst, gewichtet nach dem, was jedes liefert: Gallonen bei Becken, Pumpensumpfvolumen bei Pumpwerken, laufende Fuß bei Regenwasser- und Abwasserkanälen. Komponenten werden mit von der PMU festgelegten Gewichten, die zusammen 100 ergeben müssen, zur Stadt verdichtet, und die Städte nach genehmigten Kosten zum Programm. Die Stände werden bei jeder Abfrage berechnet, nicht gespeichert, sodass Dashboard, PDF und Datenfeed nie voneinander abweichen.
Eine weitere Regel lohnt sich: eine autorisierte Untergrenze. Sobald eine leitende Person einen Stand verifiziert hat, kann keine spätere Meldung darunter liegen, und nur der Secretary (Verwaltungschef der Behörde) oder ein Systemadministrator kann ihn neu festsetzen, wobei die Änderung protokolliert wird. Eine echte Korrektur braucht jetzt eine Unterschrift. Diese Reibung gehört genau dorthin.
Wenn ein Anbieter Ihnen die Formel hinter der Hauptkennzahl nicht zeigen kann, ist die Hauptkennzahl nur Dekoration.
4. S-Kurven-Verfolgung: Soll gegen Ist
Eine S-Kurve trägt den kumulierten Fortschritt über die Zeit auf: langsamer Start, steile Mitte, auslaufendes Ende. Legen Sie Soll- und Ist-Kurve auf dieselben Achsen, und der senkrechte Abstand ist Ihre Terminabweichung, sichtbar Monate bevor ein Fertigstellungstermin ins Rutschen gerät.
Beispielhafte S-Kurve, keine Programmdaten. Der Abstand zwischen Soll-Baseline und Ist-Linie am heutigen Datum ist die Terminabweichung.
Die Ist-Linie braucht aufgezeichnete Historie. Das PDP sichert jede Nacht jeden Stand als Snapshot, und die S-Kurve sowie jede Zahl für „diese Woche“ lesen aus diesen Snapshots.
Die Soll-Linie ist die schwierigere Hälfte. Ein Programm mit Hunderten von Baulosen hat selten für jedes einen ressourcenbelasteten Terminplan, daher ist die Soll-Baseline im PDP eine modellierte Kurve bis zum Zieltermin. Das ist legitim, solange das Diagramm es auch so ausweist. Eine Soll-Linie, die jedes Quartal so neu gezeichnet wird, dass sie knapp über der Ist-Linie liegt, ist schlimmer als gar keine S-Kurve.
5. Eine GIS-Karte, gegliedert wie die Verwaltung
Verantwortliche in Behörden denken in Verwaltungseinheiten. Die Karte im PDP filtert von der Division über Distrikt und Tehsil bis zum Municipal Committee und markiert jedes Becken, jeden Kanal und jedes Pumpwerk mit seinem aktuellen Stand.
Karten werden schnell schwer. Eine der ersten Arbeiten am PDP-Dashboard reduzierte die Datenmenge beim ersten Laden der Karte von 37 MB auf 9 MB. Über 4G entscheidet das darüber, ob jemand in der Behörde sie überhaupt öffnet. Fragen Sie Anbieter, wie viel ihre Karte wiegt.
6. Eine Live-Aktivitätsanzeige für das PMU-Büro
PDP Live ist eine Großbildanzeige, die Meldungen aus dem Feld zeigt, sobald sie eingehen. Eine Stadt, die bis zum späten Vormittag nicht gemeldet hat, fällt also an der Wand auf und nicht erst in der Monatsbesprechung.
Die Anzeige fragt den Server etwa alle zehn Sekunden ab, statt eine Push-Verbindung offen zu halten. Push rechtfertigt seine Komplexität bei einer Flottenkarte mit einem ständigen Strom von Fahrzeugpositionen, wie unsere Notizen zur Architektur für GPS-Echtzeit-Tracking erklären. Für Meldungen, die nur vereinzelt eintreffen, ist Polling einfacher, und niemand vor dem Bildschirm bemerkt einen Unterschied.
7. Berichte per Klick im Format, das die Verantwortlichen bereits nutzen
Das Morgenbriefing hat bereits eine Form und eine Seitenreihenfolge. Ein System, das sie ignoriert, erlebt, dass seine Zahlen in die alte Vorlage abgetippt werden. Das PDP erzeugt sein tägliches Briefing zum Feldfortschritt als PDF per Klick, aufgebaut wie die eigenen Folien der Verantwortlichen, dazu PDF- und Excel-Berichte nach Stadt, Bauwerkstyp und Einhaltung des Arbeitsschutzes.
8. Rollenbasierter Zugriff, der Daten eingrenzt, nicht Menüs
Das PDP hat sechs Rollen, von Außendienstkräften, die nur ihre zugewiesenen Städte sehen, bis zur Führungsebene, die das gesamte Programm sieht. Der Server filtert die Daten. Einen Menüpunkt auszublenden ist keine Zugriffskontrolle.
9. Ein Prüfpfad, den Sie einer Revision übergeben können
Im Dashboard sind Fortschrittseinträge nur anfügbar (append-only), und ein Konto mit Historie wird deaktiviert, nie gelöscht. PMIS, das Vertrags- und Zahlungssystem desselben Programms, führt einen vierschichtigen Prüfpfad: Entscheidungen, jede Anfrage, Vorher- und Nachher-Stand jeder Zeilenänderung und eine nächtliche SHA-256-Hash-Kette, die die Protokolle versiegelt, sodass eine spätere Bearbeitung die Kette bricht.
10. Verzahnung mit Verträgen und Zahlungen
Monitoring fragt, wie viel gebaut wurde. Vertrags- und Zahlungsmanagement fragt, wie viel geschuldet ist, nach welchen Abzügen und von wem freigegeben. Im PDP sind das getrennte Systeme. PMIS führt das Leistungsverzeichnis (LV, engl. Bill of Quantities, BOQ) jedes Vertrags vier Ebenen tief, berechnet neun Abzugsarten auf dem Server und leitet jede Abschlagsrechnung (Interim Payment Certificate, IPC) über einen 11-stufigen Freigabeweg plus einen Schritt nach der Freigabe. Seit dem 13. Oktober 2026 ist es live an das Finanzmanagementsystem der Provinz angebunden und sendet freigegebene Rechnungen seit dem 21. Oktober automatisch. Ziehen Sie diese Grenze vom ersten Tag an in der Leistungsbeschreibung.
Architektur und Datenmodell: das Wesentliche
Dashboards sind der sichtbare Teil. Das Datenmodell darunter entscheidet, ob man ihnen glauben sollte. Diese Datensätze würden wir erwarten, jeweils mit der Regel, die sie vertrauenswürdig macht:
| Datensatz | Was er enthält | Die entscheidende Regel |
|---|---|---|
| Bauwerk | Jedes Becken, jeder Kanal, jedes Pumpwerk oder jeder Leitungsabschnitt, mit vertraglichem Leistungsumfang und Einheit | Änderungen am Leistungsumfang mit Vorschau und erneuter Prüfung auf dem Server |
| Fortschrittseintrag | An einem Datum ausgeführte Menge, von einer Außendienstkraft | Nur anfügbar; Korrekturen sind neue Einträge |
| Nachweis | Mit dem Eintrag verknüpfte Fotos | Vom Server gestempelt, nie vom Telefon |
| Gewichte | Komponentengewichte, genehmigte Kosten je Stadt | Summe muss 100 ergeben; Änderungen protokolliert |
| Verifizierter Stand | Der letzte von einer leitenden Person bestätigte Stand | Keine Meldung darf darunter liegen |
| Tages-Snapshot | Jeder Stand am Ende jedes Tages | Speist die S-Kurve und die Veränderungswerte |
| Audit-Log | Wer was wann in welcher Rolle getan hat | Name und Rolle in der Zeile gespeichert |
Halten Sie den Stack bewusst unspektakulär. Das PDP-Dashboard läuft auf Node.js 20, Express und MySQL 8.0: rund 128.000 Zeilen Code, etwa 210 API-Endpunkte und rund 52 Tabellen. Jemand wird es noch Jahre betreuen, nachdem das ursprüngliche Team weitergezogen ist, und gängige Technologie vergrößert den Kreis der Menschen, die das können. MySQL kommt in dieser Größenordnung gut zurecht, wenn die Indizierung durchdacht ist, wie wir in Lehren aus der Optimierung einer produktiven MySQL-Datenbank mit 287 Tabellen festgestellt haben. Und wenn die Feld-App außerhalb eines App-Stores verteilt wird, sollte der Server eine Mindestversion prüfen.
Ein laufendes Behördensystem übernehmen, ohne das Berichtswesen anzuhalten
Die meisten Monitoring-Systeme von Behörden werden geerbt, nicht neu gebaut. In dieser Lage war das PDP im Juli 2026. Die ursprüngliche Plattform stammte von Technology Hive; NexGenix hat sie übernommen, auf den eigenen Server der Regierung von Punjab migriert und überarbeitet und betreibt sie seitdem. Die Umstellung am 24. Juli 2026 kostete einen Tag mit reduzierten Meldungen. In dieser Reihenfolge würden wir wieder vorgehen:
- Prüfen, bevor man etwas anfasst. Code, Schema und das, was tatsächlich live ist, lesen und schriftlich festhalten.
- Eine vollständige Kopie umziehen. Anwendung, Datenbank-Dump und jedes Baustellenfoto, meist die größte Datenmenge: im Fall des PDP 13.595 Dateien bei der Übergabe.
- Immer nur ein schreibendes System zulassen. Den genauen Moment festlegen, in dem der alte Server keine Felddaten mehr annimmt und der neue beginnt.
- Die Feld-App funktionsfähig halten. Vor der Umstellung ein Update ausliefern, das die neue Adresse kennt, und danach alte Versionen zum Update zwingen.
- Durch Zählen verifizieren. Datensätze, Fotos und Summen je Stadt, vorher und nachher.
- Dann in kleinen Releases verbessern, jedes mit vorherigem Backup und einem Weg zurück. Das ist die Disziplin hinter unserem vierphasigen Prozess für individuelle Softwareentwicklung.
Checkliste für die Beschaffung: Was Sie einen Anbieter von Monitoring-Systemen fragen sollten
Gehen Sie diese Punkte in der Demo durch, mit Ihren eigenen Daten und den echten Nutzern im Raum.
- „Zeigen Sie mir die Formel hinter der Hauptkennzahl.“ Erwarten Sie Gewichte, Einheiten und ein Rechenbeispiel für eine Ihrer Städte.
- „Schalten Sie in den Flugmodus, melden Sie Fortschritt und verbinden Sie sich dann wieder.“ Die Meldung sollte zwischengespeichert, einmal synchronisiert und vom Server gestempelt ankommen.
- „Was hindert jemanden daran, das Foto vom letzten Monat als heutiges einzureichen?“ Ein Stempel auf dem Server, nicht die Metadaten des Telefons.
- „Melden Sie sich als Außendienstkraft an.“ Nur zugewiesene Baustellen, durchgesetzt vom Server.
- „Senken Sie den Fortschritt eines Bauwerks.“ Unterhalb des verifizierten Stands abgelehnt oder mit Person und Begründung protokolliert.
- „Woher kommt die Soll-Linie der S-Kurve?“ Aus einem genehmigten Terminplan oder einem gekennzeichneten Modell.
- „Erstellen Sie das Briefing der letzten Woche in unserem Format.“ Wenn dafür ein Entwickler nötig ist, passiert es an keinem Montag.
- „Kann es auf unserem eigenen Server laufen?“ Fragen Sie, was es vom Netzwerk braucht.
- „Was bekommen wir bei der Übergabe?“ Quellcode, Schemadokumentation, ein Benutzerhandbuch, Bereitstellungsschritte und Schulung, vertraglich festgeschrieben.
- „Wie spielen Sie Änderungen in ein laufendes System ein?“ Backups, ein Rollback-Weg und ein Änderungsprotokoll.
Warnsignale bei einem Projektmonitoring-System
- Fortschritt als eingetippter Prozentwert ohne Menge dahinter.
- Fotos aus der Galerie des Telefons akzeptiert, ohne Stempel durch den Server.
- Eine Hauptkennzahl, die niemand beim Anbieter von Hand herleiten kann.
- Ein Löschknopf für bereits gemeldeten Fortschritt.
- Eine Demo, die nur mit Beispieldaten läuft.
- Keine klare Antwort darauf, wem Quellcode und Daten gehören.
Der Punkt, an dem wir aufstehen und gehen würden, ist der Löschknopf. Sobald sich Historie überschreiben lässt, wird jede Zahl im System verhandelbar.
PDP Punjab: Monitoring für 52 Städte
Das Punjab Development Program (PDP) baut Kanalisation, Regenwasserentwässerung und Abwasserpumpwerke in 52 Städten in 25 Distrikten Punjabs mit rund 7 Millionen Einwohnern. Mit Stand November 2026 umfasst es 394 Baulose mit genehmigten Programmkosten von rund 308 Milliarden PKR. Seine Program Management Unit (PMU), eingerichtet vom Local Government & Community Development (LG&CD) Department der Regierung von Punjab, arbeitet mit zwei Systemen:
- Das PDP Executive Monitoring Dashboard (Web plus Android-Feld-App) deckt physischen Fortschritt, Nachweise, Karten und Berichte ab. Mit Stand November 2026 enthält es rund 33.000 Baustellenfotos (die meisten davon georeferenziert) und hat sechs Rollen und elf Module auf 27 Webseiten; die Feld-App liegt in Version 2.9.0 vor.
- PMIS, das Project/Contract & Payment Management System, verwaltet Leistungsverzeichnisse, Abschlagsrechnungen, Abzüge und die Anbindung an das Finanzmanagementsystem. Es umfasst mehr als 70 Tabellen und mehr als 45 Live-Releases, und seine Freigabewege lassen sich seit dem 24. Oktober 2026 auf dem Bildschirm konfigurieren.
Die ursprüngliche Plattform beider Systeme stammte von Technology Hive. Beide wurden auf den eigenen Server der Regierung von Punjab migriert und werden seit Juli 2026 von NexGenix überarbeitet und betrieben.
Die Lehre, die wir weitergeben würden, betrifft die Akzeptanz. Ein System, das die Dokumente erzeugt, die die Verantwortlichen bereits verwenden, etwa das Morgenbriefing in ihrem eigenen Folienlayout, braucht wenig Schulung, um angenommen zu werden. Bauen Sie diese Dokumente früh. Die Dashboards können folgen.
Die Fallstudie zum PDP Executive Monitoring Dashboard zeigt die Bildschirme und die Zeitleiste. Die begleitende Fallstudie zu PMIS, dem Vertrags- und Abschlagsrechnungssystem behandelt den Freigabeweg und die Finanzanbindung. Sie planen etwas Ähnliches? Auf unserer Seite zur Softwareentwicklung für Behörden erklären wir, wie wir mit PMUs arbeiten.
Häufig gestellte Fragen
Was ist ein Projektmonitoring-System für Entwicklungsprojekte?
Eine Software, die den physischen Fortschritt von Entwicklungsvorhaben aus dem Feld mit Fotonachweisen erfasst und in Dashboards, Karten und Berichten verdichtet. Ein gutes System gewichtet den Fortschritt nach dem, was jedes Bauwerk liefert, und bewahrt die Historie jeder Zahl.
Was ist der Unterschied zwischen Monitoring und Evaluierung in einem M&E-System?
Monitoring verfolgt den Fortschritt laufend, solange die Arbeiten im Gang sind: gebaute Mengen, ausgegebene Mittel, Terminabweichung. Evaluierung blickt zu festgelegten Zeitpunkten zurück und beurteilt anhand der im Monitoring gesammelten Daten, ob das Programm seine angestrebten Ergebnisse erreicht hat.
Wie belegen georeferenzierte Fotos den Fortschritt bei öffentlichen Bauprojekten?
Jedes Foto aus der Feld-App ist mit einem Bauwerk und einem Fortschrittseintrag verknüpft, und der Server stempelt es mit Außendienstkraft, Koordinaten und Uhrzeit. So können Prüfende bestätigen, dass es von der richtigen Baustelle am richtigen Tag stammt.
Was ist eine S-Kurve im Projektmonitoring?
Ein Diagramm des kumulierten Fortschritts über die Zeit, mit der Soll-Baseline und der tatsächlich erbrachten Leistung. Der Abstand zwischen beiden Linien zeigt, wie weit das Projekt dem Zeitplan voraus ist oder hinterherhinkt.
Kann ein Projektmonitoring-System auf dem eigenen Server einer Behörde laufen?
Ja, und für die meisten Behörden sollte es das auch. Die PDP-Systeme laufen auf dem eigenen Server der Regierung von Punjab. Planen Sie mit eingeschränktem Internetzugang und mit Backups, die die Behörde selbst kontrolliert.
Worin unterscheidet sich ein Monitoring-System von einem Vertrags- und Zahlungsmanagementsystem?
Ein Monitoring-System misst, wie viel gebaut wurde. Ein Vertrags- und Zahlungsmanagementsystem, oft PMIS genannt, verwaltet Leistungsverzeichnis, Abschlagsrechnungen, Abzüge und Freigaben, bevor Geld fließt. Große Programme brauchen beides.
Mit dem Nachweis beginnen, nicht mit dem Dashboard
Jedes Projektmonitoring-System wird am Ende an einer einzigen Frage gemessen: Wenn jemand aus der Behörde in einer Sitzung eine Zahl nennt, kann irgendjemand sie belegen? Legen Sie zuerst die Nachweiskette, die Gewichtungsmethode und den Prüfpfad fest. Die Diagramme sind der einfache Teil.
Sie planen ein Monitoring-System für Ihr Programm?
Sagen Sie uns, wie viele Baustellen Sie haben, wer von dort meldet und was Ihre Verantwortlichen jeden Morgen auf dem Tisch brauchen. Wir sagen Ihnen klar, was Sie bauen, was Sie kaufen und was Sie in die Leistungsbeschreibung schreiben sollten.
Geprüft vom NexGenix-Engineering-Team. Lesen Sie unsere redaktionellen Richtlinien, um zu erfahren, wie wir Quellen verifizieren, KI-Assistenz offenlegen und Fehler korrigieren.
Diskussion
Melden Sie sich an, um an der Diskussion teilzunehmen