Von der Excel-Basis zur Fachlogik

Und jetzt liegt der entscheidende Sprung vor uns: von Excel zu einer echten Plattform. Die vorhandene Fachlogik ist der Kern - aber sie allein macht noch keine Plattform. Ein späterer Nutzer soll nicht mit einer komplexen Excel-Datei arbeiten müssen, sondern mit einer klar geführten Anwendung.

Dafür muss die heutige Logik in einen professionellen Rechenkern überführt werden. Darum herum braucht es eine Benutzeroberfläche, Rollen und Rechte, Berichtsausgaben, automatisierte Prüfungen, Support und einen stabilen Betrieb.

Auch die Datenerfassung soll einfacher werden. Darlehensverträge sollen später als PDF hochgeladen werden können, vorhandene Angaben möglichst automatisch übernommen und nur fehlende oder aktuelle Werte gezielt nachgefragt werden.

Der Nutzer soll damit so wenig technische Arbeit wie möglich haben. Seine Aufgabe bleibt vor allem: Angaben prüfen, fehlende Informationen ergänzen, Ziele festlegen und die Ergebnisse verstehen.

Gleichzeitig muss die professionelle Umsetzung testbar sein. Rechenwege, Regeln und Änderungen dürfen nicht nur funktionieren, sondern müssen nachvollziehbar geprüft und bei Weiterentwicklungen reproduzierbar abgesichert werden.

Der Schritt zur Plattform bedeutet deshalb nicht, die Excel einfach ins Internet zu stellen. Er bedeutet, den vorhandenen fachlichen Kern so zu übersetzen, dass daraus ein dauerhaft nutzbares Produkt wird.

Minimal klingt verlockend. Bei DAREALGOR wäre zu wenig später aber teuer. Bei einer neuen Software liegt die Versuchung nahe, zunächst nur das absolute Minimum zu bauen. Für DAREALGOR wäre das an der falschen Stelle gespart.

Dieser Anspruch ist für mich von Anfang an ein wesentlicher Teil des Projekts. DAREALGOR soll nicht nur funktionieren, sondern in seinem Feld einen Referenzmaßstab setzen.

Der Grund dafür liegt auch in der Marktposition: Nach der bisherigen Marktprüfung ist kein direkt vergleichbares Gesamtangebot bekannt, das diese Aufgabe in dieser Form löst. DAREALGOR hat damit die Chance, in einem bislang nicht besetzten Feld früh einen Maßstab zu setzen.

Das bedeutet nicht nur, möglichst früh am Markt zu sein. Die Tiefe der Regeln, Tests, Dokumentation und Ergebnisnachvollziehbarkeit soll eine Qualität schaffen, die nicht einfach nachgebaut werden kann. Nicht durch Abschottung allein, sondern vor allem durch Substanz.

Der Anspruch bedeutet nicht, vom ersten Tag an jede denkbare Zusatzfunktion umzusetzen. Aber die Teile, auf denen Vertrauen und richtige Entscheidungen beruhen, müssen von Anfang an professionell gedacht werden.

Dazu gehören vor allem nachvollziehbare Rechenergebnisse, klare Rollen, belastbare Tests, verständliche Berichte und eine saubere Trennung zwischen Fachlogik, Bedienung und Betrieb.

Ein Nutzer muss später erkennen können, was gerechnet wurde und warum ein Ergebnis entsteht. Fachpartner müssen prüfen können, ob Anforderungen sauber umgesetzt sind. Und Weiterentwicklungen dürfen bestehende Ergebnisse nicht unbemerkt verändern.

Deshalb wird zwischen notwendiger Qualität und bloßem Funktionsumfang unterschieden. Nicht jede Komfortfunktion muss sofort vorhanden sein. Die fachliche und technische Basis soll aber so aufgebaut werden, dass sie später nicht wieder grundlegend ersetzt werden muss.

"Referenzmaßstab statt Minimalversion" bedeutet damit vor allem: lieber einen klar abgegrenzten ersten Funktionsumfang professionell umsetzen als viele Funktionen schnell, aber nicht belastbar.

Software kann man einkaufen. Verantwortung für die richtige Architektur nicht. Für die professionelle Umsetzung reicht es nicht, jemanden zu finden, der Excel-Logik in irgendeine Programmiersprache überträgt. Entscheidend ist, dass die vorhandene Fachlogik verstanden und kontrolliert in eine belastbare Softwarearchitektur übersetzt wird.

Der Softwarepartner muss deshalb zwei Dinge gleichzeitig beherrschen: eine professionelle Plattform bauen und die fachlichen Regeln so umsetzen, dass ihr Verhalten nachvollziehbar und testbar bleibt.

Dazu gehören der Rechenkern, Benutzeroberfläche, Rollen und Rechte, Berichtsausgaben, Datenhaltung, Schnittstellen, automatisierte Tests und später der laufende Betrieb. Diese Bereiche müssen zusammenpassen, ohne dass die eigentliche Fachlogik in einer unübersichtlichen technischen Lösung verschwindet.

Genauso wichtig ist eine unabhängige technische Perspektive auf Auftraggeberseite. Architektur, Aufwand, Angebote, Risiken und spätere Abnahmen sollten nicht ausschließlich von dem Unternehmen bewertet werden, das die Software selbst entwickelt.

Diese unabhängige Perspektive soll konkret durch einen externen technischen Berater abgesichert werden - noch bevor die tiefe Anbieteransprache beginnt. Er gehört ausdrücklich nicht zum späteren Softwareanbieter und soll keine eigene Entwicklungs- oder Vermittlungsagenda verfolgen. Seine Aufgabe ist es, Scope, Architektur, Datenmodell, Aufwand, Angebote, Security, Qualität und später wichtige Abnahmen sowie den Handover unabhängig zu prüfen.

Auch der Schutz des vorhandenen Know-hows gehört dazu. Die Kernlogik soll Kandidaten nur stufenweise und nach klarer Vertraulichkeits- und Zweckbindung offengelegt werden. Gleichzeitig müssen Code, Repositories, Dokumentation, Tests und Übergaberechte so geregelt sein, dass DAREALGOR dauerhaft die Kontrolle behält und nicht von einem einzelnen Anbieter abhängig wird.

Der Initiator bleibt fachlicher Ursprungsträger und Abnahmeanker für die DAREALGOR-Logik. Die professionelle Softwareentwicklung übernimmt aber bewusst ein Partner, der genau dafür die notwendige Erfahrung und Verantwortung mitbringt.

Das Ziel ist keine möglichst schnelle technische Umsetzung, sondern eine Lösung, bei der Fachlogik und Softwarequalität dauerhaft zusammenpassen.