Integrieren statt bauen – Ein Leitfaden zur CRM-Integration

Angenommen, Sie arbeiten für ein Startup, das Roboter in allen Branchen verkauft. Sie nehmen Bestellungen von einer Vielzahl von Kunden entgegen, und ein Betriebsteam wertet die Bestellungen aus und arbeitet mit Drittanbietern zusammen, um Ihren Kunden genau den richtigen Roboter zu liefern.

Das Bauen des MVP war stressig, hat aber auch viel Spaß gemacht. Ihre Investoren sind begeistert und überschütten Sie mit Geld. Die nächste Phase beginnt. Sie benötigen mehr Einblick in die Rentabilität und möchten größere Kunden gewinnen, die eine anspruchsvollere Rechnungsstellung benötigen. Gleichzeitig haben Sie eine ziemlich ausgefeilte Produkt-Roadmap, um den Verkauf von margenstärkeren Robotern zu ermöglichen. Die Ressourcen sind knapp, aber Sie müssen trotzdem sicherstellen, dass das Unternehmen am Laufen bleibt.

Wie oft für kleinere Unternehmen gepredigt, ist die Konzentration auf die Dinge, in denen man gut ist, eine gute Faustregel. Aber was ist mit all den Bereichen, die Ihren Unternehmensalltag am Laufen halten? Sie wollen sicherlich kein Customer Relationship Management (CRM)-System oder Buchhaltungssystem aufbauen. Schließlich gibt es viele Produkte, die alle Probleme lösen. Aber wie werden diese Systeme mit Ihrem bestehenden Bestellsystem zusammenarbeiten?

Hier kommt die Integration von Drittanbietern ins Spiel. Lassen Sie uns also eintauchen und sehen, ob wir einige häufige Fallstricke vermeiden können.

CRM-Integration

Unabhängig davon, ob Sie Low-Touch-Verkäufe (Content-Marketing, Social-Media-Anzeigen oder Newsletter) oder High-Touch-Verkäufe (Cold Calling, Teilnahme an Konferenzen oder Nachverfolgung bestehender Kunden per Telefon) durchführen, ein CRM-System kann Ihnen viel bieten Sichtbarkeit darüber, wie es Ihnen bei bestehenden Kunden geht und wie erfolgreich Sie bei der Gewinnung neuer Kunden sind.

Oft wird die Auswahl eines CRM-Systems größtenteils der Vertriebs- und Marketingabteilung überlassen. Im Allgemeinen ist daran nichts auszusetzen. Schließlich wissen diese Menschen am besten, wie sie den Umsatz steigern können, und benötigen die beste verfügbare Unterstützung. Aber auch die beste Software ist nichts wert, wenn sie nicht richtig mit Ihrem Roboter-Bestellsystem zusammenarbeitet.

Beziehen Sie Ihre technische Abteilung in die Entscheidung ein

Egal, ob es sich um den CTO oder einen engagierten Ingenieur handelt, halten Sie sie von Anfang an auf dem Laufenden. Sie werden Ihnen sehr wahrscheinlich mehr Einblick geben, wie die beiden Systeme in Zukunft zusammenarbeiten werden.

Und ein Wort an die Ingenieure: Seien Sie offen gegenüber Lösungen von Drittanbietern. Es ist einfach, diese abzulehnen, weil ihre API nicht die beste oder ihre Benutzeroberfläche hässlich ist. Es kann jedoch sehr lohnend sein, elegante Lösungen rund um bestehende Systeme zu finden.

Dennoch gibt es ein paar Themen, über die man sprechen kann, bevor man eine Entscheidung trifft. Allgemeine Themen wie „Brauchen wir das überhaupt?“ angesprochen werden müssen. Aber es ist auch eine gute Idee, bereits eine Vorstellung davon zu haben, was der Umfang ist. Ist eine bidirektionale Synchronisierung erforderlich oder folgt das Drittanbietersystem einfach dem Bestellsystem? Sobald der Umfang aus dem Weg geräumt ist, muss auch eine technische Diskussion über Implementierungsdetails wie Webhooks oder die Bewertung der API-Limits geführt werden.

Benötigen Sie überhaupt eine benutzerdefinierte Integration?

Wenn es um die Integration geht, ist es nicht verwunderlich, dass es bereits Plattformen gibt, die versprechen, einige der Probleme zu lösen, auf die Sie wahrscheinlich stoßen werden. Derzeit sind Zapier und IFTTT die vielversprechendsten.

Je nachdem, welches Problem Sie lösen möchten, ist Ihr Roboter-Bestellsystem möglicherweise nicht einmal an der Integration beteiligt. Angenommen, Sie verwalten Ihre Newsletter-Abonnenten mit einem CRM-System wie Salesforce oder HubSpot und möchten sie einfach bequemer über einen E-Mail-Dienstleister wie Mailchimp erreichen. Zapier verfügt über unzählige vorhandene Integrationen, die Ihnen dabei helfen. Von diesem Punkt an ist die Wahl eines Anbieters, der über einen Zapier-Konnektor verfügt, ein guter Weg nach vorne.

Und selbst wenn es um die Integration benutzerdefinierter Daten (bestellte Roboter und deren Preis) geht, kann Zapier Webhooks als Vermittler für Ihre Integration fungieren.

Wenn Sie andererseits bereits Daten an Dritte senden, warum senden Sie diese nicht direkt an das CRM-System? Je mehr Daten Sie synchronisieren möchten, desto sinnvoller ist eine direkte Integration.

Was mich zu meinem nächsten Punkt bringt.

Benötigen Sie Zwei-Wege-Synchronisation?

Normalerweise beginnt eine Integration mit einer einfachen Anforderung, wie z. B. Können wir alle unsere Kunden in unser CRM-System bekommen? , typischerweise kombiniert mit den Werten einzelner Roboteraufträge, wodurch die Verwendung von Tools zur Kundensegmentierung vereinfacht wird.

Früher oder später kann es jedoch vorkommen, dass die Leute Kontaktverwaltungstools nutzen möchten, die eine CRM-Suite normalerweise bietet. Dazu gehören Funktionen wie die Deduplizierung, das Ergänzen von Kontaktdaten mit Social-Media-Daten, das Normalisieren von Lieferadressen oder einfach nur das Löschen alter Kontakte.

Das Ändern von Kontakten in einem CRM-System bedeutet höchstwahrscheinlich, dass Sie Kontaktdaten in einem anderen System ändern müssen, dh Änderungen müssen in beide Richtungen erfolgen.

Der Implementierungsaufwand dafür geht weit über eine einfache Einwegsynchronisierung hinaus, daher ist dies ein ausgezeichneter Punkt, um darüber nachzudenken, wie Sie ein neues System strategisch nutzen möchten.

Wie werden Sie über Änderungen aus dem CRM benachrichtigt?

Wenn Sie sich für eine bidirektionale Synchronisierung entscheiden, gibt es eine Folgefrage: Woher wissen Sie, dass sich auf der CRM-Seite etwas geändert hat?

Die meisten Systemanbieter haben dafür Tools, aber das beste für sofortige Änderungen sind Webhooks – im Wesentlichen ein HTTP-Benachrichtigungssystem, das so konfiguriert werden kann, dass es Sie über relevante Änderungen informiert (bei einigen Systemen sogar feldweise). .

Wenn das System keine Webhooks anbietet, überprüfen Sie zumindest, ob Sie eine Liste aller kürzlich aktualisierten Entitäten erhalten können. Auf diese Weise müssen Sie nicht alle Kontakte und Geschäfte durchgehen, nur um Ihre eigenen Daten zu aktualisieren. Beachten Sie jedoch, dass Sie das System in regelmäßigen Abständen abfragen müssen.

In diesem Fall würde sich Ihr Bestellsystem dennoch ändern und Daten über einen API-Aufruf im CRM-System erstellen. Aber alle Änderungen aus dem CRM-System würden in einem definierten Intervall abgefragt.

Zu beachten ist, dass die Updates auf dieses Intervall beschränkt sind und zu vorübergehenden Dateninkonsistenzen führen können. Wenn Sie beispielsweise nur einmal täglich von Ihrem CRM-System zu Ihrem Bestellsystem synchronisieren, können die Daten, die Sie in Ihrem Bestellsystem betrachten, bis zu 24 Stunden alt sein.

Je nachdem, welche Funktionen das System bietet, kann die Integrationsaufgabe in Komplexität und Implementierungszeit variieren. Stellen Sie sicher, dass Sie im Voraus prüfen, was das System bietet, und überprüfen Sie den Plan, den Sie kaufen möchten. Einige CRM-Systeme bieten beispielsweise Webhooks in den höher bezahlten Stufen an.

Ein Beispiel hier ist das CRM von HubSpot, das Webhooks im Allgemeinen anbietet, aber die Webhook-Funktion ist nur in ihrem Enterprise-Paket verfügbar. Die Buchhaltungstools Zoho Books bieten fünf automatisierte Workflows (einschließlich Webhooks) in ihrer niedrigsten Stufe.

Sind Ihre Daten in gutem Zustand?

Bei der Erstellung von Datensätzen in einem Fremdsystem ist es gut zu wissen, wie die Daten im eigenen System aussehen. Glücklicherweise gibt es nicht allzu viele verschiedene Möglichkeiten, Kontakte und Deals zu präsentieren, aber ein Feld, das immer wieder Ärger macht, ist das E-Mail-Feld.

Verschiedene Systeme haben unterschiedliche Vorstellungen davon, was eine gültige E-Mail-Adresse ist, und hier ist eine Spoiler-Warnung – Ihre Kunden haben Ihnen möglicherweise ungültige E-Mail-Adressen aller Art zur Verfügung gestellt. Viele CRM-Systeme lehnen die Erstellung eines Kontakts mit einer ungültigen E-Mail-Adresse ab (und natürlich definiert der CRM-Anbieter, was gültig ist und was nicht).

Tipp: Synchronisieren Sie nach Möglichkeit nur bestätigte E-Mail-Adressen mit Ihrem CRM. Das erspart Ihnen auf lange Sicht viel Schmerz.

API-Einschränkungen

Schließlich müssen API-Einschränkungen so früh wie möglich angegangen werden.

Unter der Annahme, dass es eine API gibt (die im Grunde ein Muss für jede Integration ist), ist es vorteilhaft, sich die Einschränkungen der API anzusehen. Die meisten Startups kommen mit den grundlegenden API-Grenzen der meisten CRM-Systeme zurecht. Beispielsweise bietet HubSpot selbst im kostenlosen Kontingent 250.000 API-Aufrufe pro 24-Stunden-Zeitraum. Andererseits begrenzt es auch Aufrufe auf 10 pro Sekunde (100, wenn Sie OAuth verwenden). Marktführer Salesforce erlaubt nur 100.000 alle 24 Stunden, bietet aber an, mehr zu kaufen.

Meistens fallen Sie leicht unter diese Einschränkungen, aber es gibt eine Sache zu beachten: Was ist mit Ihrem ersten Lauf? Am Anfang werden Sie viele Kontakte und Deals in Ihr CRM schieben (und möglicherweise mehrmals, wenn es Probleme gibt). Infolgedessen erreichen Sie möglicherweise das tägliche API-Limit.

Um dies abzumildern, könnten Sie mit einem kleinen Datensatz testen und die Anzahl während der gesamten Implementierung langsam erhöhen, um innerhalb der API-Grenzen zu bleiben. Planen Sie die anfängliche Migration über mehrere Tage oder an einem Wochenende. Wenden Sie sich alternativ an den Anbieter und teilen Sie ihm Ihre Absichten mit. Wenn Sie sich in der Evaluierungsphase befinden (und noch nicht für das System bezahlt haben), sind sie möglicherweise bereit, Ihre API-Zulage ein wenig zu erhöhen.

CRM-Implementierung

Nehmen wir an, Sie sind sich alle einig. Sie haben sich für ein großartiges CRM-Tool entschieden, und die Ingenieure sind zuversichtlich, dass es ziemlich einfach integriert werden kann. Sie haben sich entschieden, den Umfang so festzulegen, dass nur Kundendaten und akzeptierte Roboterbestellungen übertragen werden. Daher ist keine bidirektionale Synchronisierung erforderlich, und Adressänderungen werden nur in Ihrem eigenen Bestellsystem verarbeitet.

Während der Implementierungsphase müssen noch einige Best Practices befolgt werden.

Probieren Sie alles in einer Testumgebung aus

In den meisten Fällen wird das CRM-System erst verwendet, nachdem Ihre Integration abgeschlossen und einsatzbereit ist. Für diesen Anwendungsfall mag es attraktiv erscheinen, während der Entwicklung nur das Produktionssystem zu verwenden. Schließlich gibt es keine Produktionsdaten, die Sie beeinflussen könnten. Sobald die Entwicklung abgeschlossen ist, entfernen Sie einfach alle von Ihnen erstellten Testdaten, führen eine erste Migration durch und richten Ihr Bestellsystem auf diese Umgebung aus.

Es gibt ein paar Probleme mit diesem Ansatz:

1. Sie treten nur die Dose auf die Straße. Selbst wenn Ihr Go-Live reibungslos verläuft, wird es früher oder später eine Feature-Anfrage geben, um einen Teil Ihrer Integration zu ändern. Da der Funktionswunsch groß genug ist, benötigen Sie wahrscheinlich eine weitere Testphase. An dieser Stelle ist ein separates Prüfsystem unumgänglich; Andernfalls könnten Sie am Ende Produktionsdaten durcheinander bringen. Warum also mit dem Setup warten, bis Sie aufgefordert werden, das erste Feature zu implementieren?

   

2. Sie enden mit einer chaotischen Konfiguration. Es ist sehr wahrscheinlich, dass Ihr CRM-System eine Art Konfiguration benötigt, um den Anforderungen Ihres Bestellsystems gerecht zu werden. Statusnamen müssen möglicherweise angepasst werden, benutzerdefinierte Felder müssen normalerweise erstellt werden und so weiter. Da sich die meisten Entwickler an das CRM-System gewöhnen müssen, wird eine Konfiguration hinzugefügt, die langfristig nicht benötigt wird. In Wirklichkeit wird diese ungenutzte Konfiguration später nicht entfernt und kann sogar für immer in Ihrem CRM verbleiben. Indem Sie den zusätzlichen Schritt der Replikation der Konfiguration vom Testsystem auf das Produktionssystem erzwingen, erhalten Sie höchstwahrscheinlich eine schlankere Konfiguration auf Ihrem Produktionssystem.
   
   Es sollte beachtet werden, dass dies auch zu Ihrem Nachteil sein kann, wenn Sie vergessen, die Konfiguration von Ihrem Test- auf Ihr Produktionssystem zu kopieren, und es zu Produktionsfehlern kommt.
   
   Während es einige CRM-Systeme gibt, die Ihnen helfen, Konfigurationselemente zu vergleichen und zu kopieren, ist es im Allgemeinen nützlich, Ihre Konfigurationen aufzuschreiben, um wichtige Elemente nicht zu vergessen. Die meisten CRMs bieten eine API für ihre Konfiguration, sodass es möglich ist, diesen Schritt zu automatisieren.

3. Sie laufen ein höheres Risiko, Produktionsdaten zu verschmutzen. Stellen Sie sich für eine Sekunde zwei Entwickler vor, die an einer Integration arbeiten. Sie haben bereits ein Staging-System des Roboter-Bestellsystems. Auch diese Bereitstellung ist mit Ihrem CRM verbunden. Sobald Ihre Integration ausgeliefert ist, müssen Sie daran denken, alle drei Systeme zu trennen, da Sie sonst möglicherweise Testdaten in Ihrem (jetzt) ​​Produktions-CRM erstellen.

All diese Probleme können vermieden werden, indem von Anfang an gegen ein Testsystem entwickelt wird. Die Produktion wird erst ganz zum Schluss vorgestellt, kurz bevor alles live geht. Auf diese Weise erhalten Sie am Ende eine saubere Konfiguration, laufen nicht Gefahr, das Trennen lokaler Systeme zu vergessen, und haben eine Vorwarnung bei der Implementierung neuer Funktionen.

Definieren Sie die ID für übereinstimmende Entitäten

Beginnen wir nun mit dem Schreiben des eigentlichen Integrationscodes. Nehmen wir das Beispiel der Synchronisierung von Kontakten mit einem CRM-System. Vermutlich müssen Sie neue Kontakte erstellen und bestehende Kontakte aktualisieren. Um eine Erstellung von einer Aktualisierung zu unterscheiden, müssen Sie die beiden Entitäten verknüpfen. Auf diese Weise können Sie überprüfen, ob der Kontakt in Ihrem System auf dem externen System vorhanden ist.

Während es verlockend erscheint, nur die E-Mail-Adresse zu verwenden (schließlich handelt es sich um eine allgemeine Kennung für einen Kontaktdatensatz), gibt es eine allgemeinere Lösung – für jeden Datensatz synchronisieren Sie mit einem externen System und einer ID in Ihrer eigenen Datenbank.

Ergänzen Sie also Ihre Kontakttabelle mit einer Spalte namens crm_id oder external_id . Dieser Ansatz hat einige Vorteile:

• Da es sich um eine ID handelt, ändert sie sich nicht (im Gegensatz zu einer E-Mail-Adresse oder einer Telefonnummer).
• Sie können sehen, ob Sie die Entität erstellen oder aktualisieren müssen, ohne zuerst einen API-Aufruf durchzuführen (wenn das externe ID-Feld leer ist, können Sie davon ausgehen, dass der Kontakt nicht existiert).

Vor:

Nach dem:

Angenommen, Sie sind ein Ruby on Rails-Entwickler, der an einer Anwendung arbeitet, die bestehende und neue Kunden mit HubSpot synchronisieren muss.

Ein vereinfachtes Codebeispiel könnte so aussehen:

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

Beachten Sie, wie wir das Speichern der von companyId zurückgegebenen companyId nutzen. Es hilft uns nicht nur zu bestimmen, ob wir ein Unternehmen auf HubSpot aktualisieren oder erstellen möchten, sondern wir können auch in der Datenbanktabelle sehen, welche Entitäten bereits mit HubSpot synchronisiert sind und welche noch fehlen.

Wenn es um das Mapping von Feldern geht, gehen Sie Freestyle

Ich habe Projekte gesehen, bei denen vor der Implementierung eine riesige Excel-Tabelle erstellt wurde, in der definiert wurde, welche Spalten wohin im CRM-System gehören, mit Anmerkungen dazu, wie Daten transformiert werden sollten.

In Wirklichkeit gibt es nur wenige Möglichkeiten, Kontakte und Deals darzustellen. Anstatt also viel Zeit damit zu verbringen, darüber nachzudenken, wie genau Sie Karten erstellen möchten, warum beginnen Sie nicht mit einem Experiment? Geben Sie dem Entwickler etwas Raum, um das Mapping herauszufinden, aber bleiben Sie auch in Kontakt, damit frühzeitig Fragen auftauchen können.

Zumindest für die allgemeinen Kontaktfelder (Name, E-Mail-Adresse, Telefonnummer, Adresse) wird das Mapping sehr einfach sein, und Transformationen sind normalerweise trivial.

Wenn es um die Statuszuordnung für Deals geht, ist etwas mehr Kommunikation hilfreich (manchmal heißt der erste Status open , manchmal new , und manchmal stimmt das Statusmodell nicht zu 100 % überein, sodass Sie die Status gruppieren müssen ). Anstatt die perfekte Lösung zu finden, schauen Sie sich Ihre aktuellen Daten an und sehen Sie, wie sie am besten in das Datenmodell des CRM passen würden. Schließlich sind Sie ein agiles Unternehmen, oder?

Im obigen Beispiel sehen Sie eine Kartenmethode, die unser Rails-Modell in einen regulären Hash konvertiert, der von HubSpot verstanden wird. Für diesen speziellen Anwendungsfall ist das einzige synchronisierte Element der Name. Für eine fortgeschrittenere Nutzung möchten Sie wahrscheinlich mehr Felder einbeziehen, aber für ein großartiges Ergebnis beginnen Sie mit einer fundierten Vermutung und sprechen Sie häufig mit der Geschäftsseite, um die Details zu erfahren.

Betrachten Sie Wiederholungen

Kommen wir zur eher technischen Ebene: der Implementierung der eigentlichen Synchronisierung zwischen Ihrem System und dem CRM. Dass die Integration über eine HTTP-Verbindung erfolgt, ist fast schon selbstverständlich. Die meisten Systeme bieten eine HTTP-API, und mit allen Programmiersprachen können Sie ganz einfach HTTP-Aufrufe tätigen.

Leider, egal wie viel Geld Sie für ein CRM-System ausgeben, es wird letztendlich nicht erreichbar sein. Das wird irgendwann passieren und du kannst nichts dagegen tun. Sie können dies also genauso gut berücksichtigen, wenn Sie Ihre Integration entwickeln.

In der Praxis bedeutet dies: Wenn Sie eine API aufrufen, stellen Sie sicher, dass Ihr Aufruf im Falle eines Problems wiederholt wird (500-Statuscode von der anderen Seite). Das Implementieren von Wiederholungen wird normalerweise von Bibliotheken von Drittanbietern der Sprache Ihrer Wahl bereitgestellt.

Zusätzlich zu einem erneuten Versuch sollten Sie in Betracht ziehen, zu protokollieren, was genau passiert ist. Eine Benachrichtigung über einen Fehler zu erhalten, der bereits bei der ersten Wiederholung behoben wurde, kann frustrierend sein.

Anstatt also Ihren Fehlerkanal mit gelösten Problemen zu überfluten, zeichnen Sie alle Callouts mit der Anzahl der Wiederholungen auf, um ein Gefühl dafür zu bekommen, wie zuverlässig das System ist – ein System, für das Sie gerade viel Geld bezahlt haben.

Wenn wir die von uns erstellte Klasse als Beispiel nehmen und im Kontext von Ruby on Rails bleiben, können wir den Aufruf einfach in einen ActiveJob und ziemlich sicher sein, dass der Aufruf schließlich erfolgreich sein wird. Die Methode handle_response bei einem unerwarteten Statuscode einen Fehler aus, und ActiveJob versucht einen erneuten Versuch mit einem exponentiellen Backoff. Für eine fortgeschrittenere Lösung sollten Sie auch 4xx-Statuscodes berücksichtigen, damit ein erneuter Versuch verhindert und stattdessen eine Fehlermeldung ausgegeben wird.

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

Stellen Sie sicher, dass das System tatsächlich verwendet wird

OK, nehmen wir an, Sie haben alles verschickt. Sie sind super stolz auf Ihre Arbeit und das System geht live. Was jetzt? Dies ist erst der Anfang. Denn egal, wie viele Tests Sie durchführen, es wird immer Fehler und gewünschte Änderungen geben.

Das Problem ist, dass Sie davon nichts erfahren, es sei denn, Sie verwenden Ihr System tatsächlich. Und das aus ganz unterschiedlichen Gründen – der Vertrieb ist derzeit zu beschäftigt, um damit zu beginnen, die Strategie wurde geändert oder sogar neue Systeme werden bereits evaluiert.

Um potenzielle Probleme langfristig zu vermeiden, stellen Sie daher sicher, dass Sie alle Hindernisse beseitigt haben, die eine produktive Nutzung des Systems verhindert haben. Kommunizieren Sie häufig zwischen Teams, um neue Anforderungen abzustimmen. Und wenn Sie feststellen, dass das System für Sie einfach nicht funktioniert, schalten Sie die Integration aus. Es klingt hart und kann sehr frustrierend sein, aber es ist weniger frustrierend, als immer Dateninkonsistenzprobleme beheben und sich mit Problemumgehungen befassen zu müssen.

Einpacken

Am Ende ist ein Integrationsprojekt ein verdammt gutes Projekt, und es gibt eine Menge Dinge, die schief gehen können. Es ist aus mehreren Gründen bei Ingenieuren nicht sehr beliebt, aber es kann sich lohnen zu sehen, dass eine Implementierung einen positiven Einfluss auf die Produktivität der Menschen hat, die neben Ihnen sitzen.

Versuchen Sie also für Ingenieure, die Anforderungen eines externen Systems wie eines CRM- oder Rechnungssystems zu verstehen, indem Sie konkrete Fragen stellen wie: Wie wird dieses Produkt Ihr Leben einfacher machen? Haben Sie Konkurrenten in Betracht gezogen? Warum funktionieren sie nicht?

Für alle anderen Beteiligten: Holen Sie die Ingenieure so früh wie möglich ein, vertrauen Sie ihnen, wenn sie rote Linien aufzeigen, und entscheiden Sie sich nicht für einen billigen Plan, wenn Sie sehen, dass die Implementierung der Integration es viel schwieriger machen wird auf lange Sicht.