Kundeninformationssysteme: Fallstudie aus der Rüstungsindustrie im Nahen Osten

Dies ist eine Fallstudie darüber, wie ein mittelgroßer Rüstungshersteller im Nahen Osten seine Kundeninformationssysteme in Ordnung brachte. Kundendaten lagen an drei Stellen, Angebote gingen mit uneinheitlichen Preisen hinaus, und Freigaben gingen in E-Mails verloren. Die Lösung war ein einziger Kundendatensatz in Microsoft Dynamics, regelbasierte Angebotserstellung in Experlogix CPQ und eine automatisierte Übergabe freigegebener Angebote an SAP Sales and Distribution (SD) über SAP Cloud Integration. Die Angebotsdurchlaufzeit sank im Schnitt um 35 %. Die Fallstudie richtet sich an Verantwortliche für Sales Operations, IT und Finanzen in Fertigungsunternehmen mit langen, konfigurierbaren und compliance-lastigen Vertriebszyklen. Zum Wiederverwenden eignen sich vor allem die Einführungsabfolge und die Erkenntnisse am Ende.

Wenn Teams in der Rüstungsindustrie nach Kundeninformationssystemen fragen, meinen sie meist mehr als ein CRM. Sie wollen Struktur: einen Ort, an dem komplexe Entscheidungen im Kontext zusammenliegen, über lange Vertriebszyklen, compliance-lastige Abläufe und wechselnde Entscheidergruppen hinweg.

In meiner Rolle als Digital Transformation Director bei einem Rüstungsunternehmen sollte ich genau das lösen. Das Problem war nicht fehlender Einsatz. Die Leute leisteten die Arbeit. Das Problem war, dass der Aufwand kein Zuhause hatte. Keine gemeinsame Plattform, keine Transparenz und keine Abstimmung zwischen dem, was verkauft, und dem, was geplant wurde.

Ein mittelgroßer Rüstungshersteller im Nahen Osten. Er arbeitete im Hintergrund: keine öffentliche Marke, und Sichtbarkeit war nicht das Ziel. Seine Komponenten kamen in der Militärluftfahrt und in sicherer Kommunikation zum Einsatz.

Jeder Verkauf folgte einem detaillierten Weg: technische Prüfungen durch das Engineering, Compliance-Prüfungen, interne Freigaben, versionierte Angebote. Chaotisch war das nicht, aber schwerfällig.

Die Kundeninformationssysteme zerfielen. Der Vertrieb nutzte eine Plattform. Der Support eine andere. Der Betrieb arbeitete mit Tabellen, Offline-Ordnern und Dokumenten, die veraltet waren, bevor sie jemand öffnete.

Das war kaputt, und das hat es gekostet:

Was kaputt war	Auswirkung
Kein CRM für den Verlauf von Verkaufschancen und keine Sicht auf die Entscheider	Kein gemeinsames Bild davon, wo jedes Geschäft stand
Preise wurden manuell gepflegt, ohne einheitliche Aufzeichnung	Angebote gingen mit veralteten oder widersprüchlichen Zahlen hinaus
Freigaben per E-Mail, oft verloren oder verzögert	Compliance-Prüfpfade waren lückenhaft
Kundendatensätze in mehreren Systemen doppelt vorhanden, mit leicht abweichenden Angaben	Niemand konnte sagen, welche Version stimmte

Auf dem Papier sah es strukturiert aus. Verfolgte man ein Angebot von der Erstellung bis zur Lieferung, fiel es auseinander. Freigaben blieben ohne klare Zuständigkeit liegen. Die Preise hingen davon ab, wer das Angebot einreichte. Angebote vergruben sich in E-Mail-Verläufen. Die Teams stellten einander immer wieder dieselben Fragen. Nichts davon war ein dramatisches Versagen, aber über Monate summierten sich die kleinen Verzögerungen, und für ein Geschäft mit langen Vertriebszyklen wog der verlorene Schwung schwerer, als die meisten ahnten.

Das Ziel war nicht, alles zu ersetzen. Es ging darum, Reibung abzubauen, ohne etwas schwerer bedienbar zu machen: Die Systeme sollten abbilden, wie die Teams ohnehin arbeiteten, und die Leute nicht in starre Prozesse zwingen.

Ich verbrachte Zeit mit den Teams, bevor ich irgendeine Konfiguration anfasste. Ich beobachtete, wie die Arbeit von der Erfassung bis zur Lieferung lief, wo die Werkzeuge im Weg standen und wo die Leute den Daten nicht mehr trauten.

Aus diesen Sitzungen ergaben sich drei Prioritäten:

1. Ein gemeinsamer Kundendatensatz, für Vertrieb, Support und Betrieb im selben Format sichtbar. Keine parallelen Versionen mehr.
2. Strukturierte Angebotserstellung nach einheitlichen Regeln für Konfiguration und Preise statt nach individuellen Gewohnheiten und alten Vorlagen.
3. Verbundene Auftragsabwicklung mit einer sauberen Übergabe vom freigegebenen Angebot an SAP SD und ohne manuelle Neuerfassung.

System	Was es löste
Microsoft Dynamics CRM	Ein Kundendatensatz, verknüpft mit Vertriebsaktivitäten und Verkaufschancen
Experlogix Configure Price Quote (CPQ)	Konfigurationsregeln für Produkte, Preislogik, Angebotsversionen
SAP Sales and Distribution (SD)	Auftragsabwicklung und Lieferung
SAP Cloud Integration (CPI)	Integrationsschicht, die CPQ und CRM mit SAP SD verbindet

Microsoft Dynamics als Fundament. Wir brauchten einen Ort, an dem Kundeninformationen korrekt und im vollen Kontext sichtbar waren. Dynamics bot uns einen Ausgangspunkt, um die Daten zu entwirren. Die Vertrautheit mit der Plattform half, ebenso das Zusammenspiel mit Outlook und Teams. Die Leute mussten nicht bei null anfangen; es brauchte Anpassungen, damit es zur Arbeitsweise des Unternehmens passte. Sobald die Teams funktionsübergreifend dieselben Daten im selben Format sahen, begann das Vertrauen zu wachsen.

Experlogix CPQ für Konfiguration und Preise. Vorher wurden Angebote auf zu viele verschiedene Arten erstellt. Die Leute verließen sich auf ihr Gedächtnis und manuelle Änderungen. Wir richteten Experlogix mit definierten Regeln für Produktkombinationen ein, mit Preisen, die an Konfigurationen gebunden waren, und mit einer Freigaberoutung nach Geschäftsart und Wert. Anfangs fühlte sich das einschränkend an, und manche sagten das auch deutlich, aber es beseitigte die Mehrdeutigkeit. Das Engineering bekam sauberere Angebote, und der Vertrieb hörte auf, Preise aus der Erinnerung an frühere Geschäfte anzupassen.

SAP SD über SAP CPI. SAP SD war für Aufträge bereits im Einsatz. Die Lücke lag in der Übergabe: Ein freigegebenes Angebot musste noch von Hand in SAP erfasst werden. Wir verbanden beide über SAP CPI, sodass freigegebene Angebote direkt als Aufträge in SAP landeten und Kunden- und Auftragsdaten zwischen Dynamics und SAP synchron blieben. Wo wir an Grenzen stießen, ergänzten wir eigene Logik. Elegant war das nicht in jedem Fall, aber es funktionierte.

1. 01KundendatensatzMicrosoft Dynamics, eine Version für alle Teams
2. 02Konfigurieren und Preise ermittelnRegeln in Experlogix CPQ für Kombinationen und Preise
3. 03FreigebenGeleitet nach Geschäftsart und Wert
4. 04Auftrag anlegenSAP CPI überträgt das freigegebene Angebot nach SAP SD
5. 05LiefernSAP SD, Kundendaten bleiben synchron

Keine Neuerfassung und ein Prüfpfad von der Freigabe bis zum Auftrag

Die Einführung verlief in Phasen über etwa sechs bis acht Monate. Nichts Dramatisches: aufeinander aufbauende Änderungen, bei jedem Schritt validiert.

1. Pilot. Eine kleine Nutzergruppe und ausgewählte Szenarien rund um CRM und CPQ. Wir testeten Randfälle, deckten Lücken auf und nahmen Änderungen vor, bevor wir skalierten.
2. Daten bereinigen. Kundendatensätze wurden konsolidiert und dedupliziert, bevor sie in Dynamics kamen, und Compliance-Dokumente wurden den richtigen Verkaufschancen zugeordnet. Das dauerte länger als die Konfiguration.
3. Auf die Abteilungen ausweiten. Sobald die Pilot-Workflows verfeinert waren, ging die Lösung an Vertrieb, Support und Betrieb.
4. SAP SD zur Halbzeit anbinden. Die Integration von CPQ zu SAP ging live, sobald die vorgelagerten Systeme stabil waren, damit frühe Probleme nicht in die Aufträge durchschlugen.

Sicherheit und Compliance wurden von Anfang an mitgeplant. Für einen Kunden aus der Rüstung sind die Integrität der Prüfpfade und rollenbasierter Zugriff nicht verhandelbar. Wir definierten die Zugriffsrollen klar und verfolgten die Freigabepfade nach. Die Datenresidenz wurde früh geklärt: Alle Daten blieben innerhalb der Vereinigten Arabischen Emirate (VAE), entsprechend den Vorschriften der Verteidigungsbranche. Das bremste uns anfangs leicht, und es ersparte uns später ernstere Probleme.

Die Schulung war praxisnah: kurze Einheiten, gezielte Unterlagen, Live-Demonstrationen und Anleitungsvideos, über Wochen und Monate verteilt statt in einer einzigen Sitzung. Die Akzeptanz war anfangs nicht perfekt. Stetige Unterstützung und sichtbarer Nutzen überwanden das anfängliche Zögern. Der Wendepunkt kam, als die Teams die Werkzeuge in echten Situationen nutzten und feststellten, dass die Daten, die sie zurückbekamen, stimmten.

Ergebnis	Was sich änderte
Durchlaufzeit für Angebote	Im Schnitt um 35 % gesunken; bei vielen Geschäften Stunden gespart, bei komplexen mehrere Tage
Konfigurationsgenauigkeit	Validierungsregeln verhinderten Fehler, bevor sie das Engineering erreichten
Audit-Bereitschaft	Compliance-Prüfungen brauchten keine Hektik in letzter Minute mehr
Teamübergreifende Abstimmung	Vertrieb, Support und Betrieb arbeiteten mit demselben Kundendatensatz

Die Verkürzung um 35 % trat nicht in der ersten Woche ein. In den ersten Zyklen gab es noch Rückfragen und Korrekturen. Sobald Produktregeln und Preislogik einheitlich waren, wurde die Angebotserstellung schneller. Vertriebsmitarbeiter jagten keinen Freigaben mehr hinterher und korrigierten keine wiederverwendeten Vorlagen. Das System übernahm diese Schritte.

Abstimmung zählt mehr als Technik. Der technische Aufbau war der leichtere Teil. Schwerer war es, die Teams dazu zu bringen, einer einzigen Wahrheitsquelle zu vertrauen und ihre eigenen Aufzeichnungen nicht mehr zu pflegen. Das hieß, den Leuten zu zeigen, dass die Daten verlässlich waren, bevor man von ihnen verlangte, sich darauf zu stützen.

Integrationsdetails zählen mehr als Funktionen. Die Integration von CPQ zu SAP SD machte das ganze System wertvoll. Ein einzelnes CRM und eine einzelne Angebotslösung mit manueller Auftragserfassung hätten jeweils ein wenig geholfen. In der Verbindung zwischen ihnen verschwand die Reibung.

Betreuung und Schulung sorgen dafür, dass es hält. Eingeführt und sich selbst überlassen ist nicht geliefert. Die Schulung lief nach dem Go-live Wochen und Monate weiter, und in dieser Phase entscheidet sich, ob die Akzeptanz Wurzeln schlägt oder zerfällt.

Die Architektur trägt weiterhin: CRM für den Kundendatensatz, CPQ für strukturierte Angebote, ERP-Integration für die Auftragsabwicklung. Drei Dinge würden sich ändern, wenn dasselbe Projekt heute begänne.

Die Integrationsplattform. SAP CPI ist heute die Funktion Cloud Integration innerhalb der SAP Integration Suite, neben API-Management, ereignisbasierter Integration und vorgefertigten Integrationsinhalten. Ein Ablauf von Dynamics über CPQ zu SAP SD würde heute weniger Designzeit kosten. Mein Leitfaden zu SAP Cloud Integration behandelt die Plattform.

Das CRM von SAP selbst käme auf die Shortlist. Bei einem SAP-SD-Backend sollte ein neues Projekt SAP Sales Cloud, das inzwischen Joule enthält, mit Microsoft Dynamics vergleichen. Dynamics war hier wegen der vorhandenen Vertrautheit die richtige Wahl. Die Antwort hängt weiterhin von Funktionsumfang und Integrationspräferenzen ab, aber die SAP-native Option ist ein glaubwürdigerer Kandidat als früher. Mein Vergleich von CRM-Systemen für SAP behandelt die Optionen.

Der US-Bundesbereich braucht ein anderes Hosting-Modell. Dieser Kunde brauchte es nicht, aber ein Rüstungsunternehmen mit Aktivitäten im US-Bundesbereich würde SAP National Security Services (SAP NS2) prüfen. 2025 erhielt SAP NS2 eine vorläufige Autorisierung, S/4HANA Cloud Private Edition und SAP BTP auf FedRAMP+ Impact Level 5 zu betreiben, mit ausschließlich US-basiertem Betrieb.

Die spezifischen Anforderungen der Rüstungsbranche (Prüfpfade, rollenbasierter Zugriff, Versionskontrolle bei Angeboten, Datenresidenz) gelten unabhängig von der Plattformgeneration. Das größere Compliance-Bild finden Sie in meinem Leitfaden zu SAP-Compliance im öffentlichen Sektor.

Warum wurde Microsoft Dynamics gegenüber anderen CRM-Plattformen ausgewählt?

Es konnte den gesamten Kundenlebenszyklus abbilden, vom Lead über die Verkaufschance bis zur Betreuung nach dem Verkauf, und die langen, komplexen Geschäftszyklen im Rüstungsvertrieb bewältigen. Das Zusammenspiel mit Outlook und Teams unterstützte die Akzeptanz, und die Vertrautheit des Teams mit der Plattform senkte die Einstiegshürde weiter.

Zugriffskontrolle, Audit-Protokollierung, Flexibilität und Spielraum zum Skalieren waren die weiteren entscheidenden Faktoren für einen Kunden mit hohen Compliance-Anforderungen.

Welche Rolle spielte Experlogix CPQ, und wozu überhaupt CPQ?

Rüstungsprodukte haben komplexe Konfigurationsregeln. Eine Preisliste kann das Zusammenspiel von Produktvarianten, Compliance-Anforderungen und kundenspezifischen Konditionen nicht abbilden. Ohne CPQ hing jedes Angebot davon ab, dass der Ersteller die Regeln kannte.

Experlogix legte diese Regeln in das Angebotswerkzeug. Ein Vertriebsmitarbeiter bekam Validierungsrückmeldungen schon beim Erstellen des Angebots, statt Tage später eine Korrektur vom Engineering. Fehler wanderten nach vorn, dorthin, wo sie billig zu beheben sind.

Wie wurde SAP SD mit CRM und CPQ integriert?

SAP CPI fungierte als Middleware. Ein freigegebenes Angebot in Experlogix löste einen Ablauf aus, der den Auftrag in SAP SD mit den richtigen Positionen, Preisen und Kundendaten anlegte. CPI hielt außerdem Kunden- und Auftragsdaten zwischen Dynamics und SAP synchron, mit Validierungsregeln gegen nicht zusammenpassende Daten.

Vorher kopierte jemand jedes freigegebene Angebot von Hand in SAP. Die Automatisierung beseitigte Fehler bei der Neuerfassung und schuf einen sauberen Prüfpfad von der Freigabe bis zum Auftrag.

Was waren die größten Herausforderungen bei der Umsetzung?

Zuerst die Datenqualität. Die Kundendaten waren zwischen den Abteilungen uneinheitlich, mit Dubletten und fehlenden Feldern, und mussten bereinigt werden, bevor Dynamics die maßgebliche Quelle sein konnte.

Das Mapping der Integration kam an zweiter Stelle, besonders bei Produktkonfigurationen und Preisen über drei Systeme hinweg. Drittens die Abstimmung zwischen Vertrieb, Engineering, IT und Finanzen, vor allem, wenn sich die Zuständigkeit für Teile des Prozesses änderte.

Wie wurden Sicherheit und Compliance gehandhabt?

Sie waren von Anfang an eingebaut. Jede Komponente musste interne Sicherheitsrichtlinien und nationale Vorschriften erfüllen. Rollenbasierter Zugriff begrenzte, wer welche Datensätze sehen und ändern durfte. Lückenlose Prüfpfade deckten Angebote, Freigaben und Datenänderungen ab. Alle Daten blieben in den VAE, entsprechend den Vorschriften der Verteidigungsbranche.

Weil das Design von diesen Anforderungen ausging, hatten die Daten bereits die richtige Form, als die Compliance-Prüfungen anstanden.

Wie lange dauerte die Einführung?

Etwa sechs bis acht Monate, in Phasen. Sie begann mit einem Pilot für CRM und CPQ, wurde nach dem Feedback auf die Abteilungen ausgeweitet und nahm die Integration von SAP SD zur Halbzeit hinzu, als die vorgelagerten Systeme stabil waren. Schulung, Betreuung und Feinabstimmung liefen die ganze Zeit weiter.

Lässt sich dieses Modell auf andere Unternehmen der Rüstungs- oder Fertigungsbranche übertragen?

Ja, überall dort, wo Vertriebszyklen lang sind, Produkte konfigurierbar sind und Compliance-Dokumentation erforderlich ist: Luft- und Raumfahrt, Industrieanlagen und jedes Geschäft, in dem ein Angebot vor dem Versand eine technische Validierung durch das Engineering braucht.

Die konkreten Werkzeuge zählen weniger als die Integrationslogik. Das freigegebene Angebot muss ohne Neuerfassung in das ERP fließen, und der Kundendatensatz muss die einzige Wahrheitsquelle sein.