
12. Thales als Matrix: So entstehen echte Deals im DevSecOps-Account
In dieser Folge geht es um die komplexe Verkaufsrealität bei Thales: von der dreidimensionalen Account-Matrix über die drei Go-to-Market-Bewegungen bis hin zum Unterschied zwischen Signal und echtem Deal. Außerdem diskutieren wir, warum Motion B oft der unterschätzte Hebel ist, wie man valide Chancen mit einem Sechs-Tore-Prinzip prüft und weshalb FlytEDGE, Agenten und Verbrauchsmodelle die Enterprise-Logik verändern.
Chapter 1
Die 3D Matrix statt der Ein Deal Illusion
Otto
Fünftausend aktive DevSecOps Nutzer. Die Zahl steht im Raum, und der erste Reflex bei fast jedem Account Executive ist sofort der Gedanke an den einen, riesigen Folgevertrag.
Leonie
Der magische Zehn-Millionen-Euro-Klick, der auf einen Schlag alles abdeckt. Aber genau da fängt die Selbsttäuschung an.
Otto
Vollkommen. Thales ist kein monolithischer Softwareladen, den man mit einem einzigen Enterprise-Pitch aufräumt. Wer das versucht, verbrennt sich sofort die Finger.
Leonie
Weil man es in der Praxis mit einer echten dreidimensionalen Matrix zu tun hat. Lass uns das mal ganz konkret auseinanderdröseln. Achse eins: die Organisation. Das sind Dutzende eigenständige Business Units, Avionik-Programme, Defence-Projekte, verschiedene Ländergesellschaften. Achse zwei: die Workflows, also CI/CD, Security, Compliance, bis hin zu Agentic Engineering. Und Achse drei: das kommerzielle Modell, sprich bestehende Ultimate-Lizenzen gegen neue GitLab Credits für Verbrauchsmodelle.
Otto
Wenn man diese drei Achsen miteinander multipliziert, kriegt man kein einzelnes Verkaufsziel. Man kriegt hunderte kleine Zellen.
Leonie
Ganz genau. Und dein Job als Verkäufer ist es nicht, die ganze Matrix bunt anzumalen, sondern die eine Zelle zu finden, wo heute echter Schmerz sitzt, eine messbare Zahl existiert und jemand das Budgetrecht hat.
Otto
Wobei man da ja im Grunde zwischen drei Bewegungen unterscheidet. Motion A, B und C.
Leonie
Richtig. Motion A ist die Breite. Das bewährte GitLab-Modell auf neue Entitäten oder weitere Avionik-Teams übertragen. Motion C ist der neue Verbrauch, also wenn autonome Workflows wie Code Review Flows oder Pipeline-Fixes über DAP per Credits laufen.
Otto
Aber die spannendste Bewegung ist doch Motion B. Die Tiefe.
Leonie
Und warum ausgerechnet die?
Otto
Weil sie fast immer radikal unterschätzt wird! Bei Motion B verkaufst du unter Umständen überhaupt kein neues Produkt. Kein glänzendes KI-Feature, kein Upgrade. Du gehst in den bestehenden Ultimate-Footprint rein und hilfst ihnen, die Pipeline-Governance, die Software-Supply-Chain-Kontrollen und die Security-Scans überhaupt erst mal einheitlich zu nutzen.
Leonie
Du meinst, die schöpfen das, wofür sie ohnehin schon zahlen, noch gar nicht voll aus?
Otto
Ganz genau. Ich kenne das aus so vielen komplexen Projekten. Das Management spricht begeistert über autonome Entwicklungsagenten, während die Entwickler im Maschinenraum noch an fünf verschiedenen, veralteten Jenkins-Servern ersticken und Skripte flicken.
Leonie
Stimmt. Und wenn du dann als Anbieter reinkommst und sagst: Schaut mal, wir haben hier brandneue KI-Agenten, dann guckt dich der Platform Lead an und denkt: Ich brauche keine Agenten, ich brauche grüne Pipelines.
Otto
Absolut. Erst das Fundament abdichten, bevor man das Dachgeschoss ausbaut. Motion B schafft oft sofort messbare Stundenersparnis, ohne dass der Kunde einen einzigen Cent mehr für Lizenzen ausgeben muss. Das schafft Vertrauen.
Chapter 2
Das Sechs Tore Prinzip Warum 90 Prozent reine Recherche sind
Leonie
Aber das bringt uns direkt zu der Frage: Wann ist eine Chance in dieser Matrix wirklich real? Wir sehen ja ständig Signale. Zum Beispiel Thales-Stellenanzeigen, in denen ganz explizit nach Ingenieuren gesucht wird, die Jenkins auf GitLab CI migrieren.
Otto
Und der unerfahrene Vertriebler trägt sofort eine halbe Million in die Pipeline ein.
Leonie
Weil er ein Signal mit einem Deal verwechselt. Genau deshalb braucht es dieses Sechs-Tore-Prinzip. Ein Signal ist nur Tor eins. Ein Indiz dafür, dass man mal hinschauen sollte.
Otto
Und Tor zwei ist der Schmerz. Bestätigt der Kunde überhaupt, dass diese Koexistenz von Jenkins und GitLab ein Problem ist? Vielleicht stört es ihn ja gar nicht.
Leonie
Exakt. Und danach kommen noch vier weitere Tore: Wer besitzt das Problem? Haben wir eine messbare Metrik? Passt unsere Lösung in die strengen Sicherheitsvorgaben? Und gibt es einen konkreten nächsten Validierungsschritt? Wenn auch nur eines dieser Tore fehlt, hast du keinen Deal. Du hast nur Account-Recherche.
Otto
Das ist ein brutaler, aber heilsamer Filter. Und der führt zu einer der wichtigsten Entdeckungsfragen überhaupt im Gespräch mit den Plattformverantwortlichen.
Leonie
Welche meinst du?
Otto
Die Frage: Ist dieser Unterschied in den Entwicklungsumgebungen beabsichtigt oder einfach historisch gewachsen?
Leonie
Ah. Das ist stark. Weil es keinen Vorwurf enthält.
Otto
Genau. Bei einem Rüstungskonzern oder im Raumfahrtbereich kann Tool-Zersplitterung pure Absicht sein. Streng getrennte Netze, Souveränitätsauflagen für bestimmte NATO-Aufträge, spezielle Sicherheitsklassifizierungen. Wenn du da versuchst, alles zwanghaft auf eine einzige Plattform zu konsolidieren, zeigst du nur, dass du ihr Geschäft nicht verstehst.
Leonie
Und wenn die Antwort lautet: Nein, das ist einfach historisch so entstanden, weil Team X vor vier Jahren dieses Tool gekauft hat und Team Y jenes?
Otto
Dann hast du die offene Tür für Motion B oder Entitäts-Expansion. Aber eben erst dann. Im Vorfeld muss man ganz strikt trennen: Was ist ein Szenario-Fakt, den wir sicher wissen? Was ist eine bloße Hypothese? Und wo gilt ein klares 'No-Go until validated'?
Leonie
Wie beim Thema Software-Lieferkette. Wir wissen, dass Thales hohe Sicherheitsanforderungen hat, aber wir wissen nicht, wie Artifactory oder Nexus gruppenweit eingebunden sind. Wer da reingeht und behauptet, GitLab könne sofort alles ersetzen, verliert sofort jede Glaubwürdigkeit.
Otto
Man wird vom strategischen Partner zum drängenden Softwareverkäufer degradiert. Und aus der Schublade kommt man im Enterprise-Segment nie wieder raus.
Chapter 3
Der FlytEDGE Massstab und das Dilemma der Skalierung
Leonie
Lass uns mal auf einen Bereich schauen, wo der Mehrwert bereits öffentlich bewiesen ist: FlytEDGE. Das In-Flight-Entertainment-Programm von Thales.
Otto
Ein echtes Leuchtturm-Projekt. Die Zahlen sind ja verbürgt: zweiwöchige Release-Zyklen. Das ist rund zwanzigmal schneller als die traditionellen Zyklen in der Avionik.
Leonie
Zwanzigmal. Das muss man sich auf der Zunge zergehen lassen. In einer Branche, in der Software-Updates früher Monate oder gar Quartale an Vorlauf brauchten.
Otto
Aber, und hier kommt das riesige Aber: Das verleitet natürlich dazu, zu sagen: He, was bei FlytEDGE klappt, rollen wir jetzt einfach eins zu eins über alle anderen Avionik-Programme aus.
Leonie
Was brandgefährlich wäre. In-Flight-Entertainment berührt Passagier-Bildschirme und Streaming. Das ist hochmodern und cloud-nah. Aber sobald du in flugkritische Steuerungssysteme gehst, greifen ganz andere Zertifizierungs- und Sicherheitsauflagen.
Otto
Genau da liegt das Dilemma. Die Plattform-Teams wollen natürlich Skaleneffekte. Die wollen wiederverwendbare CI/CD-Vorlagen, automatisierte Audit-Trails und einheitliche Richtlinien bereitstellen.
Leonie
Aber die einzelnen Programm-Teams brauchen ihre lokale Autonomie, um spezifische regulatorische Hürden zu nehmen. Wenn die Plattform zu starr wird, bauen sich die Entwickler wieder Schatten-Pipelines.
Otto
Weshalb der richtige Weg nicht das Aufzwingen eines starren Templates ist, sondern das Angebot von wiederverwendbaren Bausteinen. Die Teams behalten ihre Autonomie, sparen sich aber die repetitive Arbeit bei Compliance-Nachweisen.
Leonie
Und wenn wir noch einen Schritt weiter denken: In die Welt der Agenten. Thales arbeitet ja intensiv an eigenen Initiativen wie LEA und dem Agent Garden. Und GitLab bringt Konzepte wie DAP und Credits ins Spiel.
Otto
Das stellt das gesamte kommerzielle Gefüge auf den Kopf, oder?
Leonie
Total. Jahrelang war die Enterprise-Welt simpel: Man zählte Köpfe. Soundso viele Entwickler, mal Betrag X pro Lizenz im Jahr, fertig war die Planbarkeit.
Otto
Und plötzlich rechnen wir nach tatsächlichem Nutzen und Verbrauch ab. So viele Credits für einen automatisierten Code-Review, so viele für eine Pipeline-Korrektur oder eine Schwachstellen-Analyse.
Leonie
Das klingt auf dem Papier fair, wirft aber im Großkonzern fundamentale Kontrollfragen auf. Was passiert, wenn ein Team anfängt, dutzende Agenten parallel über den Code laufen zu lassen? Wer überwacht die Kosten, wer trägt das Budgetrisiko, wenn die Pipelines plötzlich mit KI-Aktivität geflutet werden?
Otto
Und vor allem: Wer garantiert die Governance? Welcher Agent darf tatsächlich Code committen, und wo bleibt das Vier-Augen-Prinzip des Menschen unantastbar?
Leonie
Eine Frage, die sich am Ende jeder Plattform-Architekt stellen muss: Wie viel Autonomie geben wir der Maschine, und wie messen wir ihren echten wirtschaftlichen Wert, bevor wir die Schleusen öffnen?