Beratungs­wissen in ein Software­produkt überführen

Das Fachwissen ist im Haus. Entgeltumwandlung gilt selbst unter Versicherungs­experten als schwieriges Thema, weil sie Arbeitsrecht, Besteuerung, Lohnabrechnung und Dokumentations­pflicht gleichzeitig berührt. Der Markt besteht aus reinen Berechnungs­programmen, einen durchgehend unterstützten Beratungs­prozess bietet keines. Was fehlt, ist der Weg von diesem Wissen zu einem Produkt, das sich bundesweit lizenzieren lässt, und ein Implementierungs­partner, der versteht, was fachlich gemeint ist.

Vier Anforderungs­gruppen, eine Liste. An dieser Software hängen mehr Interessen als an den üblichen: die Agenturen, die damit beraten, die Arbeitgeber, die das Ergebnis in der Lohnabrechnung abbilden müssen, die Arbeitnehmer als indirekte Nutzer und der Anbieter selbst mit seinem Vertrieb. Wir haben alle vier über Workshops und halbstrukturierte Interviews erhoben, mit Schwerpunkt auf den Abläufen, weil die über Bildschirmmasken und Interaktions­pfade entscheiden. Daraus wurden zwei Anforderungs­listen, eine je Komponente, und ein Prozessmodell für die software­gestützte Beratung, das als Referenz für die gesamte weitere Entwicklung diente und in BPMN so notiert war, dass es direkt in Software überführbar blieb.

Eine Architektur, die den Außendienst kennt. Beraten wird beim Arbeitgeber oder beim Arbeitnehmer zu Hause, oft ohne Netz. Die Ziel­architektur bekam deshalb drei Schichten: Präsentation im Client am Notebook, im Web und mobil; Logik mit Steuer-, Renten- und Versichererrechnern; Datenhaltung lokal und zentral, mit Abgleich zwischen beiden. Und eine Unterscheidung, die dem Projekt Aufwand erspart hat: Die Rechenkerne der Versicherer lagen nicht in der Hand des Anbieters, sie werden nur als Webservice bereitgestellt. Technisch war deren Einbindung kein Problem, die Hürde war die Freigabe durch den jeweiligen Versicherer. Diese Grenze klar zu benennen verhinderte, Entwicklungs­aufwand gegen ein Problem zu werfen, das kaufmännisch zu lösen war.

Qualität lässt man nicht von dem prüfen, der sie erzeugt. Wir haben ein Raster für die Beurteilung von Software­qualität aufgestellt, technisch nach Architektur und Sicherheit, fachlich danach, ob das Werkzeug sachlich richtig rechnet, die zugehörigen Aufgaben abdeckt und bedienbar genug ist, um die Erfolgsquote in der Beratung tatsächlich zu erhöhen. Dann haben wir die Herstellung begleitet: Teilnahme an den Statustreffen, vermittelnde Dokumente wie Ablaufdarstellungen und Fragen­kataloge, Meilensteinüberwachung, Mitarbeit an den Tests und hartnäckiges Nachfragen bei stillen Annahmen, welches Vorwissen ein Nutzer hat und auf welcher Plattform er arbeitet. Auch die Aufwandsaufstellungen des Implementierungs­partners haben wir fachlich geprüft. Damit lag die Bewertung der Umsetzung nicht bei dem, der sie erstellt hat.

Ein Produkt entsteht nicht mit dem letzten Commit. Für die Zusammenarbeit haben wir eine gemeinsame Quelltext­verwaltung auf Git aufgebaut, in der der Implementierungs­partner ausschließlich in das zentrale Projekt­repository überträgt: Er gibt bewusst nur die Stände weiter, die Weiter­entwicklung und Test erlauben, und die Änderungs­verläufe bleiben für die Projekt­steuerung nachvoll­ziehbar. Dazu kam die Marktseite: ein funktionaler Vergleich der verfügbaren Werkzeuge nach definierten Kriterien, Testdaten und Beratungs­szenarien, die Arbeit am Preis- und Geschäfts­modell und die Präsentations­pakete für Lizenznehmer, Arbeitgeber und Arbeitnehmer. Am Ende stand nicht nur Software, sondern ein Lizenz- und Partnermodell, über das Agenturen das Werkzeug beziehen konnten.