Zum Hauptinhalt springen
    SystemSelect · Beratung für Software-Auswahl

    30 Min · kostenlos

    Beratung anfragen

    Anfragen →

    CRM & Kundenportal: Umsetzung über einen externen Integrator gesteuert

    Wie ein IT-Refurbisher die Einführung von CRM und Partnerportal kundenseitig steuerte – inklusive Anbindung eines Branchensystems per Partner-API – ohne selbst zu implementieren.

    Auf einen Blick

    Branche
    IT-Refurbishing / ITAD
    Setting
    Mehrere Standorte, mehrsprachig
    Unsere Rolle
    Auswahl + kundenseitiges PMO
    Umsetzung durch
    Externer Integrator

    Ausgangslage

    Das Unternehmen wollte seinen Geschäftskunden ein Partner-/Kundenportal bieten: Aufträge einsehen, Nachweise abrufen, Stammdaten pflegen. Das Portal war als Erstes gedacht – doch ohne ein tragfähiges CRM darunter drohte eine Insellösung mit doppelter Datenpflege. Die Umsetzung sollte ein externer Integrator übernehmen. Was fehlte, war eine Steuerungsinstanz auf Kundenseite, die Scope, Datenhoheit und Integrationsrahmen absichert.

    Vorhaben
    Ein Partner-/Kundenportal für mehrere hundert Geschäftskunden sollte auf einem noch nicht final gewählten CRM aufsetzen
    Reihenfolge-Risiko
    Das Portal war als Erstes gedacht – drohte aber zur Insellösung neben einem CRM zu werden, das die Datenbasis nicht tragen konnte
    Branchensystem
    Abholaufträge, Löschnachweise und Stammdaten lagen in einem Branchensystem mit dokumentierter Partner-API – anzubinden statt nachzubauen
    Umsetzung extern
    Implementierung von CRM und Portal sollte über einen spezialisierten Integrator laufen – ohne kundenseitige Steuerungsinstanz
    Mehrsprachigkeit
    Portal- und CRM-Oberflächen für mehrere Länder und Sprachen, mit differenzierten Rechten je externem Nutzer

    Warum kundenseitige Steuerung den Unterschied machte

    • Die eigentliche Weichenstellung lag vor der Umsetzung: Erst wurde das CRM als tragfähiges Fundament für das Portal bestimmt – sonst wäre jede Implementierungsstunde in eine Insellösung geflossen.
    • Die Anbindung des Branchensystems über dessen Partner-API war der technische Dreh- und Angelpunkt. Wir haben die API-Spezifikation ausgewertet und dem Integrator einen klaren Anbindungsrahmen vorgegeben – statt ihn selbst explorieren zu lassen.
    • Weil wir weder das CRM noch das Portal selbst gebaut haben, konnten wir den Integrator gegen einen sauber definierten Scope steuern – und die Datenhoheit beim Kunden halten.

    Vorgehen: von der Weichenstellung bis zur Übergabe

    01Weichenstellung: Plattform vor Portal (Woche 1–4)

    • Anforderungen aus Fachbereichen, IT und Geschäftsführung konsolidiert – Portal- und CRM-Anforderungen getrennt gewichtet
    • Kernprämisse festgehalten: CRM und Portal auf einer Datenbasis, kein separat gebautes Portal daneben
    • Longlist gegen harte Muss-Kriterien geprüft: externe-Nutzer-Lizenzmodell, natives Portal, delegierte Administration, Self-Hosting/Compliance, Mehrsprachigkeit
    • Entscheidungsvorlage für die Geschäftsführung mit klarer Plattform-Empfehlung und dokumentierten Alternativen

    02Integrations-Rahmen & Partner-API (Woche 3–7)

    • Partner-API des Branchensystems ausgewertet: verfügbare Datengruppen (Aufträge, Nachweise, Stammdaten), Authentifizierung, Aktualisierungslogik
    • Anbindungskonzept definiert: Polling-Intervalle, Token-Handling, Nacht-Synchronisation – als verbindliche Vorgabe an den Integrator
    • Nebenbefund aus der API-Analyse (offen erreichbare interne Dokumentation) diskret an den Systemhersteller zurückgemeldet
    • Datenhoheit und DSGVO-Rollenmodell vorab geklärt, bevor die erste Zeile Integration gebaut wurde

    03Integrator-Steuerung in der Umsetzung (Woche 6–20)

    • Backlog gegen den Anforderungskatalog geführt, Sprints und Abnahmen kundenseitig gesteuert
    • Change Requests neutral bewertet – was Bring-Schuld war, wurde nicht zusätzlich abgerechnet
    • Portal-Deep-Dives in jedem Abnahme-Zyklus: Rechte-/Rollenmodell, Dokumentenfreigabe, Mandantentrennung mit echten Daten geprüft, nicht auf Folien
    • Wöchentlicher Lenkungsausschuss mit Integrator, Fachbereich und IT auf gemeinsamer Faktenbasis

    04Portal-Rollout & Kunden-Onboarding (Woche 18–28)

    • Migration von Kunden-, Kontakt- und Vertragsdaten kundenseitig abgenommen, in Testläufen validiert
    • Rechte-/Rollenmodell verifiziert: jeder externe Nutzer sieht ausschließlich die eigenen Aufträge, Nachweise und Stammdaten
    • Kunden-Onboarding in Wellen, gestaffelt nach Land und Sprache, mit Kurzanleitungen
    • Adoptions- und Fehler-Monitoring als Steuerungsgröße im Lenkungsausschuss

    05Hypercare & Übergabe (Woche 26–32)

    • Strukturierte Stabilisierung nach Go-Live, priorisierte Fehlerliste mit klarer Zuordnung Integrator vs. Anwendung
    • Restleistungen gegen Abnahmekriterien final abgenommen, offene Punkte in eine Phase 2 überführt
    • Übergabe der laufenden Steuerung an einen internen Portal-/CRM-Owner inkl. Dokumentation und API-Betriebsleitfaden

    Ergebnisse

    1 Datenbasis
    statt Insellösung
    CRM und Portal laufen auf einer Plattform – keine doppelte Datenpflege
    API statt Nachbau
    Branchensystem angebunden
    Aufträge, Nachweise und Stammdaten fließen über die Partner-API ins Portal
    Mehrsprachig
    Länder & Sprachen live
    differenzierte Rechte je externem Nutzer, mandantensicher
    0
    eigene Implementierung
    wir haben gesteuert und abgenommen – gebaut hat der Integrator

    Qualitative Ergebnisse

    • +Die Reihenfolge stimmte: Erst die Plattform, dann das Portal – keine teure Insellösung, die später hätte ersetzt werden müssen
    • +Der Integrator baute gegen einen klaren Integrations- und Anforderungsrahmen statt gegen eine sich bewegende Zielscheibe
    • +Die Datenhoheit blieb durchgehend beim Kunden – Rechte-/Rollenmodell und Mandantentrennung wurden mit echten Daten abgenommen
    • +Ein interner Owner übernahm nach Hypercare eine dokumentierte Plattform inklusive API-Betriebsleitfaden