Über unsMediaKontaktImpressum
Boris Gloger 21. Februar 2017

Die Umfeldbedingungen des Skalierens

In diesem Spiel kann nur mitmischen, wer seine Methoden den Umständen anpasst. © vencav / Fotolia.com
© vencav / Fotolia.com

"Funktioniert Scrum auch mit großen Projekten?", fragen mich die Teilnehmerinnen und Teilnehmer in Seminaren, unsere Kunden und so gut wie jeder Manager, den ich treffe. Sie alle wollen ihre großen, aus dem Ruder gelaufenen Projekte retten. Immer wieder muss ich dabei an den Chaos Report der Standish Group denken Interner Link[1]: Mehr als 50 Prozent aller großen Projekte liefern nicht die geforderten Ergebnisse. Die Diagnose ist eindeutig: Je größer ein Projekt ist, desto wahrscheinlicher wird es – gemessen an den ursprünglichen Vorgaben – scheitern. Übrig bleibt das Fazit: Obwohl alle Beteiligten bestens im Projektmanagement ausgebildet sind, obwohl versucht wird, am Beginn eines Projekts an möglichst viel zu denken, steckt das traditionelle Management großer Projekte in einer Sackgasse.

Doch es gibt einen Ausweg: Wie gelingen große Projekte in der Soft- und Hardwareentwicklung? Als großes Projekt bezeichne ich eines, das folgende Bedingungen erfüllt: Ein Budget von mehr als einer Million Euro, eine Dauer von mehr als sechs Monaten und mehr als sechs durchführende Beteiligte, die auch an verschiedenen Orten angesiedelt sein können. Wie solche Projekte gemanagt werden können, ist eine brennende Frage, denn es ist noch immer die größte Herausforderung für die meisten Unternehmen.

Großkonzerne und der deutsche Mittelstand führen Projekte in gigantischen Ausmaßen durch – zehn Millionen Euro sind schnell ausgegeben und Dutzende Personen leisten ihren Beitrag. Aber da gibt es noch einige Besonderheiten: Diese Projekte werden im Rahmen des normalen Tagesgeschäfts durchgeführt, sie stören den normalen Ablauf. Arbeiten mehrere Standorte am Projekt mit, ist die Projektsprache Englisch. Und als wäre das allein nicht schwierig genug, sind diese Unternehmen noch dazu in einem gigantischen Beschleunigungsrennen gefangen. "Digitalisierung" lautet das Stichwort, täglich entstehen neue Technologien. Neue Optionen, neue Geschäftsfelder entwickeln sich über Nacht. Unternehmen, die auf dem internationalen Parkett weiter bestehen wollen, müssen damit umgehen können. Fehlentscheidungen und Selbstzufriedenheit führen schnell zum Desaster.

Mit der Flut an Möglichkeiten, die neue Technologien mit sich bringen, rast eine Welle von Gesetzesänderungen auf die Unternehmen zu. Kontinuierlich müssen sie ihre Prozesse und damit ihre IT-Infrastruktur anpassen, und natürlich müssen auch Projekte neu bewertet und ihr Kurs unter Umständen korrigiert werden. Vieles bleibt lange im Ungewissen, denn manchmal wissen nicht einmal die Behörden selbst, wie eine neue Vorschrift aussehen soll.
Man weiß, dass sie kommen wird, aber nicht, wann genau und in welcher Form. Werden die entwickelten Lösungen die richtigen sein?

In diesem Spiel kann nur mitmischen, wer seine Methoden den Umständen anpasst. Traditionelles Projektmanagement muss zwangsläufig scheitern, denn dessen Spielwiese wurde für einen anderen Kontext und andere Zeithorizonte entwickelt. Es leistete gute Dienste, viele Unternehmen haben gute Erfahrungen damit gemacht. Aber immer wieder ist zu beobachten, dass extrem kritische Projekte außerhalb der traditionellen Unternehmensstrukturen durchgeführt werden. Die Labs und Taskforces sind anderen Bedingungen unterworfen: Dort dürfen die Kollegen alles anders machen und werden nur daran gemessen, ob sie eine Lösung finden. Klassische Unternehmensprozesse werden ignoriert oder so geschickt ausgenutzt, dass sonst Undenkbares plötzlich möglich wird.
Die Softwareentwicklung war der erste Bereich, in dem in den 1990er-Jahren sichtbar wurde: Der traditionelle Weg der Projektdurchführung funktioniert nicht mehr. Also machten sich einige Manager auf den Weg, suchten eine Lösung für die beschriebenen Probleme und fanden die agile Softwareentwicklung. Von den unterschiedlichen Modellen setzte sich weltweit eine Vorgehensweise durch: Scrum. Dieses Managementframework wurde entwickelt, um in einem komplexen Umfeld möglichst schnell etwas liefern zu können, von dem man oft nicht weiß, wie es aussehen soll und erreicht werden kann. Zunächst ging man davon aus, dass man gut ausgebildete Softwarespezialisten zusammenbringen müsse, um aus ihnen ein Team mit einer klar definierten Aufgabe zu formen. Das funktionierte sehr gut. Heute arbeiten viele Unternehmen in ihren IT-Abteilungen erfolgreich mit diesen kleinen, sich selbst organisierenden Teams.

Scrum-Projekte wurden bald so erfolgreich, dass immer mehr Hardwareentwicklungsteams auf diese Arbeitsweise aufmerksam wurden. Die Softwareentwickler lieferten ihre Produkte immer schneller ab, nutzten andere Formen des Reportings und wirkten alles in allem zufriedener mit ihrer Arbeit. So hielt Scrum auch Einzug in das traditionelle Projektmanagement für Hardwareprodukte. Und die Verbreitung von Scrum ist noch nicht abgeschlossen: Inzwischen gibt es selbst verwaltungsnahe agile Teams, zum Beispiel in der Rechtsabteilung der Holtzbrinck Publishing Group Interner Link[2].

Geht das auch groß?

Ein kleines, sich selbst überlassenes Team kann bei einer klar umrissenen Aufgabe alle paar Wochen etwas vorzeigen. Das kann man sich vorstellen und das ist auch mit klassischem Projektmanagement erfolgreich möglich. Scrum-Projektteams wurden aber schnell mit der Frage konfrontiert, wie sie denn große Projekte stemmen würden, denn genau das ist die Herausforderung.

Ich habe mich selbst lange immer wieder dagegen gesträubt, diese Frage zu beantworten. Meine Sicht der Dinge war einfach: Kleine Scrum-Teams aus gut ausgebildeten Mitarbeitern sind um einiges effektiver als große behäbige Projektteams. Also, weshalb sollte es den Bedarf geben, Projekte möglichst groß aufzuziehen? Die Antwort lag doch auf der Hand: Man musste einfach die Projektteams verkleinern. Ich hatte selbst gesehen, dass ein zehnköpfiges Team in kurzer Zeit Projekte ablieferte, an denen 150 Personen gescheitert waren. Alles sprach also dafür, dass man das große Projekt gar nicht brauchte.

Manche Menschen "verstehen" sich aufgrund ihrer Ausbildung nicht.

Mir wurde erst klar, dass ich mich mit dem Thema noch einmal ganz anders auseinandersetzen musste, als die Anfragen zu Scrum in der Hardwareentwicklung immer häufiger wurden. Plötzlich waren völlig andere Probleme zu lösen: In diesem Bereich arbeiten nicht zwangsläufig Menschen zusammen, die ähnlich denken. Manche "verstehen" sich aufgrund ihrer Ausbildung überhaupt nicht. Chemiker denken anders als Biologen, die wiederum ganz anders an Probleme herangehen als Elektroingenieure, die natürlich alles ganz anders machen als die Maschinenbauer. Dazu kommt, dass diese unterschiedlichen Disziplinen oft gar nicht an einem Standort angesiedelt sind. Die wunderbare Idee, alle Kollegen in einem Raum zu versammeln, ist oft gar nicht umsetzbar, denn die Spezialisten sind in der ganzen Welt verteilt und mitunter gehören sie nicht einmal zum eigenen Unternehmen. Aber das Internet lässt die Welt auch in diesem Punkt schrumpfen: Die besten Köpfe lassen sich leichter finden als je zuvor und sind oft kurzfristig buchbar. Ein befreundetes kleines Zwei-Mann-Unternehmen mit einem stark eingegrenzten Spezialgebiet arbeitet für einen kalifornischen Giganten. Die zwei nehmen Aufträge an, liefern die Ergebnisse ab und es scheint hervorragend zu funktionieren. Längst haben "New Brokers of Work" daraus ein Geschäft gemacht: Sie vermitteln Aufgaben an Spezialisten, finden diese in weltweiten Netzwerken oder bauen selbst diese Netzwerke auf. Das ist auch Teil des sich abzeichnenden Trends zur Hyperspezialisierung: Arbeiten in Projekten werden kleinteilig auf diejenigen verteilt, die sich am besten für die Aufgabe eignen Interner Link[3].

Wer genau hinsieht, macht eine erstaunliche Beobachtung: Wieder ist es die Softwareentwicklung, in der dieser Trend seinen Ausgang nimmt. Weltweit verteilte Softwareentwickler arbeiten gemeinsam an Projekten, obwohl sie sich oft noch nie persönlich gesehen haben und manchmal nicht einmal die Namen der anderen kennen. Unternehmen wie Automattic (Wordpress) oder 37signals (Basecamp) wurden bewusst so konzipiert. Sie wollen mit Menschen auf der ganzen Welt zusammenarbeiten, die das benötigte Wissen haben. Microsoft baut viele seiner neuen Produkte konsequent in die Cloud, damit Menschen in jedem Winkel der Erde daran arbeiten können, auch Adobe setzt auf das gleiche Prinzip.

Schwieriger Wandel im Projektmanagement

Obwohl heute alle vor den gleichen Problemen stehen wie seinerzeit die Softwareentwicklung, gehen viele Unternehmen nach wie vor den aus meiner Sicht traditionellen und damit ungeeigneten Weg:

  • Projekte werden aus der Taufe gehoben und erst dann wird überlegt, wer die Aufgaben am besten erledigen kann.
  • Man stellt Ressourcenmanager ein, die Projektmanager immer mit den richtigen Ressourcen versorgen sollen.

Doch leider zeigt die Realität: In Projekten werden immer wieder die gleichen Personen benötigt, die genau deswegen bereits in vielen Projekten gleichzeitig arbeiten. Die Gründe sind bekannt:

  1. Es werden zu viele Projekte zur selben Zeit durchgeführt und
  2. die Key Player im Unternehmen sind entscheidende Wissensträger. Bei ihnen, vielmehr "in" ihnen, konzentriert sich das Wissen und daher werden sie in mehr als einem Projekt gebraucht.

Intuitiv ist das allen Managern klar. Daher war der immer wieder entstehende Widerstand nachvollziehbar, wenn wir forderten, dass in einem Scrum-Projekt alle gemeinsam an einem Projekt/Produkt arbeiten sollten. Wie sollte das gehen? Denn gelebte Realität war und ist in vielen Organisationen, dass ein Kollege immer in mehr als einem Projekt arbeiten muss.

Kleine Erfolge waren dennoch möglich. Bei ganz großen Projekten brachte ich das Management oft dazu, alle Projektbeteiligten zusammenzurufen. Das eine oder andere Mal führten wir Sprint Plannings mit 180 Personen in Ballsälen durch oder wir konnten Entwickler, die auf einem Stockwerk verteilt saßen, durch geeignete Maßnahmen zu einer besseren Zusammenarbeit motivieren. Das waren Ausnahmen, die zwar bewiesen, dass viele meiner Ideen korrekt waren und vor allem schlingernde Projekte konnten wir so wieder auf Kurs bringen. In der Masse waren diese Projekte aber nur ein Tropfen auf den heißen Stein. Sie funktionierten und brachten großartige Erfolge, aber die Herangehensweise war für die meisten Unternehmen nicht wiederholbar. Für dieses eine Projekt war die Kraftanstrengung möglich, die ich forderte, in letzter Konsequenz hätte es aber eine Änderung der Organisation bedeutet. Viele Unternehmen verstehen das erst, nachdem sie die Erfolge von Scrum-Projekten gesehen haben.

Und doch geschieht es: Die großen Tanker ändern ihren Kurs. Die vielen kleinen erfolgreichen Scrum-Implementierungen am Rande der Organisationen haben den Verantwortlichen gezeigt, dass sich grundsätzlich etwas ändern muss, wenn ein Unternehmen erfolgreich bleiben soll. Sie stellen erste Überlegungen dazu an, wie die Struktur der gesamten Organisation umgestaltet werden muss Interner Link[4].

Änderungen der Organisation können gelingen und machen das Projektleben leichter, doch das ist heute noch nicht die Regel. Die meisten großen Projekte werden in nichtagilen Umgebungen durchgeführt. Ist damit die Chance auf ein agiles Projekt verspielt? Nein, es ist möglich, agile Projekte in einem nichtagilen Umfeld über die Ziellinie zu bringen. Dazu muss Zusammenarbeit neu definiert werden und es bedeutet, bisher bewährte, aber nun veraltete Paradigmen allmählich aufzugeben.

Ein erster Überblick

Dem großen Projekt müssen wir uns also noch einmal anders nähern. Nicht mit den naiven Ideen der Scrum-Evangelisten, zu denen auch ich gehört habe, sondern mit dem gesamten agilen Erfahrungsschatz der letzten 15 Jahre. Beim Skalieren eines großen Projekts geht es in Wahrheit immer um die Entwicklung von etwas Bleibendem. Das kann ein neuer Prozess, ein neues Gebäude, ein neues Software- oder Hardwareprodukt sein. Jedes Mal wird am Ende ein Resultat erwartet. Es reicht also nicht aus, sich lediglich mit dem Scrum-Prozess zu beschäftigen. Wir müssen ein größeres Bild zeichnen und uns mit den folgenden Themen auseinandersetzen:

  • Wissensmanagement. Ikujiro Nonaka und Hirotaka Takeuchi sowie Peter Drucker haben für das Verständnis der Wissensarbeit Großartiges geleistet. Ihre Forschung und ihre Überlegungen machten deutlich, warum gerade die Softwareentwicklung neue Impulse setzen konnte und musste.
  • Softwarearchitektur. Ausgehend vom Silicon Valley verbreitet sich das Denken in Netzwerken und kleinen Einheiten, und das begründet wiederum ein neues Verständnis für die Zusammenarbeit von Menschen.
  • Lean Management, Lean Production und Second Generation Lean Product Development. Wer große Projekte agil umsetzen will, kommt nicht umhin, sich ausführlich mit dem Toyota Production System, der Theory of Constraints und den Arbeiten von Don Reinertsen zu beschäftigen. Auf Grundlage dieser Ideen wird deutlich, warum der Wertstrom und nicht der Plan die relevante Kenngröße für das Steuern eines Projekts ist.
  • Design Thinking. Die Revolution der Produktentwicklung hat in den 1980er-Jahren in Kalifornien begonnen. Die Designagentur IDEO entwickelte damals ein Vorgehensmodell, das tatsächlich die Anwender (User) in den Mittelpunkt aller Überlegungen stellt. IDEO verabschiedete sich von dem Konzept, dass eine Person die Produktidee haben muss und die Umsetzung daher vorgibt. Design beschreibt in diesem Sinne nicht das Erscheinungsbild eines Produkts, sondern das Verständnis, wie ein Anwender ein Produkt in seinem Lebenskontext nutzt.
  • Führung. In großen Projekten sind die beteiligten Menschen oft überall auf der Erde verstreut und man bekommt sie so gut wie nie zu Gesicht. Die Frage, wie man Menschen führen soll, bekommt hier eine völlig neue Dimension. Klare Kommunikation und ausschließlich intrinsische Faktoren geben den Ausschlag.
  • Organisation. Wie verändert sich die Organisation rund um ein großes agiles Projekt? Natürlich kann nicht gleich ein ganzes Unternehmen plötzlich agil werden und trotzdem greifen solche Projekte die Abteilungssilos an.

Fazit

Mit agilem Projektmanagement für das große Projekt kann man sich nur befassen, wenn man die folgenden sechs Bausteine anders als bisher versteht:

  • Produktarchitektur
  • Infrastruktur
  • Professionalität
  • Produktentwicklungsprozesse
  • Managementprozesse
  • Den Begriff des Projekts

Es gibt nicht für jedes Unternehmen den einen Weg zur erfolgreichen Implementierung und Skalierung von Scrum. Wichtig ist es aber vor allem, dass die einzelnen Teilaspekte ineinander greifen. Projektmanager bekommen durch agile Methoden völlig neue Mittel an die Hand, um Projekte umzusetzen. Mittels der passenden Infrastruktur, den Skills der Mitarbeiter und der nötigen Informationsarchitektur steht dem erfolgreichen Skalieren von Scrum innerhalb eines Unternehmens nichts mehr im Wege.

Dieser Artikel ist ein Auszug aus Boris Gloger's Buch "Scrum Think big: Scrum für wirklich große Projekte, viele Teams und viele Kulturen".

Quellen
  1. Hastie, S.; Wojewoda, S.: Externer LinkStandish Group 2015 Chaos Report – Q&A with Jennifer Lynch.
  2. Gloger, B.: Externer LinkDie agilen Anwälte. Case Study 2015.
  3. Malone, T. W.; Laubacher, R.; Johns, T.: Externer LinkThe Big Idea. The Age of Hyperspecialisation. In: Harvard Business Review, 89 (2011) 7/8, S. 56 – 65.
  4. Gloger, B.; Margetich, J.: Das Scrum-Prinzip. Agile Organisationen aufbauen und gestalten. Schäffer-Poeschel 2014
nach Oben
Autor

Boris Gloger

Boris Gloger gilt als einer der progressivsten Vordenker im Bereich Management und Organisation. Mit seiner Managementberatung Boris Gloger Consulting hat er sich auf das Framework Scrum spezialisiert. Er ist zudem Autor...
>> Weiterlesen
Bücher des Autors:

YTo2OntzOjY6ImZldXNlciI7aTowO3M6MzoicGlkIjtpOjMxMTM7czozOiJjaWQiO3M6NToiMjAxNTQiO3M6NDoiY29uZiI7YTo4OntzOjEwOiJzdG9yYWdlUGlkIjtpOjgyMjtzOjEzOiJVc2VySW1hZ2VTaXplIjtpOjE4O3M6OToiYWR2YW5jZWQuIjthOjI6e3M6MTA6ImRhdGVGb3JtYXQiO3M6OToiZC1tLXkgSDppIjtzOjIxOiJzaG93Q291bnRDb21tZW50Vmlld3MiO2k6MDt9czo4OiJzaGFyaW5nLiI7YToxOntzOjEyOiJ1c2VTaGFyZUljb24iO047fXM6ODoicmF0aW5ncy4iO2E6Mjp7czoxNjoicmF0aW5nSW1hZ2VXaWR0aCI7aToxMTtzOjE2OiJyZXZpZXdJbWFnZVdpZHRoIjtpOjE2O31zOjY6InRoZW1lLiI7YToxMjp7czoyNjoiYm94bW9kZWxUZXh0YXJlYUxpbmVIZWlnaHQiO2k6MjA7czoyNDoiYm94bW9kZWxUZXh0YXJlYU5ickxpbmVzIjtpOjE7czoxNToiYm94bW9kZWxTcGFjaW5nIjtpOjQ7czoxODoiYm94bW9kZWxMaW5lSGVpZ2h0IjtpOjI1O3M6MTg6ImJveG1vZGVsTGFiZWxXaWR0aCI7aToxMzQ7czoyNjoiYm94bW9kZWxMYWJlbElucHV0UHJlc2VydmUiO2k6MDtzOjIyOiJib3htb2RlbElucHV0RmllbGRTaXplIjtpOjM1O3M6MTc6InNoYXJlYm9yZGVyQ29sb3IyIjtzOjY6ImNkZGVlYyI7czoxNzoic2hhcmVib3JkZXJDb2xvcjEiO3M6NjoiYWRhZWFmIjtzOjExOiJib3JkZXJDb2xvciI7czo2OiJkOGQ4ZDgiO3M6MjE6InNoYXJlQ291bnRib3JkZXJDb2xvciI7czo2OiJlM2UzZTMiO3M6MjA6InNoYXJlQmFja2dyb3VuZENvbG9yIjtzOjY6ImZmZmZmZiI7fXM6MTQ6ImRhdGVGb3JtYXRNb2RlIjtzOjQ6ImRhdGUiO3M6MTI6IlJlcXVpcmVkTWFyayI7czoxOiIqIjt9czo0OiJsYW5nIjtzOjI6ImRlIjtzOjM6InJlZiI7czoxNjoidHRfY29udGVudF8yMDE1NCI7fQ%3D%3DYTo0OntzOjQ6ImNvbmYiO2E6MzM6e3M6MTc6InVzZVdlYnBhZ2VQcmV2aWV3IjtzOjE6IjAiO3M6MjI6InVzZVdlYnBhZ2VWaWRlb1ByZXZpZXciO3M6MToiMCI7czoyMDoid2VicGFnZVByZXZpZXdIZWlnaHQiO3M6MjoiNzAiO3M6MjA6Im1heENoYXJzUHJldmlld1RpdGxlIjtzOjI6IjcwIjtzOjMxOiJ3ZWJwYWdlUHJldmlld0Rlc2NyaXB0aW9uTGVuZ3RoIjtzOjM6IjE2MCI7czozODoid2VicGFnZVByZXZpZXdEZXNjcmlwdGlvbk1pbmltYWxMZW5ndGgiO3M6MjoiNjAiO3M6Mjc6IndlYnBhZ2VQcmV2aWV3Q2FjaGVUaW1lUGFnZSI7czozOiIxODAiO3M6MzM6IndlYnBhZ2VQcmV2aWV3Q2FjaGVUaW1lVGVtcEltYWdlcyI7czoyOiI2MCI7czozMDoid2VicGFnZVByZXZpZXdDYWNoZUNsZWFyTWFudWFsIjtzOjE6IjAiO3M6Mjg6IndlYnBhZ2VQcmV2aWV3TnVtYmVyT2ZJbWFnZXMiO3M6MjoiMTAiO3M6Mzg6IndlYnBhZ2VQcmV2aWV3U2Nhbk1pbmltYWxJbWFnZUZpbGVTaXplIjtzOjQ6IjE1MDAiO3M6MzA6IndlYnBhZ2VQcmV2aWV3U2Nhbk1pbkltYWdlU2l6ZSI7czoyOiI0MCI7czozMDoid2VicGFnZVByZXZpZXdTY2FuTWF4SW1hZ2VTaXplIjtzOjM6IjQ1MCI7czoyOToid2VicGFnZVByZXZpZXdTY2FuTWluTG9nb1NpemUiO3M6MjoiMzAiO3M6MzE6IndlYnBhZ2VQcmV2aWV3U2Nhbk1heEltYWdlU2NhbnMiO3M6MjoiNDAiO3M6Mzg6IndlYnBhZ2VQcmV2aWV3U2Nhbk1heEltYWdlU2NhbnNGb3JMb2dvIjtzOjI6IjU1IjtzOjQwOiJ3ZWJwYWdlUHJldmlld1NjYW5NYXhIb3J6aXpvbnRhbFJlbGF0aW9uIjtzOjE6IjUiO3M6Mzc6IndlYnBhZ2VQcmV2aWV3U2Nhbm1heHZlcnRpY2FscmVsYXRpb24iO3M6MToiMyI7czozMDoid2VicGFnZVByZXZpZXdTY2FuTG9nb1BhdHRlcm5zIjtzOjEwOiJsb2dvLGNyZ2h0IjtzOjM4OiJ3ZWJwYWdlUHJldmlld1NjYW5FeGNsdWRlSW1hZ2VQYXR0ZXJucyI7czo1NzoicGl4ZWx0cmFucyxzcGFjZXIseW91dHViZSxyY2xvZ29zLHdoaXRlLHRyYW5zcGEsYmdfdGVhc2VyIjtzOjM4OiJ3ZWJwYWdlUHJldmlld0Rlc2NyaXB0aW9uUG9ydGlvbkxlbmd0aCI7czoyOiI0MCI7czoyNToid2VicGFnZVByZXZpZXdDdXJsVGltZW91dCI7czo0OiI3MDAwIjtzOjEyOiJ1c2VQaWNVcGxvYWQiO3M6MToiMCI7czoxMjoidXNlUGRmVXBsb2FkIjtzOjE6IjAiO3M6MTM6InBpY1VwbG9hZERpbXMiO3M6MzoiMTAwIjtzOjE2OiJwaWNVcGxvYWRNYXhEaW1YIjtzOjM6IjgwMCI7czoxNjoicGljVXBsb2FkTWF4RGltWSI7czozOiI5MDAiO3M6MjI6InBpY1VwbG9hZE1heERpbVdlYnBhZ2UiO3M6MzoiNDcwIjtzOjIzOiJwaWNVcGxvYWRNYXhEaW1ZV2VicGFnZSI7czozOiIzMDAiO3M6MjA6InBpY1VwbG9hZE1heGZpbGVzaXplIjtzOjQ6IjI1MDAiO3M6MjA6InBkZlVwbG9hZE1heGZpbGVzaXplIjtzOjQ6IjMwMDAiO3M6MjA6InVzZVRvcFdlYnBhZ2VQcmV2aWV3IjtzOjA6IiI7czoyNDoidG9wV2VicGFnZVByZXZpZXdQaWN0dXJlIjtpOjA7fXM6MTE6ImF3YWl0Z29vZ2xlIjtzOjI4OiJXYXJ0ZSBhdWYgQW50d29ydCB2b24gR29vZ2xlIjtzOjg6InR4dGltYWdlIjtzOjEzOiJCaWxkIGdlZnVuZGVuIjtzOjk6InR4dGltYWdlcyI7czoxNToiQmlsZGVyIGdlZnVuZGVuIjt9YTowOnt9YTowOnt9YTo3OntzOjE2OiJjb21tZW50TGlzdEluZGV4IjthOjE6e3M6MTk6ImNpZHR0X2NvbnRlbnRfMjAxNTQiO2E6MTp7czoxMDoic3RhcnRJbmRleCI7aTo1O319czoxNDoiY29tbWVudHNQYWdlSWQiO2k6MzExMztzOjE2OiJjb21tZW50TGlzdENvdW50IjtzOjU6IjIwMTU0IjtzOjEyOiJhY3RpdmVsYW5naWQiO2k6MDtzOjE3OiJjb21tZW50TGlzdFJlY29yZCI7czoxNjoidHRfY29udGVudF8yMDE1NCI7czoxMjoiZmluZGFuY2hvcm9rIjtzOjE6IjAiO3M6MTI6Im5ld2NvbW1lbnRpZCI7Tjt9 YTo1OntzOjExOiJleHRlcm5hbFVpZCI7aTozMTEzO3M6MTI6InNob3dVaWRQYXJhbSI7czowOiIiO3M6MTY6ImZvcmVpZ25UYWJsZU5hbWUiO3M6NToicGFnZXMiO3M6NToid2hlcmUiO3M6MTYzOiJhcHByb3ZlZD0xIEFORCBwaWQ9ODIyIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuZGVsZXRlZD0wIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuaGlkZGVuPTAgQU5EIChleHRlcm5hbF9yZWZfdWlkPSJ0dF9jb250ZW50XzIwMTU0IikgQU5EIHBhcmVudHVpZD0wIjtzOjEwOiJ3aGVyZV9kcGNrIjtzOjkwOiJwaWQ9ODIyIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuZGVsZXRlZD0wIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuaGlkZGVuPTAiO30%3D YToyOntpOjA7czoxNDk6IjxpbWcgc3JjPSIvdHlwbzNjb25mL2V4dC90b2N0b2NfY29tbWVudHMvcmVzL2Nzcy90aGVtZXMvdGlzcXVzL2ltZy9wcm9maWxlLnBuZyIgY2xhc3M9InR4LXRjLXVzZXJwaWMgdHgtdGMtdWltZ3NpemUiIHRpdGxlPSIiICBpZD0idHgtdGMtY3RzLWltZy0iIC8%2BIjtpOjk5OTk5O3M6MTUxOiI8aW1nIHNyYz0iL3R5cG8zY29uZi9leHQvdG9jdG9jX2NvbW1lbnRzL3Jlcy9jc3MvdGhlbWVzL3Rpc3F1cy9pbWcvcHJvZmlsZWYucG5nIiBjbGFzcz0idHgtdGMtdXNlcnBpY2YgdHgtdGMtdWltZ3NpemUiIHRpdGxlPSIiICBpZD0idHgtdGMtY3RzLWltZy0iIC8%2BIjt9
Bitte bestätigen Sie
Nein
Ja
Information
Ok

Noch keine Kommentare vorhanden

Ihr Kommentar ist eine Antwort auf den folgenden Kommentar
Vorschau wird geladen ...
*: Pflichtfeld