Wann ein Festpreis für eigene Software verlässlich sein kann.

Ein Unternehmen möchte ein Kundenportal. Die Geschäftsleitung braucht einen festen Betrag für das Budget. Die Idee klingt zunächst klar: Kunden sollen sich anmelden, Angaben einreichen und ihren Status sehen.

Bei genauerem Nachfragen entstehen neue Fragen. Welche Kunden dürfen welche Daten sehen? Wer prüft einen Antrag? Welche Ausnahmen gibt es? Welche Daten kommen aus dem CRM oder ERP? Sollen alte Vorgänge übernommen werden? Wann gilt eine Funktion als fertig?

Der Satz „Wir brauchen ein Kundenportal“ beschreibt also ein Ziel, aber noch keinen kalkulierbaren Leistungsumfang.

Ein Festpreis ist nicht automatisch das Problem. Schwierig wird er, wenn die feste Zahl auf unbekannten oder wechselnden Grundlagen beruht. Dann wird während der Entwicklung gleichzeitig untersucht, entschieden und umgesetzt.

Häufig fehlen am Anfang:

• ein gemeinsames Ziel,
• wichtige Varianten und Ausnahmefälle,
• geprüfte Zugänge zu anderen Programmen,
• verlässliche Angaben zur Qualität alter Daten,
• Rollen und Zugriffsrechte,
• klare Bedingungen für Test und Abnahme,
• eine Grenze für die erste Ausbaustufe.

Solche offenen Punkte müssen nicht alle verschwinden. Sie müssen aber sichtbar sein. Vor dem Festpreis werden sie entweder geklärt oder ausdrücklich als Annahme und Grenze festgehalten.

In einer kleinen Variante gibt ein Kunde ein Formular ab. Eine zuständige Person prüft es. Danach sieht der Kunde einen einfachen Status.

In einer größeren Variante gibt es mehrere Kundengruppen, verschiedene Freigaben, Dokumente, eine Verbindung zum ERP, die Übernahme alter Daten und besondere Sicherheitsanforderungen. Beide Varianten heißen Kundenportal. Der Aufwand und das Risiko unterscheiden sich deutlich.

Wer trotz dieser offenen Fragen einen festen Preis nennt, muss einen großen Sicherheitspuffer einplanen oder riskiert später Streit über den vereinbarten Inhalt. Mehr Klarheit macht Angebote besser vergleichbar.

Wie viele Details nötig sind, hängt vom Projekt ab. Eine kleine interne Anwendung braucht weniger Vorbereitung als ein wichtiges System mit alten Daten und mehreren Verbindungen.

Mindestens geklärt sein sollten:

• der geplante Ablauf mit wichtigen Ausnahmen,
• Nutzergruppen, Rollen und Zugriffsrechte,
• die wichtigsten Funktionen der ersten Ausbaustufe,
• beteiligte Programme und geprüfte Verbindungswege,
• Umfang, Qualität und Regeln für alte Daten,
• Anforderungen an Datenschutz, Sicherheit und Betrieb,
• erwartete Geschwindigkeit, Verfügbarkeit und Qualität,
• konkrete Bedingungen für Prüfung und Abnahme,
• ausdrücklich ausgeschlossene Leistungen und nötige Mitarbeit.

Ein offener Punkt ist erlaubt. Er muss benannt und mit einer nachvollziehbaren Annahme behandelt werden.

Das Angebot sollte das fachliche Ziel mit konkreten Ergebnissen verbinden. Dazu gehören Leistungen, ausgeschlossene Arbeiten, wichtige Zwischenschritte und Zuständigkeiten beider Seiten. Auch Tests, Abnahme, technische Bereitstellung, Dokumentation und der Umgang mit gefundenen Fehlern gehören in den Rahmen.

Wichtig ist außerdem: Wer stellt Test- und Produktivumgebungen bereit? Wer besorgt Zugänge zu anderen Programmen? Welche Annahmen gelten für technische Schnittstellen und alte Daten?

Regeln zu Gewährleistung, Haftung oder Nachbesserung hängen vom tatsächlichen Vertrag ab. Dieser Artikel ist keine Rechtsberatung. Ein konkreter Vertrag sollte bei Bedarf rechtlich geprüft werden.

Auch bei guter Vorbereitung können während des Projekts neue Erkenntnisse entstehen. Das ist normal. Problematisch wird es, wenn zusätzliche Wünsche still in die Umsetzung gelangen und dadurch Preis, Termin oder Qualität verändern.

Ein geordneter Ablauf sieht so aus:

1. Die gewünschte Änderung wird beschrieben.
2. Auswirkungen auf Ablauf, Technik, Tests, Daten und Betrieb werden geprüft.
3. Folgen für Preis und Zeit werden gezeigt.
4. Erst nach einer Entscheidung wird die Änderung umgesetzt.

Dieser Vorgang heißt Change Request. Eine kleine Klarstellung, die Korrektur eines Fehlers und eine echte Erweiterung sind nicht dasselbe. Maßgeblich ist, welches Ergebnis ursprünglich nachweisbar vereinbart wurde.

Ein Festpreis passt zu einer klar beschriebenen Umsetzung. Die Bezahlung nach tatsächlich eingesetzter Zeit passt besser, wenn Ziel oder technische Machbarkeit noch bewusst untersucht werden. Dieses Modell heißt Time & Material.

Eine Kombination ist möglich: Zuerst wird eine begrenzte Analyse nach Aufwand beauftragt. Ihr Ergebnis ist ein klarer Zielablauf und Umfang. Die anschließende Umsetzung kann dann einen Festpreis erhalten.

Kein Vertragsmodell ersetzt gute Steuerung. Ein niedriger Festpreis hilft nicht, wenn beide Seiten den Inhalt verschieden verstehen. Eine flexible Abrechnung braucht weiterhin Prioritäten, transparente Arbeit und regelmäßige Entscheidungen.

Ein Festpreis für das fertige Endergebnis kann falsche Sicherheit schaffen, wenn die technische Machbarkeit unbekannt ist, sich das Ziel stark verändert, Zugänge zu anderen Programmen fehlen oder alte Daten noch nicht geprüft wurden.

Dann ist eine kleine Analyse oder ein Prototyp sinnvoller. Ein Prototyp ist eine begrenzte Testlösung. Sein Ergebnis muss nicht fertige Software sein. Er kann zeigen, ob ein Lösungsweg funktioniert, welche Variante ausscheidet, welche Risiken bleiben und welcher Umfang danach seriös kalkulierbar ist.

Prüfen Sie zuerst, ob der Zielablauf, die wichtigen Funktionen, Rollen, Verbindungen und Daten bekannt sind. Gibt es für die Abnahme konkrete Prüfkriterien? Sind Grenzen und nötige Mitarbeit dokumentiert? Dann kann ein Festpreis für diesen Umfang sinnvoll sein.

Fehlen diese Grundlagen, begrenzen Sie zuerst die Unsicherheit. Beauftragen Sie eine Prozessanalyse, eine technische Prüfung oder einen klar eingegrenzten Prototyp. Das Ergebnis sollte eine Entscheidung ermöglichen und nicht nur weitere offene Wünsche sammeln.

Scope: Der klar vereinbarte Leistungsumfang. Er beschreibt auch Grenzen und nötige Mitarbeit.

Akzeptanzkriterium: Eine konkrete, prüfbare Bedingung für eine Anforderung.

Abnahme: Die formelle Bestätigung, dass die vereinbarte Leistung erbracht wurde.

Change Request: Ein geordneter Antrag auf eine Änderung des vereinbarten Umfangs.

Time & Material: Abrechnung nach tatsächlich eingesetzter Zeit und gegebenenfalls Material.

Prototyp: Eine begrenzte Testlösung, mit der eine wichtige Annahme geprüft wird.

Deployment: Die technische Bereitstellung einer Software in einer bestimmten Umgebung.

Schnittstelle: Ein festgelegter technischer Zugang für den Datenaustausch zwischen Programmen.

Ein guter Festpreis ist das Ergebnis von Klarheit. Er braucht einen abgestimmten Zielablauf, einen beschriebenen Umfang und prüfbare Bedingungen für die Abnahme. Wenn diese Grundlage fehlt, sollte zuerst die Unsicherheit verringert werden. So bezieht sich der Preis auf ein konkretes Ergebnis und nicht auf eine Sammlung unbekannter Annahmen.