Future{hacks}: Procurement ist das neue Risikomanagement
Trending Topics auf Google als bevorzugte Nachrichtenquelle festlegen.
Vor zwei Wochen ging es um eine bequeme Verwechslung: „Unsere Cloud steht in Frankfurt.“ Das klingt nach Kontrolle, nach europäischer Ordnung, nach einem Häkchen in der Risiko-Spalte. Nur beweist Standort erst einmal Geografie. Kontrolle ist etwas anderes.
Damit bleibt eine Frage übrig, die viele Unternehmen ungern laut stellen: Wie kauft man Kontrolle eigentlich ein? Nicht als Schlagwort, nicht als „Souveränitätsprojekt“, sondern im Alltag, in Angeboten, Verträgen, Verlängerungen.
Die meisten Firmen kaufen Software noch immer so, als wäre sie ein Möbelstück. Man vergleicht Features, man verhandelt den Preis, man unterschreibt Bedingungen, und man ist froh, wenn das Thema erledigt ist. Das läuft erstaunlich lange. Bis zu dem Moment, in dem plötzlich etwas kippt: ein Preismodell, ein Support-Level, eine Anforderung eines Kunden, ein Incident. Dann sitzt jemand aus Finance oder der Geschäftsführung im Raum und stellt den Satz, der alles entlarvt: „Warum können wir nicht einfach wechseln?“
Die ehrliche Antwort ist selten technisch. Sie lautet meist: weil Wechselbarkeit, Nachweisfähigkeit und Verhandlungsmacht nicht in der IT entstehen, sondern beim Einkauf.
Warum Procurement 2026 nach Strategie riecht
Man muss kein „Public Tender“-Unternehmen sein, um sich an Beschaffungslogiken der öffentlichen Hand zu orientieren. Im Gegenteil: Immer mehr private Firmen übernehmen diese Muster, weil sie intern funktionieren.
Öffentliche Beschaffung ist nicht automatisch besser. Sie ist oft langsamer, formalisierter, manchmal auch Theater. Aber sie hat etwas gelernt, das private Unternehmen gerne verdrängen: Risiko ist nicht das, was im Pitch erwähnt wird. Risiko ist das, was im Vertrag nicht geregelt ist.
Und dieses Denken schwappt in die Privatwirtschaft, aus sehr profanen Gründen. Boards und Aufsicht wollen Belege, keine Beruhigung. Kunden verlangen Nachweise entlang der Lieferkette, weil sie selbst in Audits stehen. Versicherer und Risikomanagement wollen Prozesse sehen, nicht „wir reagieren schnell“.
Das Ergebnis ist kein ideologisches „Buy European“, sondern eine nüchterne Kaufentscheidung: Wer liefert mir Beweise, Leitplanken und Optionen, und wer liefert mir nur ein Gefühl?
Was Käufer übersehen, bis es teuer wird
In der Praxis scheitert das selten an einem großen Fehler. Es scheitert an kleinen Dingen, die man beim Kauf für lästig hält und später bezahlt.
Das erste sind Nachweise. Viele Produkte sind nicht „compliant“ wie ein Schalter, den man umlegt. Compliance ist Arbeit, Dokumentation, Prozess. Die Frage ist nicht, ob ein Vendor prinzipiell etwas liefern kann, sondern ob er es so liefert, wie man es später braucht. Wer im Einkauf nicht definiert, was „ja“ bedeutet, endet oft in einem absurden Zustand: Man hat ein teures System im Betrieb und trotzdem ein Projekt am Hals, das nachträglich Belege zusammensucht, die man eigentlich mitkaufen hätte können.
Das zweite sind Änderungen. SaaS lebt davon, beweglich zu sein. Bundles werden neu geschnitten, Metriken werden angepasst, Features wandern in höhere Pakete, Support wird zum Upsell. Man kann das moralisch bewerten, muss man aber nicht. Für Käufer zählt nur: Passiert das bei dir als genervtes Schulterzucken, oder als echtes Geschäftsrisiko? Der Unterschied ist simpel. Hast du Leitplanken vereinbart, oder hast du Bedingungen akzeptiert und gehofft, dass es schon gut geht?
Das dritte ist der Wechsel selbst. Viele überschätzen ihre Freiheit, weil sie Migration als technisches Projekt denken. In Wahrheit ist ein Wechsel meistens Organisation: Rollen, Berechtigungen, Reporting, Integrationen, Gewohnheiten. Besonders perfide wird das bei Tools, die harmlos wirken, weil sie „nur“ Zusammenarbeit sind. Dort entsteht Lock-in nicht durch APIs, sondern durch Alltag. Entscheidungen landen im Chat statt im Protokoll, Wissen hängt in Channels, und nach einem halben Jahr ist der Rückweg kein IT-Task mehr, sondern ein Kulturprojekt.
Wie man Kontrolle einkauft, ohne ein Regelbuch zu schreiben
Wenn du das jetzt liest und denkst: Klingt nach Bürokratie. Ja, kann es werden. Muss es aber nicht. Profis ersetzen Marketingwörter durch beobachtbare Dinge. Und sie behandeln diese Dinge wie Produktanforderungen.
Das beginnt banal. Nicht „seid ihr audit-ready?“, sondern: Welches Artefakt liefert ihr, und in welchem Takt? Gibt es eine Subunternehmerliste, und werden Änderungen angekündigt? Gibt es einen Incident-Prozess, der über „wir melden uns“ hinausgeht?
Es geht weiter mit Änderungen. Nicht „AGB akzeptiert“, sondern: Was passiert, wenn sich Preis-Metriken ändern? Welche Fristen gelten? Welche Option haben wir, wenn sich die Spielregeln wesentlich verschieben? Das ist trocken, aber es ist die beste Versicherung gegen „plötzlich teuer“.
An diesem Punkt lohnt sich manchmal eine Frage, die im Einkauf oft tabu ist: Muss das überhaupt SaaS sein? Nicht aus Ideologie, sondern aus Risikorechnung. Für Standardprozesse ist SaaS oft die schnellste, günstigste Wahl. Für differenzierende Prozesse, für kritische Datenflüsse oder für alles, was du realistisch nicht wechseln kannst, kippt die Rechnung. Dann zahlst du nicht nur für Software, sondern für Abhängigkeit.
Genau dort wird individuell gebaute Software plötzlich wieder attraktiv, obwohl sie am Papier „teurer“ wirkt. Nicht, weil Individualsoftware magisch ist, sondern weil sie dir zwei Dinge zurückgibt, die SaaS gerne verschluckt: Kontrolle über Änderungen und die Möglichkeit, den Betrieb notfalls auch ohne Vendor weiterzuführen. Wenn du dabei auf Open Source setzt, wird das noch pragmatischer. Du kaufst keine Blackbox, sondern ein System, das zur Not jemand anderer übernehmen kann. Das ist keine Romantik. Das ist Verhandlungsmacht.
Und es endet bei Wechselbarkeit. Nicht „wir können exportieren“, sondern: Zeigt uns im PoC einen Export, der für unseren Use Case brauchbar ist. Später reicht ein kleiner, definierter Test in regelmäßigen Abständen, um zu wissen, ob man sich selbst belügt. Nicht weil man wechseln will, sondern weil man die Option nicht verlieren darf.
Subunternehmer sind dabei nicht das Problem. Komplexität ist normal. Das Problem ist, wenn man Abhängigkeiten erst im Incident-Fall entdeckt. Transparenz heißt nicht, dass man jedes Detail kontrolliert. Es heißt, dass man weiß, wo die kritischen Knoten sind und wer im Problemfall welche Rolle hat.
Unser Future{hacks} Fazit
Cloud in Frankfurt war nie das eigentliche Thema. Es war die Ausrede, mit der man sich ein gutes Gefühl kaufen konnte. Kontrolle entsteht nicht durch Geografie, sondern durch Einkaufsentscheidungen. Wer das unterschätzt, wird nicht zwingend gehackt. Er wird irgendwann überrascht.
Die praktische Konsequenz ist nicht „SaaS ist schlecht“. Die Konsequenz ist eine saubere Trennung: Standard kaufst du ein, Differenzierung baust du dir. Und alles, was im Ernstfall nicht stillstehen darf, behandelst du wie kritische Infrastruktur, auch wenn es „nur Software“ ist. Wenn du bei dieser zweiten Kategorie zusätzlich auf Open Source setzt, machst du dich nicht automatisch unabhängig. Du machst dich ersetzbar. Und das ist in der Realität oft das Einzige, was zählt.
Frankfurt ist ein Ort. Optionen sind eine Entscheidung.
Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.
