Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Gegrünt und ein paar Typos

...

Ich (Wolfram) würde den Faden gerne aufnehmen und weiter texten. Im letzten Thread über High-Speed-Projektmanagement haben wir ausschließlich in den Kommentaren diskutiert, das führt dazu, dass das Wissen nie konsolidiert wurde, was schade ist. Daher würde ich einfach mal in "grün" weitere Ergänzungen machen. Und ja ich hab die These für gut befunden, daher auch die "Antwort" erst jetzt. Denn mir ging es lange genau so - was hat CCPM mit TOC zu tun? nicht wirklich viel. Je länger man es anwendet dann aber doch. Und die Bezeichnung im Titel TOC++ ist einfach genial - da wollte ich nicht wiedersprechen widersprechen (smile)

Mit beiden Büchern habe ich so meine Probleme. "Goldratt und die Theory of Contraints" von Uwe Techt ist ungenau und unvollständig (würde ich nicht unterschreiben). Z.B. Differenz zwischen kritischer Kette und kritischem Pfad (ist aber drin in 4. Auflage auf S. 137) . "Die kritische Kette" von E.Goldratt ist eine Art von Roman (gewöhnungbedürftig). Es ist schwierig einen Aspekt nachzuschlagen. In welchem Kapitel wird die "Differenz zwischen kritischer Kette und kritischem Pfad" angesprochen? (aus Verzeichnis der Aussagen - Kapitel 22, Seite 224 aktuelle Auflage - ist unter der Idee: Arbeitspakete sind nicht nur über funktionale Abhängigkeiten verbunden sondern auch noch über die zu verwendende Ressource). Wichtig ist beide Grundlagenbücher von Goldratt zu lesen (die Kritische Kette ist eigentlich das zweite Buch) "das Ziel" das erste. Das eine macht eigentlich ohne das andere nur teilweise Sinn. Also wer sich von Romanen nicht abschrecken läßt - dann beide lesen.

...

Der Fehler ist wohl einen Fluss zu unterstellen. Vielmehr sind es wohl abhängige Aktivitäten, die nicht schneller abschließbar sind (genau). Wenn in CCPM mehrere Aktivitäten sich vor einen Engpass stauen bilden, warum sollte es in ToC nicht anders sein? Also nicht eine Maschine ist der Engpass sondern ein ganzes System von Maschinen?

Der Fluss in CCPM sind die Arbeitspakete. Aus sicht Sicht einer Ressource sieht es so aus, als ob Arbeitspakete auf sie ein- und durchströmen. Daher gilt gerade hier auch auf jeden Fall den Work-In-Progress zu begrenzung Begrenzung um Littles Law nicht zu tragen zu bekommen.

Ressource

In ToC ist eine Ressource etwas was pro Zeiteinheit eine bestimmte Transformation vornehmen kann. Begrenzende Ressourcen sind in der Regel Maschinen, die eine klare Spezifikation ihrer Leistungsfähigkeit haben,

...

Ressource wird in heutigen CCPM Implementierung immer Synonym zu "Skill" verwendet. Also wirklich die Fähigkeit aus irgendwas etwas wertvolleres anderes zu machen. Das es sich meist um Menschen handelt und diese wie wild streuen und vielen Störungen unterliegen - oder man kann es auch positiv formulieren: hochgradig kreativ sind (smile) braucht man bei CCPM eben den Projektpuffer um diese Ganze Unsicherheit Abzufangenabzufangen. Hier wird in dem Sinne nicht versucht mit Analogien zu Produktion zu arbeiten. Gerechnet und geplant wird im ganzen CCPM oft nur über die Zeit (nicht die Kapazität) - das ist gewöhnungsbedürftig aber am Schluss konsequent.

In neueren Implementierung wird das Konzept noch viel weiter getrieben - man plant die Ressourcen praktisch gar nicht mehr! Man wählt eine viertuelle virtuelle Engpassressource und baut das Unternehmen drum herum, so dass es in anderen Teams/Skills nicht zu einem Engpass kommt. Funktioniert interesanterweise interessanterweise wunderbar - ist aber noch viel viel gewöhnungsbedürftiger für die Top-Manager als CCPM an sich schon - aber extrem leistungsfähig! Das wird kaum in Büchern erwähnt - höchstens in Seminaren.

...

Ich bin zuerst auch von "unpassend" ausgegangen - weil es nicht intiutiv intuitiv so ist. Normalerweise sieht man nur die Ressourcenkonflikte an den realen Engpässen. Wenn man die realen Engpässe aber nacheinander auflöst verändert sich das Bild und das Muster dahinter. Ich hab ca. 540 Projekte auf dem Buckel und kann mittlerweile bestätigen, dass Projekte alle!!!!!! den grundsätzlich gleichen Aufbau haben. Es gibt eine Phase (Auftragsklärung, Planung), dann wir parallelisiert (in Teilprojekten) die dann in mehren Integrationspunkte münden. Neu sind Ideen aus dem agilen - z.B. kontinuierliche Integration - das ist aber ein ganz anderes Kapitel und ganz ganz neu - das wird gerade erst geschrieben.

...