<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title><![CDATA[Forum von Schübeler Consulting - 🧭 Organisationsentwicklung & Change ]]></title>
		<link>https://forum.schuebeler-consulting.de/</link>
		<description><![CDATA[Forum von Schübeler Consulting - https://forum.schuebeler-consulting.de]]></description>
		<pubDate>Sat, 22 Aug 2026 12:51:31 +0000</pubDate>
		<generator>MyBB</generator>
		<item>
			<title><![CDATA[Pilotgruppe wählen: weder die Lautesten noch die Stillsten]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-97.html</link>
			<pubDate>Wed, 13 May 2026 09:36:43 +0200</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-97.html</guid>
			<description><![CDATA[Wer entscheidet bei Ihnen, wer die neue Software zuerst bekommt? Häufig sind das die Lauten — die, die in der Teamsitzung am schnellsten den Finger heben. Manchmal die Stillsten, weil sie ja angeblich "sowieso alles mitmachen". Beides führt in die Irre.<br />
<br />
Die Lauten sind oft die, die später am lautesten meckern, wenn etwas nicht reibungslos läuft. Die Stillen sagen nichts und tun nichts — Sie merken erst nach 8 Wochen, dass das System in der Pilotgruppe gar nicht genutzt wurde.<br />
<br />
Ich achte in der Pilotgruppe auf drei Dinge: Erstens jemanden, der den Alltagsprozess wirklich beherrscht, also nicht den Werkstudenten. Zweitens jemanden, der bereit ist, Fehler im Tool zu finden und zu melden, statt sie zu umgehen. Drittens jemanden, der im Team Anerkennung genießt — egal in welcher Funktion. Diese Person ist später Ihr Multiplikator.<br />
<br />
Wichtig: Der Pilotgruppe muss klar sein, was ihre Aufgabe ist. "Mal ausprobieren" reicht nicht. Schreiben Sie auf, was getestet wird, bis wann, mit welchem Ergebnis. Sonst hängen Sie nach 3 Monaten noch im Pilot und keiner weiß, ob das Tool taugt.<br />
<br />
Wie wählen Sie bei sich Pilotnutzer aus — nach Funktion, nach Persönlichkeit, oder nach Lust auf Neues?]]></description>
			<content:encoded><![CDATA[Wer entscheidet bei Ihnen, wer die neue Software zuerst bekommt? Häufig sind das die Lauten — die, die in der Teamsitzung am schnellsten den Finger heben. Manchmal die Stillsten, weil sie ja angeblich "sowieso alles mitmachen". Beides führt in die Irre.<br />
<br />
Die Lauten sind oft die, die später am lautesten meckern, wenn etwas nicht reibungslos läuft. Die Stillen sagen nichts und tun nichts — Sie merken erst nach 8 Wochen, dass das System in der Pilotgruppe gar nicht genutzt wurde.<br />
<br />
Ich achte in der Pilotgruppe auf drei Dinge: Erstens jemanden, der den Alltagsprozess wirklich beherrscht, also nicht den Werkstudenten. Zweitens jemanden, der bereit ist, Fehler im Tool zu finden und zu melden, statt sie zu umgehen. Drittens jemanden, der im Team Anerkennung genießt — egal in welcher Funktion. Diese Person ist später Ihr Multiplikator.<br />
<br />
Wichtig: Der Pilotgruppe muss klar sein, was ihre Aufgabe ist. "Mal ausprobieren" reicht nicht. Schreiben Sie auf, was getestet wird, bis wann, mit welchem Ergebnis. Sonst hängen Sie nach 3 Monaten noch im Pilot und keiner weiß, ob das Tool taugt.<br />
<br />
Wie wählen Sie bei sich Pilotnutzer aus — nach Funktion, nach Persönlichkeit, oder nach Lust auf Neues?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Wer im Team braucht Entwicklung — und wer braucht Klarheit?]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-22.html</link>
			<pubDate>Thu, 04 Dec 2025 19:47:28 +0100</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-22.html</guid>
			<description><![CDATA[Bei Veränderungen wird oft pauschal von „Mitarbeiterentwicklung" gesprochen. Ich finde das zu unscharf. In jedem Team, das ich begleite, gibt es grob drei Gruppen, und die brauchen sehr unterschiedliche Dinge.<br />
<br />
Die erste Gruppe will sich entwickeln und nimmt Veränderung als Chance. Diese Menschen brauchen Aufgaben, Vertrauen und Spielraum. Wer sie bremst, verliert sie.<br />
<br />
Die zweite Gruppe ist neutral. Sie macht ihre Arbeit gut, hat aber keine Lust, die nächste Karrierestufe zu nehmen. Diese Menschen brauchen Klarheit, wie ihre Rolle nach der Veränderung aussieht, und die Sicherheit, dass sie nicht zwangsbeglückt werden. Sie sind oft das Rückgrat der Abteilung. Wer sie übersieht, weil sie nicht laut sind, macht einen teuren Fehler.<br />
<br />
Die dritte Gruppe kann oder will sich nicht verändern. „Nicht können" ist der kleine Bruder von „nicht wollen", dahinter steckt fast immer Angst. Hier braucht es ehrliche Einzelgespräche und die Bereitschaft, auch unbequeme Wege zu gehen — andere Aufgaben, Teilzeit, im äußersten Fall Trennung. Das ist Führungsarbeit.<br />
<br />
Ich warne ausdrücklich davor, Gruppe 2 und 3 in einen Topf zu werfen. Genau das passiert, wenn Führungskräfte nur mit den Lauten reden. Was hilft Ihnen, in Ihrem Team diese drei Gruppen voneinander zu unterscheiden?]]></description>
			<content:encoded><![CDATA[Bei Veränderungen wird oft pauschal von „Mitarbeiterentwicklung" gesprochen. Ich finde das zu unscharf. In jedem Team, das ich begleite, gibt es grob drei Gruppen, und die brauchen sehr unterschiedliche Dinge.<br />
<br />
Die erste Gruppe will sich entwickeln und nimmt Veränderung als Chance. Diese Menschen brauchen Aufgaben, Vertrauen und Spielraum. Wer sie bremst, verliert sie.<br />
<br />
Die zweite Gruppe ist neutral. Sie macht ihre Arbeit gut, hat aber keine Lust, die nächste Karrierestufe zu nehmen. Diese Menschen brauchen Klarheit, wie ihre Rolle nach der Veränderung aussieht, und die Sicherheit, dass sie nicht zwangsbeglückt werden. Sie sind oft das Rückgrat der Abteilung. Wer sie übersieht, weil sie nicht laut sind, macht einen teuren Fehler.<br />
<br />
Die dritte Gruppe kann oder will sich nicht verändern. „Nicht können" ist der kleine Bruder von „nicht wollen", dahinter steckt fast immer Angst. Hier braucht es ehrliche Einzelgespräche und die Bereitschaft, auch unbequeme Wege zu gehen — andere Aufgaben, Teilzeit, im äußersten Fall Trennung. Das ist Führungsarbeit.<br />
<br />
Ich warne ausdrücklich davor, Gruppe 2 und 3 in einen Topf zu werfen. Genau das passiert, wenn Führungskräfte nur mit den Lauten reden. Was hilft Ihnen, in Ihrem Team diese drei Gruppen voneinander zu unterscheiden?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Wenn das Tool nicht ankommt: Sechs typische Gründe und was dahintersteckt]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-21.html</link>
			<pubDate>Fri, 07 Nov 2025 18:31:50 +0100</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-21.html</guid>
			<description><![CDATA[Eine neue Software ist eingeführt, das Team nutzt sie nicht oder nur halbherzig. Ich habe das oft genug gesehen, um ein paar Muster aufzulisten. Das sind die häufigsten Gründe, fast nie liegt es an „die wollen halt nicht":<br />
<ul class="mycode_list"><li>Das Werkzeug löst nicht das Problem, das die Mitarbeitenden tatsächlich haben.<br />
</li>
<li>Die alten Wege sind weiter offen, also wird der bequemere gewählt.<br />
</li>
<li>Die Einführung war zu schnell, das Team hatte keine Zeit, die eigenen Prozesse anzupassen.<br />
</li>
<li>Stammdaten, Vorlagen und Berechtigungen sind nicht sauber, das Tool fühlt sich „kaputt" an.<br />
</li>
<li>Es gibt keinen Ansprechpartner im Team, der das Tool kann und Fragen beantwortet.<br />
</li>
<li>Die Führungskraft selbst nutzt es nicht sichtbar.</li>
</ul>
<br />
Der letzte Punkt ist der wichtigste und der unbequemste. Wenn die Führungskraft weiter ihre Excel pflegt und dann fragt, warum das Tool nicht angenommen wird, ist das ein Strukturproblem auf Führungsebene. Mitarbeitende lesen das Verhalten der Führung sehr genau.<br />
<br />
Mein Vorgehen, wenn ein Tool zäh läuft: Erst zwei Wochen mitlaufen lassen und beobachten, dann ehrlich entscheiden, ob das Tool noch das richtige ist, der Prozess nachgezogen werden muss oder die Einführung schlicht nachgeholt gehört. In den meisten Fällen ist es das Letzte.<br />
<br />
Kennen Sie das aus eigener Erfahrung? An welchem der sechs Punkte hat es bei Ihnen gehakt?]]></description>
			<content:encoded><![CDATA[Eine neue Software ist eingeführt, das Team nutzt sie nicht oder nur halbherzig. Ich habe das oft genug gesehen, um ein paar Muster aufzulisten. Das sind die häufigsten Gründe, fast nie liegt es an „die wollen halt nicht":<br />
<ul class="mycode_list"><li>Das Werkzeug löst nicht das Problem, das die Mitarbeitenden tatsächlich haben.<br />
</li>
<li>Die alten Wege sind weiter offen, also wird der bequemere gewählt.<br />
</li>
<li>Die Einführung war zu schnell, das Team hatte keine Zeit, die eigenen Prozesse anzupassen.<br />
</li>
<li>Stammdaten, Vorlagen und Berechtigungen sind nicht sauber, das Tool fühlt sich „kaputt" an.<br />
</li>
<li>Es gibt keinen Ansprechpartner im Team, der das Tool kann und Fragen beantwortet.<br />
</li>
<li>Die Führungskraft selbst nutzt es nicht sichtbar.</li>
</ul>
<br />
Der letzte Punkt ist der wichtigste und der unbequemste. Wenn die Führungskraft weiter ihre Excel pflegt und dann fragt, warum das Tool nicht angenommen wird, ist das ein Strukturproblem auf Führungsebene. Mitarbeitende lesen das Verhalten der Führung sehr genau.<br />
<br />
Mein Vorgehen, wenn ein Tool zäh läuft: Erst zwei Wochen mitlaufen lassen und beobachten, dann ehrlich entscheiden, ob das Tool noch das richtige ist, der Prozess nachgezogen werden muss oder die Einführung schlicht nachgeholt gehört. In den meisten Fällen ist es das Letzte.<br />
<br />
Kennen Sie das aus eigener Erfahrung? An welchem der sechs Punkte hat es bei Ihnen gehakt?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[„Change Management" ist kein Workshop — und auch kein Zaubermittel]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-9.html</link>
			<pubDate>Thu, 19 Jun 2025 22:47:47 +0200</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-9.html</guid>
			<description><![CDATA[Wenn ich von Veränderungsmanagement schreibe, meine ich keine zweitägigen Offsites mit bunten Klebezetteln. Ich meine das normale Verhalten einer Führungsperson: transparent informieren, was das Ziel ist und wie dort hingearbeitet wird. Am besten gemeinsam mit den Mitarbeitenden und angrenzenden Fachabteilungen erarbeiten. Ansprechbar sein. Auch dann, wenn die Antwort lautet: „Ich weiß es noch nicht, ich melde mich am Freitag."<br />
<br />
Guru-Sprache à la „Du musst es nur wollen" halte ich für gefährlich. Sie zerstört Vertrauen bei den Menschen, die ernsthaft Sorgen haben — und die haben fast immer einen sachlichen Kern. Sorge vor neuen Aufgaben, vor Fehlern, vor Bedeutungsverlust, vor Jobverlust. Wer diese Sorgen wegwischt, bekommt entweder Flucht (Kündigung), Kampf (Widerstand) oder Totstellen (innere Kündigung). Alle drei sind teuer.<br />
<br />
Mein praktischer Tipp: Vor jeder Veränderung ein Einzelgespräch mit jedem im Team. 20 bis 30 Minuten reichen. Drei Fragen: Was nehmen Sie aus der Veränderung mit? Was macht Ihnen Sorge? Wo sehen Sie sich in 12 Monaten? Aus diesen Gesprächen entsteht eine ehrliche Landkarte des Teams. Daraus planen Sie weiter, ohne sich nur an der Vorstandsvorlage zu orientieren.<br />
<br />
Wer von Ihnen führt gerade eine Veränderung an und merkt, dass das Team kippt? Was ist das letzte Signal, das Sie gesehen haben?]]></description>
			<content:encoded><![CDATA[Wenn ich von Veränderungsmanagement schreibe, meine ich keine zweitägigen Offsites mit bunten Klebezetteln. Ich meine das normale Verhalten einer Führungsperson: transparent informieren, was das Ziel ist und wie dort hingearbeitet wird. Am besten gemeinsam mit den Mitarbeitenden und angrenzenden Fachabteilungen erarbeiten. Ansprechbar sein. Auch dann, wenn die Antwort lautet: „Ich weiß es noch nicht, ich melde mich am Freitag."<br />
<br />
Guru-Sprache à la „Du musst es nur wollen" halte ich für gefährlich. Sie zerstört Vertrauen bei den Menschen, die ernsthaft Sorgen haben — und die haben fast immer einen sachlichen Kern. Sorge vor neuen Aufgaben, vor Fehlern, vor Bedeutungsverlust, vor Jobverlust. Wer diese Sorgen wegwischt, bekommt entweder Flucht (Kündigung), Kampf (Widerstand) oder Totstellen (innere Kündigung). Alle drei sind teuer.<br />
<br />
Mein praktischer Tipp: Vor jeder Veränderung ein Einzelgespräch mit jedem im Team. 20 bis 30 Minuten reichen. Drei Fragen: Was nehmen Sie aus der Veränderung mit? Was macht Ihnen Sorge? Wo sehen Sie sich in 12 Monaten? Aus diesen Gesprächen entsteht eine ehrliche Landkarte des Teams. Daraus planen Sie weiter, ohne sich nur an der Vorstandsvorlage zu orientieren.<br />
<br />
Wer von Ihnen führt gerade eine Veränderung an und merkt, dass das Team kippt? Was ist das letzte Signal, das Sie gesehen haben?]]></content:encoded>
		</item>
	</channel>
</rss>