Zwei Anbieter können die Verbindung desselben CRM, Bestellsystems und Buchhaltungsprogramms anbieten und dabei ganz unterschiedliche Arbeiten meinen. Der eine überträgt neue Bestellungen. Der andere ordnet außerdem Kunden zu, meldet einen Status aus der Buchhaltung zurück, verarbeitet spätere Änderungen und bezieht ältere Datensätze ein.
Beschreiben Sie für einen Vergleich, was mit einer bestimmten Bestellung geschehen soll und wer das Ergebnis prüft. Die Zahl der Anwendungen zeigt, wo die Arbeit stattfindet. Die Regeln zwischen ihnen bestimmen, was gebaut werden muss.
Eine Bestellung durch die Verbindung verfolgen
Stellen Sie sich einen fiktiven Großhändler vor. Der Vertrieb pflegt Kontakte im CRM, Mitarbeitende nehmen Bestellungen im Bestellsystem an und das Finanzteam nutzt ein eigenes Buchhaltungsprogramm. Aus einer angenommenen Bestellung soll ein Belegentwurf entstehen, den das Finanzteam prüft.
Nehmen wir die Bestellung ORD-204. Ihr Kunde hat im CRM die Kennung C-81 und in der Buchhaltung das Konto A-347. Jemand muss festlegen, dass beide Angaben denselben Kunden bezeichnen. Ein Abgleich allein über den Firmennamen lässt die Entscheidung offen, wenn Namen sich ändern oder zwei Einträge ähnlich aussehen.
Legen Sie dann fest, welches System für welche Angabe maßgeblich ist. Das CRM könnte den Namen der Kontaktperson liefern, die Buchhaltung die freigegebenen Rechnungsdaten und das Bestellsystem die angenommenen Mengen und vereinbarten Preise. Das sind mögliche Regeln für dieses Beispiel; jedes Unternehmen muss seine eigenen vereinbaren.
Auch „angenommen“ braucht eine genaue Bedeutung. Wenn der Vertrieb eine Bestellung annimmt, hat das Finanzteam den daraus entstehenden Beleg damit noch nicht freigegeben. Die Dokumentation von Microsoft zu Dynamics 365 Sales veranschaulicht den Unterschied anhand getrennter Phasen für Angebot, Bestellung und Rechnung. Das ist der Ablauf eines bestimmten Produkts. Die Regeln Ihrer Verbindung müssen zu Ihrer Software und Ihren Abläufen passen.
Dieselben drei Systeme, unterschiedlicher Arbeitsumfang
Für den fiktiven Großhändler sind drei mögliche Leistungsumfänge denkbar. Jeder erweitert die Arbeit, die beschrieben, umgesetzt und geprüft werden muss, sofern die eingesetzten Produkte die erforderlichen Schritte unterstützen.
Nur neue Bestellungen
Nachdem Mitarbeitende eine neue Bestellung angenommen haben, werden die vereinbarten Felder und vorhandenen Kundenkennungen an die Buchhaltung gesendet, um einen Entwurf anzulegen. Das Finanzteam prüft ihn dort. Spätere Korrekturen erledigt ein benanntes Team manuell.
Vereinbarte Änderungen und Rückmeldungen
Legen Sie zusätzlich fest, welche späteren Änderungen an Bestellungen übertragen werden dürfen, was nach der Prüfung des Belegs durch das Finanzteam geschieht und welcher Status aus der Buchhaltung an das Bestellsystem zurückgeht. Für ungeklärte Änderungen braucht es eine zuständige Person.
Vorhandene Datensätze einbeziehen
Ergänzen Sie ältere Bestellungen aus einem ausgewählten Zeitraum und zugehörige Kundendatensätze. Ordnen Sie ihre Kennungen zu, beheben Sie vereinbarte Datenprobleme und prüfen Sie die importierten Daten, bevor die laufende Übertragung übernimmt.
Der kleinere Umfang kann ausreichen. Die manuelle Arbeit muss im Angebot sichtbar sein, damit der Käufer beurteilen kann, ob diese Lösung für ihn passt. Bei einem größeren Umfang müssen die zusätzlichen Datenwege und Entscheidungen ausdrücklich beschrieben werden.
Eine Verbindungsskizze erstellen, die ein Anbieter kalkulieren kann
Beginnen Sie mit dem Weg vom Bestellsystem zur Buchhaltung und halten Sie den Auslöser fest: „Eine Bestellung erhält im Bestellsystem den Status angenommen.“ Notieren Sie die Bestellkennung und die Zuordnung der Kundenkennungen. Listen Sie die übertragenen Felder auf und erklären Sie bei Bedarf, wie Mengen, Rabatte, Währung und Status zu verstehen sind. Stimmen Sie die buchhalterische Behandlung mit den dafür zuständigen Personen ab.
Legen Sie die Aktion im Zielsystem fest: einen Entwurf anlegen, einen noch änderbaren Entwurf aktualisieren oder einen Fall an das Finanzteam geben. Benennen Sie, wer ihn freigeben darf. Bestimmen Sie die erwartete Verzögerung und den Zeitpunkt, ab dem Mitarbeitende eine unvollständige Übertragung prüfen sollen. „Regelmäßig“ ist für den Anbieter weniger konkret als eine vereinbarte Frist.
Beschreiben Sie jeden Rückweg einzeln. Eine Belegkennung aus der Buchhaltung zurückzusenden ist eine Aktion. Einen Zahlungsstatus zurückzusenden ist eine andere. Beides bedeutet nicht, dass sämtliche Kundendaten oder Belege in beiden Systemen bearbeitet werden können.
Der Leitfaden von Microsoft zur Übersetzung zwischen Systemen erläutert, warum unterschiedliche Bedeutungen von Daten bewusst berücksichtigt werden müssen und warum Wartung und Überwachung relevant sind. Er beschreibt ein Architekturmuster, das nicht für jede Verbindung vorgeschrieben ist. Für das Angebot zählt, die Übersetzungsarbeit zu benennen, statt bei ähnlich benannten Feldern dieselbe Bedeutung anzunehmen.
Eine brauchbare Beschreibung des Datenwegs für ORD-204 könnte lauten: Für diese angenommene Bestellung anhand der vereinbarten Kundenzuordnung einen Entwurf anlegen, die Kennung aus der Buchhaltung zurückmelden und unvollständige Fälle der zuständigen Person im Finanzteam anzeigen. Das Angebot muss außerdem festlegen, wie wiederholte Benachrichtigungen und ungewisse Ergebnisse behandelt werden. Das ist eine Anforderung, die vereinbart und geprüft werden muss, kein Versprechen, dass jede Übertragung genau einmal erfolgt.
Vereinbaren, wie Mitarbeitende das Ergebnis prüfen
Halten Sie für jeden Datenweg fest, wann er als abgeschlossen gilt. Eine gesendete Nachricht sagt noch nicht, ob der erwartete Entwurf für den richtigen Kunden und mit den richtigen Summen vorhanden ist. Vereinbaren Sie, wie sich die betreffenden Datensätze in Quell- und Zielsystem vergleichen, fehlende oder abweichende Ergebnisse erkennen und die nötigen Kennungen für die Untersuchung finden lassen.
Benennen Sie die Person oder das Team, das eine Ausnahme zuerst erhält, welche Informationen dort sichtbar sind und wer den Quelldatensatz korrigieren oder einen weiteren Versuch erlauben darf. Beispiele sind ein unbekannter Kunde, ein abgelehntes Feld oder eine Korrektur, die nach der Prüfung eintrifft. Entscheiden Sie, welche Fälle Mitarbeitende manuell bearbeiten.
So wird die Verbindungsskizze nutzbar: Auslöser, maßgebliche Datenquellen, Kennungen, Richtung, Feldbedeutungen, Zielaktion, Zeitpunkt, Abschlussprüfung und Zuständigkeit bei Ausnahmen. Ergänzen Sie, wer Testzugänge bereitstellt und bestätigt, dass das Ergebnis passt.
Den Umfang historischer Daten begrenzen
„Alte Bestellungen einbeziehen“ wirft weitere Fragen auf. Wählen Sie Datensatzarten und Zeitraum aus, bestimmen Sie die nötigen zugehörigen Kundendaten und legen Sie fest, wer sie zuordnet und bereinigt. Halten Sie fest, was nach dem Import geprüft wird.
Trennen Sie diese einmalige Arbeit von der laufenden Übertragung. Vereinbaren Sie, wo die historischen Daten enden und die Verarbeitung neuer Vorgänge beginnt. Klären Sie auch, wie Änderungen während dieser Übergabe berücksichtigt werden. Sonst können zwei Anbieter verschieden viel Vorbereitung und Prüfung einkalkulieren, obwohl beide „Datenimport“ anbieten.
Annahmen und laufende Arbeit vergleichen
Lassen Sie jeden Anbieter anhand derselben Verbindungsskizze kalkulieren. Er soll angeben, was zu Produktversionen, erlaubten Aktionen, Berechtigungen, Schnittstellengrenzen und Nutzungsbedingungen der Konnektoren geprüft wurde und was noch offen ist. Eine API-Beschreibung oder das Logo eines Konnektors belegt für sich genommen nicht, dass Ihr Zugang die gewünschte Aktion zulässt.
Wenn ein Zugang fehlt oder eine Regel noch offen ist, fragen Sie, wie diese Unsicherheit geklärt wird und was sie für das Angebot bedeutet. Der britische Regierungsleitfaden Contracting for Agile erörtert, wie unvollständige Informationen geschäftliche Entscheidungen bei öffentlichen Aufträgen beeinflussen. Für diesen Vergleich hilft es, Annahmen sichtbar zu machen, bevor zwei Zusagen als gleichwertig gelten.
Trennen Sie die anfängliche Einrichtung und Prüfung von wiederkehrenden Gebühren für Software oder Konnektoren. Legen Sie dann die vereinbarte Betriebs- und Wartungsarbeit fest: Zugangsdaten verwalten, unvollständige Übertragungen prüfen, Zuordnungen anpassen und Änderungen der Kompatibilität behandeln. Fragen Sie, was enthalten ist, wer es übernimmt und wie spätere Änderungen vereinbart werden. Ein Abonnementposten allein erklärt diese Aufgaben nicht.
Gehen Sie zum Schluss ORD-204 in jedem Angebot durch. Ist erkennbar, was wann ankommt, was bei einem Fehlschlag geschieht und wer den Fall übernimmt? Besprechen Sie jeden Unterschied im Umfang, bevor Sie die Gesamtbeträge vergleichen.
Wenn Sie eine konkrete Verbindung mit LINK-V besprechen möchten, ist unser Angebot zur API-Integration ein passender Ausgangspunkt. Bringen Sie die Datenwege und offenen Fragen mit; Umfang und laufende Betreuung vereinbaren wir für jedes Projekt einzeln.
Fragen zu Integrationsangeboten
Legt ein vorhandener Konnektor den gesamten Umfang fest?
Er kann einen Teil der Übertragung abdecken. Prüfen Sie die konkrete Produktversion, Berechtigungen und unterstützten Aktionen. Vereinbaren Sie dann für Ihre Datenwege Feldbedeutungen, Freigaben, spätere Änderungen und den Umgang mit Ausnahmen.
Warum verändern historische Daten das Angebot?
Ältere Datensätze können das Zuordnen von Kennungen, Bereinigung, zugehörige Datensätze und eine Prüfung erfordern. Bestimmen Sie Datensatzarten und Zeitraum, wer sie vorbereitet und wo der Import an die laufende Übertragung übergeht.
Wer sollte die Verbindung nach dem Start betreuen?
Benennen Sie im Angebot die Verantwortlichen für Zugangsdaten, unvollständige Übertragungen, Änderungen an Zuordnungen und Kompatibilität. Trennen Sie ihre vereinbarte Arbeit von Produktabonnements und halten Sie fest, wie Betreuung und spätere Änderungen geregelt sind.
