1. Die Frage

In einem Projekt in 2017 wurde ich gefragt: „Kennst du keine Methode, mit der man die Kosten einer Systementwicklung bestimmen kann?“ Ich kannte keine. Was folgte, war eine längere Suche. Dieses Papier ist ihr Ergebnis in kurzer Form.

Begonnen hatte es zehn Jahre früher mit dem Versuch aufzuschreiben, woran man in einer Organisation eigentlich ansetzt, wenn man sie verbessern will. Vierzig Seiten, deren Überschrift nicht zufällig „Glauben Sie mir nicht“ lautete. Der Anspruch gilt hier unverändert: Prüfen Sie jede Aussage gegen Ihre eigene Erfahrung. Hält eine nicht stand, ist sie falsch.

2. Was es gibt — und wofür es gilt

Für Software existieren brauchbare Verfahren, und sie sind besser als ihr Ruf. CoCoMo II ist an historischen Projektdaten kalibriert. Function Points sind genormt — mit Zählregeln, zertifizierten Zählern und einer ISO-Norm für die COSMIC-Variante. Die Delphi-Methode strukturiert das Expertenurteil so, dass Ausreißer sichtbar werden. Diese Verfahren liefern reproduzierbare Ergebnisse, und wer sie einsetzt, schätzt nachweislich besser als wer frei schätzt.

Es gibt sogar belastbare Vergleichsdaten darüber, wie stark allein die Wahl des Vorgehensmodells auf Aufwand und Fehlerkosten durchschlägt: Zwischen dem günstigsten und dem teuersten Modell liegt bei identischem Umfang ein Vielfaches, und der größte Einzelposten sind in fast allen Fällen die Kosten des Fehlerfindens und Fehlerbehebens.

Was es nicht gibt, ist ein Gegenstück für die Systementwicklung. Sobald Mechanik, Elektronik, Software, Zulassung, Beschaffung und Fertigungsanlauf in einem Vorhaben zusammenkommen, endet die Werkzeugkiste. Das ist keine Lücke aus Nachlässigkeit. Sie hat einen Grund.

3. Warum die Lücke existiert

Schätzen heißt vergleichen. Ich könnte Ihnen nicht sagen, was eine Besteigung des Mount Everest an Zeit, Ausrüstung und Geld verlangt — nicht weil die Frage unbeantwortbar wäre, sondern weil mir jeder Vergleichsfall fehlt. Wer nie etwas Vergleichbares getan hat, kann nicht schätzen. Er kann raten.

Genau diesen Vergleich stellen die Software-Verfahren her: Sie führen eine gemeinsame Messgröße ein — Codezeilen, Function Points — und beziehen jede neue Aufgabe auf Erfahrungswerte in dieser Größe. Die Bezugsgröße ist das Erzeugnis.

Für ein System gibt es keine solche gemeinsame Größe. Ein Steuergerät, ein Kabelbaum, eine Zulassungsakte und ein Prüfstand lassen sich in keiner Einheit addieren. Wer eine sucht, sucht vergeblich — das ist die leere Stelle in der Werkzeugkiste, und sie lässt sich auf diesem Weg nicht füllen.

Bleibt ein zweiter Weg: die Bezugsgröße nicht am Erzeugnis suchen, sondern an der Arbeit. Über alle Fachgebiete hinweg gleich ist nicht das, was hergestellt wird, sondern die Tätigkeit, die es herstellt.

4. Rückwärts gefragt

Um zu wissen, was etwas kostet, muss ich zuerst wissen, was der Kunde überhaupt will — ob er intern oder extern sitzt, macht keinen Unterschied. Das Gewollte ist ein Arbeitsergebnis, ein Work Product. Alles, was auf diesem Planeten jemand haben möchte, wird durch eine Tätigkeit hergestellt: durch eine Aktivität. Jede Aktivität wird von einer Rolle ausgeführt. Keine beginnt von selbst — sie braucht einen Auslöser und bestimmte Vorbedingungen; irgendjemand wirft etwas über den Zaun. Und jede Aktivität braucht Zeit. Über die Rolle hängen an dieser Zeit die Kosten.

Damit steht die Kette, und sie besteht aus sechs Sätzen, denen Sie vermutlich zustimmen:

• Nichts geschieht ohne Auslöser — ein Zeitpunkt oder ein eintreffender Gegenstand.
• Jede Aktivität benötigt bestimmte Eingänge, um überhaupt starten zu können.
• Jede Aktivität erzeugt ein bestimmtes Ergebnis.
• Jede Aktivität wird von einer Rolle ausgeführt.
• Die Durchführung dauert eine bestimmte Zeit.
• Die Arbeitslast bestimmt sich aus der Menge des Auslösers.

Am Kaffee: Der Durst ist der Auslöser. Wasser, Kaffeemehl und Wärme sind die Vorbedingungen. Eine Rolle kocht. Eine Tasse dauert sechzig Sekunden. Zwölf Tassen dauern länger als eine.

Diese Sätze sind unspektakulär, und darin liegt ihr Wert: Sie gelten unverändert für eine Rechnung in der Buchhaltung, für eine Sicherheitsanalyse und für den Bau eines Getriebes. Damit ist die gesuchte Bezugsgröße gefunden. Sie heißt nicht Produkt, sie heißt Aktivität.

5. Die Zelle

Was dabei herauskommt, ist die kleinste Einheit der Methode — Eingang, Veränderung, Ausgang. Wer mit SIPOC gearbeitet hat, erkennt sie wieder; dort heißen Eingang und Ausgang Lieferant und Kunde, und genau das sind sie auch hier: Aus Sicht des Empfängers ist die ausführende Rolle der Lieferant — auf der Ebene einer Rechnung ist es der Buchhalter.

Abbildung 1: Die Aktivität als Zelle — Eingang, Veränderung, Ausgang.

Mehr ist an der Methode nicht zu lernen. Der Aufwand steckt nicht im Verstehen, sondern in der Umsetzung.

6. Der Unterschied: Vorbedingung statt Pfeil

Klassische Prozessdarstellungen verbinden Aktivitäten, indem jemand Pfeile zeichnet. Das hat zwei Folgen. Erstens muss das Bild bei jeder Änderung nachgezogen werden — es ist eine zweite Wahrheit neben der Wirklichkeit und liegt nach kurzer Zeit daneben. Zweitens werden Verbindungen über die Grenze der jeweiligen Landkarte hinaus gar nicht erst gezeichnet, weil sie in ein anderes Diagramm gehören, das eine andere Abteilung pflegt. Genau an diesen Stellen entstehen die Wartezeiten, über die später niemand Rechenschaft ablegen kann.

Abbildung 2: Die Verbindung wird nicht gezeichnet, sie ergibt sich.

OTSM zeichnet keine Pfeile. Erfasst wird ausschließlich, welchen Eingang eine Aktivität zum Start braucht. Wer diesen Eingang erzeugt, ergibt sich daraus von selbst — auch über Prozess-, Abteilungs- und Projektgrenzen hinweg. Die Verbindung ist kein Bild, sondern eine Folgerung. Sie kann nicht veralten, weil sie nicht gepflegt wird.

7. Flughöhe und Zerlegung

Der Stadtplaner sagt: „Bauen Sie mir eine Siedlung mit vierzig Einfamilienhäusern, mit Straßen und Kanalisation.“ Der Architekt sagt: „120 Quadratmeter, zwei Bäder, ein Wohnzimmer.“ Der Maurer sagt: „Ziegel, Länge, Breite, Höhe.“ Dasselbe Vorhaben auf drei Flughöhen. Prozessbeschreibungen liegen fast immer auf der obersten — und werden deshalb nie genau genug, um daraus zu rechnen. Die Detailtiefe wird schlicht nicht erreicht, weil sie nach zu viel Arbeit aussieht.

Sie ist aber keine Kunst, sondern Fleißarbeit, denn die Form wiederholt sich. Ist ein Work Product zu groß, wird es geteilt; jeder Teil bekommt seine eigene Aktivität, und eine weitere Aktivität setzt die Teile zusammen. Auf jeder Ebene stehen wieder Vorbedingung, Aktivität und Ergebnis.

Abbildung 3: Zerlegen — dieselbe Form auf jeder Ebene.

Das Abbruchkriterium ist einfach: Zerlegt wird, bis eine Rolle die Dauer aus Erfahrung angeben kann. Nicht früher, nicht später. Alles darüber hinaus kostet Erfassungsaufwand ohne Genauigkeitsgewinn.

8. Der Prüfstein: Ihre eigenen Angebote

Ein durchgerechnetes Beispiel steht hier bewusst nicht. Es würde nichts beweisen, weil ich mir die Zahlen passend machen könnte. Überzeugender ist der Blick in Ihr eigenes Haus.

Sehen Sie sich die letzten Angebote und Budgets an, die Sie abgegeben haben. Wie viele davon lassen sich heute noch begründen? Nicht im Sinne von „so wurde kalkuliert“, sondern: An welchen Tätigkeiten, welchen Rollen, welchen Vorbedingungen hing die Zahl?

Und dann die unangenehmere Frage. Wie oft kam aus dem Finanzbereich die Ansage, die Zahlen müssten herunter — und wurde genickt? In den seltensten Fällen, weil jemand überzeugt war. Meistens, weil dem Widerspruch nichts entgegenzusetzen war.

Das Unbehagen der Finanzabteilung hat denselben Ursprung. Dort wird nicht aus Misstrauen gekürzt, sondern weil eine Zahl auf dem Tisch liegt, die niemand belegen kann — und das ist auch dort bekannt. Beide Seiten streiten über eine Größe, für die keine von beiden eine Grundlage hat. Deshalb ist dieser Streit nicht zu gewinnen, sondern nur zu wiederholen, Angebot für Angebot, Jahr für Jahr.

Genau das ändert sich, sobald die Zahl an benannten Aktivitäten, Rollen und Vorbedingungen hängt. Die Finanzseite bekommt etwas, das sie prüfen kann, statt einer Größe, die sie nur drücken kann. Und ist geprüft, ist entschieden — die Auseinandersetzung endet mit einem Ergebnis, statt beim nächsten Mal von vorn zu beginnen.

Dazu zwei Einschränkungen, die ich lieber vorher nenne als hinterher.

Am ersten Tag sind die Zahlen nicht besser als vorher.Was sich sofort ändert, ist die Nachvollziehbarkeit: Man sieht, woran die Schätzung hängt, und wenn sie danebenlag, sieht man wo. Belastbar werden die Zahlen erst, wenn erfasste Aktivitäten auf tatsächliche Durchführungen treffen. Wer heute anfängt, hat ab sofort nachvollziehbare und potentiell belastbare Zahlen — und mit jedem Monat werden sie belegter.

Der Einstieg kostet Arbeit.Aktivitäten, Rollen und Vorbedingungen zu erfassen, ist unbequem, und es lässt sich nicht abkürzen. Der Gegenwert ist genau der Posten, der heute in jeder Kalkulation unbelegt bleibt und sie am häufigsten sprengt: Nacharbeit aus unvollständigem Input. Sobald Vorbedingungen erfasst sind, ist er benennbar — und damit verhandelbar, gegenüber dem Kunden wie gegenüber der eigenen Geschäftsführung.

Das tut weh. Anders wird es nicht funktionieren.

9. Was daraus geworden ist

Beim Erfassen fällt etwas auf. Die Work Products, die dabei entstehen, sind keine Verwaltungsobjekte: Kundenspezifikation, Systemspezifikation, Testplan, Testfall, Fehlermeldung, Änderungsantrag. Es sind die Gegenstände der Entwicklung selbst. Die Planung greift also nicht neben die Arbeit, sie greift hinein.

Und die Form trägt weiter. Dieselbe Aktivität, an ein Produkt statt an einen Prozess gehängt, ist eine Funktion. Die Frage, was passiert, wenn sie ausfällt, ist die FMEA. Die Frage, wie ihre Erfüllung nachgewiesen wird, ist die Qualitätssicherung. Die Frage, wer sie wann ausführt, ist die Planung. Ein Gegenstand, vier Sichten — und eben nicht vier Datenbestände, die man mühsam gegeneinander konsistent halten muss.

Das ist OTSM. Es hat als Antwort auf eine Kostenfrage begonnen und ist zu dem geworden, was diese Antwort voraussetzt.

Ein vollständig durchgerechnetes Beispiel zeigen wir in der Vorführung, an Ihren Zahlen statt an unseren.