In diesem Beitrag
Enterprise-Software: Spezialisten neben dem Systemintegrator einbinden
Dein Enterprise-Programm hat bereits einen Systemintegrator. Die interne IT verantwortet die Plattformen. Die Fachbereiche haben eine Roadmap. Dann braucht ein Kundenportal, eine Integration oder eine interne Anwendung gezielte Unterstützung in der Entwicklung.
Ein zusätzliches Spezialistenteam kann sinnvoll sein, wenn es einen klar definierten Beitrag übernimmt und mit den bereits beteiligten Menschen gut zusammenarbeiten kann. Die entscheidende Frage bei der Beauftragung lautet: Was soll dieses Team liefern, welche Entscheidungen darf es treffen und wie wird seine Arbeit Teil des laufenden Systems?
Bei Wavect ist das ein sinnvoller Ausgangspunkt, um mit Unternehmenskunden über Softwareentwicklung mit klar abgegrenztem Leistungsumfang zu sprechen. Beginne beim Arbeitspaket, den Schnittstellen und dem Team, das das Ergebnis übernimmt. Unser Ablauf für Enterprise-Projekte beschreibt die gesamte Zusammenarbeit, einschließlich Beschaffung und eines klar begrenzten Piloten.
Was bedeutet Co-Delivery bei Enterprise-Software?
Co-Delivery bedeutet, dass mehrere Teams zusammenhängende Teile eines Softwarevorhabens mit vereinbarten Verantwortlichkeiten umsetzen. In der hier beschriebenen Zusammenarbeit arbeiten die interne IT, ein bestehender Systemintegrator und ein zusätzliches Spezialistenteam nach einem gemeinsamen Plan. Jedes Team hat einen definierten Umfang und benannte Ansprechpartner.
Der Systemintegrator koordiniert möglicherweise bereits die übergreifende Umsetzung, während das Spezialistenteam eine bestimmte Anwendung oder Komponente verantwortet. Diese Rollen ergeben sich aus der tatsächlichen Beauftragung. Ein Unternehmensname oder eine Stellenbezeichnung allein verleiht weder Entscheidungsbefugnis über die Architektur noch das Recht zur Release-Freigabe oder die Verantwortung für die Arbeit eines anderen Anbieters.
Wann hilft ein zusätzliches Spezialistenteam?
Ziehe Spezialisten hinzu, wenn sich ein Beitrag eigenständig abgrenzen und prüfen lässt: eine Kundenanwendung, die bestehende Unternehmensdienste nutzt, ein definierter Konnektor, ein interner Ablauf oder eine anspruchsvolle Komponente, die besondere Entwicklungserfahrung erfordert.
Eine sinnvolle Grenze bildet eine Geschäftsfunktion mit nachvollziehbaren Abhängigkeiten. DORAs Leitfaden zu lose gekoppelten Teams verbindet die Eigenständigkeit von Teams mit klaren Servicegrenzen und der Möglichkeit, mit weniger Abhängigkeiten zu testen und bereitzustellen. Daraus ergibt sich für Auftraggeber eine konkrete Frage: Wie viel kann das zusätzliche Team fertigstellen, bevor es eine Entscheidung oder ein Release eines anderen Teams braucht?
Wenn die geplante Änderung denselben eng gekoppelten Kerncode betrifft, an dem der bestehende Anbieter gerade arbeitet, kann es einfacher sein, dessen Arbeitspaket zu erweitern. Ist eine Geschäftsregel strittig, kläre diese Entscheidung, bevor ein weiteres Team sie umsetzen soll. Unser Leitfaden zu widersprüchlichen Geschäftsregeln in Enterprise-Software behandelt dieses vorgelagerte Problem.
Definiere das Arbeitspaket der Spezialisten auf einer Seite
Ein hilfreiches Briefing verbindet das gewünschte Ergebnis mit erlaubten Änderungen, Abhängigkeiten, Nachweisen und der langfristig zuständigen Stelle. So können der bestehende Anbieter und die interne IT etwas Konkretes prüfen, bevor das Spezialistenteam beginnt.
Das folgende Beispiel beschreibt die Zusammenarbeit für ein Portal für Garantieanfragen. Es ist ein Vorschlag für die Abstimmung. Die Verantwortlichkeiten müssen für das tatsächliche Projekt vereinbart werden.
| Feld im Briefing | Vorgeschlagene Vereinbarung |
|---|---|
| Geschäftliches Ergebnis | Ein berechtigter Kunde stellt eine Garantieanfrage und erhält die zugehörige Vorgangsnummer aus dem ERP-System. |
| Beitrag des Spezialistenteams | Portal, Eingabeprüfung und Adapter zur vereinbarten ERP-Schnittstelle entwickeln. Komponententests und Einrichtungsanleitungen liefern. |
| Beitrag des bestehenden Anbieters | Den vereinbarten ERP-Endpunkt, die Feldzuordnung und die Integrationsumgebung innerhalb seines zugewiesenen Teilprojekts bereitstellen. |
| Beitrag der internen IT | Die Anbindung an das Identitätssystem genehmigen, die vereinbarten Umgebungen und Zugänge bereitstellen und das übernehmende Anwendungsteam benennen. |
| Abgrenzung des Umfangs | Die freigegebenen Garantieregeln und den bestehenden ERP-Prozess nutzen. Änderungen an diesen Regeln oder am Kernprozess erfordern eine separate Entscheidung. |
| Voraussetzungen für den Start | Ein versioniertes Schnittstellenbeispiel, freigegebene Testkonten und Testdaten, eine nutzbare Umgebung sowie benannte Ansprechpartner für blockierte Aufgaben. |
| Nachweise für die Abnahme | Den vereinbarten Kundenablauf in der integrierten Umgebung demonstrieren, einschließlich abgelehnter Eingaben, Zugriffsbeschränkungen und einer unterbrochenen Antwort. |
| Empfänger der Übergabe | Das benannte Anwendungsteam kann die gelieferte Komponente anhand von Code, Tests und Anleitungen bauen, bereitstellen und Fehler untersuchen. |
Kläre, wer das Paket beauftragt und Änderungen genehmigt. Ein direkt vom Unternehmen beauftragtes Spezialistenteam kann andere Anweisungs- und Eskalationswege haben als ein Subunternehmer des Integrators. Mache den tatsächlichen Weg für alle Beteiligten sichtbar. Nutze den bestehenden Leitfaden zur Prüfung von Softwareangeboten für die detaillierten kaufmännischen Fragen.
Wer entscheidet zwischen interner IT, Integrator und Spezialistenteam?
Übertrage konkrete Entscheidungsbefugnisse an benannte Personen. „Die drei Teams stimmen sich ab“ lässt das nächste blockierte Ticket ohne Verantwortlichen zurück.
Microsofts Leitfaden zur Projektorganisation bei Dynamics 365 sieht auch zeitlich begrenzte Spezialistenrollen vor. Er empfiehlt, für jedes Teilprojekt die Ergebnisse, Erfolgsmaßstäbe und das Zusammenspiel mit anderen Bereichen zu definieren. Dieses Organisationsprinzip ist auch über das konkrete Produkt hinaus hilfreich.
| Entscheidung | Zu benennende Entscheidungsstelle | Was die umsetzenden Teams liefern |
|---|---|---|
| Fachlicher Umfang und Prioritäten | Produkt- oder Teilprojektverantwortlicher auf Kundenseite mit dem entsprechenden Mandat | Optionen, Aufwand, Abhängigkeiten und die Folgen einer Umfangsänderung |
| Architektur- und Schnittstellenänderungen | Die im Programm benannte Entscheidungsstelle für Architektur oder Plattformen | Einen Änderungsvorschlag, die betroffenen Nutzer der Schnittstelle und eine Kompatibilitätsprüfung |
| Umsetzung des Arbeitspakets | Der benannte Umsetzungsverantwortliche innerhalb des vereinbarten Umfangs | Geprüfte Änderungen, Tests, Dokumentation und sichtbare Restarbeiten |
| Teamübergreifende Blockaden | Ein Programmkoordinator mit definiertem Eskalationsweg | Ein reproduzierbares Problem, die betroffenen Komponenten und einen Verantwortlichen für den nächsten Untersuchungsschritt |
| Fachliche Abnahme | Der zur Abnahme des vereinbarten Ergebnisses berechtigte Kundenvertreter | Nachweise zum integrierten Ablauf, Einschränkungen und offene Befunde |
| Produktionsfreigabe und Betrieb | Die zur Freigabe berechtigte Person und das benannte Betriebsteam | Die bereitstellbare Version, Nachweise zur Betriebsbereitschaft, einen Wiederherstellungsplan und die Übergabe |
Der Integrator kann mehrere dieser Zuständigkeiten übernehmen, wenn das Programm sie ihm zugewiesen hat. An anderer Stelle können sie bei der internen IT oder einer anderen benannten Stelle liegen. Halte die Aufteilung ausdrücklich fest, einschließlich der Befugnis, Änderungen mit Auswirkungen auf ein anderes Teilprojekt zu genehmigen.
AWS empfiehlt für Verantwortlichkeiten zwischen Teams dokumentierte Arbeitsvereinbarungen und Kommunikationswege. Übertrage dieses Prinzip auf die tatsächliche Zusammenarbeit: Wohin geht eine Anfrage zu einer Abhängigkeit, wer treibt sie voran und wann wird eine ausstehende Entscheidung eskaliert?
Mache Schnittstellen nutzbar, bevor du den Backlog füllst
„Das ERP hat eine API“ ist ein Anfang. Das Portalteam muss trotzdem wissen, welche Anfrage es senden darf, welche Antwort es erhält, wie Berechtigungen funktionieren und was bei einem Fehler passiert.
Halte für jede Abhängigkeit das liefernde Team, die vereinbarte Schnittstellenversion, ein repräsentatives Beispiel, die Verfügbarkeit für Tests und die zur Änderungsgenehmigung berechtigte Person fest. Gib blockierten Aufgaben einen nächsten Schritt und einen mit dem jeweiligen Verantwortlichen vereinbarten Termin.
Im Portalbeispiel sollten ERP-Team und Spezialistenteam gemeinsam eine akzeptierte Anfrage, eine abgelehnte Anfrage und eine unterbrochene Antwort durchgehen, bevor der Backlog wächst. Vereinbare, wie das Portal bei einer verlorenen Antwort feststellt, ob bereits ein Vorgang angelegt wurde. Erlaubte Wiederholungen und der Umgang mit Duplikaten gehören in die Schnittstellenvereinbarung.
Eine simulierte Antwort kann die Portalentwicklung voranbringen, während die Integrationsumgebung vorbereitet wird. Halte diese Abhängigkeit sichtbar und plane die Prüfung der echten Integration ein. Nach einer erfolgreichen Demonstration mit simulierten Antworten muss das Zusammenspiel mit dem tatsächlichen ERP noch verifiziert werden.
Nutze die freigegebenen Repositories, Prüfprozesse und Zugangsregelungen des Unternehmens. Kläre, welche Daten und Entwicklungswerkzeuge verwendet werden dürfen, gegebenenfalls auch KI-Werkzeuge. Gib dem Spezialistenteam die Informationen, die es für sein Arbeitspaket braucht, und nutze für zusätzliche Zugänge den etablierten Freigabeweg.
Binde das Arbeitspaket in den Test- und Release-Prozess ein
Trenne den Nachweis, dass die Komponente des Spezialistenteams funktioniert, von der Abnahme des verbundenen Geschäftsablaufs. Beides ist relevant und kann von unterschiedlichen Personen geprüft werden.
Für das beispielhafte Portal prüft das Spezialistenteam das Verhalten seiner Komponente. Danach prüfen die beteiligten Teams den freigegebenen Ablauf mit den tatsächlichen Identitäts- und ERP-Anbindungen. Nimm Zugriffsgrenzen, ungültige Anfragen und die Wiederaufnahme nach einer Unterbrechung in die vereinbarten Szenarien auf.
Scheitert ein Test zwischen Systemen, führe einen gemeinsamen Befund mit getesteten Versionen, Umgebung, Reproduktionsschritten und beobachtetem Ergebnis. Weise die nächste Untersuchung einer benannten Person zu. Sie koordiniert den nächsten Schritt. Die spätere Korrektur übernimmt das Team, das den betroffenen Umfang verantwortet.
Prüfe das verbundene Verhalten nach einer Fehlerbehebung erneut. Dokumentiere offene Befunde und alle dazu getroffenen autorisierten Entscheidungen bei den Release-Nachweisen. Fachliche Abnahme und Erlaubnis zur Bereitstellung folgen jeweils den vereinbarten Entscheidungsbefugnissen des Programms. Ein Statusbericht eines Anbieters ersetzt diese Entscheidungen nicht.
Für den detaillierten Testumfang nutze die Software-QA-Checkliste vor dem Launch. Binde das Arbeitspaket in diesen bestehenden Qualitätsprozess ein.
Plane die Übergabe mit dem künftig zuständigen Team
Benenne das übernehmende Team bereits bei der Definition des Arbeitspakets. Lass es Struktur und Betriebsanleitungen prüfen, solange Änderungen noch einfach möglich sind.
Der Leitfaden der britischen Regierung zur Zusammenarbeit mit externen Anbietern empfiehlt Wissenstransfer durch gemeinsames Arbeiten, gemeinsame Termine und gepflegte Dokumentation. Das praktische Prinzip passt auch hier: Mit dem Repository sollte das Wissen übergehen, das für seine Nutzung gebraucht wird.
Bitte das übernehmende Team, die Einrichtung anhand der Anleitung durchzuführen, die vereinbarten Tests auszuführen, einen repräsentativen Fehler zu untersuchen und die freigegebene Bereitstellung in einer geeigneten Umgebung zu erproben. Die bestehende Checkliste zur Softwareübergabe enthält die ausführlichere Übersicht.
Halte fest, wer das Portal pflegt, wer die ERP-Schnittstelle wartet und wo eine künftige systemübergreifende Störung zuerst gemeldet wird. Vereinbare laufenden Support getrennt vom Umsetzungspaket. Nach der Übergabe sollten diese Zuständigkeiten leicht zu finden sein.
Woran erkennst du, ob die Zusammenarbeit hilft?
Beurteile das Arbeitspaket anhand seines geschäftlichen Ergebnisses und der Reibung, die es im übrigen Programm erzeugt. Wir schlagen folgende Fragen vor:
- Welcher vereinbarte Nutzerablauf funktioniert jetzt in der vorgesehenen Umgebung?
- Was wartet auf ein anderes Team und hat jede Abhängigkeit einen nächsten Schritt?
- Welche Änderungen haben Nacharbeit an einer Schnittstelle verursacht?
- Kann das übernehmende Team den gelieferten Umfang betreiben und verändern?
Entscheide anhand dieser Antworten, ob du den Umfang des Spezialistenteams erweiterst, das aktuelle Paket abschließt oder zuerst die Zusammenarbeit verbesserst. Ein größerer Backlog für die Spezialisten ist nur dann hilfreich, wenn die umliegenden Teams die Ergebnisse aufnehmen können.
Wo Wavect in ein Enterprise-Programm passt
Wavect ist ein österreichisches Software-Produktstudio mit erfahrenen Entwicklern und QA-Leistungen. Wir können ein abgegrenztes Umsetzungspaket mit dir besprechen, in deiner bestehenden Entwicklungsumgebung arbeiten und Nachweise sowie Übergabe am vereinbarten Beitrag ausrichten.
Unsere IKB-Fallstudie beschreibt die Mitarbeit an einem laufenden Smart-City-Vorhaben neben dem eigenen Team der IKB: Infrastruktur und Geräteintegration ergänzen und die Plattform an das interne Team übergeben. Die Polity-Fallstudie behandelt QA-Koordination über sieben Services und mehrere Anbieter hinweg. Das sind öffentliche Beispiele für die Mitarbeit in etablierten Projektumgebungen.
Verzeichnisnachweise, geprüft am 19. Oktober 2026: Wavect steht auf Platz 1 der nummerierten österreichischen Listen für Softwareentwicklung bei Clutch und The Manifest. GoodFirms nennt Wavect in seiner österreichischen Kategorieübersicht für Softwareentwicklung als bestplatziertes Unternehmen.
Diese Kategoriepositionen beziehen sich auf den genannten Zeitpunkt. The Manifest ist eine Schwesterseite von Clutch und nutzt dessen Bewertungsdaten. Prüfe neben diesen Nachweisen die vorgeschlagenen Personen, das Arbeitspaket und eure Unternehmensanforderungen. Unsere Dokumentation der Verzeichnisrankings beschreibt die Entwicklung über weitere Kategorien hinweg.
Spezialistenteams und Systemintegratoren im Enterprise-Umfeld: FAQ
Kann ein Unternehmen ein Spezialistenteam neben seinem bestehenden Systemintegrator einsetzen?
Sollte das Unternehmen die Spezialisten direkt oder über den Integrator beauftragen?
Wer ist für einen Fehler zwischen der Anwendung der Spezialisten und dem System des Integrators zuständig?
Muss das Spezialistenteam die gesamte Unternehmensarchitektur verantworten?
Was sollte bereitstehen, bevor die Spezialisten mit der Entwicklung beginnen?
Beginne mit einem Beitrag, den dein Programm aufnehmen kann
Bring das gewünschte Ergebnis, die beteiligten Systeme und die bereits zuständigen Personen mit. Wir können ein Arbeitspaket besprechen, das dem Spezialistenteam einen klaren Beitrag zuweist und deinen bestehenden Teams einen klaren Weg gibt, das Ergebnis zu prüfen, zu integrieren und zu betreiben.