Vorbereitung
All Episodes
12. Thales als Matrix: So entstehen echte Deals im DevSecOps-Account

12. Thales als Matrix: So entstehen echte Deals im DevSecOps-Account

0:00|0:00

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.

This show was created with Jellypod, the AI Podcast Studio. Create your own podcast with Jellypod today.


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?