bluerocks_man.jpg 

+49 (0)7141 8658025

call back

Kontakt

facebook.png 


BlueRocks® Bookmarks

BlueRocks® to: Mr. Wong BlueRocks® to: Webnews BlueRocks® to: Icio BlueRocks® to: Oneview BlueRocks® to: Newsider BlueRocks® to: Linksilo BlueRocks® to: Readster BlueRocks® to: Yigg BlueRocks® to: Linkarena BlueRocks® to: Digg BlueRocks® to: Del.icoi.us BlueRocks® to: Simpy BlueRocks® to: StumbleUpon BlueRocks® to: Yahoo BlueRocks® to: Blogmarks BlueRocks® to: Diigo BlueRocks® to: Technorati BlueRocks® to: Folkd BlueRocks® to: Spurl BlueRocks® to: Google
RD Glossary

Scrum
Webpräsenzen Scrum.com und  Scrum.de haben mit dem Projektmanagement auf Anhieb nichts zu tun.

Oder doch? Der Gestaltungsrahmen Scrum für überschaubare IT Software-Entwicklungsprojekte könnte eher mit ruck (das angeordnete Gedränge im Rugby-Union-Sport) identifiziert werden.

Scrum - das Angeordnete Gedränge ist in verschiedenen Varianten des Rugbysports die Standardsituation, um das Spiel nach kleineren Regelverstößen, einem unerlaubten Vorwärtsspielen des Balles oder nach einem Aus (nur im Rugby League) neu zu starten. Einwurf erhält die Mannschaft, die den Regelverstoß nicht begangen hat.

Scrum soll den IT Software-Entwicklungsprojekten ermöglichen, dass ihre  Eigendynamik sich kontinuierlich am Dynamikgefälle zwischen ihrer Umwelt und sich selbst orientiert.

Die Fähigkeit zur Selbstorganisation des Projektteams ist für Scrum Projekte der kritische Erfolgsfaktor. Das Projektmanagement bezieht sich dafür auf Führung ohne Steuerung.


Scrum Master
Die primäre Aufgabe vom Scrum Master ist die Eigendynamik des Projektes auf das Maß der Umweltdynamik zu bringen und dafür zu sorgen, dass sich das Dynamikgefälle nicht zu Ungunsten des Projektes verschiebt.

Dafür schützt er das Team während der Iterationen (Scrumisten nennen sie Sprint) vor aus der Projektumwelt kommenden Störungen.  

Damit die Eigendynamik des Projektes nicht in chaotische Zustände ausufert, trägt er Sorge für die Einhaltung des Scrum Regelwerkes und räumt Hindernisse, die in täglichen Daily Scrums adressiert werden, aus dem Weg, indem er aufkommende Fragen und Probleme zeitnah klärt.

Der Scrum Master ist Projektmanager, der das Projektteam führt, ohne es zu steuern. (Uns sind Projektmanager bekannt, die diese Art der Teamführung seit vielen Jahren praktizieren, ohne dabei zu wissen, dass sie Scrum Master genannt werden können.) 

Ken Schwaber hat bewusst einen anderen Namen als Projektmanager gewählt, weil es sich dabei um eine andere Verantwortlichkeit handelt. In der Praxis geht die Rollenbesetzung oft schief, weil man es lediglich dabei belässt, die Rolle des Projektmanagers "umzutaufen".

Wir bezeichnen Scrum Master » der Erkenntnisbaum des Scrum Projektes  «.


Scrum Product Backlog
Product Backlog enthält alle Anforderungen.

Im Product Backlog dürfen alle Projekt Stakeholder Einträge vornehmen. Dies setzt voraus, dass man alle Stakeholder möglichst lückenlos identifiziert und für Berechtigungen eine Selektion vornimmt.

Der Product Backlog Owner ist jedoch der Product Owner. Er darf die Einträge priorisieren.

Wenn die Umsetzung offener Backlog Einträge weniger an Wert bringt, als die Umsetzung kostet, ist das Projekt zu Ende.

Wie im realen Unternehmensleben:

Wenn die Nutzung der knappen Ressourcen im Prozess nicht den geplanten (erhofften) Wert (als Output) generiert, dann ist auch ein Scrum Projekt nicht wertschöpfend. 


   

Scrum Product Owner
Mit dem Begriff Product Owner werden Weder-Fisch-Noch-Fleisch-Rollen wie Sponsor konsequent aus der Welt geschaffen.

Tatsächlich hat jedes Projekt einen Auftraggeber zu haben, der sein Geschäft mit den Ergebnissen des Projektes besser machen will und deswegen ein Projekt in Auftrag gibt, z.B. der Owner eines Geschäftsprozesses, der seinen Prozess optimieren möchte. Dieser Auftraggeber hat also das Problem selbst an der Backe. Er vertritt nicht die Interessen von Dritten.

Unter diesem Aspekt ist die Person mit der Backe ( Product Owner in Scrum ) der Herr aller Anforderungen an das Projekt, die im Product Backlog erfasst werden. Während des Projektes ist er die letzte Instanz, um die Anforderungen zu priorisieren bzw. umzusortieren. Er darf seine Unterschrift darunter setzen. Sonst keiner.

Sein Fokus liegt dabei auf Return on Investment RoI, was eigentlich auch ohne Scrum selbstverständlich sein sollte. Denn für jedes Projekt gibt das Unternehmen bekanntlich Geld aus. Übrigens Earned Value Management basiert auf der gleichen betriebswirtschaftlichen Sichtweise.

Aus Sicht des Anforderungsmanagements betrachtet ist er gleichzeitig die Kommunikationsbrücke und der Erkenntnisknoten zwischen relevanten Stakeholder in der Projektumwelt wie Anwender in seinen Linienprozessen, Manager, Behörden und dem Projektteam. 

  • Formulierung und Koordination der Anforderungen aller relevanten Stakeholder
  • Pflege und Priorisierung des Backlog (der Liste der Anforderungen) 
  • Abnahme von Sprint Ergebnissen (der Ergebnisse einzelner Iterationen)

Noch schöner kann die Welt nicht sein: Der Auftraggeber sagt nicht nur genau, was er will, sondern er verfolgt bis zum Projektende die Umsetzung seiner Anforderungen. Der Projektmanager (Scrum Master) ist der Dienstleister und steckt seine Halbwahrheiten in die Beschreibung und Aktulaisierung der Anforderungen nicht.

In der Scrum Praxis wird die Rolle in unterschiedlichen Variationen, zum Teil verwässert, gelebt. Öfters bieten sich auch externe Berater als Product Owner an. 


Scrum Selbstorganisation
Mit Selbstorganisation bezeichnen wir all jene nichtrivialen Prozesse, die dafür sorgen, dass ein soziales System wie Scrum Team eine Ordnung bekommt und aufrechterhalten bleibt. Dazu gehört auch, dass das System auf Änderungen von innen und aussen reagieren kann, flexibel bleibt und einen neuen Gleichgewichtszustand findet. Selbstorganisation bedeutet nicht, dass sich die Teammitglieder im Scrum Team selber organisieren, sondern sie ist eine Eigenschaft des sozialen Systems Scrum Team selber.

Projektteams sind komplexe soziale Systeme, die von einem Projektleiter nicht zu 100% überblickt und gesteuert werden können. Die Selbstorganisation lebt von in der Peripherie getroffenen Entscheidungen eigenständig handelnder Teammitglieder. Alle müssen den Handlungen vertrauen können. Gunter Netzer bringt es seiner Bild-Kolumne am 04. Juli 2010 auf den Punkt:

"...

Die Spieler verstehen sich untereinander nicht nur spielerisch, sondern auch menschlich. Es gibt keine Streitigkeiten, keinen Neid. Das hat nichts mit 11-Freunde-Romantik zu tun. Gegenseitiges Vertrauen ist aber auch im heutigen Profigeschäft die Voraussetzung, um gemeinsam nach wochenlanger Vorbereitung das große Ziel zu erreichen.

..."  

Das Scrum Team wird zur Selbstorganisation fähig, indem es in jedem Sprint auf Basis von aktuellen Priotitäten im Product Backlog den Inhalt und Umfang ( Scope ) eines Increment of Potentially Shippable Functionality selbst modifiziert. Reviews und Retrospektiven nach jedem Sprint dienen zu diesem Zweck.

Die Voraussetzung für die Selbstorganisation ist, dass keine Steuerung von außen erfolgt. Das Scrum Team muß seine Entscheidungen eigenständig treffen.

Scrum Master darf keine steuernden Anweisungen geben.

Die Selbstorganisation ist auch mit PMI® Gestaltungsrahmen möglich. Projektmanager und Projektteam nach PMI® müssen gemeinsam die Selbstorganisation verstehen und für das jeweilige Projekt definieren. Die Enterprise Environmental Factors EEF können externe Referenzen verkörpern, die für die Selbstorganisation des Projektteams wie Luft und Wasser nötig sind.

Im Idealfall müßte der Auftraggeber im Project Charter als Product Owner fungieren. 

Denkfehler

  • Selbstorganisation kann in systemischen Soft Skill Seminaren gelernt werden: wenn alle über emotionale Intelligenz verfügen, dann müßte man nur noch Selektion der Information, Selektion der Mitteilung und Selektion der Annahme / des Verstehens in Griff bekommen.
  • Agile Projekte lassen sich mit System Dynamics simulieren: viel Spaß beim Loops Hopping!
  • Soft Facts und Management Entscheidungen lassen sich ebenfalls mit System Dynamics gut modellieren. Die Grundvoraussetzung dafür wäre, dass der Manager all seine Gedanken ohne Zeitverluste offen legt. (Die Gedanken sind Operationen des Bewußtseinsystem des Menschen. Pro Tag sind ca. 60.000 Operationen, die das Bewußtsseinssystem abarbeitet.)
Scrum Sprint
Iterationen werden in Scrum Sprint bezeichnet. Jeder Sprint hat ein Inkrement einzulieferen, d.h. der Wertschöpfung des Projektes beizutragen. 

Während des Sprints darf der festgelegte Aufgabenumfang nicht verändert werden. Für die Verpflichtung des Teams, in einem Sprint die Aufgaben in dem Sprint Backlog vollständig (100%) abzuarbeiten, ist dies Grundvoraussetzung.


 

Scrum Team
Das Scrum Team verantwortet die Aufgabe, den aktuellen Sprint Backlog umzusetzen. Hierbei organisiert es sich selbst. Anders ausgedrückt: Als soziales System stellt sich sinnkonstituierend selbst her. Dabei schließt sich das Scrum Team von seinen Umwelten operational ab.

Die zentrale Operation des Scrum Teams als soziales Systems ist Kommunikation.

Kommuniziert wird über 

  • Scope -zu finden im Sprint Backlog-
  • Qualität
  • Zeit -Sind wir in der Time Box?-
  • Kosten
  • Ressourcen -Kollege braucht Unterstützung!-
  • Risiken

und über Wechselwirkungen unter diesen 6.

Dies bedeutet, dass die einzelnen Scrum Team Mitglieder doch vom Projektmanagement Ahnung haben müssen. Die Frage ist: Wie viel Ahnung?  

Das Scrum Team wird cross-funktional besetzt und definiert keine differenzierenden Rollen wie Entwickler, Techi, Architekt, Datenbank-Koryphäe, Designer, Prozessmanagement Schwafler.

Die eigene Organisation festzulegen, ist die Aufgabe des Scrum Teams. Die besondere Herausforderung ist die cross-cultural Kommunikation:

Cross cultural Management 

Mit der Unterscheidung von Umwelten und Scrum Team selbst kommt das emergente Verhalten zustande. Die Wahrnehmung der Umwelten durch das Scrum Team ist stets selektiv, z.B. wichtig | unwichtig im Zusammenhang mit dem Abarbeiten vom Sprint Backlog.   

Product Owner und Scrum Master gehören zu seinen Umwelten.

Denkfehler: Teilnahme an Soft Skill Trainings befähigt das Verstehen der Selbstorganisation.


 

 

Service Level Agreement SLA
Deutsch - ebenfalls Service Level Agreement

Quantitative und qualitative Vereinbarung über zu liefernde Leistungsumfänge unter Nutzung ökonomischer Schnittstellen ( externe Service Beziehungen )


Sharehopper
Wir bezeichnen manche Shareholder so, da sie Aktienpakete öfters als ihr Hemd wechseln.
Sinn
Sinn ist das Medium, welches sich in psychischen und sozialen Systemen durch Gedanken oder Kommunikationen realisiert.

Jede Selektion dieser Systeme findet im Medium Sinn statt und aktualisiert es zugleich.

Sinn das universale Medium der anschlussfähigen Formbildung sozialer und psychischer Systeme. Sinn ermöglicht die Auswahl der Operationen, indem er die unendliche Komplexität der Welt auf das sinnvoll Anschlussfähige reduziert.

Drei Dimensionen des Sinns:

  • Sachdimension arbeitet mit der Unterscheidung bestimmt | unbestimmt
  • Zeitdimension arbeitet mit der Unterscheidung vorher | nachher
  • Sozialdimension arbeitet mit der Unterscheidung ego | alter ego

→ Komplexitätsreduzierung


Sinnkopplung
Sinnkopplung - ein Merkmal des Menschen (so alt wie die Menschheit selbst) 

→ Sinn 

→ System


Soft Facts
Deutsch - weiche Fakten oder weiche Faktoren

Die auf Anhieb unsichtbaren Aspekte einer Organisation in seiner Hinterbühne. Sie sind Elemente der Wertekultur , die den Erfolg einer Organisation in dynamischen Märkten ausmachen.

Soft Facts sind Prinzipien, tatsächliche Interessen, Einstellungen, Werte, Gefühle, hidden agenda, Migrantenkomplex, informelle, nicht inszenierte Beziehungen.

In Change Management Vorhaben werden sie oft halbherzig behandelt oder gar ausgeblendet, weil sie sich nicht entwickeln lassen. Allein der Begriff Fakt ist eine Denkfalle, da man für die Werte keine Fakten schaffen kann.

Die Techniken wie Laternen Interviews und Laternen Workshops dienen zur Beobachtung der Soft Facts.   


Stakeholder
  • Stakeholder haben Bedürfnisse, Ansprüche, Interessen.
  • Stakeholder sind Kommunikationsadressen zwischen der Unternehmung und ihren Umwelten. 

Anspruch

beschreibt das Recht eines einzelnen von einem anderen ein Tun, z.B. die Zahlung eines Geldbetrags, die Abgabe einer Erklärung oder die Übergabe einer Sache, oder Unterlassen, beispielsweise das Unterlassen von unzumutbarem Lärm, zu verlangen.

Stakeholder mit Anspruchsgruppe zu übersetzen, haut nicht treffend hin. So verwenden wir auch in Deutsch Stakeholder.

Machen Sie folgende Unterscheidung und bilden anschließend eine Einheit:

Bedürfnis | Interesse

Bedürfnisse stellen die Vorstufe des Bedarfs dar. Aus einem Bedürfnis wird dann ein Bedarf, wenn dem Bedürfnis eine adäquate Kaufkraft zur Seite steht. Der Bedarf wird zur Nachfrage, wenn eine vorhandene Kaufkraft am Markt durch eine Kaufabsicht tatsächlich geltend gemacht wird. Die Bedürfnisse von »Stakeholdern« sind subjektiv empfundene Bedarfe. Nur wenn Sie schon einmal plátano (Kochbanane) gegessen haben, können Sie Appetit auf sie haben.

Der geniale Steve Jobs erreicht die Menschen in der Apple Umwelt "Gesellschaft", die noch nicht seine Kunden sind, motiviert sie mit in die Apple Umwelt "Markt" zu gehen und macht somit einen Teil von ihnen zu Apple-Kunden.

Auf dem Weg von der Umwelt Gesellschaft zur Umwelt Markt verbringen mehrere von diesen Menschen die Nacht vor einem Apple Laden. 

Ein weiteres Beispiel:

Facebook erreicht weltweit Menschen in allen drei Unternehmensumwelten: in der Gesellschaft, in der Wirtschaft, im Markt.

Interessen beschreiben ein Ziel oder einen Vorteil, den sich eine Person oder Personengruppe aus einer Sache verspricht oder erhofft. So verfolgen Interessengruppen »Stakeholder« eigene Ziele wirtschaftlicher Art. Ihre Interessen sind objektive Notwendigkeiten. Ein Händler, der mit plátano Geschäfte macht, hat Interesse sie gewinnbringend zu verkaufen.

Die Startfrage für solides Stakeholder Management lautet:

Welche Stakeholder haben Ansprüche? Sind sie Bedürfnisse oder Interessen?

Es gibt Stakeholder, die sich managen lassen, d.h. führen oder steuern lassen und Stakeholder, die sich nicht managen lassen. Was? fragen Sie nun enstetzt.

Ja. Sie können nicht jede Stakeholder Beziehung managen. Es gibt Stakeholder, die mit Ihrem Vorhaben (Projekt, Prozess, Unternehmen) dem Anschein nach kausal gekoppelt sind.

Es gibt aber auch Stakeholder, mit denen Ihr Vorhaben strukturell gekoppelt ist. Diese können Sie nur spüren, da sie den gleichen Lebensraum mit Ihnen teilen. Kausale Logik nutzt zur Beschreibung der Beziehungen zwischen diesen Stakeholder und Ihnen nichts.

Das Basiselement aller sozialen Systeme ist die Kommunikation. Die Kommunikationsprozesse verantworten die Abgrenzung zwischen Organisationen und ihren Umwelten. Stakeholder sind Kommunikationsknoten in den externen und internen Umwelten der Organisationen wie Unternehmen, Prozesse, Projekte.

In dynamischen Umwelten von heute verhalten sich die Stakeholder gänzlich anders als in trägen Umwelten von gestern. Stakeholder Management ist ein kritischer Erfolgsfaktor. 

Der Umgang mit den Stakeholdern orientiert sich am Kreislauf:

  • Stakeholder identifizieren
  • Stakeholder zuordnen (extern - intern, kausal oder strukturell gekoppelt etc.)
  • Hypothesen bilden (eventuell in Laternen Interviews und Laternen Workshops)
  • Stakeholder beobachten inkl. Managen der managebaren Stakeholder
Stakeholder identifizieren
10.1 Identify Stakeholders

Für ein Projekt -egal ob PMI oder Scrum- ist die Identifizierung von kausal- und strukturellgekoppelten Stakeholder bei der Initiierung des Projektes die halbe Miete.

Stakeholder


 

Stakeholdererwartungen managen
Engl. 10.4 Manage Stakeholder Expectations

Im PMBOK® Guide wird für den Projekt Prozess Stakeholdererwartungen managen der Austausch (was wird ausgetauscht?) mit den Stakeholdern vorgesehen, um deren Bedürfnisse zu erfüllen und ggf. auftretende Probleme auszusprechen.

Der Prozess Stakeholdererwartungen managen umfasst laut PMBOK® Guide unter anderem Mitteilungen an die Stakeholder, um deren Erwartungshaltung zu beeinflussen, auf deren Bedenken zu reagieren und Probleme zu lösen.

Diese Art vom Erwartungsmanagement soll dazu beitragen, dass die Stakeholder sich über die Vorteile und Risiken des Projektes (richtig wäre Chancen und Gefahren des Projektes! Die Anschlussfrage: Für wen?) im Klaren sind. 

Schön wäre es, wenn die Stakeholder ihre Erwartungen nur so managen lassen würden, als gebe es eindeutige Kausalitäten. Dem ist es leider nicht so. Es ist an der Zeit, sich vom naiven Stakeholder Vertändnis und Modellen zu verabschieden.

Kommunikationsmanagement in Projekten

Stakeholder Management


Steuerung
Automata von Heron von Alexandria (20-62 nach Christus) 

Heron entwickelte eine Türsteuerung , bei der sich durch Entzünden eines Feuers die Tempeltür öffnete. 

Sein Weihwasserautomat gab nach Einwurf einer Münze eine kleine Menge geweihtes Wasser aus. Seine Ideen waren die ersten Beispiele der Steuerungstechnik.

Steuerung setzt die kausale Kopplung voraus. Im Management Kontext definieren wir Steuernde | Gesteuerte und die Elemente, welche die beiden kausal verbinden.

Steuerung beeinflusst den Arbeitsablauf einer Maschine oder eines Prozesses nach einem vorgegebenen Plan.   

Abhängig von Eingangsgrößen und Zustandsgrößen werden Ausgangsgrößen gesetzt.

Durch die Abbildung der Operationen von dem Steuernden und den Gesteuerten in Automaten werden Automatisierungssysteme gebildet, z.B. Produktionsautomatisierung. Ein "intelligenterer" Automat -der Leitrechner ordnet an, was die "weniger intelligenten" Automatisierungsgeräte wann auszuführen haben. Hier läuft uns das Gefälle der Maschinen-Intelligenz über den Weg, das Niklas Luhmann Differenz bezeichnet:  

“ Man kann den Begriff der Steuerung auf jeweils spezifische Differenzen und nicht auf Systeme beziehen. Differenzen können durch Steuerung gesteigert oder auch abgeschwächt werden. In jedem Fall beobachten Steuerungsversuche das zu steuernde System mit Hilfe einer spezifischen Unterscheidung ”.   

Versucht allerdings ein Projektmanager sein Projektteam oder ein Prozessmanager seine Prozessbeteiligte zu steuern, als ob er ein Leitrechner und die Mitarbeiter Automatisierungsgeräte wären, ist das Elend vorprogrammiert. Er hat den Begriff Differenz nicht ganz verstanden. Das Machtgefälle kann mit Ursache-Wirkungs-Mustern nicht gelebt werden, da Organisationen keine trivialen Maschinen sind. Triviale Maschinen können von Software Entwicklern codiert werden. Die im Anforderungsprofil von Requierements Managern definierten Eingangsgrößen führen in ihrem Fall zu fest gekoppelten bzw. geplanten Ausgangsgrößen.

Organisationen wie Unternehmen, Projekte, Prozesse reagieren in ihrem Verhalten immer auf ihre innere Logik, so dass sie auf Eingangsgrößen selektiv reagieren. Organisationen verarbeiten Sinn. 

→ Denkfalle: Führen ist Ausführen.

Regelung - Kommt bei der Steuerung die fortlaufende Rückkopplung der Ausgangsgröße auf den Eingang hinzu, wird von Regelung gesprochen.

In der Betriebswirtschaft ist Controlling eines der Kernelemente für Steuerung. 

→ Führung

→ Management


Strategie
Die beiden Wörter haben die alten Griechen geliefert:

Stratos - das Heer und  Agein - Führen

Das Substantiv Strategos bezeichnete die Funktion des Generals im griechischen Heer.  Strategos legte fest, was die Truppen nicht anzustreben haben.

Der preußische Militärstratege Carl von Clausewitz bezeichnete die Strategie als Kunst des Weglassens. ( Die Bezeichnung gilt auch in Bayern Wink )

Sein Zeitgenosse Georg Wilhelm Friedrich Hegel : »Wer etwas Großes will, der muss sich zu beschränken wissen; der dagegen alles will, der will in der Tat nichts und bringt es zu nichts.«

Michael E. Porter hat Carl von Clausewitz treffend zitiert: Das Wichtigste bei jeder Strategie ist zu entscheiden, was man nicht macht.


Structural Drift
Structural Drift bezeichnet die Entwicklung verschiedener Systeme, die miteinander nicht kausal gekoppelt sind, aber den gleichen Lebensraum teilen, als ob zwischen den beiden gegenseitige Eingriffe stattgefunden hätten.

     

Strukturelle Kopplung
Wundern Sie sich manchmal auch, dass Sie für eine Beziehung keine Kausalität herstellen können. Sie stellen fest, dass nicht alle Eregnisse in vorher - nachher oder if - then miteinander koppeln lassen. Nicht überall ist die ereignisgesteuerte Prozessmodellierung anwendbar. Was tun?

In der Tat gibt es Ereignisse, die gleichzeitig laufen, so dass eine Vorher-Nachher Beziehung fehlt. Es gibt z.B. Stakeholder, die mit einem Prozess oder einem Projekt nur strukturell gekoppelt sind. Diese teilen mit dem Prozess oder dem Projekt den gleichen Lebensraum, wobei sie die Umwelt für den Prozess oder das Projekt sind. Durch Structural Drift spüren sich Stakeholder und der Prozess oder das Projekt einander. Der Widerstand eines solchen Stakeholder erzeugt also die strukturelle Kopplung.

Wenn Sie sich jetzt fragen: Wie soll ich denn diesen Stakeholder managen?

Wir empfehlen folgendes Vorgehen:

Klammern Sie nicht am Schein-Anker Kausalität. Dann untersuchen Sie die vorhandene „strukturelle Kopplung“ auf drei Ebenen:

  • Die erste Ebene geht auf die Kopplung verschiedener Kommunikationssysteme ein,
  • die zweite Ebene bezieht sich auf die Anpassung von Systemen an ihre Umwelten,
  • die dritte Ebene fragt nach der Kopplung des psychischen mit den sozialen Systemen, d.h. nach der Stellung des Menschen in den Systemen und nach der Bedingung der Möglichkeit, der Erkenntnis.
Sunk Costs
Sunk Costs - Deutsch: versunkene Kosten

Sunk costs sind aufgrund vergangener strategischen Entscheidungen entstandene Kosten, die weder gegenwärtig noch zukünftig beeinflussbar sind. Sie stellen irreversibel vordisponierte Kosten dar. Sunk Costs entstehen in dem Zusammenhang, wenn eine Unternehmung Investitionen mit dem Ziel unternimmt, ihre Wettbewerbsposition zu festigen. 

Der Begriff Sunk Costs wird im strategischen Management und Projektmanagement verwendet.

Sunk Costs stellen ein Besipiel für strukturelle Kopplung dar.


 

System

Traditionelle Definition, die wir schon in der Grundschule (heute noch) lernen:

Ein System ist eine Gesamtheit voneinander abhängiger Funktionen, die Input zu Output verarbeiten.  

"...

Ein System ist ein Mittel, Eingaben in Ausgaben umzuwandeln. Diese Beschreibung trifft zu, ganz gleich, ob das beschriebene System eine Behörde, eine Steuerkanzlei, ein typisches IT-System, die menschliche Leber oder Milz ist ... im Prinzip alles, was wir gern als "System" bezeichnen.

IT-Systeme unterscheiden sich davon in folgender Hinsicht: Sie sind Umwandlungen von Dateneingaben, die in das System hineinfließen, in Datenausgaben, die aus dem System herausfließen. Traditionellerweise konzentriert sich die Spezifikation solcher Systeme fast ausschließlich darauf, ihre Transformationsregeln zu definieren, die Verfahren und Methoden, die implementiert werden müssen, damit das System seine Eingaben in Ausgaben umwandeln kann.

..."

Bärentango, Tom de Marco & Timothy Lister, Seite 133

Traditionell wurde und wird ein System meist als eine irgendwie zusammengehörige Ansammlung von Dingen mit Beziehungen untereinander angesehen. Das ist klar und einfach und paßt scheinbar immer. Also wird dieses Konzept ohne weiteres auf soziale Systeme (Unternehmen, Teams, Projekte, Prozesse) übertragen. Wiederum scheint es sofort naheliegend, einzelne Personen als die Elemente eines sozialen Systems zu identifizieren. Immer wenn man auf soziale Systeme trifft, operieren Menschen in ihnen. 

Eine Behörde, eine Steuerkanzlei, ein typisches IT-System, die menschliche Leber oder Milz: Tatsächlich sind die alle "Systeme". Hier verabschieden wir uns von Tom de Marco. 

Heinz von Foerster spricht von trivialen Systemen und nichttrivialen Systemen.  

Biologische, psychische und soziale Systeme sind nicht nichttrivial.  

Zur präzisen Beschreibung müssen wir also Typen bilden. Die Input-Output-Beziehungen reichen nicht mehr aus, um die Komplexität präziser zu beschreiben. Spätestens dann geht Ihnen ohne diese Präzisierung die Puste aus, wenn Sie die Stakeholder Ihrer Unternehmung fundiert identifizieren wollen. Hier stehen uns Niklas Luhmann, Humberto R. Maturana und Fransisco J. Varela zur Seite, damit wir die Welt nicht ausschließlich in Kausalitätssätzen ausdrücken und die Technologie nicht als eine der Unternehmensumwelten zu betrachten.

  • Sinnverarbeitende Systeme
  • soziale Systeme , z.B. eine Behörde, eine Steuerkanzlei
  • das psychische System der Menschen ( Synonym - Bewußtseinssystem )
  • Codeverarbeitende Systeme
    • Nichttrivial - Biologische (= lebende) Systeme wie Organe, Zellen z.B. Leber, Milz
    • Trivial - Automaten wie Maschinen, IT z.B. ein typisches IT-System 

Systeme sind operational geschlossen, strukturell offen. Sie schließen sich an ihre Umwelt über ihre Strukturen und nicht über Operationen.

  • Soziale Systeme operieren im Medium Sinn. 
  • Die Operationen psychischer Systeme sind Gedanken (Das psychische System eines durchschnittlichen Menschen hat am Tag ca. 60.000 Operationen.)
  • Lebende Systeme produzieren, reproduzieren und erhalten Zellen, Zellteile oder Organe bzw. ganze Organismen. 

Der Mensch ist die Einheit der Unterscheidung von einem biologischen System (der Körper mit lebenden Sub-Systemen wie Organe und die Zellen...) und dem psychischen System (das Bewußtsein). Beide sind über strukturelle Kopplung miteinander verbunden und teilen sich den gleichen Lebensraum: Den menschlichen Körper.

In den sozialen Systemen wie Unternehmen, Prozessen und Projekten als Personen, als konstruierte Identitäten, als Adressaten von Kommunikation. Personen sind selbst keine sozialen Systeme, sondern als Bewußtseinssysteme Kommunikationsadressen, die über Bedürfnisse, Individualität und über bestimmte Werte verfügen. 

Wenn Prozessmanager oder Projektmanager die personellen Ressourcen planen, planen sie die Anzahl der biologischen Systeme. Bei der Teamentwicklung haben sie mit sozialen und psychischen Systemen zu tun.

So ist es nicht überraschend, dass Projektmanagement Vordenker, Querdenker und Experten immer wieder den Faktor Mensch entdecken. Deren Entdeckungsfahrt wird bis Ende der Menschheit dauern, da der Mensch in Projekten und Prozessen nicht zu finden ist.