Was ist ein Systemintegrator?

Von Brian Tr · Aktualisiert am 7. Oktober 2026

Ein Unternehmen kauft ein CRM, ein ERP, ein Data Warehouse und eine Marketingplattform. Jedes funktioniert für sich einwandfrei. Doch keines stimmt mit den anderen darin überein, was ein Kunde ist, welches System die Wahrheit über eine Bestellung hält oder wer benachrichtigt wird, wenn etwas ausfällt. Jemand muss dafür sorgen, dass die Einzelteile wie ein System arbeiten, und in den meisten großen Organisationen ist dieser Jemand weder der Softwareanbieter noch das interne IT-Team. Es ist ein Systemintegrator.

Dieser Artikel definiert den Begriff, grenzt ihn von den Partnertypen ab, mit denen er verwechselt wird, erklärt, wie SI-Partnerschaften aus Sicht des Anbieters aufgebaut sind, und beschreibt die kommerziellen Risiken.

Was ein Systemintegrator ist

Ein Systemintegrator (SI) ist ein Dienstleistungsunternehmen, das Technologiekomponenten plant, baut und verbindet, damit sie für einen bestimmten Kunden als eine Lösung zusammenarbeiten. Die Arbeit umfasst meist eine Mischung aus Design, Konfiguration, individueller Entwicklung, Datenmigration, Tests, Deployment und Übergabe.

Das amerikanische National Institute of Standards and Technology liefert in seinen Leitlinien zu Lieferkettenrisiken eine kompakte formale Definition: Systemintegratoren sind Organisationen, die dem Auftraggeber maßgeschneiderte Leistungen erbringen, darunter individuelle Entwicklung, Test, Betrieb und Wartung. Beachten Sie das Wort maßgeschneidert. Das Ergebnis eines SI ist auf die Umgebung eines einzelnen Käufers zugeschnitten, und genau das unterscheidet ihn von einem Unternehmen, das allen dasselbe Produkt liefert.

In einem Partnerprogramm wird der Begriff enger gefasst. Anbieter verwenden „SI-Partner" oder „Beratungspartner" für ein Dienstleistungsunternehmen, das die Plattform des Anbieters in Kundenkonten implementiert. Die Partnerseite von Salesforce unterteilt ihre Partnertypen zum Beispiel in ISV-Partner, die Apps entwickeln, und Beratungspartner, die Implementierungs- und Beratungsleistungen erbringen. AWS fasst dieselbe Art von Unternehmen unter seinem Services Path zusammen, für Organisationen, die Beratung, professionelle Dienstleistungen, Managed Services und Value-Added-Resale-Leistungen erbringen.

Drei Merkmale prägen das Modell:

• Es verkauft Zeit und Expertise, keine Lizenzen. Der Umsatz stammt aus Projekthonoraren, Retainern oder gestellten Teams.
• Es arbeitet anbieterübergreifend. Ein typischer SI implementiert mehrere Plattformen und muss sie nebeneinander funktionieren lassen, daher hat er selten eine Bindung an ein einzelnes Produkt.
• Es trägt das Lieferrisiko. Verzögert sich ein Go-live, ruft der Kunde zuerst den SI an, oft sogar nur den SI.

Wichtige Fakten: Systemintegratoren

• NIST definiert Systemintegratoren als Organisationen, die dem Auftraggeber maßgeschneiderte Leistungen erbringen, etwa individuelle Entwicklung, Test, Betrieb und Wartung (NIST CSRC).
• Die Partnerseite von Salesforce gibt an, dass 70 % der Salesforce-Implementierungen von Beratungspartnern geleitet werden (Salesforce). Das ist die eigene Zahl des Anbieters über sein eigenes Ökosystem.
• AWS leitet Beratungs-, Professional-Services-, Managed-Services- und Value-Added-Resale-Unternehmen über einen Services Path, wobei der Aufstieg über die AWS Services Partner Tiers gemessen wird (AWS).
• Microsoft bewertet Partner in sechs Lösungsbereichen mit jeweils bis zu 100 Punkten über Leistung, Qualifizierung und Kundenerfolg und verlangt mindestens 70 Punkte für eine Solutions-Partner-Auszeichnung (Microsoft Learn).
• Das Migration Acceleration Program von AWS wird unter den Services-Programmen als Weg aufgeführt, ein Dienstleistungsgeschäft aufzubauen, indem Value-Added-Services mit AWS-Lösungen kombiniert werden (AWS).

Was Systemintegratoren tatsächlich tun

Das Aufgabenprofil variiert mit der Projektgröße, doch die meisten Projekte durchlaufen dieselben Phasen.

Discovery und Design. Der SI erfasst die Prozesse, Systeme und Daten des Kunden und schlägt dann eine Architektur vor. Hier entscheidet er, welches System für welche Art von Datensatz die maßgebliche Quelle ist.

Aufbau und Konfiguration. Die Plattform konfigurieren, individuellen Code schreiben, wo die Konfiguration nicht reicht, und die Konnektoren zwischen den Systemen bauen. Die Integrationsarbeit, etwa mit APIs, Middleware und Event-Pipelines, gibt der Kategorie ihren Namen.

Daten migrieren. Datensätze aus Altsystemen herausholen, bereinigen und in das neue System laden. Das ist meist die unspektakulärste und am stärksten unterschätzte Aufgabe im Projektplan.

Testen und ausrollen. Abnahmetests durch die Anwender, Planung der Umstellung, Unterstützung beim Go-live.

Übergeben oder weiter betreiben. Manche SIs gehen nach der Schulung. Andere bleiben im Rahmen eines Supportvertrags, und hier beginnt sich das Modell mit dem eines Managed Service Providers zu überschneiden.

Ein konkretes Beispiel: Ein Hersteller ersetzt drei regionale Bestellsysteme durch ein Cloud-ERP. Der ERP-Anbieter liefert die Software. Der SI gestaltet den Order-to-Cash-Prozess neu, baut die Anbindungen an das Lagersystem und das Kundenportal, migriert zehn Jahre Bestellhistorie, schult das Finanzteam und steht beim ersten Quartalsabschluss in Rufbereitschaft. Der Anbieter berührt den Großteil dieser Arbeit nie, und der Kunde würde das auch nicht wollen.

SI im Vergleich zu anderen Partnertypen

Der SI wird mit mehreren Nachbarn verwechselt. Die Unterschiede ergeben sich daraus, was das Unternehmen verkauft und wer das Kundenergebnis verantwortet.

Die Grenzen sind in der Praxis durchlässig. Ein großes Unternehmen kann Ihre Plattform implementieren, Lizenzen weiterverkaufen, die Umgebung anschließend betreiben und eine eigene Zusatz-App veröffentlichen, alles unter einem Logo. Die nützliche Frage lautet nicht, welche Bezeichnung ein Unternehmen verwendet, sondern welcher Geschäftsbereich die Beziehung finanziert. Sind es Implementierungsstunden, haben Sie es mit einem SI zu tun, was sonst auch in der Broschüre steht.

Der Unterschied zum Reseller ist für das Programmdesign am wichtigsten. Ein Reseller wird von der Produktmarge angetrieben, daher können Sie ihn mit Rabatten und Deal Registration steuern. Ein SI wird von abrechenbarer Arbeit angetrieben, Rabatte bewirken daher wenig. Einen SI bewegen ein Strom gut qualifizierter Projekte, der Zugang zu Ihren Entwicklern und ein Reputationsgewinn.

Wie Anbieter SI-Partnerprogramme aufbauen

Jeder große Plattformanbieter braucht SIs, denn ein komplexes Produkt implementiert sich nicht von selbst. Die Programme unterscheiden sich im Detail, folgen aber einem gemeinsamen Muster: Eintrittsanforderungen festlegen, den Partner an Kompetenzen und Kundenergebnissen messen und gemessene Leistung mit Sichtbarkeit und Unterstützung belohnen.

Was die Anbieter veröffentlichen

Programmnamen und Stufen ändern sich häufig. Betrachten Sie dies als Momentaufnahme und lesen Sie die aktuelle Seite des Anbieters, bevor Sie einen Plan darauf aufbauen.

Die drei Stellschrauben der Anbieter

Kompetenzen. Zertifizierungen sind die häufigste Eintrittshürde, weil der Anbieter so die Lieferqualität einschätzen kann, ohne jedes Projekt zu prüfen. Der Score von Microsoft enthält eine Qualifizierungskategorie, die darauf basiert, wie viele Personen in der Partnerorganisation Zertifizierungen auf mittlerem und fortgeschrittenem Niveau besitzen. Wie das aus Programmsicht funktioniert, lesen Sie unter Partner-Zertifizierung und Partner-Enablement.

Kundenergebnisse. Programme schauen zunehmend über die Mitarbeiterzahl hinaus auf Ergebnisse. Die Kategorie Kundenerfolg bei Microsoft misst Nutzungswachstum und Deployments, der Partner wird also daran bewertet, ob Kunden das Produkt tatsächlich einsetzen. Ein Anbieter kann die Projektqualität nicht direkt sehen und beobachtet deshalb stattdessen die Nutzungsdaten.

Pipeline und Umsatz. Viele Programme belohnen Partner, die neue Kunden bringen oder beeinflussen. Die Leistungskategorie bei Microsoft basiert auf der Netto-Kundenzahl, wobei verlorene Kunden abgezogen werden. Das ist eine umsatznahe Messgröße, angewandt auf ein Dienstleistungsunternehmen, und sie zeigt, wo das Interesse des Anbieters liegt.

Was SIs im Gegenzug erhalten

Die Vorteilslisten auf diesen Seiten sind einheitlich. Salesforce nennt Rabatte auf Trainerschulungen, Trailhead- und Accredited-Professional-Prüfungsgutscheine, Empfehlungsanreize und Marketinglizenzen. Das Migration Acceleration Program von AWS wird beschrieben als Weg, Value-Added-Services mit AWS-Lösungen zu hochwertigen Angeboten zu kombinieren. Über die aufgelisteten Punkte hinaus besteht der eigentliche Preis meist darin, dem Kunden durch das eigene Vertriebsteam des Anbieters vorgestellt zu werden, was an Co-Selling anknüpft.

Warum Anbieter SI-Partner brauchen

Die Aussage von Salesforce, dass 70 % der Implementierungen von Beratungspartnern geleitet werden, zeigt auf den ersten Blick, wie viel vom Kundenerlebnis einer Plattform bei Dritten liegt. Diese Zahl ist Salesforces Beschreibung des eigenen Ökosystems, lesen Sie sie also als Hinweis auf einen Anbieter und nicht als Marktdurchschnitt.

Vier Anreize erklären die Investition.

Kapazität. Das Professional-Services-Team eines Anbieters kann nicht jedes Kundenprojekt besetzen. SIs skalieren die Umsetzung, ohne dass der Anbieter Personal aufbauen muss.

Adoption. Ein gut implementiertes Produkt wird genutzt und verlängert. Ein schlecht implementiertes wird dem Anbieter angelastet. Der Microsoft-Score, der Nutzungswachstum und Deployments misst, macht diesen Zusammenhang ausdrücklich.

Zugang zu komplexen Kunden. Große Organisationen wünschen sich oft einen vertrauten Integrator, der die Plattform auswählt und implementiert. SIs beeinflussen die Plattformwahl, deshalb wollen Anbieter, dass sie das Produkt schon vor der Kaufentscheidung kennen.

Servicemarge, die der Anbieter nicht will. Viele Softwareunternehmen bevorzugen margenstarke Lizenzerlöse gegenüber margenschwächerer Arbeitsleistung. Überlassen sie die Arbeit den Partnern, bleibt die Wirtschaftlichkeit des Anbieters intakt.

Vorteile der Zusammenarbeit mit SIs

Für den Anbieter:

• Lieferkapazität, die Sie nicht einstellen müssen. Der SI trägt die Personalkosten.
• Einfluss auf frühe Deals. Ein Integrator, der schon beim Kunden vor Ort ist, kann Ihr Produkt empfehlen.
• Kundenerfolg außerhalb Ihres Organigramms. Der SI übernimmt die anspruchsvolle Konfigurationsarbeit, die sonst zu Support-Tickets würde.

Für den Kunden:

• Eine einzige verantwortliche Partei für ein Projekt mit mehreren Anbietern.
• Umgebungsspezifisches Design, das kein Standardprodukt bietet.
• Unabhängigkeit von der Roadmap eines einzelnen Anbieters, zumindest im Prinzip.

Risiken und Zielkonflikte

Qualität, die Sie nicht kontrollieren. Die Arbeit des SI trägt Ihr Logo. Eine gescheiterte Implementierung schädigt das Bild Ihres Produkts beim Kunden, und der Kunde unterscheidet selten zwischen der Plattform und dem Partner, der sie eingeführt hat. Zertifizierungshürden und Customer-Success-Kennzahlen dienen teilweise dazu, dieses Risiko zu steuern, können es aber nicht beseitigen.

Geteilte Loyalität. Ein SI, der fünf konkurrierende Plattformen implementiert, empfiehlt diejenige, die zum Budget des Kunden und zur eigenen Besetzungsstärke passt. Für den Kunden ist das ein Vorteil, für den Anbieter ein Risiko. Exklusivität lässt sich nicht günstig kaufen, und manche Partnerverträge verzichten ausdrücklich darauf. Welche Klauseln wichtig sind, lesen Sie unter Partnervertrag.

Umsatzkonzentration. Beeinflussen wenige SIs den Großteil Ihrer Deals, tut der Verlust eines davon weh. Anbieter steuern dem entgegen, indem sie ein breiteres Partner-Ökosystem aufbauen, statt sich auf eine kurze Liste großer Unternehmen zu stützen.

Anreizkonflikt. Ein SI verdient an Stunden. Ein Produkt, das sich leichter implementieren lässt, verkürzt das Projekt und schmälert den Umsatz des SI. Diese Spannung ist real, und deshalb gewinnt ein einfacheres Produkt nicht automatisch die Unterstützung der SIs. Programme, die Adoptionsergebnisse statt Projektgröße belohnen, bringen die Anreize wieder in Einklang.

Kunden-Lock-in auf Käuferseite. Ein Kunde, der sich auf die individuellen Integrationen eines SI verlässt, kann es schwer haben, den Partner zu wechseln oder die Plattform zu aktualisieren. Käufer sollten auf Dokumentation und saubere Übergabekonditionen bestehen.

Kosten. SI-Projekte sind teuer, und die Gesamtkosten eines Anbieters für den Kunden schließen sie ein. Kostet die Implementierung mehr als die Lizenz, spürt das der Käufer, und die Abschlussquote des Anbieters ebenfalls.

Wo SIs in eine Partnerstrategie passen

SIs stehen auf der Dienstleistungsseite der Landkarte. Reseller und Distributoren bewegen Produkte, wie unter Distributor vs. Reseller beschrieben, und ISVs erweitern das Produkt. SIs sorgen dafür, dass es im Betrieb eines bestimmten Kunden funktioniert. Ein Anbieter mit komplexer Software und langen Verkaufszyklen braucht in der Regel alle drei, im Verhältnis dazu, wie schwer das Produkt zu implementieren ist.

Wenn Sie ein Programm für SIs aufbauen, lauten die praktischen Fragen:

1. Welche Kompetenzen muss ein Partner nachweisen, bevor er die Umgebung eines Kunden anfasst?
2. Wie messen Sie Kundenergebnisse und nicht nur Partneraktivität?
3. Wie leiten Sie qualifizierte Projekte fair an Partner weiter, und was passiert, wenn zwei Partner denselben Deal wollen?
4. Welchen Zugang zu Ihren Entwicklern und Ihrer Roadmap erhalten Partner, und auf welcher Stufe?

Diese Fragen gehören in Ihre Partnerschaftsstrategie und hängen mit der übergeordneten Logik des partnergetriebenen Wachstums zusammen. Die Struktur des Channel-Sales-Modells erklärt, wo Dienstleistungspartner im Verhältnis zu Verkäufern stehen, und was ein Channel-Partner ist, behandelt die allgemeine Kategorie.

Sind Sie der SI, der entscheidet, an welchen Anbietern er sich ausrichtet, drehen Sie die Fragen um: Welche Plattform nutzen Ihre Zielkunden bereits? Was kostet die Zertifizierung in abrechenbaren Stunden? Und welcher Umsatzanteil darf von einem Anbieter stammen, bevor Sie angreifbar werden?