Verzögerungskosten aufgrund von Experten

Seit Don Reinertsen in seinem Buch auf Verzögerungskosten (cost of delay) bei der (Software-)Entwicklung hingewiesen hat, wird dieses Thema vielfach diskutiert. Dabei stellt sich immer wieder heraus, dass es unterschiedliche Ursachen für Verzögerungen gibt und viele davon eigentlich als Prinzipien für eine Beschleunigung gedacht waren. Dazu gehört auch der Fokus auf Spezialisten.

Unternehmen verlassen sich häufig auf Experten, da diese Probleme schneller lösen werden als Generalisten. Allerdings wird dabei oft übersehen, dass das Verlassen auf Experten zu enormen Verzögerungskosten beiträgt. Um das zu verdeutlichen, versetzen Sie sich in ein Problem, das gelöst werden möchte. Üblicherweise müssen Sie sich dann einreihen in eine Schlange von Problemen, die ein bestimmter Experte lösen kann. Da es nicht nur eine Art von Problemen gibt und nicht nur eine Art von Experten, entstehen verschiedene Schlangen von Problemen für die unterschiedlichen Experten.

Wenn jetzt einer der Experten länger mit einem Problem kämpft, wird seine Schlange länger und länger:

Das hat zur Folge, dass manche Probleme sehr schnell gelöst werden – einfach, weil diese Probleme das Glück hatten und beim "richtigen" Experten landeten bzw. weil sie in einer Schlange landeten, in der die Probleme gerade einfach sind. Und andere Probleme werden nahezu nie gelöst, einfach deswegen, weil ein Problem in einer Schlange einen Flaschenhals oder sogar eine regelrechte Verstopfung verursacht hat.

Wichtig ist hier zu verstehen, dass keines der Probleme in Abhängigkeit von Dringlichkeit, zu erwartetem Geschäftswert oder einer anderen Art von Priorisierung gelöst wird. Sie werden alle in einer Reihenfolge gelöst, die versehentlich durch die Einreihung in einer bestimmten Schlange definiert wird. Wenn man sich statt auf einzelne Experten auf cross-funktionale Teams verlässt, in denen sich die Mitarbeiter untereinander unterstützen und Probleme gemeinsam lösen können, kann man diese Verzögerungskosten signifikant reduzieren. Man hat dann lediglich eine Schlange von Problemen, die eine stete Durchflussrate aufweist.

Diese Durchflussrate ist deswegen konstant, da sich jedes Teammitglied einfach mit dem nächsten Problem befasst, das in der Schlange wartet. Dadurch bestimmt die Reihenfolge in der Schlange jetzt auch die Reihenfolge, in der die Probleme gelöst werden.

Ich möchte noch darauf hinweisen, dass ich mir sehr wohl dessen bewusst bin, dass es Bedingungen gibt, in denen es schwierig – um nicht zu sagen nahezu unmöglich – sein wird, alle Probleme mit Generalisten zu lösen. Diese Bedingungen verlangen oftmals so viele verschiedene Arten von Fachwissen, die sich so stark unterscheiden, dass eine einzelne Person nie in der Lage sein wird, all das verlangte Fachwissen adäquat zu beherrschen.

Dennoch, das muss nicht – wie es allzu oft tut – dazu führen, dass man die Mitarbeiter so ausbildet (oder aussucht), dass sie Spezialisten für genau ein Fachgebiet sind. Denn je höher spezialisiert die Einzelnen sind, desto höher werden auch die Verzögerungskosten sein. Aus diesem Grund sollte immer das Ziel sein, dass so viele Mitarbeiter wie möglich so viele verschiedene Fachgebiete wie möglich beherrschen. Eine gute Daumenregel ist, dass in einem Team jedes Teammitglied sich in circa drei Fachgebieten auskennt und dass jedes Fachgebiet von circa drei Teammitgliedern beherrscht wird. Dadurch lassen sich bereits die Verzögerungskosten deutlich reduzieren.

Literatur:

• Don Reinertsen; The Principles of Product Development Flow: Second Generation Lean Product Development; Celeritas Publishing 2009
  

()