Ziele setzen reicht nicht. Zielarbeit ist ein Prozess. (3/11)

Im vorherigen Beitrag ging es um die Frage, ob wir überhaupt Ziele brauchen. Die Antwort war differenziert: Nicht jede Situation verlangt nach einem präzise formulierten Ergebnisziel. Aber Handlungsfähigkeit braucht bewusste Orientierung.

Doch auch ein sinnvolles und klar formuliertes Ziel steuert unser Handeln nicht automatisch. Es kann im Strategiepapier stehen, in einem Workshop beschlossen oder im persönlichen Notizbuch festgehalten sein – und trotzdem im Alltag wirkungslos bleiben.

Denn Ziele zu setzen ist nur der Anfang.

Wenn Ziele leere Hüllen bleiben

Ziele können existieren, ohne unser gegenwärtiges Handeln tatsächlich zu steuern.

Ein formuliertes Ziel ist zunächst nur eine leere Hülle: eine Beschreibung dessen, was einmal sein soll. Mit Leben gefüllt wird diese Hülle erst durch die Bedeutung, die wir dem Ziel geben, durch unsere Bindung daran und durch die Handlungen, mit denen wir es verfolgen.

Die Forschung zur Lücke zwischen Absicht und Verhalten stützt diese Unterscheidung. Paschal Sheeran zeigte in einer Metaanalyse, dass selbst erklärte Absichten nur einen Teil des späteren Verhaltens erklären. Menschen können also durchaus wissen und benennen, was sie erreichen wollen, ohne entsprechend zu handeln. Die Formulierung eines Ziels ist noch keine Garantie für seine Umsetzung.

Ein Ziel, zu dem sich niemand verpflichtet fühlt, bleibt eine Absichtserklärung. Ein Ziel, das aus der Aufmerksamkeit verschwindet, verliert seine steuernde Wirkung. Ein Ziel ohne konkrete Handlung bleibt ein Wunsch. Und ein Ziel, das nicht überprüft wird, kann zur starren Vorgabe werden.

Zielsetzung ist ein Ereignis. Zielarbeit ist ein Prozess.

Das gilt für persönliche Ziele ebenso wie für Organisationen. Unternehmen entwickeln Strategien, vereinbaren Jahresziele und veranstalten aufwendige Workshops. Projekte formulieren Zielsetzungen und erwartete Ergebnisse. Doch nach der Zielsetzung beginnt der Alltag. Neue Anforderungen entstehen, operative Probleme verlangen Aufmerksamkeit und andere Themen erscheinen dringlicher.

Die entscheidende Frage lautet deshalb nicht nur, ob ein Ziel formuliert wurde. Entscheidend ist, was zwischen einem Wunsch, einer Zielentscheidung und ihrer Umsetzung geschieht. Wann wird aus einer erwogenen Möglichkeit ein Ziel, an das wir uns tatsächlich gebunden fühlen? Und wie verändert diese Entscheidung die Art, in der wir denken und handeln?

Genau an diesem Übergang setzt das Rubikon-Modell an.

Vom Abwägen zum Handeln: das Rubikon-Modell

Heinz Heckhausen und Peter Gollwitzer unterscheiden im Rubikon-Modell verschiedene Phasen zielgerichteten Handelns. Das Modell beschreibt damit nicht lediglich eine zeitliche Abfolge. Es zeigt, dass vor und nach einer Zielentscheidung unterschiedliche psychologische Aufgaben zu bewältigen sind.


|Den ganzen Beitrag lesen…

Brauchen wir überhaupt Ziele? (2/11)

Handlungsfähigkeit unter Unsicherheit

Klares Ziel, flexibler Weg“ – so lautete die Leitidee des ersten Beitrags dieser Reihe.

Aber diese Formel enthält eine Voraussetzung, die keineswegs selbstverständlich ist: dass wir unser Ziel bereits kennen.

Was aber, wenn wir zwar spüren, dass sich etwas verändern soll, den gewünschten Zielzustand aber noch gar nicht beschreiben können? Was, wenn sich erst im Handeln zeigt, was überhaupt möglich und erstrebenswert ist? Und was geschieht, wenn wir keine eigenen Ziele bewusst verfolgen? Handeln wir dann tatsächlich ziellos – oder arbeiten wir nur zunehmend an den Zielen anderer?

Die Frage lautet deshalb zunächst:

Brauchen wir überhaupt Ziele, um handlungsfähig zu sein?

Effectuation: Wenn das Ziel erst im Handeln entsteht

Im ersten Beitrag haben wir Saras Sarasvathys Unterscheidung zwischen Causation und Effectuation bereits aufgegriffen.

Kausales Vorgehen beginnt mit einem bestimmten Ziel und fragt anschließend nach den geeigneten Mitteln:

„Ich weiß, was ich erreichen will – wie komme ich dorthin?“

Effectuation dreht die Perspektive um. Den Ausgangspunkt bilden die bereits verfügbaren Mittel:


|Den ganzen Beitrag lesen…

Klares Ziel, flexibler Weg (1/11)

Handlungsfähigkeit unter Unsicherheit

Wir neigen dazu, Zielorientierung mit Planung zu verwechseln: Ziel definieren, Weg festlegen, Plan abarbeiten. Das funktioniert gut, solange die Welt einigermaßen vorhersehbar ist.

Unter Unsicherheit wird genau diese Logik zum Problem. Dann brauchen wir beides: Orientierung und Anpassungsfähigkeit.

Oder kürzer:

Klares Ziel. Konsequentes Handeln. Flexibler Weg.

Interessanterweise findet sich diese Grundidee in sehr unterschiedlichen Forschungs- und Managementansätzen wieder.

Psychologie: Handeln, ohne alles kontrollieren zu können

Albert Banduras Konzept der Selbstwirksamkeit beschreibt die Überzeugung, durch eigenes Handeln etwas bewirken zu können. Entscheidend ist dabei nicht der Glaube „Es wird schon gut gehen“, sondern:

„Ich kann etwas dafür tun.“


|Den ganzen Beitrag lesen…

PMBOK V. 7 vs. V. 8

Ich hatte gerade einen interessanten Dialog mit der KI (ChatGPT). Die alte Ausgabe des PMBOK (V. 7 ) habe ich hier schon besprochen. Damit verbunden war eine klare Kontextorientierung, die bisherige Prozessorientierung wurde nicht aufgegeben, aber wanderte in die Anhänge.

Mit der 8. Version kommt ein verzweifelter Rollback.

Aber zu meinem Dialog mit der KI:

ICH: Böse interpretiert würde ich das als ein feiges Zurückrudern einordnen. Die theoretisch/generische Prozessorientierung kommt zurück in den Fokus und weicht den kontextspezifischen Ansatz aus der Vorversion auf. Wie siehst du das?

ChatGPT: Okay. Deine Lesart ist gut begründbar. Ich würde sie nur etwas präzisieren: PMBOK 8 ist weniger ein vollständiges Zurückrudern als ein politisch und kommerziell motivierter Kompromiss, der den konzeptionellen Mut von PMBOK 7 deutlich abschwächt.
PMBOK 7 hatte eine starke, wenn auch unbequeme Botschaft:
Professionelles Projektmanagement lässt sich nicht durch einen universellen Katalog von Prozessen beschreiben. Es muss aus Prinzipien, Kontext, gewünschter Wirkung und situativen Entscheidungen heraus gestaltet werden.
[…]

ICH: Also weil die Zielgruppe zu „blöd“ ist ein zurückrudern, um mehr Akzeptanz zu finden?

ChatGPT: Okay. Zugespitzt: Ja – PMI traut seiner eigenen Zielgruppe offenbar nicht zu, mit einem konsequent kontextorientierten Standard produktiv zu arbeiten. „Zu blöd“ trifft es trotzdem nicht ganz.
Das Problem liegt auf drei Ebenen:

Das PMI-Geschäftsmodell braucht vermittelbare Inhalte.
Zertifizierungsprüfungen, Schulungen und Lehrmaterial funktionieren besser mit benennbaren Domains, Prozessen und Zuordnungen als mit situativer Urteilskompetenz. Kontextkompetenz lässt sich schlechter standardisieren und prüfen.

Viele Anwender wollen Eindeutigkeit.
Prinzipien und Kontextentscheidungen verlangen Urteilskraft. Prozessmodelle liefern scheinbar klare Antworten: Was kommt wann, wer macht es, welches Artefakt entsteht? Das vermittelt Sicherheit, selbst wenn sie fachlich trügerisch ist.

Organisationen wollen Standardisierung.
PMOs, Beratungen und große Unternehmen brauchen Prozesse, Rollenmodelle, Templates, Audits und Toolkonfigurationen. Ein Standard, der im Kern sagt „Es kommt darauf an“, lässt sich schwer operationalisieren und kontrollieren.

[…]

PMI reagiert darauf, dass ein erheblicher Teil seines Marktes verbindliche Orientierung mit konkreten Prozessen verwechselt – und bedient dieses Bedürfnis, statt die notwendige Kontext- und Urteilskompetenz weiterzuentwickeln.

[…]

Noch schärfer formuliert: Nicht die Zielgruppe ist zu blöd. PMI behandelt sie wie eine Zielgruppe, der man keine anspruchsvolle professionelle Urteilsbildung zumuten kann – möglicherweise, weil sich regelorientierte Sicherheit besser verkauft als reflektierte Unsicherheit.

P.S. noch als kleiner Anhang, die Gegenüberstellung von V. 7 und V. 8

Inhaltliche Verschiebung

PMBOK-7-PrinzipBehandlung in PMBOK 8
Stewardshipvor allem „Be an Accountable Leader“ und Governance
Team„Build an Empowered Culture“ und Resources Domain
StakeholderStakeholders Domain
Wert„Focus on Value“ und Governance Domain
Systemdenken„Adopt a Holistic View“
Leadership„Be an Accountable Leader“
Tailoringeigenes Tailoring-Kapitel und Tailoring je Domain
Qualität„Embed Quality …“, Scope und Governance
Komplexitätganzheitliche Sicht, Risiko und Tailoring
RisikenRisk Domain
Anpassungsfähigkeit und ResilienzTailoring, Risk Domain und Entwicklungsansätze
VeränderungWertorientierung, Stakeholder und Governance
Nachhaltigkeiterstmals eigenes, ausdrückliches Prinzip

Table of Elements: Neue Homepage

Die neue Homepage der Table of Elements ist live.

Highlight sind die Detailseiten zu den einzelnen Elementen. Die detaillierten Schritt für Schritt Anleitungen und mehr Informationen gibt es darüber hinaus in der iOS App PM Elements und in unserem Buch (englische Version in Vorbereitung).

Im Rahmen der Überarbeitung haben wir unseren Poster-Shop geschlossen. Alternativ steht dafür der neue Download-Bereich bereit: Unser Periodensystem gibt es jetzt kostenlos als PDF-Download – in Englisch und Deutsch.

Und noch ein Zuckerl gibt es on Top: Neben dem Methodensystem steht auch ein Projekt Canvas bereit zum Download. Aber dazu demnächst noch mehr.

Fortschritte in der Bildgenerierung mit KI

Für die Table of Elements haben wir eine Reihe von Marketing Grafiken, die wir vor allem auf unserem LinkedIn-Kanal nutzen mit ChatGPT generiert. Gerade bei den zuletzt generierten Grafiken zeigt sich die Entwicklung der KI in diesem Bereich: Die Treffsicherheit bei der Umsetzung der Prompts ist höher, die Grafiken sind viel „fein-granularer“, was ein kleines bisschen doof ist, weil die neue Generation jetzt optisch schon ein bisschen anders aussieht als die ersten Grafiken, obwohl alles im gleichen Projekt läuft und eigentlich die Anschlussfähigkeit klar sein sollte.

Während ich bei der alten Bildgenerierung damit kämpfen musste, dass ich immer älter und älter wurde, während mein Kollege Botta immer jugendlich jung dargestellt wurde, profitieren wir jetzt wenigstens beide vom digitalen Jungbrunnen.

Das (ganz) neue Spiel

Eher zufällig bin ich über meine Aufzeichnungen zu Michael Seemanns Buch „Das neue Spiel“ aus dem Jahr 2014 gestolpert (siehe auch hier auf schlossblog). Seemann hat sich mit dem Thema Kontrollverlust vor dem Hintergrund der damals immer dominanter werdenden großen Internet-Plattformen auseinander gesetzt. Da war von KI noch keine Rede, aber seine 10 Regeln gelten auch für die KI, von anzunehmenden neuen Spielregeln, über den Kontrollverlust bis hin zur Eigenverantwortung. Vielleicht müsste man noch eine 11. Regel KI-spezifisch ergänzen:

Hinterfrage Integrität und Korrektheit aller Antworten.

Mit einer solchen Regel würde man dann noch dem Thema Biases und Halluzinationen Rechnung tragen.

Die geänderten gesellschaftlichen Kommunikationsstrukturen bekommen bei der KI durch die Agenten nochmal eine neue Dimension, aber auch die Rolle des Staats (als Teil des Problems) findet sich schon bei Seemann. Bei der KI haben wir gerade den amerikanischen Versuch erlebt, mit Exportkontrolle einen Kontrollverlust zu unterbinden, ob dies dauerhaft gelingen wird, wage ich allerdings zu bezweifeln.

DOS und DON´TS im Projektmanagement

Letztes Jahr erschien im Human Resources Manager ein Beitrag von Bernhard zu den Dos and Don´ts im Projektmanagement. Noch pointierter als dort: hier die KI-Zusammenfassung als Comic.

PVM 2026

Auch 2026 wird es eine PVM geben. Die PVM 2026 findet am 5. und 6. November 2026 im Hermann Hollerith Zentrum in Böblingen statt. Das diesjährige Leitthema lautet „Projekte im Wandel: Disruption, Künstliche Intelligenz, hybride Methoden“.

Aktuell gehe ich selbst schwanger, ob ich einreichen soll. Call for Papers läuft noch bis 14.06..

Hier der Link zur PVM.

AI Use Cases für SAP

In meinen Kundenprojekten nimmt die KI immer mehr Raum ein – auch im SAP Umfeld. Dabei zeigt sich, dass alle Parteien (inkl. SAP selber) noch am Lernen sind – insbesondere was sicherheitsrelevante und regulatorische Aspekte angeht (die Technik eilt da eher voraus).

Ein Kollege hat in einer Übersicht die Use Cases in Pattern/Muster geclustert und unterscheidet:

  • Knowledge-Based Use Cases – Dem Anwender wird gezielt mittels KI Wissen angeboten und aufbereitet, z.B. aus der SAP Hilfe, Prozessdokumentationen, etc.
  • Navigational Use Cases – Dem Anwender wird geholfen Funktionalitäten und Menüpunkte zu finden ohne dass die AI aktiv in die Geschäftsprozesse eingreift. Das geht schon stark in die Richtung KI als User Interface.
  • Analytical Use Cases – KI gestützt werden Informationen aufbereitet und ausgegeben. Auch wenn die KI nicht direkt in die Geschäftsprozesse eingreift, kann dies außerhalb des Systems in Entscheidungen zum Tragen kommen. Eine Bewertung kann daher nur fallweise erfolgen.
  • Transactional Use Cases – Die KI führt aktiv Transaktionen durch. Theoretisch könnte die KI damit auch gravierende Entscheidungen treffen. Dass ein Bot Menschen entlässt oder einstellt, halte ich allerdings eher für eine theoretische Variante. Viel mehr kommt hier das Thema Automatisierung zum Tragen: Wie ein Mensch kann die KI Käufe/Verkäufe/Zahlungen/etc. veranlassen, dummerweise halt nicht nur eine einzelne, sondern unzählige, bis der Vorgang überhaupt erst transparent wird und ggf. jemand eingreifen könnte. Eigentlich ist das Automatisierungsrisiko auch keine KI-Thematik, sondern ein Effizienz-Thema und die KI ist uns in Sachen Effizienz bei der Massenverarbeitung hoffnungslos überlegen.

Die ersten beiden Use Cases sind hingegen vergleichsweise trivial: Ihre Inhalte sind weitgehend öffentlich oder maximal für einen internen Gebrauch bestimmt und es gibt keine direkten Konsequenzen, die zu verfolgen wären.

Auf der Lösungsseite sind mir im SAP Umfeld bislang 3 technologische Ansätze untergekommen:

  • SAP Joule – die SAP eigene KI, wobei man etwas aufpassen muss, weil SAP den Namen Joule marketingtechnisch etwas inflationär benutzt und schnell alles, was mit KI zu tun hat, auch mal als Joule betitelt
  • Specific Capabilities – Während Joule weitgehend produktübergreifend konzipiert ist, entwickelt SAP auch spezifische KI-Lösungen für Ihre Produkte, z.B. für SAP Signavio oder andere. Dabei wird mitunter, wie auch bei Joule, die Business AI Foundation genutzt, sprich auch für spezifischere Anwendungsfälle kommen die gleichen LLMs zum Einsatz, die dann auch spezifische Modelle und Lösungen unterstützen.
  • Individual AI Solutions – Mit SAP BTP hat die SAP entwicklungsseitig Tür und Tor geöffnet und findige Entwickler können im eigenen Programmcode natürlich auch beliebige KI Lösungen ansprechen. Der Tragweite kann durchaus immens sein und der SW-Entwicklung kommt plötzlich auch die Verantwortung für Auswahl, Konfiguration und Nutzung der KI-Modells zu. In diese Kategorie würden auch KI-Lösungen von 3rd-Party Anbietern fallen, auch wenn mir solche bislang noch nicht untergekommen sind, was aber sicher nur eine Frage der Zeit ist.

Unabhängig von der KI-Thematik gilt es zu berücksichtigen, dass Daten mitunter über Schnittstellen bis hin zu 3rd Parties, wie z.B. einem LLM-Anbieter gegeben werden. Wie weit dies in Abhängigkeit von der Kritikalität der Daten sinnvoll oder sogar zulässig ist, ist zu berücksichtigen.

Wie verteilen sich nun die Use Cases auf die Lösungsszenarien? Hier meine Interpretation (es mag Ausnahmen geben, aber die Tendenz scheint naheliegend):

SAP Joule dürfte die Knowledge-Based und Navigational Use Cases weitestgehend abdecken. Bei Analytical Use Cases bin ich mir noch nicht sicher , wie weit hier SAP Joule zum Einsatz kommen wird, auch wenn generisch die Ansätze vorhanden sein werden. Im analytischen und auch im transaktionalen Bereich werden aber produktspezifische Capabilities wie sie auch bei der SAP auf der Roadmap stehen eine gewichtige Rolle spielen. Individuelle Lösungen können als „Schweizer Taschenmesser“ oder für noch spezifischere Anwendungsfälle fungieren. Die Hemdsärmligkeit, wie wir sie auch aus der Entwicklung von KI-Tools in anderen Bereichen kennen steht hier im Widerspruch zu den gestiegenen Anforderungen und der Verantwortung bei Entwicklung und Einsatz.

Das bringt uns noch zu einem weiteren Aspekt: den Compliance-Anforderungen, z.B. aus dem EU AI Act (eine Zusammenfassung gibt es übrigens auch im schlossBlog) und unternehmenseigenen Anforderungen, z.B. aus dem Risikomanagement.

Jetzt stehen das Enterprise Risk Management und der EU AI Act zwar nicht im Widerspruch, aber die EU-Bürokraten haben bei ihrer Arbeit leider übersehen, dass der Risiko-Begriff längst auch anderweitig besetzt war und ist. Ihr Fokus auf Menschenrechte und hoheitliche Themen ist Ausdruck des Elfenbeinturms in dem sie sich bewegen. Nicht dass die Anforderungen per se falsch wären, aber es gibt eben auch noch andere Anforderungen und ich persönlich halte es nicht für zielführend für jede Technologie eigene Regelwerke zu erlassen, anstatt allgemeine Regelwerke auf ihre Tauglichkeit hin für neue Technologien zu prüfen, das hat schon zur EU-Leuchtmittelverordnung und zu EU-Staubsaugerverodnung geführt.

Auch wenn Unternehmensrisiken durchaus die Themen des AI Act aufgreifen sollten, ist der Schwerpunkt der Betrachtung doch ein anderer. Ich sehe hier vor allem zwei Themenfelder:

(1) KI-gestützte Entscheidungen (und nicht nur Personalentscheidungen wie im AI Act, sondern grundsätzlich auch die strategische Entscheidungsfindung, die im worst case existenzbedrohend für ein Unternehmen werden kann.)

(2) Das Automatisierungsdilemma. Die KI kann, wie wir Menschen, Fehler machen, nur kann sie diese auch exponentiell machen. Ich habe ja auch an anderer Stelle schon darauf hingewiesen, dass wir vielleicht eine eigene Fehlerkultur für die KI entwickeln müssen.

Spannend wird es, wenn wir nun die Enden dieses Beitrags zusammenführen:

Die meisten SAP Joule Anwendungsfälle (weil Knowledge-based und Navigational) sind aus Risikosicht (sowohl des AI Acts als auch des Enterprise Risk Managements) trivial. Die Tücke liegt aber im Detail und analytische und transaktionale Anwendungsfälle benötigen dann doch eine genauere Betrachtung. In einer Diskussion mit Vertretern der SAP habe ich den Kollegen die Frage gestellt, ob SAP Joule maximal low-risk Use Cases im Sinne des AI Acts abdeckt und high-risk Use Cases out of scope sind. Soweit wollte allerdings niemand gehen, auch wenn sich alle Fälle die wir aktuell diskutieren in diesem Bereich bewegen. Die Fragen, wie die Anforderungen für high-risk Use Cases (im Sinnes des AI Acts) seitens SAP abgedeckt werden, wurden aber eher mit einem Commitment als mit konkreten Aussagen beantwortet.

Bei den Specific Capabilities liegt eine fallweise Betrachtung auf der Hand. Zur Herausforderung könnten aber insbesondere Individual AI solutions werden. Anforderungen, wie Logging Capabilities, technische Dokumentation und Robustheit, wie sie der AI Act für high-risk Use Cases fordert machen auch aus Unternehmenssicht darüber hinaus Sinn, wenn man an das Thema Automatisierung denkt. Die Verantwortung der Entwickler steigt hier, mitunter ohne dass sie sich dessen bewusst sind.



bernhardschloss.de