Umstieg in 30 Tagen mit den eigenen Daten

In einer Vorführung fällt fast immer dieselbe Frage, und es ist nie die nach dem Funktionsumfang. Sie lautet sinngemäß: Was macht das Programm mit dem Sonderfall, den es nur hier gibt? Mit der Familie, deren drei Kinder an zwei Standorten betreut werden. Mit dem Kind, dessen Beitrag das Jugendamt trägt. Mit der Großmutter, die per Dauerauftrag zahlt, obwohl das Mandat auf die Mutter lautet.

Darauf gibt es in einer Demo keine belastbare Antwort. Der Anbieter kann sie beschreiben, und beschreiben ist nicht zeigen. Genau an dieser Stelle bleiben Entscheidungen monatelang liegen — nicht, weil jemand zweifelt, dass die Software Beiträge rechnen kann, sondern weil niemand weiß, ob sie die Beiträge dieser Einrichtung rechnen kann.

Ein Probebereich dreht die Reihenfolge um. Am Anfang steht kein Termin, sondern ein Export; zurück kommt kein Angebot, sondern ein Bericht über die eigenen Daten samt der Stellen, an denen sie unvollständig sind. Das ist unbequemer als eine Vorführung und beantwortet die Frage, die vorher offen blieb.

Der Einstieg ist eine Datei. Ein Excel-Export der Schülerliste, eine CSV aus der Vereinsverwaltung, ein Auszug aus der Buchhaltung oder der Personalsoftware — was vorhanden ist, nicht was ideal wäre. Aufbereiten muss die Einrichtung dafür nichts: Lücken, Dubletten und widersprüchliche Schreibweisen sind Teil des Befunds, nicht die Vorbedingung.

Innerhalb von zwei Werktagen entsteht daraus ein abgeschlossener Bereich mit den echten Kindern, Familien, Verträgen und Beiträgen der Einrichtung. Er ist technisch von allen anderen Bereichen getrennt, liegt auf denselben Servern in Deutschland wie der spätere Echtbetrieb, und die Übergabe des Exports ist durch einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO gedeckt — geschlossen vor dem Export, nicht danach.

Mitgeliefert wird kein Angebot, sondern ein Plausibilitätsbericht. Er zählt, was angekommen ist, und benennt, was fehlt oder sich widerspricht. Ein solcher Bericht liest sich etwa so:

• 84 aktive Kinder an zwei Standorten, davon 12 mit Geschwistern im jeweils anderen Bereich desselben Trägers.
• Drei Haushalte ohne hinterlegten Zahler — in aller Regel getrennt lebende Eltern, bei denen offen ist, wer das Schulgeld schuldet.
• Sieben Kinder ohne Geburtsdatum, alle aus derselben Liste, in der das Feld nie gepflegt wurde.
• Zwei SEPA-Mandate ohne Mandatsreferenz und eines ohne Datum der Erteilung.
• Neun mutmaßliche Dubletten, gefunden über Anschrift und Geburtsdatum statt über die Schreibweise des Namens.
• Die Summe der monatlichen Sollstellungen, gegengerechnet mit der Summe aus der alten Lösung — auf den Cent.

Viele freie Träger organisieren sich mit einer Vereinsverwaltung, weil der Verein zuerst da war und die Schule danach kam. Solche Programme kennen genau einen Datensatztyp: das Mitglied. Ein Kind ist ein Mitglied, der Beitrag hängt am Mitglied, die Bankverbindung ebenfalls. Eine Elternstruktur gibt es nicht, weil ein Verein sie nie gebraucht hat.

Das trägt, solange niemand nach der Familie fragt. Es hört auf zu tragen, sobald zwei Geschwister zwei Mitglieder sind: Der Geschwisterrabatt lässt sich nicht als Regel rechnen, weil die Software nicht weiß, dass die beiden zusammengehören. Eine Adressänderung trifft zwei Datensätze. Und eine Rechnung an die Familie gibt es nicht, weil es die Familie im Datenmodell nicht gibt.

Beim Umstieg entsteht diese Struktur nachträglich — und sie entsteht nicht aus dem Namen. Zusammengeführt wird über die Merkmale, die tatsächlich stabil sind: Anschrift, IBAN des Zahlers, Mandatsreferenz und Geburtsdatum. Der Vorschlag kommt aus dem Import, die Entscheidung bleibt in der Verwaltung: Jede vorgeschlagene Zusammenführung wird einzeln bestätigt oder verworfen.

Im beschriebenen Fall wurden aus 84 Mitgliedern 84 Kinder mit Haushalten, Sorgeberechtigten und Zahlern. Ein Teil der Vorschläge war falsch — gleiche Anschrift, aber zwei Familien im selben Haus. Sie wurden in der Prüfung verworfen; genau dafür ist die Prüfung da.

Der eigentliche Gewinn zeigt sich erst danach: Sobald Haushalte existieren, rechnet die Geschwisterstaffel von selbst, Jahresbescheinigungen gehen an den Zahler, und Elternpost erreicht Sorgeberechtigte statt Kinder.

Der Plan hat vier Wochen und einen Stichtag. Er setzt keine Ferien voraus, sondern einen Monatsersten — weil Beiträge monatlich fällig werden und ein Wechsel mitten im Abrechnungsmonat den einzigen Zustand erzeugt, der wirklich teuer wird: einen halb umgestellten Beitragslauf.

• Tag 1 bis 2: Export übergeben, Probebereich steht, Plausibilitätsbericht liegt vor.
• Woche 1: Feldzuordnung bestätigen, Dublettenvorschläge entscheiden, fehlende Angaben ergänzen. Jetzt wird der Stichtag festgelegt, ab dem in den alten Dateien nichts mehr geändert wird.
• Woche 2: Beitragsregeln nachbauen — Staffelstufen, Geschwisterregel, Ermäßigungen, Zu- und Abschläge. Danach ein Testlauf der Sollstellungen gegen den letzten echten Lauf der alten Lösung.
• Woche 3: Generalprobe. Der komplette Monatslauf wird im Probebereich gerechnet, die SEPA-Datei erzeugt und geprüft, aber nicht bei der Bank eingereicht. Parallel läuft eine Woche doppelte Pflege.
• Woche 4: Abnahme anhand fester Zahlen, Freigabe, Umstellung zum Monatsersten. Der erste echte Lastschriftlauf wird begleitet.
• Danach: zwei Wochen mit einer festen Ansprechperson. Nicht für Schulungen, sondern für die Fragen, die erst im Tun auftauchen.

Die Sorge um die Mandate ist die konkreteste vor einem Wechsel — und die am einfachsten auszuräumende. Ein erteiltes Mandat gehört dem Gläubiger, nicht der Software. Bleibt der Träger derselbe und damit auch die Gläubiger-Identifikationsnummer, bleiben die Mandate gültig. Niemand muss neu unterschreiben.

Entscheidend ist allein, dass drei Angaben unverändert mitwandern: die Mandatsreferenz, das Datum der Erteilung und die Gläubiger-ID. Fehlt eine Mandatsreferenz im Export, muss sie aus der alten Lösung nachgeschlagen werden. Neu vergeben werden darf sie nicht — die Bank ordnet Lastschriften daran zu, und eine geänderte Referenz erzeugt Rückläufer.

Zwei Dinge sind trotzdem zu regeln. Erstens die Vorabankündigung: Sie muss die Fälligkeitstermine des neuen Laufs nennen; welche Frist dafür gilt, steht in der Lastschriftvereinbarung mit der Bank und ist bei vielen Trägern längst auf wenige Tage verkürzt. Zweitens die Rechtsform: Wechselt der Träger sie im selben Zug, etwa von einem Verein in eine gemeinnützige GmbH, gehört vor den Umstieg die Klärung mit der Hausbank, ob Gläubiger-ID und Mandate übergehen. Das ist eine Frage an die Bank, nicht an die Software.

Ein Umstieg ist nicht fertig, wenn er sich fertig anfühlt, sondern wenn vier Zahlen stimmen. Sie werden vor dem Start festgelegt und am Stichtag gegen die alte Lösung gehalten:

• Die Zahl der aktiven Kinder, getrennt nach Standort und Bereich.
• Die Summe der monatlichen Sollstellungen, auf den Cent.
• Die Zahl der aktiven SEPA-Mandate, jeweils mit Referenz.
• Die Summe der offenen Posten zum Stichtag.

Erfahrungsgemäß stimmen drei der vier Abnahmezahlen sofort. Die vierte weicht ab, und fast immer steckt dahinter kein Importfehler, sondern eine mündlich vereinbarte Ermäßigung, die in keiner Liste stand. Der Umstieg hat sie nicht verloren — er hat sie sichtbar gemacht. Das ist unangenehm und trotzdem der halbe Nutzen des Projekts.

Teuer wird eine Migration selten durch die Datenmenge. Teuer wird sie durch fehlende Entscheidungen: ein Stichtag, der nicht durchgesetzt wird; niemand, der verbindlich sagt, welcher Datenstand gilt; Vereinbarungen, die nur in Köpfen existieren. Ein Festpreis lässt sich deshalb erst nach dem Plausibilitätsbericht benennen, dafür dann verbindlich — er deckt Import, Regeln und Abnahme ab, nicht das nachträgliche Klären von Fällen, die vorher nie geklärt waren.

Am Ende steht ein Satz, der nüchtern klingt und den Aufwand rechtfertigt: Umstellung zum 1. Oktober, 84 Kinder, kein Datenverlust, erster Lastschriftlauf im neuen System planmäßig.