OFFSHORE-ZUSAMMENARBEIT ERFOLGREICH ETABLIERT:
fachartikelmehr zum REICH ETABLIERT:EIN PRAXISREPORT ÜBEREIN MIGRATIONSPROJEKTIM MASCHINENBAUder autorKlaus-Peter Wichmann(E-Mail: wkl@zuehlke.com) ist SeniorProjektmanager und Berater bei derZühlke Engineering AG in der Schweiz.Sein fachlicher Schwerpunkt liegt imBereich der globalen Softwareentwicklung.Der Artikel beschäftigt sich mit den Erfahrungen, die in einem international ausgerichteten Software-Entwicklungsprojekt unter Einbindung von indischen OffshoreRessourcen gesammelt wurden. Das Thema des Projekts ist die Migration einerAltanwendung auf moderne Technologien inklusive der Neuentwicklung einerzukunftsfähigen Architektur. Die Fachdomäne des Kunden ist der klassischeMaschinenbau, seine Produkte sind komplexe Strömungsmaschinen. Zweck derApplikation ist es, Konstruktionszeichnungen der Maschinen vollautomatisch zugenerieren. Ausgehend von den Herausforderungen im Kontext der OffshoreZusammenarbeit werden die gewählten Offshore-Ansätze und die Erfahrungen ausdiesem Projekt beschrieben und diskutiert.Der Auftraggeber des Projekts ist im Maschinenbau tätig und stellt im KundenauftragStrömungsmaschinen her. Ein Auftrag umfasstdabei die Konstruktion und die Herstellungder Maschine sowie die Inbetriebnahme vorOrt. Dabei erfolgt die Maschinenkonstruktionauf Basis einer hohen Produktstandardisierung. Alle Bauteile sind aufeinander abgestimmt und können unter Beachtung der technischen Regeln zu einer komplexen Maschinezusammengestellt werden.Die Auslegung – also die Auswahl derBauteile und die Berechnung der Bauteilmaße – wird durch eine bestehende Applikation unterstützt. Nach der automatischen Auswahl und Auslegung der Bauteileübernimmt eine zweite Applikation – imFolgenden „Zeichnungsgenerator” genannt– die vollautomatische Generierung derKonstruktionszeichnungen. Abbildung 1zeigt beispielhaft ein fiktives Bauteil mitseinen generischen Parametern.Diese Altapplikationen sind am Endeihres Lebenszyklus angelangt und dieWartung ist sehr aufwändig und teuergeworden. Daher wurde der Entschlussgefasst, sie von Grund auf neu zu entwickeln. In einem ersten Schritt soll zunächstder Zeichnungsgenerator ersetzt und in diebestehende Werkzeugkette migriert werden. Vom Auftraggeber gab es dann nocheine Randbedingung für das Projekt: Wennimmer möglich sollten Offshore-Ressourcen eines indischen Vertragspartners in dieEntwicklung mit eingebunden werden.5051In diesem Kontext berät er Unternehmen,leitet Offshore-Projekte und ist als Trainertätig.Abb. 1: Fiktives Beispiel für eines der 300 Bauteile mit generischen Parametern.
fachartikelAusgangslageEine Analyse zur Ausgangslage im Offshore-Kontext ergab das im Folgenden dargestellte Bild.Unzureichende Dokumentationdes AltsystemsDas Altsystem war nur rudimentär bzw.ungenügend dokumentiert. In bestimmtenBereichen fehlte die Dokumentation vollständig, in anderen Bereichen war sie nichtmehr auf dem neuesten Stand.Engpass bei den Fachexpertender ProblemdomäneDie Verfügbarkeit der Fachexperten – alsoder Maschinenbau-Ingenieure des Kunden– war ein wichtiger Erfolgsfaktor imProjekt, auch gerade wegen der unzureichenden Dokumentation des Altsystems.Bei diesem Personenkreis lag jedoch einpersoneller Engpass vor. Einerseits gab esnur sehr wenige Mitarbeiter, die über dasnotwendige Fachwissen verfügten, auf deranderen Seite bestand das personelleRisiko, dass sie zur Unterstützung der eigenen Auftragsabwicklung abgezogen werden könnten.Wenig Erfahrung im Erstellender SpezifikationenDie Fachexperten verfügten über wenigErfahrung, Spezifikationen mit der notwendigen Qualität und Eindeutigkeit fürdie Offshore-Zusammenarbeit zu schreiben. Für lokal durchgeführte Projekte magdies in dem einen oder anderen Fall ja nochgenügen, bei Offshore-Projekten handelt essich jedoch um eine Schlüsselfähigkeit.Hohe Anforderungen an dieRichtigkeit der KonstruktionsdatenDa die Fertigung zwar nicht ausschließlich,aber zum Teil direkt ab den generiertenZeichnungen erfolgt, gab es hohe Anforderungen an die Richtigkeit der Datenin den Zeichnungen. Im ungünstigsten Fallwerden die Fertigungsfehler erst bei derMontage entdeckt. Die Kosten zur Behebung könnten dann sehr hoch ausfallen.Viele zu beherrschende DetailsFür den Zeichnungsgenerator wird dieErstellung einer Bauteilbibliothek mit ca.300 Elementen benötigt. Jedes Element hatdurchschnittlich 25 Parameter. Insgesamtliegen also ca. 7.500 Parameter vor. DieApplikation kennt weiter die Businesslogik3/2008zur Erstellung von 5 Zeichnungstypen.Diese Logik umfasst neben der Bauteilbibliothek umfangreiche Regeln für dieVermaßung der Konturen, wie zum BeispielLängen- oder Winkelmaße.W ie wurde dasProjekt gestartet?Nach der Analyse der Ausgangslage beschäftigten wir uns mit den konzeptionellen Fragen zur Zusammenarbeit und damit,wie das Projekt am besten gestartet werdensollte. Die im Folgenden geschilderten fünfAktivitäten bekamen eine hohe Prioritätund wurden früh im Projekt umgesetzt.Schlüsselrollen besetzenDa das Kernkerngeschäft des Unternehmens im Bereich Maschinenbau liegt undweniger im Software-Engineering, wurdenExperten von Zühlke für die Schlüsselrollen ins Projekt geholt. Dazu gehören derProjektmanager, der Softwarearchitekt mitSchwerpunkt in der Computergrafik sowieder Testmanager. Dieses Kernteam erhieltden Auftrag, das allgemeine Vorgehen, dieEntwicklungsprozesse und die technischenKonzepte zu definieren.Know-how-Transfer insOffshore-Team sicherstellenKurz nach Projektstart wurde ein Mitarbeiter des Offshore-Partners zur Ausbildung vor Ort beim Auftraggeber eingeladen. Dieser Mitarbeiter sollte später inIndien die Rolle des Team-Leaders übernehmen und Hauptansprechpartner für Der Interaktionsbedarf mit denFachexperten vor Ort ist gering. Die Anforderungen an die Komponente sind bekannt und spezifiziert. Das Verhältnis Aufwand zu Nutzenfür die Erstellung der Spezifikation istwirtschaftlich gerechtfertigt. Die Komponente gehört nicht zurKernkompetenz des Kunden (Geheimhaltung, Schutz vor Industriespionage). Die Komponente weist eine geringeKomplexität auf. Es bestehen nur geringe Abhängigkeiten zu anderen Applikationen.Kasten 1: Kriterien zur Einstufung derKomponenten auf ihre OffshoreTauglichkeit.den Projektleiter sein. Er begleitete dasProjekt vor Ort für ca. sechs Monate undlernte in dieser Zeit das Fachgebiet, dieAnforderungen, die Architektur und dieEntwicklungskultur gut kennen. Ein ersterWissenstransfer war somit organisiert.Geeignete Komponenten fürsOffshoring auswählenAuf Basis eines ersten, stabilen Architekturentwurfes wurde dann eine Analyseder Softwarekomponenten auf ihre Eignung für die Offshore-Entwicklung durchgeführt. Die angewandten Kriterien für diese Einstufung sind im Kasten 1 dargestellt.Wichtigstes Kriterium war der „Interaktionsbedarf mit den Fachexperten”. Beieinem mittleren bis hohen Bedarf, sollte dieEntwicklung aus wirtschaftlichen Gründenbesser vor Ort erfolgen.Dem Offshore-Team wurden nach dieserAnalyse die Implementierung und dasTesten der Bauteilbibliothek zugeordnet.Als weitere Aufgabe wurde dem OffshoreTeam die Durchführung der Systemtestszugewiesen. Beide Aufgaben umfassten ca.50 % des gesamten Entwicklungsaufwands.Das lokale Team war dann verantwortlich für die Entwicklung der Schnittstellezum Altsystem, für die Entwicklung desDatenmodells der Maschine und für dieBasismechanismen. Warum wurden diesedrei Komponenten lokal entwickelt? DasDatenmodell repräsentiert die Kernkompetenz des Kunden und stellt damit ein schützenswertes Gut dar. Für die Implementierung der Schnittstelle zum Altsystemsind wegen der fehlenden Dokumentationviele Interaktionen mit den Fachexpertennötig. Die Basismechanismen sollten vorOrt implementiert werden, um eine flexibleund zukunftsorientierte Architektur sicherzustellen.Die Arbeitsteilung zwischen den verteilten Teams ist in Tabelle 1 dargestellt.Entwicklungsprozess definierenWie sah der Prozess vor Ort aus? Die lokalen Entwicklungen erfolgten nach demRational Unified Process. Es wurde iterativin enger Zusammenarbeit mit den Fachexperten entwickelt. Eine Iteration dauertevier Wochen und wurde jeweils mit eineminternen Release abgeschlossen. DieFreigabe der einzelnen Entwicklungsphasen durch den Auftraggeber erfolgtenach dem im Unternehmen vorhandenen
fachartikelDisziplinLokales lAnalyse & DesignLokalImplementierung und Test- Basismodule- ReferenzimplementierungLokalOffshore TeamImplementierung und Test- auf Basis mentOffshoreLokalKonfigurations- EnvironmentLokalOffshoreTabelle 1: Arbeitsteilung zwischen dem lokalen und dem Offshore-Team.Abb. 2: Der Offshore-Arbeitsablauf in einer groben Übersicht.5253Quality-Gate Process.Bevor die Zusammenarbeit mit dem Offshore-Team beginnen konnte, wurde nochder Offshore-Entwicklungsprozess festgelegt und in Form eines Kooperationsplansdokumentiert. Beim Offshore-Prozess wurde anders als beim lokalen Prozess vorgegangen. Grundlage des Prozesses warenArbeitspakete, die beim Offshore-Team inAuftrag gegeben wurden. Alle Tätigkeitendes Offshore-Teams wurden über formalisierte Aufträge gesteuert. Die einzelnenSchritte bestanden aus: Erstellen der Spezifikation vor Ortinklusive Review und Freigabe Implementierung, Test und TestreportErstellung durch das Offshore-Team Abnahmetest der Lieferung vor Ort Start der Nachbearbeitung im FehlerfallDer grobe Arbeitsablauf zwischen demlokalen und dem Offshore-Team ist in demAktivitätsdiagramm in Abbildung 2 zusehen.Großen Wert legten wir auf eine guteSpezifikation. Testfälle und Testdaten wurden vom lokalen Team definiert und warenBestandteil der Spezifikation.Mit dem Offshore-Team wurde dann alswichtiges Ziel vereinbart, möglichst wenigeNachbearbeitungen anzustreben, da dieseunnötigen Aufwand auf beiden Seiten erzeugen. Der Offshore-Prozess wurde in einemKooperationsplan dokumentiert und mit demOffshore-Team besprochen. Das Inhaltsverzeichnis dieses Plans zeigt Kasten 2.Den kontinuierlichenKommunikationsfluss sicherstellenAus Erfahrungsberichten von OffshoreProjekten wussten wir, dass ein kontinuierlicher Kommunikationsfluss und persönliche Treffen zu den Erfolgsfaktoren imOffshoring gehören. Aus diesem Grundeplanten wir die ständige Anwesenheit mindestens eines indischen Mitarbeiters vorOrt. Seine Hauptaufgabe war es, als Kommunikationsschnittstelle zum OffshoreTeam zu wirken. Er war Ansprechpartnerfür beide Teams für unklare, technischeAnforderungen und sorgte dafür, dassAnfragen unverzüglich geklärt wurden.Die zweite wichtige Maßnahme war es,ein- bis zweimal pro Woche Telefonkonferenzen mit dem Offshore-Team durchzuführen. Ein solches Ferntreffen dauerte inder Anfangsphase zwischen 30 und 60Minuten, in der Routinephase ging der
EinführungProjektzieleMeetings auf ManagementebeneMeetings auf kturGemeinsam genutzte WerkzeugeInfrastruktur in IndienSoftwarelizenzen in arbeitsmodellDetaillierter gurationsmanagementKasten 2: Inhaltsverzeichnis desKooperationsplanes.Bedarf auf 15 bis 30 Minuten zurück.Technisch wurde die Kommunikationdurch gemeinsam genutzte Werkzeuge unterstützt. Eingesetzt wurden eine Projektdatenbank (Repository), ein Wiki, einFehlerverwaltungswerkzeug sowie ein Werkzeug zur Verwaltung der Arbeitspakete.Erfahrungen aus dem ProjektIn dem Projekt ist es gelungen, eine gutfunktionierende Zusammenarbeit mit demindischen Partner zu etablieren. AlleLieferungen erfolgten im geplanten Zeitrahmen und mit der notwendigen hohenQualität im Hinblick auf die Richtigkeitder Zeichnungen. Das Offshore-Team zeigte sich als sehr engagiert, die Arbeitsatmosphäre war entspannt und angenehm.Im Laufe der jetzt einjährigen Kooperationkonnten wir die folgenden Erfahrungenmachen und Erkenntnisse gewinnen.Bedeutung der SpezifikationenEin entscheidender Erfolgsfaktor in demProjekt war die Erstellung der Spezifikationfür die Offshore-Implementierungen. Wirhaben insbesondere davon profitiert, dasswir die Testfälle und Überprüfungspunktegleich am Anfang eines jeden Arbeitspaketsmitgeliefert hatten. Auf der einen Seitekonnten wir so gezielt die Testtiefe beeinflussen. Ein vereinfachtes Beispiel dazu:Falls der Radius REG in Abbildung 1 auchden Wert 0 annehmen kann, wurde hierfürein zusätzlicher Testfall definiert. Anhandder gelieferten Testprotokolle konnten wir3/2008dann schnell sehen, ob die Implementierungauch den Sonderfall REG 0 berücksichtigthatte. Auf der anderen Seite unterstützengute Testdaten ein unabhängiges Arbeitendes Partners, denn es gibt weniger Bedarfan Rückfragen.Hohe Prozesstreue beim Offshore-PartnerUm die eingangs erwähnte sehr hoheAnzahl an Details in den Griff zu bekommen, war es wichtig, alle Unstimmigkeitenund Abweichungen umgehend erfassen undadressieren zu können. Neben einer werkzeuggestützten Verwaltung dieser Detailswar die hohe Prozesstreue beim Partnerwichtig. Diese Prozesstreue stellte sich nichtper se ein, sondern wurde gezielt durchBeobachtungen und Rückmeldungen aufgebaut. Dazu gehörten besonders am Anfanghäufige Überprüfungen, inwieweit die definierten Arbeitsschritte auch eingehaltenwurden. Abweichungen wurden dannumgehend bei der nächsten regelmäßigenTelefonkonferenz besprochen. Währendanfangs alle Vorgaben kommentarlos vomOffshore-Team akzeptiert und umgesetztwurden, lernte dieses im Laufe der Zeit,auch Prozessverbesserungen vorzuschlagen.An dieser Stelle treffen zwei Kulturen aufeinander: Die indische ist stark hierarchieorientiert und dem Vorgesetzten wird ehernicht widersprochen, unsere Kultur dagegenerwartet von den Mitarbeitern eine kritischeund offene Haltung mit dem Zweck,Verbesserungen zu erzielen.Engpass bei den Fachexperten gemeistertEines der größten Projektrisiken bestanddarin, dass die Fachexperten nicht genügend Zeit für das Projekt hätten aufwendenkönnen. Da der Projekterfolg direkt vondieser Verfügbarkeit abhing, reichten wirdieses Risiko bereits früh an den Lenkungsausschuss weiter. Wir erhielten daraufhin gute Unterstützung vom Management bei der Ressourcenplanung.In einer weiteren Maßnahme reduziertenwir nach ersten Erfahrungen den Aufwandfür die Spezifikationen soweit wie möglich.Auf Abfragen ohne wesentlichen Informationsgehalt wurde verzichtet. Zusätzlichwurde die Spezifikationsvorlage stärkerformalisiert. Pseudocode oder mathematische Ausdrücke wurden gegenüber Prosaformulierungen bevorzugt. Die Fachexperten konnten dann mit der Delegationvon Routinetätigkeiten weiter entlastetwerden. Als dritten Punkt erkannten wirspäter, dass auch das Offshore-Team in derLage war, Testdaten selber zu erzeugen.Ein großer Vorteil war es, dass wir dieAbnahmetests für die Lieferungen auchdelegieren konnten. Anfangs gingen wirdavon aus, dass die Abnahme nur durch dieFachexperten erfolgen könnte und müsste.Da wir für jedes Offshore-Arbeitspaketaber Testfälle hatten, wurde dieser Test vonunserem indischen Kollegen im lokalenTeam durchgeführt. Die guten Erfahrungenbestätigten diesen Ansatz.Der Anteil der internen Projektmitarbeiter lag damit bei nur 19 %, alle anderenTätigkeiten wurden von externen Mitarbeitern wahrgenommen. Zühlke als inländischer Berater stellte davon 25 % und derOffshore-Partner 56 %. Das ist ein Vorteil,wenn die internen Mitarbeiter ein knappesGut darstellen und dringend für das eigeneProduktgeschäft benötigt werden. Abbildung 3 zeigt die prozentuale Verteilungzwischen externen und internen Mitarbeitern.Abb. 3: Prozentuale Verteilung der internen und externen Ressourcen.
fachartikelAbb. 4: Anzahl der Nachbearbeitungen je Arbeitspaket.Routineentwicklungen – bestensgeeignet fürs OffshoringIn dem Projekt gibt es viele Wiederholungen bei der Implementierung. So enthältdie Bauteilbibliothek 300 Elemente, damitliegen etwa 299 Wiederholungen vor. UnserAnsatz besteht darin, dass das lokale Teamzunächst eine stabile Referenzimplementierung erstellt und diese vor Ort verifiziert.Danach erfolgt der Wissenstransfer insOffshore-Team; die nachfolgenden Entwicklungen werden dann vom OffshoreTeam unter Einhaltung der nun gegebenenLeitplanken getätigt.Dies ist ein Ansatz zur Minimierung derOffshore-Entwicklungsrisiken. Das lokaleTeam übernimmt die Verantwortung fürdie Architektur und damit für eine flexibleund wieder verwendbare Lösung. DasOffshore-Team übernimmt die Verantwortung, die routinemäßige Entwicklung mitguter Qualität durchzuführen.Die Aufgabenteilung zwischen dem lokalen und dem Offshore-Team hat in demProjekt gut funktioniert. Positiv überraschtwaren wir von der Disziplin der indischenMitarbeiter, insbesondere von ihrer Geduldbei der Überprüfung der vielen Verifikationspunkte.Nur wenig NachbearbeitungenEin wichtiges Ziel bei der Offshore-Zusammenarbeit bestand darin, die Anzahlder Nachbearbeitungen minimal zu halten.Eine hohe Anzahl war eine unsererBefürchtungen zu Beginn des Projekts, diesich jedoch nicht eingestellt hat. EineNachbearbeitung wird notwendig, falls die5455Lieferung des Partners als unvollständigoder fehlerhaft erkannt wird. Jede Nachbearbeitung muss dabei wieder formal inAuftrag gegeben werden und alle Prozessschritte sind noch einmal zu durchlaufen.Abbildung 4 zeigt die Anzahl der notwendigen Nachbearbeitungen über die einzelnen Arbeitspakete. Die ersten vier Paketeverlangten mindestens eine Nachbearbeitung, danach wurden nur vereinzeltebenötigt. Die vielen Nachbearbeitungen amAnfang der Zusammenarbeit sind inOrdnung, da dies zur Lernphase gehörte.KundennutzenDer Kunde konnte in diesem Projekt an denfolgenden Stellen profitieren.Gute Qualität Dank intensiven TestensDie Offshore-Zusammenarbeit hat es unsermöglicht, die vielen und notwendigenTests in Auftrag geben zu können. InterneMitarbeiter hätten aus Zeitgründen sichernur einen Bruchteil dieser Tests selberdurchführen können.Wiederverwendung der Softwarelösungenin zukünftigen ProjektenDie Anforderung, eine erweiterbare undportierbare Architektur zu entwerfen, wurde von den Architekten erreicht. DieLösungen können für andere Aufgabenstellungen wiederverwendet werden. Heutewerden zweidimensionale Zeichnungenerstellt, die Architektur erlaubt es aberauch, zum Beispiel dreidimensionale Modelle zu generieren. Dies ist eine zukünftigeHerausforderung für den Kunden.Offshore-Prozess als Prototyp füreinen firmenweiten StandardprozessDie Zusammenarbeit mit dem OffshorePartner funktionierte in diesem Projekt reibungslos, die Qualität der Ergebnisse istgut. Das in dem Projekt entwickelte Prozessmodell hat sich bewährt. Es kann somitfür zukünftige Projekte übernommen werden und sich zu einem firmenweitenStandard entwickeln.Gute Unterstützung der OffshoreStrategie des UnternehmensEine der Projektvorgaben bestand darin,Offshore-Ressourcen wo immer möglicheinzusetzen. Das Unternehmen möchte denUmfang der Offshore-Kooperation mitdem Vertragspartner weiter steigern undprofitabel betreiben. Mit einem Anteil von56 % an Offshore-Mitarbeitern im Projektund den guten Ergebnissen wurde dieseVorgabe sicher erfüllt und hat zum übergeordneten Unternehmensziel beigetragen.Ausbau der Fähigkeiten der FachexpertenIm Projektverlauf wurde die Bedeutungeiner guten Spezifikation immer klarer.Gute Spezifikationen zahlen sich darin aus,dass es weniger Bedarf an Abklärungengibt, und entlasten so das lokale Teamerheblich. Es gibt weniger Missverständnisse und damit weniger Nachbearbeitungen. Die Fachexperten haben Erfahrungenin diesem Bereich sammeln können undihre Fähigkeiten gut ausgebaut. Das ist einegute Voraussetzung für weitere OffshoreProjekte. Die Lerneffekte ergaben sich einerseits durch das Schreiben selber und
fachartikeldurch die wiederkehrenden, intensivenReviews der Spezifikationen.FazitIn dem hier beschriebenen verteilten Offshore-Entwicklungsprojekt trugen vorallem drei Faktoren zum Gelingen bei: An erster Stelle ist die Bereitstellungeiner guten Spezifikation inklusive derTestfälle zu nennen. Die Aufrechterhaltung eines kontinuierlichen Kommunikationsflusses zwischen dem lokalen und dem OffshoreTeam war der zweite Erfolgsfaktor.Dazu gehörten die ständige Präsenzeines indischen Mitarbeiters vor Ortsowie regelmäßige Telefonkonferenzen. Der dritte Erfolgsfaktor ist aus unsererSicht die Einführung eines geeignetenund disziplinierten Offshore-Prozesses.3/2008Das Projekt zeichnete sich durch seine vielenWiederholungen bei der Entwicklung derKomponenten aus. Der gewählte OffshoreAnsatz für die Zusammenarbeit undAufgabenteilung hat sich in der Praxisbewährt. Es ist ein Vorgehen mit minimalenOffshore-Entwicklungsrisiken und damitauch geeignet für Organisationen, die erstnoch im Aufbau einer Offshore-Kooperationsind. Unser Offshore-Ansatz sieht vor, dieVerantwortung für die Prozesse, für dieArchitektur und für die Teststrategie beimlokalen Team zu belassen. Wahrgenommenwerden diese Funktionen durch Schlüsselrollen, die über die entsprechendeErfahrungen auf diesen Gebieten verfügen.Das lokale Team entwickelt prototypisch fürjeden Wiederholungstyp eine Referenzimplementierung und verifiziert den Ansatz. Nachdem Wissenstransfer erfolgt die Entwicklungaller weiteren Komponenten von diesem Typdurch das Offshore-Team.Nach Ansicht des Autors ist dies ein ausgleichender Offshore-Ansatz, der alle dreiSeiten – Kunde, inländische Mitarbeiterund Offshore-Mitarbeiter – integrierendberücksichtigt: Der Kunde konnte dasProjekt mit nur einer kleinen, internenMannschaft steuern und führen. Durch denMix aus inländischen Beratern undOffshore-Mitarbeitern konnte er seineOffshore-Strategie umsetzen. Für die inländischen Mitarbeiter ist die Zusammenarbeit eine Bereicherung, da sie neueErfahrungen in der internationalen Zusammenarbeit und der Teamarbeit sammelnkonnten. Arbeitsplatzängste sollten bei dieser Art Aufgabenteilung relativiert werden.Und schließlich war das indische Team inein interessantes und innovatives Projekteingebunden, einige Offshore-Mitarbeiterkonnten darüber hinaus Erfahrungen aneinem westlichen Standort sammeln.
Implementierung und Test - auf Basis der Referenzimplementierung Offshore Systemtest Offshore Deployment Lokal Konfigurations- und Änderungsmanagement Lokal Projektmanagement Lokal Offshore Environment Lokal Abb. 2: Der Offshore-Arbeitsablauf in einer groben Übersicht. Tabelle 1: A
services necessary to construct and maintain the Arctic/Offshore Patrol Ships (AOPS), Joint Support Ships (JSS), Polar Icebreaker, and Offshore Fisheries/ Offshore Oceanographic Science . National Shipbuilding Procurement Strategy OFSV Offshore Fisheries Science Vessel OOSV Offshore Oceanographic Science Vessel . Recent Ice-Classed Offshore .
Offshore wind farm status GW 10.4 7.7 2.6 2.3 1.7 0.3 25.0 % 42% 31% 10% 9% 7% 1% 100% UK Germany Netherlands Belgium Denmark Rest of Europe Total Turbines 2,292 1,501 537 399 559 112 5,400 Triton Knoll west offshore substation and jackup vessel Neptune 04 Offshore wind operational report 2020 05 Offshore wind operational report 2020 Offshore .
Andreas Wagner, CEO Berlin Office Schiffbauerdamm 19, D-10117 Berlin Phone: 49-30-27595-141 Fax: 49-30-27595142 berlin@offshore-stiftung.de Varel Office Oldenburger Str. 65, D-26316 Varel Phone: 49-4451-9515-161 Fax: 49-4451-9515-249 varel@offshore-stiftung.de www.offshore-stiftung.de More news & information (German/English) 16 Backup Slides German Offshore Windfarms under Construction 2 .
In the year 2000, DNV published first offshore standard (OS) DNV-OS-F101 for the design of the offshore pipeline systems with limit states or load and resis-tance factor design (LRFD). This offshore standard has been continuously updated based on various joint industry projects and many offshore installations (DNV, 2000, 2005, 2007, 2010).
Offshore Wind Farm Worker Safety, author. Worker health and safety on offshore wind farms / Committee on Offshore Wind Farm Worker Safety. pages cm — (Transportation research board special report ; 310) ISBN 978-0-309-26326-9 1. Offshore wind power plants—Employees—Health and hygiene—United States. 2.
Maryland Offshore Wind Energy Act of 2013 Created a "carve-out" for offshore wind within Maryland's Renewable Portfolio Standard (RPS) that is equal to 2.5 percent of all electricity sales within Maryland. Created a financial support mechanism for "Qualified Offshore Wind Projects" via Offshore Wind Renewable Energy Credits (ORECs).
An Offshore Wind Energy Roadmap3; Wind Farm Site Decisions and permits issued under the Offshore Wind Energy Act; If necessary, subsidies under the Stimulation of Sustainable Energy Production Decision; and A Development Framework for the development of offshore wind energy, and that of the offshore grid in particular.
Agile Software Development with Scrum An Iterative, Empirical and Incremental Framework for Completing Complex Projects (Slides by Prof. Dr. Matthias Hölzl, based on material from Dr. Philip Mayer with input from Dr. Andreas Schroeder and Dr. Annabelle Klarl) CHAOS Report 2009 Completion of projects: 32% success 44% challenged 24% impaired Some of the reasons for failure: Incomplete .
