In einer Beratung existiert derselbe Kunde gleichzeitig im CRM, im Angebotstool, im Finanzsystem, im Kalender eines Beraters und im Identitätsverzeichnis. Jedes Werkzeug kennt diesen Kunden ein wenig anders, unter einer anderen Kennung und mit einem anderen Satz Felder. Solange die Systeme nicht miteinander sprechen, tippen Berater Daten von Hand ab und der Entscheider bekommt nie ein glaubwürdiges Bild eines Projekts. Das ist kein Problem eines einzelnen Werkzeugs, sondern eine fehlende Integrationsschicht.
Aus unserer Erfahrung in Individualsoftware und Integrationen wissen wir: Die Schwierigkeit liegt nicht darin, eine API anzubinden, sondern darin, Daten über ein Dutzend Systeme hinweg über Jahre konsistent zu halten. Auch wenn wir keine Einführung in genau Ihrer Umgebung geliefert haben, stellen wir Menschen und Kompetenzen bereit, die solche Integrationen entwerfen und pflegen - als Team-Verstärkung oder als Individualsoftware-Projekt.
Warum ist die Integration der Systeme einer Beratung so schwierig?
Die Schwierigkeit ist nicht ein einzelner Konnektor, sondern die Natur einer Professional-Services-Organisation. Eine Beratung kauft in jeder Kategorie das beste Werkzeug: ein eigenes CRM, ein eigenes Angebotstool, ein eigenes Finanzsystem, ein eigenes für Zeit und Abrechnung. Jedes hat sein eigenes Datenmodell und eine API unterschiedlicher Reife, sodass derselbe Kunde und dasselbe Projekt in jedem System eine andere Kennung tragen und sich die Regeln widersprechen können. Dazu kommt der Druck durch Vertraulichkeit und Prüfbarkeit. Deshalb entwerfen wir die Integration nie als Skript für eine Nacht, sondern als gesteuerten Ablauf: mit Ereignisprotokoll, Fehlerbehandlung und klarer Synchronisationsrichtung.
Wie integrieren Sie das CRM mit Angebotstools?
Das ist meist der erste und lohnendste Ablauf, denn er berührt Geld und die tägliche Vertriebsarbeit. Wir verbinden das CRM so mit Angebotstools, dass nichts zweimal eingegeben wird:
- eine Opportunity im CRM speist das Angebot mit Kundendaten, Umfang und Team, ohne manuelles Abtippen,
- der Angebotsstatus fließt ins CRM zurück (versendet, geöffnet, angenommen), sodass die Vertriebsprognose aktuell bleibt,
- ein angenommenes Angebot eröffnet ein Projekt im Delivery- und Abrechnungssystem,
- die Inhalts- und Satzbibliothek bleibt eine einzige Quelle.
Entscheidend ist hier die Regel, dass eine Opportunity im CRM eine Einheit ist, während die Angebotsversionen ihre Historie sind.
Wie verbinden Sie Systeme mit Finanzen und ERP?
Die Integration mit Finanzen und ERP ist heikler, denn hier wird aus einem Datenfehler ein Rechnungsfehler. Wir behandeln sie deshalb anders als Marketing-Integrationen: mit Validierung und der Prüfung, ob Beträge, Währungen und Perioden auf beiden Seiten übereinstimmen. Ein im CRM gewonnenes Projekt muss das richtige Objekt im ERP erzeugen, und Stunden aus der Zeiterfassung müssen die Abrechnung erreichen, ohne manuellen Export in eine Tabelle.
Meist binden wir uns an ein bestehendes ERP an, statt es zu ersetzen, unsere Rolle ist also der Bau einer verlässlichen, prüfbaren Brücke zwischen Vertrieb, Delivery und Buchhaltung. Arbeitet die ERP-API in Stapeln, ergänzen wir eine Zwischenschicht mit Warteschlange und Wiederholversuchen.
Wie integrieren Sie Kalender und Werkzeuge der Zusammenarbeit?
Die Zeit eines Beraters ist das Produkt einer Beratung, deshalb lohnt es, Kalender und Werkzeuge der Zusammenarbeit an das übrige Ökosystem anzubinden. Meist tun wir Folgendes:
- wir synchronisieren Kalender (Microsoft 365, Google Workspace) mit dem Projekt- und Auslastungssystem,
- wir binden Messenger (z. B. Teams, Slack) an Benachrichtigungen über Statusänderungen von Projekten oder Angeboten an,
- wir verknüpfen Dokumentenräume mit dem Kunden- und Projektdatensatz, damit Dateien Kontext tragen.
Am wichtigsten ist hier Zurückhaltung: Die Integration soll Klicks sparen und im richtigen Moment erinnern, nicht Menschen in Benachrichtigungen ertränken.
Wie führen Sie Single Sign-on ein und verwalten Identität (SSO/SCIM)?
Single Sign-on und Identität sind ein Fundament, das sich früh zu legen lohnt, denn es berührt der Reihe nach jedes System. Statt getrennter Konten in einem Dutzend Werkzeugen bauen wir eine Identität und eine Anmeldung:
- SSO (SAML oder OpenID Connect) mit einem zentralen Verzeichnis (z. B. Entra ID, Okta) als eine Tür in alle Werkzeuge,
- SCIM für das automatische Anlegen, Aktualisieren und Deaktivieren von Konten, wenn jemand kommt, die Rolle wechselt oder geht,
- Abbildung von Rollen und Gruppen auf Berechtigungen in jedem System, einheitlich und prüfbar.
In einer Beratung, in der Menschen zwischen Projekten wechseln, ist automatisches Provisioning und Deprovisioning keine Bequemlichkeit, sondern eine Sicherheitsanforderung.
Welche Integrationsschicht wählen Sie: APIs, Webhooks, iPaaS, Warteschlangen?
Es gibt keine einzig richtige Technologie, nur die Passung von Werkzeug und Ablauf. Wir prüfen, ob Daten in Echtzeit oder in Stapeln wandern sollen und wie kritisch es ist, dass nichts verloren geht:
- APIs und Webhooks dort, wo eine nahezu sofortige Reaktion zählt (eine Statusänderung, ein neuer Datensatz),
- iPaaS (z. B. Low-Code-Integrationsplattformen) für typische Verbindungen zwischen verbreiteten Systemen,
- Warteschlangen und Message Broker dort, wo Systeme entkoppelt sein und kurze Ausfälle des jeweils anderen überstehen müssen,
- eigene Integrations-Microservices dort, wo die Logik ungewöhnlich ist.
Meist mischen wir diese Ansätze: iPaaS übernimmt einfache Abläufe, und unser Team ergänzt eigenen Code und Warteschlangen dort, wo die Regeln für einen fertigen Konnektor zu speziell sind.
Wie halten Sie Stammdaten konsistent (Kunde, Projekt, Person)?
Das ist der Kern des Puzzles. Ohne Einigkeit darüber, was ein Kunde, ein Projekt und eine Person ist, verbreitet jede Integration inkonsistente Daten nur schneller. Bevor wir etwas verbinden, legen wir deshalb fest, welches System für jedes Objekt und jedes Feld die Quelle der Wahrheit ist und wie eine gemeinsame Kennung entsteht und wandert. In der Praxis heißt das, ein Vokabular zu vereinbaren (wann ein Kunde aktiv ist, wann ein Projekt geschlossen ist), Regeln zur Dublettenbereinigung und eine Synchronisationsrichtung für jedes Feld einzeln.
Manchmal führen wir eine leichte Stammdatenschicht als Schiedsrichter ein. Das ist der weniger glanzvolle Teil des Projekts als eine glänzende Integration, aber er entscheidet darüber, ob einem Managementbericht überhaupt zu trauen ist.
Welche Kompetenzen stellen wir für ein Integrationsprojekt bereit?
Wir stellen das Team rund um Ihre konkrete Systemlandschaft zusammen, nicht „auf Vorrat”. Wir besetzen Rollen wie:
- einen Integrationsarchitekten, der Abläufe, API-Verträge und die Stammdatenschicht entwirft,
- einen Backend- / Integrationsentwickler, der Konnektoren, Microservices und die Verarbeitung von Warteschlangen baut,
- einen Identitätsspezialisten, der SSO, SCIM und die Rollenabbildung umsetzt,
- einen Data Engineer, der Konsistenz, Mappings und Migrationen verantwortet,
- einen DevOps-Engineer, der Deployments, Monitoring und Fehlerbehandlung baut.
Unsere AI- und Daten-Kompetenz ist real, deshalb ergänzen wir dort, wo es sinnvoll ist, einen intelligenten Abgleich von Datensätzen oder eine Anomalieerkennung in den Abläufen.
Wie machen wir das bei RITS?
Wir tun es als Nearshore-Partner aus Polen, mit Erfahrung in Individualsoftware und Systemintegration:
- wir beginnen mit einer Karte der Systeme und Stammdaten, bevor der erste Konnektor entsteht,
- wir prüfen die Kompetenzen vor dem Start und stellen das Team rund um Ihre Werkzeuglandschaft zusammen,
- in einer nahen Zeitzone nehmen wir ohne langen Anlauf an Code-Reviews und Terminen teil,
- wir entwerfen Integrationen als gesteuerte, prüfbare Abläufe und nicht als Skripte für eine Nacht.
Meist liefern wir das als Individualsoftware, gebaut von unserem Team, und dort, wo Kompetenzen schnell aufzustocken sind, als Team-Verstärkung.
Wo beginnen Sie mit der Integration der Systeme einer Beratung?
Beginnen Sie mit dem schmerzhaftesten einzelnen Ablauf (meist CRM zum Angebotstool oder Projekt zu Finanzen) und mit der Frage, welches System die Quelle der Wahrheit für Kunde, Projekt und Person ist. Das legt Umfang, Technologie der Integrationsschicht und die nötigen Rollen fest. Parallel lohnt es, die Identität zu legen (SSO und SCIM). Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie integrieren CRM, ERP, Kalender und Identität in einer Beratung? Sprechen wir darüber - wir finden ein Team und eine Architektur passend zu Ihrer Systemlandschaft.