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. Daten existieren mehrfach. Jede Integration ist ein Workaround. Niemand hat eine einheitliche Datenquelle.
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. Zu diesem Zeitpunkt ist der Spielraum für echte Veränderung oft schon eng.
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, sind Sie hier richtig.
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. Weniger IT-Projekt, mehr echte Zusammenarbeit.
Jede Anwendung hat einen Lebenszyklus. Organisationen, die ihn gut managen, treffen bewusste Entscheidungen auf dem Weg, 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: End-to-End-Release-Management-Prozess von Grund auf konzipiert und eingeführt. 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. Daten lagen in Silos. 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 einheitlichen Workflow. Change Requests fließen automatisch zwischen den Plattformen. Kein manueller Abgleich mehr, keine Datensilos.
Situation: Die Organisation hatte in solide Tools investiert. 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 Methodik 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, Berater für digitale Transformation mit Hintergrund in Enterprise-Architektur, Application Lifecycle Management und operativer Umsetzung. Ich habe in der Fertigungsindustrie, der Automobilbranche und im öffentlichen Sektor gearbeitet. Meistens dann, wenn etwas Wichtiges nicht funktioniert und niemand weiß, warum.
Das meiste, was in einem Projekt wirklich zählt, steckt zwischen den Zeilen. In dem, was nicht ausgesprochen wird. Oder noch nicht gefragt wurde. Ich stelle die Frage, die eigentlich 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
Schildern Sie mir die Situation. Ich antworte innerhalb eines Werktags.