Ich bin Deniz Gerss. Unternehmen holen mich ins Haus, wenn ein SAP- oder Transformationsprogramm feststeckt und keiner genau sagen kann, warum. Ich arbeite direkt im Team an Architektur und Application Lifecycle, und ich gehe, sobald das Team ohne mich weiterkommt.
Nicht wegen der Technologie. Sondern wegen der Art, wie sie eingeführt wird.
IT spricht Infrastruktur. Business spricht Ergebnisse. Ohne jemanden, der beide Sprachen fließend beherrscht, stagnieren Projekte. Langsam. Teuer. Und jeder ist überzeugt, dass der andere das Problem ist.
Eine Person trägt das institutionelle Gedächtnis. Die Prozesse, die Workarounds, das Wissen der Organisation: alles steckt in ihrem Kopf. Wenn sie geht, geht alles mit.
Die Tools reden nicht miteinander. Dieselben Datensätze liegen in mehreren Systemen, und die Kopien stimmen nicht überein. Jede Integration ist von Hand gebaut. Es gibt keinen Stand, dem alle trauen.
Die Reihenfolge ist entscheidend. Die meisten Organisationen versuchen, Probleme zu lösen, bevor sie sie verstanden haben, und holen externe Unterstützung erst dann, wenn die wichtigen Entscheidungen bereits gefallen sind. Dann steht die Architektur, und Sie optimieren eine Entscheidung, die Sie anders getroffen hätten.
Neue Software wird eingeführt. Alte Gewohnheiten bleiben. Das Warum hat niemand erklärt. Das Tool bleibt ungenutzt oder wird halb genutzt, und das eigentliche Problem besteht einfach weiter.
Wenn Ihnen das bekannt vorkommt, sollten wir reden.
Discovery Call buchenDie meisten Architektur-Projekte beginnen in einem lauten Raum: konkurrierende Prioritäten und Entscheidungen, die nie jemand aufgeschrieben hat. Die Aufgabe ist, alle in eine gemeinsame Sprache zu bringen, damit Ihre Teams gute Entscheidungen treffen, ohne dass ein Berater danebensitzt. Ich arbeite eingebettet, direkt neben den Leuten, die die eigentliche Arbeit machen. Architektur muss den Praxistest überleben, sonst landet sie im Regal.
Dass IT und Business aneinander vorbeireden, ist normal. Es muss nur nicht so bleiben. Ich arbeite mit beiden Seiten an denselben Fragen: Was braucht die eine Seite von der anderen, und was schuldet sie ihr? Sobald das klar ist, fühlen sich Projekte nicht mehr wie Tauziehen an.
Jede Anwendung hat einen Lebenszyklus. Organisationen, die ihn gut managen, entscheiden bewusst, in welche Anwendungen sie investieren und welche sie ablösen, statt erst zu reagieren, wenn etwas bricht. Ich helfe, diesen Lebenszyklus zu strukturieren: von den ersten Anforderungen bis zur Ablösung, mit einer Governance, die gemeinsam mit den Menschen entsteht, die damit leben müssen.
Details sind vertraulich. Ergebnisse nicht.
Situation: Die SAP-Landschaft war über Jahre informell gewachsen, verwaltet von einer kleinen Gruppe, die einfach schon immer da war. Prozesse waren nicht dokumentiert. Änderungswünsche lebten in E-Mail-Threads. Releases fanden statt, wenn sich jemand sicher genug fühlte. Eine Person hielt alles zusammen.
Was ich getan habe: Einen Release-Prozess konzipiert und eingeführt, der vom Änderungswunsch bis in die Produktion reicht. Ein zentrales Change Advisory Board etabliert. JIRA mit SAP Solution Manager integriert, damit die Tools den tatsächlichen Workflow abbilden. Hands-on-Trainings durchgeführt, um die über Jahre gewachsene Abhängigkeit von einer einzelnen Person aufzubrechen.
Ergebnis: Ein strukturierter Release-Prozess, der der Organisation gehört. Nicht einer Einzelperson. Änderungsentscheidungen wurden transparent, Releases planbar. Und Peter konnte endlich Urlaub nehmen.
Situation: Das Change-Management war über JIRA, ServiceNow und SAP verteilt. Jedes Team pflegte seine eigene Kopie der Daten. Entwicklung und Betrieb glichen sich jeden Tag von Hand ab. Niemand hatte das vollständige Bild.
Was ich getan habe: Die Architektur für SAP Solution Manager 7.2 entworfen und eigene APIs für JIRA und ServiceNow entwickelt. Change Requests laufen seitdem automatisch durch die gesamte Toolchain, ohne manuelle Übergaben.
Ergebnis: Entwicklung und Betrieb arbeiten in einem Workflow. Ein Change Request läuft durch alle drei Systeme, ohne dass ihn jemand neu eintippt. Kein täglicher Abgleich mehr.
Situation: Die Organisation hatte gute Tools gekauft: Focused Build, Cloud ALM. Aber niemand hatte überlegt, wie die Mitarbeitenden sie im Alltag tatsächlich nutzen würden. Ein Tool ohne Prozess ist teures Regaldekor.
Was ich getan habe: Die komplette SAP-Focused-Build-Einführung geleitet. Die eigentliche Arbeit passierte aber davor: bestehende, undokumentierte Prozesse gemeinsam mit den Stakeholdern aufgenommen, bevor eine einzige Konfigurationsentscheidung fiel. Daraus eine Arbeitsweise gebaut, die abbildet, wie die Organisation wirklich arbeitet, nicht wie es im Vendor-Whitepaper steht.
Ergebnis: Eine Organisation, die versteht, warum ihr Tool das richtige ist. Und die es nutzt, ohne mich wieder ins Haus zu holen.
Ich bin Deniz. Mein Hintergrund ist Enterprise-Architektur und Application Lifecycle Management, und ich setze die Rollouts selbst um, statt sie weiterzureichen. Ich habe in der Fertigungsindustrie, der Automobilbranche und im öffentlichen Sektor gearbeitet. Meistens dann, wenn etwas Wichtiges nicht funktioniert und niemand weiß, warum. Wenn ein Projekt mehr Hände braucht, hole ich Leute dazu, mit denen ich seit Jahren arbeite.
Was in einem Projekt wirklich zählt, steht selten in den Unterlagen. Es steckt in dem, was keiner ausspricht oder noch nicht gefragt hat. Ich stelle die Frage, die auf der Hand liegt. Die kommt nicht immer gut an. Meistens ist sie trotzdem richtig.
Mein Auftrag endet, wenn Ihr Team ohne mich weiterkommt. Das ist der einzige Maßstab, der zählt.
Discovery Call buchen
Der Discovery Call beginnt mit einer Nachricht. Sagen Sie mir, wo es klemmt, und ich antworte innerhalb eines Werktags.