🌐

English?

Would you like to switch to your local language?

Sep 18, 2026

Bewertung von Systemintegratoren mit 8 Entscheidungskriterien

Bewertung von Systemintegratoren aus der Sicht des Managements: So zeigt sich, ob der Partner die Prozesse tatsächlich verbessert oder nur zusätzliche Komplexität schafft.

Bewertung von Systemintegratoren mit 8 Entscheidungskriterien

Short Answer

Bewertung von Systemintegratoren aus der Sicht des Managements: So zeigt sich, ob der Partner die Prozesse tatsächlich verbessert oder nur zusätzliche Komplexität schafft.

Morgens lädt jemand die Bestellungen des Webshops herunter und erfasst sie manuell im Verwaltungssystem. Das Lager arbeitet mit einer anderen Tabelle, und der Vertrieb kann nur telefonisch mitteilen, was erfüllt werden kann. Alle Systeme funktionieren - dennoch übernehmen die Menschen die Datenübertragung zwischen ihnen. In einer solchen Situation ist die Bewertung des Systemintegrators nicht in erster Linie eine technologische Beschaffungsaufgabe. Es geht darum, ob der ausgewählte Partner in der Lage ist zu verstehen, wie das Geschäft tatsächlich funktioniert, und ob er es nachhaltig verbessern kann.

Eine Integration kann eine schnell erstellte Datenverbindung sein, aber auch ein Eingriff, der Fehler reduziert, die Durchlaufzeit verkürzt und zuverlässigere Managementinformationen schafft. Der Unterschied wird selten dadurch entschieden, welcher Anbieter die meisten Systeme kennt. Vielmehr geht es darum, welche Fragen gestellt werden, wie das Risiko gehandhabt wird und wer die Verantwortung übernimmt, auch wenn im Echtbetrieb eine Ausnahme auftritt.

Die Bewertung des Systemintegrators beginnt mit dem Geschäftsprozess

Wenn ein Partner im ersten Gespräch bereits eine fertige technologische Lösung anbietet, sollte man vorsichtig sein. Es mag sein, dass tatsächlich eine ERP-Verbindung, eine individuelle Entwicklung oder eine automatisierte Dokumentenverarbeitung erforderlich ist. Aber zuerst muss geklärt werden, warum der betreffende Prozess so entstanden ist.

Zum Beispiel erfolgt eine Verzögerung bei der Rechnungsstellung nicht unbedingt, weil zwei Systeme nicht verbunden sind. Es kann sein, dass die Bestelldaten unvollständig sind, die Genehmigungsregeln unklar sind oder dass dieselben Daten von drei verschiedenen Teams gepflegt werden. Wenn eine neue Verbindung dies unverändert nur schneller weiterleitet, wird der Fehler auch schneller in das nächste System übertragen.

Ein guter Integrator kartiert die Prozessschritte, die Verantwortlichkeitspunkte und den Informationsfluss. Er fragt nach, wo manuelle Arbeit entsteht, wer in Ausnahmesituationen entscheidet, welche Daten authentisch sind und was passiert, wenn ein externes System nicht verfügbar ist. Dies ist keine überflüssige Vorbereitung. Es trennt die Betriebsverbesserung von der bloßen Systemverbindung.

1. Versteht er das Problem über die Systemnamen hinaus?

Ein Integrator muss über APIs, Berechtigungen, Protokollierung und Fehlerbehandlung sprechen können. Für die Entscheidung ist jedoch ebenso wichtig, dass er die geschäftlichen Konsequenzen versteht.

Wenn zum Beispiel der Lagerbestand im Webshop erst Stunden später aktualisiert wird, ist die technische Frage die Art der Datenaktualisierung. Die geschäftliche Frage ist jedoch, wie viele Fehlbestellungen, Kundenanfragen, Teillieferungen und manuelle Korrekturen daraus resultieren. Ein erfahrener Partner behandelt beide Ebenen und verwechselt nicht das Symptom mit der Ursache.

Es lohnt sich, den Kandidaten zu bitten, das Problem in seinen eigenen Worten zusammenzufassen. Wenn er ausschließlich Werkzeuge und Schnittstellen aufzählt, betrachtet er es wahrscheinlich als Entwicklungsaufgabe. Wenn er über den Prozessverantwortlichen, Entscheidungspunkte, Ausnahmen und messbare Ergebnisse spricht, kann er die gesamte Veränderung eher im Griff behalten.

2. Hat er eine nachweisbare Methode zur Bewertung?

„Wir ermitteln die Anforderungen“ ist an sich keine Methodik. Der Leiter muss sehen, welche Entscheidungen am Ende der Bewertung getroffen werden können. Wird zum Beispiel geklärt, welches System die primäre Quelle der jeweiligen Daten ist? Wird die Beschreibung des aktuellen und zukünftigen Prozesses erstellt? Werden die Ausnahmen, Abhängigkeiten und Risiken sichtbar?

Eine gute Vorbereitung hat greifbare Ergebnisse: Prozessdiagramm, Systembild, Datenflussmodell, Verantwortlichkeitsmatrix, priorisierter Entwicklungsplan und Abnahmekriterien. Nicht jedes Projekt erfordert die gleiche Detailtiefe. Eine gut dokumentierte Verbindung zwischen zwei Systemen erfordert möglicherweise weniger Untersuchung als eine Umgestaltung, die Produktions-, Bestands- und Bestelldaten betrifft. Das Wesentliche ist die Verhältnismäßigkeit, nicht die Menge der Dokumente.

Ein besonders warnendes Zeichen ist, wenn der Partner einen festen Preis und eine feste Frist verspricht, ohne die Qualität der Quelldaten, die Einschränkungen des alten Systems oder die täglichen Ausnahmefälle zu kennen. Dies ist oft keine Selbstsicherheit, sondern die Vorbereitung auf spätere Änderungsanforderungen.

3. Wie geht er mit Datenqualität und Systemgrenzen um?

Ein häufiges Missverständnis bei Integrationen ist, dass die Verbindung von Systemen Ordnung in die Daten bringt. Tatsächlich überträgt die Integration nur das, was verfügbar ist. Wenn derselbe Kunde drei Namen, unterschiedliche Identifikatoren oder unvollständige Adressen an mehreren Stellen hat, sind zuerst Datenverantwortliche und Geschäftsregeln erforderlich.

Bei der Bewertung des Systemintegrators sollten daher konkrete Fragen gestellt werden: Welches System wird die authentische Quelle für die Kundenstammdaten, die Artikelstammdaten, die Preise und den Bestand sein? Wie werden Duplikate behandelt? Was wird automatisch übertragen, was muss von Menschen genehmigt werden, und welche Fälle können nicht übertragen werden?

Die gute Antwort ist nicht, „wir synchronisieren alles“. In vielen Fällen schafft gerade die bidirektionale Synchronisation die späteren Konflikte. Eine gut geplante Lösung weist klare Datenverantwortliche zu und bewegt Informationen nur dort, wo es einen geschäftlichen Grund dafür gibt.

4. Plant er Ausnahmen, Fehler und Rückverfolgbarkeit?

In der Präsentation ist jede Bestellung fehlerfrei, jedes System verfügbar und die Daten perfekt. Im Betrieb hingegen sendet ein Partner eine Datei in einem anderen Format, eine Kurierverbindung fällt zeitweise aus oder eine Bestellung wird nachträglich geändert. Dies sind keine außergewöhnlichen Ereignisse, sondern Teil des Betriebs.

Ein ernsthafter Integrator spricht nicht nur über die erfolgreiche Datenübertragung. Er zeigt, wo ein Fehler sichtbar wird, wer benachrichtigt wird, wie eine Verarbeitung sicher wiederholt werden kann und wann eine menschliche Entscheidung erforderlich ist. Eine wichtige Frage ist auch, ob im Falle eines nachträglichen Streits nachvollziehbar ist: Welche Daten eingegangen sind, wann sie umgewandelt wurden, welches System sie akzeptiert hat und wer sie später geändert hat.

Dies ist besonders wichtig bei finanziellen, Produktions- und Logistikprozessen. Daten, die stillschweigend verloren gehen, sind oft gefährlicher als sichtbare Fehler. Letztere stoppen den Prozess, erstere führen jedoch zu fehlerhaften Rechnungen, falschen Bestandsinformationen oder verspäteter Erfüllung.

5. Ist der Liefer- und Implementierungsplan realistisch?

Ein zu großes, auf einmal eingeführtes Projekt birgt ein erhebliches Geschäftsrisiko. Gleichzeitig kann aus zu kleinen, voneinander unabhängigen Verbesserungen leicht ein unübersichtliches Flickwerk werden. Die richtige Zeitplanung hängt davon ab, wie hoch das Ausfallrisiko ist, wie stabil die aktuellen Systeme sind und wie schnell Ergebnisse erzielt werden müssen.

Ein gutes Zeichen ist, wenn der Partner Phasen vorschlägt, die für sich genommen geschäftlichen Wert bieten. Zuerst wird beispielsweise die zuverlässige Übertragung von Bestelldaten und die Sichtbarkeit von Fehlern umgesetzt, später die Erweiterung der Bestands-, Rechnungs- oder Kundenkommunikationsprozesse. So wird die Organisation nicht erst am Ende eines langen Projekts mit der realen Funktionsweise konfrontiert.

Der Implementierungsplan sollte Tests mit realistischen Daten, geschäftliche Abnahmekriterien, Berechtigungsprüfungen, einen Wiederherstellungsplan und Benutzerschulungen enthalten. Es reicht nicht aus, dass der Entwickler-Test erfolgreich ist. Es muss nachweisbar sein, dass der Prozess auch für die betroffenen Teams korrekt funktioniert.

6. Wem gehört das Wissen und die Betriebsverantwortung?

Viele Unternehmen stützen sich bei kritischen Prozessen auf einen einzigen externen Entwickler oder einen internen Schlüsselmitarbeiter. Solange die Person verfügbar ist, scheint dies oft kein Problem zu sein. Bei Urlaub, Kündigung oder dringendem Fehler stellt sich jedoch heraus, dass niemand weiß, wo und warum eine bestimmte Verbindung läuft.

Bei der Bewertung sollten die Dokumentation, die Betriebsbeschreibungen, die Zugriffsrechte und die Übergabe des Quellcodes geprüft werden. Wer ist berechtigt, Änderungen vorzunehmen? Wo sind die Passwörter und technischen Schlüssel? Wer überwacht den Betrieb? Wie schnell reagiert der Partner auf einen geschäftskritischen Fehler? Dies sind keine administrativen Details, sondern Fragen der Geschäftskontinuität.

Ein langfristiges Partnermodell kann wertvoll sein, insbesondere in komplexen Umgebungen. Aber Abhängigkeit und verantwortungsvoll gestaltete Betriebsbeziehungen sind nicht dasselbe. Das Unternehmen muss die Betriebsrahmen seiner eigenen kritischen Systeme verstehen, auch wenn die täglichen technischen Aufgaben von externen Experten durchgeführt werden.

7. Kann er messbare Ergebnisse liefern?

Nicht jedes Ergebnis ist am ersten Tag monetär messbar, aber jedes Projekt sollte eine geschäftliche Messlatte haben. Dazu kann die Reduzierung der manuell verarbeiteten Bestellungen, die Durchlaufzeit der Rechnungsstellung, der Anteil der Bestandsabweichungen, die Anzahl der fehlerhaften Datenübertragungen oder die Zeit für die Erstellung des wöchentlichen Berichts gehören.

Der Partner muss keine unrealistischen Einsparungen versprechen. Im Gegenteil, ein zu genaues, unbegründetes Versprechen ist eher ein Risiko. Glaubwürdig ist es, wenn gemeinsam der Ausgangszustand, die Zielkennzahlen und die Messung der Veränderung festgelegt werden. So wird der Erfolg des Projekts nicht daran gemessen, dass „die Integration abgeschlossen ist“, sondern daran, dass der Betrieb tatsächlich berechenbarer geworden ist.

8. Wie arbeitet er mit der Geschäfts- und IT-Seite zusammen?

Ein Integrationsprojekt stockt, wenn das Geschäft sagt, „das sollte das System können“, und die IT sagt, „solche Anforderungen standen nicht in der Spezifikation“. Ein guter Partner wählt keine Seite. Er schafft eine gemeinsame Sprache zwischen den Prozessverantwortlichen, den Führungskräften und dem technischen Team.

In der Praxis bedeutet dies regelmäßige Entscheidungspunkte, klare Verantwortlichkeiten und kontrolliertes Änderungsmanagement. Wenn ein neuer Bedarf entsteht, müssen die geschäftlichen Auswirkungen, die Kosten, das Risiko und die Auswirkungen auf den Zeitplan sichtbar sein. So wird die Änderung nicht zum Konflikt, sondern zu einer steuerbaren Entscheidung.

Die Auswahl des richtigen Systemintegrators geht letztlich nicht darum, wer mehr Systeme verbinden kann. Es geht darum, wer hilft, den Betrieb so zu vereinfachen, dass weniger manuelle Übertragungen erforderlich sind, die Verantwortlichkeiten klarer sind und das Management auf verlässlicheren Informationen basieren kann. Bevor Sie Angebote vergleichen, wählen Sie einen wiederkehrend schmerzhaften Prozess aus und verfolgen Sie ihn von Anfang bis Ende. Bereits diese Untersuchung zeigt oft, welche Fragen ein zukünftiger Partner wirklich beantworten muss.

Planning a similar system or integration?

Show us the current process and systems. We will help identify the lowest-risk next step.

Key Takeaways

  • Systemintegratoren sollten sowohl technische als auch geschäftliche Aspekte verstehen.
  • Eine klare Methodik zur Bedarfsermittlung ist entscheidend für fundierte Entscheidungen.
  • Datenqualität und Systemgrenzen müssen sorgfältig gehandhabt werden, um Missverständnisse zu vermeiden.
  • Ausnahmen, Fehler und Nachverfolgbarkeit sollten im Planungsprozess berücksichtigt werden.
  • Ein ausgewogenes Projektmanagement vermeidet sowohl übermäßige Risiken als auch unübersichtliche Flickarbeiten.

Frequently Asked Questions

1. Versteht der Integrator das Problem über die Systemnamen hinaus?

Ein Integrator sollte über APIs, Berechtigungen, Protokollierung und Fehlerbehandlung sprechen können. Ebenso wichtig ist es, die geschäftlichen Konsequenzen zu verstehen.

2. Gibt es eine nachweisbare Methodik zur Bedarfsermittlung?

„Wir ermitteln die Anforderungen“ ist allein keine Methodik. Der Manager muss sehen, welche Entscheidungen am Ende der Ermittlung getroffen werden können. Wird beispielsweise geklärt, welches System die primäre Quelle für bestimmte Daten ist? Werden die aktuellen und zukünftigen Prozesse beschrieben? Werden Ausnahmen, Abhängigkeiten und Risiken sichtbar?

3. Wie wird die Datenqualität und die Systemgrenzen gehandhabt?

Ein häufiges Missverständnis bei Integrationen ist, dass die Verbindung von Systemen die Daten ordnet. Tatsächlich überträgt die Integration nur das, was verfügbar ist. Wenn ein Kunde drei verschiedene Namen, unterschiedliche IDs oder unvollständige Adressen hat, sind zuerst Datenverantwortliche und Geschäftsregeln erforderlich.

Discuss the Specific Requirement

Request an initial proposal or book a 30-minute expert consultation.

Send us an inquiry
Infrastruktur-Governance Infrastruktur-Fallstudien