Agilität auch im Anlagenbau ?

Agilität auch im Anlagenbau ?

Eike Eilks, Interim Manager, Berater und Coach

 

Traditionell werden Großprojekte im Bau und Anlagenbau nach genormten und erprobten Prozessen abgewickelt. Durch eine Projektsteuerung nach dem Wasserfallmodell mit vielen Prozessen und viel Dokumentation sollen unter Einsatz technischer Hilfmittel Problemen hinsichtlich der Termin, Qualität und der Kosten verhindert werden.
 
Das ist jedoch meist nicht erfolgreich. Weniger als 20% der Projekte enden nach den klassischen Kriterien mit einer Bewertung als weitgehend erfolgreich. Enttäuschte Kundenerwartungen sind der Regelfall ebenso wie das Verfehlen der Ziele des Lieferanten.

 

Meist wird das Eintreten dieser Mängel mit einer unzureichend proffessionellen Anwendung der vorgegeben Prozesshäuser begründet. Aber ist das richtig ?

 

Willkommen in der VUCA – Welt

In einem zunehmend dynamischen und volatilen Wirtschaftsumfeld sind naturgemäß auch die Projektteams im Anlagebau ständig neuen Einflüssen, Veränderungsprozessen und Unsicherheiten ausgesetzt, auch wenn man von außen betrachtet dieses nicht immer wahrnimmt.

So wird der BER in Berlin, wenn er fertig werden sollte, von außen durchaus der BER sein, den man glaubte zu brauchen und er wird den Zweck dieses Projektes mehr oder weniger gut erfüllen (was aber erst die Zukunft zeigen wird, die wir heute noch nicht kennen). Vergleicht man aber die ursprüngliche Planung mit dem heutigen Stand oder dem zukünftigen finalen Ergebnis, so werden aber nur wenige Details übereinstimmen.

Auch wenn eigentlich beim Bau einer großen Anlage (man nehme als Beispiel diesen Flughafen) bei der Entscheidung für den Neubau eigentlich alles klar zu sein scheint, so wird bei näherer Betrachtung schnell sichtbar, dass das fixe Bild hier steht bald der Flughafen in Wirklichkeit etwas hoch Dynamisches ist, dass sich von innen heraus, ebenso wie durch Einflüsse von außen ständig verändert. Allein das Ziel erscheint definiert und fixiert. Doch auch dieses mag variieren. So wurde im Laufe des Projektes BER die prognosizierten Fluggastzahl häufig angepasst, was dann Folgen für die Realisierung bestimmter Teilanlagen hatte.

Diese immer häufiger eintretenden Veränderungen führen die überwiegend linearen Abwicklungsmodelle der klassischen Projektmanagementmethoden  immer mehr an ihre Grenzen. Bedingt ist dieses schon allein aufgrund der Komplexität der heutigen Lösungen sowie auch durch die Innovationsgeschwindigkeit der technischen Entwicklungen.

In der Folge sind die meist bis zum Ende der aktuellen Projektphasen (teilweise auch bis zu Projektende) durchgerechneten Planungen häufig nachzuführen und werden hochdynamisch. Dieses bedeutet einen erheblichen Aufwand. Auf der anderen Seite erfolgt die Planungsanpassungsarbeit in dem Bewusstsein, dass der Verlässlichkeitshorizont sehr begrenzt ist.

Warum also viel Arbeit in etwas stecken, dass Morgen, nächste Woche spätestens aber im nächsten Monat makulativ ist. Wie sehen die Alternativen aus?

Alternativen

Diese Problematik wurde im Bereich der Softwareentwicklung schon in den 90ziger Jahren schmerzlich bemerkt, getrieben auch durch die nahezu unendliche Vielzahl der möglicher Lösungsvarianten immer komplexerer Anforderungen an die IT-Systeme. Oft wirkten sich Veränderungen von Rahmenbedingung im Zeitraum des Projektes dahingehend aus, dass die benötigten Funktionen des am Ende des Projektes übergebenen Produktes sich gegenüber dem zu Anfang angeforderten deutlich unterscheiden.

Basierend auf Konzepten, die erstmals im 2.Weltkrieg in der Entwicklung von Flugzeugen in den USA erprobt wurden, wurde Anfang dieses Jahrtausend ein neuer Fokus für die Herangehensweise in der Softwareentwicklungspraxis entwickelt. Dieser trägt der Erfahrung Rechnung, dass die zu entwickelnden Produkte zu Beginn des Projektes nicht vollständig durchdacht sind und meist auch nicht sein können. Damit sind sie weder vollständig beschreibbar und spezifizierbar. Um mit dieser Realität umzugehen wurden andere Prozesse und Abläufe notwendig, als die, die in der bisherigen Praxis anzuwendet wurden.

Die Grundgedanken dazu wurden im “Agilen Manifest” beschrieben und werden heute in vielen Managementbereichen in Varianten angewandt.

Im Anlagenbau schließt es sich jedoch vordergründig aus, dass sich das am Ende des Projektes übergebene Produkt von dem zu Beginn des Projektes bestellten unterscheidet. Der Kunde benötigt seine Anlage für einen bestimmten Zweck, meist, um damit etwas zu produzieren, etwas zu testen oder um bestimmte Auflagen zu erfüllen. Wenn aber das Ziel konkret fest zu stehen scheint, dann erscheint der Standard “Wasserfallmodell” doch genau richtig dieses zu erreichen?
 

Dennoch ist es auch im Bereich von Anlagen- und Bauprojekten eher der Regelfall als die Ausnahme, dass es trotz aller Proffesionalität zu Problemen mit den Qualitäts-, Kosten- oder Terminzielen kommt.

Warum ist das so ?

Auch der Anlagenbau befindet sich in einem zunehmend volatilen Umfeld und ist ständigen immer schnelleren Veränderungen ausgesetzt. Bei Projektlaufzeiten von meist mehreren Jahren ist es auszuschließen, dass diese Veränderungen im Umfeld oder in den Anforderungen nur marginalen Einflüß auf das Projekt haben.
 

Das Wasserfallmodell kommt trotz professionellem Change- und Claim-Management schnell an seine Grenzen, wenn diese Veränderungen der Regelfall des Tagesgeschäftes werden und so der Planungsaufwand explodiert. Eine Vertrags- und Umgangskultur, die von Misstrauen, Konflikten und einer daraus resultierenden aggressiven Streitkultur geprägt ist, fördert die Schwierigkeiten. Wirtschaftsliberale Ansätze, die proklamieren, dass alle Unternehmen sich wirtschaftlich immer und in alle Richtungen optimieren wollen, lassen jeden Anpassungswunsch und jede Verzögerung schnell zum Objekt des Vertrags- und Claimmanagements werden.

Um eine Benachteiligung der eigenen Position zu vermeiden, leben wir also mehr eine Vertragskultur als eine Projektpartnerschaft. Der Versuch die Verträge durchzusetzen, ist das vermeintlich probate Mittel, das eigene Projektziel zu erreichen. Da aber jeder Teilnehmer am Projekt vertraglich in einer anderen Situation ist, wird auch sein Projektziel ein anderes sein.

Es stellt sich die Frage, ob die Summe des notwendigen Ressourceneinsatzes zur Rettung der eigenen Position im Sinne dieser Kultur, insbesondere auch im Angesicht des aktuellen Fachkräftemangels, sinnvoll ist, oder ob durch Einführung einer Kultur partnerschaftlicher Geschäftsbeziehungen sowohl eine Begrenzung der Kosten-, als auch der Terminüberschreitungen in Realität nicht besser erreichbar wäre.

Auch bleibt festzustellen, dass es auch im Anlagenbau kaum ein Projekt gibt (und das gilt wohl auch in vielen anderen Branchen, in denen Kundenprojekte abgewickelt werden), in dem alle Details der Realisierung und der Anlage bei Vertragsunterschrift spezifiziert sind. Die ungeplante aber notwendige Kernbohrung durch Wände und Ebenen des neuerichteten Betonbaus gehört zur Tagesordnung.

Im Regelfall erreichen wir diesen Spezifizierungsgrad nicht einmal mit dem ersten oder zweiten Design-Freeze. Erst die “As-Build”-Dokumentation kommt diesem Anspruch nach. Wesentlich sind nur die vom Kunden vorgegebenen essenteillen Requirements, die sicherstellen, dass die Anlage nach Übergabe auch ihren Kernzweck erfüllt. Der Weg bis zu dieser Anlage, sowie viele technische Details einer solchen Anlage werden erst im Rahmen des Engineerings festgelegt und abgestimmt.  Das aber erinnert sehr stark an den agilen Ansatz.

Ein “Agiles Manifest” für den Anlagenbau

So wie in die Bauausführung mit Lean-Construction bereits Modelle und Ansätze aus der Welt des Lean-Production hineinadaptiert wurden, bieten sich auch für das Engineering und die Planung Ansätze des agilen Managements an. 

Agilität bedeutet Gewandtheit, Reaktionsvermögen, Flexibilität und Wendigkeit. Verständlich wird dieses Erfordernis, wenn man bestimmte Grundanahmen als Realität akzeptiert:

  1. Veränderungen sind der Regelfall, nicht die Ausnahme
  2. Im Zentrum von Leistungen stehen Menschen, nicht Prozesse oder Tools
  3. Führung muss dienen – sowohl den Mitarbeitern als auch dem Ziel
  4. erfolgreiche Entwicklung erfolgt iterativ und inkrementell
  5. Erfolge sind bewertbar, aber nicht vollumfänglich messbar

Betrachten wir diese Realitäten für die Anlagenplanung und die Bauausführungsplanung als den Kernbereich von Projekten im Anlagenbau und fokussieren auf zufriedene Kunden (also einem Kunden der aufgrund guter Erfahrungen gerne den nächsten Auftrag erteilt, anstatt aufgrund des Vermutung das kleinere Übel zu wählen),  so sind die Parallelen zur Situation in der IT-Systementwicklung der 90ziger Jahren sichtbar. Mit der Fokussierung auf zufriedenen Kunden müsste also auch das agile Manifest als Grundidee übertragtbar sein.

Eine mögliche Adapation für den Anlagenbau, könnte wie folgt aussehen:

Individuen und deren Interaktionen

vor

Prozessen und Werkzeugen

Funktionierende Technik

vor

umfassender (Detail-)Dokumentation

Zusammenarbeit mit den Kunden

vor

Vertrags- und Claimverhandlungen

Eingehen auf Veränderung

vor

der Befolgung von Plänen

Schauen wir uns im folgenden die zugrundeliegenden fünf Annahmen an und was sie für den Anlagenbau bedeuten:

Annahmen

1.) Veränderungen als Regelfall akzeptieren

Auch der Anlagenbau agiert in einem zunehmend volatilen Umfeld, auf das immer mehr disruptive Ereignisse einwirken. Die typischen Märkte verändern sich, Anlagen werden heute in immer kürzeren Zyklen geplant, angepasst und modernisiert. Technische Entwicklungen erfolgen schneller und bewirken ebenso wie gesellschaftliche Veränderungen neue Anforderungen. Noch verfügen wir in Deutschland über ein stabiles politisches System, nichts desto trotz verändert sich aber die politische Lage in immer kürzeren Zyklen mit immer stärkerem Einfluß von Influenzern. Dieses hat Einfluss auf die Abwicklung von Projekten.

Zu akzeptieren, dass Veränderungen permanent und real eintreten, zwingt zu einem professionellen Umgang damit. In der klassischen Form der Projektabwicklung werden Veränderungen in erster Linie als Störungen empfunden und auch so behandelt. Der Projektleiter hat die Aufgabe die Störung abzuwehren, zu begrenzen oder zu kompensieren. Über das Vertragsmanagement wird mit viel Aufwand der Versuch gestartet, dieser Aufgabe nachzukommen und die Auswirkungen zu mindern bzw. über das Claim-Management Kompensationen zu erreichen.

Die agile Projektabwicklung versteht Veränderung nicht als Störung, sondern als gegeben (ggf. sogar als willkommen) an. Damit wird das Veränderungsmanagement integraler und wesentlicher Bestandteil der Abwicklung und nutzt kreative Methoden zur Lösungsfindung und Innovation. Das auf Abwehr und Kompensation ausgerichtete klassische Vertrag- und Claim-Management ist diesem Ziel nach- und untergeordnet. Es wird ergänzt bzw. ersetzt durch ein kreatives und kooperatives Changemanagement, das für die Veränderung gemeinsam mit dem Kunden oder Lieferanten eine Lösung sucht und findet, in denen selbstverständlich auch die kommerziellen und terminlichen Aspekte berücksichtigt sind.

2.) Die Menschen stehen im Zentrum der Leistungserbringung

Um Projekte im Anlagenbau zu realisieren ist die Zusammenarbeit verschiedenster Fachbereiche zwingend erforderlich. Üblicherweise werden die notwendigen Arbeiten in viele kleine separate Arbeitspakete mit jeweils nur einem fachlichen Schwerpunkt unterteilt, die von einzelnen Kollegen oder einem kleinen Team von Spezialisten realisiert werden können. Bei genauer Betrachtung wird jedoch deutlich, dass diese Arbeiten meist nur aufgrund von Informationen erfolgen können, die über eine Vielzahl von Schnittstellen durch andere bereitgestellt werden.

Um diese Informationen sicherzustellen wird die Kommunikation durch Strukturen und Schnittstellen vorgegeben, die den Informationsfluss sicherstellen sollen und die Arbeitspakete mit einander verzahnen. (Verzeichnisstrukturen, Dateinamenskonventionen, Kommunikationsmatrizen, Statusmeetings, Protokolltemplates, Abstimmungskonferenzen, Workflowdefinitionen, …)

Bertrachtet man gut laufende Projekten, so stellt man fest, dass die meist auf Mitarbeitern basieren, die sich als echtes Team verstehen und als solches agieren. In solchen erfolgt die benötigte Kommunikation überwiegend außerhalb von vorgegebenen Kommunikationsstrukturen. Diese werden zwar pro Forma zusätzlich genutzt, bedeuten aber nur einen geringen Gewinn an Qualität und Sicherheit. Benötigte Schnittstellen, Formate und Prozesse entwickeln die Mitarbeiter solcher Teams mit pragmatischen Ansätzen nach eigenem Bedarf selbst und lassen diese ggf. auch wieder sterben.

Wenn wir davon ausgehen, dass die Mitarbeiter in unseren Projekten gut ausgebildet sind und wissen was sie tun und brauchen, warum dann nicht die im Projekt arbeitenden Menschen mit Ihren Bedürfnissen in den Mittelpunkt stellen. Strukturen, Regeln, Vorgaben… soweit benötigt und akzeptiert ja, aber weniger fixierte Prozesse nutzen und statt dessen mehr Verstand. Spielräume für Selbstorganisation ermöglichen Flexibilität und erweisen sich als produktivitätssteigernd.

3.) Führung dient – sowohl den Mitarbeitern als auch dem Ziel

Studien über den Erfolg von Projekten und damit über den Erfolg des Projektmanagements weisen leider immer wieder erschreckend niedrige Erfolgsraten auf. Weniger als 20% der Projekte werden trotz umfangreicher PM-Prozesshandbücher, technischer Hilfsmittel und eines engen Controllings erfolgreich abgeschlossen, zumindest, wenn man die zu Beginn des Projektes festgelegten Ziele betrachtet.

Die in diesen Studien ermittelten Ursachen verweisen auf das immer noch fest verankerte Menschenbild aus der Frühzeit der industriellen Revolution, wie sie von F.W. Taylor Anfang des letzten Jahrhunderts für die Unternehmensorganisation beschrieben wurden. “Unten wird gemacht, oben wird gedacht!”

Durch konkrete Vorgaben für Verhalten, Aufgabe und Handlung wurde es auch weniger Qualifizierten ermöglicht, fachlich zwar begrenzte, aber dennoch produktive Arbeit zu leisten. Jedoch wird so die Flexibilität der Organisation eingeschränkt, da die Möglichkeit kreative Entscheidungen treffen auf wenige Vorgesetzte konzentriert wird, die in höheren Bereichen der Hierarchie angesiedelt sind. Diesen fehlt aber oft das Detailwissen zu den Problemen und zu deren Lösungsoptionen. Die in dieser Form getroffenen Entscheidungen sind für die betroffenen Mitarbeiter oft unverständlich. Die Annahme, dass es noch andere ihnen unbekannte Aspekte für diese Entscheidungen gibt, kasschiert dieses nur begrenzt. Schnell empfinden sie solche Entscheidungen als Sabotage an den von ihnen erbrachten Leistungen und als Ignoranz ihrer Kompetenz und ihres Engagements. Das führt zu Demotivation, zu Frustration und letztendlich zu Fluktuation.

Seit dem Ende des letzten Jahrtausends verändert sich das Menschenbild in der Wirtschaft wesentlich. Unsere Arbeitsmärkte sind heute überwiegend von hoch qualifizierten Mitarbeitern geprägt, die wir auch aufgrund der immer weiter zunehmenden Komplexität in Wirtschaft und Technik dringend brauchen. Diese Menschen sind meist intrinsisch motiviert und fordern, ihre Fähigkeiten, ihre Kompetenzen sowie ihre Kreativität selbstverantwortlich einbringen zu können. Diese Forderungen, eine akzeptable Vergütung und vor allem das Wahrnehmen ehrlicher Wertschätzung als Rückmeldung für ihre Leistung sind heute die wesentlichen Motivatoren.

Agile Führung fokussiert genau in diese Richtung. Grundlage ist ein Menschenbild, das diese intrinsische Motivation fördert und bewusst versucht zu leiten anstatt zu führen. Der Mitarbeiter wird als kompetent, kreativ und befähigt verstanden. Die Führung solcher Teams versteht sich daher mehr als dienende Führung (Servant Leadership). Diese gibt lediglich das Ziel und einen Rahmen für die Selbstorganisation des Teams vor und versucht Behinderungen für die Mitarbeiter und das Team zu beseitigen. Servant Leadership verzichtet auf die Nutzung eines erheblichen Teils der bisheriegen Weisungs- und Kontrollmechanismen der Vorgesetzten.

4.) Erfolgreiche Entwicklung erfolgt iterativ und inkrementell

Iterationen in Form von häufigen Feedbackschleifen prägen agile Prozesse. Im Rahmen dieser Schleifen werden Step-by-Step die Teile der Gesamtleistung inkrementell geklärt und geschaffen. Die Kunden bleiben in die Entwicklung eingebunden, so dass die generierten Werte über Reviews ständig bestätigt, verändert, optimiert, überarbeitet und erweitert werden können.

Ständige Qualitätskontrollen sind Teil dieses Prozesses. Der Kunde erlebt den den Fortschritt des Projektes mit und ist über das sich entwickelnde und entstehende Produkt und die Probleme gut informiert. Größere Differenzen zwischen den Vorstellungen des Kunden und dem realen Ergebnis werden auf diese Weise vermieden. Dieses betriff auch Rahmenparameter wie die Termin- und Kostensituation. Notwendige und gewünschte Anpassungen fliessen in den Prozess ein und werden lösungsorientiert betrachtet und bearbeitet. Gemeinsam mit dem Kunden und/oder Lieferanten wird versucht aus qualitativer, aus terminlicher und aus kommerzieller Sicht eine sinnvolle Lösung zu entwickeln.

Auch wenn im Anlagenbau das finale System genauer feststeht, als dieses beispielsweise in der IT oft der Fall ist, so sind doch viele Aspekte auf dem Weg dorthin erst im Rahmen der Entwicklung festzulegen. Nutze ich eine große, zwei mittlere oder drei kleine Pumpen, um eine bestimmte Menge Fluid zu bewegen? Was für Materialien nutze ich, um Rohrstrecken zu bauen? Steuere ich Ventile mit Luft, Hydraulik oder elektrisch an? Wie sieht das Brandschutzkonzept aus? ….. Hieraus ergeben sich Optionen und Fragen.

Entscheidungen führen ggf. zwar in technisch korrekte Lösungen, die seitens des Kunden aber nicht favorisiert werden. Durch kurze Iterationen kann schnell nachgesteuert und so der Aufwand für Fehlentwicklungen klein gehalten.

5.) Erfolge sind bewertbar, aber nicht exakt messbar

Klassische Projekte bewerten den Projekteerfolg als Vergleich zwischen dem Output und den ursprünglichen Plänen, die zu Projektbeginn festgelegt wurden (Meilensteine, Dokumentenlisten, Requirements, Kostenrahmen, Termine, sonstigen Anforderungen, … ).

Der zu realisierende Kundennutzen liegt damit allein in der Verantwortung des Auftraggebers, der diese Verantwortung in Form der von ihm erstellten, bzw. beigestellten Spezifikation als Vertragsbestandteil wahrnimmt. Sind in dieser Spezifikation aber Fehler vorhanden, oder ist diese unklar formuliert, so werden diese Fehler oder Missverständnisse im Zweifelsfall umgesetzt, was auch dazu führen kann, dass die Anlage nach Inbetriebsetzung nur eingeschränkt genutzt werden kann. Der Kunde erhält zwar genau das, was bestellt ist, ist aber mit dem Ergebnis unzufrieden.

In agil abgewickelten Projekten werden die Nützlichkeit und die Funktion der Anlage (bzw. des Produktes) in den Vordergrund gesetzt. Die konkrete Beschreibung der Anlage tritt dabei hinter dem Nutzen und der Funktion zurück.

Dieser Nutzen wird in der Spezifikation beschrieben, ist aber auch im Laufe des Projektes anpassbar. Wesentliches Projektziel ist der für den Kunden entstehenden funktionale Mehrwert aus Sicht des Kunden. Um dieses zu erreichen ist eine durchgehend enge Zusammenarbeit und intensive Kommunikation mit dem Kunden während der Umsetzung unverzichtbar. Änderungen werden von beiden Parteien nicht als Störung empfunden, sondern als Bestandteil des Prozesses. Dieses inkludiert aber auch eine offene und ehrliche Kommunikation über die Kosten der Veränderung und über die terminlichen Auswirkungen.

Der relativ exakt bestimmbare Vergleich zwischen Spezifikation und Output weicht also Bewertung der Zufriedenheit des Kunden mit dem Ergebnis anhand den in der Spezifikation festgelegten Zielen.

Implementierung in Projekten im Anlagenbau

Durch die ständigen Veränderungen und Unsicherheiten werden die Anforderungen an die Projektteams auch im Anlagebau immer größer. Den eher linearen Abwicklungsmodellen der klassischen Projektmanagement-Methoden werden immer mehr die Grenzen aufgezeigt. Die meist bis zum Ende der aktuellen Projektphasen (teilweise bis zum Projektende) durchgerechneten Planungen sind häufig nachzuführen und somit hochdynamisch. Dieses bedeutet  einen erheblichen Aufwand. Und leider auch Frustration, da schon die Planungsanpassungsarbeit in dem Bewusstsein erfolgt, dass der Verlässlichkeitshorizont sehr begrenzt ist. Warum also viel Arbeit in etwas stecken, dass bereits Morgen, nächste Woche oder im nächsten Monat makulativ ist?

Die Situation

Der Regelfall in Großprojekten sind erhebliche Kosten- und Terminüberschreitungen. Diese steigen statistisch sowohl mit der Laufzeit der Projekte als auch mit dem Einfluss öffentlicher Stakeholder. Die Kultur in solchen Projekten ist von Misstrauen zwischen den Vertragspartnern und darauf basierenden Konflikten geprägt. Hieraus resultieren viele Auseinandersetzungen. Im Managementteam solcher Projekte haben die Funktionen Vertragsmanagement, Claimmanagement und juristische Beratung oft die gleiche Personalstärke wie die der technischen Umsetzung. Dabei wächst der Arbeitsaufwand dieser Bereiche mit zunehmender Projektdauer aufgrund der entstehenden Historie überproportional. Anstatt im Laufe des Projektes ein Vertrauen mit Kunden oder Lieferanten aufzubauen, dass die Zusammenarbeit bei Folgeprojekten vereinfacht und den Folgeauftrag sichert, führt dieses dazu, dass die Wahrnehmung des Geschätspartner negativ vorbesetzt ist und nichts partnerschaftliches mehr hat. In der Folge müssen für jeden neuen Auftrag neue Kunden akquiriert und für jedes neue Projekt neue Lieferanten gefunden und bewertet werden. Ein hoher Aufwand sowohl für den Sales- als auch für den Procurement-Bereich.

Insbesondere im Kontext sich verengender Märkte und steigender Qualitätsanforderungen ist die durch diese Kultur ausgelöste Kräfteverschwendung unverständlich. Die Zusammenarbeit zwischen Kunde und Lieferant als Kern der agilen Ansätze bietet hier eine Alternative. Solange man miteinander spricht, schießt man nicht aufeinander und solange man miteinander arbeitet, solange entwickelt man Verständnis füreinander und mittelfristig auch Vertrauen. Verständnis und Vertrauen bieten den Schlüssel für kreative Lösungen, die für beide Parteien akzeptabel sind und beiden Parteien Aufwand sparen. Unnötiger Aufwand ist die teuerste Form von Verschwendung in Unternehmen.

Adaption von Methoden

Nun unterscheiden sich Software und Anlagenbau wesentlich, obwohl, wie ausgeführt auf abstrakter Ebene viele Ähnlichkeiten vorhanden sind. Um nun agile Methoden und Ansätze in den Anlagenbau zu adaptieren sind die Rahmenbedingungen zu betrachten. Aspekte sind zum Beispiel:
  • Anzahl der Stakeholder und Interessen
  • Flexibilitätsbedarf (wie häufig sind Veränderungen)
  • Komplexität der Lösung
  • Länge möglicher Iterationszyklen
  • Notwendige Reaktionsgeschwindigkeit
  • Projektphase und Überlappungen
  • Teamgröße
  • Umgangskultur der Vertragspartner
Hieraus ergeben sich Handlungsoptionen. Diese umfassen projektteaminterne Optionen, aber auch Optionen an den Schnittstellen zu den Partnern und Stakeholdern. Solche Optionen gehen bis zu übergreifenden Change-Projekten zur Implementierung einer neuen Umgangs- und Vertrauenskultur. Jedes Projekt im Anlagenbau beginnt mit umfangreichen Plannungs- und Konzeptionsarbeiten. Diese sind geprägt durch technische, organisierende und operative Kreativität. Die Komplexität eines solchen Projektes lässt es nicht zu, dass benötigte Kompetenz hierfür durch einen nur kleinen Kreis von Kollegen erbracht wird. Kommunikation ist das essenzielle Mittel, um die Kompetenzen der vielen beteiligten einzelnen Mitarbeiter zu vernetzen, um so brauchbare Ergebnisse zu erreichen. In vielen Projekten wird diese Kommunikation in normierte Pfade gezwungen, um die Weitergabe der Information in Perfektion sicherzustellen. In der Realität begrenzt aber dieses aber die Effizienz der Kommunikation. Die Entscheidung über wichtig und unwichtig ist nicht mehr möglich. Generiert durch Kommunikationsmatrizen und automatisierte Verfahren wird die ein E-Mail-Volumen hervorgerufen, das ein solches Ausmaß annimmt, dass die beteiligten Mitarbeiter zwar faktisch alle Informationen erhalten, aber nicht mehr in der Lage sind diese Flut zu lesen, geschweige denn, sie inhaltlich qualitativ sinnvoll zu verarbeiten. Das Ziel des Prozesse ist effizient konterkariert.

Gerade hier sind die agilen Ansätze stark. Durch tägliche Standup’s, in denen die Mitarbeiter ihre aktuelle Aufgabe, ihre Probleme und ihre Befürchtungen kurz kommunizieren, wird neben dem fachlichen Inhalt auch die Bedeutung der Person für das Projekt sichtbar. Es entsteht ein gemeinsames Bild des Projektes, dass zwar nicht exakt und absolut vollständig ist, aber besser den Status und die Herausforderungen des Projektes beschreibt, als dieses ein Statusformular kann. In interdisziplinäre Workshops auf Basis von Kreativitätstechniken können Mitarbeiter neue Lösungen für Probleme entwickeln, in dem sie auf Ideen von Kollegen zurückgreifen, die das Problem bisher nur von außen kennen. Retrospektiven über die Optimierung der Zusammenarbeit bieten die Möglichkeit, dass sich das Projektteam entlastet, in dem es möglich wird, bisherige Strukturen, Prozesse und Tools zu hinterfragen und diese zu reduzieren oder zu modifizieren, wenn deren Nutzen zweifelhaft ist. Die so frei werdenden Resourcen machen das Team bei der Lösung der anstehenden Aufgaben und Probleme effizienter.

Fazit

Wenn man auf einer abstrakten Ebene die Tätigkeiten, Anforderungen und Abläufe bei der Entwicklung von Softwaresystemen mit denen der Entwicklungsarbeiten im Anlagenbau vergleicht, so sind Ähnlichkeiten in der Komplexität erkennbar, jedoch auch Unterschiede. Hierbei fällt insbesondere auch der notwendige langfristige Vorausplanung bestimmter Arbeitssequenzen in der Realisierung ins Gewicht, die im Bereich der Softwareentwicklung die absolute Ausnahme sind. Auf der anderen Seite sind die sehr alten Paradigmen und Methoden in weiten Teilen dieser Branche zu sehen, die schnelle Veränderungen schwierig machen. Ein Umschalten in einen Anlagenbau „AgilePlantEngineering 4.0“ wird es also kurzfristig aufgrund der vorhandenen Strukturen und der etablierten Methoden nicht geben. Hybride Ansätze, in denen die klassischen Methoden durch agile Ideen ergänzt oder zum Teil ersetzt werden, sind aber durchaus hilfreich und können die bestehenden Abläufe an vielen Stellen entkrusten. Unternehmen, die diesen Weg gehen, sparen Ressourcen und werden flexibler. Beides sind Wettbewerbsvorteile.

Hier sehe ich großes Potential, dass bisher nur wenig realisiert wird. Um dieses zu heben sind Kenntnisse bezüglich der agilen Ideen und Werte erforderlich und die Bereitschaft, das was ist, in Frage zustellen, um kreative Adaptionen zu entwickeln. Die zunehmende Volatilität in den Märkten, auch im Anlagenbau, negiert die Frage nach dem „Ob“ automatisch. Jedes Unternehmen muss stattdessen für sich die Frage nach dem „Wie“ und „Wann“ beantworten.

Dieser Beitrag hat 3 Kommentare

  1. Eike.Eilks
    Carsten M.

    Die These ist interessant. Solange aber die meisten Projekte mit dem heissen Daumen kalkuliert und vergeben werden, entsteht schnell ein Kostendruck, der zu reaktivem Handeln führt. Damit verlieren Projektleiter die Fähigkeit zu handeln und geben dieses an die Juristen ab. Das ist wohl bei jedem öffentlichen Auftrag so, da nach Vergaberecht immer der billigste den Auftrag erhält. Da ist kein Platz für Nutzen und Agilität.

  2. Eike.Eilks
    Volker Engelke

    Hallo Eike

    Herzlichen Dank für Deine Ausführungen. Die sind es sicher wert zu diskutieren.
    Ich teile den Ansatz agile Methoden nutzbar zu machen. Die Schilderung der Situation zum klassischen Ansatz teile ich nicht.
    Auch hier geht es um Flexibilisierung und das Eingehen auf Veränderung bzw. den Erkenntnisgewinn während des Projektverlaufes.
    Nicht ohne Grund spricht man in der Abwicklung von unterschiedlichen Phasen, die auf Grund unterschiedlicher Gegebenheiten auch unterschiedliche Managementmethoden und unterschiedliche Führung benötigen. Eine Feasibility study oder das Basic Engineering ist eben keine Fertigung oder Montage und bedarf einer anderer Organisation und Vorgehensweise. Das ist auch klassisch so!
    Auch ist Vertrags- und Claimmanagement zumindest international nicht gleichzusetzen mit Streitkultur und wird auch wo es funktioniert nicht so gelebt.

    Die Sache erscheint mir also nicht so einfach zu sein und ein paar Kreativ-Workshops und Stand-up Meetings sind sicher nicht die Lösung. Ein agiler Mindset bedeutet die Selbstorganisation der Arbeiten und die Veränderung zum Prinzip zu machen und deshalb stellt auch eine Dokumentation, die schnell überholt ist, keinen Mehrwert dar. Dennoch gibt es ist in vielen Bereiche gesetzlichen Notwendigkeiten für eine umfängliche Dokumentation im Anlagenbau. So gilt es nicht nur hier tragfähige Kompromisse und Ideen zu entwickeln. In dieser Richtung verstehe ich auch Dienen Ansatz zum Agilen Manifest im Anlagenbau.
    Die Verhältnisse sind m.E. klarer zu fassen und den Paradigmenwechsel mit seine Folgen und Möglichkeiten klarer und eindeutiger zu beschreiben. Gerade hier freue ich mich auf den weiteren Austausch.

    herzliche Grüße
    Volker Engelke

    1. Eike.Eilks
      Eike.Eilks

      Ich stimme Dir zu. Ziel ist es, das Überkommene und Bewährte aus Vergangenheit zu ergänzen und zu überprüfen, nicht aber es auszumerzen oder zu ersetzen. Gerade bei großen Projekten ist Organisationsstruktur und Dokumentation wesentlich, um das Ziel nicht aus den Augen zu verlieren und das ganze Team (was durchaus sehr groß werden kann) in die gleiche Richtung zu leiten. Und natürlich auch um gesetzlichen Regelungen nachzukommen.

      Aber das genau ist das Thema: In vielen Projekten erscheint das einmal spezifizierte und festgeschriebene Ziel unveränderlich wie von Gott mit Blitzen in Granit gemeißelt und auf zwei Steinen zur Erde gesandt.

      Aber genau das passt heute nicht mehr (Wahrscheinlich hat auch nie gepasst, aber die Einflüsse von außen sind heute stärker und vor allem schneller). Als Beispiel nehme ich Projekte in der Verteidigung: Entwicklungen, die in 50ziger, oder 60ziger Jahren gestartet wurden, führten zu Gütern die für die Strategie meist noch passten, die Realität war, als die Güter verfügbar waren und in die Truppe eingeführt wurden. Das ist heute nicht mehr so. Die Entwicklungszeiträume blieben in etwa gleich, jedoch ändert sich die geostrategische Lage so schnell, dass heutige Rüstungsprogramme oft für Strategien spezifiziert werden, die zum Zeitpunkt der Fertigstellung der Güter oft schon 2-mal überholt sind.

      Heute wirkt sich der Einfluss scheinbarer Minderheiten oft plötzlich sehr stark aus. Greta Thunberg konnte in kürzester Zeit Millionen von Menschen mobilisieren, denen sich Politik und Wirtschaft nicht verschließen kann und konnte. Ohne Lösungen zu haben verändert sich der Weg in die Zukunft sich also sehr schnell. Projekte mit 5, 10 oder mehr Jahren Laufzeit werden in einem politischen oder wirtschaftlichen Umfeld fertig, dass möglicherweise ganz anders aussieht, als jenes, das man erwartet hat.

      An dieses Stellen ist insbesondere das Management von Projekten im Anlagenbau gefordert: Es muss akzeptieren, dass das Erfüllen eines Vertrages nicht mehr ausreichend ist, für den Erfolg des Projektes, sondern das der Umgang mit den Veränderungen im Zeitraum des Projektes Teil des Projektmanagements ist. Dazu ist aber eine neue Kultur im Miteinander der Vertragspartner erforderlich. Das ist der Ansatz des agilen Manifestes.

      Beste Grüsse
      Eike

Schreibe einen Kommentar