Bevor wir über Lösungen sprechen, verstehen wir die Lage. Zwei intensive Wochen, fester Preis, klar abgegrenztes Ergebnis. Sie bekommen ein Lagebild Ihrer Situation und eine begründete Handlungsempfehlung – und entscheiden danach in Ruhe, wie es weitergeht.

Das Lagebild – was wir liefern

Das Lagebild beschreibt zwei Dinge: was ist und was sein soll. Erst aus der ehrlichen Gegenüberstellung beider Seiten lässt sich seriös spezifizieren.

Die Lage – was ist

• Systemlandkarte  – Ihre tatsächliche IT-Landschaft, logisch und physisch dokumentiert: Datenbanken, Excel-Mappen, Applikationen, Hoster, Provider, Zugriffsrechte. Inklusive der gewachsenen Lösungen, die in keinem Organigramm auftauchen – aber den Betrieb am Laufen halten.
• Schlüsselpersonenregister  – Wer entscheidet, wer hat ein Veto, wer pflegt welches System, wer ist von einer Veränderung am stärksten betroffen. Auch externe Beteiligte: IT-Dienstleister, Steuerberater, Schnittstellenpartner. Software-Projekte scheitern selten an der Technik, oft an unausgesprochenen Abhängigkeiten zwischen Personen.
• Risikoregister  – Eine strukturierte Aufstellung der Risiken nach Eintrittswahrscheinlichkeit und Auswirkung – technisch, organisatorisch, vertraglich, semantisch. Das Format kennen Sie aus ISO-Audits oder Anlageninvestitionen. Wir wenden dieselbe Disziplin auf Software an.
• Glossar  – Begriffe, wie sie in Ihrem Geschäft tatsächlich verwendet werden – nicht wie sie in einem Lehrbuch stehen sollten. Wenn Auftrag im Vertrieb etwas anderes bedeutet als in der Buchhaltung, ist das eine Tatsache, mit der gearbeitet werden muss. Eine geteilte Sprache zwischen Fachbereich und Entwicklung ist die Grundlage jeder funktionierenden Software.

Das Ziel – was sein soll

• Problemstellung  – Eine schriftliche, abgestimmte Formulierung dessen, was eigentlich gelöst werden soll. Klingt selbstverständlich, ist es nie. Die meisten Software-Projekte starten mit einer ungefähren Problembeschreibung und enden mit der Erkenntnis, dass das eigentliche Problem ein anderes war.
• Erfolgsdefinition mit Metriken  – Woran erkennen wir, dass es funktioniert hat? Welche Kennzahl darf sich um wie viel verbessern, gemessen über welchen Zeitraum, mit welcher Methode erhoben. Nur eine messbare Erfolgsdefinition schützt davor, dass am Ende ein technisch funktionierendes System abgeliefert wird, das niemand als Erfolg empfindet.

Die Handlungsempfehlung – was wir raten

Auf Basis des Lagebilds erstellen wir eine begründete Handlungsempfehlung. Sie umfasst zwei Schritte:

Erstens eine Cost-of-Delay-Übersicht: Wir quantifizieren, was Sie das Nichthandeln pro Monat kostet – pro Problemfeld, mit nachvollziehbarer Rechnung. Erst diese Zahl macht entscheidbar, ob und in welcher Reihenfolge die gefundenen Probleme angegangen werden sollten.

Zweitens für jedes priorisierte Problem einen empfohlenen Lösungspfad: Standardsoftware, Individualentwicklung, Prozessänderung – oder eine Kombination. Mit ehrlichen Tradeoffs, nicht mit dem Reflex, dass jede Frage ein Software-Projekt als Antwort braucht.

Das Festhonorar-Angebot – was am Ende steht

Weist die Handlungsempfehlung eine Spezifizierung als sinnvollen nächsten Schritt aus, legen wir am Ende von Phase 1 ein Festhonorar-Angebot für Phase 2 vor. Es bindet uns; Sie sind ungebunden. Das Honorar ist ein Festhonorar, kein Festpreis – Phase 2 ist eine spezifizierende, keine bauende Phase. Der Festpreis für die Fertigung entsteht erst am Ende von Phase 2, wenn die Spezifikation unterschrieben ist.

Ein Hinweis zur Ehrlichkeit

Wir sind nicht neutral. Wenn wir empfehlen, weiterzumachen, profitieren wir davon. Drei Dinge halten wir dem entgegen: Die Handlungsempfehlung ist so dokumentiert, dass ein unabhängiger Dritter sie nachvollziehen und prüfen kann. Wir nennen explizit auch Optionen, die uns kein Folgeprojekt bringen – inklusive „kein Software-Projekt starten“. Und das Honorar für die Voruntersuchung bleibt gleich, ob Sie weitermachen oder nicht. Es ist kein Lockangebot.

Was Sie konkret bekommen

Am Ende halten Sie ein Dokument in der Hand, das einer Voruntersuchung im Anlagenbau entspricht: vollständig dokumentiert, prüfbar durch Dritte, weiterverwendbar auch ohne uns. Sie können auf seiner Grundlage mit uns die Spezifizierung beauftragen, die Spezifizierung an einen anderen Anbieter geben – oder feststellen, dass kein Software-Projekt der richtige nächste Schritt ist. Alle drei Wege sind für uns akzeptable Ergebnisse.

Festpreis-Projekte laufen meist deshalb aus dem Ruder, weil die Spezifikation in Prosa geschrieben ist, die Prosa Lücken hat, und die Lücken erst während des Baus entdeckt werden. Der Bau ist dann mehrere Monate hintereinander zu achtzig Prozent fertig.

In Phase 2 schließen wir diese Lücken, bevor der Bau beginnt. Vier bis acht Wochen, fester Preis, vereinbart am Ende von Phase 1. Am Ende stehen eine unterschriebene Spezifikation und ein verbindlicher Festpreis für die Umsetzung.

Die Spezifikation – was wir liefern

Wir übersetzen die in Phase 1 erarbeitete Domänentheorie in mehrere parallele Darstellungen. Jede deckt andere Lücken auf. Was die eine sichtbar macht, wird in den anderen geprüft und nachgezogen. Am Ende sind sie widerspruchsfrei – und genau dann ist Spezifizierung abgeschlossen.

Drei parallele Darstellungen

• Die Prosa-Spezifikation – was Sie unterschreiben  – Die vertragliche Grundlage, in Ihrer Fachsprache. Szenariobasiert, lesbar, ohne technisches Vokabular. Das Dokument, das beschreibt, was das System in welcher Situation tun soll – formuliert so, dass Sie es Ihrem Vertriebsleiter, Ihrem Steuerberater oder Ihrem Beirat vorlegen können. Was hier nicht steht, wird auch nicht gefertigt. Was hier steht, wird gefertigt.
• Die formale Prüfung – was die Maschine prüft  – Parallel zur Prosa entsteht eine formale Spezifikation in einer Sprache, die unser Werkzeug maschinell auf Lücken und Widersprüche prüft. Sie sehen diese Spezifikation nicht direkt – sie ist Werkzeug, kein Vertragsgegenstand. Aber jeder Widerspruch, den die formale Seite findet, wird zu einer konkreten Frage an Sie. Diese Methodik ist älter als heutige KI; KI macht sie außerhalb der Luft- und Raumfahrt überhaupt erst wirtschaftlich.
• Prototypen und Mockups – was sichtbar entscheidbar wird  – Manche Entscheidungen lassen sich nicht im Lesen klären, sondern nur im Tun oder im Sehen. Wie sich ein Ablauf anfühlt, wenn man ihn klickt. Wo der Blick auf einer Maske zuerst hinfällt. Welche Information dominieren soll, welche nachgeordnet sein darf. Für solche Fragen bauen wir klickbare Prototypen und visuelle Mockups – nicht als Selbstzweck, sondern dort, wo andere Darstellungen die Frage nicht beantworten können.

Das Pendel – wie sie zur Deckung kommen

Die Darstellungen pendeln gegeneinander. Was die formale Seite an Widersprüchen aufdeckt, was ein Prototyp im Gebrauch unklar macht, was ein Mockup an offenen Entscheidungen sichtbar werden lässt – alles wird zu einer Frage an Sie. Ihre Antwort verändert die Prosa, die Prosa verändert die anderen Darstellungen, die nächste Lücke wird sichtbar. Dieser Vorgang ist endlich: Mit jedem Durchgang werden die Lücken kleiner und seltener, bis die Darstellungen sich nicht mehr widersprechen.

Ihre Mitwirkung in dieser Phase ist mittel und strukturiert. Wir kommen mit konkreten Fragen, Sie entscheiden. Keine offenen Workshops, keine Brainstorming-Runden. Jede Sitzung hat ein definiertes Ziel und endet mit Festlegungen.

Das Festpreis-Angebot – was am Ende steht

Wenn die Darstellungen sich nicht mehr widersprechen und Sie die Prosa-Spezifikation unterschreiben, ist sie eingefroren. Erst dann nennen wir den Festpreis für die Umsetzung. Der Festpreis ist möglich, weil die Varianz, die ihn üblicherweise aufbläht, vorher aufgelöst wurde – nicht weil wir besser raten, sondern weil weniger zu raten übrig ist.

Auch hier gilt: Die unterschriebene Spezifikation gehört Ihnen. Sie können auf ihrer Grundlage mit uns die Fertigung beauftragen, ein konkurrierendes Angebot von einem anderen Anbieter einholen – oder das Projekt vorerst zurückstellen. Eine seriöse Spezifikation behält ihren Wert.

Die Fertigung ist die Phase, in der das Werk entsteht – und zugleich die vorhersehbarste. Das ist Absicht. Die schwierigen Entscheidungen sind in den ersten beiden Phasen getroffen; hier können wir uns ganz auf die saubere, verlässliche Umsetzung konzentrieren. Genau deshalb wird die Fertigung gut.

Dauer und Festpreis stehen seit Ende Phase 2 fest. Sie bekommen während des Baus regelmäßig lauffähige Zwischenstände, keinen monatelang wachsenden Berg, der angeblich zu achtzig Prozent fertig ist.

Wie wir bauen

Wir erzeugen die Implementierung unter unserer architektonischen Verantwortung, eingeschränkt durch die formale Spezifikation aus Phase 2. Die Invarianten, die Sie unterschrieben haben, kann der Code nicht verletzen – nicht weil wir besonders aufpassen, sondern weil die Struktur, aus der er erzeugt wird, sie konstruktiv erzwingt.

Der Anteil der KI in dieser Phase ist am höchsten. Code-Generierung, Test-Erzeugung, Dokumentation, Refactoring – das sind die Tätigkeiten, in denen generative Modelle zuverlässig produktiv sind, vorausgesetzt sie arbeiten innerhalb einer engen formalen Struktur. Genau diese Struktur haben wir in Phase 2 gefertigt. Was bei anderen das Risiko ist, ist bei uns keines, weil die Spezifikation den Korrektheitsbegriff vorgibt, gegen den geprüft wird.

Wenn doch etwas auftaucht

Auch nach einer sorgfältigen Spezifizierung kommt es vor, dass der Bau etwas zutage fördert, was niemand vorher gesehen hat. Eine Annahme, die im Modell stimmig war, aber im laufenden System scheitert. Eine Anforderung, die Sie erst formulieren können, wenn Sie das System tatsächlich benutzen. Eine Schnittstelle, die sich anders verhält als ihre Dokumentation.

Wir gehen mit solchen Funden offen um. Drei Fälle sind zu unterscheiden:

• Wir haben einen Fehler gemacht.  Wenn unsere Spezifikation eine Lücke hatte, die wir hätten sehen müssen, tragen wir die Kosten. Phase 2 ist keine Garantie, aber sie ist eine Verantwortung. Was wir nicht ehrlich spezifiziert haben, müssen wir ehrlich nachholen.
• Die Realität war anders, als wir beide dachten.  Wenn die Annahme im Modell für beide Seiten plausibel war und sich erst im Bau als falsch erweist, sprechen wir über die Anpassung – Aufwand, Auswirkung, gemeinsame Entscheidung. Solche Fälle sind selten, weil Phase 2 sie meistens vorher findet, aber sie kommen vor.
• Sie wollen etwas anderes als unterschrieben.  Echte Änderungswünsche durchlaufen denselben Spezifikationszyklus wie das Original, mit eigener Bepreisung. Niemals stillschweigend absorbiert, niemals heimlich nachverhandelt.

In allen drei Fällen wird dokumentiert, was warum entschieden wurde. Sie haben am Ende nicht nur ein System, sondern auch eine nachvollziehbare Geschichte, wie es geworden ist, was es ist.

Was Sie am Ende bekommen

Ein lauffähiges System, abgenommen gegen die Spezifikation aus Phase 2. Den vollständigen Quellcode, sauber dokumentiert, in Ihrem Eigentum. Eine strukturierte Übergabe an Ihr Team oder einen IT-Dienstleister Ihrer Wahl. Der Maßstab: jeder ausreichend qualifizierte Senior-Entwickler soll den Code nach der Übergabe eigenständig weiterentwickeln können. Optional einen Wartungsvertrag zu klar getrennten Konditionen.