Ein Objekt kann jeder. Das Problem beginnt bei zwölf.
Für ein einzelnes Objekt gibt es die Exposé-Vorlage, damit ist die Sache erledigt. Beim Neubauprojekt mit drei Bauabschnitten sieht es anders aus: Der monatliche Bericht an den Bauträger ist kein Formular, sondern eine Frage — und die ändert sich jeden Monat. Warum genau dort die Fehler entstehen, die niemandem auffallen.
Für ein einzelnes Objekt ist die Sache erledigt: Vorlage wählen, Merge-Felder ziehen, Exposé fertig. Der Aufwand beginnt bei der Mehrzahl. Ein Neubauprojekt mit drei Bauabschnitten und 120 Einheiten lässt sich nicht mit einer Vorlage berichten, und der Grund dafür ist grundsätzlicher, als es zunächst aussieht.
Was der Bauträger monatlich erwartet
Einmal im Monat will der Bauträger wissen, wo sein Projekt steht. Wie viele Einheiten sind verkauft, wie viele reserviert, wie viele frei. Getrennt nach Bauabschnitt, weil der erste bezogen ist, der zweite im Bau und der dritte noch in Planung. Diese Zahlen ändern sich täglich, der Bericht friert sie zu einem Stichtag ein.
Das allein wäre noch ein Formular. Interessant wird der zweite Teil: Der Bauträger fragt, welche Wohnungsgrößen besonders nachgefragt werden. Und zwar nicht nach der Menge der Anfragen, die sagt für sich genommen wenig. Wie viele Anfragen es bis zum Kaufvertrag braucht, liegt im Neubau je nach Lage, Preis und Kanal grob zwischen zwanzig und fünfzig. Eine allgemeingültige Zahl gibt es nicht, und wer eine nennt, hat meist ein bestimmtes Projekt vor Augen.
Das ist kein Mangel, sondern ein Hinweis darauf, wo der Maßstab liegt: nicht in der Branche, sondern im eigenen Projekt. Interessant ist nicht, ob ein Grundriss vierzig Anfragen braucht, sondern ob er mehr braucht als die anderen Grundrisse im selben Haus, unter denselben Marktbedingungen und mit demselben Vertrieb. 34 gegen 62 im selben Projekt ist eine Aussage, auch ohne Branchenmittelwert. Und ein Typ ohne einen einzigen Abschluss bei fast hundert Anfragen ist eine Ansage. Nicht aus Neugier, sondern weil der dritte Bauabschnitt noch nicht steht. Was sich in Abschnitt eins und zwei schnell verkauft hat und was liegen blieb, entscheidet darüber, was er als Nächstes baut. Aus einem Bericht wird eine Bauentscheidung.
| Abschnitt | Einheiten | Verkauft | Reserviert | Frei | Stand |
|---|---|---|---|---|---|
| Bauabschnitt 1 | 38 | 34 | 2 | 2 | bezogen |
| Bauabschnitt 2 | 42 | 19 | 5 | 18 | im Bau |
| Bauabschnitt 3 | 40 | 0 | 0 | 40 | in Planung |
| Wohnungstyp | Anfragen | Verkauft | Anfragen je Verkauf | Nachfrage |
|---|---|---|---|---|
| 2 Zimmer, 48–58 m² | 790 | 22 | 36 | hoch |
| 3 Zimmer, 72–86 m² | 880 | 26 | 34 | hoch |
| 4 Zimmer, 96–112 m² | 310 | 5 | 62 | niedrig |
| Penthouse, ab 130 m² | 95 | 0 | — | niedrig |
Der Bericht ist kein Formular, sondern eine Frage
Hier liegt der Punkt, an dem Vorlagen enden, und zwar aus einem strukturellen Grund. Eine Vorlage ist für Wiederholung gebaut. Sie lohnt sich, wenn dieselbe Frage jeden Monat gleich gestellt wird. Die Frage des Bauträgers ist aber jeden Monat eine andere.
Im Januar will er die Nachfrage nach Größen. Im März, nachdem der Vertrieb im zweiten Abschnitt angezogen hat, will er wissen, ob die Käufer aus der Region kommen oder von außerhalb. Im Juni, vor dem Gespräch mit der Bank, will er den durchschnittlichen Quadratmeterpreis je Abschnitt, getrennt nach verkauft und frei. Jede dieser Fragen ließe sich als Vorlage anlegen. Bis zur nächsten.
Also endet der Weg in der Tabellenkalkulation. Daten exportieren, sortieren, summieren, ins Dokument kopieren, Projektlogo einsetzen, PDF erzeugen. Einmal im Monat, für jedes Projekt.
Wo dabei die Fehler entstehen
Nicht beim Abtippen einer Adresse. Ein falscher Straßenname fällt auf. Die Fehler, die durchgehen, sind Summenfehler: eine reservierte Einheit, die in „verkauft" mitgezählt wird. Ein Durchschnittspreis, der die Penthouse-Einheiten enthält, obwohl er sie nicht enthalten sollte. Eine Zeile, die beim Sortieren aus dem markierten Bereich gerutscht ist.
Solche Zahlen sehen richtig aus. Sie stehen in der richtigen Spalte, haben eine plausible Größenordnung und niemand rechnet sie nach, weil sie aus einem Bericht stammen. Sie fallen erst auf, wenn jemand zwei Monate später dieselbe Zahl anders ausrechnet. Bis dahin hat der Bauträger womöglich eine Entscheidung darauf gestützt.
Dazu kommt die Alterung. Eine Zahl, die am Monatsersten aus dem CRM in eine Tabelle kopiert wurde, ist ab diesem Moment eine zweite Wahrheit. Sie ändert sich nicht mehr mit, auch wenn am Dritten zwei Einheiten verkauft werden. Wer den Bericht am Zehnten verschickt, verschickt den Stand vom Ersten, ohne dass das irgendwo steht.
Der Aufwand liegt nicht im Rechnen
Belastbare Zahlen dazu, wie viel Zeit ein Projektbericht kostet, gibt es nicht. Was kursiert, stammt von Softwareanbietern und nennt keine Erhebungsgrundlage. Eine Beobachtung aus einem Fachbeitrag zum Neubau-Monatsreporting trifft die Sache aber genauer als jede Stundenzahl: Der eigentliche Aufwand liegt nicht in der Berechnung, sondern in der Datendisziplin. Statusänderungen mit Datum, einheitliche Begriffe, kanalübergreifende Erfassung und eine verbindliche Definition, was „reserviert" im Team bedeutet.
Das deckt sich mit dem, was wir bei Onboardings sehen. Die Stunde am Monatsanfang ist nicht das Problem. Das Problem ist, dass die Zahlen erst zusammengesucht werden müssen, weil der Status einer Einheit an drei Stellen gepflegt wird und niemand sagen kann, ob die Reservierung vom Dienstag schon drin ist. Wer das sauber hat, erzeugt den Bericht fast nebenbei. Wer es nicht hat, rechnet jeden Monat neu.
Die Struktur muss aus dem Datensatz kommen
Damit eine solche Auswertung überhaupt möglich ist, muss das Projekt im System als Struktur abgebildet sein und nicht als 120 lose Objekte. In propgen leisten das Areale für zusammengehörende Gebäude und die Projekthierarchien für Bauabschnitte und Einheiten. Eine Einheit weiß, zu welchem Abschnitt sie gehört, ein Abschnitt weiß, zu welchem Projekt.
Erst das macht die zweite Tabelle oben möglich. Wer die Nachfrage nach Wohnungsgrößen auswerten will, braucht die Verbindung zwischen Einheit, Größe, Anfragen und Status an einer Stelle. Liegt das in drei Tabellenkalkulationen, ist die Auswertung eine Fleißarbeit. Liegt es im Datensatz, ist sie eine Abfrage.
Für den Bericht selbst gilt dann eine einfache Arbeitsteilung. Was sich jeden Monat gleich wiederholt, gehört in eine Vorlage, samt Projektlogo und fester Gliederung. Was sich von Monat zu Monat ändert, also die eigentliche Frage des Bauträgers, formuliert man als Frage. Der KI-Assistent zieht die Zahlen aus den verknüpften Datensätzen und gibt das Ergebnis als Datei aus, die man weiterreichen kann.
Wer den Bericht schickt, haftet für die Summen
Damit ist nichts gewonnen, wenn man die Zahlen ungeprüft weitergibt. In Folge 74 des ImmoKaiser-Podcasts hat Silab genau davor gewarnt, und der Satz gilt für einen Projektbericht mehr als für ein Exposé.
„Alles, was wir gerade versprochen haben, ist cool — und sollte trotzdem noch einmal überprüft werden, bevor man es blind rausschickt."
Der Unterschied liegt nicht darin, ob geprüft wird, sondern ob sich prüfen lässt. Eine Summe aus einer gewachsenen Tabellenkalkulation lässt sich kaum nachvollziehen, weil niemand mehr weiß, welche Zeilen beim letzten Mal markiert waren. Eine Summe, die aus verknüpften Datensätzen entsteht, lässt sich zurückverfolgen: Man öffnet den Bauabschnitt und zählt nach.
Das ist der eigentliche Gewinn, nicht die gesparte Stunde am Monatsanfang. Die Stunde ist der sichtbare Teil. Der wichtigere Teil ist, dass unter der Zahl im Bericht ein Datensatz liegt und keine Kopie vom Ersten des Monats. Denn auf dem Bericht steht der Name des Maklers, und die Entscheidung über den dritten Bauabschnitt trifft der Bauträger.