Smart Hacks für IT Projektmanager

Sidekick Network

Since 12/2024 12 Episoden

Vom Tool zur Wirkung: Drei Bausteine für gelungene IT-Einführung

Wie man mit Personas, Showcases und einem Key-User-Netzwerk nachhaltige Tool-Adoption sicherstellt.

29.08.2025 27 min

Zusammenfassung & Show Notes

In dieser Episode von „Smart Hacks für IT-Projektmanager“ spricht Gastgeber Andreas Weller mit Robert Klein, Senior Manager IT Infrastructure & Digital Transformation bei GlaxoSmithKline (GSK) in Deutschland und Ungarn.

Robert Klein verantwortet den Aufbau skalierbarer IT-Strukturen in stark regulierten Produktionsumgebungen und stellt dabei eine Frage immer wieder ins Zentrum: Wie bringe ich meine Nutzer dauerhaft auf Geschwindigkeit?

Im Gespräch erläutert er, warum IT-Projekte oft an unterschätzter Komplexität und fehlender Änderungsbereitschaft scheitern und zeigt drei praxisnahe Hacks:

(1) Personas sauber definieren und jedem Stakeholder klarmachen, was für ihn persönlich drin ist;
(2) Showcases und Sandboxes aufsetzen, in denen Anwender mit ihren eigenen Daten gefahrlos experimentieren;
(3) ein mehrstufiges Key-User-Framework etablieren, das Power- und Senior-User systematisch in Support-, Schulungs- und Verbesserungsprozesse einbindet.

So entsteht ein Pull-Effekt, der Akzeptanz fördert und kontinuierliche Optimierung ermöglicht.

📢 Episode: „Vom Tool zur Wirkung: Drei Bausteine für gelungene IT-Einführung“

🎙 Gast: Robert Klein – Senior Manager IT Infrastructure & Digital Transformation, GlaxoSmithKline (GSK)
🎙 Gastgeber: Andreas Weller – Managing Director, Sidekick Network GmbH

🎯 Thema: Wie man mit Personas, Showcases und einem Key-User-Netzwerk nachhaltige Tool-Adoption sicherstellt.

🔍 In dieser Episode erfährst du:

Warum Angst vor Schnelllebigkeit ein Adoption-Killer ist – und wie du sie abbauen kannst.
Wie klar definierte Personas den „What’s in for me?“-Faktor sichtbar machen.
Weshalb Showcases mit Echtdaten Vertrauen schaffen und Widerstände brechen.
Wie ein dreistufiges Key-User-Framework Supportkosten senkt und Innovation beschleunigt.
Welche Soft-Skills IT-Projektmanager stärken müssen, um Change-Prozesse zu führen.

📌 Highlights

⏳ [00:05:01] – Komplexität & Angst als Hauptfallstricke
👥 [00:07:58] – Personas & WIIFM: Kommunikation, die ankommt
🧪 [00:22:00] – Sandbox & Showcases: Akzeptanz durch Ausprobieren
🔑 [00:24:40] – Key-User-Framework: Vom Power- zum Senior-User
🎯 [00:27:42] – Drei Hacks im Überblick & Take-aways

🎧 Jetzt anhören & smarter werden! → [Link zur Folge]

🔔 Links

Gast: Robert Klein https://www.linkedin.com/in/robert-klein-25042710/
Host: Andreas Weller https://www.linkedin.com/in/andreas-weller-a68ba31/
Sidekick Network: https://www.linkedin.com/company/sidekick-network/

Transkript

Hallo und herzlich willkommen bei SmartHacks für IT-Projektmanager. Präsentiert von Sidekick Network, basiert unser Podcast auf der Erfahrung von über 20.000 IT-Projekten. Bist du bereit, direkt zum Punkt zu kommen? Dann lass uns starten. Mein heutiger Gast ist Robert Klein. Er ist Senior Manager und technischer Standort für die Produktionsstätten von Klexos Smith Klein in Deutschland und Ungarn und verantwortet die IT-Infrastruktur und digitale Transformation an den Standorten. Mit seiner Expertise in Capability Building und der Einführung von IT-Tools und ERP-Systemen ist er darauf spezialisiert, interne Stakeholder und Nutzer auf ein gemeinsames Tempo und Verständnisniveau zu bringen. Sein Fokus liegt darauf, nicht nur technische Lösungen bereitzustellen, sondern auch die kontinuierliche und effektive Nutzung der Tools sicherzustellen. Stellen. Robert kombiniert dabei praktisches Wissen mit einem tiefen Verständnis für die Anforderungen moderner IT-Projekte und stellt die zentrale Frage immer wieder: „Wie bekomme ich eigentlich meine Leute dauerhaft auf Geschwindigkeit? Hallo Robert, schön, dass du da bist heute. Hallo Andy, schön, dass ich da sein darf und reden und Antwort stehen kann. Ja, das freut mich auch. In den Projekten, wo du bist, da bringen ja diese IT-Projekte immer neue Tools und Systeme mit sich. Warum aus Aus deiner Sicht scheitern viele trotzdem daran, dann den Mehrwert in der Praxis am Ende wirklich zu realisieren? Super Frage. Lässt sich gar nicht so mit einem einzelnen Satz beantworten. Es gibt ja mehrfache Gründe. Sicherlich ist einer der Hauptpunkte anzuführen, dass viele die Komplexität unterschätzen. Ein anderes Thema ist Angst, die jetzt unterschiedlich sein kann. Es kann Angst sein, der Sache näherzuwerden. Ist aber auch häufig eine Angst, dass sich die Technologie zu schnell ändert und dementsprechend man irgendwas verpassen kann. Also nach dem Motto: „Wir haben eine riesige Iteration, jedes Jahr eine neue Version. Die Industrie hat heutzutage Ich sage, Produktzyklen, die wir in der Vergangenheit nie gesehen haben. Und dadurch entsteht natürlich immer ein Bedenken: „Wenn ich heute in den Weg einschlage, habe ich Mugen, eventuell das zurückzudrehen und muss einen neuen Weg einschlagen. Du meinst jetzt die Angst bei bei dem Verantwortlichen? Sowohl als auch. Also auf der einen Seite beim Entscheidungsträger, der sagt: „Dieses Projekt möchte ich jetzt umsetzen, mit dem Scope, mit dem zeitlichen Rahmen und auf der anderen Seite aber auch beim Kunden, also bei dem Kunden, der das am Endeffekt anwenden soll. Der Endnutzer? Der Endnutzer, der natürlich jetzt nicht unbedingt sich von vornherein schon vorstellen kann: „Welche Kompetenz brauche ich denn dazu? Gehe ich heute in die richtige Richtung? Wir kennen alle Entwicklungspläne von Mitarbeitern. Das wird irgendwo im Jahresrhythmus definiert und dann kommt natürlich man schnell an den Punkt und sagt: „Was muss ich denn morgen wissen? Bringen wir das überhaupt was? Oder „Wo muss ich hin? – in der Weiterbildung. Genau. Da sagt der erste: „Ja, du musst die Anwendung kennen. Aber die Anwendung ist gar nicht der ausschlaggebende Punkt. Das ist das, was heute in einem stinkenden normalen IT-Projekt als Standardpunkt im Projektplan drin steht. Ich schule meinen Mitarbeiter, meinen Anwender auf das Tool. Die Herausforderung ist aber in dem Prozess, wo das Tool angewandt wird, der ja auch einer Änderung unterliegt, der kontinuierlich verändert wird, zu verstehen, wo das sich hin entwickelt und auf der anderen Seite natürlich auch seine eigenen Limitierungen einzusehen, weil der Mensch ist nur begrenztaufnahmefähig. Jetzt ist immer die Frage: Welche Zielgruppe adresse ich mit dem Projekt? Ist das jetzt jemand, der auch in seinem Geschäftsprozess permanenten Änderungen unterlegen ist? Oder ist das jetzt jemand, der immer das Gleiche macht? Der Apotheker, der hat seit in x Jahren immer den gleichen Ablauf. Wenn ich dem jetzt mit dem IT-Projekt, mit der Digitalisierung, was auf den Tisch lege, dann hat er eine andere Änderungsbereitschaft als, ich sage jetzt mal, der klassische IT-Lop per se, der ja schon seit Jahrzehnten getrieben ist durch den Wechsel der Tools und der Produkte. Also wir müssen sozusagen weitergehen als einfach nur eine Schulung, so wie es typischerweise gemacht wird. Wir schicken die alle durch eine Schulung und dann wird sich das schon lösen. Deswegen ist für uns, und das sehen wir im Unternehmen, sehr stark dieses allgemeine integrierte Änderungsmanagement, Change Management, so existenziell, weil das fängt eben nie am Tool an, sondern das geht über Prozesse, über die Personen, all solches weiter. Und ich denke mal, ein Projekt leider muss dort existenziell Bezug zunehmen, wie ist das Mindset in dem Unternehmen, wo ich das Projekt umsetze? Das ist natürlich nicht überall gleich. Da hat jeder eine andere Maturity-Kurve Level oder Maturity Level. Das ist sicherlich erst mal schon wichtig für den Projektleiter zu verstehen, wie sieht jetzt mein Stakeholder aus? Ich spreche ja auch immer von der englischen Phrase, aber what's in for me. Genau. Das ist natürlich jetzt vielleicht ein bisschen eine Frage: Wo kommt das her? Was will man damit erreichen? Aber man kriegt dem Gegenüber, den Kunden, am besten, indem man dem erklärt, was für ihn persönlich drin ist. Jetzt nie was für das Unternehmen drin ist, sondern was für die ihn persönlich drin ist. Und das ist häufig nie selbsterklärend, weil man dort vielleicht mit irgendwelchen Phrasen die Ecke kommt, das Projekt zu begründen oder überhaupt erst mal auf die Strecke zu bringen, sondern da muss ich andere Leute überzeugen, als den Menschen, der irgendwo an der Linie, an der Maschine oder irgendwo im Feld unterwegs ist. Kannst du dich die gleichen Taktiken verändern? Nein, und das ist echt eine große Herausforderung, sich in diese Person reinzuversetzen. Dann definiere ich irgendwo meine Personas daraus. Die können eben unterschiedlichster Couleur sein und wenn ich den explizit benennen kann, das ist für dich drin. Das ist der Mehrwert, den du bekommst. Das kann Wegfall von sinnfreien Tätigkeiten sein, die poher manueller Leistung sind, wo ich jetzt nie irgendwie groß drunter nachdenken muss. Das kann aber auch sein, ich mache für den das Leben in der Datenauswertung, in der Analyse einfach, weil ich schlage denen gewisse Dinge dann automatisch vor. Das ist schon eine Herausforderung, das von vornherein mit abzubilden und herauszuarbeiten. Ich sage jetzt mal, gibt es unterschiedliche Praktiken dazu. Wer macht dann so einen Kommunikationsplan? Der erste Punkt ist sicherlich im Design Thinking unterwegs zu sein. Wir tendieren, Gerade das deutsche Ingenieurwesen tendiert dazu, die Lösung schon vor dem Problem zu kennen. Da wollen wir aufs Tachet jetzt jetzt schreiben. Auf der anderen Seite, der Kommunikationsplan spielt eine Rolle im Sinne von: Wie häufig brauche ich wen? Also: Wie häufig hole ich den ab? Reicht es, wenn ich dem eine E-Mail schreibe? Reicht es, wenn ich dem ein Video als Self Service zur Verfügung stelle? Wann will der in die Situation kommen, dass ich es anfasse? Also das ist wirklich das mit meinen eigenen Daten, mit denen ich was anfangen kann, die jetzt nie irgendwie konstruiert durch irgendeine Sandbox oder Demologik von irgendeinem weit weg entstanden sind, sondern wo kann ich selber mit meinen eigenen tagtäglich benannten Daten umgehen? Aber ihr verbindet sozusagen schon das Thema, dass ihr sagt, wir haben die Präsentation oder dieses Vorgehen auf Managementebene, das Ding überhaupt zum Leben zu erwecken. Und dann prägt ihr das runter bis zum Endnutzer und sagt, wir haben jetzt Vision, Strategie, aber wir haben sozusagen auch den Alltägliches. Wir wissen, wo du stehst und wie wir dich abholen, wie wir die Brücke bauen. Wir unterscheiden jetzt nie von einem IT-Projekt zu einem x-beliebigen anderen Projekt. Die sind alle in das gleiche Framework eingebunden und das Framework speist sich erst mal durch eine Unternehmensstrategie, die dann eben auf Kertalsweise auf KPIs suchen, worunter gebrauchen wird. Da orientiert man sich sehr stark an den Lean-Prozessen, die schon zu Toyota-Zeiten irgendwo in der Industrie etabliert worden sind. Was wir aber Was wir da merken, ist, dass dieses IT-Wording, ob das jetzt aus der agilen oder aus einer Wasserfalllogik rauskommt, immer noch so ein bisschen unique ist, also eindeutig ist oder nicht so einfach für den Nutzer zu verstehen ist. Und dann merkt man, die Sprache ist nicht unbedingt die gleiche. Also jetzt nicht im Deutsch, Englisch, Spanisch irgendwas, sondern die Fachsprache ist nicht immer gleich. Deswegen ist es schon wichtig, diesen Kommunikationsplan zu haben: Wen möchte ich über welches Medium wann und vielleicht wie häufig erreichen? Mit den Personas, das habe ich, ich glaube, noch keinem einzigen Unternehmen gesehen, dass sich Gedanken gemacht wurde, welche Personas, außer jetzt, man macht eine Stakeholder-Liste und sagt, das ist X, Y, Z, aber so, wie kriege ich die Person? Wie tickt die? Wir sehen das relativ schnell in unserem Strategieumfeld. Welches Tool möchte ich für welchen Prozess strategisch tendenziell einsetzen? Und wie kriege ich den Entscheidungsträger abgeholt? Der Entscheidungsträger ist aber auf dem Papier der einzelnen Personen im Prozess auch noch irgendwo. Aber unterm Strich ist nicht er derjenige, der das Ganze beeinflusst, sondern er ist vielleicht der, der die letzte Unterschrift runtergibt. Sondern viel interessanter ist der, der es tagtäglich im Umfeld verwendet. Und da habe ich natürlich unterschiedliche Personas. Das kann jetzt irgendein Produktionsdokumentationstool sein oder ein Maintenance-Dokumentationstool, wo ich schon mal per se unterschiedliche Leute drin habe. Ich habe den, der das Execution macht. Ich habe der, der das Scheduling macht. Ich habe den, der das KPI, das Reporting irgendwo macht. Und schon habe ich drei unterschiedliche Personas definiert, die noch nie die Person sind, die die finale Entscheidung trifft, aber die beeinflussen Die entscheiden die Entscheidung ganz massiv. Die sind natürlich, gerade auch in der Nachhaltigkeit, immer wieder abzuholen. Wie gehen die tagtäglich mit dem Tooling, sobald es dann eingeführt ist, und was sind denn ihre Schmerzen am Zack? Genau, andersherum, wenn du die nicht abholst, wären das wahrscheinlich die ersten, die sagen: „Ihr habt ja niemand mit uns geredet, wo wird ihr das Tool eingeführt? Und dann entsteht so eine ablehnende Haltung dazu und das führt natürlich zu so einer Unzufriedenheit. Und bei so einer Unzufriedenheit, das sehen wir ja im politischen Umfeld, dann lädt man das erst mal ab, ohne dass man jetzt vielleicht die Energie reinsteckt und sagt: „Ich möchte es jetzt weiter verändern, weiter verbessern. Mir ist bewusst, dass das nicht die 100%-Logik ist und Lösung ist, sondern ich will da aktiv daran arbeiten, das Tool dorthin zu bringen, wo es mir wirklich tendenziell auf Dauer den Mehrwert liefert. Und woran erkennt ihr, dass so ein Endnutzer tatsächlich jetzt wirklich bereit ist oder ready ist, wie man so schön sagt, die Lösung dann auch wirklich zu setzen für sich? Da gibt es auf den Seiten einen formellen Ansatz, zu sagen, okay, für unsere größeren Anwendungen, wir nennen es jetzt Enterprise-Anwendungen, dass wir dann ein gewisses Key User Framework geschaffen haben. Das ist jetzt, sage ich mal, nicht der Standardnutzer, sondern der, der schon ein bisschen advanced ist. Power User. Ja, man könnte es einen Power User nennen. Und dann gibt es noch, ich sage jetzt mal, einen gewissen Senior User oder Prozessverantwortlichen, der das wirklich verinnerlicht hat, der genau weiß, dieses Tool wird in dem Prozess so und so benutzt. Der kann dir auch im Troubleshooting relativ schnell helfen. Wir kennen das ein bisschen aus dem IT-Umfeld, wo ich mit dem Level 1, Level 2, Level 3-Support unterwegs bin. Am Ende ist das nichts anderes, bloß auf der User-Seite, auf der Kunden-Seite etabliert. Genauso bildet man dann auch die Herausforderung mit dem Tool relativ gut ab. Ist es jetzt ein reines How-to-Thema, wo vielleicht der User selber drauf kann, Self-Service, irgendwo Level-0-Support, und er geht in eine Knowledge-Base, sucht sein Problem raus, findet das? Da gibt es inzwischen sehr, sehr gute KI-basierte Systeme, die das in einem eigenen Wording mit unterstützen. Und auf der anderen Seite helfen diese Cues auch ungemein, Probleme zu kanalisieren. Was wir immer wieder merken, ist, der Mensch ist relativ gut in Symptomen beschreiben. Ich kann die drucken. Ich nehme das mal als Beispiel, weil das immer relativ einfach ist. Ich kann nicht drucken, sagt noch nichts darüber aus, welcher Prozess ist davon beeinträchtigt, was ist meine Herausforderung in meiner Zielerreichung für in der täglichen Arbeit, der sagt nie, wo das ist. Man tendiert dann relativ schnell, aber wenn man dieser Nutzer gehört, in diese Abteilung, könnte dieser Prozess sein, könnte dieses technische Hintergrundund Problem sein. Aber das hilft nie wirklich, strategisch unterwegs zu sein, das zu verändern, das zu verbessern, sondern das adressiert wirklich nur die pure Störung. Viel interessanter ist, wenn wir an den Punkt kommen, dass der Power User, der Process Owner in der Lage ist, auch das dahinterliegende Problem zu verstehen und zu artikulieren. Das größer Blick hat, sozusagen. Genau, vor allen Dingen das zu artikulieren, weil sonst Ist, ist es wieder nur Firefighting an der technischen Störung. Das hilft ungemein. Wenn man dieses Feedback bekommt, zeigt man oder sieht man, dass das Team ready ist, dass die Prozessbeteiligten ready sind, das wirklich zu akzeptieren und auch tagtäglich zu nutzen. Das heißt aber auch, ihr müsst ja sehr viel im Austausch mit dem sein und überhaupt feststellen, dass die so weit sind. Das können wir jetzt nicht aus einer klassischen IT-Sicht erreichen. Das ist richtig. Dafür sind heutzutage IT-Organisationen viel zu schmal aufgestellt. Sondern wichtig ist dann dort, dass die Organisation, die Unternehmensstruktur das mit abbildet. Man sieht das in vielen Unternehmen, da wird dann Digital Lead da und Digital Kompetensträger da. Da wird auf immer Funktion geschaffen oder umbenannt, wo man erst mal gar nicht so richtig zuordnen kann: Was machen die den ganzen Tag? Aber das eine ist der Name und das andere ist die Rolle, die die ausüben. Und das ist vielleicht auch so ein Punkt. Gerade in größeren Organisationen sieht man das, das ist so viel, so komplex, dass ich noch mal eine Struktur irgendwie brauche. Sei es jetzt eine rollenbasierte Struktur, dass ich genau weiß, dieser Mitarbeiter hat diese Funktion mit den und den Rollen und auf der anderen Seite auch Dass ich meine Prozesse dokumentiere. Jetzt sagt der ihnen: „Ich bin im regulierten Umfeld, gerade dort, wo ich herkomme, ist es ein super reguliertes Umfeld. Das sind alle Prozesse dokumentiert, das stimmt. Die sind aber sehr textuell dokumentiert. Und Interessant wird es, wenn man in Prozesse rein und raus zoomen kann. Also von einer High-Level-Logik, ich will von A nach B fahren, das ist jetzt ein High-Level, aber wenn ich dann in den Low-Level-Bereich reinkomme, was brauche ich dazu? Wen Wo ist der Zugriff dazu? Wann muss ich wo, wie sein? Und selbst die müssen ja nicht up to date sein. Das kann ja vor 20 Jahren mal gemacht worden. Das ist natürlich ein Punkt, wo wir in einem Produktionsbereich durchaus eine Komplexität haben. Die kriegst du immer noch Tool-basiert unterstützt. Und da eben Mitstreiter auch in den jeweiligen Bereichen, in den Teams zu haben, die nicht in IT sitzen, ist da existenziell. Also dieses Capability Building und dann auch Mapping in den Nicht-IT-Rollen ist wirklich ein Schlüssel dorthin. Und wenn man jetzt noch einen Schritt weiterdenkt über Methoden und Werkzeug jetzt aus deiner Erfahrung, die du einsetzt, und sicherzustellen, dass sozusagen auch dauerhaft dann, wenn das Ding einmal zum Leben erweckt wurde, dass die Anwender und Stakeholder dann auch dauerhaft mit dem Tool Schritt halten können. Das fand ich ganz interessant im Vorgespräch. Wie machst du das oder wie macht ihr das? Welchen Ansatz habt ihr da? Das matcht so ein bisschen zu dem, was ich gesagt habe. Es ist natürlich immer die Frage: Wie sieht die Organisationsstruktur aus? Welchen Änderungsmindset haben die? Daraus resultiert natürlich auch, ob es jetzt auf Projekt oder auf Tagesgeschäft ist, brauche ich dedizierte Ressourcen oder kann ich irgendwo gemischte Ressourcen benutzen. Das klingt jetzt ein bisschen komisch erst mal. Also Leute, die sowohl im Tagesgeschäft als auch im Projektgeschäft irgendwo zu Hause sind. Das ist durchaus eine existenzielle Frage. Je größer das Projekt ist, desto eher denke ich, ich brauche dedizierte Ressourcen, habe aber dann das Risiko, einen Disconnect herzustellen zu meinem Tagesgeschäft. Das passiert tagtäglich in unserem Projektfeld. Und dort muss man durchaus auch nachjustieren können, dass man das jetzt nicht monolithisch irgendwie sieht, sondern die Projekt, die Organisationsstruktur dynamisch anzupassen. Jetzt wird der nächste gesagt: „Na ja, weniger als mehr. Dass ich sage, ich zerteile meine Tätigkeiten immer mehr, da kann ich es noch händeln, alles, was dann in einer gewissen Größe abgebildet wird, generiert eine Komplexität, das kann niemand mehr irgendwie begreifen. Das klingt jetzt so einfach, aber das ist natürlich total schwer, weil gerade im Projektumfeld habe ich eine klare Scoping-Formulierung und will den Scope natürlich auch erreichen. Und Da ist jetzt sicherlich eher die Frage: Verstehen alle Beteiligten die Methodik, wie ich mich der Sache nähere? Der klassische Ingenieur im Engineering-Bereich würde vielleicht sagen: „Wir machen wie immer Wasserfallmodelle. Ich weiß genau, wo ich hin will, wie ich da hinkomme. Im IT-Umfeld wird man sagen: „Lass uns das agil irgendwo umsetzen und wir sind total grün. Man merkt aber relativ schnell, dass dort die Mischung macht es. Natürlich auch der, der im Projekt beteiligt ist, dass der diese Methoden kennt. Was wir immer wieder merken, ist, das ist ein Fachexperte aus Bereich XY. Den nehme ich jetzt einfach, werfe den in das Projekt rein und dann ist das ein Selbstläufer, der kennt ja seinen Prozess. Und da kennt die Projektmanagementmethoden halt nicht. Dementsprechend ist es schon wichtig, dass wenn man so was tut, die Leute auf einen einheitlichen Nenner bringt und brieft. Ja, ich würde mal noch einen Schritt zurückgehen, noch einmal. Wir sind jetzt, wenn es läuft, aber wir hatten noch ein interessantes Thema, das Thema Showcases. Das haben wir jetzt völlig übersprungen. Aber das würde ich gerne noch mal anschneiden, weil ich glaube, das ist auch ein super Hack für unsere Zuhörer. Ihr stellt sogenannte Showcases zur Verfügung, wo Nutzer schon mal mit dem Tool, ich versuche es jetzt wiederzugeben, wie ich es verstanden habe, probieren kann, aber nicht einfach nur mit einem sinnlosen Demo-Tool, sondern er kann sogar seine eigenen Daten verwenden. Das ist richtig. Natürlich ist es immer ein bisschen abhängig, welches Tool das ist. Ja. Ich nehme jetzt mal die zwei letzten größeren Projekte, die sehr im Execution-Bereich unterwegs waren. Dort war das ein Schlüssel zum Erfolg, zu sagen, man lässt den Nutzer auf eine Sandbox, auf eine Testumgebung direkt ran, was man jetzt nicht immer üblicherweise macht. Vielleicht im Trainingsumfeld ja, aber jetzt nicht im Experimentier-oder Showcase-Umfeld und lässt ihn wirklich mal einfache Dinge ausprobieren. Begleitet ihn vor allen Dingen, also nicht nach dem Motto: „Hier hast du, probieren wir aus. Du kannst dich einlocken. Das bringt nichts, sondern den muss er schon an die Hand nehmen. Den muss er schon ein bisschen mehr erklären, als nur „Melde dich an. Das hat sozusagen einen kleinen Peek in seine Zukunft. Genau, dass er quasi schon mal mitbekommt, wo entwickelt sich das hin? Damit kann ihn das natürlich sacken lassen. Wir haben vor uns am Anfang der sagt, die Welt dreht sich zu schnell. Der braucht so ein bisschen ein Teasing, der muss ein bisschen vorbereitet werden, der muss wissen, wie er sein Development irgendwie gestaltet. Und das hilft natürlich da ungemein. Und der Mensch ist nun mal haptisch geprägt. Das ist eine digitale Lösung, immer schwer anzufassen. Aber visuell ja sichtbar. Aber der braucht was, mit dem er sich identifizieren kann. Und der hilft das natürlich nie, wenn er mit irgendwelchen Demodaten von irgendeiner Prozess XY, mit denen er gar nichts zu tun hat. Die auch alle perfekt sind wahrscheinlich, damit das Thema funktioniert. Natürlich. Sondern für den ist schon wichtig, dass er seine Informationen da drin sieht, dass er seinen Prozess mit dem Tool abbilden kann. Wenn er das jetzt nicht direkt mit seinem Prozess machen kann, hilft aber auch irgendein Spielsachverhalt zu verwenden, den jeder kennt. Wir haben jetzt mal ein simples Beispiel. Wir haben Kriegsbreite gekauft mit dem Execution System. Das geht schon los: Wie strukturiere ich meine Arbeitsanweisungen? So, dass das eben eine Maschine verstehen kann. Der Mensch ist da viel multidimensionaler unterwegs. Der denkt sich bei vielen Sachen noch was dazu, währenddessen in der puren Logik-Abbildung, in so einem Execution System, wo sich wirklich Schritt genau unterwegs ist. Also wie so ein prompt, in ChatGPT, da musst du schon ein bisschen mehr Fleisch dazu geben. Man muss ein bisschen mehr außenherum bauen. Aber das hilft so ungemein, dann die Akzeptanz herzustellen. Und wenn die Akzeptanz da ist, ist der Anwender drin. Der ist dann wirklich dabei und nicht bloß: „Das hat sich jetzt irgendwo einer ausgedacht und ich kriege das jetzt übergeholfen und ich muss das jetzt machen, sondern das ist eher andersherum. Der will das dann auch. Der will auch sein Erlebnisteilen dann erfinden. Wir sehen das durchaus. Der erste Schritt ist relativ Bumby und schwer, den erst mal in diese Überzeugung zu kriegen. Wenn ich den aber habe, entsteht ein relativ schneller Pull-Effekt. Der zieht dann selber. Der will häufig schneller, als wir in der Lage sind, das zu liefern. Und dann ist schon alles erreicht. Da darf man den dann nicht zu lange hinhalten. Das ist auch gefährlich. Wann lässt du ihn drauf? Auf der anderen Seite finde ich auch in der Beziehung spannend, weil Leute wollen an ihrer Erfahrung teilen und wollen ja auch sagen, im Endeffekt, vielleicht nicht böse gemeint, aber schon zu ihren Kollegen: „Ich hatte Zugang, ihr nicht. Ja, da ist es stolz sein. Es soll stolz drauf sein, dass man da überhaupt ausgewählt wurde dafür und dass man selber weiß ja schon, wie das neue System aussieht. Das ist ja auch so was, dann hebt man die auch auf eine positive Stufe, wenn man es so will. Das ist richtig. Und Dann entstehen natürlich auch Ideen, die man in dem Projekt schon mal mit thematisieren kann. Das muss jetzt vielleicht nicht in den Projektscope reinfallen, aber dann habe ich ja schon die Liste an Improvement-und Verbesserungsideen für danach. Die du sowieso bekommen wirst, hast du schon mal … Aber die hast du schon identifiziert. Das stimmt. Das ist sicherlich ein anderes Thema: Wie geht so ein Unternehmen mit einer derartigen Änderungskultur um? Wie akzeptiert man diese permanente Änderung? Wir sehen das ja im öffentlichen, im politischen Bereich ist diese VUCA-Welt irgendwo präsent ist. Und selbst im heimischen Umfeld kann man sich da vorne nicht mehr verschließen. Und wenn das dann natürlich über die dienstlichen Sachen genauso auf ihn einströmt, ist das schon eine Herausforderung, diese ganzen unterschiedlichen Tendenzen erst einmal wahrzunehmen und dann eben auch adäquat darauf reagieren zu können. Bereit zu sein, permanent einen Wechsel ausgesetzt zu sagen. Die Industrie macht es uns nie einfach. Nein. Peter, bis zum Telefon, jedes Jahr soll man ein neues kaufen. Das geht bei Autos weiter. Wenn man sich die Autoindustrie anguckt, dort wären heutzutage jährliche Modelle veröffentlicht, die nur mit leichten Nuance und die Chinesen machen es uns vor. Das ist natürlich bei diversen IT-Anwendungen permanent der Fall. Es ist natürlich schon mal schön, wir reden da ja von Waves, wo man sagt, man hat eine vierteljährliche oder eine jährliche Wave, gewisse Dinge erst mal einzuspielen. Aber das ist ja nur der optimale Zustand. Wir wissen, dass das in der Realität immer noch anders aussieht, weil ich ja nicht nur eine Anwendung habe, sondern mehrere. Und wenn ich dann mehrere parallel in unterschiedlichen Wave-Rhythmen unterwegs bin, muss ich den natürlich mitnehmen und deswegen ist diese Änderungskultur so wichtig. Das finde ich auch eine gute Zusammenfassung. Vielleicht noch mal auf die drei Hex eingehen. Jetzt kommen wir langsam zum Schluss. Also erstens klare Benennungen und Definition einer Persona und dann eben dieses auf der Ebene kommunizieren, was ist für die drin, aber eben von oben nach unten oder unten nach oben in beide Richtungen aber auch klar zu verbinden mit der Strategie und der Vision. Worauf zahlt das eine und was habe ich davon? Dann das zweite, was wir gerade besprochen haben im Grunde genommen dieses Showcases, finde ich einen coolen Ansatz. Macht man, denke ich, viel zu wenig, weil man auch immer unter Zeitstress steht. Man hat immer, go life ist dann und dann. Man hat gar keine Zeit, die da noch Zeit dafür einzuplanen. Und dann aber auch der dritte Eck, wo ich sage, das ist cool, immer dieses Mantra zu befolgen, eine Kombination aus weniger als mehr, aber auch diese Key-Nutzer frühzeitig damit reinzuholen und bei der stetigen Verbesserung dann auf dem Netzwerk aufzubauen. Diese Key-User-Logik, vielleicht noch als Abschluss, das kostet Zeit. Das kostet Man hat auf jeden Fall einen gewissen Aufwand. Man muss bereit sein, inzufahren, zu telefonieren. Genau, und man muss mit den Leuten reden. Ich hatte das ein bisschen in der Vorbereitung versucht, zu reflektieren. Kommunikation klingt immer so einfach, aber Kommunikation ist eben nicht nur das, was ich sage, sondern wem und wie ich das sage und vor allen Dingen, wie ich den Rückkanal wahrnehme. Das ist nie jedermanns Sache. Der ITler tendiert eher da Wo wir perfekt drin sind zu sein. Zu reduzierter Kommunikation. Das ist sicherlich auch eine Sachbarkeit, wo wir in der Branche durchaus noch Nachholbedarf haben. Ist jetzt kein Hard-Skill, ist ein klassischer Soft-Skill. Ja, das sagen wir immer, 90% unserer Projekte sind Kommunikation. Ist vielleicht auch ein gutes Schlusswort, weil der mit Roboter auch gerne kommunizieren will, in den Shownotes findet ihr seine Kontaktdaten. Gerne auf ihn zugehen. Ansonsten könnt ihr uns auch gerne weiter folgen. Dann bedanke ich mich euch recht herzlich beim Roboter und hoffe, wir sehen uns bald wieder. Gerne. Danke für die Einladung. Mach’s gut. Tschüss. Ciao, ciao.. Ciao, ciao.