Bewertung von Systemintegratoren mit 8 Entscheidungskriterien
Bewertung von Systemintegratoren aus der Sicht der Führungskräfte: So erkennen Sie, ob der Partner die Prozesse wirklich verbessert oder nur zusätzliche Komplexität aufbaut.
Short Answer
Bewertung von Systemintegratoren aus der Sicht der Führungskräfte: So erkennen Sie, ob der Partner die Prozesse wirklich verbessert oder nur zusätzliche Komplexität aufbaut.
Morgens lädt jemand die Bestellungen des Webshops herunter und gibt sie manuell in das Verwaltungssystem ein. Das Lager arbeitet mit einer anderen Tabelle, und der Vertrieb kann nur telefonisch mitteilen, was erfüllt werden kann. Alle Systeme funktionieren – dennoch übernehmen Menschen den Datentransfer 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 bereits im ersten Gespräch eine fertige technologische Antwort gibt, ist Vorsicht geboten. Möglicherweise wird tatsächlich eine ERP-Verbindung, eine individuelle Entwicklung oder eine automatisierte Dokumentenverarbeitung benötigt. Aber zuerst muss geklärt werden, warum der betreffende Prozess so entstanden ist.
Zum Beispiel erfolgt die 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 dieselben Daten von drei verschiedenen Teams gepflegt werden. Wenn eine neue Verbindung dies unverändert nur schneller überträgt, 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. Dies 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, wie die Datenaktualisierung erfolgt. Die geschäftliche Frage hingegen ist, 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 mit eigenen Worten zusammenzufassen. Wenn er nur Werkzeuge und Schnittstellen aufzählt, betrachtet er es wahrscheinlich als Entwicklungsaufgabe. Wenn er über den Prozessverantwortlichen, Entscheidungspunkte, Ausnahmen und messbare Ergebnisse spricht, ist er eher in der Lage, die gesamte Veränderung zu steuern.
2. Hat er eine nachweisbare Methode zur Erhebung?
„Wir erheben die Anforderungen“ ist an sich keine Methodik. Der Leiter muss sehen, welche Entscheidungen am Ende der Erhebung getroffen werden können. Wird zum Beispiel geklärt, welches System die primäre Quelle für die betreffenden 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 Akzeptanzkriterien. Nicht jedes Projekt erfordert den gleichen Detaillierungsgrad. Eine gut dokumentierte Verbindung zwischen zwei Systemen kann weniger Untersuchung erfordern als eine Umgestaltung von Produktions-, Bestands- und Bestelldaten. 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 Ausnahmen zu kennen. Dies ist oft keine Zuversicht, sondern die Vorbereitung auf spätere Änderungswünsche.
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 Kennungen 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 Kundenstamm, Artikelstamm, Preis und Bestand sein? Wie erfolgt die Behandlung von Duplikaten? Was wird automatisch übertragen, was muss von einem Menschen genehmigt werden, und welche Fälle können nicht weitergeleitet 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 für Ausnahmen, Fehler und Rückverfolgbarkeit?
In der Präsentation ist jede Bestellung fehlerfrei, jedes System verfügbar und die Daten sind 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 seriöser 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 bei einem nachträglichen Streit 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 logistischen Prozessen. Daten, die leise verloren gehen, sind oft gefährlicher als sichtbare Fehler. Letztere stoppen den Prozess, während erstere fehlerhafte Rechnungen, falsche Bestandsinformationen oder verspätete Erfüllungen verursachen können.
5. Ist der Liefer- und Einführungsplan realistisch?
Ein zu großes, auf einmal eingeführtes Projekt birgt ein erhebliches Geschäftsrisiko. Gleichzeitig kann eine zu kleine, voneinander unabhängige Verbesserung leicht zu einem unübersichtlichen Flickwerk werden. Der richtige Zeitplan hängt davon ab, wie groß das Risiko eines Betriebsausfalls 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 zum Beispiel die zuverlässige Übertragung der 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 Einführungsplan sollte Tests mit realistischen Daten, geschäftliche Akzeptanzkriterien, Berechtigungsprüfungen, einen Rückfallplan und Benutzerschulungen enthalten. Es reicht nicht aus, dass der Entwicklertest 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 kritische Prozesse auf einen einzigen externen Entwickler oder 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 sollte die Übergabe von Dokumentation, Betriebsbeschreibungen, Zugängen und Quellcode untersucht 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äftsrelevanten 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 eine verantwortungsvoll gestaltete Betriebsbeziehung sind nicht dasselbe. Das Unternehmen muss auch dann die Betriebsrahmen seiner kritischen Systeme verstehen, wenn die täglichen technischen Aufgaben von einem externen Experten durchgeführt werden.
7. Kann er messbare Ergebnisse liefern?
Nicht jedes Ergebnis ist am ersten Tag in Geld messbar, aber jedes Projekt sollte eine geschäftliche Messlatte haben. Dazu gehören die Reduzierung der manuell bearbeiteten Bestellungen, die Durchlaufzeit der Rechnungsstellung, der Anteil der Bestandsabweichungen, die Anzahl der fehlerhaften Datenübertragungen oder die Zeit, die für die Erstellung des wöchentlichen Berichts aufgewendet wird.
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 Projekterfolg 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 gerät ins Stocken, wenn das Geschäft sagt: „Das sollte das System können“, und die IT sagt: „Diese Anforderung war nicht in der Spezifikation enthalten“. 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, Kosten, Risiken 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 dreht sich letztlich nicht darum, wer mehr Systeme verbinden kann. Es geht darum, wer hilft, den Betrieb so zu vereinfachen, dass weniger manuelle Übergaben 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 betrachten Sie ihn von Anfang bis Ende. 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
- Ein Systemintegrator muss sowohl technische als auch geschäftliche Aspekte verstehen.
- Eine fundierte Methodik zur Anforderungserhebung ist entscheidend.
- Datenqualität und Systemgrenzen müssen klar definiert werden.
- Planung für Ausnahmen und Fehler ist ein wesentlicher Bestandteil der Integration.
- Ein ausgewogenes Implementierungstempo minimiert Risiken.
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 für die Anforderungserhebung?
„Wir erheben die Anforderungen“ ist keine Methodik. Führungskräfte müssen sehen, welche Entscheidungen am Ende der Erhebung getroffen werden können. Wird beispielsweise klar, welches System die primäre Datenquelle 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 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 Namen, unterschiedliche IDs oder unvollständige Adressen hat, sind zuerst Datenverantwortliche und Geschäftsregeln erforderlich.
4. Wird für Ausnahmen, Fehler und Rückverfolgbarkeit geplant?
In der Präsentation ist jede Bestellung fehlerfrei, jedes System verfügbar und die Daten perfekt. Im Betrieb sendet jedoch 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.
5. Ist der Liefer- und Implementierungsplan realistisch?
Ein zu großes, auf einmal eingeführtes Projekt birgt erhebliche Geschäftsrisiken. Gleichzeitig kann eine zu kleine, unabhängige Verbesserung schnell zu einem unübersichtlichen Flickwerk werden. Der richtige Zeitplan hängt vom Ausfallrisiko, der Stabilität der aktuellen Systeme und der Geschwindigkeit ab, mit der Ergebnisse erzielt werden müssen.
Related Engineering Insights
API-Gateway oder Punkt-zu-Punkt-Integration für Unternehmen
API-Gateway oder Punkt-zu-Punkt-Integration: Wann hilft die zentrale Steuerung und wann bleibt die direkte Systemverbindung langfristig sinnvoll für Ihr Unternehmen?
Wie verwaltet man Lieferanten-Produktfeeds?
Wie verwaltet man Lieferanten-Produktfeeds so, dass der Webshop, der Bestand und der Verkauf auf denselben geprüften Daten sicher arbeiten können.
Wer ist für die Datenqualität bei der Systemintegration verantwortlich?
Wer ist für die Datenqualität bei der Systemintegration verantwortlich? Die Antwort liegt nicht bei einer einzigen Rolle: Es bedarf klarer Verantwortung, Prozesse und Kontrollen.