<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Ideen/Konzepte Archive - Jens Spaniel IT-Strategie und Projektcoaching</title>
	<atom:link href="https://www.strategieskipper.de/category/ideenkonzepte/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.strategieskipper.de/category/ideenkonzepte/</link>
	<description>Der Strategieskipper.</description>
	<lastBuildDate>Thu, 25 Jan 2024 17:34:50 +0000</lastBuildDate>
	<language>de</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.1</generator>

<image>
	<url>https://www.strategieskipper.de/wp-content/uploads/2017/11/cropped-Logo-32x32.jpg</url>
	<title>Ideen/Konzepte Archive - Jens Spaniel IT-Strategie und Projektcoaching</title>
	<link>https://www.strategieskipper.de/category/ideenkonzepte/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>DSGVO im Alltag der Architekten und Entwickler von Software</title>
		<link>https://www.strategieskipper.de/dsgvo-im-alltag/</link>
		
		<dc:creator><![CDATA[Jens Spaniel]]></dc:creator>
		<pubDate>Mon, 07 Oct 2019 09:28:30 +0000</pubDate>
				<category><![CDATA[Allgemein]]></category>
		<category><![CDATA[Ideen/Konzepte]]></category>
		<category><![CDATA[Meinungen]]></category>
		<category><![CDATA[DSGVO GDPR Datenschutz Softwareentwicklung Softwarearchitektur]]></category>
		<guid isPermaLink="false">https://www.strategieskipper.de/?p=5835</guid>

					<description><![CDATA[<p>Der Beitrag <a href="https://www.strategieskipper.de/dsgvo-im-alltag/">DSGVO im Alltag der Architekten und Entwickler von Software</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></description>
										<content:encoded><![CDATA[<div class="et_pb_section et_pb_section_0 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_0">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_0  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_0  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><h2>DSGVO im Alltag der Architekten und Entwickler von Software</h2>
<p><span style="font-size: 14px;">Die DSGVO hat die Herangehensweise in Softwareprojekten grundlegend verändert – sollte man zumindest meinen, nachdem man sich einen ersten Überblick über die Vorgaben verschafft hat. Vor allem die Cookie-Meldungen auf Webseiten erinnern uns ständig daran, dass Unternehmen und Behörden an ihren IT-Lösungen gearbeitet haben. Doch der Geist der DSGVO wollte mehr erreichen: ein grundsätzliches Bewusstsein um den Umgang mit personenbezogenen Daten. Und das sollte sich auf (fast) jedes Softwareprojekt auswirken.</span></p>
<p>Aber hat es das auch? Sind die Grundsätze bei Softwarearchitekten, Datenanalysten und Softwareentwicklern angekommen? Ist es bereits zu einer Gewohnheit geworden, Verfahrensverzeichnisse zu pflegen und die Lebensdauer eines Datensatzes zu definieren, der personenbezogene Informationen enthält?</p>
<p>Dieser Artikel richtet sich an alle Experten, die Software erstellen, pflegen und betreiben. Darüber hinaus versuche ich den Artikel auch für Nicht-ITler verständlich zu halten, denn gerade auch die Kollegen aus dem Marketing oder aus HR/Personal stellen an die IT regelmäßig Anforderungen, die die Verwendung von personenbezogenen Daten einschließen. Der Artikel soll helfen, sich und das eigene Team zu sensibilisieren und den Geist der Verordnung zu verstehen. So ist es möglich, die Verordnung in der täglichen Arbeit einzuhalten. Dann kann man bei der Umsetzung des Datenschutzes agieren – anstatt gezwungen zu werden, kurzfristig zu reagieren.</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_1">
				<div class="et_pb_column et_pb_column_3_5 et_pb_column_1  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_1  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><span style="font-size: 14px;">Noch ist wenig öffentlich dazu bekannt geworden, dass mittelständische Unternehmen die empfindlichen Sanktionen der DSGVO zu spüren bekommen haben. Aber dazu soll es ja auch nicht kommen. Die Sanktionen sind in nationalem Recht festgeschrieben, z. B. in § 42 BDSG. Danach kann mit bis zu zwei Jahren Freiheitsstrafe bestraft werden, wer unberechtigt personenbezogene Daten verarbeitet, wenn diese nicht allgemein zugänglich sind und er sich dadurch einen Vorteil verschafft. Es kann also sehr persönlich werden. Deshalb ist Handeln angesagt, bevor es richtig weh tut und ins Mark des Unternehmens trifft.</span><span style="font-size: 14px;"> </span></p></div>
			</div>
			</div><div class="et_pb_column et_pb_column_2_5 et_pb_column_2  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_0">
				
				
				
				
				<span class="et_pb_image_wrap "><img fetchpriority="high" decoding="async" width="400" height="267" src="https://www.strategieskipper.de/wp-content/uploads/2019/10/Schmerz.jpg" alt="" title="" srcset="https://www.strategieskipper.de/wp-content/uploads/2019/10/Schmerz.jpg 400w, https://www.strategieskipper.de/wp-content/uploads/2019/10/Schmerz-300x200.jpg 300w" sizes="(max-width: 400px) 100vw, 400px" class="wp-image-5842" /></span>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_2">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_3  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_2  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><h3>Das Auskunftsbegehren</h3>
<p>Früher oder später wird der Zeitpunkt kommen, wo ein Unternehmen zu reagieren hat. Da kommt eine E-Mail dem Sinne nach:</p>
<blockquote>
<p>„Sehr geehrte Damen und Herren,</p>
<p>&nbsp;</p>
<p>auf Grundlage des <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e2528-1-1" target="_blank" rel="noopener noreferrer">Artikel 15</a> der DSGVO bitte ich um Auskunft, welche Daten zu meiner Person bei Ihnen gespeichert sind, zu welchen Zwecken Sie diese speichern und verarbeiten, wann Sie diese löschen werden und an wen meine Daten weitergegeben wurden.“</p>
</blockquote>
<p>Eine andere Variante könnte lauten:</p>
<blockquote>
<p>„Auf der Grundlage des Artikel 15 Abs. 3 bitte ich um Kopien der Daten, die sich auf meine Person beziehen.“</p>
</blockquote>
<p>Noch spannender wird es, wenn bezugnehmend auf <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e2621-1-1" target="_blank" rel="noopener noreferrer">Artikel 17</a> eine Person die Einwilligung zur Verarbeitung der Daten widerruft oder die unverzügliche Löschung bestimmter oder aller auf sie bezogenen Daten fordert.</p>
<h3>Der Hintergrund des Auskunftsrechts</h3>
<p>Das Auskunftsrecht ist nicht dazu da, Rechtsabteilungen mit der Abwehr zu beschäftigen oder damit enttäuschte Kunden Unternehmen schikanieren können. Tatsächlich stehen nachvollziehbare Gründe hinter diesem Recht. Zur DSGVO existieren zahlreiche „Erwägungsgründe“, die helfen, Regelungen zu verstehen und diese umzusetzen. So lautet der Erwägungsgrund 63 auszugsweise:</p>
<p>„Eine betroffene Person sollte ein Auskunftsrecht hinsichtlich der sie betreffenden personenbezogenen Daten, die erhoben worden sind, besitzen und dieses Recht problemlos und in angemessenen Abständen wahrnehmen können, um sich der Verarbeitung bewusst zu sein und deren Rechtmäßigkeit überprüfen zu können. … Jede betroffene Person sollte daher ein Anrecht darauf haben zu wissen und zu erfahren, insbesondere zu welchen Zwecken die personenbezogenen Daten verarbeitet werden und, wenn möglich, wie lange sie gespeichert werden, wer die Empfänger der personenbezogenen Daten sind, nach welcher Logik die automatische Verarbeitung personenbezogener Daten erfolgt und welche Folgen eine solche Verarbeitung haben kann, zumindest in Fällen, in denen die Verarbeitung auf Profiling beruht. Nach Möglichkeit sollte der Verantwortliche den Fernzugang zu einem sicheren System bereitstellen können, der der betroffenen Person direkten Zugang zu ihren personenbezogenen Daten ermöglichen würde. Dieses Recht sollte die Rechte und Freiheiten anderer Personen, etwa Geschäftsgeheimnisse oder Rechte des geistigen Eigentums und insbesondere das Urheberrecht an Software, nicht beeinträchtigen. Dies darf jedoch nicht dazu führen, dass der betroffenen Person jegliche Auskunft verweigert wird. Verarbeitet der Verantwortliche eine große Menge von Informationen über die betroffene Person, so sollte er verlangen können, dass die betroffene Person präzisiert, auf welche Information oder welche Verarbeitungsvorgänge sich ihr Auskunftsersuchen bezieht, bevor er ihr Auskunft erteilt.“</p>
<h3>Die Erwartung von Datenschutzbehörden</h3>
<p>Wie die Antwort auf ein Auskunftsbegehren aussehen sollte, haben Datenschutzbehörden inzwischen konkretisiert. Das Bayerische Landesamt für Datenschutzaufsicht hat beispielsweise <a href="https://www.datenschutzbeauftragter-online.de/wp-content/uploads/2019/04/Auskunftsrecht-Muster-gute-Auskunft-4-2019.pdf" target="_blank" rel="noopener noreferrer">ein Musterantwortschreiben</a> veröffentlicht.</p>
<h3>Das Verzeichnis von Verarbeitungstätigkeiten</h3>
<p>Um ein Auskunftsbegehren beantworten zu können, muss ein Unternehmen zunächst einmal wissen, in welchen IT-Lösungen und Datenbanken potentiell personenbezogene Daten gespeichert sein können. Das war früher, als es eine zentrale Unternehmenssoftware gab, schon nicht gerade leicht zu beantworten. Heute, wo die Vorteile der Microservice-Architektur dieser zu einem Siegeszug verholfen hat, können Daten zu einer Person von mehreren Programmen (Services) verarbeitet und gespeichert werden. Was in vielen Fällen Vorteile mit sich bringt, wird hier zu einem Nachteil: dass Prinzip der Microservices, dass jeder Service seinen eigenen Datenspeicher bzw. seine eigene Datenbank haben sollte, statt auf eine einzige zentrale Datenbank zuzugreifen.</p>
<p>Doch genau dabei, nämlich bei der Suche nach potentiellen Speicherorten, sollte eine weitere Vorschrift helfen: das Verzeichnis von Verarbeitungstätigkeiten. Es wird in <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e3277-1-1" target="_blank" rel="noopener noreferrer">Artikel 30</a> beschrieben. Dieses Verzeichnis zu haben und es aktuell zu halten, ist nicht nur hilfreich; Aufsichtsbehörden, wie das bereits zitierte Bayrische Landesamt für Datenschutzaufsicht, können Einsicht in das Verzeichnis eines Unternehmens fordern. Dass die Behörden das auch zunehmend tun, verrät ein Blick auf deren Internetseiten.</p>
<h3>Den Teufel nicht an die Wand malen</h3>
<p>Dann ist da noch das gestiegene Risiko, dass vertrauliche Daten an die Öffentlichkeit oder an Unbefugte gelangen. Man spricht dann von einem „data breach“, einer Datenpanne oder einem Datenleck. Wer seine öffentlichen IP-Adressen überwacht, dürfte bestätigen: die Anzahl der Eindringversuche durch Hacker hat 2019 massiv zugenommen. Doch das Risiko, dass Daten des Unternehmens in unbefugte Hände gelangen, lässt sich nicht alleine an der Firewall eliminieren: immer häufiger gelangen Daten von innen nach außen, weil Mitarbeiter E-Mail-Anhänge oder Webseiten geöffnet haben, durch die auf Rechnern im Unternehmen – hinter der Firewall – Schadsoftware installiert wurde, die dann fleißig Daten sammelt und nach draußen weiterleitet.</p>
<p>Dann ist da noch das Risiko, dass Mitarbeiter Daten nach außen geben, entweder aufgrund von menschlichem Versagen oder Sabotage. In der englischen Wikipedia existiert der Artikel <a href="https://en.wikipedia.org/wiki/List_of_data_breaches" target="_blank" rel="noopener noreferrer">„List of data breaches“</a>, der sicher nur die Spitze des Eisberges auflistet. Interessant ist dabei die Spalte „Method“. Es überrascht, wie häufig „accidentally published“ oder „inside job“ zu finden sind.</p>
<p>Auffällig ist ebenfalls, dass für 2019 kaum Unternehmen mit Sitz in der EU zu finden sind. Dabei schreibt <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e3446-1-1" target="_blank" rel="noopener noreferrer">Artikel 33</a> vor, dass eine Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden an die Aufsichtsbehörde zu melden ist – was natürlich nicht bedeutet, dass eine Verletzung auch öffentlich bekannt wird. Der Artikel definiert außerdem, welche Angaben die Meldung zu enthalten hat. Darüber hinaus sind gemäß <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e3502-1-1" target="_blank" rel="noopener noreferrer">Artikel 34</a> von einem Datenleck betroffene Personen zu verständigen, sofern von einem hohen Risiko für die persönlichen Rechte und Freiheiten auszugehen ist.</p>
<p>Damit eine Meldung frist- und formgerecht erfolgen kann und ggf. auch Betroffene informiert werden, sollten unternehmensinterne Prozesse existieren. Auch muss bekannt sein, welche Art von Daten in welchem IT-System verarbeitet werden, um im Fall eines Schadens auch handeln zu können. Auch dabei hilft ein aktuelles Verzeichnis von Verarbeitungstätigkeiten.</p>
<h3>DSGVO in Fleisch und Blut</h3>
<p>Für erfahrene Architekten und Entwickler ist es in Fleisch und Blut übergegangen, auf Wartbarkeit, Einfachheit, Kompaktheit und Robustheit/Qualität von Code zu achten. DRY ist nur eines der Konzepte, Unit Tests ein Weiteres. Auch wenn es zunächst einmal zusätzliche Zeit kostet, Unit Tests zu entwerfen und zu schreiben, so hat sich die Erkenntnis durchgesetzt, dass man letztendlich Zeit und Kosten spart. Zeit und Kosten, vor allem auch empfindliche Strafen, kann man auch sparen, wenn Architekten und Entwickler noch ein weiteres Prinzip verinnerlichen: das Bewusstsein um die besondere „Empfindlichkeit“ von personenbezogenen Daten. Um dieses Bewusstsein aufzubauen, sollte man sich mindestens diese drei Artikel der DSGVO zu verinnerlichen:</p>
<ul>
<li><a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e1825-1-1" target="_blank" rel="noopener noreferrer">Artikel 5</a><br /> Hier werden <strong>6 Grundsätze</strong> genannt, die bei der Verarbeitung personenbezogener Daten einzuhalten sind. Diese sind:
<p>&nbsp;</p>
<ul>
<li>Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz</li>
<li>Zweckbindung</li>
<li>Datenminimierung, also Datensparsamkeit</li>
<li>Richtigkeit</li>
<li>Speicherbegrenzung, was bedeutet, jede gespeicherte Information mit einem Löschdatum zu versehen</li>
<li>Integrität und Vertraulichkeit</li>
</ul>
</li>
</ul>
<p>Der Artikel erinnert auch daran, dass ein Unternehmen, bzw. um genau zu sein, die dort verantwortliche Person, <strong>rechenschaftspflichtig</strong> ist.</p>
<ul>
<li><a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e1906-1-1" target="_blank" rel="noopener noreferrer">Artikel 6</a><br /> Zählt 6 Umstände auf, unter denen die Verarbeitung und Speicherung personenbezogener Daten überhaupt legal ist. <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e2044-1-1" target="_blank" rel="noopener noreferrer">Artikel 8</a> erweitert diese noch um besondere Bedingungen für die Daten von Kindern.</li>
<li><a href="https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&amp;from=DE#d1e3395-1-1" target="_blank" rel="noopener noreferrer">Artikel 32</a><br /> beschreibt Grundsätze, Verfahren und Verhaltensregeln, um die Sicherheit der Daten sicherzustellen. Dazu gehören Pseudonymisierung, Verschlüsselung aber auch Konzepte, zur Wiederherstellung der Daten bei einem physischen oder technischen Zwischenfall.</li>
</ul>
<h3>DSGVO in der täglichen Routine</h3>
<p>Zusammengefasst sollte ein Architekt oder ein Entwickler folgendes bedenken, wenn ein Stück Software entsteht, das personenbezogene Daten verarbeitet oder speichert:</p>
<ul>
<li>Diese Information kann durch eine Person durch ein Auskunftsbegehren abgefragt werden und muss dann in der Auskunft aufgeführt werden.</li>
<li>Die Person oder eine Aufsichtsbehörde können einen Nachweis verlangen, dass die Verarbeitung einer Information rechtens war.</li>
<li>Die Person kann die Löschung einzelner oder aller Daten verlangen, wobei Ausnahmen bestehen und gewisse Daten aufgrund anderer regulatorischer Vorgaben erst nach Ablauf einer Aufbewahrungsfrist gelöscht werden dürfen.</li>
<li>Die Information muss nach einer gewissen Zeit automatisch gelöscht werden.</li>
<li>Die Information kann unberechtigt offengelegt werden. Dann sind Melde- und ggf. Informationspflichten einzuhalten.</li>
<li>Personenbezogene Daten sind zu pseudonymisieren und zu verschlüsseln.</li>
<li>Eine Wiederherstellung der Daten ist bei einem physischen oder technischen Zwischenfall sicherzustellen.</li>
</ul>
<p>Wie lassen sich diese Anforderungen erfüllen? Auch hier führen viele Wege nach Rom. Besonders spannend wird es, wenn individuelle Softwarelösungen nach einer Microservice-Architektur entworfen wurden und/oder diese in der Cloud betrieben werden.</p>
<p>Sie wollen auf meine Erfahrung zurückgreifen?</p>
<p>Dann freue ich mich auf Ihren Kontakt.</p></div>
			</div><div class="et_pb_button_module_wrapper et_pb_button_0_wrapper et_pb_button_alignment_center et_pb_module ">
				<a class="et_pb_button et_pb_button_0 et_animated et_pb_bg_layout_light" href="/#Kontakt">Jetzt kontaktieren</a>
			</div><div class="et_pb_module et_pb_text et_pb_text_3  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><h3>Disclaimer </h3>
<p>Der Artikel schöpft aus meinen Erfahrungen aus unterschiedlichen Projekten bei verschiedenen Kunden aus 20 Monaten in Vorbereitung auf die DSGVO und in deren Umsetzung. Ich bin kein Jurist und kann daher auch keine verbindlichen Aussagen treffen. Dieser Artikel ist keine Rechtsberatung und ersetzt auch keine. Entsprechend muss ich eine Haftung aufgrund meiner Aussagen ausschließen.</p></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>
<p>Der Beitrag <a href="https://www.strategieskipper.de/dsgvo-im-alltag/">DSGVO im Alltag der Architekten und Entwickler von Software</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Organisationen: Traditionell vs. Agil</title>
		<link>https://www.strategieskipper.de/traditionell-vs-agil/</link>
		
		<dc:creator><![CDATA[Jens Spaniel]]></dc:creator>
		<pubDate>Sun, 25 Mar 2018 20:13:42 +0000</pubDate>
				<category><![CDATA[Allgemein]]></category>
		<category><![CDATA[Ideen/Konzepte]]></category>
		<category><![CDATA[Meinungen]]></category>
		<category><![CDATA[IT Berater Scrum Agil Projektmanagement]]></category>
		<guid isPermaLink="false">http://www.strategieskipper.de/wordpress/?p=4102</guid>

					<description><![CDATA[<p>Der Beitrag <a href="https://www.strategieskipper.de/traditionell-vs-agil/">Organisationen: Traditionell vs. Agil</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p><div class="et_pb_section et_pb_section_1 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_3">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_4  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_4  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>You will find this article in english <a href="#English">below</a>.</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_4">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_5  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_5  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><h2>Organisationen: Traditionell vs. agil</h2>
<p>In Verbindung mit der digitalen Transformation liest man häufig auch von der Notwendigkeit einer Transformation der eigenen Organisation. Ziel ist eine agile Organisation.</p>
<p>Was ist darunter zu verstehen? Was unterscheidet traditionelle Organisationsformen und Methoden von agilen? Wie unterscheidet sich die Arbeit insbesondere bei der Produktentwicklung und einführung, z. B. für eine Software? Wie unterscheidet sich im Fall von Software der spätere IT-Betrieb?</p>
<p>In diesem Artikel möchte ich auf diese Fragen eingehen und die Stärken und Schwächen beleuchten, aber auch die Herausforderungen, die sich nach meiner Erfahrung durch agile Methoden für Organisationen ergeben.</p>
<h3>Traditionelle Modelle</h3>
<h4>Wasserfallmodell</h4></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_5">
				<div class="et_pb_column et_pb_column_1_2 et_pb_column_6  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_6  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>Nach dem Wasserfallmodell werden einzelne Projektphasen sequentiell bearbeitet. Der Fluss des Projekts erfolgt von einer Phase zur die nächsten, ähnlich einem Wasserfall mit mehreren Kaskaden. Die Phasen werden traditionell wie in Abbildung 1 dargestellt, gegliedert.</p></div>
			</div>
			</div><div class="et_pb_column et_pb_column_1_2 et_pb_column_7  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_1">
				
				
				
				
				<span class="et_pb_image_wrap "><img loading="lazy" decoding="async" width="640" height="480" src="/wp-content/uploads/2017/11/2016-03-25_Wasserfallmodell.png" alt="" title="Abbildung 1 Schema des Wasserfallmodells nach Paul Hoadley, Paul Smith und Shmuel Csaba Otto Traian, CC BY-SA 3.0" srcset="https://www.strategieskipper.de/wp-content/uploads/2017/11/2016-03-25_Wasserfallmodell.png 640w, https://www.strategieskipper.de/wp-content/uploads/2017/11/2016-03-25_Wasserfallmodell-300x225.png 300w, https://www.strategieskipper.de/wp-content/uploads/2017/11/2016-03-25_Wasserfallmodell-510x382.png 510w" sizes="(max-width: 640px) 100vw, 640px" class="wp-image-4103" /></span>
			</div><div class="et_pb_module et_pb_text et_pb_text_7  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><em> Abbildung 1 Schema des Wasserfallmodells nach Paul Hoadley, Paul Smith und Shmuel Csaba Otto Traian, CC BY-SA 3.0</em></p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_6">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_8  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_8  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>An der Abarbeitung einer Phase sind häufig, ähnlich wie bei Gewerken bei einem Hausbau, spezialisierte Mitarbeiter beteiligt:</p>
<ul>
<li>bei den Beschreibungen der Anforderungen, häufig in Form eines Lastenhefts, Mitarbeiter und spätere Anwender aus den betroffenen operativen Bereichen ggf. unterstützt durch Arbeitskreise und Berater,</li>
<li>im Entwurf IT-Architekten, die zumeist ein Pflichtenheft und einen Architekturentwurf erstellen, auf dessen Basis häufig ein Festpreisangebot abgegeben und Werkvertrag mit dem implementierenden Dienstleister geschlossen wird,</li>
<li>in der Implementation Entwickler, die die Lösung auf Basis des Pflichtenhefts und ggf. ergänzenden Informationen der IT-Architekten programmieren,</li>
<li>in der Überprüfung Tester des implementierenden Dienstleisters mit nachfolgenden Integrations- und Abnahmetests durch den Auftraggeber, an dem dann die Mitarbeiter beteiligt sind, die die Anforderungen beschrieben haben.<span style="font-size: 14px;"> </span></li>
</ul>
<p>Übergreifend koordiniert werden diese Phasen und Mitarbeiter durch einen Projektleiter. Erfolgt die Implementation durch Entwickler des eigenen Unternehmens, so sind die Mitarbeiter häufig in einer Matrix organisiert und temporär dem Projektleiter fachlich zugeordnet.<span style="font-size: 14px;"> </span></p>
<h4>Klassischer IT-Betrieb</h4>
<p><span style="font-size: 14px;">Der klassische IT-Betrieb folgt häufig den Grundsätzen von ITIL. ITIL ist eine Sammlung von Best-Practice-Ansätzen und beschreibt Prozesse, Funktionen und Rollen zum Betrieb von IT-Infrastruktur.</span></p>
<p><span style="font-size: 14px;">Im klassischen IT-Betrieb hat der zuverlässige und störungsfreie Betrieb die oberste Priorität. Viele Organisationen setzen dabei ITIL dahingehend um, dass die Entwicklung und der IT-Betrieb organisatorisch und disziplinarisch voneinander getrennt sind. Neue Softwarereleases werden in geplanten Zyklen nach eigenen Tests durch Mitarbeiter des IT-Betriebs in produktiven Umgebungen bereitgestellt. Je nach Organisation wird monatlich oder einmal im Quartal ein neues Release bereitgestellt. In Abstimmung mit dem oder den Projektleitern wird festgelegt, welche Funktionen (Features) in ein Release aufgenommen werden. Die Erstellung des Release folgt zumeist dem Wasserfallmodell.</span></p>
<h3>Agile Modelle<span style="font-size: 14px; color: rgba(56, 56, 56, 0.921569); font-family: Raleway, Helvetica, Arial, Lucida, sans-serif; font-weight: 500;"> </span></h3>
<h4>Scrum / Kanban<span style="font-size: 14px; color: rgba(56, 56, 56, 0.921569); font-family: Raleway, Helvetica, Arial, Lucida, sans-serif; font-weight: 500;"> </span></h4>
<p>Scrum, als Beispiel für ein verbreitetes agiles Framework, kennt ebenfalls die Tätigkeiten der Anforderungsdefinition, des Entwurfes, der Implementation und der Überprüfung. Allerdings durchläuft nicht das gesamte zu erstellende Gewerk einmal diese Phasen wie im Wasserfallmodell in einem Stück, sondern die Anforderungen werden in mehreren Schritten, sogenannten Sprints, realisiert. <span>Das zu entwickelnde Werk oder die zu erstellende Softwarelösung wird als Produkt betrachtet. Hierbei übernimmt der &#8222;Product Owner&#8220; sowohl fachliche als auch budgetäre Verantwortung.</span></p>
<p>Scrum folgt einem empirischen Ansatz mit den Säulen Transparenz, Überprüfung (Inspect) und Anpassung (Adapt). Das, was man durch regelmäßige Überprüfungen lernt, fließt in Form von Anpassungen in die weitere Produktentwicklung ein. Bei der Überprüfung wird ausdrücklich das Feedback von Kunden berücksichtigt, um das Produkt tatsächlich an den aktuellen Anforderungen des Marktes auszurichten. Außerdem stützt sich Scrum auf die Grundsätze von Lean Thinking, wozu das &#8222;Pull-Prinzip&#8220; gehört und das Ziel, Verschwendung zu vermeiden. Der Scrum-Guide ist <a href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German-männlich-male-version.pdf">hier</a> verfügbar.<span></span></p>
<p>Das Produkt wird gemeinschaftlich von einem Scrum-Team realisiert. Zum Scrum-Team gehört der Product Owner, das Entwicklerteam und ein &#8222;Scrum Master&#8220;.</p>
<p><span>Der Scrum Master ist kein klassischer Projektmanager, sondern eher ein &#8222;Facilitator&#8220; für das Scrum-Team. Seine Hauptaufgabe besteht darin, sicherzustellen, dass das Scrum-Team das Scrum-Framework und den empirischen Ansatz korrekt versteht und erfolgreich anwendet.</span><span> Insbesondere fördert er das Team in der Fähigkeit zur Selbstorganisation. </span>Er hält dem Team auch &#8222;den Rücken frei&#8220;, indem er dort, wo Engpässe oder Hindernisse (Impediments) entstehen, sich Team-intern und -extern eine Lösung fördert.</p>
<p>Das Entwicklerteam besteht aus Architekten, Entwicklern und Testern. Das Team verfügt über alle erforderlichen Fähigkeiten und Mittel (Ausstattung, Werkzeuge), um das Produkt realisieren zu können.</p>
<p>Zu Beginn der Produktentwickler erstellt der Product Owner gemeinsam mit den Anforderern (Stakeholdern) das sogenannte Product Backlog, eine grobe Liste der Anforderungen. Der Product Owner kommunizierte auch mit Stakeholdern, die nicht nur fachliche Anforderungen an das Produkt haben, sondern in jeglicher Hinsicht Einfluss auf das Produkt nehmen (z. B. Datenschutz, IT-Security, Rechtsabteilung).</p>
<p><span>Nachdem das Produkt Backlog durch den Product Owner priorisiert wurde, </span><span>kann die eigentliche Umsetzung beginnen. Das Produkt wird nun schrittweise in sogenannten &#8222;Sprints&#8220; realisiert, wie in Abbildung 2 gezeigt. Ein Sprint dauert zwischen zwei und vier Wochen. Danach beginn der Zyklus von Neuem. Inzwischen wurden weitere Anforderungen beschrieben und im Product Backlog priorisiert. Der empirische Ansatz ermöglicht es nun, flexibler (agiler) als im klassischen Wasserfallmodell noch während der Produktentwicklung Anpassungen vorzunehmen, um ein marktgerechtes Produkt entstehen zu lassen.</span></p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_7">
				<div class="et_pb_column et_pb_column_1_2 et_pb_column_9  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_2">
				
				
				
				
				<span class="et_pb_image_wrap "><img loading="lazy" decoding="async" width="505" height="349" src="/wp-content/uploads/2017/11/032416_1629_Organisatio2.png" alt="" title="" srcset="https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1629_Organisatio2.png 505w, https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1629_Organisatio2-300x207.png 300w" sizes="(max-width: 505px) 100vw, 505px" class="wp-image-4104" /></span>
			</div><div class="et_pb_module et_pb_text et_pb_text_9  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><em>Abbildung 2 Schema Vorgehen in Scrum-Projekten, <br /></em><em>Quelle: DasScrumTeam AG</em></p></div>
			</div>
			</div><div class="et_pb_column et_pb_column_1_2 et_pb_column_10  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_10  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><span style="font-size: 14px;"></span></p>
<p>Ein Sprint ist vergleichbar mit einem Teilprojekt. Zu Beginn eines Sprints plant das Scrum-Team gemeinsam den Umfang des kommenden Sprints. Der Product Owner bringt dazu den Vorschlag für ein Sprint-Ziel ein. Das Entwicklerteam wählt aus dem Product Backlog zum Sprint-Ziel passende Einträge und übernimmt diese in das vom Entwicklerteam gemeinsam verantwortete Sprint Backlog. Nach dem gemeinsamen &#8222;Commitment&#8220; des Entwicklerteams zum Sprint-Ziel und dem geplanten Sprint Backlog, beginnt die Realisierung.  </p>
<p>Typisch für Scrum ist, dass sich das Entwicklerteam täglich zu einem kurzen, maximal 15-minütigem Meeting trifft, in dem es die Arbeit für den aktuellen Tag abstimmt und eventuelle Hindernisse anspricht.</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_8">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_11  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_11  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><span>Am Ende jedes Sprints steht ein betriebsbereites Produktinkrement zur Verfügung, das die geplanten Anforderungen erfüllt. Das Scrum-Team präsentiert dieses Produktinkrement während des sogenannten Sprint-Reviews den Stakeholdern. Während dieses Meetings gibt der Product Owner außerdem einen Überblick über die gesetzten Prioritäten und die Zielsetzungen für den kommenden Sprint. Die Sprint-Review dient somit nicht nur als bloße Demonstrationsveranstaltung, sondern fungiert als interaktives Arbeitsmeeting für das Scrum-Team und die beteiligten Stakeholdern. Idealerweise nehmen daran auch Kunden teil. Die Sprint Review setzt also die empirischen Säulen von Scrum Transparenz, Überprüfung und Anpassung um.</span></p>
<p>Um die Zusammenarbeit des Scrum-Teams zu verbessern, trifft sich dieses unter Anleitung des Scrum-Masters am Ende des Sprints (Sprint Retrospektive, Lessons learned). Auch dieses Meeting dient zur Überprüfung und hat Anpassung zum Ziel.</p>
<p><span style="font-size: 14px;">Zur Steuerung der Aufgaben des Teams wird Scrum häufig mit Kanban kombiniert. Dieser ursprünglich aus der Automobilfertigung stammende Ansatz wurde auf die Softwareentwicklung übertragen. Die einzelnen Aufgaben werden dabei auf Kanban-Karten notiert und durchlaufen die Softwareproduktion. Als einzelne Produktionsbereiche gelten dabei zumeist Design, Test-Preparation, Development, Test und Deployment. Die Produktion erfolgt typisch für Kanban nach dem Pull-Prinzip. Nachfolgende Produktionsbereiche fordern bei freien Kapazitäten beim vorausgehenden Produktionsbereich neue Aufgaben an. Ein Prinzip von Kanban ist, den Fluss der Arbeit zu visualisieren. So ist auf dem Kanban-Board erkennbar, wie vielen Aufgaben in welchem Produktionsbereich stecken (WiP/Work in Progress). So werden Engpässe in einzelnen Bereichen leichter erkennbar, wodurch der Prozess der Realisierung der Features optimiert werden kann.</span><span style="font-size: 14px;"> </span></p>
<p>Neben Features werden auch Bugs auf Kanban-Karten notiert und durchlaufen ebenso den gesamten Prozess.</p>
<h4>Continuous Integration, Continuous Delivery und DevOps</h4>
<p>Auf der Basis von agilen Methoden wie Scrum und Extreme Programming haben sich Konzepte etabliert, die eine kurzfristige und doch hohen Qualitätsansprüchen genügende Bereitstellung von Software ermöglichen. Das Konzept der Continuous Integration beschreibt Prozesse, Grundsätze und Anforderungen an Werkzeuge, um fortlaufend und mit einem hohen Automatisierungsgrad qualitativ hochwertige Software zu erstellen. Automatisiert meint dabei nicht, dass die Programmierung selbst automatisiert erfolgt. Diese Tätigkeit obliegt nach wie vor Entwicklern. Die Continuous Integration automatisiert jedoch den Prozess, der aus dem Quellcode eine neue Programmversion des Softwareprodukts baut (Software Build).</p>
<p>Ein wesentliches Element sind dabei automatisierte Tests, sogenannte Unittests. Als Grundlage für einen Unittest dienen Business Cases, die durch den jeweiligen Fachbereich beschrieben werden. Ein Business Case beschreibt einen konkreten Geschäftsvorfall, beispielsweise:<span style="font-size: 14px;"> </span></p>
<p>Der Mitarbeiter Müller aus der Niederlassung 0815 erfasst am 15.01.2016 für die Sendung 4711 eine Retoure an den Versender aufgrund einer Annahmeverweigerung durch den Empfänger. Erwartet wird dabei, dass der Mitarbeiter durch die Software einen Fehlerhinweis erhält, da in der Datenbank bereits dokumentiert ist, dass die Zustellung der Sendung am 14.01.2016 erfolgte.<span style="font-size: 14px;"> </span></p>
<p>Der Entwickler verwendet den Business Case, um ein kleines Testprogramm zu schreiben. Dieses ruft die Softwarefunktion oder Methode (z. B. eine API-Funktion) auf, die durch den Test überprüft werden soll und durch den beschriebenen Business Case genutzt wird. Dabei nutzt er die konkreten Informationen aus dem Business Case als Parameter für den Funktionsaufruf. Da der Business Case auch das erwartete Ergebnis definiert, kann das Testprogramm dieses mit der tatsächlichen Rückgabe der getesteten Funktion vergleichen. Stimmen erwartetes und tatsächliches Ergebnis überein, so ist der Test erfolgreich, andernfalls fehlerhaft.<span style="font-size: 14px;"> </span></p>
<p>Während der automatischen Erstellung eines Software Builds werden alle Unittests durchlaufen. Nur wenn alle Unittests erfolgreich abgeschlossen werden konnten, steht eine neue ausführbare Programmversion zur Verfügung.</p>
<p>Das Konzept der Continuous Delivery führt den Prozess der Continuous Integration fort und beschreibt Techniken und Prozesse, wie neue Programmversionen in kurzen Zyklen für die stabile produktive Nutzung bereitgestellt werden.</p>
<p>Zur Umsetzung von Continuous Delivery beschreibt der DevOps-Ansatz eine entsprechende Philosophie und einen organisatorischen Rahmen. Der Kern liegt darin, wie die Zusammenarbeit zwischen den Entwicklern (Dev) und dem IT-Betrieb (Ops) verbessert werden kann. In klassischen Organisationen sind diese beiden Abteilungen voneinander getrennt und verfolgen kollidierende Ziele: die Entwickler möchten möglichst kurzfristig und häufig neue Programmversionen an den Endanwender ausliefern, um Bugfixes und neue Funktionen bereitzustellen; der IT-Betrieb möchte möglichst selten Änderungen an der produktiven Umgebung, da jede Änderung das potentielle Risiko trägt, den IT-Betrieb zu stören. Der DevOps-Ansatz fördert dabei eine Kultur, die die Zusammenarbeit zum Nutzen des Endanwenders verbessert, ohne Risiken für den stabilen IT-Betrieb zu erhöhen. Das Softwarearchitekturmodell der Microservices legt dabei eine technische Grundlage, um auftretende Fehler und Störungen im Betrieb zu begrenzen und optimal zu behandeln.<span style="font-size: 14px;"> </span></p>
<h3>Vergleich der Modelle<span style="font-size: 14px; color: rgba(56, 56, 56, 0.921569); font-family: Raleway, Helvetica, Arial, Lucida, sans-serif; font-weight: 500;"> </span></h3>
<p>Welches Vorgehensmodell für welches Projekt besonders geeignet ist, um zuverlässig und kosteneffizient die Projektziele zu erreichen, hängt insbesondere von der Komplexität des Projekts ab und der an dem Projekt beteiligten Persönlichkeiten.<span style="font-size: 14px;"> </span></p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_9">
				<div class="et_pb_column et_pb_column_1_2 et_pb_column_12  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_3">
				
				
				
				
				<span class="et_pb_image_wrap "><img loading="lazy" decoding="async" width="378" height="324" src="/wp-content/uploads/2017/11/032416_1628_Organisatio3.png" alt="" title="" srcset="https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1628_Organisatio3.png 378w, https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1628_Organisatio3-300x257.png 300w" sizes="(max-width: 378px) 100vw, 378px" class="wp-image-4105" /></span>
			</div><div class="et_pb_module et_pb_text et_pb_text_12  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><em>Abbildung 3 Komplexitätsdiagramm nach Ralph Douglas Stacey, Quelle: Andreas Schliep, DasScrumTeam AG</em></div>
			</div>
			</div><div class="et_pb_column et_pb_column_1_2 et_pb_column_13  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_13  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>Der Komplexitätsforscher Ralph Douglas Stacey hat für zunehmende Komplexität zwei Treiber identifiziert: Uneinigkeit und Unsicherheit. Übertragen auf ein IT-Projekt bedeutet das, dass wenn Einigkeit zu Vorgehen, Ressourcen und Budget besteht und man genau weiß, was man möchte und keine offenen Punkte bestehen, das Projekt als einfach eingestuft werden kann. In Projekten, in denen Uneinigkeit und Unsicherheit höher ist, steigt die Komplexität bis hin zu chaotisch, wobei chaotisch in diesem Fall nicht negativ zu deuten ist. Welche Komplexität ein Projekt besitzt, wird durch das Projekt selbst, seine Rahmenbedingungen und die Beteiligten bestimmt. Eine hohe Komplexität lässt sich nicht immer vermeiden. Die Unsicherheit wird häufig dadurch getrieben, indem zwar eine Vision von dem finalen Produkt existiert, aber der konkrete Weg zur Realisierung unklar ist und mitunter auch experimentell vorgegangen werden muss. Der Umfang oder die Dauer des Projekts gilt nach diesem Modell nicht als Treiber für Komplexität. Demnach kann der Bau einer großen Anlage, der mehrere Monate in Anspruch nimmt, als kompliziert eingestuft werden, sofern die Faktoren Uneinigkeit und Unsicherheit gering sind.</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_10">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_14  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_14  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>Das Wasserfallmodell ist insbesondere für Projekte geeignet, die den Komplexitätsgrad einfach oder kompliziert haben, agile Methoden für komplex und chaotisch.</p>
<p>Die Erfahrungen mit agilen Methoden haben gezeigt, dass sich damit kurze bis sehr kurze Produktzyklen mit einer dennoch hohen Qualität realisieren lassen. Sie empfehlen sich, wenn nicht im Detail frühzeitig geplant werden kann, wie das zu erstellende Produkt final aussehen soll (hohe Unsicherheit). Dies wird auch durch den Vergleich der Wertschöpfungskurven der beiden Modelle deutlich (Abbildung 4).</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_11">
				<div class="et_pb_column et_pb_column_1_2 et_pb_column_15  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_4">
				
				
				
				
				<span class="et_pb_image_wrap "><img loading="lazy" decoding="async" width="378" height="274" src="/wp-content/uploads/2017/11/032416_1628_Organisatio4.png" alt="" title="" srcset="https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1628_Organisatio4.png 378w, https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1628_Organisatio4-300x217.png 300w" sizes="(max-width: 378px) 100vw, 378px" class="wp-image-4106" /></span>
			</div><div class="et_pb_module et_pb_text et_pb_text_15  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><em>Abbildung 4 Wertschöpfungskurven Wasserfallmodell vs. agilen Methoden, Quelle: Andreas Schliep, DasScrumTeam AG</em></div>
			</div>
			</div><div class="et_pb_column et_pb_column_1_2 et_pb_column_16  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_16  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>Die graue Linie gibt den Verlauf bei einem klassischen Vorgehensmodell wieder, die orange bei einem agilen Vorgehen. Aufgrund der häufigen Iterationen z. B. in Form von Sprints, entsteht bei der Anwendung von agilen Methoden bereits früh ein erstes Produktinkrement, z. B. in Form eines Klick-Dummys. Die Iterationen ermöglichen es auch, für jede Iteration/jeden Sprint die Anforderungen nachzujustieren. Bei Abschluss des Projekts erhält man so ein Produkt, das den Anforderungen entspricht, die erst zuletzt festgeschrieben wurden. So können praktische Erfahrungen berücksichtigt werden, die während des Projektverlaufs gewonnen wurden. In der Grafik entspricht daher das Produkt den Anforderungen, die zum Zeitpunkt tx definiert wurden.</p>
<p>Klassische Vorgehensmodelle beginnen mit einer längeren Analyse- und Planungsphase. Dazu werden früh im Projekt, in der Grafik zum Zeitpunkt t1, die Anforderungen festgeschrieben, z. B. in Form eines Pflichtenhefts. Entsprechend entspricht das fertige Produkt am Ende des Projekts den Anforderungen zum Zeitpunkt t1.<span> </span></p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_12">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_17  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_17  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>Die Vorteile der klassischen Methoden werden häufig in einer vermeintlichen Kostensicherheit gesehen: Da zum Zeitpunkt t1 der Funktionsumfang festgeschrieben wird, kann ein Dienstleister den Aufwand zur Umsetzung schätzen und ist in der Lage ein Festpreis anzubieten. Dieser Festpreis wird jedoch in der Praxis nicht selten überschritten, da zum Zeitpunkt t1 Anforderungen übersehen wurden, noch nicht bekannt waren oder erst durch den Fortschritt der Zeit im Projekt hinzukamen. Diese Änderungen erhöhen dann in Form von Projektnachträgen die Kosten.<span style="font-size: 14px;"> </span></p>
<p>Kostensicherheit kann in agilen Projekten durch den &#8222;Design-to-Budget&#8220;-Ansatz sichergestellt werden. Vor jeder Iteration/jedem Sprint definiert der Product Owner ein Budget und stimmt mit dem Team/dem Dienstleister ab, welche Features in diesem Rahmen realisiert werden können. Dies fördert eine Kosten-Nutzen-Abwägung einzelner Funktionen und berücksichtigt das Pareto-Prinzip. Dieses besagt, dass 80 % des Ergebnisses mit 20 % des Gesamtaufwands erreicht werden, wohingegen die verbleibenden 20 % der Ergebnisse 80 % der Kosten verschlingen. Durch eine zielgerichtete Kosten-Nutzen-Abwägung wird häufig deutlich, dass nicht immer eine 100 %-Lösung erforderlich ist, die alle Anforderungen berücksichtigt. Das trägt direkt dazu bei, dass ein Produkt früher verfügbar ist und zu geringeren Kosten. Dabei ist nicht ausgeschlossen, dass zu einem späteren Zeitpunkt weitere Anforderungen umgesetzt werden, die dann jedoch die Erfahrungen berücksichtigen können, die durch die zwischenzeitliche Nutzung des Produkts gewonnen wurden.</p>
<p>Eine Herausforderung in der Anwendung von agilen Methoden besteht jedoch in dem höheren erforderlichen Reifegrad der beteiligten Personen und Organisationen. So hat bei Scrum das Team eine höhere Freiheit in der Umsetzung aber damit auch eine höhere Verantwortung. Außerdem organisiert sich das Team selbst. Beides setzt voraus, dass die Teammitglieder hierzu bereit sind.<span style="font-size: 14px;"> </span></p>
<p>Außerdem erfordert Scrum auch von dem Auftraggeber/dem Investor eine höhere Risikobereitschaft, da nicht vor Start eines Projekts exakt definiert ist, zu welchen Kosten und in welcher Zeit das Produkt erstellt werden kann.<span style="font-size: 14px;"> </span></p>
<h3>Fazit<span style="font-size: 14px; color: rgba(56, 56, 56, 0.921569); font-family: Raleway, Helvetica, Arial, Lucida, sans-serif; font-weight: 500;"> </span></h3>
<p>Grundsätzlich besteht nicht in jedem Projekt die Pflicht, dieses nach agilen Methoden zu bearbeiten. Aufgabenstellungen, die den Komplexitätsgrad einfach bis kompliziert haben, können erfolgreich mit einer klassischen Planung und Durchführung gelöst werden.</p>
<p>Die digitale Transformation stellt Organisationen vor Herausforderungen – bietet aber auch die Chance, neben neuen Technologien einen Wandel der Unternehmenskultur hin zu einer agilen Organisation zu vollziehen. Die meisten externen IT-Dienstleister und einige unternehmensinterne IT-Abteilungen arbeiten bereits mit agilen Methoden. Das vollständige Potential können agile Methoden jedoch nur entfalten, wenn der gesamte Prozess zur Entwicklung und Einführung eines neuen Produkts agile Methoden nutzt – nicht nur der Teil, der durch die IT bearbeitet wird.<span style="font-size: 14px;"> </span></p>
<p>Dabei lassen sich Organisationen nicht per Schalter auf agil umstellen – dies ist ein Reifeprozess. Mitarbeiter und Manager benötigen Zeit, um Vertrauen in agile Methoden zu fassen und Praxis und Sicherheit in der Anwendung zu gewinnen. In diesem Prozess können sie zumindest anfänglich durch einen externen Berater unterstützt werden, der in der Anwendung agiler Methoden erfahren ist.</p>
<p>Sie wollen auf meine Erfahrung zurückgreifen?<span style="font-size: 14px;"> </span></p>
<p>Dann freue ich mich auf Ihren Kontakt.<span style="font-size: 14px;"> </span></p></div>
			</div><div class="et_pb_button_module_wrapper et_pb_button_1_wrapper et_pb_button_alignment_center et_pb_module ">
				<a class="et_pb_button et_pb_button_1 et_pb_bg_layout_light" href="/#Kontakt">Jetzt kontaktieren</a>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div><div class="et_pb_section et_pb_section_2 et_clickable et_section_regular" >
				
				
				
				
				
				
				<div id="English" class="et_pb_row et_pb_row_13">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_18  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_18  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><h2>Organizations: Traditional vs. Agile</h2>
<p><span style="font-size: 14px;"><span>In connection with digital transformation, one often comes across the necessity of transforming one&#8217;s own organization. The goal is to achieve an agile organization. </span></span></p>
<p><span style="font-size: 14px;"><span>What does this mean? What sets traditional organizational forms and methods apart from agile ones? How does work, especially in product development and implementation, differ, for instance, in the case of software? How does the subsequent IT operation differ in the case of software? </span></span></p>
<p><span style="font-size: 14px;"><span>In this article, I aim to address these questions, shedding light on the strengths and weaknesses, as well as the challenges that, in my experience, arise for organizations through agile methods</span>.</span></p>
<h3>T<span>raditional Models</span></h3>
<h4><span>Waterfall Model</span></h4></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_14">
				<div class="et_pb_column et_pb_column_1_2 et_pb_column_19  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_19  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>According to the Waterfall Model, individual project phases are processed sequentially. The flow of the project moves from one phase to the next, similar to a waterfall with multiple cascades. The phases are traditionally organized as depicted in Figure 1.</p></div>
			</div>
			</div><div class="et_pb_column et_pb_column_1_2 et_pb_column_20  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_5">
				
				
				
				
				<span class="et_pb_image_wrap "><img loading="lazy" decoding="async" width="800" height="600" src="https://www.strategieskipper.de/wp-content/uploads/2024/01/waterfall.png" alt="" title="waterfall" srcset="https://www.strategieskipper.de/wp-content/uploads/2024/01/waterfall.png 800w, https://www.strategieskipper.de/wp-content/uploads/2024/01/waterfall-480x360.png 480w" sizes="(min-width: 0px) and (max-width: 480px) 480px, (min-width: 481px) 800px, 100vw" class="wp-image-6354" /></span>
			</div><div class="et_pb_module et_pb_text et_pb_text_20  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><em>Image 1: Diagram of the Waterfall Model by Paul Hoadley, Paul Smith und Shmuel Csaba Otto Traian, CC BY-SA 3.0</em></p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_15">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_21  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_21  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><span>In the execution of each phase, specialized personnel are often involved, similar to trades in construction projects</span>:</p>
<ul>
<li>In the requirements description phase, often outlined in the form of a requirements specification, employees and future users from the affected operational areas may be assisted by working groups and consultants.</li>
<li>In the design phase, IT architects typically create a requirements specification and an architectural design. Based on this, a fixed-price offer is often submitted, and a contract is signed with the implementing service provider.</li>
<li>In the implementation phase, developers program the solution based on the requirements specification and additional information provided by the IT architects.</li>
<li>In the verification phase, testers from the implementing service provider conduct subsequent integration and acceptance tests, overseen by the client. Employees who described the requirements are often involved in this phase as well.<span style="font-size: 14px;"> </span></li>
</ul>
<p><span>These phases and personnel are overseen and coordinated by a project manager. If the implementation is carried out by developers from the same company, employees are often organized in a matrix and temporarily assigned to the project manager in terms of expertise</span>.<span style="font-size: 14px;"> </span></p>
<h4><span>Traditional IT Operations</span></h4>
<p><span style="font-size: 14px;"><span>Traditional IT operations often adhere to the principles of ITIL (Information Technology Infrastructure Library). ITIL is a collection of best practice approaches that describe processes, functions, and roles for operating IT infrastructure. </span></span></p>
<p><span style="font-size: 14px;"><span>In traditional IT operations, ensuring reliable and uninterrupted operation takes top priority. Many organizations implement ITIL in a way that separates the development and IT operations organizationally and disciplinarily. New software releases are deployed in planned cycles after internal testing by IT operations personnel in productive environments. Depending on the organization, a new release may be deployed monthly or quarterly. In coordination with project managers, it is determined which features are included in a release. The creation of the release typically follows the waterfall model</span>.</span></p>
<h3>Agile Models<span style="font-size: 14px; color: rgba(56, 56, 56, 0.921569); font-family: Raleway, Helvetica, Arial, Lucida, sans-serif; font-weight: 500;"> </span></h3>
<h4>Scrum / Kanban<span style="font-size: 14px; color: rgba(56, 56, 56, 0.921569); font-family: Raleway, Helvetica, Arial, Lucida, sans-serif; font-weight: 500;"> </span></h4>
<p>Scrum, as an example of a widely used agile framework, also involves activities such as requirement definition, design, implementation, and verification. However, the entire product or solution being developed does not go through these phases in one continuous piece, as in the waterfall model. Instead, the requirements are realized in multiple steps, known as sprints. The product or solution being developed is considered a product, and the &#8222;Product Owner&#8220; takes on both functional and budgetary responsibilities.</p>
<p>Scrum follows an empirical approach with the pillars of Transparency, Inspection, and Adaptation. What is learned through regular inspections is incorporated into further product development through adjustments. During the inspection, customer feedback is explicitly considered to align the product with the current market requirements. Additionally, Scrum is based on the principles of Lean Thinking, including the &#8222;Pull Principle&#8220; and the goal of avoiding waste. The Scrum Guide is available <a href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf">here</a>.</p>
<p>The product is collaboratively realized by a Scrum Team, which includes the Product Owner, the development team, and a Scrum Master.</p>
<p>The Scrum Master is not a traditional project manager but rather a facilitator for the Scrum Team. Their main task is to ensure that the Scrum Team correctly understands and successfully applies the Scrum framework and the empirical approach. In particular, they promote the team&#8217;s ability to self-organize. The Scrum Master also &#8222;has the team&#8217;s back&#8220; by fostering solutions where bottlenecks or impediments arise, both internally and externally.</p>
<p>The development team consists of architects, developers, and testers. The team possesses all the necessary skills and resources (equipment, tools) to realize the product.</p>
<p>At the beginning of the product development, the Product Owner, together with stakeholders, creates the Product Backlog, a rough list of requirements. The Product Owner also communicates with stakeholders who have influence over the product in various aspects (e.g., data protection, IT security, legal department).</p>
<p>Once the Product Backlog has been prioritized by the Product Owner, the actual implementation can begin. The product is now realized gradually in sprints, as shown in Figure 2. A sprint lasts between two and four weeks. Afterward, the cycle begins anew. Meanwhile, additional requirements have been described and prioritized in the Product Backlog. The empirical approach allows for more flexibility (agility) than in the traditional waterfall model, enabling adjustments during product development to create a market-ready product.</p>
<p><span style="font-size: 14px;">.</span></p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_16">
				<div class="et_pb_column et_pb_column_1_2 et_pb_column_22  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_6">
				
				
				
				
				<span class="et_pb_image_wrap "><img loading="lazy" decoding="async" width="505" height="349" src="/wp-content/uploads/2017/11/032416_1629_Organisatio2.png" alt="" title="" srcset="https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1629_Organisatio2.png 505w, https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1629_Organisatio2-300x207.png 300w" sizes="(max-width: 505px) 100vw, 505px" class="wp-image-4104" /></span>
			</div><div class="et_pb_module et_pb_text et_pb_text_22  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><em>Figure 2 &#8211; Process Schema in Scrum Projects, <br /></em><em>Source: DasScrumTeam AG</em></p></div>
			</div>
			</div><div class="et_pb_column et_pb_column_1_2 et_pb_column_23  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_23  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><span style="font-size: 14px;"></span></p>
<p>A Sprint is comparable to a subproject. At the beginning of a Sprint, the Scrum Team collaboratively plans the scope of the upcoming Sprint. The Product Owner contributes the proposal for a Sprint Goal. The Development Team selects entries from the Product Backlog that align with the Sprint Goal and incorporates them into the Sprint Backlog, which is jointly responsible for the Development Team. After the Development Team&#8217;s shared commitment to the Sprint Goal and the planned Sprint Backlog, the implementation begins.</p>
<p>A characteristic feature of Scrum is that the Development Team meets daily for a short, maximum 15-minute meeting, where it aligns the work for the current day and addresses any potential impediments.</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_17">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_24  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_24  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>At the end of each Sprint, a functional product increment that meets the planned requirements is made available. The Scrum Team presents this product increment to stakeholders during the Sprint Review. During this meeting, the Product Owner also provides an overview of the set priorities and goals for the upcoming Sprint. The Sprint Review serves not only as a mere demonstration event but functions as an interactive working meeting for the Scrum Team and involved stakeholders. Ideally, customers also participate. Thus, the Sprint Review embodies the empirical pillars of Scrum: Transparency, Inspection, and Adaptation.</p>
<p>To enhance the collaboration of the Scrum Team, they gather under the guidance of the Scrum Master at the end of the Sprint (Sprint Retrospective or Lessons Learned). This meeting also serves for inspection and aims for adaptation.</p>
<p>To manage the team&#8217;s tasks, Scrum is often combined with Kanban. This approach, originally from manufacturing, has been applied to software development. Tasks are noted on Kanban cards and go through the software production phases. Design, Test Preparation, Development, Test, and Deployment are typically considered as individual production stages. Production in Kanban typically follows the Pull Principle, where subsequent stages request new tasks from the preceding stage when there are available capacities. A principle of Kanban is to visualize the flow of work. The Kanban board indicates how many tasks are in progress in each production stage (WiP/Work in Progress), making bottlenecks in individual stages more easily identifiable, optimizing the process of feature realization.</p>
<p>In addition to features, bugs are also noted on Kanban cards and undergo the entire process.</p>
<h4>Continuous Integration, Continuous Delivery and DevOps</h4>
<p>Based on agile methods like Scrum and Extreme Programming, concepts have been established to enable the short-term and yet high-quality deployment of software. The concept of Continuous Integration describes processes, principles, and tool requirements to continuously build high-quality software with a high level of automation. Automation, in this context, does not mean that programming itself is automated; developers still handle this task. However, Continuous Integration automates the process of building a new program version from the source code (Software Build).</p>
<p>A crucial element is automated tests, known as unit tests. Business cases, described by the respective business department, serve as a basis for a unit test. A business case describes a specific business scenario, for example:</p>
<p>&#8222;Employee Müller from Branch 0815 records a return to the sender for shipment 4711 on 15.01.2016 due to the recipient&#8217;s refusal. The expectation is that the employee receives an error message through the software since the database already documents the delivery of the shipment on 14.01.2016.&#8220;</p>
<p>The developer uses the business case to write a small test program. This program calls the software function or method (e.g., an API function) that the test aims to verify and is used by the described business case. Using the specific information from the business case as parameters for the function call, the developer compares the expected result defined by the business case with the actual return of the tested function. If the expected and actual results match, the test is successful; otherwise, it is faulty.</p>
<p>During the automatic creation of a software build, all unit tests are executed. Only if all unit tests are successfully completed, a new executable program version becomes available.</p>
<p>The concept of Continuous Delivery extends the Continuous Integration process and describes techniques and processes for providing new program versions for stable productive use in short cycles.</p>
<p>To implement Continuous Delivery, the DevOps approach describes a corresponding philosophy and organizational framework. The core lies in improving collaboration between developers (Dev) and IT operations (Ops). In traditional organizations, these two departments are separate and pursue conflicting goals: developers aim to deliver new program versions to end-users as quickly and frequently as possible to provide bug fixes and new features, while IT operations want to make changes to the production environment as infrequently as possible since each change carries the potential risk of disrupting IT operations. The DevOps approach promotes a culture that improves collaboration for the benefit of end-users without increasing risks for stable IT operations. The Microservices software architecture model provides a technical foundation to limit and handle errors and disruptions efficiently during operation.</p>
<h3>Comparison of Models<span style="font-size: 14px; color: rgba(56, 56, 56, 0.921569); font-family: Raleway, Helvetica, Arial, Lucida, sans-serif; font-weight: 500;"> </span></h3>
<p>The suitability of a particular approach for reliably and cost-effectively achieving project goals depends mainly on the complexity of the project and the personalities involved in the project.<span style="font-size: 14px;"> </span></p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_18">
				<div class="et_pb_column et_pb_column_1_2 et_pb_column_25  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_7">
				
				
				
				
				<span class="et_pb_image_wrap "><img loading="lazy" decoding="async" width="378" height="324" src="/wp-content/uploads/2017/11/032416_1628_Organisatio3.png" alt="" title="" srcset="https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1628_Organisatio3.png 378w, https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1628_Organisatio3-300x257.png 300w" sizes="(max-width: 378px) 100vw, 378px" class="wp-image-4105" /></span>
			</div><div class="et_pb_module et_pb_text et_pb_text_25  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><em>Figure 3 &#8211; Complexity Diagram according to Ralph Douglas Stacey, Source: Andreas Schliep, DasScrumTeam AG</em></div>
			</div>
			</div><div class="et_pb_column et_pb_column_1_2 et_pb_column_26  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_26  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>Complexity researcher Ralph Douglas Stacey has identified two drivers for increasing complexity: disagreement and uncertainty. Applied to an IT project, this means that when there is agreement on approach, resources, and budget, and one knows exactly what is wanted with no open issues, the project can be classified as simple. In projects where disagreement and uncertainty are higher, complexity increases, ranging up to chaotic, where chaos, in this case, is not necessarily negative. The complexity of a project is determined by the project itself, its conditions, and the participants. High complexity cannot always be avoided. Uncertainty is often driven by the existence of a vision for the final product, but the concrete path to realization is unclear and may require experimental approaches. According to this model, the scope or duration of the project is not a driver for complexity. Therefore, the construction of a large facility taking several months can be classified as complicated if the factors of disagreement and uncertainty are low.</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_19">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_27  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_27  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>The Waterfall model is particularly suitable for projects with a complexity level that is simple or complicated, while agile methods are suitable for complex and chaotic projects.</p>
<p>Experiences with agile methods have demonstrated their effectiveness in realizing short to very short product cycles with high quality. They are recommended when detailed planning of the final product appearance cannot be done early on (high uncertainty). This is also evident in the comparison of the value creation curves of the two models (Figure 4).</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_20">
				<div class="et_pb_column et_pb_column_1_2 et_pb_column_28  et_pb_css_mix_blend_mode_passthrough">
				
				
				
				
				<div class="et_pb_module et_pb_image et_pb_image_8">
				
				
				
				
				<span class="et_pb_image_wrap "><img loading="lazy" decoding="async" width="378" height="274" src="/wp-content/uploads/2017/11/032416_1628_Organisatio4.png" alt="" title="" srcset="https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1628_Organisatio4.png 378w, https://www.strategieskipper.de/wp-content/uploads/2017/11/032416_1628_Organisatio4-300x217.png 300w" sizes="(max-width: 378px) 100vw, 378px" class="wp-image-4106" /></span>
			</div><div class="et_pb_module et_pb_text et_pb_text_28  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><em> Figure 4 Value Creation Curves &#8211; Waterfall Model vs. Agile Methods, Source: Andreas Schliep, DasScrumTeam AG</em></div>
			</div>
			</div><div class="et_pb_column et_pb_column_1_2 et_pb_column_29  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_29  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>The gray line represents the progression in a traditional approach, while the orange line represents an agile approach. Due to frequent iterations, such as in the form of Sprints, agile methods generate an initial product increment early on, for example, in the form of a clickable prototype. The iterations also allow for adjusting the requirements for each iteration/Sprint. Upon project completion, the result is a product that aligns with the requirements defined most recently. This approach enables the incorporation of practical experiences gained during the project. In the graph, therefore, the product corresponds to the requirements defined at time tx.</p>
<p>Traditional approaches typically commence with an extended analysis and planning phase. Early in the project, at time t1 in the graph, the requirements are documented, for instance, in the form of a requirements specification. Consequently, the final product at the end of the project adheres to the requirements set at time t1.</p></div>
			</div>
			</div>
				
				
				
				
			</div><div class="et_pb_row et_pb_row_21">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_30  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_30  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>The advantages of traditional methods are often perceived in terms of cost certainty: Since the scope of functionality is defined at time t1, a service provider can estimate the effort required for implementation and is able to offer a fixed price. However, in practice, this fixed price is often exceeded because requirements were overlooked at time t1, were not yet known, or emerged as the project progressed over time. These changes then increase costs in the form of project supplements.</p>
<p>Cost certainty in agile projects can be ensured through the &#8222;Design-to-Budget&#8220; approach. Before each iteration/Sprint, the Product Owner defines a budget and collaborates with the team/service provider to determine which features can be realized within this framework. This promotes a cost-benefit assessment of individual functions and considers the Pareto principle, stating that 80% of results are achieved with 20% of the total effort, while the remaining 20% of results consume 80% of the costs. A targeted cost-benefit assessment often reveals that a 100% solution that accommodates all requirements is not always necessary. This directly contributes to making a product available earlier and at lower costs. It is not excluded that additional requirements may be implemented at a later time, but these can consider the experiences gained through the interim use of the product.</p>
<p>However, a challenge in the application of agile methods lies in the higher required maturity level of the individuals and organizations involved. In Scrum, for example, the team has greater freedom in implementation but also greater responsibility. Additionally, the team organizes itself, which requires team members to be willing to do so.</p>
<p>Scrum also requires a higher level of risk tolerance from the client/investor, as the exact costs and timeframe for creating the product are not precisely defined before the start of a project.</p>
<h3>Conclusion:</h3>
<p>Not every project is obligated to be processed using agile methods. Tasks with a complexity level ranging from simple to complicated can be successfully addressed with traditional planning and execution.</p>
<p>The digital transformation poses challenges for organizations but also offers the opportunity to undergo a cultural shift towards an agile organization alongside adopting new technologies. Most external IT service providers and some internal IT departments already work with agile methods. However, the full potential of agile methods can only be realized if the entire process of developing and implementing a new product embraces agile methods—not just the part handled by IT.</p>
<p>Organizations cannot switch to agile overnight; it is a maturation process. Employees and managers need time to develop trust in agile methods and gain practical experience and confidence in their application. In this process, they can be initially supported by an external consultant experienced in the application of agile methods.</p>
<p>If you wish to leverage my experience, I look forward to your contact.<span style="font-size: 14px;"> </span></p></div>
			</div><div class="et_pb_button_module_wrapper et_pb_button_2_wrapper et_pb_button_alignment_center et_pb_module ">
				<a class="et_pb_button et_pb_button_2 et_pb_bg_layout_light" href="/#Kontakt">Contact me now</a>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div></p>
<p>Der Beitrag <a href="https://www.strategieskipper.de/traditionell-vs-agil/">Organisationen: Traditionell vs. Agil</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Das Wirtschaftswunder für Ideen in der eigenen Organisation</title>
		<link>https://www.strategieskipper.de/das-wirtschaftswunder-fuer-ideen-in-der-eigenen-organisation/</link>
		
		<dc:creator><![CDATA[Jens Spaniel]]></dc:creator>
		<pubDate>Thu, 27 Mar 2014 21:17:00 +0000</pubDate>
				<category><![CDATA[Allgemein]]></category>
		<category><![CDATA[Ideen/Konzepte]]></category>
		<category><![CDATA[Marktplatz der Verbesserung]]></category>
		<guid isPermaLink="false">http://www.strategieskipper.de/wordpress/?p=4112</guid>

					<description><![CDATA[<p>Der Beitrag <a href="https://www.strategieskipper.de/das-wirtschaftswunder-fuer-ideen-in-der-eigenen-organisation/">Das Wirtschaftswunder für Ideen in der eigenen Organisation</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></description>
										<content:encoded><![CDATA[<div class="et_pb_section et_pb_section_3 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_22">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_31  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_31  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><h2>Das Wirtschaftswunder der 50er-Jahre</h2>
<p>Die wenigsten von uns waren Zeitzeugen, aber wir haben es im Geschichtsunterricht oder später im Rahmen der Volkswirtschafslehre gelehrt bekommen: das Wirtschaftswunder unter der Regie von Ludwig Erhard. Unter <a href="http://www.wirtschaftswundermuseum.de/">www.wirtschaftswundermuseum.de</a> gibt es sogar ein virtuelles Museum, das eine Reihe der für diese Zeit typischen Werbemotive zeigt und so die Stimmung jener Zeit einfängt.</p>
<p>Die Grundlagen für diesen Aufschwung legte Erhard als einer der Vordenker der Währungsreform vom 20. Juni 1948. Der Erfolg der Währungsreform gründete auf verschiedenen Faktoren. Da war zum einen der psychologische Effekt neues Geld in den Händen zu halten. Das konnte dann auch wirklich jeder anfassen, denn jeder Bürger bekam 40 DM ausgezahlt, das sogenannte Kopfgeld. Ein wesentlicher Faktor war jedoch eine mutige Entscheidung Erhards: die Zwangsbewirtschaftung und die Preisbindungen für einen Teil der industriellen Fertigprodukte wurde mit der Währungsreform aufgehoben.</p>
<p>Das war nicht ohne Risiken und tatsächlich stiegen die Preise danach, konnten aber schließlich durch eine kluge Geldmarktpolitik der Zentralbank stabilisiert werden. Die positiven Effekte wurden jedoch sofort sichtbar: über Nacht waren die Schaufenster plötzlich wieder gefüllt. Was bis dahin nur mit viel Glück auf dem Schwarzmarkt zu erhalten war, konnte man geregelt und legal gegen das neue Geld tauschen. Und die freien Preise waren für die Produzenten nun auch Anreiz, die Produktion zu erhöhen. Mit steigender Kaufkraft war es dann auch interessant, neue Produkte auf den Markt zu bringen, d. h. in Forschung und Entwicklung zu investieren. Der Innovationsgeist war angefacht, &#8222;Made in Germany&#8220; wurde zu einer Qualitätsaussage und das Wirtschaftswunder nahm seinen Lauf.</p>
<h2>Das Wirtschaftswunder in der eigenen Organisation</h2>
<p>Dieser kleine Rückblick soll der Einstieg in die Fortsetzung zu meiner <a href="/category/marktplatz-der-verbesserung/">Blog-Artikelreihe</a> über den &#8222;Marktplatz der Verbesserung&#8220; gewesen sein. Darin stelle ich ein Konzept vor, wie Organisationen Mechanismen eines Marktplatzes nutzen können, um passende Lösungen für Anforderungen zu finden und die Innovationskraft der eigenen Mitarbeiter zu stärken.</p>
<p>Mein letzter Artikel lies die Frage offen: Wie bekommt man diesen Marktplatz in Gang? Von Erhard können wir hier einiges abschauen. Darüber hinaus gibt es in der Kommunalpolitik einige Ansätze, denen man sich bedienen kann. Und nicht zuletzt zeigen auch erfolgreiche Plattformen für Innovationsmanagement spannende Möglichkeiten. So kann man sich Inspiration verschaffen, welche Konzepte und Methoden am besten für die eigene Organisation geeignet sind.</p>
<h2>Erhard – die Ikone</h2>
<p>Eine Bewegung braucht ein Gesicht. Ludwig Erhard war das Gesicht des Wirtschaftswunders. Er wusste, dass er die Massen für seine Vision der sozialen Marktwirtschaft gewinnen musste. Dies gelang ihm als Autor seines Buches &#8222;Wohlstand für alle&#8220;, das er in der Sprache des kleinen Mannes verfasste.</p>
<p><img decoding="async" src="/wp-content/uploads/2017/12/032714_0900_DasWirtscha1.jpg" alt="" data-themekey="#" /></p>
<p>Quelle: Bundesarchiv, B 145 Bild-F004204-0003 / Adrian, Doris / CC-BY-SA</p>
<p>Was für das Wirtschaftswunder gut war, funktioniert auch, um den Enthusiasmus der eigenen Mitarbeiter zu entfesseln und die Identifikation mit dem eigenen Unternehmen zu steigern: auch hier braucht es ein Gesicht. Die Kampagne der Einführung eines Marktplatzes der Verbesserung braucht ein Gesicht und zwar eines, dem die Mitarbeiter zutrauen, dass diese Person kraft seiner Ausstrahlung, Kompetenz und Position bzw. Macht im Unternehmen diese Kampagne auch zum Erfolg führen kann. Und diese Person sollte die Idee seinen Mitarbeitern in einer Sprache vermitteln, die sie verstehen. So können sie den Nutzen erkennen und lassen sich davon anstecken, mitzumachen.</p>
<p>OK, so einleuchtend diese Forderung klingen mag, so schwer wird sie in der Praxis umzusetzen sein. Das Top Management hat viel zu tun, zu viel, um jetzt auch noch als Community Manager tätig zu werden. Anfänglich wird der auserkorene Manager – das Gesicht des Marktplatzes der Verbesserung – durch persönliche Präsenz die Mitarbeiter von der Idee überzeugen müssen. Nach diesem Anfang wird er auch weiterhin zeigen müssen, dass er sich für den Marktplatz interessiert und ihn unterstützt. Dazu kann er dann auch eine Assistenz als Community Manager einspannen. Diese schreibt dann im firmeninternen Blog in seinem Namen. Alternativ kann sie in eigenem Namen schreiben und das Management kommentiert dann regelmäßig diese Beiträge.</p>
<h2>Von Auswertungen und Metriken</h2>
<p>Wer soziale Netzwerke nutzt kennt das: Likes oder +1 oder ähnliches, womit Nutzer ihr Gefallen an einem Inhalt ausdrücken. Diese Möglichkeiten sollten auch auf einer Plattform genutzt werden, auf dem der Marktplatz der Verbesserung abgebildet wird. Stellt jemand eine Idee, eine Innovation ein, aber niemand liket diesen Beitrag, so ist die Idee möglicherweise nicht klar und verständlich formuliert, so dass man auch den Nutzen nicht erkennen kann. Gleiches gilt, wenn jemand eine Anforderung beschreibt, also der Kaufinteressent an einer Lösung sich auf den Marktplatz der Verbesserung begibt. Kommt auf sein Beitrag keine Resonanz, so kann er nochmals seine Anforderung reflektieren oder sich persönliches Feedback bei Kollegen holen, um dann nochmals an der Anforderungsbeschreibung zu feilen. Wer schon mal versucht hat ein Auto über das Internet zu verkaufen kennt das: bleibt das Interesse aus, stellt man vielleicht noch ein paar weitere coole Bilder des Autos ein, bietet an die Winterreifen mit dazu zu geben oder geht sogar mit dem Preis runter.</p>
<p>Neben dem Liken für einen Beitrag sollte natürlich auch das Kommentieren möglich sein. Das ist ja auch gerade das, was einem realen Wochenmarkt die Atmosphäre verleiht. &#8222;Herr Matt, Ihr Apfelmost von letzter Woche hat wieder genau meinen Geschmack getroffen. Leicht moussierend aber noch süß.&#8220; Über ein solches Feedback freut sich der Mann am Obststand und er belohnt seinen Kunden eventuell mit einem Tipp der Woche oder einem Apfelkuchenrezept seiner Großmutter. Kommentare zu Ideen- oder Anforderungsbeiträgen sogen ebenfalls dafür, dass die Teilnehmer am Ball bleiben, erst Recht wenn die Kommentare &#8222;von Herrn Erhard&#8220; kommen. Kommentare tragen also ganz wesentlich dazu bei, dass auf dem Marktplatz der Verbesserung eine Atmosphäre herrscht, die dazu einlädt, wiederzukommen.</p>
<p>Das ganze Feedbacksystem funktioniert natürlich nur dann richtig gut, wenn die technische Plattform, auf der der Marktplatz der Verbesserung realisiert wird, auch Metriken anbietet, die erkennen lassen, wie groß das Interesse an einem Beitrag ist und wie sich das Interesse über die Zeit streut. Einfache Metriken kennt jeder, der schon mal ein Angebot bei eBay eingestellt hat. Da interessiert man sich dafür, wie viele sich das Angebot bereits angesehen oder gar gemerkt haben.</p>
<h2>Von Bürgergutachten und Planungszellen</h2>
<p>Manchmal mag es vorkommen, dass für eine wirklich wichtige und dringende Anforderung einfach keine Lösung kommen mag – und das, obwohl an der Formulierung der Anforderung bereits gefeilt wurde. Was dann? Hier kann man sich von einem Vorgehen inspirieren lassen, das bereits so manche kommunale Verwaltung erfolgreich genutzt hat, um eine Lösung mit einer breiten Akzeptanz zu finden: die Planungszelle, die ein Bürgergutachten erstellt.</p>
<p>Eine Planungszelle besteht aus bis zu 25 Bürgern. Wesentlich dabei ist, dass diese zufällig aus dem Melderegister ausgewählt werden und dennoch einen repräsentativen Querschnitt der Bürger bilden – Hausfrauen, Rentner, Angestellte, Arbeiter, Unternehmer und das aus möglichst unterschiedlichen Berufsgruppen. Die Gruppe arbeitet dann an vier bis fünf Tagen gemeinsam an einer Problemstellung. Hierzu werden sie anfänglich durch Experten an das Thema herangeführt, die verschiedene bekannte Lösungsvarianten auch kontrovers darstellen. In kleineren Gruppen von fünf Personen erfolgt dann die eigentliche Lösungsfindung. Anfänglich werden die Gruppen eventuell durch einen neutralen Moderator angeleitet, der sich auf die Arbeit mit Planungszellen spezialisiert hat. Um Meinungsführerschaften oder eine Dominanz einzelner Mitglieder entgegenzuwirken, werden die Gruppen nach einiger Zeit neu zusammengesetzt – also ähnlich, wie man es von der Workshopmethode World Café kennt.</p>
<p>Als Ergebnis erstellen die Teams ein Bürgergutachten. Der Auftraggeber ist natürlich an dieses nicht gebunden, kann jedoch bei der Umsetzung der Lösung auf das Bürgergutachten zugreifen oder dieses modifiziert realisieren. In größeren Projekten können mehrere Planungszellen parallel arbeiten, um ein noch repräsentativeres Gutachten zu erhalten.</p>
<p>Während Mitglieder einer Planungszelle vom kommunalen Auftraggeber eine Aufwandsentschädigung erhalten, dürfte sich in einem Unternehmen die Freistellung der ausgewählten Mitarbeiter leichter organisieren lassen. Hier kann man sich für die erste Planungszelle einen erfahrenen Moderator ins Haus holen, er gleich auch einen internen Mitarbeiter schult, der dann künftig Planungszellen moderieren kann. Dadurch, dass Mitarbeiter durch das Management eingeladen werden, an der Planungszelle mitzuwirken, haben sie quasi auch einen offiziellen Auftrag. Sie werden um ihre Meinung gebeten. Das kommt gerade Mitarbeitern zu Gute, die zwar gute Ideen haben aber zu zurückhaltend sind, um diese zu äußern. Andererseits beugt es auch möglichen Neid vor. So manchem wurde bereits vorgeworfen, sich mit einer Idee profilieren zu wollen. Wer aber darum gebeten wurde, an einer Planungszelle mitzuarbeiten, ist von diesem Verdacht aus dem Kollegenkreis befreit.</p>
<h2>Gameplay auf der Arbeit</h2>
<p>So manch einer mag irritiert geschaut haben, als er das erste Mal Gast bei einer Firma war, die Spielkonsolen für die Mitarbeiter aufgestellt hatte. Gameplay scheint förderlich zu sein. Auch für den Marktplatz der Verbesserung können spielerische Methoden zum Einsatz kommen. Das zeigt auch eine aktuelle Roadshow, die die Zeitschrift Wissensmanagement gemeinsam mit MindJet durchführt. Unter dem Motto &#8222;Kreativität mit System: Innovationsmanagement strategisch umsetzen&#8220; wird neben theoretischen Grundlagen auch gezeigt, wie spielerische Elemente eingesetzt werden können, um Mitarbeiter zu begeistern, Ideen beizutragen. Die Roadshow läuft noch bis zum 04.06.2014. Infos, Orte und Termine finden sich <a href="http://www.wissensmanagement.net/events/ansicht/termin/event/termin/kreativitaet_mit_system_innovationsmanagement_strategisch_umsetzen-1/view-list%7cpage_id-331.html?no_cache=1&amp;tx_cal_controller%5byear%5d=2014&amp;tx_cal_controller%5bmonth%5d=03&amp;tx_cal_controller%5bday%5d=27&amp;cHash=92e0895fd053f90a7985f2d9ca61254e">hier</a>.</p>
<p>Wem es nicht möglich sein sollte, die Veranstaltung zu besuchen – mein Blog wird fortgesetzt. Im nächsten Artikel wird es um den Marktplatz der Verbesserung als Spielplatz der Verbesserung gehen.</p></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>
<p>Der Beitrag <a href="https://www.strategieskipper.de/das-wirtschaftswunder-fuer-ideen-in-der-eigenen-organisation/">Das Wirtschaftswunder für Ideen in der eigenen Organisation</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Betriebliches Vorschlagswesen und der Marktplatz der Verbesserung</title>
		<link>https://www.strategieskipper.de/betriebliches-vorschlagswesen-und-der-marktplatz-der-verbesserung/</link>
		
		<dc:creator><![CDATA[Jens Spaniel]]></dc:creator>
		<pubDate>Thu, 27 Feb 2014 21:19:18 +0000</pubDate>
				<category><![CDATA[Allgemein]]></category>
		<category><![CDATA[Ideen/Konzepte]]></category>
		<category><![CDATA[Marktplatz der Verbesserung]]></category>
		<guid isPermaLink="false">http://www.strategieskipper.de/wordpress/?p=4114</guid>

					<description><![CDATA[<p>Der Beitrag <a href="https://www.strategieskipper.de/betriebliches-vorschlagswesen-und-der-marktplatz-der-verbesserung/">Betriebliches Vorschlagswesen und der Marktplatz der Verbesserung</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></description>
										<content:encoded><![CDATA[<div class="et_pb_section et_pb_section_4 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_23">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_32  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_32  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>					Anfang Februar hatte ich in <a href="/der-marktplatz-der-verbesserung/">diesem</a> Blog-Artikel mein Konzept zum <strong>&#8222;Marktplatz der Verbesserung&#8220;</strong> vorgestellt. Seither gab es Feedback und Detailanregungen – auf einiges möchte ich in diesem Artikel eingehen.</p>
<h3>Status Quo: Der kontinuierliche Verbesserungsprozess</h3>
<p>Einige Unternehmen, mit denen ich in den letzten Wochen gesprochen habe, arbeiten derzeit an einem Konzept für ein betriebliches Vorschlagswesen. Die Motivation ist weitgehend ähnlich: Man ist überzeugt vom Nutzen eines kontinuierlichen Verbesserungsprozesses (Stichwort &#8222;Kaizen&#8220;) und möchte die Innovationskraft anregen, das Wissen der eigenen Mitarbeiter nutzen und Vorschläge umsetzen. Mitarbeiter sollen die Möglichkeit haben Vorschläge einzubringen, die ein Gremium begutachtet, bewertet, ggf. prämiert und zur Umsetzung bringt. Neben dem Nutzen für das Unternehmen durch wirkungsvolle Vorschläge, versprechen sich Unternehmen von diesem Konzept auch ein höheres Engagement und eine höhere Identifikation der Mitarbeiter mit dem Unternehmen. Schließlich werden Mitarbeiter direkt an der Gestaltung beteiligt – können also etwas bewegen.</p>
<p>Die Idee an sich hat richtige und gute Ansätze. Wie so oft liegt die Herausforderung in der Realisierung. Hier zeichnen Gespräche mit einigen Unternehmen, die schon seit Längerem ein betriebliches Vorschlagswesen eingeführt haben, ein zweigeteiltes Bild. Einerseits wurden Vorschläge eingebracht und umgesetzt, durch die messbare Verbesserungen erzielt werden konnten. Andererseits hat die Anzahl der Vorschläge mit der Zeit abgenommen. Auch wird beobachtet, dass Vorschläge immer wieder von denselben Mitarbeitern eingebracht werden. Gemessen an der gesamten Belegschaft beteiligt sich ein recht kleiner Anteil der Mitarbeiter. Mitunter kommt es bei der Bekanntgabe von Prämierungen hinter vorgehaltener Hand zu recht menschliche Reaktionen: &#8222;Der schon wieder!&#8220; Auch die Dauer zwischen Idee und Umsetzung wird teilweise als nicht optimal beurteilt. Die Gremien, die die Vorschläge prüfen, kommen teilweise vierteljährlich zusammen. Wird ein Vorschlag angenommen und zur Umsetzung weitergegeben, beginnt häufig erst die eigentliche Arbeit. Mancher Vorschlag bleibt auch in den betrieblichen Mühlen stecken – trotz einer ausgezahlten Prämie. Wie sich das letztendlich auf die Motivation des Vorschlagenden auswirkt liegt auf der Hand.</p>
<h3>Vom Wesen und Charme eines Marktes</h3>
<p>Das Konzept des <em>Marktplatzes der Verbesserung</em> nutzt die Vorteile eines betrieblichen Vorschlagswesens, erweitert dieses Modell aber um Grundsätze eines freien Marktes.</p>
<p>Auf einem Markt treffen Angebot und Nachfrage aufeinander. Optimal geschieht dies bei völliger Markttransparenz, wenn also jeder Anbieter auch jeden Nachfrager sehen kann und umgekehrt. Zwar kommen Anbieter und potentielle Käufer mit eigenen Vorstellungen auf den Markt was Preis und Beschaffenheit eines Gutes angeht, häufig aber ist der Möchtegern-Käufer bereit, seine Erwartungen an die Beschaffenheit und den Preis eines angebotenen Gutes anzupassen. Der Anbieter wiederum wird sein Warenangebot überdenken, wenn er feststellt, dass sich niemand dafür interessiert. Ein guter Verkäufer merkt, was Käufer tatsächlich wünschen. Er wird dann versuchen, entsprechende Waren anzubieten – vorausgesetzt er kann damit gut verdienen. Oder sagen wir es allgemeiner: vorausgesetzt, er hat etwas davon.</p>
<p>Diese Anpassung, dieses Angleichen von Angebot und Nachfrage, kommt nicht von selbst. Sie findet in einem Prozess statt, den viele besonders mögen: dem Handeln und Feilschen. Zwanglose Kommunikationsprozesse sind wesentlich für funktionierende Märkte.</p>
<p>Jetzt gibt es aber auch viele Zeitgenossen, die nicht unbedingt mit der Absicht zu Kaufen oder zu Verkaufen einen Markt besuchen. Ich selbst zähle mich auch dazu. Ich liebe es geradezu, über den Radolfzeller Wochenmarkt zu schlendern – auch ohne Einkaufzettel. Ein prosperierender Markt bietet nämlich nicht nur Güter. Er bietet eine <strong>Atmosphäre</strong>. Er ist ein<strong>Umschlagplatz für Informationen</strong>. Man trifft sich, sieht und wird gesehen. Manche beliebte Märkte versprühen regelrecht einen eigenen Charme. Je entspannter man selbst beim Marktbesuch ist und je weniger man unter Zeitdruck steht, umso angenehmer wird das Erlebnis. Nicht ohne Grund freuen sich viele darauf im Urlaub einen beliebten Markt besuchen zu können.</p>
<h3>Marktplatz vs. betriebliches Vorschlagswesen</h3>
<p>Diese Grundsätze und Erlebnisse eines Marktes haben jetzt nur noch sehr wenig mit den bekannten Modellen eines betrieblichen Vorschlagswesens zu tun. Diesem mangelt es häufig an Transparenz. Die Wirkung ist einseitig: es ist ein Markt der Anbieter. Diese erfahren aber selten, was derzeit tatsächlich nachgefragt wird. Denn wenn Unternehmen nach Lösungen für akute Anforderungen suchen, so wird häufig in dem gleichen keinen Personenkreis nach einer Lösung gesucht. Auch findet selten eine zwanglose Kommunikation zwischen dem Anbieter und dem Nachfrager statt. In vielen Fällen gibt es gar keinen Nachfrager. Es gibt lediglich ein Gremium, das ein Angebot bewertet. Dabei kann es vorkommen, dass auch das Gremium einen potentiellen Käufer einer Idee gar nicht kennt, denn derjenige, der nach einer Lösung für eine Anforderung sucht, mag darüber das Gremium gar nicht informiert haben. Die Schlussfolgerung führt wieder zur Idee des Marktes: dort braucht es kein zwischengeschaltenes Gremium, aber Transparenz, damit Anbieter und Nachfrager zueinander finden können. So erfährt der Anbieter, was genau der Nachfrager braucht und der Nachfrager erfährt, welche Beschaffenheit das angebotene Gut hat. Durch den Handel gleichen sich beide einander an, oder aber der Nachfrager wird auf einen anderen Anbieter aufmerksam, der den Bedarf erkennt und schnell genug ist, ein passendes Angebot zu machen.</p>
<h3>Der Traum vom vollkommenden Markt</h3>
<p>Optimal funktioniert ein Markt wenn er frei und vollkommen ist. Allerdings ist ein freier, vollkommener Markt Illusion – und das gilt auch für einen vollkommenen <em>Marktplatz der Verbesserung</em>. Auf einem vollkommenen Markt sind Anbieter und Nachfrager zahlreich, die angebotenen Güter sind gleich und es herrscht Transparenz. Zumindest die ersten beiden Grundsätze treffen kaum auf einen <em>Marktplatz der Verbesserung</em> zu, selbst bei großen Organisationen. Und die Schaffung von Transparenz dürfte bei der Umsetzung so manchem Bauchschmerzen bereiten. Auch der bekannte Mechanismus, dass Angebot und Nachfrage den Preis regelt, dürfte auf einem <em>Marktplatz der Verbesserung</em> kaum in Gang kommen. Das gilt selbst dann, wenn eine Idee durch einen Käufer ähnlich dem betrieblichen Vorschlagswesen mit einer Prämie belohnt wird. Schließlich sind die Käufer innerhalb eines Unternehmens selten zahlreich und ein Wettbewerb um eine Idee wird nicht stattfinden. Auch ist eine Idee nicht zahlenmäßig begrenzt, dieselbe Idee lässt sich beliebig oft umsetzen, sofern eine Nachfrage besteht. Umgekehrt wird der Markt jedoch in Gang kommen können. Denn eine Anforderung wird das Interesse von mehreren Marktteilnehmern wecken, die sich dann auch mit einer eigenen Lösungsidee melden.</p>
<p>Obwohl kein realer Markt ein vollkommener Markt ist (zumindest kenne ich keinen), nutzen wir alle Märkte. Also spricht ein gewisser Mangel gemessen am Ideal auch nicht gegen einen<em>Marktplatz der Verbesserung</em>. Unvollkommene Märkte unterliegen einer gewissen Regulierung und Aufsicht und genießen auch einen gewissen Schutz, um überhaupt prosperieren zu können. In früheren Jahrhunderten wurde das Marktrecht durch einen Fürsten, häufig durch eine hohe Instanz wie dem König oder gar Kaiser verliehen. Er war auch der Schirmherr des Marktes, gewährte ihm seinen Schutz und er gab auch Regeln und Maßstäbe vor. Nicht selten hatte er sogar das nötige Umfeld einzurichten und eine Infrastruktur aufzubauen. Dabei handelte der Herrscher auch in eigenem Interesse. Gut gehende Märkte warfen nicht nur für Kaufleute Gewinne ab und stellten die Bevölkerung zufrieden. Sie stärkten die Wirtschaft insgesamt und sorgten für höhere Steuereinnahmen.</p>
<h3>Marktgrundsätze angewandt</h3>
<p>Diese Analogie besteht auch für den <em>Marktplatz der Verbesserung</em>. Dieser Markt kann nur funktionieren, wenn das oberste Management das Marktrecht verleiht, den Markt also selbst will. Damit sind auch die Verantwortlichkeiten klar definiert und es ist bestimmt, wer den Markt in Gang zu bringen hat. Und wie auch in früheren Zeiten obliegt es dem obersten Management, das entsprechende Marktumfeld zu schaffen. Dieses Umfeld besteht primär aus drei Säulen:</p>
<ul>
<li>einer angenehmen Markt-Atmosphäre;<br />
diese findet ihre Grundlage in einer angepassten Arbeits- und Führungsphilosophie.</li>
<li>einer Infrastruktur, um den Markt nutzen zu können<br />
d. h. die Bereitstellung entsprechender Werkzeuge, in der Regel innerhalb des Intranets des Unternehmens</li>
<li>Regeln und Maßnahmen, um einen Markt in Gang zu bringen und in Gang zu halten,<br />
also Methoden und Prozesse.</li>
</ul>
<p><img decoding="async" src="/wp-content/uploads/2017/12/022714_1447_Betrieblich1.png" alt="" data-themekey="#" /></p>
<h3>Der Architekt</h3>
<p>Ein König oder Kaiser hat sich in früheren Zeiten nicht selbst darum gekümmert, ein entsprechendes Marktumfeld zu schaffen. Er hat zwar seine Vorstellungen eingebracht und mit Interesse die Entstehung des Umfelds und das spätere Marktgeschehen verfolgt – die Realisierung des Marktes hat er jedoch anderen überlassen. In dieser Rolle sehe ich mich, gewissermaßen als der Architekt eines Marktes, nicht aber als der Bauherr. Der Bauherr ist der CEO, der geschäftsführende Gesellschafter, der Inhaber. Meine Leistung liegt darin, die interne Auseinandersetzung mit der Arbeits- und Führungsphilosophie zu moderieren, damit eine angenehme Markt-Atmosphäre entstehen kann. Ich unterstütze beim Aufbau der Infrastruktur, indem ich meine Erfahrung einbringe, welche Anforderungen an eine geeignete Marktplattform bestehen. Hierfür habe ich begonnen Gespräche mit unterschiedlichen Softwarelösungsanbietern zu führen. Dort, wo bereits ein Intranet lebt, arbeite ich Vorschläge aus, wie dieses erweitert werden kann, um als Marktplattform genutzt werden zu können. Wo gewünscht, übernehme ich für die Implementierung auch das Projektmanagement oder unterstütze den internen Projektmanager. Und nicht zuletzt steuere ich meine Erfahrung zu Methoden und Grundsätzen bei, um individuell auf das Unternehmen angepasste Prozesse, Methoden und Regeln zu entwerfen. Schließlich soll der Markt in Gang kommen und in Gang bleiben.</p>
<p>Damit, wie man den Markt in Gang bekommt und welche Rolle dabei das Stichwort &#8222;Planungszelle&#8220; spielen kann, wird sich mein nächster Blogbeitrag zum <em>Marktplatz der Verbesserung</em> befassen. Für diesen Beitrag freue ich mich auf offenes Feedback, praktisch als erste Übung zu einem Marktplatz.</p></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>
<p>Der Beitrag <a href="https://www.strategieskipper.de/betriebliches-vorschlagswesen-und-der-marktplatz-der-verbesserung/">Betriebliches Vorschlagswesen und der Marktplatz der Verbesserung</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Der Marktplatz der Verbesserung</title>
		<link>https://www.strategieskipper.de/der-marktplatz-der-verbesserung/</link>
		
		<dc:creator><![CDATA[Jens Spaniel]]></dc:creator>
		<pubDate>Wed, 05 Feb 2014 21:21:53 +0000</pubDate>
				<category><![CDATA[Allgemein]]></category>
		<category><![CDATA[Ideen/Konzepte]]></category>
		<category><![CDATA[Marktplatz der Verbesserung]]></category>
		<category><![CDATA[Crowdsourcing]]></category>
		<category><![CDATA[Innovationen]]></category>
		<category><![CDATA[IT Berater]]></category>
		<category><![CDATA[Marktplatz]]></category>
		<category><![CDATA[Schwarmintelligenz]]></category>
		<category><![CDATA[Verbesserung]]></category>
		<guid isPermaLink="false">http://www.strategieskipper.de/wordpress/?p=4118</guid>

					<description><![CDATA[<p>Der Beitrag <a href="https://www.strategieskipper.de/der-marktplatz-der-verbesserung/">Der Marktplatz der Verbesserung</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></description>
										<content:encoded><![CDATA[<div class="et_pb_section et_pb_section_5 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_24">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_33  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_33  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><div class="ms-metadata ms-textSmall"></div>
<div class="ms-blog-postBody">
<div class="ms-rtestate-field" dir="">
<div class="ExternalClass1DD51B34FD624A899E63579F3631D5B8">
<p>Ich hatte durch meine Gespräche der letzten Wochen mit CEOs und CIOs eine Gemeinsamkeit unterschiedlichster Firmen erkennen können – gleich, welche Branche oder welche Unternehmensgröße: Unternehmen müssen sich in einem immer höheren Tempo verbessern. Gerade die CEOs haben dabei das diffuse Gefühl, dass in den Mitarbeitern ihrer Organisation noch ungenutzte Potentiale schlummern. Ich fand es daher bezeichnend, was der neue Microsoft-CEO Nadella in seinem ersten Interview sagte: &#8222;In unseren 130.000 Mitarbeitern steckt riesiges Potenzial, das müssen wir nutzen in einer Umgebung, in der Software immer wichtiger wird.&#8220; (Quelle <a href="http://www.tagesschau.de/wirtschaft/microsoft-nadella102.html">deutsch</a>/<a href="http://video.golem.de/wirtschaft/12395/interview-mit-microsoft-ceo-satya-nadella.html">englisch</a>).</p>
<p>In den letzten Wochen habe ich aufgrund dieser Erkenntnisse begonnen ein Konzept zu entwickeln, das ich den <strong>&#8222;Marktplatz der Verbesserung&#8220;</strong> nenne. Auf einem Marktplatz treffen sich <strong>Käufer</strong> und <strong>Verkäufer</strong> – in einem geregelten Umfeld. Beim Marktplatz der Verbesserung sind die Käufer diejenigen, die Anforderungen haben und eine Lösung suchen. Die Verkäufer sind diejenigen, die Ideen haben, Innovationen und Lösungen.</p>
<p><img decoding="async" src="/wp-content/uploads/2017/12/020514_2201_DerMarktpla1.png" alt="" data-themekey="#" /></p>
<p>Sehr häufig werden in Unternehmen die <strong>Käufer</strong>, die <strong>Anforderer</strong> einer Lösung wahrgenommen – besonders dann, wenn sie aus den oberen Hierarchien stammen. In der Regel suchen die Anforderer dann nach einer Lösung, häufig landen solche Anforderungen dann auch bei der IT oder einem externen Berater.</p>
<p>Weniger wahrgenommen wird das Angebot der <strong>Verkäufer</strong> – was manche heute über ein Innovationsmanagement versuchen zu kanalisieren. Allerdings wird dabei häufig nur eine schmale Bandbreite der Mitarbeiter angesprochen, sofern man kein betriebliches Vorschlagswesen hat.</p>
<p>Durch den <strong>&#8222;Marktplatz der Verbesserung&#8220;</strong> wird im Unternehmen ein <strong>Umfeld </strong>geschaffen, in dem sich <strong>Angebot und Nachfrage</strong> treffen können. Die Mechanismen wirken wie auf einem Markt. Anfänglich dürfte in den meisten Unternehmen die Nachfrage auf dem Markt sichtbar sein, nicht aber das Angebot. Dieses schlummert quasi noch unsichtbar in Köpfen oder Schubladen. Denn viele Mitarbeiter haben zwar Ideen, wurden aber über die Jahre frustriert diese ins Unternehmen auch einzubringen, besonders wenn sie in unteren Hierarchien wirken. Wird aber eine Nachfrage wie auf einem Markt sichtbar, so kann auch eine bislang nicht geäußerte Idee, die als Lösung hierzu passt, ebenfalls sichtbar werden. Kommt dieser Markt in Gang und sehen auch die <strong>Innovatoren</strong>, die <strong>Kreativen</strong>, die <strong>Verkäufer</strong> von Ideen, dass Verbesserungen umgesetzt werden, wird auch das Angebot weiter zunehmen. Dann kann auch der umgekehrte Effekt in Kraft treten: ein sichtbares Angebot, trifft einen über den Markt bummelnden Käufer, der plötzlich eine Einsatzmöglichkeit für das Angebot erkennt.</p>
<p>Das Grundkonzept, das dahinter steht, vereinigt verschiedene Themen. Neben den Mechanismen eines Marktes, kommen Ansätze aus den Disziplinen Änderungsmanagement, Anforderungsmanagement, Innovationsmanagement und Projektmanagement zur Anwendung. Ergänzt wird dies durch die aktuell viel diskutierte <strong>Schwarmintelligenz</strong> bzw. <strong>Crowdsourcing</strong>.</p>
<p>Ich nenne die Umsetzung eines solchen Marktes ein <strong>Horizontprojekt</strong>. Horizontprojekte realisieren ein Umfeld, das auf Anforderungen eingeht, die heute schon in der Ferne zu erkennen sind und strategischer Natur sind. Es wird durch die <strong>oberste Managementebene</strong> initiiert und begleitet. Sie sind diejenigen, die quasi das Marktrecht verleihen und den Verkehr auf dem Markt sicherstellen.</p>
<p>Meine Leistung besteht darin, Unternehmen bei der Schaffung eines Umfelds für einen Markt zu begleiten. Dazu bringe ich Konzepte ein, die auf Führungs- und Arbeitsphilosophie, Methoden und Werkzeuge wirken.</p>
<p>Bei dem was ich hier beschreibe, handelt es sich allerdings nur um die erste Stufe des Horizontprojekts. Denn nachdem eine <strong>Anforderung</strong> eine <strong>Lösung</strong> gefunden hat, kommt die nächste Herausforderung: die <strong>Umsetzung</strong>. Und auch hierzu habe ich bereits ein Konzept, wie dabei der <strong>&#8222;Marktplatz der Verbesserung&#8220;</strong> mitwirken kann. Dazu in einem künftigen Artikel mehr.</p>
<p>Spannend? Interessiert? Dann sollten wir miteinander sprechen.</p>
</div>
</div>
</div></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>
<p>Der Beitrag <a href="https://www.strategieskipper.de/der-marktplatz-der-verbesserung/">Der Marktplatz der Verbesserung</a> erschien zuerst auf <a href="https://www.strategieskipper.de">Jens Spaniel IT-Strategie und Projektcoaching</a>.</p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
