Individualsoftware beauftragen: Vergleichen Sie den Änderungsfall, nicht nur den Preis
Zwei Angebote können dieselben Funktionen nennen und völlig unterschiedliche Leistungen enthalten. Ein konkreter Änderungsfall macht Annahmen, Grenzen und Folgekosten sichtbar.
Von Innovation T Team
Das Angebot enthält Kundenverwaltung, Dashboard und eine ERP-Schnittstelle. Das zweite Angebot nennt dieselben Punkte und kostet weniger. Trotzdem wissen Sie noch nicht, ob beide Anbieter dieselbe Anwendung meinen. Vielleicht umfasst die Schnittstelle im ersten Angebot eine überwachte Verarbeitung mit Fehlerbehandlung, im zweiten lediglich einen nächtlichen Export. Der Unterschied wird häufig erst sichtbar, wenn ein realer Geschäftsfall vom idealen Ablauf abweicht.
Wer Individualsoftware für ein deutsches Unternehmen beauftragt, sollte deshalb einen konkreten Änderungsfall in den Angebotsvergleich aufnehmen. Ändern Sie eine Berechtigung, korrigieren Sie einen bereits übertragenen Auftrag oder ergänzen Sie ein neues Pflichtfeld. Lassen Sie jeden Anbieter erklären, welche Auswirkungen das hat, wer entscheidet und welche Arbeit im Angebot enthalten ist. Dadurch wird der Leistungsumfang wesentlich greifbarer als durch eine lange Funktionsliste.
Beschreiben Sie zuerst eine Entscheidung im Arbeitsalltag
Eine gute Anfrage beginnt mit einem nachvollziehbaren Ablauf. Beispielsweise prüft ein Mitarbeiter einen eingegangenen Projektauftrag, ergänzt fehlende Informationen und gibt ihn für die Planung frei. Beschreiben Sie die beteiligten Rollen, verwendeten Systeme und heute notwendigen Rückfragen. Fügen Sie bereinigte Beispieldaten hinzu, damit die Anbieter dieselbe Ausgangslage beurteilen.
Halten Sie auch fest, woran eine Verbesserung erkennbar wäre. Soll eine Information seltener doppelt erfasst werden? Soll ein offener Vorgang immer einen Verantwortlichen haben? Oder soll eine Freigabe später eindeutig nachvollziehbar sein? Solche Ergebnisse lassen sich im Projekt zeigen. Das allgemeine Versprechen einer modernen Plattform lässt sich wesentlich schwerer prüfen.
Legen Sie jedem Anbieter denselben Änderungsfall vor
Nehmen wir einen ausdrücklich fiktiven Dienstleistungsbetrieb: Nach der Freigabe ändert der Kunde den Leistungsort. Diese Änderung beeinflusst die Einsatzplanung, ein Dokument und möglicherweise eine bereits übertragene ERP-Buchung. Ein Anbieter sollte erklären, welche Daten neu geprüft werden und welche bestehenden Entscheidungen ihre Gültigkeit verlieren.
Fragen Sie nach dem Zustand zwischen Anfrage und Umsetzung. Ist die Änderung sofort aktiv oder zunächst ein Vorschlag? Wer darf sie bestätigen? Wie wird verhindert, dass zwei Mitarbeiter widersprüchliche Änderungen speichern? Welche Nachricht erhält der Kunde, wenn ein angeschlossenes System vorübergehend nicht erreichbar ist?
Es geht dabei nicht darum, jede technische Lösung vorzugeben. Sie prüfen, ob der Dienstleister die Geschäftslogik verstanden hat und den gesamten Vorgang kalkuliert. Eine überzeugende Antwort nennt Grenzen und offene Fragen, statt jede Änderung pauschal als problemlos darzustellen.
Verlangen Sie Nachweise für Sicherheitsanforderungen
Sicherheit sollte als konkrete Eigenschaft des Ablaufs beschrieben werden. Ein Mitarbeiter darf einen Vorgang sehen, aber nicht unbedingt freigeben. Ein Kunde darf seine Dokumente herunterladen, jedoch keine Dokumente eines anderen Kunden. Solche Grenzen gehören in die Abnahmefälle und müssen auch bei direkten technischen Anfragen wirksam bleiben.
Der OWASP Application Security Verification Standard bietet überprüfbare Anforderungen für Anwendungen und Webdienste. Das NIST Secure Software Development Framework beschreibt ergänzend Praktiken für eine sichere Softwareentwicklung und eine gemeinsame Sprache im Austausch mit Lieferanten. Beides sind nützliche Bezugspunkte, aber kein Ersatz für die Auswahl passender Anforderungen Ihres Projekts.
Lassen Sie den Anbieter erläutern, welche Anforderungen tatsächlich umgesetzt und wie sie überprüft werden. Eine pauschale Aussage wie „nach OWASP entwickelt“ nennt weder den Umfang noch die vorhandenen Nachweise. Sie sollten erkennen können, was vor der Freigabe geprüft wird und wie später entdeckte Probleme bearbeitet werden.
Trennen Sie Untersuchung, Umsetzung und laufenden Betrieb
Ein ungeklärter Altsystemexport ist kein gewöhnlicher Bildschirm. Wenn die Datenqualität unbekannt ist, sollte zuerst eine begrenzte Untersuchung erfolgen. Das Ergebnis kann eine verlässliche Zuordnung, eine Liste ungeklärter Felder und ein Probelauf mit repräsentativen Daten sein. Erst danach lässt sich die vollständige Migration sinnvoll eingrenzen.
Für die Umsetzung brauchen Sie eine klare Beschreibung der enthaltenen Funktionen und der erwarteten Mitwirkung. Wer liefert Texte, Testdaten, Zugänge und fachliche Entscheidungen? Welche Termine hängen davon ab? Dokumentieren Sie diese Voraussetzungen so, dass fehlende Informationen sichtbar werden, bevor sie einen geplanten Start verschieben.
Der Betrieb benötigt einen eigenen Umfang. Klären Sie Aktualisierungen, Überwachung, Wiederherstellung, Ansprechpartner und den Umgang mit Drittanbieterkosten. Eine Anwendung kann erfolgreich ausgeliefert sein und trotzdem ohne ausreichende Betriebsverantwortung dastehen. Der Angebotsvergleich sollte daher auch die Zeit nach dem ersten Produktivstart berücksichtigen.
Bewerten Sie Änderungen mit einer gemeinsamen Struktur
Ein brauchbarer Änderungsvorschlag beschreibt Anlass, betroffene Abläufe, technische Auswirkungen und die vorgeschlagene Entscheidung. Er nennt Aufwand und mögliche Terminfolgen, bevor die Arbeit verbindlich beauftragt wird. Kleine Korrekturen und neue Anforderungen sollten dabei nachvollziehbar voneinander unterschieden werden.
Bitten Sie um ein Beispiel dieser Darstellung. Damit erkennen Sie, ob der Anbieter Änderungen verständlich kommuniziert oder lediglich zusätzliche Stunden nennt. Ihr Fachteam muss die Konsequenzen beurteilen können, ohne jeden technischen Begriff zu kennen.
Vereinbaren Sie außerdem, wo Entscheidungen dokumentiert werden. Wenn fachliche Zusagen ausschließlich in einzelnen E-Mails liegen, fehlen sie später bei der Abnahme. Eine gemeinsame, versionierte Entscheidungsgrundlage verhindert, dass verschiedene Beteiligte mit unterschiedlichen Vorstellungen arbeiten.
Nutzen Sie die erste Lieferung als Beleg für die Zusammenarbeit
Eine begrenzte erste Lieferung sollte einen vollständigen Geschäftsvorgang abbilden. Dazu gehören Eingabe, Berechtigungen, Verarbeitung, Fehlerfall und ein sichtbares Ergebnis. Ein isolierter Prototyp kann für die Gestaltung hilfreich sein, beweist aber noch nicht, dass die Schnittstelle oder der Betrieb funktioniert.
Lassen Sie Ihr eigenes Team die Abnahme anhand der vereinbarten Fälle durchführen. Dokumentieren Sie, welche Punkte erfüllt, offen oder bewusst verschoben sind. Diese Erfahrung zeigt oft besser als eine Präsentation, wie der Dienstleister Rückfragen, Unsicherheit und Verantwortung behandelt.
Vertiefende Grundlagen finden Sie in unseren Beiträgen zu prüfbaren Tests und sicherer Softwareentwicklung. Innovation T unterstützt Unternehmen mit Software- und Digitalleistungen. Besprechen Sie Ihr Softwarevorhaben mit einem konkreten Arbeitsablauf und der Änderung, die heute besonders viele Rückfragen auslöst.
Häufige Fragen
Wie werden Softwareangebote vergleichbar?
Geben Sie allen Anbietern dieselben Geschäftsfälle, Datenbeispiele und Abnahmekriterien. Lassen Sie Annahmen, ausgeschlossene Leistungen und den Umgang mit Änderungen ausdrücklich beschreiben.
Ist ein Festpreis grundsätzlich besser?
Ein Festpreis hilft bei klar begrenztem Umfang. Bei offenen Schnittstellen oder unklaren Regeln braucht es zuerst eine Untersuchung oder ausdrücklich vereinbarte Annahmen und einen nachvollziehbaren Änderungsprozess.
Welche Unterlagen sollten nach der ersten Projektphase vorliegen?
Ein abgestimmter Ablauf, geklärte Datenverantwortung, priorisierte Risiken, konkrete Abnahmefälle und eine nachvollziehbare Aufwandseinschätzung bilden eine brauchbare Grundlage für die Umsetzung.
Bereit, mit Innovation T zu bauen?
Ob Sicherheit, Wachstum oder Engineering, unser Team hilft Ihnen, es gut umzusetzen.