Die Branchensoftware war abgekündigt. Die Daten wollte sie nicht hergeben.
Wie aus drei getrennten Welten ein Fluss wurde, wie der Import gegen nachgebaute Daten entstand statt gegen echte, und was passiert, wenn ein Programm versehentlich zweimal auf demselben Rechner liegt.
- Branche
- Übersetzungsdienstleistung
- Form
- Anwendung auf dem eigenen Rechner
- Stand
- im Echtbetrieb mit übernommenen Altdaten
- Prüfung
- 126 automatische Tests
Ausgangslage
Ein Übersetzungsbüro arbeitet mit Aufträgen, die aus vielen kleinen Teilen bestehen: Sprachpaare, Textmengen, Zeilen- oder Wortpreise, Fremdleistungen von Übersetzerinnen und Übersetzern, dazu Termine, die nicht verschoben werden können. Geführt wurde das in einer Branchensoftware, die der Hersteller abgekündigt hatte. Sie lief noch, aber sie bekam keine Korrekturen mehr, und ihre Daten gab sie nur als Ausfuhrdateien heraus.
Angebote, Aufträge und Rechnungen lagen dabei in getrennten Welten. Ein angenommenes Angebot wurde von Hand zu einem Auftrag, der Auftrag von Hand zu einer Rechnung. Jede dieser Übertragungen ist eine Stelle, an der eine Zahl abweichen kann, und genau das passierte auch.
Nicht „dasselbe nochmal bauen“, sondern: eine Angabe wird einmal erfasst und wandert weiter. Das Angebot wird zum Auftrag, der Auftrag zur Rechnung, ohne dass jemand etwas abtippt.
Drei Entscheidungen, die das Projekt geprägt haben
-
Die Anwendung läuft auf dem eigenen Rechner, nicht im Netz
Naheliegend wäre eine Webanwendung gewesen. Dagegen sprach der Alltag: Die Daten enthalten Kundenadressen und Honorare, das Büro ist klein, und eine laufende Monatsrechnung für einen Server war nicht gewollt. Die Anwendung läuft deshalb lokal und wird als eine einzige Installationsdatei ausgeliefert, in der die Laufzeitumgebung schon steckt. Ein Doppelklick installiert, derselbe Doppelklick aktualisiert. Es muss nichts vorher installiert werden, und nichts verlässt das Haus.
-
Der Import entstand gegen nachgebaute Daten, nie gegen echte
Echte Kunden- und Honorarlisten haben in einer Entwicklungsumgebung nichts verloren. Der Import wurde deshalb gegen nachgebaute Dateien entwickelt, die die Macken des Altsystems genau nachstellen. Das kostete zuerst Zeit und hat sich sofort bezahlt, weil man die Macken dabei benennen muss: falsche Zeichenkodierung, verlorene führende Null in Postleitzahlen, Fehlerwerte in Zellen statt Werten, Zuordnungen, die als Fließtext in einer Spalte standen, abgeschnittene Blattnamen, Fortsetzungszeilen ohne eigene Nummer, Zellen mit einem einzelnen Leerzeichen.
Den Import mit den echten Dateien fährt das Büro selbst. Das ist keine Notlösung, sondern der Punkt: Wer die Daten kennt, entscheidet über Zuordnungen, nicht wer das Programm geschrieben hat.
-
Erst Trockenlauf, dann Übernahme, und beides durch denselben Code
Ein Trockenlauf, der weniger prüft als der echte Lauf, ist wertlos. Beide Wege laufen deshalb durch dieselbe Verarbeitung, unterschieden nur durch einen Schalter, der am Ende schreibt oder nicht schreibt. Vor jeder Übernahme wird gesichert, und die Übernahme lässt sich wiederholen: erkannt wird an der Nummer aus dem Altsystem, ein zweiter Lauf legt deshalb nichts doppelt an.
Was dabei schiefgegangen ist
Zwei Vorfälle, beide aus dem laufenden Betrieb, beide mit einer Lehre, die inzwischen in allen lokal ausgelieferten Anwendungen steckt.
Nach einem Update meldete das Büro: „Version ist hoch, aber alles ist leer.“ Die Ursache war keine verlorene Datenbank. Das Programm lag an zwei Stellen, einmal im Anwendungsverzeichnis und einmal auf dem Schreibtisch. Gestartet wurde die eine Stelle, aktualisiert die andere. Zu sehen war das erst an der Befehlszeile des laufenden Prozesses.
Es ist kein Datensatz verloren gegangen, weil vor jedem Update gesichert wird und die Sicherung von vorher vollständig war. Geändert hat sich die Einrichtung: Sie sucht heute alle Stellen, an denen das Programm liegt, aktualisiert jede, gleicht den Datenbestand ab und ersetzt nie einen größeren Bestand durch einen kleineren.
Die Rechnungsausgabe brach ab, sobald die Bankverbindung in der Fußzeile stand. Der Grund lag in einer Eigenheit der Ausgabebibliothek: Nach einer Textzeile über die volle Breite steht die Schreibmarke am rechten Rand, für die zweite Zeile bleibt also keine Breite übrig. Die zweite Zeile war die Bankverbindung, und die entsteht nur, wenn die Bankfelder gefüllt sind. In der Voreinstellung sind sie leer. Jeder Test war deshalb grün, und beim Kunden stürzte es ab.
Zwei Dinge sind daraus geworden: Fließtext wird nur noch über eine gemeinsame Funktion ausgegeben, die die Schreibmarke vorher zurücksetzt. Und die Anwendung führt ein sichtbares Fehlerprotokoll, das der Kunde selbst öffnen kann. Genau das hat den Fehler in Minuten statt in Stunden gefunden.
Das Büro hatte eine Fassung nie in Betrieb und wegen dieses Absturzes nie eine fertige Rechnung gesehen. Auf der Rückmeldeliste stand daraufhin „fehlt“ neben Dingen, die längst gebaut waren. Was als fehlend gemeldet wird, kann vorhanden und nur nie sichtbar gewesen sein. Seitdem wird bei jeder Rückmeldung zuerst nachgesehen, ob die Funktion erreichbar ist, und erst dann gebaut.
Wie das Ergebnis aussieht
- Ein Fluss vom Angebot zur Rechnung: Das angenommene Angebot wird zum Auftrag, Beschreibung und Auftragsnummer des Kunden gehen durch alle Belege.
- Sammelrechnungen über mehrere Aufträge, mit Zwischenüberschrift je Auftrag, wiederholtem Tabellenkopf und Seitenzahlen.
- E-Rechnung nach EN 16931 mit eingebetteten Daten im PDF, dazu Zahlungserinnerung und Mahnung mit demselben Zahlenstand.
- Leistungsarten, die zum Geschäft passen: Zeile, Wort, Stunde, Pauschale, Porto, gefahrene Kilometer, Fahrtzeit, jede mit ihrer Einheit.
- Ausfuhr für die Buchhaltung mit frei wählbarem Zeitraum und der Trefferzahl noch vor dem Herunterladen.
Was davon in anderen Projekten wiederverwendet wird
| Baustein | Hier entstanden als | Heute auch in |
|---|---|---|
| Einrichtung per Doppelklick | Installation und Update in einer Datei | Vertriebswerkzeug, Compliance-Verwaltung, Ausschreibungsprüfung |
| Trockenlauf und Übernahme aus einem Code | Import der Altdaten | Fahrerverwaltung, Fahrzeugverwaltung, Vorgangsübernahme |
| Sichtbares Fehlerprotokoll | Suche nach dem Ausgabefehler | alle lokal ausgelieferten Anwendungen |
| E-Rechnung nach EN 16931 | Ausgangsrechnungen | Werkstattsystem, Auftragsportal, Rechnungswerkzeug |
Wenn Ihr Fall ähnlich klingt
Typische Anzeichen: eine Software, die keine Korrekturen mehr bekommt, ein Hersteller, der auf ein Nachfolgeprodukt verweist, und die Frage, wie die Daten von zehn Jahren herauskommen. Schildern Sie das in ein paar Sätzen an kontakt@hubfox.de. Lesen Sie vorher gern, wie wir Updates absichern, denn genau daran entscheidet sich so ein Vorhaben.
Erzählen Sie, was heute weh tut.
Ein paar Sätze genügen: was gemacht wird, womit es heute gemacht wird und woran es hakt. Sie bekommen eine ehrliche Einschätzung, auch dann, wenn die Antwort lautet: dafür brauchen Sie uns nicht.