Wer kennt das nicht: man sitzt mit einem Kollegen aus dem Fachbereich zusammen und nimmt dessen Anforderungen auf. Sätze wie „Über den Teil habe ich mir noch keine Gedanken gemacht.“, „Das kann sich noch ändern.“ oder auch „Das ist der aktuelle Stand, da kommt aber noch was dazu.“ können da schon mal fallen. Was tun? Ist die Antwort „Dann überleg noch mal und sag Bescheid, wenn du Genaueres weißt. Solange kann ich nichts machen.“ immer die beste oder gar richtige? Könnte die momentane Ungewissheit nicht Indikator für den Bedarf einer fachlichen Stellschraube sein?
Im noch laufenden Projekt kann diese Stellschraube für nachträglich „eintrudelnde“ Erweiterungen genutzt werden. Darüber hinaus machen genau diese fachlich motivierten Stellschrauben Software im Betrieb flexibel, weil genau an diesen Stellen gezielt Anpassungen gemacht werden können – zentral an einer dafür vorgesehenen Stelle.
Ein Beispiel aus der Praxis
Ein Beispiel aus meinem aktuellen Projekt im Bereich der Krankenleistungsbearbeitung bei einer Versicherung: Aus den eingereichten Belegen zu erfolgten Behandlungen muss abgeleitet werden, welche tariflichen Teilleistungen für die Regulierung und Erstattung infrage kommen. Prinzipiell kommen für eine erfolgte Behandlung mehrere Teilleistungen in Betracht, abhängig davon, ob die Behandlung z.B. im Rahmen einer Zahnersatzmaßnahme oder einer Vorsorge erfolgt ist. Dieser Sachverhalt steht so nicht explizit auf dem eingereichten Beleg und muss normalerweise durch einen Sachbearbeiter durch Sichtung des eingereichten Belegs und ggf. unter Berücksichtigung der Leistungshistorie ermittelt werden. Würde man an dieser Stelle nicht die letztlich richtige Teilleistung wählen, käme es zu einer Übererstattung. No go. Für eine effiziente Bearbeitung müssen derartige manuelle Bearbeitungsschritte aber möglichst selten vorkommen.
Leider, oder eigentlich zum Glück, wussten wir zum Zeitpunkt der Umsetzung dieses Teilprozesses noch nicht genau, wie die Teilleistungen fachlich geschnitten sein werden. Einerseits weil sich noch kein Best Practice für die Art des Schnitts herausgeprägt hatte, aber auch, weil zu diesem Zeitpunkt noch gar nicht alle Tarife in Teilleistungen zerlegt waren. Hierzu die passende Aussage aus dem Fachbereich: „Das ist der aktuelle Stand. Der kann sich noch ändern und es kommen noch welche dazu.“ Diese gefühlt unvollständige Anforderungsbeschreibung hat zum Konzept der Teilleistungseinschränker geführt. Ein Teilleistungseinschränker prüft die infrage kommende Teilleistungen gegen den Kontext der Behandlung und führt über Ausschluss zur maschinellen Reduktion der Teilleistungen. Je Sachverhalt kann ein Einschränker erstellt werden und dank eines im Ablauf vorgesehenen Plug-in-Mechanismus‘ einfach und schnell in den bestehenden Prozess zu den bereits existierenden Einschränkern eingeklinkt werden. Welchen Wertbeitrag diese Stellschraube zur Flexibilität und späteren Optimierung hat, haben wir kurz darauf erleben können: zu den zwar bekannten, aber noch nicht abgebildeten Tarifen gesellten sich, gesetzlich getrieben, die Unisex-Tarife und damit neue Teilleistungen. Neue Einschränker bauen und einklinken – fertig.
Fazit
Natürlich ist nicht jede Konzeptlücke sinnvoll mit flexiblerer und dadurch unter Umständen teurerer Software zu beantworten. Das oben Gesagte ist aber ein Plädoyer dafür, in noch unvollständigen Anforderungen auch die Chance auf bessere Software zu sehen und auf die manchmal leisen Untertöne und Halbsätze des Noch-nicht-Wissens zu achten. Unser Geschick als Business Analysten, Architekten und Entwickler muss es sein, diese Nuancen rauszuhören und mit den richtigen Mitteln darauf zu reagieren. In vielen Fällen muss die Lösung nicht hochtrabende rocket science sein. Wir konnten das geschilderte Problem mit bereits seit längerem bekannten Architekturmustern (Verantwortlichkeitskette) und –prinzipien (Open Close Principle) lösen.
