Schnittstellen zu ERP, CRM und Co.: Was im Lastenheft stehen muss, damit die Anbindung im Festpreis bleibt

Eine neue Software steht selten allein. Sie soll Kunden aus dem CRM übernehmen, Rechnungen an das ERP übergeben oder Zahlungen über einen externen Anbieter abwickeln. Im Lastenheft steht dann ein Satz wie "Anbindung an unser ERP", und er sieht harmlos aus. Tatsächlich verbirgt sich dahinter Arbeit, die sich ohne weitere Angaben nicht seriös zum Festpreis kalkulieren lässt. Dieser Artikel zeigt, welche Angaben dein Entwicklungspartner braucht und wie du sie beschaffst.

Warum "Anbindung an unser ERP" nicht kalkulierbar ist

Hinter dem Wort Schnittstelle stecken sehr unterschiedliche Aufgaben. Eine Anbindung kann bedeuten, dass das Fremdsystem eine dokumentierte Programmierschnittstelle (API) anbietet, die der Entwickler aufruft. Sie kann aber ebenso heißen, dass Dateien in einem festen Format auf einen Server gelegt werden, dass ein Datenbankzugriff nötig ist oder dass für das Altsystem gar keine Schnittstelle existiert. Der Aufwand unterscheidet sich je nach Fall um ein Vielfaches. Ohne Angaben zu Art und Dokumentation der Schnittstelle muss der Anbieter entweder einen hohen Risikopuffer einpreisen oder unter Annahmen kalkulieren, die später zu Nachträgen führen.

Die Fragen, die du pro Schnittstelle beantworten solltest

Lege für jedes angebundene System einen eigenen Abschnitt im Lastenheft an und beantworte diese Punkte:

Welches System, welche Version? Hersteller, Produktname und Versionsstand, bei Eigenentwicklungen das Jahr der Inbetriebnahme und die verwendete Technologie.
Welche Art von Schnittstelle gibt es? REST- oder SOAP-API, Dateiaustausch (zum Beispiel CSV oder XML), Datenbankzugriff, Webhooks, oder keine.
Gibt es eine Dokumentation? Ein Link oder Dokument, das der Entwickler vor dem Angebot lesen kann, spart Annahmen.
Zugang zum Testen. Gibt es eine Testumgebung (Sandbox) des Fremdsystems? Ohne sie lässt sich die Anbindung nur gegen das Produktivsystem prüfen. Das ist riskant, weil Testdaten dann in Echtdaten münden können.
Richtung und Auslöser des Datenflusses. Liest die neue Software nur Daten, schreibt sie auch zurück? Passiert das auf Knopfdruck, zeitgesteuert oder in Echtzeit?
Datenumfang und Frequenz. Wie viele Datensätze pro Übertragung und wie oft? Zehn Kundendatensätze am Tag stellen andere Anforderungen als hunderttausend Artikelpreise pro Stunde.
Authentifizierung. Wie meldet sich die neue Software am Fremdsystem an, und wer stellt die Zugangsdaten bereit?

Das Verhalten im Fehlerfall festlegen

Schnittstellen fallen aus: Das Fremdsystem ist zeitweise nicht erreichbar, eine Antwort bleibt aus oder Daten kommen in unerwarteter Form an. Schreibe deshalb ins Lastenheft, was in diesen Fällen passieren soll:

Wird ein fehlgeschlagener Versand automatisch wiederholt, und wie oft?
Wer wird informiert, wenn eine Übertragung dauerhaft scheitert, und auf welchem Weg?
Werden nicht übertragene Daten zwischengespeichert, bis das Fremdsystem wieder antwortet?
Wie gehst du mit doppelten oder widersprüchlichen Datensätzen um?

Ohne diese Festlegungen entscheidet der Entwickler selbst, und du erfährst es erst, wenn der erste Fehler im Betrieb auftritt.

Wer ist für Änderungen am Fremdsystem verantwortlich?

Ein Fremdsystem ändert sich unabhängig von deinem Projekt. Anbieter aktualisieren ihre Programmierschnittstellen, schalten alte Versionen ab oder ändern Preismodelle. Eine Schnittstelle, die bei der Abnahme einwandfrei funktioniert, kann Monate später ausfallen, ohne dass der Dienstleister etwas falsch gemacht hat.

Kläre daher vorab:

Gewährleistung und Wartung trennen. Die Abnahme bestätigt, dass die Anbindung gegen den vereinbarten Stand des Fremdsystems funktioniert. Anpassungen an spätere Änderungen des Fremdsystems sind Weiterentwicklung. Wie du sie vertraglich regelst, beschreibt der Artikel Wartung & Weiterentwicklung - was nach dem Launch niemand einplant.
Benachrichtigung vereinbaren. Wer informiert wen, wenn der Anbieter des Fremdsystems Änderungen ankündigt? Ankündigungen eines Drittanbieters gehen an dessen Vertragspartner, also an dich und nicht an deinen Dienstleister.
Versionierung nutzen. Frag, ob der Dienstleister gegen eine feste API-Version entwickelt und wie lange der Anbieter diese Version unterstützt.

Mitwirkung des Auftraggebers einplanen

Schnittstellenprojekte hängen von Dingen ab, die der Dienstleister nicht allein beschaffen kann: Zugangsdaten, Testsysteme, Ansprechpartner beim Hersteller des Altsystems, Freigaben durch die eigene IT. Halte im Vertrag fest, was du bis wann liefern musst. Verzögert sich das, kann das den Zeitplan verschieben. Mehr zu diesem Thema steht im Artikel Wie du den Zeitplan deines Softwareprojekts realistisch planst.

Sonderfall Altsystem ohne Schnittstelle

Wenn das Bestandssystem keine Schnittstelle anbietet, bleiben mehrere Wege: ein regelmäßiger Datenexport als Datei, ein lesender Datenbankzugriff, der vom Hersteller freigegeben sein muss, oder die Ablösung des Altsystems. Jeder Weg hat andere Risiken, und der Dienstleister sollte sie vor der Festpreiskalkulation prüfen dürfen. Plane dafür eine bezahlte Analysephase ein. Der Artikel Legacy-System ablösen, ohne den Betrieb zu gefährden behandelt diese Frage ausführlicher.

Fazit

Eine Schnittstelle ist ein eigenes Teilprojekt. Pro angebundenem System brauchst du im Lastenheft Angaben zu Version, Schnittstellenart, Dokumentation, Testzugang, Datenfluss, Datenmenge, Anmeldung und Fehlerverhalten. Kläre außerdem, wer für spätere Änderungen am Fremdsystem zuständig ist und was du zum Projekt beisteuerst.

Häufig gestellte Fragen

Reicht es, dem Entwickler Zugang zum Produktivsystem zu geben?

Für lesende Tests mag das funktionieren, für schreibende nicht. Wenn der Entwickler Daten zurückschreibt, brauchst du eine Testumgebung oder einen geschützten Testmandanten, damit keine Testdaten in deine Geschäftsdaten gelangen.

Was kostet eine Schnittstelle?

Eine pauschale Zahl ist nicht seriös. Der Aufwand hängt von Dokumentation, Schnittstellenart, Datenumfang und Fehlerbehandlung ab. Mit den Angaben aus diesem Artikel kann ein Anbieter die Anbindung als eigene Position kalkulieren.

Wer zahlt, wenn der Hersteller des Fremdsystems seine Schnittstelle ändert?

Das hängt vom Vertrag ab. Üblich ist, dass Anpassungen nach der Abnahme zur Wartung oder Weiterentwicklung zählen und nicht im ursprünglichen Festpreis stecken. Vereinbare das ausdrücklich.