Never give up. The sky is the limit.

01Wer ich bin

Every life counts. Nicht 999 von 1.000.

Bevor ich Software gebaut habe, habe ich zwei Berufe erlernt, in denen es keine 99,9 % gibt: Linienpilot bei Austrian Airlines und Fluglotse bei Austro Control. Die Aufnahmetests für beide gehören zu den schwersten der Welt – der DLR-Test in Hamburg mit seiner Durchfallquote nördlich von 98 %, das mehrtägige Assessment bei Austro Control, in dem Menschen erfahren, wie belastbar sie wirklich sind. Zehntausende bewerben sich, ein paar Dutzend kommen durch. Ich habe beide bestanden.

IQ misst, wie schnell jemand denkt. Der Cockpit-Test misst, wie ruhig jemand bleibt, wenn die Anzeige rechts oben schon fünf Sekunden lang etwas Falsches meldet und man es als Erster merken muss. In der Fliegerei zählt das zweite. Und über allem steht ein Prinzip: Es zählt jedes Leben. Every life counts. Nicht 999 von 1.000. Alle.

Ob das eine Berufs-Pose oder ein Betriebssystem ist? Als ich im Herbst 2025 nach dreißig Jahren Pause wieder mit Tennis begonnen habe, habe ich mir einen Trainer gesucht, der jahrzehntelang ATP-Top-10-Spieler betreut hat. Nicht, weil ich auf die Tour will – sondern weil ich, wenn ich etwas ernst nehme, wissen will, wo mein Deckel wirklich ist.

02Zu Hause

Drei Kinder, ein Vater, kein Autopilot.

Ich bin alleinerziehender Vater von drei Kindern. Die beiden Jüngeren sind im Schulalter, der Älteste ist volljährig. Wer das kennt, weiß: Es gibt keinen Dienstplan, der hält, und keinen Tag, der so endet, wie er geplant war. Man lernt, Prioritäten in Sekunden zu setzen – und sie am nächsten Morgen neu zu sortieren.

Mein ältester Sohn ist schwer behindert. Er lebt mit einem seltenen Gendefekt, einer Mikrodeletion. Er hat mir mehr über Geduld, Verlässlichkeit und das Wesentliche beigebracht als jedes Assessment und jedes Projekt.

Meine drei Kinder sind mein Lebensmittelpunkt und meine Motivation – jeden einzelnen Tag.

Wenn ich „Every life counts“ sage, ist das kein Satz aus dem Cockpit mehr. Es ist Alltag. Und es ist der Grund, warum ich Software baue, die Menschen Zeit zurückgibt – Zeit, die woanders dringender gebraucht wird.

Mein Leben hat sich durch all das massiv verändert. Ich bin noch strukturierter geworden, als ich es aus dem Cockpit gewohnt war – und genau deshalb passt in die frühen Morgenstunden, bevor das Haus aufwacht, jeden Tag eine Stunde Sport: Kettlebell, Rope Skipping, Boxen. Nicht trotz der Verantwortung, sondern wegen ihr.

Ich bin überzeugt: Das Wichtigste ist die tägliche Routine.

Große Ziele erreicht man nicht mit großen Tagen, sondern mit vielen gewöhnlichen, die verlässlich gleich beginnen. Genau so bauen wir Software: Sie soll die tägliche Routine tragen – unspektakulär, verlässlich, jeden Tag –, damit für das Unplanbare Kopf und Zeit bleiben.

Never give up.
The sky is the limit.

Mein Motto. Kein Poster an der Wand – eine Entscheidung, jeden Morgen.

03Ein Satz in Hamburg

Wie aus KSIC die CloudDNA wurde.

Ich habe die CloudDNA vor über zehn Jahren gegründet – ursprünglich nicht unter diesem Namen. Ich kam von SAP, wo ich Jahre in einem der größten Softwarekonzerne der Welt verbracht hatte. Ein sicherer Hafen. Ich habe ihn trotzdem verlassen.

Am Anfang stand ein sperriger Name: die KSIC GmbH – Koch Security, Integration and Cloud Consulting. Vier Buchstaben, die niemand aussprechen konnte. Die Rettung kam bei einem Abendessen in Blankenese, Hamburg, in einem Fischlokal an der Elbe. Mein alter SAP-Kollege Jörg hörte sich zum dritten Mal meine Erklärung an, hob das Glas und sagte einen einzigen Satz:

„Martin, du hast die Cloud in deiner DNA.“

Zwei Wochen später hieß die KSIC GmbH nicht mehr KSIC. Mit dabei war damals schon Daniel, mein erster Mitarbeiter – auf seiner allerersten Dienstreise. (Den Steinbutt, Daniel, tut mir bis heute leid.)

Angefangen haben wir in einem winzigen Büro in Oberwart. Heute sitzen wir in der ehemaligen Raiffeisenbank in Loipersdorf, mitten in der Thermen- und Weinregion Südburgenland, und schöpfen aus zwei Talentschmieden, die man auf keiner Weltkarte findet: der HTL Pinkafeld und der FH Burgenland. Aus dem Duo ist ein Team von 24 Menschen geworden, und wir haben siebzehn Bücher bei SAP Press veröffentlicht – immer aus der Praxis, nie aus dem Marketing.

04Der Umbruch

Individualsoftware war ein rotes Tuch. Bis 2023.

Ich habe die CloudDNA aufgebaut, um für Konzerne SAP-Integrationen zu bauen – schwere Software, in Monaten getaktet. In dieser Welt mied man Individualsoftware wie der Teufel das Weihwasser: zu teuer, zu langsam, zu riskant.

Dann kamen die Sprachmodelle.

Mir wurde klar: Das ist keine graduelle Verbesserung, das ist der Umbruch, der unser Handwerk umschreibt. Also habe ich mich selbst hingesetzt und Software gebaut – nachts, am eigenen Editor, mit denselben Werkzeugen, die ich meinem Team empfehle. Man kann niemandem mit einer PowerPoint erklären, wie KI-gestützte Entwicklung funktioniert. Man muss es vorleben.

Was früher drei Monate und ein sechsstelliger Betrag war, geht heute in Wochen. Nicht, weil Programmierer zaubern, sondern weil Copiloten die Fleißarbeit übernehmen und Entwickler wieder werden, was sie sein sollten: Handwerker mit Kopf.

05Wir bauen das

Von „We deliver“ zu „Wir bauen das“.

Über zehn Jahre lang hieß unser Versprechen „We deliver“: Ein Kunde beschreibt, wir liefern. Das hat uns groß gemacht. Aber es hat eine Grenze: Wer nur liefert, was bestellt wird, baut selten das, was gebraucht wird.

Deshalb bauen wir uns um. Aus Beratern und Entwicklern werden Forward Deployed Engineers und Product Owner. Forward deployed heißt: Sie sitzen dort, wo das Problem entsteht – in der Hausverwaltung, im Weingut, in der Kanzlei – und bauen vor Ort. Product Owner heißt: Sie bleiben, bis es gelöst ist, und verantworten das Produkt, nicht das Ticket.

„Wir bauen das.“ Drei Wörter, die man einem Kunden nur sagen darf, wenn man sie auch meint.

06Wir sprechen KI

In der KI-Blase und vor allem draußen.

In der KI-Blase reden alle über Modelle, Benchmarks und Agenten. Draußen – bei der Hausverwalterin mit tausend Tops, beim Winzer im Südburgenland, beim Wirt mit zwanzig Tischen – zählt eine andere Frage: Spart mir das morgen eine Stunde, und kann ich mich darauf verlassen?

Wir übersetzen zwischen diesen Welten. Wir bauen täglich mit Claude von Anthropic und sind auf dem besten Weg, Partner von Anthropic zu werden. Aber was beim Kunden ankommt, ist kein Modell, sondern ein Ablauf, der funktioniert:

• Die KI schlägt vor, ein Mensch entscheidet. Mehr Selbstständigkeit gibt es erst nach bestandener Probezeit.
• Jede Aktion steht im Prüfpfad. Was die KI getan hat, lässt sich nachlesen.
• KI muss sich rechnen. Eigener Schlüssel, feste Kostengrenze je Mandant.
• Daten bleiben, wo sie hingehören. Mandanten bis in die Datenbank getrennt.

Anthropic und Claude sind Marken der Anthropic PBC. Die Nennung beschreibt unsere Arbeitsweise.

07Die Familie der Tailors

Maßgeschneidert statt Standard mit hundert Kompromissen.

Statt nur über KI-gestützte Entwicklung zu reden, haben wir Branchen ausgesucht, die ich gut genug kenne – oder in denen ich Freunde habe, die mir das Problem so lange erklären, bis es sitzt. Jeder Tailor teilt mit seinen Geschwistern dasselbe Fundament, aber spricht die Sprache seiner Branche:

• ProbeTailor – für Abnahmetests in SAP-Projekten und Fachsoftware, weil ich in all den Jahren SAP-Beratung zu viele Abnahmen in Excel-Listen und zu viele Screenshots in Mails gesehen habe.
• JournalTailor – für die Kreditorenbuchhaltung vor SAP, BMD und DATEV, weil ich in SAP-Projekten zu oft gesehen habe, wie Rechnungen abgetippt werden, obwohl die Buchung dahinter längst Routine ist.
• DocumentTailor – für SAP-Häuser, weil ich selbst fünfzehn Jahre lang Formulare auf den SAP Adobe Document Services gebaut habe und die Nachfolgefrage nicht länger unbeantwortet lassen wollte.
• RecordTailor – für alle, die ein DMS brauchen, das nicht nur speichert, sondern liest – weil ich zu oft gesehen habe, wie jemand heimlich Excel öffnet, weil das DMS zu langsam ist.
• ImmoTailor – für Hausverwaltungen und Projektentwickler, weil sich dort Buchhaltung, Technik und Portale besonders oft im Weg stehen.
• TaxTailor – für Steuerkanzleien, weil ein Freund mir bei einem Glas Wein von seinem Windows-Terminal-Server erzählt hat.
• DineTailor – für die Gastronomie, weil ich seit Jahren an fremden Tischen sitze und Champagner an Wirte verkaufe.
• StayTailor – für die Hotellerie, weil die Thermenregion voller Betriebe steckt, die sich unter dem Konditionen-Diktat der Portale ducken.
• MeetingTailor – für Sitzungen und Gremien, weil Stiftungsräte, Gemeinderäte und Vereinsvorstände in meinem Freundeskreis immer wieder dieselbe Nachtszene beschreiben.
• Weintailor – für Winzerinnen und Winzer, weil wir mitten in einer Weinregion sitzen und jede zweite Reise ohnehin zur Weinreise wird.
• BuildTailor – für Bau und Handwerk, weil Mängel, Pläne und Regieberichte auf der Baustelle entstehen – nicht im Büro.
• iFlowTailor – für SAP Cloud Integration, weil ich das Cookbook dazu mitgeschrieben habe und trotzdem jeden Tag zehn Tabs offen hatte: Monitor, Postman, XPath-Tester, Keystore, Excel mit Namen. Die Werkbank dazu hat gefehlt, also haben wir sie gebaut.

Die CloudDNA ist deshalb kein reiner SAP-Zulieferer mehr, sondern eine Werkstatt mit einer wachsenden Produktlinie. Wirtschaftlich mutiger. Menschlich das Ehrlichste, was wir tun konnten.

08Warum iFlowTailor

Ich habe das Cookbook mitgeschrieben. Und trotzdem zehn Tabs offen gehabt.

Wer im Cockpit sitzt, hat alle Instrumente vor sich – nicht in zehn Fenstern verteilt. In der Integrationsentwicklung war das nie so: Editor hier, Monitor dort, Postman, XPath-Tester, Keystore, die Excel-Liste mit den Namen. Sechs Gedanken, aus denen iFlowTailor entstanden ist:

1. Gedanke 1 · Das Cookbook

   Das Wissen stand im Buch. Gebraucht wurde es im Editor.

   Mit Thorsten Reisinger und Marc Urschick habe ich das SAP Cloud Integration Cookbook¹ geschrieben. Rezepte für Fehlerbehandlung, Retries, Security, Performance. Nur: Beim Bauen liegt das Buch selten aufgeschlagen daneben. Die 40 Regeln von Quick Review² sind dieses Wissen, dort, wo es gebraucht wird – und bekannte Fehlermuster verweisen auf das passende Kapitel.

2. Gedanke 2 · Das Cockpit

   Alle Instrumente vor einem, nicht in zehn Fenstern.

   Im Flugzeug sucht niemand den Höhenmesser in einem anderen Raum. iFlowTailor ist ein Panel neben dem Editor³, das weiß, welches iFlow gerade offen ist – Review, Test, Monitor, Keystore und Suche beziehen sich darauf.

3. Gedanke 3 · Kein Server

   Die beste Datenhaltung ist die, die es nicht gibt.

   Jede andere Tailor-Software hat ein Fundament mit Datenbank. iFlowTailor hat bewusst keines: kein Server, keine Telemetrie⁴, die bestehende SAP-Session⁵. Das macht die Freigabe in der IT kürzer und die Nacht ruhiger.

4. Gedanke 4 · Read-only

   Erst schauen, dann anfassen.

   Ein Werkzeug, das einen Produktiv-Tenant ändern kann, muss es nicht ab Werk tun. Schreibaktionen sind aus⁶, bis jemand sie bewusst freischaltet – und dann mit Vorher/Nachher und Protokoll. Wie die Checkliste vor dem Anlassen der Triebwerke.

5. Gedanke 5 · Ursache vor Symptom

   Hundert Fehler, eine Ursache.

   Im Betrieb habe ich zu viele Nächte damit verbracht, fehlgeschlagene Nachrichten einzeln zu öffnen. Die Fehleranalyse gruppiert nach Signatur⁷ und kennt die üblichen Verdächtigen: TLS-Handshake, 401 vom Empfänger, Zertifikatskette, Timeout.

6. Gedanke 6 · Die Hand am Hebel

   Der Autopilot schlägt vor. Fliegen tut der Mensch.

   Ask Tailor erklärt, entwirft und berät – mit deinem eigenen Modell, maskiert⁸. Selbst das iFlow aus einer Anforderung wird nur nach Bestätigung angelegt und nie deployt⁹. Das ist keine Vorsicht aus Mangel an Vertrauen in die Technik. Es ist dieselbe Regel, nach der ich geflogen bin.