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.