Vom Geschäftsproblem zur Maske: wie wir eine Anforderung in eine Lösung verwandeln

Wenn uns ein Geschäftsführer sagt: „Ich brauche eine bessere Kontrolle über die Kredite“, verlangt er keine Bildschirmmaske. Er beschreibt ein Geschäftsproblem: Kunden, die nicht zahlen, Lieferungen, die ohne Absicherung hinausgehen, ein wachsender Forderungsbestand. Unsere Aufgabe ist es, dieses Problem in etwas zu verwandeln, das das System ausführen, überprüfen und messen kann.

Die vier Ebenen

1. Geschäftsanforderung (das „Warum“). Das Ziel, in der Sprache des Unternehmens. „Überfällige Forderungen senken, ohne den Verkauf zu bremsen.“
2. Geschäftsregeln (das „Was entschieden wird“). Die Richtlinien, die das Unternehmen festlegt. „Wir liefern nicht an einen Kunden, der sein Kreditlimit überschreitet, es sei denn, die Kreditabteilung genehmigt es.“
3. Funktionale Anforderungen (das „Was das System tut“). Konkrete, überprüfbare Verhaltensweisen. „Wenn ein Kreditauftrag bestätigt wird, berechnet das System das Obligo des Kunden und setzt den Auftrag auf Halt, wenn es das Limit überschreitet.“
4. Abnahmekriterien (das „Woran wir erkennen, dass es funktioniert“). Testfälle, die vor jeder Zeile Code geschrieben werden.

Eine Ebene zu überspringen ist der häufigste Grund, warum Projekte „funktionieren“, aber nichts lösen.

Wie wir vorgehen

• Wir hören auf das Problem, nicht auf die Lösung. Wenn ein Benutzer „einen Knopf zum Sperren von Kunden“ verlangt, fragen wir nach dem Warum. Fast immer steckt eine allgemeinere Regel dahinter.
• Wir formulieren die Regel gemeinsam mit dem Unternehmen. Das Geschäft entscheidet über die Regeln. Wir machen sie explizit, mit ihren Ausnahmen und denjenigen, die sie genehmigen.
• Wir zerlegen sie in funktionale Anforderungen mit Beispielen. Jede funktionale Anforderung kommt mit konkreten Beispielen mit echten Zahlen.
• Wir definieren die Abnahme vor dem Programmieren. Mit testgetriebener Entwicklung hat jede Regel von Anfang an ihren automatisierten Test.
• Wir validieren mit dem Key-User während des Sprints. Nicht am Projektende: in jeder Lieferung von zwei bis vier Wochen.
• Wir messen. Die Geschäftsanforderung hatte ein Ziel; nach dem Go-live überprüfen wir die Kennzahl.

Fall 1: ein Großhändler, der ohne Kontrolle auf Kredit verkaufte

Geschäftsproblem. Die Außendienstmitarbeiter nahmen Kreditaufträge an, ohne zu wissen, wie viel der Kunde schuldete; die überfälligen Forderungen wuchsen und die Kreditabteilung erfuhr es zu spät.

Geschäftsregeln.

• Jeder Kunde hat ein Kreditlimit.
• Das Obligo ist das, was der Kunde bereits schuldet, plus der Auftrag, der gerade bestätigt wird.
• Überschreitet das Obligo das Limit, wird der Auftrag auf Halt gesetzt; nur jemand mit Berechtigung kann ihn freigeben.
• Anzahlungen des Kunden werden bei der Fakturierung des Auftrags verrechnet.

Funktionale Anforderungen.

• Beim Bestätigen eines Kreditauftrags das Obligo berechnen und mit dem Limit vergleichen.
• Bei Überschreitung den Auftrag als angehalten markieren und die Kreditabteilung benachrichtigen.
• Ein angehaltener Auftrag kann weder geliefert noch fakturiert werden.
• Bei der Fakturierung die Anzahlung des Kunden automatisch verrechnen.

Abnahmekriterium (Beispiel). Gegeben ein Kunde mit einem Limit von Bs 50.000 und Bs 42.000 Schulden, wenn der Außendienstmitarbeiter einen Auftrag über Bs 12.000 bestätigt, dann wird der Auftrag auf Halt gesetzt, die Kreditabteilung erhält die Benachrichtigung und die Liefertaste ist gesperrt.

Fall 2: ein Importeur, der seine tatsächlichen Kosten nicht kannte

Geschäftsproblem. Der Verkaufspreis wurde auf Basis des Rechnungswerts des Lieferanten kalkuliert, ohne Fracht, Versicherung, Zoll oder lokale Kosten. Einige Produkte wurden mit Verlust verkauft, ohne dass es jemand bemerkte.

Geschäftsregeln.

• Die Kosten eines importierten Produkts umfassen alle Importkosten.
• Jede Kostenposition wird nach einer festgelegten Basis auf die Produkte verteilt: Wert, Gewicht, Volumen oder Menge.
• Die endgültigen Kosten stehen fest, wenn die Importakte abgeschlossen wird.

Funktionale Anforderungen.

• Eine Importakte fasst die Lieferantenrechnungen und alle zugehörigen Kosten zusammen.
• Für jede Kostenposition wird die Verteilungsbasis gewählt.
• Bei der Abrechnung berechnet das System die endgültigen Stückkosten jedes Produkts und aktualisiert die Lagerkosten.
• Auf Basis der endgültigen Kosten wird ein Verkaufspreis gemäß der Zielmarge vorgeschlagen.

Abnahmekriterium (Beispiel). Gegeben eine Sendung mit zwei Produkten gleichen Werts und unterschiedlichen Gewichts, wenn die Fracht nach Gewicht verteilt wird, dann trägt das schwerere Produkt mehr Fracht und seine Stückkosten spiegeln das wider.

Warum das wichtig ist

Eine Anforderung, die sauber in funktionale Begriffe zerlegt ist, lässt sich testen, warten und messen. Eine, die es nicht ist, endet als Anpassungen, die ein Jahr später niemand mehr versteht.

Beide Fälle aus diesem Artikel wurden zu Abläufen in MKA; den ersten können Sie in der Demo zu Aufträgen und Lieferungen durchgehen.