.svg)
Das Lieferrisiko von Integrationsprojekten für Professional Services
Integration ist unter den Beratungsleistungen insofern ungewöhnlich, als sie Systeme betrifft, die das Unternehmen nicht selbst entwickelt hat, von APIs abhängt, die das Unternehmen nicht kontrolliert, und lange nach Projektabschluss weiter funktionieren muss. Die meisten anderen Professional-Services-Leistungen sind begrenzt: ein Strategiedokument, eine Website, eine Marketingkampagne. Integration ist von Natur aus unbegrenzt. Einmal bereitgestellt, steht und fällt sie damit, ob externe Systeme wie erwartet funktionieren und ob jemand aufpasst, wenn sie es nicht tun.
Dies führt zu Risikomustern, die sich bei Unternehmen immer wieder zeigen. Umfangsschätzungen sind fehlerhaft, weil die „einfache“ Datenstruktur des Kunden undokumentierte Ausnahmen aufweist. Zeitpläne geraten ins Wanken, weil ein Konnektor zwischen zwei Systemen individuell entwickelt werden muss, wenn eine Anbieteränderung einen bestehenden Ansatz unbrauchbar macht. Stabilitätsprobleme treten in der Produktion auf, weil niemand die Fehlermodi getestet hat. Und sechs Monate nach der Übergabe unterbricht ein API-Update die Integration stillschweigend, und der Kunde meldet dies als Serviceausfall statt als anbieterseitige Änderung.
Typische Fehlerquellen bei der Integrationsbereitstellung
Die häufigsten Lieferrisiken sind nicht exotisch. Sie sind vorhersehbar und weitgehend architektonisch bedingt. Das Schätzrisiko entsteht durch die Unterschätzung der Komplexität der tatsächlichen Kundendaten, nicht der zu verbindenden Systeme. Das Entwicklungsrisiko entsteht durch individuellen Code, der auf Annahmen basiert, die nur der ursprüngliche Entwickler vollständig versteht. Das Übergaberisiko entsteht durch die Bereitstellung funktionierender Integrationen, die das Kundenteam nicht sicher warten oder ändern kann. Das Risiko nach dem Launch entsteht durch Änderungen, die das Unternehmen nicht verursacht hat, für deren Behebung es aber verantwortlich gemacht wird.
Jedes dieser Risiken hat dieselbe Grundursache: zu viele Unbekannte, die durch Code zusammengehalten werden, der außerhalb eines gesteuerten Systems existiert. Die Lösung ist nicht besseres Projektmanagement. Es ist ein Liefermodell, bei dem die Unbekannten durch die Architektur selbst reduziert werden.
Wie eine zentralisierte iPaaS das Schätz- und Entwicklungsrisiko reduziert
Wenn Integrationen auf einer Plattform mit vorgetesteten Konnektoren und wiederverwendbaren Transformationsmustern aufgebaut werden, sinkt die Anzahl der Unbekannten bei der Schätzung drastisch. Das Team schätzt nicht „wie lange es dauern wird, eine Verbindung zwischen Shopify und SAP von Grund auf neu aufzubauen“. Sie schätzen: „Wie lange wird es dauern, das Standard-Shopify-SAP-Muster für die spezifischen Feldzuordnungen und Sonderfälle dieses Kunden zu konfigurieren?“ Die Basisschicht ist bekannt, getestet und im gesamten Team verstanden.
Das Entwicklungsrisiko reduziert sich auch, weil die Plattform die Arbeitsbereiche übernimmt, die am ehesten Fehler verursachen: Authentifizierung, Wiederholungslogik, Fehlerbehandlung und Formatübersetzung. Der Aufwand des Teams konzentriert sich auf die kundenspezifische Geschäftslogik, anstatt die Infrastruktur neu aufzubauen. Sonderfälle werden in einer isolierten Transformationsschicht behandelt, oft durch Tools wie Alumios Code Transformer für Fälle, die die visuelle Konfiguration nicht abdecken kann, ohne die Standardvorlage zu beeinträchtigen.
Wie eine gesteuerte Plattform das Übergabe- und Post-Launch-Risiko reduziert
Das Risiko, das Unternehmen kommerziell am meisten schadet, ist das nach dem Launch. Ein erfolgreicher Go-Live, gefolgt von Monaten unbezahlbaren Supports, frisst jede im Projekt einkalkulierte Marge auf. Die Hauptursachen sind Wissensabhängigkeit und mangelnde Transparenz.
Individuelle Integrationen schaffen Wissensabhängigkeit: Die Integration wird nur von dem Entwickler vollständig verstanden, der sie erstellt hat. Verlässt diese Person das Unternehmen, trägt das Unternehmen das Risiko. Eine gesteuerte Integrationsplattform verteilt das Wissen im gesamten Team, da die Konfiguration visuell, dokumentiert und über dieselbe Schnittstelle, auf die jeder zugreifen kann, überprüfbar ist.
Transparenz entsteht durch zentralisiertes Monitoring. Wenn eine Integration bei einer individuellen Entwicklung fehlschlägt, erfährt das Unternehmen dies typischerweise vom Kunden. Wenn sie innerhalb einer gesteuerten Plattform fehlschlägt, sieht das Unternehmen die Warnung, bevor es der Kunde tut. Dieser einzige Unterschied, es vor dem Kunden zu erfahren, ist oft das, was Managed-Service-Verträge, die Margen erhalten, von denen unterscheidet, die stillschweigend Geld verlieren.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
