Christoph Korfhage 

Ich hoffe, alle haben schon ein bisschen was gegessen und sind nicht allzu müde nach dem Essen. Schön, dass ihr da seid. Schöne kleine Runde heute in unserer Masterclass. Das Thema kennt ihr alle. Wir schauen euch jetzt mal ein bisschen drauf, wie man alte Systeme liebt und trotzdem sexy macht. Kleine Einstiegsfrage in die Runde: Wer hat schon mal erlebt, dass ein großes Re-Platforming-Projekt gegen die Wand gefahren wurde? Oder nicht so gelaufen ist, wie man sich das initial vorgestellt hat. Das alle versprechen wirklich, der eine oder andere. Ja, letztendlich dann wahrscheinlich fast alle. Heute wollen wir beweisen, dass es auch anders geht, wie man eine erfolgreiche Weiterentwicklung macht, ohne dass man ein komplettes Re-Platforming machen muss. Und zwar, dass das auch funktioniert auf Basis eines schon seit 20 Jahren gewachsenen Systems. Wir sind heute zu dritt hier. Mein Name ist Christoph. Ich bin Head of UX bei der Synergy, komme aus Düsseldorf, mache das Ganze seit über zehn Jahren und bin hier zusammen mit der Jasmin. 

Jasmin Kahl 

Ja, Jasmin Kahl von der Soennecken. Produkt Owner oder Produktverantwortlich für unsere Shopsysteme. Bin seit zehn Jahren bei der Soennecken und seit über 25 Jahren in der IT und bin in Köln ansässig. Bene. 

Benedikt Grimm 

Hi, ich bin Ben. Hätte auf Frontend bei der Synergy. Dann gucken wir uns den ganzen Technik-Kram. Bin aus Mörs und mache das Ganze auch schon eine ganze Weile. 

Christoph Korfhage 

Wir machen einen ganz kurzen Vorstellungspart, der dauert aber wirklich nicht lange und dann geht es wirklich in die Sache. Über die Synergy: Wir sind eine Full-Service-Digitalagentur, kommen aus Köln, haben auch ein Büro in Dortmund und in Berlin jetzt auch. Wir sind sehr stark in dem ganzen Thema B2B-Commerce unterwegs, machen das Ganze schon ein paar Jährchen, sind Teil der Time to Act Group, die auch in Köln ansässig ist, über 1500 Mitarbeitende hat und eigentlich die ganze Brandbreite an IT Services anbietet, die man sich so vorstellen kann. Den Rest findet ihr sicherlich im Web, wenn ihr mal googelt. Und damit übergebe ich auch schon wieder an Jasmin, die ein paar Worte zu Sonnecken sagt. 

Jasmin Kahl 

Sehr gerne. Hier seht ihr so ein bisschen den Eindruck, wie es bei uns vor Ort aussieht. Unser Hauptstandort Wir haben in Overrad, in der Nähe von Köln. Wir haben oben in Melsdorff im Norden noch eine große Lagerverortung und in Essen sitzt unser Entwicklungsteam. Genau, hier so ein paar Zahlen, Daten, Fakten. Wichtig zu Sonnecken ist, wir sind Wir haben eine Genossenschaft für Bürobedarf, also auch tatsächlich einmal eine andere Fermierung, dadurch auch eine sehr andere oder ja, differente Komplexität in den Dingen, die uns täglich begegnen mit unseren Mitgliedern. Wir haben diverse Services und Produkte in unserem Portfolio für unsere Mitglieder und heute gucken wir tatsächlich auf die Shopsysteme. Wir haben zwei. Das ist zum einen der YoCommerce, das ist ein offenes B2X-Shopsystem und heute Da sprechen wir über den „Your Procure. Da reden wir über geschlossene Shopsysteme für unsere Mitglieder. 

Christoph Korfhage 

Genau. Jetzt geht es direkt schon in die Sache. Hat nicht mehr fünf Minuten gedauert. Perfekt. Die Ausgangslage. Jasmin hat es gerade gesagt, wir schauen uns so „Procure. Die Benahungen sind alle sehr ähnlich und „Zungenbrecher sind da garantiert. „so Procure gibt es schon seit über 20 Jahren und wurde kontinuierlich weiterentwickelt. Das ist eine Procurement-Lösung, die Sóniken für die Mitglieder geschaffen hat und ich glaube, mehr Da kannst du am besten erzählen dazu. 

Jasmin Kahl 

Genau. Das ist ein geschlossenes Shopsystem, sehr, sehr komplex. Ich glaube, wenn ich mal hochwerfe, wir haben über 1500 Funktionalitäten und Einrichtungsmöglichkeiten, die wir den Fachhändlern und den Shopadministratoren auf der Kundenseite an die Hand geben in dem System. Und ich glaube, das zeigt so ein bisschen, was da drinsteckt an Funktionen in dem Thema Beschaffung. Denn das ist das, was wir unseren Mitglieder mitgeben. Sie kriegen von uns Das ist ein Produkt, wo Sie mit Ihren eigenen Kunden Beschaffungsprozesse abbilden können. Das mal so auf die Kürze. Ich könnte ganz stundenlang und viel erzählen, gerne dann im Nachgang, aber sonst verliere ich, glaube ich, hier nicht hier. 

Christoph Korfhage 

Wir haben schon gesagt, seit über 20 Jahren im Einsatz. Das hat dann natürlich vielleicht auch eine kleine Folge, Jasmin, oder? 

Jasmin Kahl 

Yes, es hat eine Folge. Also nicht erschrecken. Das war vor 20 Jahren State of the art. Das, was wir aber haben, ist, wir haben ein sehr robustes und performantes System. Das heißt, es läuft, es ist stabil. Unsere Mitglieder können safe jeden Tag ihre Arbeitsprozesse und Beschaffungsprozesse mit deren Kunden abbilden und es läuft ruhig durch. Jetzt kommt das „Aber? Das Front-end, wie man vielleicht erahnen kann, entspricht nicht mehr dem neuesten Standard. Teilweise braucht man wahrscheinlich auch eine Brille oder man muss zoomen, je nachdem, welchen Desktop man vor Ort nimmt. Barrierefreiheit. Und das, was Man hat so Fragmente. Und das, was man vielleicht auch sehen kann, über die ganzen 20 Jahre, hat man zum einen Dinge, die man nicht mehr nutzt in der Funktionalität, nicht ausgebaut. Das heißt, man hat so Fragmente. Und auf der anderen Seite hat man immer wieder drangebaut und da hat man sich in den 20 Jahren vielleicht nicht immer die Gedanken gemacht, zu sagen: Wo macht das denn Sinn, das einzubauen aus UX-UI-Sicht? Sondern man hat es irgendwo drunter gesetzt. Und deswegen haben wir heute den Frankenstein. 

Benedikt Grimm 

Und uns allen Alles klar, wir brauchen einen Glow Up. Wir müssen irgendwas tun, diese Plattform, die ja mega gut ist und die eine unfassbare Anzahl an Features mitbringt, auch scheinen zu lassen. Und wie haben wir das gemacht? Wir haben erst mal an der Wir haben geguckt, wir haben ein Backend, das ist so die Konfigurationsmaske, könnt ihr euch vorstellen, und wir haben ein SuppoCure Frontend. Das ist das, was ihr gerade eben schon gesehen habt. Das ist im Prinzip das, was die Endanwender auch bedienen können. Jetzt ist es so: Im Backend haben wir eher so eine spec-mäßige UX. Ist vielleicht auch ganz okay, weil wie oft geht man schon hin, ändert die Einstellung, sieht erst mal ganz gut aus für uns und im Frontend, da ist eher der Gap noch, den wir füllen müssen. Da ist die UX veraltet. Wir müssen einmal ein bisschen anpassen und wir müssen es so hinkriegen, dass die Mitglieder nicht unbedingt durch die Handbücher navigieren müssen. Und deswegen war auch relativ schnell klar: Das Backend, das behalten wir und wir passen nur das Frontend an. Wie machen wir das? Im Prinzip ähnlich wie ihr das bei 500 anderen Vorträgen gehört habt über Composable Commerce. 

Benedikt Grimm 

Wir sagen, wir lassen unsere Provider-Systeme unten einfach mal stehen und bauen Da haben wir uns eine API-Schicht dazu. Und an die API-Schicht docken wir unser neues Frontend an. Das haben wir mit React gebaut. Und das gibt uns die Möglichkeit, zukünftig eben flexible Bausteine noch zu ergänzen. Und zwar nicht, indem wir jetzt ein komplett neues E-Commerce-System bauen, sondern wir bauen nur die Parts neu, die auch wirklich relevant sind für uns. Und die Systeme, die uns die ganze Power geben, die lassen wir einfach stehen und ergänzen die immer noch, zukünftig vielleicht mit einem AI-Tool oder mit einem CMS-System. Und dadurch haben wir ein deutlich geringeres Risiko auch, weil wir die ganze Business-Logik – und das ist ja das Komplexste, was bei den Projekten meistens schiefläuft –, die müssen wir nicht neu bauen. Und dann müssen wir uns natürlich die Frage stellen: Kann das überhaupt funktionieren? Also typischer Pitch: Wir sagen, wir machen das jetzt so. Ja klar, wenn man das Vertrauen kriegt vom Kunden, dann geht man schon die Richtung, aber wir wollen das natürlich auch safe haben. Das heißt, wir machen erst mal einen Hackathon Wir haben einen Hackathon gemacht, zusammen mit den Kollegen und Kolleginnen von der Sonnecken, haben uns zwei Tage vor Ort in Essen eingesperrt. 

Benedikt Grimm 

Drei Tage waren es, glaube ich, sogar. Drei, genau. Drei Tage haben wir uns eingesperrt und haben das Ganze durchprobiert, und zwar in der Form, dass wir einen kompletten Durchstich einmal gemacht haben. Wir haben von Produktkatalog bis hin zum Checkout und ein paar Funktionen im Kontobereich einfach mal generieren lassen, mit ganz viel Hilfe von Gen AI, und das zusammen Wir haben es mit den Kollegen ausprobiert, haben uns Flipcharts in allen möglichen Ecken der Räume platziert, die Features immer grob abzustecken, und es funktioniert. Wir haben es wirklich nach den drei Tagen sagen können, das funktioniert in der Form, wie wir das hier vorhaben. Das hat natürlich dann auch für Sönnecken ganz deutlich das Risiko gesenkt, die natürlich auch eine Verantwortung haben gegenüber ihrer Mitglieder. Absolut. Und dann kommt das Spannende dabei: Der Designprozess, denn Ähnlich wie wir es eben schon festgehalten haben, die Features sind sehr detailliert und da steckt jetzt im Prinzip meiner Meinung nach die ganze Magie drin, Koffi. Teufel im Detail. Und da bin ich gespannt, wie du das erzählst. 

Christoph Korfhage 

– im Detail. Ja, genau. Also grundsätzlich ist das Ziel ja, die Ist-Funktionalitäten eins zu eins zu überführen, nur in besser, in der neuen Welt. Dafür muss man aber auch natürlich erst mal herausfinden, was diese Ist-Funktionalitäten im Detail auch eigentlich sind, weil 1500 Einstellungsmöglichkeiten, die auch alle miteinander kombiniert werden können, das kann man gar nicht wirklich durch testen oder durchkonfigurieren. Das muss man systemisch verstehen. Wir haben erst mal angefangen und ein UX-Manifest aufgesetzt und ein paar Spielregeln definiert: Wie wollen wir in die Gestaltung reingehen? Welche Mechanismen nutzen wir? Welche Pattern? Wir haben definiert, dass alle Interfaces responsiv sind, auch wenn 95% der Nutzer das Tool auf dem Desktop bedienen, einfach weil wir nicht wissen, wohin geht die Reise. Vielleicht kann man irgendwann auch kleinere Sachen einfach mal on the fly und mobil machen. Die Use Cases werden sich wahrscheinlich so ein bisschen in die Richtung entwickeln und vielleicht ist es auch jetzt einfach so, dass das so schwer bedienbar ist, dass niemandem das jemals eingefallen ist, das auf dem Handy zu öffnen. Wir haben definiert, dass die neue Lösung barrierefrei sein soll, auch wenn wir vom BFSG nicht direkt betroffen sind, aber auch da, je barriereärmer etwas ist, desto mehr Nutzer können das nutzen, desto zukunftssicherer sind wir auch da aufgestellt. 

Christoph Korfhage 

Deswegen das auch direkt als Anforderung mit aufgenommen und dann haben wir modulare Prozesse definiert, wiederkehrende UX-Patterns, Popover-Menüs, Scrape-Modale, alle diese UX-UI-Fachbegriffe und dann auch eine Master-Tabelle aufgesetzt mit ganz vielen Funktionalitäten, weil Tabellen spielen eine sehr, sehr wichtige Rolle für dieses Interface. Das neue Front-end setzt dann bei uns auf einem Wide-Label Designsystem auf, für das wir auch dann entsprechend schon eine Storefront im Einsatz haben, das viele Patterns mitbringt. Und dann haben wir zu Beginn einen komplett neuen Seitenrahmen geschaffen. Das war eigentlich so die, ich sage mal, Vorbereitung auf das eigentliche Projekt. Seitenrahmen schaffen die ganzen Patterns an die Grundbedingungen anzupassen, die wir vorfinden, eine Kontonavigation, alle Tabellen optimiert und barrierefrei gestaltet. Aber das war nicht die Hauptherausforderung in dem Projekt. Ich habe es eben schon mal erwähnt: 20 Jahren ist viel passiert, manchmal auch ein bisschen Wildwuchs. Und da muss man dann natürlich schon drauf schauen: Was kann davon weg? Was wird auf jeden Fall noch gebraucht? Wie validieren wir das? Es gibt unfassbar viele Features, die von den Kunden admins ein-oder ausgeschaltet werden können und miteinander kombiniert werden können. Es gibt ein Handbuch, das ist unsere Bibel, aber das auch nicht immer alles bis ins letzte Detail definiert und nicht alles auf dem aktuellsten Stand. 

Christoph Korfhage 

Um euch die Komplizität so ein bisschen zu verdeutlichen, haben wir mal ein Beispiel mitgebracht, ein Vorher-und Nachher-Beispiel. Das hier ist einmal die Ist-Welt. Wir steigen jetzt ein in die Spezifika von einem typischen Procurement-Prozess, und zwar ist das die Konfiguration von Sortimentsrollen. Der Use Case ist, ich habe Multilevel-Einkaufsprozesse. Chefeinkäufer, Sub-Einkäufer, Sub-Sub-Einkäufer, die verschiedene Freigabe-Regeln einstellen müssen, Rollen definieren, auf welche Sortimente können die eigentlich zugreifen, welche Produkte können die kaufen, weil man kann bei So Procure ultra viele Kataloge auch von anderen Herstellern einfach anstöpseln. Das heißt, wir können gar nicht das Sortiment selber steuern. Das findet dann überwiegend über diese Konfiguration der Rollen statt. Ich zeige jetzt einmal so ein bisschen, wie es da vorangeht. Wir gehen über die Navigation. Dann gehen wir mal rein in die Verwaltung, in die Sortimente, in die Sortimentsrollen. Da sehen wir die Rollen der Übersicht. Eine Tabelle, gehen in die Admin-Rolle mal und dann sehen wir oben, können wir ein paar grundlegende Einstellungen vornehmen zu dieser Rolle und da drunter Da findet eigentlich so ein bisschen die Magic statt, die zugeordneten Segmente, also: Welche Sortimente, welche Segmente kann ich denn bestellen? Und da wollen wir mal das Segment Bürobedarf konfigurieren. Was ist jetzt passiert? 

Christoph Korfhage 

Reload. Wo konfiguriere ich das jetzt? Ich muss wissen, ich muss noch ein Stückchen nach unten scrollen. Da findet jetzt die Konfiguration statt. Da kann ich dann Einstellungen vornehmen. Ich kann superkrasse Sachen machen. Erststufiges Genehmigungsverfahren z. B. Abnahmbestellung von 500 €. Gesamtwert: Soll ein Genehmigungsprozess angesteuert werden? Zweiter Genehmigungsverfahren: Wenn ein Artikel mit mehr als 200 € im Warenkorb liegt, muss auch eine Genehmigung eingestellt werden. Da kann ich noch diverse andere abhängige Checkboxen einstellen. Ihr seht, die Tabelle lädt immer neu, da kommen immer mehr Checkboxen hinzu. Diese ganze Logik lag rein im Front-end. Das heißt, das war nicht so richtig dokumentiert und das musste man jetzt alles erschließen, erst mal herauszufinden, wo liegen welche Abhängigkeiten drin. Und dann darf ich nicht vergessen, hier unten rechts diesen Speichern-Button zu klicken, weil wenn ich den nicht finde, dann ist alles weg. Jetzt habe ich das Segment konfiguriert und wenn ich jetzt ein zweites Segment konfigurieren möchte, würde ich dann wiederum auf das einzelne Segment draufklicken und dann öffnet sich wieder unten dieser Bereich. Als wir das zum ersten Mal gesehen haben, haben wir gedacht: „Ja, coole Funktion. Wie gehen wir damit um? Das ist wirklich kein Bashing. Die Funktionen sind super und die sind super wertvoll und die werden auch echt gut genutzt. 

Christoph Korfhage 

Nur, wir können, glaube ich, auch neuen Leuten und Neukunden, die dann hinzukommen, das schwer verkaufen, so wie es jetzt gerade ist. Da müssen wir halt einfach was machen. Man braucht so ein kleines Studium. Ja, genau. Und deswegen das Glow Up. Wir haben das Feature erst mal als komplex bewertet. Das war die erste Einstufung. Das heißt, komplexes Feature, da brauchen wir irgendeine Art von Workflow für, das auch wirklich zu meistern. Was haben wir gemacht? Wir haben das Format der Deep Dive Groomings ins Leben gerufen, wo wir uns einmal sehr eng und intensiv abstimmen, insbesondere aus dem PO, dem Fachreferent, mit einem technischen Abstimmungspartnern und dann UX und UI. Dann schließen wir uns einen halben Tag ein und sezieren das Feature eigentlich einmal komplett runter, definieren, was sind eigentlich die ganzen Ist-Funktionalitäten, wo ist vielleicht das Delta zur Doku, wo kann man wirklich auch mal einen Zopf abschneiden, wenn es denn irgendwie geht. Und das ist dann sozusagen die Basis und dann gehen wir im zweiten Schritt darüber: Wir sehen Raum für Verbesserungen, ob wir es. Wie stellen wir uns das Ganze vor? Da haben wir einen Scribble gemeinsam auch in diesem Meeting gemacht Das wurde dann als PBI gehangen mit einer ganz kurzen Beschreibung eigentlich. 

Christoph Korfhage 

Und das war dann der Startpunkt für unsere UX-UI-Oberarbeitung. Jetzt fast forward. Wie sieht das Feature denn eigentlich in Zukunft aus? Das ist jetzt einmal das Nachherbeispiel. Auch die selben Funktionalitäten, die selben Funktionen. Wir sehen jetzt schon einmal den deutlich bereinigten Seitenrahmen, der einfach viel weniger Informationen enthält. Wir haben eine dynamische Kontonavigation. Je nachdem, welche rechte Rollen ich eigentlich selber habe, wird diese Navigation größer oder kleiner, je nachdem, wie viele Features was ich eigentlich nutzen kann. Wir haben die erste Tabelle der Sortimentsrollen angereichert mit aktiven Segmenten und letzten Änderungen. Warum? Wenn ich kein Segment konfiguriert habe, ist die Rolle eigentlich nicht da, die ist eigentlich nicht fähig. Das muss ich irgendwie wissen, damit ich sehe, wo sind meine Fehlkonfigurationen? Und das zweite, irgendwas ist schiefgelaufen. Ja, okay, dann sortiere ich mal nach letzter Änderung, weil dann weiß ich auch, da sind dann die meisten Sachen direkt nach oben sortiert, schnell einsteigen zu können. Und dann klicke ich hier mal auf „Play. Ich hoffe, ich komme immer mit. Das ist jetzt Das haben wir natürlich voraufgenommen. Ich gehe dann jetzt gleich einmal rein, auch wieder in eine Sortimentsrolle und navigiere eine Ebene tiefer. Dafür haben wir auch so Popover-Menüs geschaffen, weil es sind noch sehr viele Funktionalitäten versteckt, die vorher alle irgendwo sich im Interface verbunden haben. 

Christoph Korfhage 

Jetzt sind wir in der Sortimentsrolle, in den allgemeinen Einstellungen. Wir haben auch das aufgeteilt. Es gibt hier zwei Tabs, allgemein und Segmentkonfiguration. Da findet ja eigentlich die Magic statt. Jetzt haben wir hier unsere neue aufgeräumte Tabelle von den einzelnen Segmenten. Auch Die wurde angereichert, und zwar mit den Katalogen, mit den Genehmigungsverfahren und mit den Benachrichtigungen. Das gab es alles vorher nicht. Vorher war es ja einfach nur eine plane Liste. Aber so sehe ich schon: Was habe ich denn eigentlich grundsätzlich an meinen Segmenten konfiguriert? Wie viele Kataloge sind drin? Wie viele Genehmigungsverfahren sind aktiv? Habe ich hier irgendwelche Benachrichtigungen? Fehlen sie mir oder stören sie mich? Und ich kann sie schnell ausschalten, weil ich weiß, wo sie sich verbergen. Und auch solche Kleinigkeiten – man kann es Kleinigkeiten nennen – sind mit drin. Klassische Vor Die klassischen Kleinigkeiten: Wenn man aktuell ein Segment deaktiviert, dann wird dieses Segment gelöscht. Also alle Einstellungen, die vorher drin waren, die gehen dann verloren. Daran haben sich die Nutzer jetzt gewöhnt, das wissen sie in der Regel, aber wir haben das zum Anlass genommen, da auch noch mal ein paar Validierungen mit reinzunehmen. Wollen Sie das wirklich? Sind Ihnen die Folgen bewusst, damit wir da auch den Nutzerfrust gerade bei neuen Nutzern verringern, weil man es einfach nicht sieht. 

Christoph Korfhage 

Das haben wir gemacht, obwohl es in dem Bereich gar nicht konkret gefordert war, weil die Nutzer sich daran gewöhnt haben. Und wir haben es außerdem gemacht, weil die Alternative gewesen wäre, die ganze Logik im Backend umzuschreiben und das wollten wir vermeiden. Das ist so der Quick Fix. Da müssen wir gar nichts großartig ändern. Das kriegt man super schnell gelöst. Der Nutzerfrist wird reduziert. Einfache Lösung. Damit gehen wir weiter. Das zweite, das seht ihr jetzt, diese ganzen Einstellungen, die vorher unterhalb der Tabelle waren, die haben wir einfach rausgezogen und über die Tabelle drübergelegt. So ist die Tabelle immer noch sichtbar. Ich habe die ganzen Einstellungsdetails gekapselt und auch hier wieder eine Substruktur eingeführt, damit es eben ein bisschen übersichtlicher ist und einfacher verwaltet werden kann. Hier kann ich jetzt genau dieselben Einstellungen vornehmen, wie ihr das eben auch schon in dem Ist-Beispiel gesehen habt. Ich kann „Kataloge auswählen und ans Segment reinpacken. Ich kann in den Genehmigungsprozess reingehen und dieselben komplexen Genehmigungsverfahren einstellen, die ich vorher auch schon einstellen konnte. Und wir haben dann noch die Benachrichtigungsfunktionen eingeführt. Das seht ihr oben rechts. Die waren vorher irgendwo zwischendrin versteckt. Man hatte überall so kleine Benachrichtigungsthemen. Das haben wir geclustert, weil wenn ich jetzt eine Benachrichtigung einstelle, seht ihr oben links diesen grünen Button-Bubble, der sagt schon, okay, da ist irgendwas aktiv geworden und genau diese Einstellungen spielen wir dann auch auf der Tabelle wieder, wenn ich eben hier meine Ebene gespeichert habe. 

Christoph Korfhage 

„speichern ist auch ein guter Punkt. Viel deutlicher, viel prägnanter. Ich kann viel schneller meine ganze Konfiguration vornehmen. Erstes Key Take away. Ux-design ist wichtig und hat eine große Rolle dabei, das Benutzererlebens natürlich deutlich zu verbessern. Viele Überarbeitungen wirken jetzt im Nachhinein naheliegend und total obvia ist, weil ja klar, warum hat man das nicht immer schon gemacht. Der Weg dahin ist ein bisschen schwieriger, weil man einfach sehr, sehr viel in die Kommunikation gehen muss, in die Abstimmung reingehen muss. Wir haben diese Deep Dive Grooming Sessions ins Leben gerufen. Wir haben feste Defend Over Slots in unserem Sprint Format definiert, 90 Minuten pro Woche, die immer stattfinden, weil wir die auch nutzen, diese ganzen Rückfragen innerlich zu klären, den Devs auch schon mal Zwischenstände zu zeigen, weil die sind auch nicht bei jeder Abstimmung mit dabei, damit sie früh ein Veto haben, dann noch mal Einfluss auf die Gestaltung zu haben. Und allgemein binden wir auch Fokusgruppen ein, Gruppen von der Sönneke, die schon früh auf Features mal draufgucken, eben da auch ein Buy-in zu bekommen. Und damit geht es in den Entwicklungsprozess. 

Benedikt Grimm 

Denn alles, was Herr Koffi hier so schön designt hat, muss natürlich auch irgendjemand am Ende entwickeln. Da machen wir uns natürlich ein modernes Werkzeug zu Nutze. Kannst du mal eins weiterklicken, Koffi? Ich habe gerade den Mister Obvious. Wir nehmen KI auch im Entwicklung Workflow mit auf. Und zwar machen wir das aber bewusst. Wir machen das nicht. Wir lassen das einmal runter generieren, in der Hoffnung, da kommt das One-Shot-perfekte Ergebnis raus. Sagen wir, wir gehen iterativ vor. Wir gehen dabei so vor, dass wir mit MCPs, Model-Context-Protokoll, habt ihr vielleicht an einer anderen Stelle schon mal was von mitbekommen. Usb-c-stecker für KI wird es oft genannt. Dem geben wir einfach ein paar neue Tools an die Hand. In unserem Fall ist das so, dass wir ein Tool haben, aus Figma-Designs Code zu generieren und dabei auch die Design Tokens, die der Koffie mit seinem Team akribisch vorbereitet hat im Designsystem, die mit in unsere Codebase rüber zu kriegen. Der Agent folgt dabei der Strukturvorgabe, die wir ihm geben. Wir geben ein ganzes Regelset an Guidelines mit, damit das auch in unserem Sinne gebaut wird. Aber das Wichtige daran ist, wir lassen nur den Rohbau durch die KI machen. 

Benedikt Grimm 

Wenn wir sagen, hier baut zum Beispiel die Tabelle, die der Koffee eben gezeigt hat, oder das Slight-Out-Panel, in der Detailausgestaltung gehen aber dann die Kollegen aus der Technik hin und die Kolleginnen und führen das Ganze im Detail aus. Wir nutzen Tailwind, wir nutzen React. Das macht das ganz praktisch, weil die KI darauf ganz gut funktioniert. Das Wichtigste ist die Feinjustierung. Die machen die Kollegen von Hand. Wichtig ist dabei zu wissen, dass parallel dazu natürlich auch die ganzen Schnittstellen entstehen müssen. Wir haben eben gesehen, wir haben unser Back-end-Provider-System. Das hat natürlich von Haus aus erst mal noch nicht die Schnittstellen. Das heißt, die Back-and-Kollegen von Sönnecken Seite müssen das Ganze natürlich auch bauen, brauchen von uns die Requirements. Das kann aber parallel dazu erfolgen, denn es ist ja schon recht klar, was das Endergebnis ist. Wir wissen ja schon, was die Funktion am Ende ist und welche Features es geben soll, vor allen Dingen nach dem der Christoph und Jasmin das in ihren Groomings ausgefiniert haben. Und dabei ist immer immer wichtiger und das wird euch wahrscheinlich auch zukünftig immer mehr begegnen, wenn wir mit KI arbeiten, auch vor allen Dingen im Code-Bereich, dann müssen wir das Ganze natürlich auch viel, viel strikter kontrollieren. 

Benedikt Grimm 

Wir haben mit Zona Cube ein ganz gutes Regelset im Einsatz, wo wir automatisiert das Ganze in der Qualität checken können, weil wir sind hier in einem Enterprise-Bereich. Wenn da ein Fehler drin ist, dann … Katastrophe? Ist eine Katastrophe, weil Wirklich, ich weiß gar nicht, wie viele Kunden sind unterwegs, grob? Kunden? Oh, das ist eine ganz hohe Zahl. Das nagelt ziemlich fest. 

Jasmin Kahl 

Ich glaube, sie ist sechsstellig. Und da dürfen wir oder unsere Fachhändler dürfen keinen Tag verlieren, auch keinen halben Tag. Das ist direkt mit wirklich hohem Umsatzverlust zu versehen und die Kunden auf der Seite von unseren Fachhändlern sind dann auch nicht wirklich happy. Das ist kritisch. 

Benedikt Grimm 

Deshalb: Strenge Testprotokolle im Team. Wir machen einen Unit Test und so weiter. Alles, was ihr kennt von einem typischen Projekt, machen wir natürlich auch. Nur noch mal eine Schippe strikter, einfach weil wir wissen, wir lassen uns einen Teil von KI generieren und machen den Review-Prozess halt eben deutlich stärker. Das wichtige Key Take-away an der Stelle ist eigentlich, dass diese Innovation und neue Modelle anzuwenden, das braucht Vertrauen. Wir könnten das nicht machen und nicht sehr erfolgreich machen in dem Projekt, wenn wir nicht das Stakeholder-Vertrauen von der Sonnecken-Seite hätten. Wir müssen in der Lage sein, Lösungen auch mal spontan komplett neu denken zu können. Und wir müssen aber auch das Risiko gleichzeitig einschränken können. Deswegen so Hacketons kann ich nur empfehlen. Es hat bis jetzt jedes Mal super funktioniert, wenn wir das gemacht haben. Schenkt das Vertrauen, ich glaube, ihr werdet belohnt. 

Christoph Korfhage 

Genau. Und wären wir nicht in so einem agilen Ansatz unterwegs und hätten im Vorfeld einen Festpreis definiert mit allen Anforderungen, die genau runtergeschrieben sind – erst mal wäre das kaum möglich. „das geht nicht wirklich, weil es so komplex ist –, dann könnten wir das Projekt gar nicht so durchführen. Das geht nur, wenn wir agil unterwegs sind und im sehr kollaborativen Modus. Genau. Und dann kommen wir zum Projekt. Genau. 

Jasmin Kahl 

Also alle, die jetzt erwarten, dass wir einen Projektplan haben und da steht wirklich alles dekliniert runter, geschrieben, was wir wann tun. Mit Zeitfenstern drin haben wir nichts. Wir setzen uns hin und wir wissen, welche Module und Funktionalitäten wir alle bauen müssen. Wir gönnen uns auch einen Teil Lage vor Ort, wo wir uns zusammensetzen und dann tatsächlich Grobschätzungen dran schreiben an die einzelnen Themen. Und dadurch kommen wir in die Situation, dass wir eine Phasenplanung machen können. Und das passt auch hoch ins Management, mit dieser Phasenplanung auch besprechbar zu bleiben oder in der Diskussion zu bleiben: Wann können wir denn welche Dinge liefern und wann sind wir voraussichtlich fertig? Jetzt könnte man ja erwarten, dass wir den Scrum-Guide genommen haben und sind so richtig akribisch und stoisch hinterher und immer alles nach Lehrbuch. Nein. Wenn man sich vorstellt, das Team setzt sich zusammen aus eigentlich, sage ich mal, drei Subteams oder vier, wenn man ehrlicherweise sagen müsste. Wir haben die QR, wir haben das Backend und das Content-Team. Und wenn wir jetzt alle jedes Mal, jede Woche, drei, vier Stunden im Refirement sitzen würden und würden alle möglichen Anforderungen besprechen und in die Diskussion kommen, würde die Hälfte wahrscheinlich sich langweilen und nichts zu sagen haben und umgekehrt und wir würden Zeit verlieren und die wollen wir nicht verlieren. 

Jasmin Kahl 

Das heißt, wir haben uns sehr flexibel aufgestellt. Wir haben begonnen als ein Team in den Zeremonien und nach jeder Retro gucken wir, was waren eigentlich die Pain Points? Was können wir besser machen? Und dann sind wir sehr flexibel unterwegs. Häufig ist das eine Chat-Nachricht. Zwei Menschen oder drei tauschen sich aus, holen sich vielleicht noch mal einen Schulterschlag von dem nächsten Team und wenn alle die Daumen hoch machen, kommt es in den Chat rein und dann ist es direkt gewachsen, neue Prozessstruktur. Das hat dazu geführt, dass wir, ich glaube, nach drei, vier Sprints, fünf vielleicht, die Teams separiert haben. Das heißt, das Content-Team ist unterwegs mit dem UX-Team und das Back-end-Team mit der WA. Wir trennen die Refinements, weil das Front-End-Team häufig schneller ist in der Umsetzung und Entwicklung als das Back-and-Team. Genau, und so holen wir die Fährtchen und können die Fährtchen in dem ganzen Rennen auch ganz gut orchestrieren. Das läuft tatsächlich ganz über Das ist schon sehr gut. Genau, was sind unsere Learnings auch? Wir haben festgestellt, wir sitzen ja an unterschiedlichen Standorten, unterschiedliche Teams, dass es sehr wertvoll ist, wenn wir uns mal einen Tag oder zwei einschließen. Das tun wir regelmäßig. 

Jasmin Kahl 

Wir gehen auch so zum Mittagessen. Wir haben auch mal Spaß. Wir sind jetzt nicht nur die ganze Zeit und sagen: „Ja, okay, weiter, weiter. Und das Schöne und das Besondere ist, und ich sage das jetzt einfach für das ganze Team: Es gibt nicht diese Kundendienstleistung, Da ist da Barriere. Das nehme ich zumindest nicht wahr. 

Christoph Korfhage 

Wir auch nicht. 

Jasmin Kahl 

Es gibt keine Trennung oder „Ich kann das jetzt nicht sagen, das sage ich dir hinterher. Das ist echt eine super Teamarbeit und ich glaube, deswegen können wir auch so gut performen zusammen. 

Christoph Korfhage 

Super schönes Fazit eigentlich schon auch. Wir haben noch ein abschließendes Fazit mitgebracht tatsächlich und das ist es: Traut es euch, auch mal alte Sachen stehen zu lassen? Denn das alte ist nicht schlecht. Viele Tech-Partner-Agenturen – wir machen das auch häufig – sagen: „Okay, lasst uns ein komplettes Re-Platforming machen, einen freshen Start, dann geht es los. Das kriegt man aber nicht in der kurzen Projektlaufzeit hin. Das ist natürlich auch klar, weil die ganze Komplexität im Backend, die in dem Backend-System liegt, muss natürlich erst mal erfasst werden, muss dann auch reframed werden, neu aufgebaut werden. Das sorgt für eine lange Projektlaufzeit. Durch diesen Ansatz, den wir hier gewählt haben, eher eine Evolution statt einer Revolution, ist das Ganze viel besser möglich und umsetzbar in einem kleineren Zeitraum, und zwar auch mit einem wirklichen Mindset auf die Customer-Centric. Denn das ist das, was die Endkunden am Ende interessiert. Die interessiert nicht, wie die Back-in-Systeme es im Hintergrund lösen. Das, was die anfassen, muss gut sein, muss verständlich sein und deswegen ist das für uns auch so eine Quintessenz aus diesem Projekt. Wir bauen das nicht komplett neu, sondern wir reframen eigentlich das, was wir vorher in der Oberfläche drin hatten. 

Christoph Korfhage 

Pflegt eure Legacy-Software, hegt sie, aber wenn ihr dann große neue Features wenn ihr das hinzubauen wollt, dann macht das eher in einem kleinen Composable-Bauestein daneben, denn das ermöglicht auch das Decoupling von Back-and-Front. Man muss keine komplett reine Natur von MACH-Infrastruktur aufsetzen. Die ganzen großen Vorteile, die kriegt man auch schon durch das Decoupling und ist dann auch flexibel, schnell neue Bausteine hinzuzufügen und agil zu werden. Ist immer eine kurze Masterclass, diese halbe Stunde. Wir sind auch schon durch. Wir wollen noch mal ein super großes Dankeschön an unser Team aussprechen. Es Hier ist es kein Team Sóniken, kein Team Synergy. Es ist einfach ein großes gesamtheitiges Team. Es macht super Spaß, mit allen zusammenzuarbeiten. Und jetzt sind wir ready für eure Fragen. Wenn ihr sie denn habt, ihr könnt gerne die QR-Code scannen, dann folgt ihr uns auf LinkedIn und da werden wir dann auch noch mal das Slight Deck teilen. Ja. 

Jasmin Kahl 

Also angefangen haben wir Anfang des Jahres. Ich glaube, im Februar haben wir angefangen. Genau. Im Februar waren so die ersten Sprintanfänge, die ersten Groomings. Wir sind mittendrin und Zielgerade ist Q1 26. Wir liegen aber tatsächlich gerade im guten Zeitplan. Wir haben gerade keine Verzögerung. Wenn man sich das Ganze mal so ein bisschen anguckt, das ist dieses Glockenprinzip. Man hat einen sehr steilen langen Weg, der sich hochzieht und wenn man oben den Peek erreicht hat und da befinden wir uns gerade, haben wir letzte Woche noch draufgeschaut mit allen Teams, wir sind gerade oben an der Glocke und jetzt kommt langsam dieser Kipppunkt, wo es dann auch Geschwindigkeit erledigt. 

Benedikt Grimm 

Wohlgemerkt, Q1 in feature complete. Wir haben natürlich Zwischenziele gesetzt, damit auch die Fachhändler mal in der Fokusgruppe drauf gucken können, damit wir frühstmöglich auch ein Feedbackschema kriegen. Und da gibt es halt so Zwischenziele. 

Jasmin Kahl 

Genau. Wir wären jetzt Mitte Ende Q3, die Fachhändler mit on board, testen das vollumfänglich. Und dann ist auch geplant, dass die mit ihren ersten Kunden, die wenige Module im Einsatz haben oder aktiviert haben, tatsächlich auch schon in die Umstellung gehen können. Wie viel seid ihr bei euch? 

Christoph Korfhage 

Also einmal zwei Leute im UX und GI, dann, ich glaube, zwei oder drei front-end „2,5, nicht? „2,5, klar. 

Benedikt Grimm 

„2,5. 

Christoph Korfhage 

„2,5, nicht? „2,5, ja genau. Und das war’s, glaube ich, schon von dem Synergy-Part. 

Jasmin Kahl 

Genau, bei „Synergy-und „Backend-seitig haben wir zwei Senior-Backend-Kollegen, zwei junge Kollegen in der Ausbildung und zwei Kollegen in der QA. Genau. Und das war’s. Bezogen auf … Ja, genau. Weitere Fragen? Genau. Das ist auf cplace plus geschrieben, das Backend. 

Benedikt Grimm 

Das ist schon ins extreme, in performance optimiert. Das heißt, das Wegglen System antwortet schon jetzt mega schnell und deswegen ist das gar nicht so unser Pain Point. Genau. Genau, das passiert auch in dem … Ich glaube, das schreiben Sie mit C sharp. Da bin ich gar nicht so tief drin, aber das ist auch echt gut performant. War ich selber überrascht, aber die Kollegen wissen, was wir nun machen. Machen Sie schon. Das ist vorab schon gemacht. Vorab nicht, das passiert während der Entwicklung. Dafür haben wir die QR-Kollegen, die tatsächlich dann auch auf die Last gucken. Aber ihr guckt ja auch noch drauf, oder? Genau das. Und für das eigentliche Back-and-System gibt es ja die regelmäßigen Audits, weil Sönnecken muss ja auch bestimmten Zertifizierungen entsprechen mit, ich weiß gar nicht, 27 001 und so weiter. Genau, alle ISO-Fahrungen. Da gibt es regelmäßige Audits für, sowohl sicherheitsmäßig als auch lastmäßig. Genau, und es ist auch alles im Monitoring drin. Das heißt, die Infrastruktur wird überwacht und dann gehen die roten Lampen an und die gelben Wender irgendwo, was sich vermeintlich auftut. 

Christoph Korfhage 

Sehr schön. Dann sind wir durch. Vielen, vielen Dank für die Teilnahme und die Aufmerksamkeit.