Unsere Prinzipien
So arbeiten wir — und so entscheiden wir, woran wir arbeiten.
Wir beraten zu SAP-Technologie und bauen unsere eigenen Werkzeuge. Diese Prinzipien haben sich über knapp zwanzig Jahre herausgebildet — nicht als Leitbild am Reißbrett, sondern als Muster in den Entscheidungen, die sich bewährt haben.
Das eigentliche Problem lösen
Die meisten SAP-Projekte scheitern nicht an der Technologie. Sie scheitern, weil jemand das falsche Problem gelöst hat — das aus der Präsentation statt das in der Landschaft. Wir beginnen damit, zu verstehen, was tatsächlich da ist: die Systeme, die Rahmenbedingungen, die Geschichte. Dann finden wir heraus, was sich wirklich ändern muss.
Das bedeutet, dass wir manchmal dem Briefing widersprechen. Wenn ein Kunde eine Custom-Integration will, das eigentliche Problem aber eine falsch konfigurierte RFC-Destination ist, sagen wir das. Das Ziel ist nicht, Stunden abzurechnen — sondern die Landschaft in einem besseren Zustand zu hinterlassen.
Das gleiche Prinzip gilt für unsere Werkzeuge. YaNco existiert, weil der Standard-SAP-.NET-Connector funktionale Programmierung unmöglich machte. Unser DMS-Migrationsframework existiert, weil kein vorhandenes Tool SAP-DMS-Verknüpfungstabellen korrekt behandelte. Wir bauen, was gebraucht wird, nicht was gerade im Trend liegt.
Was wir empfehlen, haben wir selbst erprobt
Wir empfehlen nicht nur Architekturen — wir bauen die Werkzeuge, die beweisen, dass sie funktionieren. Wenn wir funktionale Fehlerbehandlung für RFC-Aufrufe empfehlen, können wir YaNco zeigen. Wenn wir sagen, asynchrone Replikation ist das richtige Muster, können wir auf Integrationsframeworks verweisen, die wir selbst gebaut haben und in Produktion betreiben.
Das hält uns ehrlich. Beratung ohne Bauen sind nur Meinungen. Bauen ohne Beratung ist nur Code. Die Rückkopplung zwischen beidem macht beides besser. Unsere Werkzeuge entstehen aus der Praxis, und unsere Beratung basiert auf dem, was wir tatsächlich ausgeliefert haben.
Es bedeutet auch, dass wir betreiben, was wir bauen. Wir betreiben unsere eigene Infrastruktur, verwalten unsere eigenen Deployments und haben mit denselben betrieblichen Realitäten zu tun wie unsere Kunden.
Verantwortung für das Ergebnis
Go-live ist nicht die Ziellinie. Wenn wir eine Integration, eine Migration oder eine Architekturempfehlung liefern, bleiben wir verantwortlich dafür, ob es in Produktion tatsächlich funktioniert. Nicht weil wir müssen — weil das Ergebnis zählt, nicht das Deliverable.
Deshalb ist Design, Build, Operate kein Dreierpaket von Services — es ist eine Philosophie. Wer die Architektur entwirft, sollte verstehen, wie sie betrieben wird. Wer das Tool baut, sollte sich dafür interessieren, ob es den Kontakt mit echten Daten überlebt. Wir übergeben nicht und gehen.
Verantwortung heißt auch erreichbar sein. Wenn nachts um zwei etwas kaputtgeht oder sechs Monate nach Go-live ein Edge Case auftaucht, sind wir immer noch die, die den Hörer abnehmen. Dieses langfristige Engagement verändert, wie man Systeme von Anfang an entwirft.
Offen als Standard
Unser Standard ist, unsere Werkzeuge als Open Source zu veröffentlichen. YaNco, dotnet-ovn, unsere Integrationsbibliotheken — alles öffentlich. Nicht weil Open Source im Trend liegt, sondern weil es bessere Software hervorbringt. Öffentlicher Code wird geprüft, dokumentiert und auf höherem Niveau gepflegt.
Das bedeutet auch: Wer wissen will, was wir können, kann sich den Code ansehen. Unsere Architekturmuster sind dokumentiert, unsere Bibliotheken auf GitHub. Die Tiefe der Arbeit ist der Beleg — nicht Behauptungen auf einer Website.
Offen heißt auch ehrlich zum Reifegrad. Manche Tools sind kampferprobt über mehrere Kundenprojekte. Andere sind experimentell. Wir kennzeichnen sie entsprechend und lassen die Leute selbst entscheiden.
Diese Prinzipien in der Praxis
Möchten Sie sehen, wie sich das in echten Projekten zeigt? Sprechen wir über Ihre SAP-Landschaft.