Das neue St. Galler Management Modell: Resümee

Das Buch ist seit ein paar Tagen gelesen. Ich habe nun die notwendige Distanz einen Artikel zu verfassen., der zusammenfasst, was aus meiner Sicht das Wesentliche ist.

Das Modell basiert auf einem Systemischen Ansatz und integriert explizit die Bedeutung von nicht trivialen Regelkreisen. Ein mir wesentlich erscheinendes Merkmal ist auch in der Definition der Anspruchsgruppen gegeben. Damit wird der Rahmen eines Unternehmens wesentlich weiter gesteckt als unter der Annahme lediglich Kunden und Lieferanten würden an der Interaktion mit dem Unternehmen Interesse haben.

Darüber hinaus beschreibt es trotz der im Thema inhärenten Komplexität wie die einzelnen Elemente der Unternehmensführung (Strategie, Umweltanalyse, Ressourcen, Kultur, uvm.) miteinander in Verbindung stehen. Es gibt einen Bezugsrahmen in den man als Manager dann einzelne Methoden z.B. der Analyse, der Strategiefindung, des Prozessdesigns, der Innovation, uvm. Eingliedern kann.

Das Modell gibt diesen Bezugsrahmen – nicht mehr. Es leistet nicht, Entscheidungen vorwegzunehmen, es ist kein Kochrezept und dennoch vermag es Komplexität einfach zu beschreiben.

Falls Ihr mehr wissen wollt, ohne das Buch zu lesen: http://de.wikipedia.org/wiki/St._Galler_Management-Modell

P.S.: Bezugnehmend auf meinen gestrigen Artikel könnten die US-Militärs von den St. Galler Professoren ja abschauen wie man Information aufbereitet. Das Buch kommt bei einem komplexen Thema mit weniger als 90 Seiten aus.

Outsourcing von Teilen der Wertschöpfungskette in der Softwareentwicklung

Entscheidet sich ein Unternehmen Teile der Softwareentwicklung von Partnern übernehmen zu lassen, so hat das weitreichende Implikationen darauf, wie Prozesse gestaltet werden, die nun über Unternehmensgrenzen hinweg funktionieren müssen. Auf was kommt es dabei an?

Aus meiner Sicht ist Vorbereitung der Schlüssel zum Erfolg. Diese Vorbereitung muss vor dem Start der operativen Zusammenarbeit abgeschlossen sein. Diese Vorbereitung muss mindestens folgende Themen abdecken:

  • Definition der gemeinsamen Ziele
  • Rollen und Verantwortlichkeiten der beteiligten Partner – wer ist für welchen Teil der Value-Chain verantwortlich?
  • Definition der Abläufe und der beteiligten Rollen
  • Definition der benutzen Artefakte(strukturell und inhaltlich) und Softwareentwicklungsmethoden
  • Definition von Kennzahlen, die den Erfolg der Zusammenarbeit anzeigen (z.B. Messgrößen für die Durchsatzmessung, Qualitätsmaßzahlen)

Jeder dieser Punkte muss vor dem Start der Zusammenarbeit auf dieser Basis detailliert genug Vereinbart sein, um spätere Kommunikationsprobleme zu minimieren. Damit schafft man eine gute Ausgangsbasis, um an den Unternehmensgrenzen und darüber hinaus erfolgreich zusammenzuarbeiten.

Defect Prevention statt Defect Detection

Je später ein Fehler im Softwareentwicklungsprozess entdeckt wird umso teurer ist seine Behebung bzw. der dadurch verursachte Schaden. Das Ziel muss daher sein, Fehler möglichst früh im Softwareentwicklungsprozess zu erkennen, um diese zu beheben.

Ein Beispiel: Bei der Analyse der Anforderungen wurde vergessen Leistungskriterien für die Software zu definieren. Beim Test stellt sich heraus, dass der Kunde mit den Antwortzeiten nicht zufrieden ist und die Abnahme verweigert. Um die Leistung zu erhöhen sind an der Datenbank und an den Abfragen Änderungen vorzunehmen. Auch der Code muss angepasst werden und erneut getestet werden. Wäre die Anforderung von vorneherein klar gewesen hätte man die Lösung gleich so gebaut, dass sie den Kriterien entspricht. Doppelter Aufwand wäre vermieden worden.

Der Trick an der Vermeidung von Fehlern ist möglichst viele Informationen früh im Software Life Cycle zu erheben und gleichzeitig bei den Arbeitsergebnissen früh Feedback zu erhalten. Am besten geht das durch Reviews der Arbeitsergebnisse durch Kollegen aber auch durch den Kunden, um Fehler zu entdecken und diese zu beheben, bevor teure Ressourcen mit der Codierung beauftragt werden.

Prozesse und deren Umgehung

Prozesse sind wichtig um für Arbeitsvorgänge ein standardisiertes Vorgehen verfügbar zu haben. Dadurch kann eine Organisation und damit jeder einzelne Mitarbeiter effizient arbeiten. Prozesse schaffen auch Klarheit darüber wer was in welcher Reihenfolge zu tun hat. Prozesse erlauben auch Planungssicherheit herzustellen.

Was passiert aber, wenn durch Machteingriffe Vorgesetzter in Prozesse eingegriffen wird und damit der Sinn der Prozesse in Frage gestellt wird?

Neben der Frustration in der Belegschaft, die dieses Vorgehen auslösen wird ergibt sich auch eine potentielle Destabilisierung der Prozesse (zumindest temporär).

Generell nützen Prozesse der Sache, der sie dienen. Führt man sie im Management ad absurdum muss man sich als in der Sache beteiligter Manager über die Auswirkungen bewusst sein. Es gilt abzuwägen, ob man nicht genau mit einer solchen Aktion ein Zeichen setzt, das in der Wahrnehmung der Belegschaft den Prozess  als unwichtig gesehen wird.

Ich bin der Meinung, dass Prozesse da sind, damit sich jeder daran hält. Die Aufgabe des Management muss es also sein, den Prozess zu schützen und keinesfalls zu umgehen. Wenn der Prozess den Anforderungen nicht genügt und Ad-Hoc-Entscheidungen notwendig werden, muss der Prozess danach geändert werden, so dass er den Fall, der die Ad-Hoc-Entscheidung notwendig machte, in Zukunft unterstützt.