<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="de">
	<id>http://wikiivs.albrechtconsult.com/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Pf%C3%A4hler</id>
	<title>IVS-Wiki - Benutzerbeiträge [de]</title>
	<link rel="self" type="application/atom+xml" href="http://wikiivs.albrechtconsult.com/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Pf%C3%A4hler"/>
	<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=Spezial:Beitr%C3%A4ge/Pf%C3%A4hler"/>
	<updated>2026-07-30T04:01:24Z</updated>
	<subtitle>Benutzerbeiträge</subtitle>
	<generator>MediaWiki 1.34.2</generator>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=Compliance_und_Konformitaet&amp;diff=12762</id>
		<title>Compliance und Konformitaet</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=Compliance_und_Konformitaet&amp;diff=12762"/>
		<updated>2017-12-20T15:48:16Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
= Konformität in TOGAF =&lt;br /&gt;
&lt;br /&gt;
Link zu TOGAF: [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap48.htm http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap48.htm]&lt;br /&gt;
&lt;br /&gt;
TOGAF definiert Begriffe für den Grad der Übereinstimmung mit Architekturvorgaben. Dabei wäre &amp;quot;Konform&amp;quot; ideal und &amp;quot;Compliant&amp;quot; in Ordnung.&lt;br /&gt;
&lt;br /&gt;
Insbesondere führt TOGAF folgende Kriterien an:&lt;br /&gt;
&lt;br /&gt;
*Supports the stated strategy and future directions &lt;br /&gt;
*Adheres to the stated standards (including syntax and semantic rules specified) &lt;br /&gt;
*Provides the stated functionality &lt;br /&gt;
*Adheres to the stated principles; for example: &lt;br /&gt;
*Open wherever possible and appropriate &lt;br /&gt;
*Re-use of component building blocks wherever possible and appropriate &lt;br /&gt;
&lt;br /&gt;
= Die Konformität mit der IVS-Rahmenarchitektur =&lt;br /&gt;
&lt;br /&gt;
Eine reale IVS-Architektur ist dann konform, wenn (Checkliste)&lt;br /&gt;
&lt;br /&gt;
* &lt;br /&gt;
* &lt;br /&gt;
* &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Die Konformität mit der IVS-Referenzarchitektur =&lt;br /&gt;
&lt;br /&gt;
Eine reale IVS-Architektur ist dann konform, wenn (Checkliste)&lt;br /&gt;
&lt;br /&gt;
* &lt;br /&gt;
*&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=Bedeutung_der_Toolunterstuetzung&amp;diff=12761</id>
		<title>Bedeutung der Toolunterstuetzung</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=Bedeutung_der_Toolunterstuetzung&amp;diff=12761"/>
		<updated>2017-12-20T15:45:06Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
= Ein Vorwort zu Tools =&lt;br /&gt;
&lt;br /&gt;
Im Rahmen der IVS-Rahmenarchitektur orientieren sich die Autoren stark an TOGAF, einem Framework für Enterprise Architecture Management (EAM). Für TOGAF und EAM gibt es bereits zahlreiche am Markt verfügbare und teilweise von der Open Group zertifizierte Tools. Eine [[IVS-Architekturwerkzeuge|Auswahl]] ist im Wiki zu finden.&lt;br /&gt;
&lt;br /&gt;
= Arten von Tools =&lt;br /&gt;
&lt;br /&gt;
Im Prinzip können bei den am Markt verfügbaren Tools zwei Arten von Tools unterschieden werden - diese unterscheiden sich in den darstellbaren Artefakten:&lt;br /&gt;
&lt;br /&gt;
*&amp;lt;u&amp;gt;Tools zur Modellierung&amp;lt;/u&amp;gt;: Klarer Fokus auf der Erstellung von graphischen Modellen aller Art. Beispiele: &lt;br /&gt;
**ERM, BPMN 2.0 (Prozessebene) &lt;br /&gt;
**UML (Anwendungs- und Infrastrukturebene) &lt;br /&gt;
**Architmate 3.0 (Modellierungssprache der Open Group, kann universell auf allen Architekturebenen und übergreifend zur Strategiedarstellung, generischen Metamodell Darstellung, etc. eingesetzt werden.)   &lt;br /&gt;
*&amp;lt;u&amp;gt;Tools zu Planungszwecken:&amp;lt;/u&amp;gt; Diese bieten in der Regel strukturiertere Darstellungen. Beispiele: &lt;br /&gt;
**Darstellung von Zusammenhängen (in Form von Matritzen) &lt;br /&gt;
**Meilsensteindarstellung, etc.   &lt;br /&gt;
&lt;br /&gt;
= Mehrwert der Tool-Unterstützung =&lt;br /&gt;
&lt;br /&gt;
Der Einsatz von Tools bringt &amp;lt;u&amp;gt;folgende Vorteile&amp;lt;/u&amp;gt;, die in der Funktionalität der Tools begründet sind.&amp;amp;nbsp; Die wichtigste Funktionalität eines Tools ist aus Sicht der Autoren die zentrale Datenbank bzw. ein zentrales Repository, dies ermöglicht folgendes:&lt;br /&gt;
&lt;br /&gt;
*&amp;lt;u&amp;gt;Wiederverwendung&amp;lt;/u&amp;gt;: Einzelne Bausteine müssen nur einmal angelegt werden und können immer wiederverwendet werden. &lt;br /&gt;
*&amp;lt;u&amp;gt;Keine Doppelarbeit:&amp;lt;/u&amp;gt; Zusammenhänge zwischen Bausteinen müssen nur einmal und in der Regel nur in eine Richtung dokumentiert werden. &lt;br /&gt;
*&amp;lt;u&amp;gt;Flexibler Zugriff auf Informationen:&amp;lt;/u&amp;gt; Die Datenbank bzw. das Repository kann flexibel abgefragt werden, auch zum Zwecke der Entscheidungsunterstützung - nicht vorhergesehene Informationsbedarfe können zum Großteil ad-hoc beantwortet werden. &lt;br /&gt;
*&amp;lt;u&amp;gt;Vereinfachte Modellerstellung:&amp;lt;/u&amp;gt; Mit den Modellierungs-Tools können übersichtliche und korrekte Modelle der Sachverhalte mit geringem Aufwand erzeugt werden. &lt;br /&gt;
*&amp;lt;u&amp;gt;Zusammenhänge darstellbar:&amp;lt;/u&amp;gt; Die ebenenübergreifende Darstellung von Zusammenhängen wird vereinfacht.&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=Governance_Kurzfassung&amp;diff=12760</id>
		<title>Governance Kurzfassung</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=Governance_Kurzfassung&amp;diff=12760"/>
		<updated>2017-12-20T15:33:31Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
Dies ist eine Kurzfassung der Seite [[IVS-Governance]]&lt;br /&gt;
&lt;br /&gt;
Architektur hat immer ganz viel mit Kompromissen und Verhandlungen sowie Kommunikation und Mediation zu tun. Ein erfahrener TOGAF-Berater sagt: &amp;quot;50% des Architektur Managements sind Mediation.&amp;quot; Es ist daher wichtig, Gremien zum Austausch und für Verhandlungen zu haben. Auch müssen die Ergebnisse in Verträgen, Vorgaben, Architekurprinzipien usw. festgehalten werden. Dies fällt in den Bereich der Governance.&lt;br /&gt;
&lt;br /&gt;
Governance allgemein bezeichnet Regeln und Regelungsstrukturen, welche die Zielerreichung sicherstellen.&lt;br /&gt;
&lt;br /&gt;
Im IVS-Kontext ist es zentral, unternehmensübergreifende Gremien aufzubauen, welche Entwicklung und Betrieb von IVS-Diensten verantworten und koordinieren. (z.B. bei Wegfall eines Partners in der Wertschöpfungskette)&lt;br /&gt;
&lt;br /&gt;
Diese Gremien treffen dann grundsätzliche und langfristige Entscheidungen, die in Form von Regeln festgehalten werden. Das Management eines IVS-Dienstes und der zugehörigen Partner sollte verpflichtet werden, sich an diese Regeln zu halten.&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=Warum&amp;diff=12745</id>
		<title>Warum</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=Warum&amp;diff=12745"/>
		<updated>2017-12-20T13:28:37Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
= Warum IVS-Dienste =&lt;br /&gt;
&lt;br /&gt;
Von IVS-Diensten verspricht man sich generell verschiedene Nutzenpotenziale. Sie können z.B. dazu beitragen, Staus oder Emissionen zu reduzieren oder das Reisen für den Reisenden angenehmer und sicherer zu machen. All diese Effekte lassen sich über Kennzahlen erfassen und messen. Grundsätzlich kann jeder IVS-Dienst für sich bestehen und die hier beschreibene IVS-Rahmenarchitektur außer Acht lassen. Die Projektteilnehmer versprechen sich aber besondere Vorteile davon, wenn man den Architekturempfehlungen der Rahmenarchitektur folgt.&lt;br /&gt;
&lt;br /&gt;
= Warum IVS-Architektur im Sinne der Rahmenarchitektur =&lt;br /&gt;
&lt;br /&gt;
Von der IVS-Rahmenarchitektur und der Anwendung der Vorgaben aus der IVS-Rahmenarchitektur auf IVS-Dienste versprechen wir uns folgende Nutzenpotenziale:&lt;br /&gt;
&lt;br /&gt;
*Ganzheitliche Betrachtung der IVS-Pyramide, insbesondere Einbezug der Governance-, Ziel- und Geschäftsebenen. &lt;br /&gt;
*Transparenz über die Zusammenhänge innerhalb der IVS-Pyramide für alle beteiligten Projekteilnehmer &lt;br /&gt;
*Damit verbunden auch eine Komplexitätsreduktion für ein besseres Verständnis (Abstraktion) &lt;br /&gt;
*Reduzierter Implementierungsaufwand durch klare Vorgaben und Spezifikationen, auf denen aufgebaut werden kann (das Rad muss nicht ständig neu erfunden werden) &lt;br /&gt;
*Vereinfachte Herstellung von Interoperbailität auf allen Ebenen durch harmonisierte Architekturen &lt;br /&gt;
*Dadurch einfacher Austausch von IVS-Akteuern in der Praxis möglich und &lt;br /&gt;
*Vereinfachte Wiederverwendung von IVS-Diensten in weiteren Diensten &lt;br /&gt;
*Erprobtes Vorgehensmodell, welches für verschiedene Typen von IVS-Diensten bereits durchdacht und angewendet wurde &lt;br /&gt;
*Laufende Anpassung und Verbesserung der Rahmenarchitektur &lt;br /&gt;
*Bereitstellung eines geminsamen Vokabulars zur Verbesserung der Projektinternen Kommunikation sowie eines klaren Verständnis über die Projektlaufzeit hinaus &lt;br /&gt;
*...&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=Warum&amp;diff=12744</id>
		<title>Warum</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=Warum&amp;diff=12744"/>
		<updated>2017-12-20T13:28:18Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
= Warum IVS-Dienste =&lt;br /&gt;
&lt;br /&gt;
Von IVS-Diensten verspricht man sich generell verschiedene Nutzenpotenziale. Sie können z.B. dazu beitragen, Staus oder Emissionen zu reduzieren oder das Reisen für den Reisenden angenehmer und sicherer zu machen. All diese Effekte lassen sich über Kennzahlen erfassen und messen. Grundsätzlich kann jeder IVS-Dienst für sich bestehen und die hier beschreibene IVS-Rahmenarchitektur außer Acht lassen. Die Projektteilnehmer versprechen sich aber besondere Vorteile davon, wenn man den Architekturempfehlungen der Rahmenarchitektur folgt.&lt;br /&gt;
&lt;br /&gt;
= Warum IVS-Architektur im Sinne der Rahmenarchitektur =&lt;br /&gt;
&lt;br /&gt;
Von der IVS-Rahmenarchitektur und der Anwendung der Vorgaben aus der IVS-Rahmenarchitektur auf IVS-Dienste versprechen wir uns folgende Nutzenpotenziale:&lt;br /&gt;
&lt;br /&gt;
*Ganzheitliche Betrachtung der IVS-Pyramiden, insbesondere Einbezug der Governance-, Ziel- und Geschäftsebenen. &lt;br /&gt;
*Transparenz über die Zusammenhänge innerhalb der IVS-Pyramide für alle beteiligten Projekteilnehmer &lt;br /&gt;
*Damit verbunden auch eine Komplexitätsreduktion für ein besseres Verständnis (Abstraktion) &lt;br /&gt;
*Reduzierter Implementierungsaufwand durch klare Vorgaben und Spezifikationen, auf denen aufgebaut werden kann (das Rad muss nicht ständig neu erfunden werden) &lt;br /&gt;
*Vereinfachte Herstellung von Interoperbailität auf allen Ebenen durch harmonisierte Architekturen &lt;br /&gt;
*Dadurch einfacher Austausch von IVS-Akteuern in der Praxis möglich und &lt;br /&gt;
*Vereinfachte Wiederverwendung von IVS-Diensten in weiteren Diensten &lt;br /&gt;
*Erprobtes Vorgehensmodell, welches für verschiedene Typen von IVS-Diensten bereits durchdacht und angewendet wurde &lt;br /&gt;
*Laufende Anpassung und Verbesserung der Rahmenarchitektur &lt;br /&gt;
*Bereitstellung eines geminsamen Vokabulars zur Verbesserung der Projektinternen Kommunikation sowie eines klaren Verständnis über die Projektlaufzeit hinaus &lt;br /&gt;
*...&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12321</id>
		<title>IVS-Architektur-Vorgehensmodell</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12321"/>
		<updated>2017-12-04T15:25:28Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
&lt;br /&gt;
== Problemstellung ==&lt;br /&gt;
&lt;br /&gt;
Das '''T'''he '''O'''pen '''G'''roup '''A'''rchitecture '''F'''ramework (TOGAF) bietet einen Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen. Als operationelles Framework der Gruppe Government and Agency Frameworks bietet TOGAF mit der Architecture Development Method (ADM) unter anderem auch ein Vorgehensmodell zur Entwicklung von Unternehmensarchitekturen (siehe hier&amp;amp;nbsp;[https://de.wikipedia.org/wiki/TOGAF TOGAF]).&lt;br /&gt;
&lt;br /&gt;
Aufgrund der weltweiten Verbreitung und Anerkennung als &amp;quot;das Modell&amp;quot; für die Entwicklung von Unternehmensarchitekturen eignen sich TOGAF und die ADM sehr gut als konzeptioneller Hintergrund auch für die Entwicklung von IVS-Architekturen. Allerdings ist TOGAF einerseits mehr auf die Entwicklung der Architektur eines einzelnen Unternehmens ausgerichtet und stellt andererseits viele Konzepte für Architekturaspekte bereit, die für IVS und IVS-Dienste keine Bedeutung haben. Für die Entwicklung einer IVS-Architektur, das heißt die Architektur von IVS-Diensten, an denen in der Regel mehrere Institutionen und Unternehmen beteiligt sind, erfolgte deshalb eine Anpassung (Tailoring) des TOGAF-Vorgehensmodells unter drei Gesichtspunkten:&lt;br /&gt;
&lt;br /&gt;
*Entwicklung eines generellen Modells zur Anpassung des TOGAF-Vorgehensmodells an die Aufgaben zur Erstellung einer IVS-Architektur, um dieses für die Entwicklung von IVS-Architekturen nutzen zu können &lt;br /&gt;
*Erarbeitung eines TOGAF basierten Rahmenwerks für die verschiedenen Phasen der IVS-Architekturentwicklung und Darstellung in einem Wiki &lt;br /&gt;
*Entwicklung eines IVS-Architektur-Glossars und -Metamodells &lt;br /&gt;
&lt;br /&gt;
Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der ADM wird diese im Folgenden kurz erläutert.&lt;br /&gt;
&lt;br /&gt;
== TOGAF - ein Überblick ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF ADM-Phasenmodell ===&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAF-ADM.jpg|thumb|right|259x336px|TOGAF ADM]]TOGAF definiert mit der ADM (siehe nebenstehendes Bild) einen Prozess zur Entwicklung von Unternehmensarchitekturen. Im Einzelnen werden mit der ADM folgende Phasen durchlaufen:&amp;lt;ref&amp;gt;Schmid, Daniel (2013): ARCHITEKTURMANAGEMENT MIT TOGAF. Online verfügbar unter http://blog.itil.org/2013/01/allgemein/architekturmanagement-mit-togaf/, zuletzt geprüft am 14.11.2017.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Preliminary Phase (Vorarbeiten) &lt;br /&gt;
:Hier werden die Einbindung zugrundeliegender Modelle geklärt, Modell-Anpassungen definiert sowie wichtige Prinzipien für die Architekturentwicklung festgelegt. &lt;br /&gt;
;Phase A - Architecture Vision (Architekturvision) &lt;br /&gt;
:Hier werden die Ziele der Architekturentwicklung und die daran Beteiligten festgelegt. &lt;br /&gt;
;Phase&amp;amp;nbsp;B - Business Architecture (Geschäftsarchitektur) &lt;br /&gt;
:Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden u.a. Geschäftsprozessmodelle, Use-Case- und Klassendiagramme verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;C - Information and Systems Architectures (Informations- und System-Architektur) &lt;br /&gt;
:Hier werden für die Informations-/Datenarchitektur und für die Anwendungsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Datenmodelle und Anwendungen verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;D - Technology Architecture (Technologiearchitektur) &lt;br /&gt;
:Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die benötigte Technologie für die Ausführung der Anwendungen und der darüber liegenden Prozesse beschrieben. &lt;br /&gt;
;In Phase E - Opportunities and Solutions (Möglichkeiten und Lösungen) &lt;br /&gt;
:Hier werden die Vorhaben festgelegt, welche die Transformation aus der Ist-Situation zum Soll-Zustand durchführen. &lt;br /&gt;
;Phase F - Migration Planning (Migrationsplanung) &lt;br /&gt;
:Hier wird die Überführung von Ist-Zustand in den Soll-Zustand geplant. &lt;br /&gt;
;Phase G - Implementation Governance (Steuerung und Überwachung der Implementierung) &lt;br /&gt;
:Hier wird die Implementierung in den Soll-Zustand überwacht. &lt;br /&gt;
;Phase H - Architecture Change Management (Änderungsmanagement) &lt;br /&gt;
:Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als Grundlage für einen evtl. nächsten Durchlauf des Prozesses dienen. &lt;br /&gt;
;Requirements Management (Anforderungsmanagement) &lt;br /&gt;
:Das Anforderungsmanagement treibt den ADM Prozess kontinuierlich an und steht deshalb im Zentrum des Prozesses.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-ADM Schrittmodell ===&lt;br /&gt;
&lt;br /&gt;
Gemäß TOGAF Version 9.1 ist jede Phase nochmals in einzelne Schritte ('''Steps''') unterteilt, die im TOGAF-Handbuch genau erklärt sind. Damit wird generell ein methodisches und umfassendes Vorgehen bei der Entwicklung einer Unternehmensarchitektur sichergestellt. Ein Beispiel für die '''Vorbereitungsphase''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF-Vorgabe&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 2&lt;br /&gt;
| Betroffene &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Eine Besonderheit ist mit dem Schrittmodell der Phasen B, C und D verbunden (siehe auch [[Hinweise_zu_den_Phasen_B,C_und_D|Hinweise zum TOGAF Schrittmodell der Phasen B, C und D]]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== TOGAF Architecture Deliverables als Ergebnisse (Liefergegenstände) der Architekturarbeit ===&lt;br /&gt;
&lt;br /&gt;
Das Vorgehen in Schritten mündet in sog. '''Architecture Deliverables''' als Ergebnis (Liefergegenstände) der Architekturarbeit. Dabei unterscheidet TOGAF folgende &amp;quot;Architecture Deliverables&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
*'''Artefakte''' (im möglichen Format von Katalogen, Matrizen und Diagrammen) und &lt;br /&gt;
*'''Other Deliverables''' &lt;br /&gt;
&lt;br /&gt;
[[File:Architecture Deliverables.png|thumb|center|300px|Architektur Liefergegenstände]]&lt;br /&gt;
&lt;br /&gt;
Artefakte beschreiben Bausteine ('''Building blocks'''). Das sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. &amp;lt;span style=&amp;quot;font-size:small&amp;quot;&amp;gt;&amp;lt;span style=&amp;quot;font-family: arial, helvetica, sans-serif&amp;quot;&amp;gt;&amp;lt;span style=&amp;quot;line-height: 107%&amp;quot;&amp;gt;TOGAF stellt ein Metamodell bereit, welches die Zuordnung der Bausteine zu verschiedenen Bereichen der Unternehmensarchitektur ermöglicht.&amp;lt;/span&amp;gt;&amp;lt;/span&amp;gt;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, z.B. es&amp;amp;nbsp;werden in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B dann basierend auf den IVS-Rollen Prozesse beschrieben.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFBausteine.png|thumb|center|300px|TOGAF Bausteine]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Unterschied zwischen Artefakten und Deliverables ===&lt;br /&gt;
&lt;br /&gt;
In TOGAF wird zwischen Artefakten und anderen Deliverables unterscheiden. Die Unterscheidung kommt daher, dass Artefakte stets die Architektur an sich beschreiben bzw. die einzelnen Bestandteile der Architektur. Andere Deliverables beschreiben z.B. die Umgebung der Architektur oder die Projektstruktur des Architekturprojekts.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFArtefakte.PNG|thumb|center|300px|Mögliche Artefakte zur Beschreibung einer Architektur nach TOGAF]]&lt;br /&gt;
&lt;br /&gt;
Artefakte sind entweder Kataloge, Matrizen oder Diagramme und bestehen aus den einzelnen Bausteinen.&lt;br /&gt;
&lt;br /&gt;
*Ein Baustein ist z. B. eine einzelne Rolle. Der Rollenkatalog, der alle Rollen auflistet, ist ein mögliches Artefakt. Ein Prozessdiagramm mit Rollen als Swimlanes wäre ein weiteres mögliches Artefakt, das die Bausteine Prozess und Rolle kombiniert. &lt;br /&gt;
*Ein Katalog besteht immer nur aus einem Bausteintyp; Matrizen bestehen typischerweise aus zwei verschiedenen Bausteintypen und Diagramme aus mehreren. &lt;br /&gt;
&lt;br /&gt;
TOGAF sieht eine Vielzahl an Artefakten vor (siehe Abbildung (schwarz-weiß)).&lt;br /&gt;
&lt;br /&gt;
Im Los 1 IVS-Rahmenarchitektur werden sowohl Templates zur Beschreibung einzelner Bausteine als auch Templates für Artefakte entwickelt und für die IVS-Referenzarchitekturen bereitgestellt.&lt;br /&gt;
&lt;br /&gt;
== Das TOGAF-basierte Rahmenwerk für IVS-Architektur ==&lt;br /&gt;
&lt;br /&gt;
=== Tailoring des TOGAF Phasen- und Schrittmodells ===&lt;br /&gt;
&lt;br /&gt;
Um das TOGAF-Modell für jede Phase und jeden einzelnen Schritt an die Anforderung der Entwicklung einer IVS-Architektur anpassen zu können, wurde ein Tailoring-Modell entwickelt, das die Schritt-Tabellen der Phasen um Spalten wie folgt erweitert:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; width=&amp;quot;792&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF&lt;br /&gt;
! Tailoring IVS-Architektur&lt;br /&gt;
! Anleitung&lt;br /&gt;
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables&lt;br /&gt;
! Empfehlung für IVS-Referenzarchitekturen&lt;br /&gt;
! style=&amp;quot;width: 89.55px&amp;quot; | Empfehlung für IVS-Architekturen realer IVS-Dienste&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;Wirkungsbereichs&amp;lt;/u&amp;gt; von IVS-Architektur&lt;br /&gt;
| [[Wirkungsbereichs_der_IVS-Architekturaufgabe|'''Wirkungsbereich von IVS-Architektur''']] &lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Wirkungsbereich_von_IVS-Architektur|Beispiel IVS-Rahmenarchitektur]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 2&lt;br /&gt;
| Identifizierung der betroffenen &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung von IVS-Architektur betroffener &amp;lt;u&amp;gt;Institutionen/Unternehmen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen|'''Von IVS-Architektur betroffene Institutionen/Unternehmen und Rahmenbedingungen''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;Steuerungs- und Unterstützungsframeworks für IVS-Architektur&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Steuerungs- und Unterstützungsframeworks für IVS-Architektur''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;IVS-Architektur-Teams und einer Organisation&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architekturteam|'''Hinweise zur Bildung eines IVS-Architekturteams''']]&lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Meta-Modelle|Modell, Grundlage für Nachvollziehbarkeit]] &lt;br /&gt;
:[[Glossar|Glossar, Grundlage für gemeinsames Verstehen]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;IVS-Architekturprinzipien&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architektur&amp;amp;Geschäftsprinzipien|'''IVS-Architektur-Prinzipien''']]&lt;br /&gt;
&lt;br /&gt;
*[[IVS-Architekturprinzip|Baustein IVS-Architekturprinzip]] &lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Katalog_IVS-Architekturprinzipien|Beispiele für Architekturprinzipien aus dem IKT-Bereich]] &lt;br /&gt;
&lt;br /&gt;
| [[Media:IVS-Architekturprinzip-Katalog_00-00-01.docx|K: IVS-Architekturprinzipien]]&lt;br /&gt;
| K: IVS-Architekturprinzipien für die IVS-Dienstekategorie (geerbt von der IVS-Rahmenarchitektur, erweitert für die IVS-Dienstekategorie)&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | K: IVS-Architekturprinzipien für den spezifischen IVS-Dienst (geerbt von der IVS-Dienstekategorie, erweitert für den spezifischen IVS-Dienst)&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Auswahl und Anpassung von &amp;lt;u&amp;gt;IVS-Architekturframeworks&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Nationale und internationale IVS-Architekturframworks''']]&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;IVS-Architekturwerkzeugen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Architekturwerkzeuge|'''Vorschläge für IVS-Architekturwerkzeuge''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-basierte Rahmenwerk als Ergebnis des Tailorings ===&lt;br /&gt;
&lt;br /&gt;
Ergebnis des Tailorings des TOGAF ADM-Phasenmodells ist am Ende das '''TOGAF-basierte Rahmenwerk für IVS-Architektur'''. Es besteht im Einzelnen aus&lt;br /&gt;
&lt;br /&gt;
*der [[Los1:_UAP1.2_TOGAF_basiertes_Rahmenwerk#Tayloring_des_TOGAF_ADM-Phasenmodells_als_Grundlage_f.C3.BCr_IVS-Architekturarbeit|'''TOGAF ADM-Tailoringmethode für IVS-Architektur''']] sowie die gemäß TOGAF ADM strukturierten Phasen und Schritte zur Entwicklung einer IVS-Architektur (siehe im Wiki-Navigationsbaum Menüpunkt &amp;quot;Phasen und Schritte zur Entwicklung einer IVS-Architektur&amp;quot;) &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Hauptseite_rechts|'''Ablage für Templates für IVS-Architekturbausteine''']] auf der Wiki-Hauptseite rechts, &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Schnellzugriff|'''Ablage für Deliverables eines Architekturprojekts''']] auf der Wiki-Hauptseite links. &lt;br /&gt;
&lt;br /&gt;
=== Phasen und Schritte der IVS-Rahmenarchitektur 1.0 ===&lt;br /&gt;
&lt;br /&gt;
Für die Entwicklung der IVS-Rahmenarchitektur 1.0 wurde der Schwerpunkt auf die Architekturvision, die Geschäfts- und Informationssystemarchitektur gelegt (TOGAF Phasen A bis C).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
TOGAF-ADM.jpg | TOGAF - ADM &lt;br /&gt;
FokusVersion09.png | Fokus IVS-Rahmenarchitektur 1.0&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In der '''TOGAF Phase D''' erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme, aus Hardware, Software und Kommunikationstechnologie. Diese Phase ist eine wichtige Phase für eine IVS-Architektur eines realen IVS-Dienstes. Jeder Akteur, der an einer IVS-Architektur eines realen IVS-Dienstes beteiligt ist, muss sich die Fragen nach der bestmöglichen technologischen Einbettung in die Unternehmensarchitektur seines Wirkungsbereichs stellen. Diese Entscheidungen können und sollen weder von der IVS-Rahmenarchitektur noch von einer IVS-Referenzarchitektur getroffen werden.&lt;br /&gt;
&lt;br /&gt;
Für die TOGAF Phasen A bis C enthält die IVS-Rahmenarchitektur Vorgaben für die Entwicklung der entsprechenden Phasen der IVS-Referenzarchitekturen. Die IVS-Referenzarchitekturen enthalten wiederum die Beschreibung der Architekturphasen A bis C für die jeweiligen Domänen. Dort werden Vorgaben und Vorschläge für IVS-Architekturen realer IVS-Dienste entwickelt und beschrieben. Von dieser Vorgehensweise wird für die '''TOGAF Phasen E bis H''' abgewichen. Für die IVS-Referenzarchitekturen entfallen diese Phasen vollständig, da keine einheitlichen Vorgaben für IVS-Architekturen realer IVS-Dienste entwickelt werden können. Stattdessen müssen in jedem Projekt, in dem eine IVS-Architektur eines IVS-Dienstes erarbeitet wird, diese Phasen individuell ausgearbeitet werden. Für die IVS-Rahmenarchitektur ändert sich für die Phasen E bis H der Blickwinkel: Anstatt Vorgaben für die IVS-Referenzarchitekturen zu entwickeln, werden diese Phasen zusammengefasst und es wird die Vorgehensweise zur Umsetzung der IVS-Architekturen beschrieben.&lt;br /&gt;
&lt;br /&gt;
Einen Überblick über das Tailoring der Phasen '''Vorbereitung''' sowie&amp;amp;nbsp;'''Phasen A, B und C (C1. und C.2)''' liefern die folgenden Grafiken:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
File:Vorbereitungsphase_00-00-07.png | Vorbereitungsphase&lt;br /&gt;
File:Phase-A_00-00-03.png | Phase A - IVS-Architekturvision&lt;br /&gt;
Datei: Phase-B_00-00-01.png | Phase A - IVS-Geschäftsarchitektur&lt;br /&gt;
Datei: Phase-C-Daten.png | Phase C.1 - IVS-Datenarchitektur&lt;br /&gt;
Datei: Phase-C-Anwendung.png | Phase C.1 - IVS-Anwendungsarchitektur&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Literaturverzeichnis ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12320</id>
		<title>IVS-Architektur-Vorgehensmodell</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12320"/>
		<updated>2017-12-04T15:22:42Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
&lt;br /&gt;
== Problemstellung ==&lt;br /&gt;
&lt;br /&gt;
Das '''T'''he '''O'''pen '''G'''roup '''A'''rchitecture '''F'''ramework (TOGAF) bietet einen Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen. Als operationelles Framework der Gruppe Government and Agency Frameworks bietet TOGAF mit der Architecture Development Method (ADM) unter anderem auch ein Vorgehensmodell zur Entwicklung von Unternehmensarchitekturen (siehe hier&amp;amp;nbsp;[https://de.wikipedia.org/wiki/TOGAF TOGAF]).&lt;br /&gt;
&lt;br /&gt;
Aufgrund der weltweiten Verbreitung und Anerkennung als &amp;quot;das Modell&amp;quot; für die Entwicklung von Unternehmensarchitekturen eignen sich TOGAF und die ADM sehr gut als konzeptioneller Hintergrund auch für die Entwicklung von IVS-Architekturen. Allerdings ist TOGAF einerseits mehr auf die Entwicklung der Architektur eines einzelnen Unternehmens ausgerichtet und stellt andererseits viele Konzepte für Architekturaspekte bereit, die für IVS und IVS-Dienste keine Bedeutung haben. Für die Entwicklung einer IVS-Architektur, das heißt die Architektur von IVS-Diensten, an denen in der Regel mehrere Institutionen und Unternehmen beteiligt sind, erfolgte deshalb eine Anpassung (Tailoring) des TOGAF-Vorgehensmodells unter drei Gesichtspunkten:&lt;br /&gt;
&lt;br /&gt;
*Entwicklung eines generellen Modells zur Anpassung des TOGAF-Vorgehensmodells an die Aufgaben zur Erstellung einer IVS-Architektur, um dieses für die Entwicklung von IVS-Architekturen nutzen zu können &lt;br /&gt;
*Erarbeitung eines TOGAF basierten Rahmenwerks für die verschiedenen Phasen der IVS-Architekturentwicklung und Darstellung in einem Wiki &lt;br /&gt;
*Entwicklung eines IVS-Architektur-Glossars und -Metamodells &lt;br /&gt;
&lt;br /&gt;
Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der ADM wird diese im Folgenden kurz erläutert.&lt;br /&gt;
&lt;br /&gt;
== TOGAF - ein Überblick ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF ADM-Phasenmodell ===&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAF-ADM.jpg|thumb|right|259x336px|TOGAF ADM]]TOGAF definiert mit der ADM (siehe nebenstehendes Bild) einen Prozess zur Entwicklung von Unternehmensarchitekturen. Im Einzelnen werden mit der ADM folgende Phasen durchlaufen:&amp;lt;ref&amp;gt;Schmid, Daniel (2013): ARCHITEKTURMANAGEMENT MIT TOGAF. Online verfügbar unter http://blog.itil.org/2013/01/allgemein/architekturmanagement-mit-togaf/, zuletzt geprüft am 14.11.2017.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Preliminary Phase (Vorarbeiten) &lt;br /&gt;
:Hier werden die Einbindung zugrundeliegender Modelle geklärt, Modell-Anpassungen definiert sowie wichtige Prinzipien für die Architekturentwicklung festgelegt. &lt;br /&gt;
;Phase A - Architecture Vision (Architekturvision) &lt;br /&gt;
:Hier werden die Ziele der Architekturentwicklung und die daran Beteiligten festgelegt. &lt;br /&gt;
;Phase&amp;amp;nbsp;B - Business Architecture (Geschäftsarchitektur) &lt;br /&gt;
:Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden u.a. Geschäftsprozessmodelle, Use-Case- und Klassendiagramme verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;C - Information and Systems Architectures (Informations- und System-Architektur) &lt;br /&gt;
:Hier werden für die Informations-/Datenarchitektur und für die Anwendungsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Datenmodelle und Anwendungen verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;D - Technology Architecture (Technologiearchitektur) &lt;br /&gt;
:Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die benötigte Technologie für die Ausführung der Anwendungen und der darüber liegenden Prozesse beschrieben. &lt;br /&gt;
;In Phase E - Opportunities and Solutions (Möglichkeiten und Lösungen) &lt;br /&gt;
:Hier werden die Vorhaben festgelegt, welche die Transformation aus der Ist-Situation zum Soll-Zustand durchführen. &lt;br /&gt;
;Phase F - Migration Planning (Migrationsplanung) &lt;br /&gt;
:Hier wird die Überführung von Ist-Zustand in den Soll-Zustand geplant. &lt;br /&gt;
;Phase G - Implementation Governance (Steuerung und Überwachung der Implementierung) &lt;br /&gt;
:Hier wird die Implementierung in den Soll-Zustand überwacht. &lt;br /&gt;
;Phase H - Architecture Change Management (Änderungsmanagement) &lt;br /&gt;
:Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als Grundlage für einen evtl. nächsten Durchlauf des Prozesses dienen. &lt;br /&gt;
;Requirements Management (Anforderungsmanagement) &lt;br /&gt;
:Das Anforderungsmanagement treibt den ADM Prozess kontinuierlich an und steht deshalb im Zentrum des Prozesses.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-ADM Schrittmodell ===&lt;br /&gt;
&lt;br /&gt;
Gemäß TOGAF Version 9.1 ist jede Phase nochmals in einzelne Schritte ('''Steps''') unterteilt, die im TOGAF-Handbuch genau erklärt sind. Damit wird generell ein methodisches und umfassendes Vorgehen bei der Entwicklung einer Unternehmensarchitektur sichergestellt. Ein Beispiel für die '''Vorbereitungsphase''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF-Vorgabe&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 2&lt;br /&gt;
| Betroffene &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Eine Besonderheit ist mit dem Schrittmodell der Phasen B, C und D verbunden (siehe auch [[Hinweise_zu_den_Phasen_B,C_und_D|Hinweise zum TOGAF Schrittmodell der Phasen B, C und D]]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== TOGAF Architecture Deliverables als Ergebnisse (Liefergegenstände) der Architekturarbeit ===&lt;br /&gt;
&lt;br /&gt;
Das Vorgehen in Schritten mündet in sog. '''Architecture Deliverables''' als Ergebnis (Liefergegenstände) der Architekturarbeit. Dabei unterscheidet TOGAF folgende &amp;quot;Architecture Deliverables&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
*'''Artefakte''' (im möglichen Format von Katalogen, Matrizen und Diagrammen) und &lt;br /&gt;
*'''Other Deliverables''' &lt;br /&gt;
&lt;br /&gt;
[[File:Architecture Deliverables.png|thumb|center|300px|Architektur Liefergegenstände]]&lt;br /&gt;
&lt;br /&gt;
Artefakte beschreiben Bausteine ('''Building blocks'''). Das sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. &amp;lt;span style=&amp;quot;font-size:small&amp;quot;&amp;gt;&amp;lt;span style=&amp;quot;font-family: arial, helvetica, sans-serif&amp;quot;&amp;gt;&amp;lt;span style=&amp;quot;line-height: 107%&amp;quot;&amp;gt;TOGAF stellt ein Metamodell bereit, welches die Zuordnung der Bausteine zu verschiedenen Bereichen der Unternehmensarchitektur ermöglicht.&amp;lt;/span&amp;gt;&amp;lt;/span&amp;gt;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, z.B. es&amp;amp;nbsp;werden in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B dann basierend auf den IVS-Rollen Prozesse beschrieben.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFBausteine.png|thumb|center|300px|TOGAF Bausteine]]&lt;br /&gt;
&lt;br /&gt;
=== Unterschied zwischen Artefakten und Deliverables ===&lt;br /&gt;
&lt;br /&gt;
Es wird in TOGAF unterschieden zwischen Artefakten und anderen Deliverables. Die Unterscheidung kommt daher, dass Artefakte stets die Architektur an sich beschreiben bzw. die einzelnen Bestandteile der Architektur. Andere Deliverables beschreiben z. B. die Umgebung der Architektur oder die Projektstruktur des Architekturprojekts.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFArtefakte.PNG|thumb|center|300px|Mögliche Artefakte zur Beschreibung einer Architektur nach TOGAF]]&lt;br /&gt;
&lt;br /&gt;
Artefakte sind entweder Kataloge, Matrizen oder Diagramme und bestehen aus den einzelnen Bausteinen.&lt;br /&gt;
&lt;br /&gt;
*Ein Baustein ist z. B. eine einzelne Rolle. Der Rollenkatalog, der alle Rollen auflistet, ist ein mögliches Artefakt. Ein Prozessdiagramm mit Rollen als Swimlanes wäre ein weiteres mögliches Artefakt, das die Bausteine Prozess und Rolle kombiniert. &lt;br /&gt;
*Ein Katalog besteht immer nur aus einem Bausteintyp; Matrizen bestehen typischerweise aus zwei verschiedenen Bausteintypen und Diagramme aus mehreren. &lt;br /&gt;
&lt;br /&gt;
TOGAF sieht eine Vielzahl an Artefakten vor&amp;amp;nbsp; (siehe Abbildung.)&lt;br /&gt;
&lt;br /&gt;
Im Los 1 IVS-Rahmenarchitektur werden sowohl Templates zur Beschreibung einzelner Bausteine als auch Templates für Artefakte entwickelt und für die IVS-Referenzarchitekturen bereitgestellt.&lt;br /&gt;
&lt;br /&gt;
== Das TOGAF-basierte Rahmenwerk für IVS-Architektur ==&lt;br /&gt;
&lt;br /&gt;
=== Tailoring des TOGAF Phasen- und Schrittmodells ===&lt;br /&gt;
&lt;br /&gt;
Um das TOGAF-Modell für jede Phase und jeden einzelnen Schritt an die Anforderung der Entwicklung einer IVS-Architektur anpassen zu können, wurde ein Tailoring-Modell entwickelt, das die Schritt-Tabellen der Phasen um Spalten wie folgt erweitert:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; width=&amp;quot;792&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF&lt;br /&gt;
! Tailoring IVS-Architektur&lt;br /&gt;
! Anleitung&lt;br /&gt;
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables&lt;br /&gt;
! Empfehlung für IVS-Referenzarchitekturen&lt;br /&gt;
! style=&amp;quot;width: 89.55px&amp;quot; | Empfehlung für IVS-Architekturen realer IVS-Dienste&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;Wirkungsbereichs&amp;lt;/u&amp;gt; von IVS-Architektur&lt;br /&gt;
| [[Wirkungsbereichs_der_IVS-Architekturaufgabe|'''Wirkungsbereich von IVS-Architektur''']] &lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Wirkungsbereich_von_IVS-Architektur|Beispiel IVS-Rahmenarchitektur]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 2&lt;br /&gt;
| Identifizierung der betroffenen &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung von IVS-Architektur betroffener &amp;lt;u&amp;gt;Institutionen/Unternehmen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen|'''Von IVS-Architektur betroffene Institutionen/Unternehmen und Rahmenbedingungen''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;Steuerungs- und Unterstützungsframeworks für IVS-Architektur&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Steuerungs- und Unterstützungsframeworks für IVS-Architektur''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;IVS-Architektur-Teams und einer Organisation&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architekturteam|'''Hinweise zur Bildung eines IVS-Architekturteams''']]&lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Meta-Modelle|Modell, Grundlage für Nachvollziehbarkeit]] &lt;br /&gt;
:[[Glossar|Glossar, Grundlage für gemeinsames Verstehen]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;IVS-Architekturprinzipien&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architektur&amp;amp;Geschäftsprinzipien|'''IVS-Architektur-Prinzipien''']]&lt;br /&gt;
&lt;br /&gt;
*[[IVS-Architekturprinzip|Baustein IVS-Architekturprinzip]] &lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Katalog_IVS-Architekturprinzipien|Beispiele für Architekturprinzipien aus dem IKT-Bereich]] &lt;br /&gt;
&lt;br /&gt;
| [[Media:IVS-Architekturprinzip-Katalog_00-00-01.docx|K: IVS-Architekturprinzipien]]&lt;br /&gt;
| K: IVS-Architekturprinzipien für die IVS-Dienstekategorie (geerbt von der IVS-Rahmenarchitektur, erweitert für die IVS-Dienstekategorie)&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | K: IVS-Architekturprinzipien für den spezifischen IVS-Dienst (geerbt von der IVS-Dienstekategorie, erweitert für den spezifischen IVS-Dienst)&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Auswahl und Anpassung von &amp;lt;u&amp;gt;IVS-Architekturframeworks&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Nationale und internationale IVS-Architekturframworks''']]&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;IVS-Architekturwerkzeugen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Architekturwerkzeuge|'''Vorschläge für IVS-Architekturwerkzeuge''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-basierte Rahmenwerk als Ergebnis des Tailorings ===&lt;br /&gt;
&lt;br /&gt;
Ergebnis des Tailorings des TOGAF ADM-Phasenmodells ist am Ende das '''TOGAF-basierte Rahmenwerk für IVS-Architektur'''. Es besteht im Einzelnen aus&lt;br /&gt;
&lt;br /&gt;
*der [[Los1:_UAP1.2_TOGAF_basiertes_Rahmenwerk#Tayloring_des_TOGAF_ADM-Phasenmodells_als_Grundlage_f.C3.BCr_IVS-Architekturarbeit|'''TOGAF ADM-Tailoringmethode für IVS-Architektur''']] sowie die gemäß TOGAF ADM strukturierten Phasen und Schritte zur Entwicklung einer IVS-Architektur (siehe im Wiki-Navigationsbaum Menüpunkt &amp;quot;Phasen und Schritte zur Entwicklung einer IVS-Architektur&amp;quot;) &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Hauptseite_rechts|'''Ablage für Templates für IVS-Architekturbausteine''']] auf der Wiki-Hauptseite rechts, &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Schnellzugriff|'''Ablage für Deliverables eines Architekturprojekts''']] auf der Wiki-Hauptseite links. &lt;br /&gt;
&lt;br /&gt;
=== Phasen und Schritte der IVS-Rahmenarchitektur 1.0 ===&lt;br /&gt;
&lt;br /&gt;
Für die Entwicklung der IVS-Rahmenarchitektur 1.0 wurde der Schwerpunkt auf die Architekturvision, die Geschäfts- und Informationssystemarchitektur gelegt (TOGAF Phasen A bis C).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
TOGAF-ADM.jpg | TOGAF - ADM &lt;br /&gt;
FokusVersion09.png | Fokus IVS-Rahmenarchitektur 1.0&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In der '''TOGAF Phase D''' erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme, aus Hardware, Software und Kommunikationstechnologie. Diese Phase ist eine wichtige Phase für eine IVS-Architektur eines realen IVS-Dienstes. Jeder Akteur, der an einer IVS-Architektur eines realen IVS-Dienstes beteiligt ist, muss sich die Fragen nach der bestmöglichen technologischen Einbettung in die Unternehmensarchitektur seines Wirkungsbereichs stellen. Diese Entscheidungen können und sollen weder von der IVS-Rahmenarchitektur noch von einer IVS-Referenzarchitektur getroffen werden.&lt;br /&gt;
&lt;br /&gt;
Für die TOGAF Phasen A bis C enthält die IVS-Rahmenarchitektur Vorgaben für die Entwicklung der entsprechenden Phasen der IVS-Referenzarchitekturen. Die IVS-Referenzarchitekturen enthalten wiederum die Beschreibung der Architekturphasen A bis C für die jeweiligen Domänen. Dort werden Vorgaben und Vorschläge für IVS-Architekturen realer IVS-Dienste entwickelt und beschrieben. Von dieser Vorgehensweise wird für die '''TOGAF Phasen E bis H''' abgewichen. Für die IVS-Referenzarchitekturen entfallen diese Phasen vollständig, da keine einheitlichen Vorgaben für IVS-Architekturen realer IVS-Dienste entwickelt werden können. Stattdessen müssen in jedem Projekt, in dem eine IVS-Architektur eines IVS-Dienstes erarbeitet wird, diese Phasen individuell ausgearbeitet werden. Für die IVS-Rahmenarchitektur ändert sich für die Phasen E bis H der Blickwinkel: Anstatt Vorgaben für die IVS-Referenzarchitekturen zu entwickeln, werden diese Phasen zusammengefasst und es wird die Vorgehensweise zur Umsetzung der IVS-Architekturen beschrieben.&lt;br /&gt;
&lt;br /&gt;
Einen Überblick über das Tailoring der Phasen '''Vorbereitung''' sowie&amp;amp;nbsp;'''Phasen A, B und C (C1. und C.2)''' liefern die folgenden Grafiken:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
File:Vorbereitungsphase_00-00-07.png | Vorbereitungsphase&lt;br /&gt;
File:Phase-A_00-00-03.png | Phase A - IVS-Architekturvision&lt;br /&gt;
Datei: Phase-B_00-00-01.png | Phase A - IVS-Geschäftsarchitektur&lt;br /&gt;
Datei: Phase-C-Daten.png | Phase C.1 - IVS-Datenarchitektur&lt;br /&gt;
Datei: Phase-C-Anwendung.png | Phase C.1 - IVS-Anwendungsarchitektur&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Literaturverzeichnis ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12319</id>
		<title>IVS-Architektur-Vorgehensmodell</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12319"/>
		<updated>2017-12-04T15:18:26Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
&lt;br /&gt;
== Problemstellung ==&lt;br /&gt;
&lt;br /&gt;
Das '''T'''he '''O'''pen '''G'''roup '''A'''rchitecture '''F'''ramework (TOGAF) bietet einen Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen. Als operationelles Framework der Gruppe Government and Agency Frameworks bietet TOGAF mit der Architecture Development Method (ADM) unter anderem auch ein Vorgehensmodell zur Entwicklung von Unternehmensarchitekturen (siehe hier&amp;amp;nbsp;[https://de.wikipedia.org/wiki/TOGAF TOGAF]).&lt;br /&gt;
&lt;br /&gt;
Aufgrund der weltweiten Verbreitung und Anerkennung als &amp;quot;das Modell&amp;quot; für die Entwicklung von Unternehmensarchitekturen eignen sich TOGAF und die ADM sehr gut als konzeptioneller Hintergrund auch für die Entwicklung von IVS-Architekturen. Allerdings ist TOGAF einerseits mehr auf die Entwicklung der Architektur eines einzelnen Unternehmens ausgerichtet und stellt andererseits viele Konzepte für Architekturaspekte bereit, die für IVS und IVS-Dienste keine Bedeutung haben. Für die Entwicklung einer IVS-Architektur, das heißt die Architektur von IVS-Diensten, an denen in der Regel mehrere Institutionen und Unternehmen beteiligt sind, erfolgte deshalb eine Anpassung (Tailoring) des TOGAF-Vorgehensmodells unter drei Gesichtspunkten:&lt;br /&gt;
&lt;br /&gt;
*Entwicklung eines generellen Modells zur Anpassung des TOGAF-Vorgehensmodells an die Aufgaben zur Erstellung einer IVS-Architektur, um dieses für die Entwicklung von IVS-Architekturen nutzen zu können &lt;br /&gt;
*Erarbeitung eines TOGAF basierten Rahmenwerks für die verschiedenen Phasen der IVS-Architekturentwicklung und Darstellung in einem Wiki &lt;br /&gt;
*Entwicklung eines IVS-Architektur-Glossars und -Metamodells &lt;br /&gt;
&lt;br /&gt;
Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der ADM wird diese im Folgenden kurz erläutert.&lt;br /&gt;
&lt;br /&gt;
== TOGAF - ein Überblick ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF ADM-Phasenmodell ===&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAF-ADM.jpg|thumb|right|259x336px|TOGAF ADM]]TOGAF definiert mit der ADM (siehe nebenstehendes Bild) einen Prozess zur Entwicklung von Unternehmensarchitekturen. Im Einzelnen werden mit der ADM folgende Phasen durchlaufen:&amp;lt;ref&amp;gt;Schmid, Daniel (2013): ARCHITEKTURMANAGEMENT MIT TOGAF. Online verfügbar unter http://blog.itil.org/2013/01/allgemein/architekturmanagement-mit-togaf/, zuletzt geprüft am 14.11.2017.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Preliminary Phase (Vorarbeiten) &lt;br /&gt;
:Hier werden die Einbindung zugrundeliegender Modelle geklärt, Modell-Anpassungen definiert sowie wichtige Prinzipien für die Architekturentwicklung festgelegt. &lt;br /&gt;
;Phase A - Architecture Vision (Architekturvision) &lt;br /&gt;
:Hier werden die Ziele der Architekturentwicklung und die daran Beteiligten festgelegt. &lt;br /&gt;
;Phase&amp;amp;nbsp;B - Business Architecture (Geschäftsarchitektur) &lt;br /&gt;
:Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden u.a. Geschäftsprozessmodelle, Use-Case- und Klassendiagramme verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;C - Information and Systems Architectures (Informations- und System-Architektur) &lt;br /&gt;
:Hier werden für die Informations-/Datenarchitektur und für die Anwendungsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Datenmodelle und Anwendungen verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;D - Technology Architecture (Technologiearchitektur) &lt;br /&gt;
:Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die benötigte Technologie für die Ausführung der Anwendungen und der darüber liegenden Prozesse beschrieben. &lt;br /&gt;
;In Phase E - Opportunities and Solutions (Möglichkeiten und Lösungen) &lt;br /&gt;
:Hier werden die Vorhaben festgelegt, welche die Transformation aus der Ist-Situation zum Soll-Zustand durchführen. &lt;br /&gt;
;Phase F - Migration Planning (Migrationsplanung) &lt;br /&gt;
:Hier wird die Überführung von Ist-Zustand in den Soll-Zustand geplant. &lt;br /&gt;
;Phase G - Implementation Governance (Steuerung und Überwachung der Implementierung) &lt;br /&gt;
:Hier wird die Implementierung in den Soll-Zustand überwacht. &lt;br /&gt;
;Phase H - Architecture Change Management (Änderungsmanagement) &lt;br /&gt;
:Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als Grundlage für einen evtl. nächsten Durchlauf des Prozesses dienen. &lt;br /&gt;
;Requirements Management (Anforderungsmanagement) &lt;br /&gt;
:Das Anforderungsmanagement treibt den ADM Prozess kontinuierlich an und steht deshalb im Zentrum des Prozesses.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-ADM Schrittmodell ===&lt;br /&gt;
&lt;br /&gt;
Gemäß TOGAF Version 9.1 ist jede Phase nochmals in einzelne Schritte ('''Steps''') unterteilt, die im TOGAF-Handbuch genau erklärt sind. Damit wird generell ein methodisches und umfassendes Vorgehen bei der Entwicklung einer Unternehmensarchitektur sichergestellt. Ein Beispiel für die '''Vorbereitungsphase''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF-Vorgabe&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 2&lt;br /&gt;
| Betroffene &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Eine Besonderheit ist mit dem Schrittmodell der Phasen B, C und D verbunden (siehe auch [[Hinweise_zu_den_Phasen_B,C_und_D|Hinweise zum TOGAF Schrittmodell der Phasen B, C und D]]).&lt;br /&gt;
&lt;br /&gt;
=== TOGAF Architecture Deliverables als Ergebnisse (Liefergegenstände) der Architekturarbeit ===&lt;br /&gt;
&lt;br /&gt;
Das Vorgehen in Schritten mündet in sog. '''Architecture Deliverables''' als Ergebnis (Liefergegenstände) der Architekturarbeit. Dabei unterscheidet TOGAF folgende &amp;quot;Architecture Deliverables&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
*'''Artefakte''' (im möglichen Format von Katalogen, Matrizen und Diagrammen) und &lt;br /&gt;
*'''Other Deliverables''' &lt;br /&gt;
&lt;br /&gt;
[[File:Architecture Deliverables.png|thumb|center|300px|Architektur Liefergegenstände]]&lt;br /&gt;
&lt;br /&gt;
Artefakte beschreiben Bausteine ('''Building blocks'''). Dass sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. TOGAF ordnet Bausteine in verschiedene Ebenen ein.&lt;br /&gt;
&lt;br /&gt;
Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, z. B. es&amp;amp;nbsp;werden in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B werden basierend auf diesen Rollen dann Prozesse beschrieben.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFBausteine.png|thumb|center|300px|TOGAF Bausteine]]&lt;br /&gt;
&lt;br /&gt;
=== Unterschied zwischen Artefakten und Deliverables ===&lt;br /&gt;
&lt;br /&gt;
Es wird in TOGAF unterschieden zwischen Artefakten und anderen Deliverables. Die Unterscheidung kommt daher, dass Artefakte stets die Architektur an sich beschreiben bzw. die einzelnen Bestandteile der Architektur. Andere Deliverables beschreiben z. B. die Umgebung der Architektur oder die Projektstruktur des Architekturprojekts.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFArtefakte.PNG|thumb|center|300px|Mögliche Artefakte zur Beschreibung einer Architektur nach TOGAF]]&lt;br /&gt;
&lt;br /&gt;
Artefakte sind entweder Kataloge, Matrizen oder Diagramme und bestehen aus den einzelnen Bausteinen.&lt;br /&gt;
&lt;br /&gt;
*Ein Baustein ist z. B. eine einzelne Rolle. Der Rollenkatalog, der alle Rollen auflistet, ist ein mögliches Artefakt. Ein Prozessdiagramm mit Rollen als Swimlanes wäre ein weiteres mögliches Artefakt, das die Bausteine Prozess und Rolle kombiniert. &lt;br /&gt;
*Ein Katalog besteht immer nur aus einem Bausteintyp; Matrizen bestehen typischerweise aus zwei verschiedenen Bausteintypen und Diagramme aus mehreren. &lt;br /&gt;
&lt;br /&gt;
TOGAF sieht eine Vielzahl an Artefakten vor&amp;amp;nbsp; (siehe Abbildung.)&lt;br /&gt;
&lt;br /&gt;
Im Los 1 IVS-Rahmenarchitektur werden sowohl Templates zur Beschreibung einzelner Bausteine als auch Templates für Artefakte entwickelt und für die IVS-Referenzarchitekturen bereitgestellt.&lt;br /&gt;
&lt;br /&gt;
== Das TOGAF-basierte Rahmenwerk für IVS-Architektur ==&lt;br /&gt;
&lt;br /&gt;
=== Tailoring des TOGAF Phasen- und Schrittmodells ===&lt;br /&gt;
&lt;br /&gt;
Um das TOGAF-Modell für jede Phase und jeden einzelnen Schritt an die Anforderung der Entwicklung einer IVS-Architektur anpassen zu können, wurde ein Tailoring-Modell entwickelt, das die Schritt-Tabellen der Phasen um Spalten wie folgt erweitert:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; width=&amp;quot;792&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF&lt;br /&gt;
! Tailoring IVS-Architektur&lt;br /&gt;
! Anleitung&lt;br /&gt;
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables&lt;br /&gt;
! Empfehlung für IVS-Referenzarchitekturen&lt;br /&gt;
! style=&amp;quot;width: 89.55px&amp;quot; | Empfehlung für IVS-Architekturen realer IVS-Dienste&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;Wirkungsbereichs&amp;lt;/u&amp;gt; von IVS-Architektur&lt;br /&gt;
| [[Wirkungsbereichs_der_IVS-Architekturaufgabe|'''Wirkungsbereich von IVS-Architektur''']] &lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Wirkungsbereich_von_IVS-Architektur|Beispiel IVS-Rahmenarchitektur]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 2&lt;br /&gt;
| Identifizierung der betroffenen &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung von IVS-Architektur betroffener &amp;lt;u&amp;gt;Institutionen/Unternehmen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen|'''Von IVS-Architektur betroffene Institutionen/Unternehmen und Rahmenbedingungen''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;Steuerungs- und Unterstützungsframeworks für IVS-Architektur&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Steuerungs- und Unterstützungsframeworks für IVS-Architektur''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;IVS-Architektur-Teams und einer Organisation&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architekturteam|'''Hinweise zur Bildung eines IVS-Architekturteams''']]&lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Meta-Modelle|Modell, Grundlage für Nachvollziehbarkeit]] &lt;br /&gt;
:[[Glossar|Glossar, Grundlage für gemeinsames Verstehen]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;IVS-Architekturprinzipien&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architektur&amp;amp;Geschäftsprinzipien|'''IVS-Architektur-Prinzipien''']]&lt;br /&gt;
&lt;br /&gt;
*[[IVS-Architekturprinzip|Baustein IVS-Architekturprinzip]] &lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Katalog_IVS-Architekturprinzipien|Beispiele für Architekturprinzipien aus dem IKT-Bereich]] &lt;br /&gt;
&lt;br /&gt;
| [[Media:IVS-Architekturprinzip-Katalog_00-00-01.docx|K: IVS-Architekturprinzipien]]&lt;br /&gt;
| K: IVS-Architekturprinzipien für die IVS-Dienstekategorie (geerbt von der IVS-Rahmenarchitektur, erweitert für die IVS-Dienstekategorie)&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | K: IVS-Architekturprinzipien für den spezifischen IVS-Dienst (geerbt von der IVS-Dienstekategorie, erweitert für den spezifischen IVS-Dienst)&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Auswahl und Anpassung von &amp;lt;u&amp;gt;IVS-Architekturframeworks&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Nationale und internationale IVS-Architekturframworks''']]&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;IVS-Architekturwerkzeugen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Architekturwerkzeuge|'''Vorschläge für IVS-Architekturwerkzeuge''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-basierte Rahmenwerk als Ergebnis des Tailorings ===&lt;br /&gt;
&lt;br /&gt;
Ergebnis des Tailorings des TOGAF ADM-Phasenmodells ist am Ende das '''TOGAF-basierte Rahmenwerk für IVS-Architektur'''. Es besteht im Einzelnen aus&lt;br /&gt;
&lt;br /&gt;
*der [[Los1:_UAP1.2_TOGAF_basiertes_Rahmenwerk#Tayloring_des_TOGAF_ADM-Phasenmodells_als_Grundlage_f.C3.BCr_IVS-Architekturarbeit|'''TOGAF ADM-Tailoringmethode für IVS-Architektur''']] sowie die gemäß TOGAF ADM strukturierten Phasen und Schritte zur Entwicklung einer IVS-Architektur (siehe im Wiki-Navigationsbaum Menüpunkt &amp;quot;Phasen und Schritte zur Entwicklung einer IVS-Architektur&amp;quot;) &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Hauptseite_rechts|'''Ablage für Templates für IVS-Architekturbausteine''']] auf der Wiki-Hauptseite rechts, &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Schnellzugriff|'''Ablage für Deliverables eines Architekturprojekts''']] auf der Wiki-Hauptseite links. &lt;br /&gt;
&lt;br /&gt;
=== Phasen und Schritte der IVS-Rahmenarchitektur 1.0 ===&lt;br /&gt;
&lt;br /&gt;
Für die Entwicklung der IVS-Rahmenarchitektur 1.0 wurde der Schwerpunkt auf die Architekturvision, die Geschäfts- und Informationssystemarchitektur gelegt (TOGAF Phasen A bis C).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
TOGAF-ADM.jpg | TOGAF - ADM &lt;br /&gt;
FokusVersion09.png | Fokus IVS-Rahmenarchitektur 1.0&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In der '''TOGAF Phase D''' erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme, aus Hardware, Software und Kommunikationstechnologie. Diese Phase ist eine wichtige Phase für eine IVS-Architektur eines realen IVS-Dienstes. Jeder Akteur, der an einer IVS-Architektur eines realen IVS-Dienstes beteiligt ist, muss sich die Fragen nach der bestmöglichen technologischen Einbettung in die Unternehmensarchitektur seines Wirkungsbereichs stellen. Diese Entscheidungen können und sollen weder von der IVS-Rahmenarchitektur noch von einer IVS-Referenzarchitektur getroffen werden.&lt;br /&gt;
&lt;br /&gt;
Für die TOGAF Phasen A bis C enthält die IVS-Rahmenarchitektur Vorgaben für die Entwicklung der entsprechenden Phasen der IVS-Referenzarchitekturen. Die IVS-Referenzarchitekturen enthalten wiederum die Beschreibung der Architekturphasen A bis C für die jeweiligen Domänen. Dort werden Vorgaben und Vorschläge für IVS-Architekturen realer IVS-Dienste entwickelt und beschrieben. Von dieser Vorgehensweise wird für die '''TOGAF Phasen E bis H''' abgewichen. Für die IVS-Referenzarchitekturen entfallen diese Phasen vollständig, da keine einheitlichen Vorgaben für IVS-Architekturen realer IVS-Dienste entwickelt werden können. Stattdessen müssen in jedem Projekt, in dem eine IVS-Architektur eines IVS-Dienstes erarbeitet wird, diese Phasen individuell ausgearbeitet werden. Für die IVS-Rahmenarchitektur ändert sich für die Phasen E bis H der Blickwinkel: Anstatt Vorgaben für die IVS-Referenzarchitekturen zu entwickeln, werden diese Phasen zusammengefasst und es wird die Vorgehensweise zur Umsetzung der IVS-Architekturen beschrieben.&lt;br /&gt;
&lt;br /&gt;
Einen Überblick über das Tailoring der Phasen '''Vorbereitung''' sowie&amp;amp;nbsp;'''Phasen A, B und C (C1. und C.2)''' liefern die folgenden Grafiken:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
File:Vorbereitungsphase_00-00-07.png | Vorbereitungsphase&lt;br /&gt;
File:Phase-A_00-00-03.png | Phase A - IVS-Architekturvision&lt;br /&gt;
Datei: Phase-B_00-00-01.png | Phase A - IVS-Geschäftsarchitektur&lt;br /&gt;
Datei: Phase-C-Daten.png | Phase C.1 - IVS-Datenarchitektur&lt;br /&gt;
Datei: Phase-C-Anwendung.png | Phase C.1 - IVS-Anwendungsarchitektur&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Literaturverzeichnis ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12318</id>
		<title>IVS-Architektur-Vorgehensmodell</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12318"/>
		<updated>2017-12-04T15:16:03Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
&lt;br /&gt;
== Problemstellung ==&lt;br /&gt;
&lt;br /&gt;
Das '''T'''he '''O'''pen '''G'''roup '''A'''rchitecture '''F'''ramework (TOGAF) bietet einen Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen. Als operationelles Framework der Gruppe Government and Agency Frameworks bietet TOGAF mit der Architecture Development Method (ADM) unter anderem auch ein Vorgehensmodell zur Entwicklung von Unternehmensarchitekturen (siehe hier&amp;amp;nbsp;[https://de.wikipedia.org/wiki/TOGAF TOGAF]).&lt;br /&gt;
&lt;br /&gt;
Aufgrund der weltweiten Verbreitung und Anerkennung als &amp;quot;das Modell&amp;quot; für die Entwicklung von Unternehmensarchitekturen eignen sich TOGAF und die ADM sehr gut als konzeptioneller Hintergrund auch für die Entwicklung von IVS-Architekturen. Allerdings ist TOGAF einerseits mehr auf die Entwicklung der Architektur eines einzelnen Unternehmens ausgerichtet und stellt andererseits viele Konzepte für Architekturaspekte bereit, die für IVS und IVS-Dienste keine Bedeutung haben. Für die Entwicklung einer IVS-Architektur, das heißt die Architektur von IVS-Diensten, an denen in der Regel mehrere Institutionen und Unternehmen beteiligt sind, erfolgte deshalb eine Anpassung (Tailoring) des TOGAF-Vorgehensmodells unter drei Gesichtspunkten:&lt;br /&gt;
&lt;br /&gt;
*Entwicklung eines generellen Modells zur Anpassung des TOGAF-Vorgehensmodells an die Aufgaben zur Erstellung einer IVS-Architektur, um dieses für die Entwicklung von IVS-Architekturen nutzen zu können &lt;br /&gt;
*Erarbeitung eines TOGAF basierten Rahmenwerks für die verschiedenen Phasen der IVS-Architekturentwicklung und Darstellung in einem Wiki &lt;br /&gt;
*Entwicklung eines IVS-Architektur-Glossars und -Metamodells &lt;br /&gt;
&lt;br /&gt;
Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der ADM wird diese im Folgenden kurz erläutert.&lt;br /&gt;
&lt;br /&gt;
== TOGAF - ein Überblick ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF ADM-Phasenmodell ===&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAF-ADM.jpg|thumb|right|259x336px|TOGAF ADM]]TOGAF definiert mit der ADM (siehe nebenstehendes Bild) einen Prozess zur Entwicklung von Unternehmensarchitekturen. Im Einzelnen werden mit der ADM folgende Phasen durchlaufen:&amp;lt;ref&amp;gt;Schmid, Daniel (2013): ARCHITEKTURMANAGEMENT MIT TOGAF. Online verfügbar unter http://blog.itil.org/2013/01/allgemein/architekturmanagement-mit-togaf/, zuletzt geprüft am 14.11.2017.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Preliminary Phase (Vorarbeiten) &lt;br /&gt;
:Hier werden die Einbindung zugrundeliegender Modelle geklärt, Modell-Anpassungen definiert sowie wichtige Prinzipien für die Architekturentwicklung festgelegt. &lt;br /&gt;
;Phase A - Architecture Vision (Architekturvision) &lt;br /&gt;
:Hier werden die Ziele der Architekturentwicklung und die daran Beteiligten festgelegt. &lt;br /&gt;
;Phase&amp;amp;nbsp;B - Business Architecture (Geschäftsarchitektur) &lt;br /&gt;
:Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden u.a. Geschäftsprozessmodelle, Use-Case- und Klassendiagramme verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;C - Information and Systems Architectures (Informations- und System-Architektur) &lt;br /&gt;
:Hier werden für die Informations-/Datenarchitektur und für die Anwendungsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Datenmodelle und Anwendungen verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;D - Technology Architecture (Technologiearchitektur) &lt;br /&gt;
:Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die benötigte Technologie für die Ausführung der Anwendungen und der darüber liegenden Prozesse beschrieben. &lt;br /&gt;
;In Phase E - Opportunities and Solutions (Möglichkeiten und Lösungen) &lt;br /&gt;
:Hier werden die Vorhaben festgelegt, welche die Transformation aus der Ist-Situation zum Soll-Zustand durchführen. &lt;br /&gt;
;Phase F - Migration Planning (Migrationsplanung) &lt;br /&gt;
:Hier wird die Überführung von Ist-Zustand in den Soll-Zustand geplant. &lt;br /&gt;
;Phase G - Implementation Governance (Steuerung und Überwachung der Implementierung) &lt;br /&gt;
:Hier wird die Implementierung in den Soll-Zustand überwacht. &lt;br /&gt;
;Phase H - Architecture Change Management (Änderungsmanagement) &lt;br /&gt;
:Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als Grundlage für einen evtl. nächsten Durchlauf des Prozesses dienen. &lt;br /&gt;
;Requirements Management (Anforderungsmanagement) &lt;br /&gt;
:Das Anforderungsmanagement treibt den ADM Prozess kontinuierlich an und steht deshalb im Zentrum des Prozesses.&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-ADM Schrittmodell ===&lt;br /&gt;
&lt;br /&gt;
Gemäß TOGAF Version 9.1 ist jede Phase nochmals in einzelne Schritte ('''Steps''') unterteilt, die im TOGAF-Handbuch genau erklärt sind. Damit wird generell ein methodisches und umfassendes Vorgehen bei der Entwicklung einer Architektur sichergestellt. Ein Beispiel für die '''Vorbereitungsphase''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF-Vorgabe&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 2&lt;br /&gt;
| Betroffene &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Eine Besonderheit ist mit dem Schrittmodell der Phasen B, C und D verbunden (siehe auch [[Hinweise_zu_den_Phasen_B,C_und_D|Hinweise zum TOGAF Schrittmodell der Phasen B, C und D]]).&lt;br /&gt;
&lt;br /&gt;
=== TOGAF Architecture Deliverables als Ergebnisse (Liefergegenstände) der Architekturarbeit ===&lt;br /&gt;
&lt;br /&gt;
Das Vorgehen in Schritten mündet in sog. '''Architecture Deliverables''' als Ergebnis (Liefergegenstände) der Architekturarbeit. Dabei unterscheidet TOGAF folgende &amp;quot;Architecture Deliverables&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
*'''Artefakte''' (im möglichen Format von Katalogen, Matrizen und Diagrammen) und &lt;br /&gt;
*'''Other Deliverables''' &lt;br /&gt;
&lt;br /&gt;
[[File:Architecture Deliverables.png|thumb|center|300px|Architektur Liefergegenstände]]&lt;br /&gt;
&lt;br /&gt;
Artefakte beschreiben Bausteine ('''Building blocks'''). Dass sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. TOGAF ordnet Bausteine in verschiedene Ebenen ein.&lt;br /&gt;
&lt;br /&gt;
Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, z. B. es&amp;amp;nbsp;werden in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B werden basierend auf diesen Rollen dann Prozesse beschrieben.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFBausteine.png|thumb|center|300px|TOGAF Bausteine]]&lt;br /&gt;
&lt;br /&gt;
=== Unterschied zwischen Artefakten und Deliverables ===&lt;br /&gt;
&lt;br /&gt;
Es wird in TOGAF unterschieden zwischen Artefakten und anderen Deliverables. Die Unterscheidung kommt daher, dass Artefakte stets die Architektur an sich beschreiben bzw. die einzelnen Bestandteile der Architektur. Andere Deliverables beschreiben z. B. die Umgebung der Architektur oder die Projektstruktur des Architekturprojekts.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFArtefakte.PNG|thumb|center|300px|Mögliche Artefakte zur Beschreibung einer Architektur nach TOGAF]]&lt;br /&gt;
&lt;br /&gt;
Artefakte sind entweder Kataloge, Matrizen oder Diagramme und bestehen aus den einzelnen Bausteinen.&lt;br /&gt;
&lt;br /&gt;
*Ein Baustein ist z. B. eine einzelne Rolle. Der Rollenkatalog, der alle Rollen auflistet, ist ein mögliches Artefakt. Ein Prozessdiagramm mit Rollen als Swimlanes wäre ein weiteres mögliches Artefakt, das die Bausteine Prozess und Rolle kombiniert. &lt;br /&gt;
*Ein Katalog besteht immer nur aus einem Bausteintyp; Matrizen bestehen typischerweise aus zwei verschiedenen Bausteintypen und Diagramme aus mehreren. &lt;br /&gt;
&lt;br /&gt;
TOGAF sieht eine Vielzahl an Artefakten vor&amp;amp;nbsp; (siehe Abbildung.)&lt;br /&gt;
&lt;br /&gt;
Im Los 1 IVS-Rahmenarchitektur werden sowohl Templates zur Beschreibung einzelner Bausteine als auch Templates für Artefakte entwickelt und für die IVS-Referenzarchitekturen bereitgestellt.&lt;br /&gt;
&lt;br /&gt;
== Das TOGAF-basierte Rahmenwerk für IVS-Architektur ==&lt;br /&gt;
&lt;br /&gt;
=== Tailoring des TOGAF Phasen- und Schrittmodells ===&lt;br /&gt;
&lt;br /&gt;
Um das TOGAF-Modell für jede Phase und jeden einzelnen Schritt an die Anforderung der Entwicklung einer IVS-Architektur anpassen zu können, wurde ein Tailoring-Modell entwickelt, das die Schritt-Tabellen der Phasen um Spalten wie folgt erweitert:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; width=&amp;quot;792&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF&lt;br /&gt;
! Tailoring IVS-Architektur&lt;br /&gt;
! Anleitung&lt;br /&gt;
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables&lt;br /&gt;
! Empfehlung für IVS-Referenzarchitekturen&lt;br /&gt;
! style=&amp;quot;width: 89.55px&amp;quot; | Empfehlung für IVS-Architekturen realer IVS-Dienste&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;Wirkungsbereichs&amp;lt;/u&amp;gt; von IVS-Architektur&lt;br /&gt;
| [[Wirkungsbereichs_der_IVS-Architekturaufgabe|'''Wirkungsbereich von IVS-Architektur''']] &lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Wirkungsbereich_von_IVS-Architektur|Beispiel IVS-Rahmenarchitektur]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 2&lt;br /&gt;
| Identifizierung der betroffenen &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung von IVS-Architektur betroffener &amp;lt;u&amp;gt;Institutionen/Unternehmen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen|'''Von IVS-Architektur betroffene Institutionen/Unternehmen und Rahmenbedingungen''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;Steuerungs- und Unterstützungsframeworks für IVS-Architektur&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Steuerungs- und Unterstützungsframeworks für IVS-Architektur''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;IVS-Architektur-Teams und einer Organisation&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architekturteam|'''Hinweise zur Bildung eines IVS-Architekturteams''']]&lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Meta-Modelle|Modell, Grundlage für Nachvollziehbarkeit]] &lt;br /&gt;
:[[Glossar|Glossar, Grundlage für gemeinsames Verstehen]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;IVS-Architekturprinzipien&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architektur&amp;amp;Geschäftsprinzipien|'''IVS-Architektur-Prinzipien''']]&lt;br /&gt;
&lt;br /&gt;
*[[IVS-Architekturprinzip|Baustein IVS-Architekturprinzip]] &lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Katalog_IVS-Architekturprinzipien|Beispiele für Architekturprinzipien aus dem IKT-Bereich]] &lt;br /&gt;
&lt;br /&gt;
| [[Media:IVS-Architekturprinzip-Katalog_00-00-01.docx|K: IVS-Architekturprinzipien]]&lt;br /&gt;
| K: IVS-Architekturprinzipien für die IVS-Dienstekategorie (geerbt von der IVS-Rahmenarchitektur, erweitert für die IVS-Dienstekategorie)&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | K: IVS-Architekturprinzipien für den spezifischen IVS-Dienst (geerbt von der IVS-Dienstekategorie, erweitert für den spezifischen IVS-Dienst)&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Auswahl und Anpassung von &amp;lt;u&amp;gt;IVS-Architekturframeworks&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Nationale und internationale IVS-Architekturframworks''']]&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;IVS-Architekturwerkzeugen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Architekturwerkzeuge|'''Vorschläge für IVS-Architekturwerkzeuge''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-basierte Rahmenwerk als Ergebnis des Tailorings ===&lt;br /&gt;
&lt;br /&gt;
Ergebnis des Tailorings des TOGAF ADM-Phasenmodells ist am Ende das '''TOGAF-basierte Rahmenwerk für IVS-Architektur'''. Es besteht im Einzelnen aus&lt;br /&gt;
&lt;br /&gt;
*der [[Los1:_UAP1.2_TOGAF_basiertes_Rahmenwerk#Tayloring_des_TOGAF_ADM-Phasenmodells_als_Grundlage_f.C3.BCr_IVS-Architekturarbeit|'''TOGAF ADM-Tailoringmethode für IVS-Architektur''']] sowie die gemäß TOGAF ADM strukturierten Phasen und Schritte zur Entwicklung einer IVS-Architektur (siehe im Wiki-Navigationsbaum Menüpunkt &amp;quot;Phasen und Schritte zur Entwicklung einer IVS-Architektur&amp;quot;) &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Hauptseite_rechts|'''Ablage für Templates für IVS-Architekturbausteine''']] auf der Wiki-Hauptseite rechts, &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Schnellzugriff|'''Ablage für Deliverables eines Architekturprojekts''']] auf der Wiki-Hauptseite links. &lt;br /&gt;
&lt;br /&gt;
=== Phasen und Schritte der IVS-Rahmenarchitektur 1.0 ===&lt;br /&gt;
&lt;br /&gt;
Für die Entwicklung der IVS-Rahmenarchitektur 1.0 wurde der Schwerpunkt auf die Architekturvision, die Geschäfts- und Informationssystemarchitektur gelegt (TOGAF Phasen A bis C).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
TOGAF-ADM.jpg | TOGAF - ADM &lt;br /&gt;
FokusVersion09.png | Fokus IVS-Rahmenarchitektur 1.0&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In der '''TOGAF Phase D''' erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme, aus Hardware, Software und Kommunikationstechnologie. Diese Phase ist eine wichtige Phase für eine IVS-Architektur eines realen IVS-Dienstes. Jeder Akteur, der an einer IVS-Architektur eines realen IVS-Dienstes beteiligt ist, muss sich die Fragen nach der bestmöglichen technologischen Einbettung in die Unternehmensarchitektur seines Wirkungsbereichs stellen. Diese Entscheidungen können und sollen weder von der IVS-Rahmenarchitektur noch von einer IVS-Referenzarchitektur getroffen werden.&lt;br /&gt;
&lt;br /&gt;
Für die TOGAF Phasen A bis C enthält die IVS-Rahmenarchitektur Vorgaben für die Entwicklung der entsprechenden Phasen der IVS-Referenzarchitekturen. Die IVS-Referenzarchitekturen enthalten wiederum die Beschreibung der Architekturphasen A bis C für die jeweiligen Domänen. Dort werden Vorgaben und Vorschläge für IVS-Architekturen realer IVS-Dienste entwickelt und beschrieben. Von dieser Vorgehensweise wird für die '''TOGAF Phasen E bis H''' abgewichen. Für die IVS-Referenzarchitekturen entfallen diese Phasen vollständig, da keine einheitlichen Vorgaben für IVS-Architekturen realer IVS-Dienste entwickelt werden können. Stattdessen müssen in jedem Projekt, in dem eine IVS-Architektur eines IVS-Dienstes erarbeitet wird, diese Phasen individuell ausgearbeitet werden. Für die IVS-Rahmenarchitektur ändert sich für die Phasen E bis H der Blickwinkel: Anstatt Vorgaben für die IVS-Referenzarchitekturen zu entwickeln, werden diese Phasen zusammengefasst und es wird die Vorgehensweise zur Umsetzung der IVS-Architekturen beschrieben.&lt;br /&gt;
&lt;br /&gt;
Einen Überblick über das Tailoring der Phasen '''Vorbereitung''' sowie&amp;amp;nbsp;'''Phasen A, B und C (C1. und C.2)''' liefern die folgenden Grafiken:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
File:Vorbereitungsphase_00-00-07.png | Vorbereitungsphase&lt;br /&gt;
File:Phase-A_00-00-03.png | Phase A - IVS-Architekturvision&lt;br /&gt;
Datei: Phase-B_00-00-01.png | Phase A - IVS-Geschäftsarchitektur&lt;br /&gt;
Datei: Phase-C-Daten.png | Phase C.1 - IVS-Datenarchitektur&lt;br /&gt;
Datei: Phase-C-Anwendung.png | Phase C.1 - IVS-Anwendungsarchitektur&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Literaturverzeichnis ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12317</id>
		<title>IVS-Architektur-Vorgehensmodell</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12317"/>
		<updated>2017-12-04T15:12:01Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
&lt;br /&gt;
== Problemstellung ==&lt;br /&gt;
&lt;br /&gt;
Das '''T'''he '''O'''pen '''G'''roup '''A'''rchitecture '''F'''ramework (TOGAF) bietet einen Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen. Als operationelles Framework der Gruppe Government and Agency Frameworks bietet TOGAF mit der Architecture Development Method (ADM) unter anderem auch ein Vorgehensmodell zur Entwicklung von Unternehmensarchitekturen (siehe hier&amp;amp;nbsp;[https://de.wikipedia.org/wiki/TOGAF TOGAF]).&lt;br /&gt;
&lt;br /&gt;
Aufgrund der weltweiten Verbreitung und Anerkennung als &amp;quot;das Modell&amp;quot; für die Entwicklung von Unternehmensarchitekturen eignen sich TOGAF und die ADM sehr gut als konzeptioneller Hintergrund auch für die Entwicklung von IVS-Architekturen. Allerdings ist TOGAF einerseits mehr auf die Entwicklung der Architektur eines einzelnen Unternehmens ausgerichtet und stellt andererseits viele Konzepte für Architekturaspekte bereit, die für IVS und IVS-Dienste keine Bedeutung haben. Für die Entwicklung einer IVS-Architektur, das heißt die Architektur von IVS-Diensten, an denen in der Regel mehrere Institutionen und Unternehmen beteiligt sind, erfolgte deshalb eine Anpassung (Tailoring) des TOGAF-Vorgehensmodells unter drei Gesichtspunkten:&lt;br /&gt;
&lt;br /&gt;
*Entwicklung eines generellen Modells zur Anpassung des TOGAF-Vorgehensmodells an die Aufgaben zur Erstellung einer IVS-Architektur, um dieses für die Entwicklung von IVS-Architekturen nutzen zu können &lt;br /&gt;
*Erarbeitung eines TOGAF basierten Rahmenwerks für die verschiedenen Phasen der IVS-Architekturentwicklung und Darstellung in einem Wiki &lt;br /&gt;
*Entwicklung eines IVS-Architektur-Glossars und -Metamodells &lt;br /&gt;
&lt;br /&gt;
Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der ADM wird diese im Folgenden kurz erläutert.&lt;br /&gt;
&lt;br /&gt;
== TOGAF - ein Überblick ==&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF ADM-Phasenmodell ===&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAF-ADM.jpg|thumb|right|259x336px|TOGAF ADM]]TOGAF definiert mit der Architecture Development Method (ADM; siehe nebenstehendes Bild) einen Prozess zur Entwicklung von Unternehmensarchitekturen. Im Einzelnen werden mit der ADM folgende Phasen durchlaufen:&amp;lt;ref&amp;gt;Schmid, Daniel (2013): ARCHITEKTURMANAGEMENT MIT TOGAF. Online verfügbar unter http://blog.itil.org/2013/01/allgemein/architekturmanagement-mit-togaf/, zuletzt geprüft am 14.11.2017.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Preliminary Phase (Vorarbeiten) &lt;br /&gt;
:Hier werden die Einbindung zugrundeliegender Modelle geklärt, Modell-Anpassungen definiert sowie wichtige Prinzipien für die Architekturentwicklung festgelegt. &lt;br /&gt;
;Phase A - Architecture Vision (Architekturvision) &lt;br /&gt;
:Hier werden die Ziele der Architekturentwicklung und die daran Beteiligten festgelegt. &lt;br /&gt;
;Phase&amp;amp;nbsp;B - Business Architecture (Geschäftsarchitektur) &lt;br /&gt;
:Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden u.a. Geschäftsprozessmodelle, Use-Case- und Klassendiagramme verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;C - Information and Systems Architectures (Informations- und System-Architektur) &lt;br /&gt;
:Hier werden für die Informations-/Datenarchitektur und für die Anwendungsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Datenmodelle und Anwendungen verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;D - Technology Architecture (Technologiearchitektur) &lt;br /&gt;
:Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die benötigte Technologie für die Ausführung der Anwendungen und der darüberliegenden Prozesse beschrieben. &lt;br /&gt;
;In Phase E - Opportunities and Solutions (Möglichkeiten und Lösungen) &lt;br /&gt;
:Hier werden die Vorhaben festgelegt, welche die Transformation aus der Ist-Situation zum Soll-Zustand durchführen. &lt;br /&gt;
;Phase F - Migration Planning (Migrationsplanung) &lt;br /&gt;
:Hier wird die Überführung von Ist-Zustand in den Soll-Zustand geplant. &lt;br /&gt;
;Phase G - Implementation Governance (Steuerung und Überwachung der Implementierung) &lt;br /&gt;
:Hier wird die Implementierung in den Soll-Zustand überwacht. &lt;br /&gt;
;Phase H - Architecture Change Management (Änderungsmanagement) &lt;br /&gt;
:Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als Grundlage für einen evtl. nächsten Durchlauf des Prozesses dienen. &lt;br /&gt;
;Requirements Management (Anforderungsmanagement) &lt;br /&gt;
:Das Anforderungsmanagement treibt den ADM Prozess kontinuierlich und steht deshalb im Zentrum des Prozesses. &lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-ADM Schrittmodell ===&lt;br /&gt;
&lt;br /&gt;
Gemäß TOGAF Version 9.1 ist jede Phase nochmals in einzelne Schritte ('''Steps''') unterteilt, die im TOGAF-Handbuch genau erklärt sind. Damit wird generell ein methodisches und umfassendes Vorgehen bei der Entwicklung einer Architektur sichergestellt. Ein Beispiel für die '''Vorbereitungsphase''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF-Vorgabe&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 2&lt;br /&gt;
| Betroffene &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Eine Besonderheit ist mit dem Schrittmodell der Phasen B, C und D verbunden (siehe auch [[Hinweise_zu_den_Phasen_B,C_und_D|Hinweise zum TOGAF Schrittmodell der Phasen B, C und D]]).&lt;br /&gt;
&lt;br /&gt;
=== TOGAF Architecture Deliverables als Ergebnisse (Liefergegenstände) der Architekturarbeit ===&lt;br /&gt;
&lt;br /&gt;
Das Vorgehen in Schritten mündet in sog. '''Architecture Deliverables''' als Ergebnis (Liefergegenstände) der Architekturarbeit. Dabei unterscheidet TOGAF folgende &amp;quot;Architecture Deliverables&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
*'''Artefakte''' (im möglichen Format von Katalogen, Matrizen und Diagrammen) und &lt;br /&gt;
*'''Other Deliverables''' &lt;br /&gt;
&lt;br /&gt;
[[File:Architecture Deliverables.png|thumb|center|300px|Architektur Liefergegenstände]]&lt;br /&gt;
&lt;br /&gt;
Artefakte beschreiben Bausteine ('''Building blocks'''). Dass sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. TOGAF ordnet Bausteine in verschiedene Ebenen ein.&lt;br /&gt;
&lt;br /&gt;
Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, z. B. es&amp;amp;nbsp;werden in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B werden basierend auf diesen Rollen dann Prozesse beschrieben.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFBausteine.png|thumb|center|300px|TOGAF Bausteine]]&lt;br /&gt;
&lt;br /&gt;
=== Unterschied zwischen Artefakten und Deliverables ===&lt;br /&gt;
&lt;br /&gt;
Es wird in TOGAF unterschieden zwischen Artefakten und anderen Deliverables. Die Unterscheidung kommt daher, dass Artefakte stets die Architektur an sich beschreiben bzw. die einzelnen Bestandteile der Architektur. Andere Deliverables beschreiben z. B. die Umgebung der Architektur oder die Projektstruktur des Architekturprojekts.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFArtefakte.PNG|thumb|center|300px|Mögliche Artefakte zur Beschreibung einer Architektur nach TOGAF]]&lt;br /&gt;
&lt;br /&gt;
Artefakte sind entweder Kataloge, Matrizen oder Diagramme und bestehen aus den einzelnen Bausteinen.&lt;br /&gt;
&lt;br /&gt;
*Ein Baustein ist z. B. eine einzelne Rolle. Der Rollenkatalog, der alle Rollen auflistet, ist ein mögliches Artefakt. Ein Prozessdiagramm mit Rollen als Swimlanes wäre ein weiteres mögliches Artefakt, das die Bausteine Prozess und Rolle kombiniert. &lt;br /&gt;
*Ein Katalog besteht immer nur aus einem Bausteintyp; Matrizen bestehen typischerweise aus zwei verschiedenen Bausteintypen und Diagramme aus mehreren. &lt;br /&gt;
&lt;br /&gt;
TOGAF sieht eine Vielzahl an Artefakten vor&amp;amp;nbsp; (siehe Abbildung.)&lt;br /&gt;
&lt;br /&gt;
Im Los 1 IVS-Rahmenarchitektur werden sowohl Templates zur Beschreibung einzelner Bausteine als auch Templates für Artefakte entwickelt und für die IVS-Referenzarchitekturen bereitgestellt.&lt;br /&gt;
&lt;br /&gt;
== Das TOGAF-basierte Rahmenwerk für IVS-Architektur ==&lt;br /&gt;
&lt;br /&gt;
=== Tailoring des TOGAF Phasen- und Schrittmodells ===&lt;br /&gt;
&lt;br /&gt;
Um das TOGAF-Modell für jede Phase und jeden einzelnen Schritt an die Anforderung der Entwicklung einer IVS-Architektur anpassen zu können, wurde ein Tailoring-Modell entwickelt, das die Schritt-Tabellen der Phasen um Spalten wie folgt erweitert:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; width=&amp;quot;792&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF&lt;br /&gt;
! Tailoring IVS-Architektur&lt;br /&gt;
! Anleitung&lt;br /&gt;
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables&lt;br /&gt;
! Empfehlung für IVS-Referenzarchitekturen&lt;br /&gt;
! style=&amp;quot;width: 89.55px&amp;quot; | Empfehlung für IVS-Architekturen realer IVS-Dienste&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;Wirkungsbereichs&amp;lt;/u&amp;gt; von IVS-Architektur&lt;br /&gt;
| [[Wirkungsbereichs_der_IVS-Architekturaufgabe|'''Wirkungsbereich von IVS-Architektur''']] &lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Wirkungsbereich_von_IVS-Architektur|Beispiel IVS-Rahmenarchitektur]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 2&lt;br /&gt;
| Identifizierung der betroffenen &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung von IVS-Architektur betroffener &amp;lt;u&amp;gt;Institutionen/Unternehmen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen|'''Von IVS-Architektur betroffene Institutionen/Unternehmen und Rahmenbedingungen''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;Steuerungs- und Unterstützungsframeworks für IVS-Architektur&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Steuerungs- und Unterstützungsframeworks für IVS-Architektur''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;IVS-Architektur-Teams und einer Organisation&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architekturteam|'''Hinweise zur Bildung eines IVS-Architekturteams''']]&lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Meta-Modelle|Modell, Grundlage für Nachvollziehbarkeit]] &lt;br /&gt;
:[[Glossar|Glossar, Grundlage für gemeinsames Verstehen]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;IVS-Architekturprinzipien&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architektur&amp;amp;Geschäftsprinzipien|'''IVS-Architektur-Prinzipien''']]&lt;br /&gt;
&lt;br /&gt;
*[[IVS-Architekturprinzip|Baustein IVS-Architekturprinzip]] &lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Katalog_IVS-Architekturprinzipien|Beispiele für Architekturprinzipien aus dem IKT-Bereich]] &lt;br /&gt;
&lt;br /&gt;
| [[Media:IVS-Architekturprinzip-Katalog_00-00-01.docx|K: IVS-Architekturprinzipien]]&lt;br /&gt;
| K: IVS-Architekturprinzipien für die IVS-Dienstekategorie (geerbt von der IVS-Rahmenarchitektur, erweitert für die IVS-Dienstekategorie)&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | K: IVS-Architekturprinzipien für den spezifischen IVS-Dienst (geerbt von der IVS-Dienstekategorie, erweitert für den spezifischen IVS-Dienst)&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Auswahl und Anpassung von &amp;lt;u&amp;gt;IVS-Architekturframeworks&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Nationale und internationale IVS-Architekturframworks''']]&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;IVS-Architekturwerkzeugen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Architekturwerkzeuge|'''Vorschläge für IVS-Architekturwerkzeuge''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-basierte Rahmenwerk als Ergebnis des Tailorings ===&lt;br /&gt;
&lt;br /&gt;
Ergebnis des Tailorings des TOGAF ADM-Phasenmodells ist am Ende das '''TOGAF-basierte Rahmenwerk für IVS-Architektur'''. Es besteht im Einzelnen aus&lt;br /&gt;
&lt;br /&gt;
*der [[Los1:_UAP1.2_TOGAF_basiertes_Rahmenwerk#Tayloring_des_TOGAF_ADM-Phasenmodells_als_Grundlage_f.C3.BCr_IVS-Architekturarbeit|'''TOGAF ADM-Tailoringmethode für IVS-Architektur''']] sowie die gemäß TOGAF ADM strukturierten Phasen und Schritte zur Entwicklung einer IVS-Architektur (siehe im Wiki-Navigationsbaum Menüpunkt &amp;quot;Phasen und Schritte zur Entwicklung einer IVS-Architektur&amp;quot;) &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Hauptseite_rechts|'''Ablage für Templates für IVS-Architekturbausteine''']] auf der Wiki-Hauptseite rechts, &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Schnellzugriff|'''Ablage für Deliverables eines Architekturprojekts''']] auf der Wiki-Hauptseite links. &lt;br /&gt;
&lt;br /&gt;
=== Phasen und Schritte der IVS-Rahmenarchitektur 1.0 ===&lt;br /&gt;
&lt;br /&gt;
Für die Entwicklung der IVS-Rahmenarchitektur 1.0 wurde der Schwerpunkt auf die Architekturvision, die Geschäfts- und Informationssystemarchitektur gelegt (TOGAF Phasen A bis C).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
TOGAF-ADM.jpg | TOGAF - ADM &lt;br /&gt;
FokusVersion09.png | Fokus IVS-Rahmenarchitektur 1.0&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In der '''TOGAF Phase D''' erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme, aus Hardware, Software und Kommunikationstechnologie. Diese Phase ist eine wichtige Phase für eine IVS-Architektur eines realen IVS-Dienstes. Jeder Akteur, der an einer IVS-Architektur eines realen IVS-Dienstes beteiligt ist, muss sich die Fragen nach der bestmöglichen technologischen Einbettung in die Unternehmensarchitektur seines Wirkungsbereichs stellen. Diese Entscheidungen können und sollen weder von der IVS-Rahmenarchitektur noch von einer IVS-Referenzarchitektur getroffen werden.&lt;br /&gt;
&lt;br /&gt;
Für die TOGAF Phasen A bis C enthält die IVS-Rahmenarchitektur Vorgaben für die Entwicklung der entsprechenden Phasen der IVS-Referenzarchitekturen. Die IVS-Referenzarchitekturen enthalten wiederum die Beschreibung der Architekturphasen A bis C für die jeweiligen Domänen. Dort werden Vorgaben und Vorschläge für IVS-Architekturen realer IVS-Dienste entwickelt und beschrieben. Von dieser Vorgehensweise wird für die '''TOGAF Phasen E bis H''' abgewichen. Für die IVS-Referenzarchitekturen entfallen diese Phasen vollständig, da keine einheitlichen Vorgaben für IVS-Architekturen realer IVS-Dienste entwickelt werden können. Stattdessen müssen in jedem Projekt, in dem eine IVS-Architektur eines IVS-Dienstes erarbeitet wird, diese Phasen individuell ausgearbeitet werden. Für die IVS-Rahmenarchitektur ändert sich für die Phasen E bis H der Blickwinkel: Anstatt Vorgaben für die IVS-Referenzarchitekturen zu entwickeln, werden diese Phasen zusammengefasst und es wird die Vorgehensweise zur Umsetzung der IVS-Architekturen beschrieben.&lt;br /&gt;
&lt;br /&gt;
Einen Überblick über das Tailoring der Phasen '''Vorbereitung''' sowie&amp;amp;nbsp;'''Phasen A, B und C (C1. und C.2)''' liefern die folgenden Grafiken:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
File:Vorbereitungsphase_00-00-07.png | Vorbereitungsphase&lt;br /&gt;
File:Phase-A_00-00-03.png | Phase A - IVS-Architekturvision&lt;br /&gt;
Datei: Phase-B_00-00-01.png | Phase A - IVS-Geschäftsarchitektur&lt;br /&gt;
Datei: Phase-C-Daten.png | Phase C.1 - IVS-Datenarchitektur&lt;br /&gt;
Datei: Phase-C-Anwendung.png | Phase C.1 - IVS-Anwendungsarchitektur&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Literaturverzeichnis ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12316</id>
		<title>IVS-Architektur-Vorgehensmodell</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architektur-Vorgehensmodell&amp;diff=12316"/>
		<updated>2017-12-04T10:58:35Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Problemstellung ==&lt;br /&gt;
&lt;br /&gt;
Das '''T'''he '''O'''pen '''G'''roup '''A'''rchitecture '''F'''ramework (TOGAF) bietet einen Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen. Als operationelles Framework der Gruppe Government and Agency Frameworks bietet TOGAF mit der Architecture Development Method (ADM) unter anderem auch ein Vorgehensmodell zur Entwicklung von Unternehmensarchitekturen (siehe hier&amp;amp;nbsp;[https://de.wikipedia.org/wiki/TOGAF TOGAF]).&lt;br /&gt;
&lt;br /&gt;
Aufgrund der weltweiten Verbreitung und Anerkennung als &amp;quot;das Modell&amp;quot; für die Entwicklung von Unternehmensarchitekturen eignen sich TOGAF und die TOGAF ADM sehr gut als konzeptioneller Hintergrund auch für die Entwicklung von IVS-Architekturen. Allerdings ist TOGAF einerseits mehr auf die Entwicklung der Architektur eines einzelnen Unternehmens ausgerichtet und stellt andererseits viele Konzepte für Architekturaspekte bereit, die für IVS und IVS-Dienste keine Bedeutung haben. Für die Entwicklung einer IVS-Architektur, das heißt die Architektur von IVS-Diensten, an denen in der Regel mehrere Institutionen und Unternehmen beteiligt sind, erfolgte deshalb eine Anpassung (Tailoring) des TOGAF-Vorgehensmodells unter drei Gesichtspunkten:&lt;br /&gt;
&lt;br /&gt;
*Entwicklung eines generellen Modells zur Anpassung des TOGAF-Vorgehensmodells an die Aufgaben zur Erstellung einer IVS-Architektur, um dieses für die Entwicklung von IVS-Architekturen nutzen zu können &lt;br /&gt;
*Erarbeitung eines TOGAF basierten Rahmenwerks für die verschiedenen Phasen der IVS–Architekturentwicklung und Darstellung in einem Wiki &lt;br /&gt;
*Entwicklung eines IVS-Architektur-Glossars und -Metamodells &lt;br /&gt;
&lt;br /&gt;
Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der TOGAF ADM wird diese im Folgenden kurz erläutert.&lt;br /&gt;
&lt;br /&gt;
== TOGAF - ein Überblick ==&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF ADM-Phasenmodell ===&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAF-ADM.jpg|thumb|right|259x336px|TOGAF ADM]]TOGAF definiert mit der Architecture Development Method (ADM; siehe nebenstehendes Bild) einen Prozess zur Entwicklung von Unternehmensarchitekturen. Im Einzelnen werden mit der ADM folgende Phasen durchlaufen:&amp;lt;ref&amp;gt;Schmid, Daniel (2013): ARCHITEKTURMANAGEMENT MIT TOGAF. Online verfügbar unter http://blog.itil.org/2013/01/allgemein/architekturmanagement-mit-togaf/, zuletzt geprüft am 14.11.2017.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Preliminary Phase (Vorarbeiten) &lt;br /&gt;
:Hier werden die Einbindung zugrundeliegender Modelle geklärt, Modell-Anpassungen definiert sowie wichtige Prinzipien für die Architekturentwicklung festgelegt. &lt;br /&gt;
;Phase A - Architecture Vision (Architekturvision) &lt;br /&gt;
:Hier werden die Ziele der Architekturentwicklung und die daran Beteiligten festgelegt. &lt;br /&gt;
;Phase&amp;amp;nbsp;B - Business Architecture (Geschäftsarchitektur) &lt;br /&gt;
:Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden u.a. Geschäftsprozessmodelle, Use-Case- und Klassendiagramme verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;C - Information and Systems Architectures (Informations- und System-Architektur) &lt;br /&gt;
:Hier werden für die Informations-/Datenarchitektur und für die Anwendungsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Datenmodelle und Anwendungen verwendet. &lt;br /&gt;
;Phase&amp;amp;nbsp;D - Technology Architecture (Technologiearchitektur) &lt;br /&gt;
:Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die benötigte Technologie für die Ausführung der Anwendungen und der darüberliegenden Prozesse beschrieben. &lt;br /&gt;
;In Phase E - Opportunities and Solutions (Möglichkeiten und Lösungen) &lt;br /&gt;
:Hier werden die Vorhaben festgelegt, welche die Transformation aus der Ist-Situation zum Soll-Zustand durchführen. &lt;br /&gt;
;Phase F - Migration Planning (Migrationsplanung) &lt;br /&gt;
:Hier wird die Überführung von Ist-Zustand in den Soll-Zustand geplant. &lt;br /&gt;
;Phase G - Implementation Governance (Steuerung und Überwachung der Implementierung) &lt;br /&gt;
:Hier wird die Implementierung in den Soll-Zustand überwacht. &lt;br /&gt;
;Phase H - Architecture Change Management (Änderungsmanagement) &lt;br /&gt;
:Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als Grundlage für einen evtl. nächsten Durchlauf des Prozesses dienen. &lt;br /&gt;
;Requirements Management (Anforderungsmanagement) &lt;br /&gt;
:Das Anforderungsmanagement treibt den ADM Prozess kontinuierlich und steht deshalb im Zentrum des Prozesses. &lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-ADM Schrittmodell ===&lt;br /&gt;
&lt;br /&gt;
Gemäß TOGAF Version 9.1 ist jede Phase nochmals in einzelne Schritte ('''Steps''') unterteilt, die im TOGAF-Handbuch genau erklärt sind. Damit wird generell ein methodisches und umfassendes Vorgehen bei der Entwicklung einer Architektur sichergestellt. Ein Beispiel für die '''Vorbereitungsphase''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF-Vorgabe&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 2&lt;br /&gt;
| Betroffene &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| style=&amp;quot;text-align: center&amp;quot; | 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Eine Besonderheit ist mit dem Schrittmodell der Phasen B, C und D verbunden (siehe auch [[Hinweise_zu_den_Phasen_B,C_und_D|Hinweise zum TOGAF Schrittmodell der Phasen B, C und D]]).&lt;br /&gt;
&lt;br /&gt;
=== TOGAF Architecture Deliverables als Ergebnisse (Liefergegenstände) der Architekturarbeit ===&lt;br /&gt;
&lt;br /&gt;
Das Vorgehen in Schritten mündet in sog. '''Architecture Deliverables''' als Ergebnis (Liefergegenstände) der Architekturarbeit. Dabei unterscheidet TOGAF folgende &amp;quot;Architecture Deliverables&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
*'''Artefakte''' (im möglichen Format von Katalogen, Matrizen und Diagrammen) und &lt;br /&gt;
*'''Other Deliverables''' &lt;br /&gt;
&lt;br /&gt;
[[File:Architecture Deliverables.png|thumb|center|300px|Architektur Liefergegenstände]]&lt;br /&gt;
&lt;br /&gt;
Artefakte beschreiben Bausteine ('''Building blocks'''). Dass sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. TOGAF ordnet Bausteine in verschiedene Ebenen ein.&lt;br /&gt;
&lt;br /&gt;
Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, z. B. es&amp;amp;nbsp;werden in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B werden basierend auf diesen Rollen dann Prozesse beschrieben.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFBausteine.png|thumb|center|300px|TOGAF Bausteine]]&lt;br /&gt;
&lt;br /&gt;
=== Unterschied zwischen Artefakten und Deliverables ===&lt;br /&gt;
&lt;br /&gt;
Es wird in TOGAF unterschieden zwischen Artefakten und anderen Deliverables. Die Unterscheidung kommt daher, dass Artefakte stets die Architektur an sich beschreiben bzw. die einzelnen Bestandteile der Architektur. Andere Deliverables beschreiben z. B. die Umgebung der Architektur oder die Projektstruktur des Architekturprojekts.&lt;br /&gt;
&lt;br /&gt;
[[File:TOGAFArtefakte.PNG|thumb|center|300px|Mögliche Artefakte zur Beschreibung einer Architektur nach TOGAF]]&lt;br /&gt;
&lt;br /&gt;
Artefakte sind entweder Kataloge, Matrizen oder Diagramme und bestehen aus den einzelnen Bausteinen.&lt;br /&gt;
&lt;br /&gt;
*Ein Baustein ist z. B. eine einzelne Rolle. Der Rollenkatalog, der alle Rollen auflistet, ist ein mögliches Artefakt. Ein Prozessdiagramm mit Rollen als Swimlanes wäre ein weiteres mögliches Artefakt, das die Bausteine Prozess und Rolle kombiniert. &lt;br /&gt;
*Ein Katalog besteht immer nur aus einem Bausteintyp; Matrizen bestehen typischerweise aus zwei verschiedenen Bausteintypen und Diagramme aus mehreren. &lt;br /&gt;
&lt;br /&gt;
TOGAF sieht eine Vielzahl an Artefakten vor&amp;amp;nbsp; (siehe Abbildung.)&lt;br /&gt;
&lt;br /&gt;
Im Los 1 IVS-Rahmenarchitektur werden sowohl Templates zur Beschreibung einzelner Bausteine als auch Templates für Artefakte entwickelt und für die IVS-Referenzarchitekturen bereitgestellt.&lt;br /&gt;
&lt;br /&gt;
== Das TOGAF-basierte Rahmenwerk für IVS-Architektur ==&lt;br /&gt;
&lt;br /&gt;
=== Tailoring des TOGAF Phasen- und Schrittmodells ===&lt;br /&gt;
&lt;br /&gt;
Um das TOGAF-Modell für jede Phase und jeden einzelnen Schritt an die Anforderung der Entwicklung einer IVS-Architektur anpassen zu können, wurde ein Tailoring-Modell entwickelt, das die Schritt-Tabellen der Phasen um Spalten wie folgt erweitert:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; width=&amp;quot;792&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
! Schritt&lt;br /&gt;
! TOGAF&lt;br /&gt;
! Tailoring IVS-Architektur&lt;br /&gt;
! Anleitung&lt;br /&gt;
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables&lt;br /&gt;
! Empfehlung für IVS-Referenzarchitekturen&lt;br /&gt;
! style=&amp;quot;width: 89.55px&amp;quot; | Empfehlung für IVS-Architekturen realer IVS-Dienste&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 1&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Bestimmung des &amp;lt;u&amp;gt;Wirkungsbereichs&amp;lt;/u&amp;gt; von IVS-Architektur&lt;br /&gt;
| [[Wirkungsbereichs_der_IVS-Architekturaufgabe|'''Wirkungsbereich von IVS-Architektur''']] &lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Wirkungsbereich_von_IVS-Architektur|Beispiel IVS-Rahmenarchitektur]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 2&lt;br /&gt;
| Identifizierung der betroffenen &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung von IVS-Architektur betroffener &amp;lt;u&amp;gt;Institutionen/Unternehmen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen|'''Von IVS-Architektur betroffene Institutionen/Unternehmen und Rahmenbedingungen''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 3&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Sicherstellung von &amp;lt;u&amp;gt;Steuerungs- und Unterstützungsframeworks für IVS-Architektur&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Steuerungs- und Unterstützungsframeworks für IVS-Architektur''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 4&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Definition und Aufbau eines &amp;lt;u&amp;gt;IVS-Architektur-Teams und einer Organisation&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architekturteam|'''Hinweise zur Bildung eines IVS-Architekturteams''']]&lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Meta-Modelle|Modell, Grundlage für Nachvollziehbarkeit]] &lt;br /&gt;
:[[Glossar|Glossar, Grundlage für gemeinsames Verstehen]] &lt;br /&gt;
&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 5&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Identifizierung und Festlegung von &amp;lt;u&amp;gt;IVS-Architekturprinzipien&amp;lt;/u&amp;gt;&lt;br /&gt;
| &lt;br /&gt;
[[IVS-Architektur&amp;amp;Geschäftsprinzipien|'''IVS-Architektur-Prinzipien''']]&lt;br /&gt;
&lt;br /&gt;
*[[IVS-Architekturprinzip|Baustein IVS-Architekturprinzip]] &lt;br /&gt;
&lt;br /&gt;
;Hintergrundinformationen und Techniken &lt;br /&gt;
:[[Katalog_IVS-Architekturprinzipien|Beispiele für Architekturprinzipien aus dem IKT-Bereich]] &lt;br /&gt;
&lt;br /&gt;
| [[Media:IVS-Architekturprinzip-Katalog_00-00-01.docx|K: IVS-Architekturprinzipien]]&lt;br /&gt;
| K: IVS-Architekturprinzipien für die IVS-Dienstekategorie (geerbt von der IVS-Rahmenarchitektur, erweitert für die IVS-Dienstekategorie)&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | K: IVS-Architekturprinzipien für den spezifischen IVS-Dienst (geerbt von der IVS-Dienstekategorie, erweitert für den spezifischen IVS-Dienst)&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 6&lt;br /&gt;
| Auswahl und organisationsspezifische Anpassung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Auswahl und Anpassung von &amp;lt;u&amp;gt;IVS-Architekturframeworks&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Frameworks|'''Nationale und internationale IVS-Architekturframworks''']]&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Anpassung und Erweiterung&lt;br /&gt;
|- style=&amp;quot;vertical-align: top&amp;quot;&lt;br /&gt;
| 7&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]&amp;lt;/u&amp;gt;&lt;br /&gt;
| Implementierung von &amp;lt;u&amp;gt;IVS-Architekturwerkzeugen&amp;lt;/u&amp;gt;&lt;br /&gt;
| [[IVS-Architekturwerkzeuge|'''Vorschläge für IVS-Architekturwerkzeuge''']]&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| Projektspezifische Lösung&lt;br /&gt;
| style=&amp;quot;width: 89.55px&amp;quot; | Projektspezifische Lösung&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Das TOGAF-basierte Rahmenwerk als Ergebnis des Tailorings ===&lt;br /&gt;
&lt;br /&gt;
Ergebnis des Tailorings des TOGAF ADM-Phasenmodells ist am Ende das '''TOGAF-basierte Rahmenwerk für IVS-Architektur'''. Es besteht im Einzelnen aus&lt;br /&gt;
&lt;br /&gt;
*der [[Los1:_UAP1.2_TOGAF_basiertes_Rahmenwerk#Tayloring_des_TOGAF_ADM-Phasenmodells_als_Grundlage_f.C3.BCr_IVS-Architekturarbeit|'''TOGAF ADM-Tailoringmethode für IVS-Architektur''']] sowie die gemäß TOGAF ADM strukturierten Phasen und Schritte zur Entwicklung einer IVS-Architektur (siehe im Wiki-Navigationsbaum Menüpunkt &amp;quot;Phasen und Schritte zur Entwicklung einer IVS-Architektur&amp;quot;) &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Hauptseite_rechts|'''Ablage für Templates für IVS-Architekturbausteine''']] auf der Wiki-Hauptseite rechts, &lt;br /&gt;
*der nach den TOGAF ADM-Phasen strukturierten [[Vorlage:Schnellzugriff|'''Ablage für Deliverables eines Architekturprojekts''']] auf der Wiki-Hauptseite links. &lt;br /&gt;
&lt;br /&gt;
=== Phasen und Schritte der IVS-Rahmenarchitektur 1.0 ===&lt;br /&gt;
&lt;br /&gt;
Für die Entwicklung der IVS-Rahmenarchitektur 1.0 wurde der Schwerpunkt auf die Architekturvision, die Geschäfts- und Informationssystemarchitektur gelegt (TOGAF Phasen A bis C).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
TOGAF-ADM.jpg | TOGAF - ADM &lt;br /&gt;
FokusVersion09.png | Fokus IVS-Rahmenarchitektur 1.0&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In der '''TOGAF Phase D''' erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme, aus Hardware, Software und Kommunikationstechnologie. Diese Phase ist eine wichtige Phase für eine IVS-Architektur eines realen IVS-Dienstes. Jeder Akteur, der an einer IVS-Architektur eines realen IVS-Dienstes beteiligt ist, muss sich die Fragen nach der bestmöglichen technologischen Einbettung in die Unternehmensarchitektur seines Wirkungsbereichs stellen. Diese Entscheidungen können und sollen weder von der IVS-Rahmenarchitektur noch von einer IVS-Referenzarchitektur getroffen werden.&lt;br /&gt;
&lt;br /&gt;
Für die TOGAF Phasen A bis C enthält die IVS-Rahmenarchitektur Vorgaben für die Entwicklung der entsprechenden Phasen der IVS-Referenzarchitekturen. Die IVS-Referenzarchitekturen enthalten wiederum die Beschreibung der Architekturphasen A bis C für die jeweiligen Domänen. Dort werden Vorgaben und Vorschläge für IVS-Architekturen realer IVS-Dienste entwickelt und beschrieben. Von dieser Vorgehensweise wird für die '''TOGAF Phasen E bis H''' abgewichen. Für die IVS-Referenzarchitekturen entfallen diese Phasen vollständig, da keine einheitlichen Vorgaben für IVS-Architekturen realer IVS-Dienste entwickelt werden können. Stattdessen müssen in jedem Projekt, in dem eine IVS-Architektur eines IVS-Dienstes erarbeitet wird, diese Phasen individuell ausgearbeitet werden. Für die IVS-Rahmenarchitektur ändert sich für die Phasen E bis H der Blickwinkel: Anstatt Vorgaben für die IVS-Referenzarchitekturen zu entwickeln, werden diese Phasen zusammengefasst und es wird die Vorgehensweise zur Umsetzung der IVS-Architekturen beschrieben.&lt;br /&gt;
&lt;br /&gt;
Einen Überblick über das Tailoring der Phasen '''Vorbereitung''' sowie&amp;amp;nbsp;'''Phasen A, B und C (C1. und C.2)''' liefern die folgenden Grafiken:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;gallery&amp;gt;&lt;br /&gt;
File:Vorbereitungsphase_00-00-07.png | Vorbereitungsphase&lt;br /&gt;
File:Phase-A_00-00-03.png | Phase A - IVS-Architekturvision&lt;br /&gt;
Datei: Phase-B_00-00-01.png | Phase A - IVS-Geschäftsarchitektur&lt;br /&gt;
Datei: Phase-C-Daten.png | Phase C.1 - IVS-Datenarchitektur&lt;br /&gt;
Datei: Phase-C-Anwendung.png | Phase C.1 - IVS-Anwendungsarchitektur&lt;br /&gt;
&amp;lt;/gallery&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Literaturverzeichnis ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsprozesse_und_Wertsch%C3%B6pfungsnetzwerke&amp;diff=9619</id>
		<title>IVS-Geschäftsprozesse und Wertschöpfungsnetzwerke</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsprozesse_und_Wertsch%C3%B6pfungsnetzwerke&amp;diff=9619"/>
		<updated>2017-05-08T09:48:10Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Definition ==&lt;br /&gt;
&lt;br /&gt;
Die folgende Aufzählung enthält die relevanten Begriffe der Geschäftsarchitektur und setzt sie zueinander in Beziehung:&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Wertschöpfungskette/-netzwerk''' betreibt einen '''Realer Dienst&amp;quot;''' &lt;br /&gt;
*'''Realer Dienst liefert über einen &amp;quot;IVS-Dienstzugangspunkt''' eine '''IVS-Information''' &lt;br /&gt;
*'''IVS-Information''' spendet '''IVS-Nutzen''' &lt;br /&gt;
*''''IVS-Nutzen''' ist von Wert für ''''IVS-End-Nutzer''' &lt;br /&gt;
&lt;br /&gt;
&amp;amp;nbsp;&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Akteur''' ist Bestandteil '''IVS-Wertschöpfungskette/-netzwerk''' und nimmt '''IVS-Rolle''' ein &lt;br /&gt;
*'''IVS-Rolle''' repräsentiert '''IVS-Capability''', die erforderlich ist, um einen Wertbeitrag zur IVS-Wertschöpfung zu leisten. &lt;br /&gt;
&lt;br /&gt;
Diese Begriffe und die Beziehungen zwischen ihnen werden im folgenden UML-Diagramm dargestellt:&lt;br /&gt;
&lt;br /&gt;
[[File:IVS-Wertschöpfungsnetzwerk.jpg|700px|UML-Diagramm für IVS-Wertschöpfungsprozess]]&lt;br /&gt;
&lt;br /&gt;
==Operationalisierung durch IVS-Geschäftsprozesse==&lt;br /&gt;
Ein IVS-Geschäftsprozess operationalisiert ein IVS-Wertschöpfungsnetzwerk durch Orchestrierung einzelner IVS-Dienste. In dieser Orchestrierung werden die Reihenfolge, in der die IVS-Dienste verwendet werden, die Ereignisse, die den Geschäftsprozess auslösen, beeinflussen oder beenden, sowie die IVS-Informationsobjekte, die zwischen den IVS-Diensten ausgetauscht werden, festgelegt. Zur Modellierung von IVS-Geschäftsprozessen eignen sich BPMN-Prozessdiagramme (siehe [[#Beispiel|Beispiel]]).&lt;br /&gt;
&lt;br /&gt;
Aus diesen Diagrammen lassen sich die beteiligten IVS-Dienste, die relevanten IVS-Rollen und die verwendeten IVS-Informationsobjekte ablesen. Die IVS-Rollen wurden bereits in der [[TOGAF-Phase A]] erfasst und werden in dieser Architekturphase bei Bedarf vervollständigt und ergänzt. Auch die IVS-Dienste wurden bereits in der TOGAF-Phase A erfasst und können vervollständigt und ergänzt werden. Die IVS-Informationsobjekte, die zur Realisierung des Wertschöpfungsprozesses benötigt werden, werden in der [[TOGAF-Phase C]] gesammelt und beschrieben.&lt;br /&gt;
&lt;br /&gt;
== Strategische und operative Geschäftsprozesse== &lt;br /&gt;
&lt;br /&gt;
===Strategische Geschäftsprozesse===&lt;br /&gt;
Strategische Geschäftsprozesse beschreiben den Ablauf eines Geschäftsprozesses so kompakt wie möglich. Das Ziel ist die übersichtliche Darstellung von Anfang bis Ende, wobei alle Details, die für die Interoperabilität zwischen verschiedenen IVS-Akteuren benötigt werden, abgebildet werden. Details, die nur einen IVS-Akteur betreffen werden in der Regel weggelassen. Deshalb werden häufig Teilprozesse anstelle von Aufgaben verwendet. Alle Aktivitäten müssen eindeutig einer Rolle zugeordnet sein. Die Verbindungen zwischen den Rollen sowie die ausgetauschten Informationsobjekte sollen klar beschrieben sein.&lt;br /&gt;
&lt;br /&gt;
'''Strategische Geschäftsprozesse''' werden vorwiegend auf Ebene der '''IVS-Referenzarchitekturen''' eingesetzt.&lt;br /&gt;
&lt;br /&gt;
===Operative Geschäftsprozesse===&lt;br /&gt;
In operativen Geschäftsprozessen werden die menschlichen und technischen Aktivitäten und die Sequenzflüsse zwischen diesen beschrieben. Die Beschreibung der menschlichen Aktivitäten dient dazu, die nicht automatisierten Teile eines operativen Geschäftsprozesses hervorzuheben. Technische Aktivitäten können automatisiert werden, idealerweise mithilfe von Process Engines. Der Geschäftsprozess wird auf operativer Ebene deshalb sehr viel detaillierter beschrieben als auf der strategischen Ebene. Der gesamte Prozess ist in der Regel ein komplexes Zusammenspiel von Menschen und IT-Systemen bzw. IVS-Diensten. Häufig werden die bei den strategischen Geschäftsprozessen verwendeten Teilprozesse in operativen Geschäftsprozessen beschrieben. &lt;br /&gt;
&lt;br /&gt;
'''Operative Geschäftsprozesse''' werden vorwiegend auf der Ebene von '''IVS-Architekturen realer IVS-Dienste und Produkte''' verwendet.&lt;br /&gt;
&lt;br /&gt;
== Kern- und Supportprozesse ==&lt;br /&gt;
&lt;br /&gt;
[[Datei: KernUSupportProzesse.png | 300px| Kern- und Supportprozesse ]]&lt;br /&gt;
&lt;br /&gt;
==Beschreibung von IVS-Geschäftsprozessen==&lt;br /&gt;
IVS-Geschäftsprozesse werden im [[IVS-Geschäftsprozess|Katalog IVS-Geschäftsprozesse]] beschrieben. Zusätzlich sollen sie in BPMN-Geschäftsprozessdiagrammen modelliert werden. [[Modellierungsrichtlinien für Geschäftsprozessdiagramme]] legen fest, wie Geschäftsprozessdiagramme aufgebaut werden sollen.&lt;br /&gt;
&lt;br /&gt;
==Modellierungsrichtlinien für IVS-Geschäftsprozesse==&lt;br /&gt;
Um hochwertige und einheitliche Geschäftsprozessdiagramme zu erhalten, sollten bestimmte Regeln definiert und eingehalten werden. Die Regeln dienen dazu, die IVS-Architekten bei ihrer Arbeit zu unterstützen. Außerdem soll damit erreicht werden, dass die Ergebnisse der Architekturarbeit einheitlich aufgebaut und vergleichbar sind.&lt;br /&gt;
&lt;br /&gt;
#'''Verwendung von eindeutigen Diagrammnamen:''' Die Namen der Geschäftsprozessdiagramme sollen dem Namen des Geschäftsprozesses entsprechen.&lt;br /&gt;
#'''Verwendung von Pools:''' Bei strategischen Geschäftsprozessdiagrammen, die hauptsächlich in IVS-Referenzarchitekturen verwendet werden, sollen Pools verwendet werden, um die beteiligten IVS-Rollen darzustellen. Bei operativen Geschäftsprozessdiagrammen sollen IVS-Akteure als Pools verwendet werden&lt;br /&gt;
#'''Verwendung von IVS-Rollen bzw. IVS-Akteuren als Poolbezeichnungen:''' Als Poolbezeichnungen sollen nur IVS-Rollen bzw. IVS-Akteure verwendet werden.&lt;br /&gt;
#'''Verwendung von IVS-Informationsobjekten als Datenobjekte:''' Wenn Datenobjekte in einem Geschäftsprozessdiagramm verwendet werden, sollte die Bezeichnung der Datenobjekte mit IVS-Informationsobjekten übereinstimmen.&lt;br /&gt;
#'''Verwendung von Namen für Aktivitäten:''' Aktivitäten müssen in einem Diagramm benannt werden, damit klar ist, was damit gemeint ist.&lt;br /&gt;
#'''Benennung von Sequenzflüssen und Meldungsflüssen:''' Sequenzflüsse und Meldungsflüsse müssen in einem Diagramm benannt werden, damit klar ist, was mit diesem Fluss gemeint ist.&lt;br /&gt;
#'''Konsistente Verwendung von Start- und Ende-Ereignissen:''' Die Verwendung von Start- und Ende-Ereignissen ist notwendig, um darzustellen, wo der Prozess beginnt bzw. endet.&lt;br /&gt;
#'''Verwendung von Meldungsflüssen nur zwischen Pools:''' Meldungsflüsse sollen nur zwischen verschiedenen Pools bzw. zwischen Aktivitäten von diesen verwendet werden.&lt;br /&gt;
#'''Maximale Diagrammgröße:''' Die Größe eines Geschäftsprozessdiagrammes sollte DIN-A3 nicht überschreiten. Falls ein Diagramm größer wird, sollen Aktivitäten zu Teilprozessen zusammengefasst werden, die dann in Detaildiagrammen dargestellt werden.&lt;br /&gt;
#'''Keine Überlagerung von Kanten:''' Die Überlagerung von Kanten ist nicht zulässig. Sowohl die Verständlichkeit als auch die Übersichtlichkeit des Geschäftsprozesses leiden unter dem Verstoß gegen diese Regel.&lt;br /&gt;
#'''Keine Überlagerung von Knoten:''' Für die Übersichtlichkeit und das Verständnis eines Geschäftsprozessiagrammes sollten sich keine Knoten überlagern.&lt;br /&gt;
&lt;br /&gt;
==Beispiel==&lt;br /&gt;
Das folgende Diagramm enthält ein Beispiel für einen IVS-Geschäftsprozess. Dabei repräsentieren die horizontalen Kästen IVS-Rollen, die gelben Rechtecke sind IVS-Dienste, die grünen Objekte sind IVS-Informationsobjekte. Das gesamte Diagramm beschreibt den IVS-Geschäftsprozess, der ein IVS-Wertschöpfungsnetzwerk operationalisiert:&lt;br /&gt;
[[Datei: Wertschöpfung.jpg | 700px |  Beispiel für einen IVS-Geschäftsprozess]]&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9301</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9301"/>
		<updated>2016-12-19T16:49:18Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an dem sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Instrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien zu etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
Eine Überwachung erfolgt bspw. mithilfe eines Performance-Managements. Das Performance-Management ist eng verbunden mit dem Prozess der kontinuierlichen Verbesserung und umfasst Überwachung, Steuern und die Erstellung von Leistungsbereichten und Leistungsauswertungen.&lt;br /&gt;
Mithilfe eines Performance-Managements wird sichergestellt, dass Aktivitäten und Services mit den festgelegten Kriterien übereinstimmen. Eine Überwachung erfolgt durch einen Vergleich von durchgeführten Aktivitäten und Services mit festgelegten Vorgaben und mit Reportings.&lt;br /&gt;
(siehe TOGAF 9.1)&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
** Dieser formale Prozess muss sicherstellen, dass anfallende Architektur-Änderungen, Verträge oder allgemeine Informationen richtig aufgenommen, wenn nötig aktualisiert, validiert und publiziert und werden. Somit wird durch diesen Governance-Prozess die Integration in bestehende Governance-Strukturen ermöglicht und bereits bestehnder Governance-Inhalt gemanagt und auditiert. &lt;br /&gt;
&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
** Regelmäßige &amp;quot;Compliance-Assessments&amp;quot; müssen durchgeführt werden, zur Sicherstellung der Einhaltung von SLAs, OLAs, Standards und regulatorischen Anforderungen. Nach der Durchführung der Assessments, werden diese entweder akzeptiert oder, bei nicht eingehaltenen Vorgaben, abgelehnt.&lt;br /&gt;
&lt;br /&gt;
* Dispensation&lt;br /&gt;
** Wird eine Compliance-Assessment abgelehnt, da Vorgaben nicht eingehalten worden sind, werden durch den Prozess der Dispensation alternative Möglichkeiten und Aktivitäten erarbeitet, um den internen Vorgaben wieder zu entsprechen und somit flexibel reagieren und vor allem SLAs und OLAs einzuhalten zu können. &lt;br /&gt;
&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
** siehe Performance-Management&lt;br /&gt;
&lt;br /&gt;
* Business Control&lt;br /&gt;
** Ein Vorgang der Entscheidungsfindung, wo entsprechende Entscheidungslogik auf die Auswahl eines Ansatzes zur korrekten Ausführung eines Prozesses hinsichtlich der dafür gültigen Vorgaben (Governance- Kriterien) angewendet wird.&lt;br /&gt;
&lt;br /&gt;
* Environment Management&lt;br /&gt;
** Dieser Prozess dient der Sicherstellung einer stabilen Governance-Umgebung. Hierunter fallen administrative Prozesse, bspw. User-Management und definieren/einhalten interner SLAs.&lt;br /&gt;
&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9288</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9288"/>
		<updated>2016-12-15T13:50:00Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Prozesse einer IVS-Governance */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an dem sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien zu etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
Eine Überwachung erfolgt bspw. mithilfe eines Performance-Managements. Das Performance-Management ist eng verbunden mit dem Prozess der kontinuierlichen Verbesserung und umfasst Überwachung, Steuern und die Erstellung von Leistungsbereichten und Leistungsauswertungen.&lt;br /&gt;
Mithilfe eines Performance-Managements wird sichergestellt, dass Aktivitäten und Services mit den festgelegten Kriterien übereinstimmen. Eine Überwachung erfolgt durch einen Vergleich von durchgeführten Aktivitäten und Services mit festgelegten Vorgaben und mit Reportings.&lt;br /&gt;
(siehe TOGAF 9.1)&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
** Dieser formale Prozess muss sicherstellen, dass anfallende Architektur-Änderungen, Verträge oder allgemeine Informationen richtig aufgenommen, wenn nötig aktualisiert, validiert und publiziert und werden. Somit wird durch diesen Governance-Prozess die Integration in bestehende Governance-Strukturen ermöglicht und bereits bestehnder Governance-Inhalt gemanagt und auditiert. &lt;br /&gt;
&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
** Regelmäßige &amp;quot;Compliance-Assessments&amp;quot; müssen durchgeführt werden, zur Sicherstellung der Einhaltung von SLAs, OLAs, Standards und regulatorischen Anforderungen. Nach der Durchführung der Assessments, werden diese entweder akzeptiert oder, bei nicht eingehaltenen Vorgaben, abgelehnt.&lt;br /&gt;
&lt;br /&gt;
* Dispensation&lt;br /&gt;
** Wird eine Compliance-Assessment abgelehnt, da Vorgaben nicht eingehalten worden sind, werden durch den Prozess der Dispensation alternative Möglichkeiten und Aktivitäten erarbeitet, um den internen Vorgaben wieder zu entsprechen und somit flexibel reagieren und vor allem SLAs und OLAs einzuhalten zu können. &lt;br /&gt;
&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
** siehe Performance-Management&lt;br /&gt;
&lt;br /&gt;
* Business Control&lt;br /&gt;
** Ein Vorgang der Entscheidungsfindung, wo entsprechende Entscheidungslogik auf die Auswahl eines Ansatzes zur korrekten Ausführung eines Prozesses hinsichtlich der dafür gültigen Vorgaben (Governance- Kriterien) angewendet wird.&lt;br /&gt;
&lt;br /&gt;
* Environment Management&lt;br /&gt;
** Dieser Prozess dient der Sicherstellung einer stabilen Governance-Umgebung. Hierunter fallen administrative Prozesse, bspw. User-Management und definieren/einhalten interner SLAs.&lt;br /&gt;
&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9287</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9287"/>
		<updated>2016-12-15T13:46:30Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Prozesse einer IVS-Governance */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an dem sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien zu etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
Eine Überwachung erfolgt bspw. mithilfe eines Performance-Managements. Das Performance-Management ist eng verbunden mit dem Prozess der kontinuierlichen Verbesserung und umfasst Überwachung, Steuern und die Erstellung von Leistungsbereichten und Leistungsauswertungen.&lt;br /&gt;
Mithilfe eines Performance-Managements wird sichergestellt, dass Aktivitäten und Services mit den festgelegten Kriterien übereinstimmen. Eine Überwachung erfolgt durch einen Vergleich von durchgeführten Aktivitäten und Services mit festgelegten Vorgaben und mit Reportings.&lt;br /&gt;
(siehe TOGAF 9.1)&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
** Dieser formale Prozess muss sicherstellen, dass anfallende Architektur-Änderungen, Verträge oder allgemeine Informationen richtig aufgenommen, wenn nötig aktualisiert, validiert und publiziert und werden. Somit wird durch diesen Governance-Prozess die Integration in bestehende Governance-Strukturen ermöglicht und bereits bestehnder Governance-Inhalt gemanagt und auditiert. &lt;br /&gt;
&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
** Regelmäßige &amp;quot;Compliance-Assessments&amp;quot; müssen durchgeführt werden, zur Sicherstellung der Einhaltung von SLAs, OLAs, Standards und regulatorischen Anforderungen. Nach der Durchführung der Assessments, werden diese entweder akzeptiert oder, bei nicht eingehaltenen Vorgaben, abgelehnt.&lt;br /&gt;
&lt;br /&gt;
* Dispensation&lt;br /&gt;
** Wird eine Compliance-Assessment abgelehnt, da Vorgaben nicht eingehalten worden sind, wird durch den Prozess der Dispensation alternative Möglichkeiten und Aktivitäten erarbeitet, um den internen Vorgaben wieder zu entsprechen und somit flexibel reagieren zu können und vor allem SLAs und OLAs einzuhalten. &lt;br /&gt;
&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
** siehe Performance-Management&lt;br /&gt;
&lt;br /&gt;
* Business Control&lt;br /&gt;
** Ein Vorgang der Entscheidungsfindung, wo entsprechende Entscheidungslogik auf die Auswahl eines Ansatzes zur korrekten Ausführung eines Prozesses hinsichtlich der dafür gültigen Vorgaben (Governance- Kriterien) angewendet wird.&lt;br /&gt;
&lt;br /&gt;
* Environment Management&lt;br /&gt;
** Dieser Prozess dient zur Sicherstellung einer stabilen Governance-Umgebung. Hierunter fallen administrative Prozesse zur Ausführung einer Service- und Prozessumgebung. Hierunter fallen bspw. Prozesse wie User-Management und interne SLAs.&lt;br /&gt;
&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9286</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9286"/>
		<updated>2016-12-15T13:11:30Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Überwachung und Reporting */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an dem sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien zu etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
Eine Überwachung erfolgt bspw. mithilfe eines Performance-Managements. Das Performance-Management ist eng verbunden mit dem Prozess der kontinuierlichen Verbesserung und umfasst Überwachung, Steuern und die Erstellung von Leistungsbereichten und Leistungsauswertungen.&lt;br /&gt;
Mithilfe eines Performance-Managements wird sichergestellt, dass Aktivitäten und Services mit den festgelegten Kriterien übereinstimmen. Eine Überwachung erfolgt durch einen Vergleich von durchgeführten Aktivitäten und Services mit festgelegten Vorgaben und mit Reportings.&lt;br /&gt;
(siehe TOGAF 9.1)&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9285</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9285"/>
		<updated>2016-12-15T13:09:31Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Überwachung und Reporting */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an dem sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien zu etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
Eine Überwachung erfolgt bspw. mithilfe eines Performance-Managements. Das Performance-Management ist eng verbunden mit dem Prozess der kontinuierlichen Verbesserung und umfasst Überwachung, Steuern und die Erstellung von Leistungsbereichten und Leistungsauswertungen.&lt;br /&gt;
Mithilfe eines Performance-Managements wird sichergestellt, dass Aktivitäten und Services mit den festgelegten Kriterien übereinstimmen. Eine Überwachung erfolgt durch einen Vergleich von durchgeführten Aktivitäten und Services mit festgelegten Vorgaben und mit Reportings.&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9284</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9284"/>
		<updated>2016-12-15T13:08:20Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Überwachung und Reporting */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an dem sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien zu etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
Eine Überwachung erfolgt bspw.mithilfe eines Performance-Managements. Das Performance-Management ist eng verbunden mit dem Prozess der kontinuierlichen Verbesserung und umfasst Überwachung, Steuern und die Erstellung von Leistungsbereichten und -auswertungen.&lt;br /&gt;
Mithilfe eines Performance-Managements wird sichergestellt, dass Aktivitäten und Services mit den festgelegten Kriterien übereinstimmen. Eine Überwachung erfolgt durch einen Vergleich von durchgeführten Aktivitäten und Services mit festgelegten Vorgaben und mit Reportings.&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9283</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9283"/>
		<updated>2016-12-15T10:55:25Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Bedeutung von Governance für IVS */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an dem sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien zu etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9282</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9282"/>
		<updated>2016-12-15T10:52:34Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an dem sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9281</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9281"/>
		<updated>2016-12-15T10:43:00Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Governance vs. Management */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
(Nach COBIT 5.0, Prinzip 5)&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an den sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9280</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9280"/>
		<updated>2016-12-15T10:38:06Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Prozesse einer IVS-Governance */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an den sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Inhalte einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9213</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9213"/>
		<updated>2016-12-08T15:31:33Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Überwachung un Reporting */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an den sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung und Reporting ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Prozesse einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9212</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9212"/>
		<updated>2016-12-08T14:43:12Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an den sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. &lt;br /&gt;
Die Zusammenhänge können in einer Matrix dargestellt werden, wie hier ein Beispiel aus dem Bereich der Enterprise Architekturen zeigt: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung un Reporting ===&lt;br /&gt;
...&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Prozesse einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9211</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9211"/>
		<updated>2016-12-08T14:42:05Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Service Level Agreements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an den sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Operational_Level_Agreement &amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Überwachung un Reporting ===&lt;br /&gt;
...&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Prozesse einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9210</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9210"/>
		<updated>2016-12-08T14:40:43Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Service Level Agreements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an den sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
'''Service Level Agreement (SLA)'''&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
'''Operational Level Agreement (OLA)'''&lt;br /&gt;
&lt;br /&gt;
Wikipedia definiert den Begriff OLA als eine Vereinbarung, die üblicherweise innerhalb einer Organisation zwischen unterschiedlichen Organisationseinheiten getroffen wird und der Absicherung eines übergeordneten SLAs der Organisation gegenüber einem Dritten dient. Somit ist das OLA im Gegensatz zum SLA eine organisationsinterne, nicht vertragliche Vereinbarung zur Absicherung der höherwertigen Vereinbarung. Beide Dokumenttypen verwenden jedoch in der Regel identische Strukturen und enthalten vergleichbare konkrete Details zu Absprachen über die Erbringung von definierten Services (IT- oder TK-Leistungen).&lt;br /&gt;
&lt;br /&gt;
=== Überwachung un Reporting ===&lt;br /&gt;
...&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Prozesse einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9209</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9209"/>
		<updated>2016-12-08T14:32:36Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Notwendigkeit von IVS-Governance */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an den sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
=== Überwachung un Reporting ===&lt;br /&gt;
...&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Prozesse einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9208</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9208"/>
		<updated>2016-12-08T14:31:17Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Service Level Agreements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Herkunft und Verwendung des Governance-Begriffs ==&lt;br /&gt;
=== Wikipedia ===&lt;br /&gt;
Gemäß Wikipedia &amp;lt;ref&amp;gt; https://de.wikipedia.org/wiki/Governance &amp;lt;/ref&amp;gt; wird der Begriff '''Governance''' (von französisch gouverner („verwalten, leiten, erziehen“), aus lateinisch gubernare; gleichbedeutend griechisch κυβερνάω bzw. κυβερνῶ (kontr.) / kybernáo bzw. kybernō: das Steuerruder führen; vgl. Kybernetik) oft übersetzt als '''Regierungs-, Amts- bzw. Unternehmensführung''', auch Lenkungsform und bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet.&lt;br /&gt;
-------------------&lt;br /&gt;
&lt;br /&gt;
=== ISO/IEC 38500 Standard ===&lt;br /&gt;
Im '''ISO/IEC 38500 Standard - Corporate Governance in Information Technology''' &amp;lt;ref&amp;gt;ISO/IEC 38500: Corporate Governance in Information Technology (2008)&amp;lt;/ref&amp;gt; ist der Begriff &amp;quot;Governance&amp;quot; mit dem Ziel eingeführt, Institutionen bei der Einrichtung ihrer IT-Prozesse so zu unterstützen, dass zum einen '''gesetzliche Vorschriften''' aber auch '''branchenspezifische Regularien''' eingehalten werden und dass die Prozesse diesen entsprechen.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Grundbestandteil des ISO/IEC 38500 Standards sind '''sechs Prinzipien für gute Unternehmensführung in der IT'''&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Responsibility (Verantwortung): Die Verantwortung für die IT-Belange muss von der Unternehmensleitung (Topmanagement) getragen werden.&lt;br /&gt;
;Strategy (Strategie): Die IT-Strategien leiten sich aus Unternehmensstrategien ab, um das IT-Potenzial zu erweitern. Die Unternehmensstrategien definieren die Anforderungen an die derzeitige und zukünftige Ausrichtung der IT.&lt;br /&gt;
;Acquisition (Beschaffung): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am Bedarf orientieren.&lt;br /&gt;
;Performance (Leistung): Die Leistung der IT-Services soll entsprechend den Anforderungen der Fach- und Organisationsbereiche gestaltet werden.&lt;br /&gt;
;Conformance (Konformität): Die IT hat mit allen rechtlichen Vorgaben, Normen, internen Standards etc. konform zu gehen.&lt;br /&gt;
;Human Behaviour (der menschliche Faktor): Die IT-Konzepte müssen die Bedürfnisse der internen und externen Nutzer beachten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Jedem dieser sechs Prinzipien sind von ISO/IEC 38500 jeweils drei Funktionen zugeordnet&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes unter Berücksichtigung aller Einflussfaktoren.&lt;br /&gt;
;Leitung: Steuerung einer Business-gerechten Fokussierung der IT-Maßnahmen.&lt;br /&gt;
;Kontrolle: Systematische Überwachung von Regelkonformität (Compliance) und Leistungsfähigkeit der IT.&lt;br /&gt;
&lt;br /&gt;
---------------------------------&lt;br /&gt;
&lt;br /&gt;
=== COBIT ===&lt;br /&gt;
Das COBIT 5 Prozess Referenzmodell der ISACA Organsiation&amp;lt;ref&amp;gt;https://www.isaca.org/Pages/default.aspx?cid=1000270&amp;amp;Appeal=SEM&amp;lt;/ref&amp;gt; unterteilt die IT-relevanten Aktivititäten der Unternehmensführung in die Bereiche '''Governance''' und '''Management''' und grenzt diese damit gegeneinander ab:&lt;br /&gt;
*The Governance domain contains five governance processes; within each process, evaluate, direct and monitor (EDM) practices are defined.&lt;br /&gt;
*The four Management domains are in line with the responsibility areas of plan, build, run and monitor (PBRM).&lt;br /&gt;
&lt;br /&gt;
COBIT 5 for Information Security examines each of the processes from an information security perspective.&lt;br /&gt;
&lt;br /&gt;
== Governance vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management diefferenziert werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen und hinsichtlich&lt;br /&gt;
* ihres Zwecks,&lt;br /&gt;
* ihrer Verantwortlichkeiten und &lt;br /&gt;
* ihrer Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Während '''Governance''' sich darauf fokussiert&amp;lt;/u&amp;gt;&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;fokussiert sich '''Management''' auf&amp;lt;/u&amp;gt; &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. &lt;br /&gt;
&lt;br /&gt;
Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
== Übertragung des Governance-Konzepts auf IVS ==&lt;br /&gt;
=== Warum &amp;quot;Governance&amp;quot; und nicht &amp;quot;Management&amp;quot; von IVS-Diensten === &lt;br /&gt;
IVS-Dienste, die den ständig wachsenden und sich verändernden Ansprüchen heutiger End-Nutzer entsprechen wollen, weisen eine komplexe Geschäftsarchitektur auf. An IVS-Akteure, die sich in ein IVS-Wertschöpfungsnetzwerk integrieren wollen, werden hohe organisatorische und technologische und auch finanzielle Anforderungen gestellt. Zudem sind IVS-Wertschöpungsnetzwerke nicht unbedingt über viele Jahre stabil; vielmehr müssen sie in der Lage sein, sich dem aktuell ständige veränderenden Verkehrs-, Transport- und Mobilitätsmarkt schnell und zielgerichtet anzupassen.&lt;br /&gt;
 &lt;br /&gt;
Erfahrungen im IVS-Sektor haben gezeigt, dass traditionelle &amp;quot;Ein-Unternehmenslöungen&amp;quot;, die &amp;quot;umfassende, ganzheitliche IVS-Dienste&amp;quot; anbieten wollen und an denen unterschiedliche eigenständige Institutionen/Unternehmen beteiligt (wie z.B. &amp;quot;PPP-Betreibermodelle&amp;quot;) sind, weil ein Unternehmen allein nicht in der Lage ist, das ganzheitliche IVS-Diensteprofil abzudecken, in der Regel nicht erfolgreich sind. Entweder fehlt ein wirtschaftlich tragendes Geschäftsmodell oder die beteiligten Partner sehen sich nicht dauerhaft in der Lage, sich auf gemeinsame Ziele und Realisierungsstrukturen zu einigen, oder es fehlt an der notwendigen Anpassungsfähigkeit an den sich verändernden Markt. Insofern kommen heutige IVS-Dienste bis auf wenigen Ausnahmen (Google-Maps, TomTom ...) nur zustande wenn mehrere IVS-Akteure sich zu IVS-Wertschöpfungsnetzwerken dauerhaft oder auch ad hoc zusammenschließen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: Cobit-Governance.png | thumb | 300px | right | COBIT: Abgrenzung von Governance und Management ]]&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund wird deutlich, dass &amp;quot;Management&amp;quot; als klassiches Intrument der Unternehmensführung für die Steuerung, das Controlling und die Bewertung nicht geeignet ist, für die Zilerreichung heterogener IVS-Wertschöpfungsketten Sorge zu tragen. &lt;br /&gt;
&lt;br /&gt;
An dieser Stelle setzt das '''Governance-Prinzip und -Konzept''' an, das auf die Kooperation unabhängig gemanagter Institutionen, die in IVS-Geschäftsprozessen mit jeweils &amp;quot;lose gekoppelten&amp;quot; Aktivitäten zusammenarbeiten, ausgerichtet ist. Das Prinzip zeigt nebenstehendes Bild.&lt;br /&gt;
&lt;br /&gt;
=== Bedeutung von Governance für IVS ===   &lt;br /&gt;
Vom Grunde her soll IVS-Governance also sicherstellen, dass zuvor gesetzte übergreifende IVS-Ziele, erreicht werden, aber auch dass die Interessen der beteiligten IVS-Akteure und -Stakeholder gewahrt werden. Dazu müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden.&lt;br /&gt;
&lt;br /&gt;
Dies geschieht durch Vorgaben ('''Richtung vorgeben'''), '''Überwachung''' der Ergebnisse und Bewertung der Ergebnisse auf Einhaltung der Vorgaben ('''Evaluierung'''). &lt;br /&gt;
&lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
Beispiele sind:&lt;br /&gt;
&lt;br /&gt;
*Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
*Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
*Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
*Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
&lt;br /&gt;
*SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von IVS-Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
&lt;br /&gt;
'''Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF)''':&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
=== Überblick ===&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
=== Vorgaben für IVS-Governance === &lt;br /&gt;
*Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
**räumlich/verkehrspolitisch&lt;br /&gt;
**wirtschaftlich, förderungstechnisch&lt;br /&gt;
**rechtlich (EU, national, regional)&lt;br /&gt;
**normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
*Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
**Europäische und nationale Gesetze und Regulierungen (rechtlich, fachlich)&lt;br /&gt;
**Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
**Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
**Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
*Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
**Finanzielle Beteiligung der Partner &lt;br /&gt;
**Förderquellen &lt;br /&gt;
**Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
*Organisation der Operativen Betriebs&lt;br /&gt;
**Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
**Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
**Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
**Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
**Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
*Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
**Räumlich/Verkehrspolitisch &lt;br /&gt;
**Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
**Rechtlich (EU, national, regional) &lt;br /&gt;
**Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für IVS-Governance-Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|left|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br Clear=all&amp;gt;&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
Hierbei handelt es sich um Verträge, die zwischen Service-Konsument und Service-Lieferanten geschlossen wird. Verträge stellen ein ergebnisorientiertes Kontrollinstrument dar. Das definieren von Service Level Agreements dient somit der Überwachung und Sicherstellung zur Zielerreichung. &lt;br /&gt;
Hierfür werden u.a. eine Service-Qualität und Leistungsmerkmale festgelegt, die dem Dienst, bzw. dem Dienstvertrag zugeordnet sind. Die festgelegten Kriterien, dienen der späteren Ergebniskontorolle (Überwachung und Reporting). Festgelegte Kennzahlen schränken zudem opportunistisches Verhalten der Service-Lieferanten ein.&lt;br /&gt;
&lt;br /&gt;
=== Überwachung un Reporting ===&lt;br /&gt;
...&lt;br /&gt;
=== Was gehört zu IVS-Governance ===&lt;br /&gt;
====Prozesse einer IVS-Governance==== &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
====Prozesse einer IVS-Governance====&lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards und &lt;br /&gt;
* ein Repository&lt;br /&gt;
&lt;br /&gt;
==Literaturverzeichnis==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9193</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=9193"/>
		<updated>2016-12-08T10:47:20Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Definition (Allgemein) ==&lt;br /&gt;
Governance soll sicherstellen, dass alle Interessen der Stakeholder und festgelegte Ziele, die organisationsweit festgelegt wurden, erreicht werden. Zur Sicherstellung dessen, müssen Priorisierungen durchgeführt, Entscheidungen getroffen, Performance überwacht werden. &lt;br /&gt;
&lt;br /&gt;
Es müssen also Vorgaben gemacht werden, damit sichergestellt wird, dass die vorher festgelegten Ziele erreicht werden. Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. Überdies muss eine Entscheidung getroffen werden, WER die jeweiligen Vorgaben in WELCHEM Bereich macht.&lt;br /&gt;
&lt;br /&gt;
== Governanve vs. Management ==&lt;br /&gt;
Wichtig ist, dass zwischen Governance und Management unterschieden werden muss. Beide Disziplinen unterscheiden sich in ihren Gestaltungsbereichen. Sie unterscheiden sich hinsichtlich&lt;br /&gt;
* ihren Zwecks,&lt;br /&gt;
* ihren Verantwortlichkeiten,&lt;br /&gt;
* und ihren Aktivitäten.&lt;br /&gt;
&lt;br /&gt;
Während Governance sich darauf fokussiert&lt;br /&gt;
* zu '''bewerten''' (über Ziele, die erreicht werden sollen abzustimmen und festzulegen),&lt;br /&gt;
* zu '''lenken''' (damit Ziele erreicht werden, müssen Priorisierungen durchgeführt und Entscheidungen getroffen werden)&lt;br /&gt;
* und zu '''überwachen''' (damit Ziele durch ausgeführte Aktivitäten erreicht werden),&lt;br /&gt;
&lt;br /&gt;
fokussiert sich Management auf &lt;br /&gt;
* das Planen, &lt;br /&gt;
* das Festlegen, &lt;br /&gt;
* das Durchführen &lt;br /&gt;
* und das Überwachen  &lt;br /&gt;
von Aktivitäten zur Erreichung der Ziele. Das Management stellt also sicher, dass Aktivitäten durchgeführt und überwacht werden. Außerdem stellt es sicher, dass die Aktivitäten so gelenkt werden, wie es die Vorgaben der Governance festlegen.&lt;br /&gt;
&lt;br /&gt;
== Governance-Aktivitäten ==&lt;br /&gt;
Die Ausführung von Governance-Aktivitäten unterscheiden sich hinsichtlich Größe, Struktur und Komplexität in der auszuführenden Organisation und müssen demensprechend ausgerichtet werden. Nachfolgend werden mögliche Governance-Aktivitäten aufgelistet. &lt;br /&gt;
* '''Vorgaben''' treffen, um Ziele zu erreichen&lt;br /&gt;
* '''Zuständigkeiten''' festlegen, wer Vorgaben macht&lt;br /&gt;
* '''Service Level Agreements''' (SLA’s) definieren&lt;br /&gt;
* '''Überwachung und Reporting'''&lt;br /&gt;
&lt;br /&gt;
=== Vorgaben === &lt;br /&gt;
1) Arten von Vorgaben für IVS-Wertschöpfungsketten&lt;br /&gt;
* räumlich/verkehrspolitisch&lt;br /&gt;
* wirtschaftlich, förderungstechnisch&lt;br /&gt;
* rechtlich (EU, national, regional)&lt;br /&gt;
* normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
2) Gesetzliche und rechtliche Grundlagen&lt;br /&gt;
* Europäische und nationale Gesetze und Regulierungen &lt;br /&gt;
** rechtlich&lt;br /&gt;
** fachlich&lt;br /&gt;
* Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
* Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
* Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...) &lt;br /&gt;
&lt;br /&gt;
3) Finanzierung gemeinsamer Ressourcen&lt;br /&gt;
* Finanzielle Beteiligung der Partner &lt;br /&gt;
* Förderquellen &lt;br /&gt;
* Verteilung der Einkünfte &lt;br /&gt;
&lt;br /&gt;
4) Organisation der Operativen Betriebs&lt;br /&gt;
* Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Organisationseinheit mit Adresse, Ansprechpartner und Stellvertreter) &lt;br /&gt;
* Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen &lt;br /&gt;
* Sprachen für die Kommunikation (bei Cross-Border Kooperationen) &lt;br /&gt;
* Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
* Time-Out Kriterien &lt;br /&gt;
&lt;br /&gt;
5) Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten&lt;br /&gt;
* Räumlich/Verkehrspolitisch &lt;br /&gt;
* Wirtschaftlich, Förderungstechnisch &lt;br /&gt;
* Rechtlich (EU, national, regional) &lt;br /&gt;
* Normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|center|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
=== Service Level Agreements ===&lt;br /&gt;
&lt;br /&gt;
=== Überwachung un Reporting ===&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
=== Was gehört zu Governance ===&lt;br /&gt;
&lt;br /&gt;
Prozesse einer EA-Governance: &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
&lt;br /&gt;
Inhalt: &lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards&lt;br /&gt;
* und ein Repository&lt;br /&gt;
&lt;br /&gt;
== Notwendigkeit von Governance ==&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. &lt;br /&gt;
Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF):&lt;br /&gt;
&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Governance im IVS-Kontext ==&lt;br /&gt;
Vorgaben durch IVS-Rahmen- und -Referenzarchitekturen:&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
&lt;br /&gt;
Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.)&lt;br /&gt;
 &lt;br /&gt;
Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
&lt;br /&gt;
Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden auch hier sollten Governance Strukturen hinterlegt werden. &lt;br /&gt;
&lt;br /&gt;
Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=8127</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=8127"/>
		<updated>2016-11-08T13:03:27Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Festlegung von Zuständigkeiten für Vorgaben */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== IVS-Governance ==&lt;br /&gt;
&lt;br /&gt;
=== Definition Governance ===&lt;br /&gt;
Ensures that stakeholder needs, conditions and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritization and decision making; and monitoring performance and compliance against agreed-on direction and objectives.&lt;br /&gt;
Governance stellt also sicher, dass zuvor gesetzte Ziele erreicht werden. Dies geschieht durch Vorgaben und Überprüfung der Einhaltung dieser Vorgaben. &lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. &lt;br /&gt;
Zentral in der Diskussion um Governance ist auch, dass festgelegt werden muss, WER die Vorgaben für welche Bereiche macht. &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
[[Datei:Festlegung_von_Zuständigkeiten_Governance.jpg|thumb|center|400px|Beispiel: Festlegung von Zuständigkeiten]]&lt;br /&gt;
&lt;br /&gt;
=== Arten von Vorgaben für IVS-Wertschöpfungsketten ===&lt;br /&gt;
* räumlich/verkehrspolitisch &lt;br /&gt;
* wirtschaftlich, förderungstechnisch &lt;br /&gt;
* rechtlich (EU, national, regional) &lt;br /&gt;
* normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. &lt;br /&gt;
Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF):&lt;br /&gt;
&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support. &lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu Governance ===&lt;br /&gt;
&lt;br /&gt;
Prozesse einer EA-Governance: &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
&lt;br /&gt;
Inhalt: &lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards&lt;br /&gt;
* und ein Repository&lt;br /&gt;
&lt;br /&gt;
=== Gesetzliche und rechtliche Grundlagen ===&lt;br /&gt;
* Europäische und nationale Gesetze und Regulierungen  &lt;br /&gt;
** rechtlich&lt;br /&gt;
** fachlich&lt;br /&gt;
&lt;br /&gt;
*Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
** Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
** Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...)&lt;br /&gt;
&lt;br /&gt;
===Finanzierung gemeinsamer Ressourcen ===&lt;br /&gt;
* Finanzielle Beteiligung der Partner&lt;br /&gt;
*Föderquellen&lt;br /&gt;
*Verteilung der Einkünfte&lt;br /&gt;
&lt;br /&gt;
=== Organisation der Operativen Betriebs ===&lt;br /&gt;
*Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Oragnaistaionseinheit mit Adresse, Ansprechpartner und Stellvertreter)&lt;br /&gt;
*Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen&lt;br /&gt;
*Sprachen für die Kommunikation (bei Cross-Border Kooperationen)&lt;br /&gt;
*Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
*Time-Out Kriterien&lt;br /&gt;
&lt;br /&gt;
=== Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten ===&lt;br /&gt;
*Räumlich/Verkehrspolitisch&lt;br /&gt;
*Wirtschaftlich, Förderungstechnisch&lt;br /&gt;
*Rechtlich (EU, national, regional)&lt;br /&gt;
*Normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Governance im IVS-Kontext ==&lt;br /&gt;
Vorgaben durch IVS-Rahmen- und Referenzarchitekturen:&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.) &lt;br /&gt;
Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden  auch hier sollten Governance Strukturen hinterlegt werden. &lt;br /&gt;
Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=Datei:Festlegung_von_Zust%C3%A4ndigkeiten_Governance.jpg&amp;diff=8126</id>
		<title>Datei:Festlegung von Zuständigkeiten Governance.jpg</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=Datei:Festlegung_von_Zust%C3%A4ndigkeiten_Governance.jpg&amp;diff=8126"/>
		<updated>2016-11-08T13:00:53Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=8125</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=8125"/>
		<updated>2016-11-08T12:59:14Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Governance im IVS-Kontext */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== IVS-Governance ==&lt;br /&gt;
&lt;br /&gt;
=== Definition Governance ===&lt;br /&gt;
Ensures that stakeholder needs, conditions and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritization and decision making; and monitoring performance and compliance against agreed-on direction and objectives.&lt;br /&gt;
Governance stellt also sicher, dass zuvor gesetzte Ziele erreicht werden. Dies geschieht durch Vorgaben und Überprüfung der Einhaltung dieser Vorgaben. &lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. &lt;br /&gt;
Zentral in der Diskussion um Governance ist auch, dass festgelegt werden muss, WER die Vorgaben für welche Bereiche macht. &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
BILD&lt;br /&gt;
&lt;br /&gt;
=== Arten von Vorgaben für IVS-Wertschöpfungsketten ===&lt;br /&gt;
* räumlich/verkehrspolitisch &lt;br /&gt;
* wirtschaftlich, förderungstechnisch &lt;br /&gt;
* rechtlich (EU, national, regional) &lt;br /&gt;
* normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. &lt;br /&gt;
Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF):&lt;br /&gt;
&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support. &lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu Governance ===&lt;br /&gt;
&lt;br /&gt;
Prozesse einer EA-Governance: &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
&lt;br /&gt;
Inhalt: &lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards&lt;br /&gt;
* und ein Repository&lt;br /&gt;
&lt;br /&gt;
=== Gesetzliche und rechtliche Grundlagen ===&lt;br /&gt;
* Europäische und nationale Gesetze und Regulierungen  &lt;br /&gt;
** rechtlich&lt;br /&gt;
** fachlich&lt;br /&gt;
&lt;br /&gt;
*Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
** Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
** Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...)&lt;br /&gt;
&lt;br /&gt;
===Finanzierung gemeinsamer Ressourcen ===&lt;br /&gt;
* Finanzielle Beteiligung der Partner&lt;br /&gt;
*Föderquellen&lt;br /&gt;
*Verteilung der Einkünfte&lt;br /&gt;
&lt;br /&gt;
=== Organisation der Operativen Betriebs ===&lt;br /&gt;
*Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Oragnaistaionseinheit mit Adresse, Ansprechpartner und Stellvertreter)&lt;br /&gt;
*Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen&lt;br /&gt;
*Sprachen für die Kommunikation (bei Cross-Border Kooperationen)&lt;br /&gt;
*Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
*Time-Out Kriterien&lt;br /&gt;
&lt;br /&gt;
=== Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten ===&lt;br /&gt;
*Räumlich/Verkehrspolitisch&lt;br /&gt;
*Wirtschaftlich, Förderungstechnisch&lt;br /&gt;
*Rechtlich (EU, national, regional)&lt;br /&gt;
*Normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Governance im IVS-Kontext ==&lt;br /&gt;
Vorgaben durch IVS-Rahmen- und Referenzarchitekturen:&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.) &lt;br /&gt;
Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden  auch hier sollten Governance Strukturen hinterlegt werden. &lt;br /&gt;
Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=8124</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=8124"/>
		<updated>2016-11-08T12:58:51Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== IVS-Governance ==&lt;br /&gt;
&lt;br /&gt;
=== Definition Governance ===&lt;br /&gt;
Ensures that stakeholder needs, conditions and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritization and decision making; and monitoring performance and compliance against agreed-on direction and objectives.&lt;br /&gt;
Governance stellt also sicher, dass zuvor gesetzte Ziele erreicht werden. Dies geschieht durch Vorgaben und Überprüfung der Einhaltung dieser Vorgaben. &lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. &lt;br /&gt;
Zentral in der Diskussion um Governance ist auch, dass festgelegt werden muss, WER die Vorgaben für welche Bereiche macht. &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
BILD&lt;br /&gt;
&lt;br /&gt;
=== Arten von Vorgaben für IVS-Wertschöpfungsketten ===&lt;br /&gt;
* räumlich/verkehrspolitisch &lt;br /&gt;
* wirtschaftlich, förderungstechnisch &lt;br /&gt;
* rechtlich (EU, national, regional) &lt;br /&gt;
* normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. &lt;br /&gt;
Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF):&lt;br /&gt;
&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support. &lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu Governance ===&lt;br /&gt;
&lt;br /&gt;
Prozesse einer EA-Governance: &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
&lt;br /&gt;
Inhalt: &lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards&lt;br /&gt;
* und ein Repository&lt;br /&gt;
&lt;br /&gt;
=== Gesetzliche und rechtliche Grundlagen ===&lt;br /&gt;
* Europäische und nationale Gesetze und Regulierungen  &lt;br /&gt;
** rechtlich&lt;br /&gt;
** fachlich&lt;br /&gt;
&lt;br /&gt;
*Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
** Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
** Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...)&lt;br /&gt;
&lt;br /&gt;
===Finanzierung gemeinsamer Ressourcen ===&lt;br /&gt;
* Finanzielle Beteiligung der Partner&lt;br /&gt;
*Föderquellen&lt;br /&gt;
*Verteilung der Einkünfte&lt;br /&gt;
&lt;br /&gt;
=== Organisation der Operativen Betriebs ===&lt;br /&gt;
*Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Oragnaistaionseinheit mit Adresse, Ansprechpartner und Stellvertreter)&lt;br /&gt;
*Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen&lt;br /&gt;
*Sprachen für die Kommunikation (bei Cross-Border Kooperationen)&lt;br /&gt;
*Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
*Time-Out Kriterien&lt;br /&gt;
&lt;br /&gt;
=== Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten ===&lt;br /&gt;
*Räumlich/Verkehrspolitisch&lt;br /&gt;
*Wirtschaftlich, Förderungstechnisch&lt;br /&gt;
*Rechtlich (EU, national, regional)&lt;br /&gt;
*Normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Governance im IVS-Kontext ==&lt;br /&gt;
Vorgaben durch IVS-Rahmen- und Referenzarchitekturen:&lt;br /&gt;
Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.) &lt;br /&gt;
Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden  auch hier sollten Governance Strukturen hinterlegt werden. &lt;br /&gt;
Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=8123</id>
		<title>IVS-Governance</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Governance&amp;diff=8123"/>
		<updated>2016-11-08T12:57:28Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== IVS-Governance ==&lt;br /&gt;
&lt;br /&gt;
=== Definition Governance ===&lt;br /&gt;
Ensures that stakeholder needs, conditions and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritization and decision making; and monitoring performance and compliance against agreed-on direction and objectives.&lt;br /&gt;
Governance stellt also sicher, dass zuvor gesetzte Ziele erreicht werden. Dies geschieht durch Vorgaben und Überprüfung der Einhaltung dieser Vorgaben. &lt;br /&gt;
Die Vorgaben können sich z.B. auf Prozesse beziehen oder auf den Einsatz vorbestimmter Tools. &lt;br /&gt;
Zentral in der Diskussion um Governance ist auch, dass festgelegt werden muss, WER die Vorgaben für welche Bereiche macht. &lt;br /&gt;
&lt;br /&gt;
=== Festlegung von Zuständigkeiten für Vorgaben ===&lt;br /&gt;
Im ersten Schritt bei der Etablierung von Governance muss zunächst festgelegt werden, wer in welchem Bereich Entscheidungen bezüglich der Vorgaben machen soll. Hier ein Beispiel aus dem Bereich der Enterprise Architekturen: &lt;br /&gt;
&lt;br /&gt;
BILD&lt;br /&gt;
&lt;br /&gt;
=== Arten von Vorgaben für IVS-Wertschöpfungsketten ===&lt;br /&gt;
* räumlich/verkehrspolitisch &lt;br /&gt;
* wirtschaftlich, förderungstechnisch &lt;br /&gt;
* rechtlich (EU, national, regional) &lt;br /&gt;
* normativ (Richtlinien und Standards) &lt;br /&gt;
&lt;br /&gt;
=== Notwendigkeit von Governance ===&lt;br /&gt;
Governance ist deswegen von hoher Bedeutung, um sicherzustellen, dass alle Artefakte nach Vorgaben oder Vorschlägen „produziert“ werden und damit schlussendlich den gewünschten Nutzen zu erreichen. &lt;br /&gt;
Um sicherzustellen, dass hierfür definierte Prozesse und Artefakte existieren und ausgeführt werden können, sollte eine passende Umgebung geschaffen werden zur konkreten Ausführung der Governance. (Zur Überwachung der angebrachten Durchführung der Projekte können Referenzdaten aus existierenden Standards und Regularien verwendet und angewendet werden. (COBIT, ITIL)) &lt;br /&gt;
Schlüsselfaktoren für den Erfolg zur Schaffung einer funktionierenden Governance sind (laut TOGAF):&lt;br /&gt;
&lt;br /&gt;
* das Managen von Governance-Prozessen, &lt;br /&gt;
* das Bewerten der Übereinstimmung mit den definierten Vorgaben, &lt;br /&gt;
* das Festlegen von Service Level Agreements und Operational Level Agreements &lt;br /&gt;
* sowie die Nutzung von Vorlagen, Anpassung und Wiederverwendung,  &lt;br /&gt;
* die Festlegung von Vorgaben, Rollen, Fähigkeiten, dafür notwendige Strukturen und Service Support. &lt;br /&gt;
&lt;br /&gt;
=== Was gehört zu Governance ===&lt;br /&gt;
&lt;br /&gt;
Prozesse einer EA-Governance: &lt;br /&gt;
* Policy Management&lt;br /&gt;
* Compliance (Sicherstellung der Übereinstimmung)&lt;br /&gt;
* Dispensation&lt;br /&gt;
* Monitoring, Reporting&lt;br /&gt;
* Business Control&lt;br /&gt;
* Environment Management&lt;br /&gt;
&lt;br /&gt;
Inhalt: &lt;br /&gt;
* Anforderungen&lt;br /&gt;
* SLAs und OLAs&lt;br /&gt;
* Autoritätsstrukturen&lt;br /&gt;
* Standards&lt;br /&gt;
* und ein Repository&lt;br /&gt;
&lt;br /&gt;
=== Governance im IVS-Kontext ===&lt;br /&gt;
Vorgaben durch IVS-Rahmen- und Referenzarchitekturen:&lt;br /&gt;
Bei der Entwicklung von realen IVS-Diensten sollten die Vorgaben, die von Rahmen- und Referenzarchitektur aufgestellt wurden, beachtet werden. &lt;br /&gt;
Innerhalb des IVS-Projekts und im späteren Betrieb, muss sichergestellt werden, dass die teilnehmenden IVS-Akteure Informationen, Daten, etc. austauschen können/müssen und das möglichst reibungslos. Auch hierzu sind Governance-Strukturen notwendig. (z.B. Vertraglich geregelte Governance (SLAs) und relationale Governance hinsichtlich der Austauschperformance.) &lt;br /&gt;
Im Bereich der Serviceorientierung, spielen SLAs eine große und gewinnbringende Rolle, da lose gekoppelte Dienste aus verschiedenen Verantwortungsbereichen und Organisationen möglichst stabil und reibungslos zusammenarbeiten müssen. Daher sollten beispielsweise Schnittstellen definiert werden. &lt;br /&gt;
Zentral ist es auch bei unternehmensübergreifenden IVS-Diensten gemeinsame Gremien etablieren, die Entscheidungen bezüglich des IVS-Dienstes treffen können. &lt;br /&gt;
SLA für IVS-Dienste, SLA’s für alle Beteiligten zur Bereitstellung eines IVS-Dienstes. Ein Monitoring muss stattfinden  auch hier sollten Governance Strukturen hinterlegt werden. &lt;br /&gt;
Definierte SLAs werden ebenso in einem Repository abgelegt.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Gesetzliche und rechtliche Grundlagen ===&lt;br /&gt;
* Europäische und nationale Gesetze und Regulierungen  &lt;br /&gt;
** rechtlich&lt;br /&gt;
** fachlich&lt;br /&gt;
&lt;br /&gt;
*Rechtliche Gestaltung der Zusammenarbeit &lt;br /&gt;
** Rechtsform der Zusammenarbeit (Zusammenarbeit eigenständiger Partner, GmbH ...) &lt;br /&gt;
** Vertragsform (Kooperationsvertrag, Kooperationsvereinbarung, MoU-Memorandum of Understanding...)&lt;br /&gt;
&lt;br /&gt;
===Finanzierung gemeinsamer Ressourcen ===&lt;br /&gt;
* Finanzielle Beteiligung der Partner&lt;br /&gt;
*Föderquellen&lt;br /&gt;
*Verteilung der Einkünfte&lt;br /&gt;
&lt;br /&gt;
=== Organisation der Operativen Betriebs ===&lt;br /&gt;
*Kontaktpunkte der beteiligten IVS-Akteure (Verantwortliche Oragnaistaionseinheit mit Adresse, Ansprechpartner und Stellvertreter)&lt;br /&gt;
*Medien (inkl. Fall-Back) für die Kommunikation der IVS-Akteure auf allen Ebenen&lt;br /&gt;
*Sprachen für die Kommunikation (bei Cross-Border Kooperationen)&lt;br /&gt;
*Regeln und Konditionen für Kommunikation (Wer ist Client, wer ist Server)&lt;br /&gt;
*Time-Out Kriterien&lt;br /&gt;
&lt;br /&gt;
=== Regeln und Rahmenbedingungen für IVS-Wertschöpfungsketten ===&lt;br /&gt;
*Räumlich/Verkehrspolitisch&lt;br /&gt;
*Wirtschaftlich, Förderungstechnisch&lt;br /&gt;
*Rechtlich (EU, national, regional)&lt;br /&gt;
*Normativ (Richtlinien und Standards)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capibilities&amp;diff=8044</id>
		<title>IVS-Capibilities</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capibilities&amp;diff=8044"/>
		<updated>2016-10-30T17:42:22Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Interoperabilität als Anforderung - Beispiel */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Geschäftsfähigkeiten (Capabilities) in TOGAF == &lt;br /&gt;
&lt;br /&gt;
===Capability-Definition===&lt;br /&gt;
&lt;br /&gt;
[[Datei:TMValueChainMitPyramiden.png|thumb|right|350px|IVS-Wertschöpfungskette für einen Verkehrsmanagement-Service]]&lt;br /&gt;
&lt;br /&gt;
Mit '''Capability''' wird in TOGAF eine '''Fähigkeit''' bezeichnet, die eine Organisation, Person oder ein System besitzt. Capabilities werden mit allgemeinen bzw. übergeordneten Begriffen benannt und sind typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können. (Quelle: Bitkom, 2011 und TOGAF 9.1)&lt;br /&gt;
&lt;br /&gt;
Von strategischer Bedeutung für jedes Unternehmen sind sog. ''' Business Capabilities (Geschäfts-Fähigkeiten)'''. Sie kennzeichen Eigenschaften einer Institution/eines Unternehmens, die unbedingt erforderlich sind, damit es seine strategischen Ziele erreichen kann. &lt;br /&gt;
&lt;br /&gt;
'''Cabilities...'''&lt;br /&gt;
* sind die eigentlichen Bausteine für das Geschäft (Business) einer Institution/eines Unternehmens&lt;br /&gt;
* repräsentieren stabile geschäftliche Funktionen&lt;br /&gt;
* sind einzigartig und unabhängig voneinander&lt;br /&gt;
* abstrahieren von der Organisation einer Institution/eines Unternehmens&lt;br /&gt;
* repräsentieren letztlich das Geschäftsinteresse einer Institution/eines Unternehmens&lt;br /&gt;
&lt;br /&gt;
Das Besondere an Capabilities ist zum einen ihre Zeitstabilität, d.h. sie ändern sich sehr selten bzw. nur dann, wenn sich die strategische Ausrichtung einer Institution/eines Unternehmen ändert. Zum zweiten werden sie von der Fachseite erarbeitet und nicht wie oftmals üblich, von der IT-Seite diktiert. Insofern bilden sie eine Abstraktionsschicht zwischen Geschäfts- und IT-Prozessen.&lt;br /&gt;
&lt;br /&gt;
=== Capability-Dimensionen ===&lt;br /&gt;
&lt;br /&gt;
Wie nachfolgende Abbildung symbolisieren soll, wirkt sich die Schaffung von Capabilities in der Regel auf alle Ebenen (der IVS-Pyramide) einer Institution/eines Unternehmens aus. Dies wird mit den '''Dimensionen einer Capability''' bezeichnet und ist oft mit schwierigen Eingriffen in bestehende Unternehmens-/Institutions-Strukturen und mit entsprechenden, für die Beteiligten oft schmerzhaften Veränderungsprozessen verbunden. Vor diesem Hintergrund müssen Fähigkeiten in konkreten Dimensionen strukturiert werden. D.h. es gibt übergeordnete Fähigkeiten, die wiederum andere Fähigkeiten erfordern. Fähigkeiten sollten nicht redundant sein.&lt;br /&gt;
&lt;br /&gt;
[[Datei:Capa_dimensions.png| center| left | 400px| Capabilities: Ausprägung]]&lt;br /&gt;
&lt;br /&gt;
== Übertragung des Capability-Konzepts auf IVS-Architektur == &lt;br /&gt;
&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
[[Datei:IVSWertschöpfungsnetzwerk_neu.png|thumb|right|150px|IVS-Wertschöpfungsnetzwerk]]&lt;br /&gt;
&lt;br /&gt;
Im Sinne von IVS repräsentiert IVS-Capability einen Satz von Fähigkeiten, die ein IVS-Akteur als Bestandteil einer IVS-Prozesskette (IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk) mitbringen muss, damit am Ende der potentielle Nutzen des IVS-Dienstes verwirklicht werden kann. &lt;br /&gt;
&lt;br /&gt;
Dabei werden Anforderungen der End-Nutzer an den Nutzen von IVS-Diensten immer umfangreicher und komplexer. Daraus resultiert, dass die meisten IVS-Dienste nur über '''Kooperation''', d.h. die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure mit ganz spezifischen Fähigkeiten und Nutzenbeiträgen entstehen können (siehe auch [[IVS-Rollenkonzept | IVS-Wertschöpfungs- und Rollenkonzept]]). Vor diesem Hintergrund gewinnt „die Kooperation von IVS-Akteuren“ für IVS immer mehr an Bedeutung. Alle Lösungen im Bereich von IVS, d.h. technische Produkte oder Dienstangebote etc., müssen im Grundsatz dem Anspruch genügen, dass sie auch als Bestandteil einer Wertschöpfungskette bzw. eines Wertschöpfungsnetzwerks darstellbar sind. Daraus muss hervorgehen, in welcher Beziehung die beteiligten IVS-Akteure in ihren Rollen zusammenarbeiten und welche Fähigkeiten sie in welchen Dimensionen entwickeln müssen, um den von ihnen erwarteten Nutzen bzw. Mehrwert bei der Wertschöpfung generieren zu können.&lt;br /&gt;
&lt;br /&gt;
Vor diesem Hintergrund muss sich jeder einzelne IVS-Akteur, der sich an einer IVS-Wertschöpfungskette/einem IVS-Wertschöpfungsnetzwerk beteiligen will, die Frage stellen: &lt;br /&gt;
*über welche '''Capabilities (Fähigkeiten)''' er verfügen oder welche er noch entwickeln muss, damit eine erfolgreiche Kooperation und Wertschöpfung zustande kommen kann und&lt;br /&gt;
*welche '''Capability-Dimensionen''' die Entwicklung der Capabilities auf Menschen, Organisation, Prozesse und Technologien seiner Institution/seines Unternehmens haben werden.&lt;br /&gt;
&lt;br /&gt;
=== Interoperabilität als Schlüsseldimension der Kooperationsfähigkeit ===&lt;br /&gt;
[[Datei: IVS-Interoperabilität_Horizontal.png | thumb| right | 400px| Interoperabilität zwischen den Schichten der IVS-Architekturpyramide ]]&lt;br /&gt;
&lt;br /&gt;
Einer der Schlüssel für erfolgreiche Kooperation ist die '''Interoperabilität der beteiligten IVS-Akteure''' einer IVS-Werschöpfungskette/eines IVS-Wertschöpfungsnetzwerks. Im IVS-Kontext bedeutet Interoperabilität die Fähigkeit voneinander unabhängiger IVS-Akteure, mit u.U. ganz heterogenen Strategien, Geschäftsprozessen, Informationsstrukturen und IT-Systemen in IVS-Wertschöpfungsketten im Sinne der Informationslogistik möglichst nahtlos zusammenzuarbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen und am Ende dem Benutzer zur Verfügung zu stellen. &lt;br /&gt;
&lt;br /&gt;
Hier setzt das Interesse des IVS-Architekten und von IVS-Architektur ein. Der Begriff Interoperabilität darf nicht auf IT-Aspekte reduziert werden. Für den erfolgreichen Aufbau von IVS-Wertschöpfung muss Interoperabilität für alle Beteiligten nachvollziehbar auf allen Ebenen von IVS-Architektur hergestellt werden und durch entsprechende Architektur-Bausteine repräsentiert werden.&lt;br /&gt;
&lt;br /&gt;
Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten die [[IVS-Architekturprinzipien | '''IVS-Pyramide''']] vorgeschlagen. Im Kontext der Capability-Diskussion eignet sie sich besonders auch als Visualisierungsmodell für Interoperabilität auf allen Ebenen von IVS-Architektur.&lt;br /&gt;
&lt;br /&gt;
=== Formen von Interoperabilität ===&lt;br /&gt;
&lt;br /&gt;
Im IVS-Architekturkontext ist Interoperabilität Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide dargestellt - die obere Abbildung.&lt;br /&gt;
&lt;br /&gt;
Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei unterschiedliche Formen von Interoperabilität unterschieden werden:&lt;br /&gt;
&lt;br /&gt;
* '''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen &lt;br /&gt;
* '''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen&lt;br /&gt;
&lt;br /&gt;
Die ''' Kommunikative Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''kommunikativen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Hier kommen in der Regel nationale und zukünftig immer mehr europäische bzw. internationale IVS-Normen und -Standards für Kommunikation und Daten zum Einsatz (siehe auch [[TOGAF-Phase C | TOGAF Phase C – Informationssystem-Architektur ]])&lt;br /&gt;
&lt;br /&gt;
Die ''' Verhaltens-Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''funktionalen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Es liegt in der Natur der Sache, dass für jede spezifische IVS-Domäne bzw. jeden spezifischen IVS-Dienst fachbezogen ganz unterschiedliche Verhaltens-Interoperabilitäten erforderlich sind. Aber auch hier kommen mehr und mehr nationale und auch europäische IVS-Richtlinien und Spezifikationen zum Einsatz. &lt;br /&gt;
&lt;br /&gt;
Beispiele für funktionale Richtlinien und Spezifikationen im Sinne von IVS-Verhaltens-Interoperabilität:&lt;br /&gt;
*Technologiearchitekturen und Standards (z.B. ETSI-Standard)&lt;br /&gt;
*Europäische Implementierungsrichtlinien, z.B. EasyWay Deployment Guidelines &lt;br /&gt;
*Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)&lt;br /&gt;
*Architekturmuster (z.B. Service Orientierte Architektur, SOA)&lt;br /&gt;
*Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, REST, JSON, WS-*). &lt;br /&gt;
*Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)&lt;br /&gt;
*Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)&lt;br /&gt;
&lt;br /&gt;
== Interoperabilität als Anforderung - Beispiel ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Datei: CapabilityAlsAnforderung.PNG | thumb | right | 180px | Interoperabilität als Anforderungen]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung von IVS-Diensten ist grundsätzlich nicht davon auszugehen, dass die beteiligten IVS-Akteure - auch wenn sie vom Grundsatz her schon über die in Rede stehende Capability verfügen - von Hause aus interoperabel sind. Sind die entsprechenden Capability-Dimensionen für Interoperabilität noch nicht vorhanden, so kann man die zukünftig zu entwickelnden Capability-Dimensionen im Sinne von Requirements verstehen. Wie nebenstehende Abbildung symbolisieren soll, können diese Anforderungen Auswirkungen auf allen Ebenen von IVS-Architektur, und zwar an Schnittstellen nach Außen aber auch innerhalb der Organisation haben:&lt;br /&gt;
&lt;br /&gt;
Als '''Beispiel''' sei die Kooperation einer Stadt mit einem privaten Navigationsdienstleister im Rahmen einer '''Alternativroutensteuerung''' genannt. Die Kooperationsvereinbarung enthält u.a. folgendes:&lt;br /&gt;
&lt;br /&gt;
* die Stadt verpflicht sich zur kostenpflichtigen Abnahme von FCD-Daten, die der private Navigationsdienstleister zur Verfügung stellen kann.  &lt;br /&gt;
* als Gegenleistung verpflichtet sich der private Navigationsdienstleister, sich bei seinen Routenempfehlungen &amp;quot;stragiekonform&amp;quot; zu verhalten, das heißt die '''Capabilty &amp;quot;Stragiekonformes Routen&amp;quot;''' zu entwickeln. &lt;br /&gt;
&lt;br /&gt;
Mit dieser Vereinbarung sind u.a. folgende Anforderungen an das Verhalten des Navigationsdienstleisters verbunden ('''Capability-Diemsionen'''):&lt;br /&gt;
;Strategie-Ebene: der Navigationsdienstleister muss seine Service-Strategie für seinen Kunden dahingehend anpassen, dass er seinen Kunden nicht grundsätzlich die individuell günstigste Route zu einem Ziel anbietet, sondern dass er die Routenempfehlungen der Stadt einbezieht, insbesondere Tempo 30 - Zonen von der Routenempfehlung ausnimmt.&lt;br /&gt;
;Geschäftsprozess-Ebene: der Navigationsdienstleister muss seine Geschäftsprozesse auf die Kommunikation mit der Stadt hin ausbauen.&lt;br /&gt;
;Informations-Ebene: der Navigationsdienstleister muss seine Informationsstrukturen um das Datenmodell der Alternativroutenempfehlungen der Stadt erweitern. Auf der anderen Seite muss er ein Datenmodell für FCD-Daten entwickeln, das die Stadt verarbeiten kann.&lt;br /&gt;
;Informations-Ebene: der Navigationsdienstleister muss neue IT-Dienste für den Austausch von Alternativrouten (Client-Service) und FCD-Daten (Server-Service) bereitstellen.&lt;br /&gt;
;Infrastruktur-Ebene: der Navigationsdienstleister muss eine permanente Netzverbindung mit der Stadt herstellen.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=Grundlegende_IVS-Architekturkonzepte&amp;diff=7678</id>
		<title>Grundlegende IVS-Architekturkonzepte</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=Grundlegende_IVS-Architekturkonzepte&amp;diff=7678"/>
		<updated>2016-10-18T11:38:35Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Im Folgenden sind grundlegende Konzepte  aufgelistet, die den IVS-Architektur-Ansatz und die Bedeutung der IVS-Architektur-Bausteine und -Deliverables ausführlich erläutern. Demjenigen, der sich ernsthaft mit dem IVS-Architekturansatz beschäftigen und auseinandersetzen möchte, wird empfohlen, diese Konzepte zu lesen. Eine kritisiche Durchsicht und Kommentierung der Konzepte ist willkommen (Hanfried.Albrecht@AlbrechtConsult.com). &lt;br /&gt;
*[[IVS-D%C3%B6m%C3%A4nen | Das IVS-Domänenkonzept]]&lt;br /&gt;
*[[IVS-Dienste-Konzept | Das IVS-Dienste- und IVS-Wertschöpfungs-Konzept]]&lt;br /&gt;
*[[IVS-Rollenkonzept | Das IVS-Rollenkonzept]]&lt;br /&gt;
*[[IVS-Geschäftsziele | Das Konzept für die Formulierung von IVS-Zielen und IVS-Realisierungsvorstellungen]]&lt;br /&gt;
*[[IVS-Capibilities | Das IVS-Capability und -Zusammenarbeitskonzept]]&lt;br /&gt;
*[[Hilfsmittel, Sichten und Werkzeuge für IVS-Geschäftsarchitektur]]&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Rollenkonzept&amp;diff=7677</id>
		<title>IVS-Rollenkonzept</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Rollenkonzept&amp;diff=7677"/>
		<updated>2016-10-18T07:22:46Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Arten von IVS-Rollen */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Grundlagen ==&lt;br /&gt;
&lt;br /&gt;
Die Befassung mit Rollen und Geschäftsmodellen im Kontext von IVS setzt die Verfügbarkeit eines Modells voraus, das die Semantik für eine typisierte Beschreibung der Rollen liefert und das von allen Beteiligten als Diskussions- und Beschreibungsgrundlage akzeptiert wird. &lt;br /&gt;
&lt;br /&gt;
=== Definition ===&lt;br /&gt;
''' IVS-Rolle...'''&lt;br /&gt;
*ist ein '''IVS-Architekturbaustein''', mit dem Stereotypen von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.&lt;br /&gt;
*ist ein '''signifikanter Bestandteil von IVS-Wertschöpfungsketten für IVS-Informationslogistik''', der von '''IVS-Akteuren und IVS-Stakeholdern''' je nach Erforderniss des zu realisierenden IVS-Dienstes eingenommen wird, wobei ein einzelner IVS-Akteur oder IVS-Stakeholder eine oder mehrere IVS-Rollen besetzen kann.&lt;br /&gt;
*'''operationalisiert seine IVS-Fähigkeiten und IVS-Verantwortlichkeiten in Geschäftsprozessen''' in Form von '''Aktivitäten''', die mit den Aktivitäten anderer IVS-Rollen die IVS-Geschäftsprozesse von IVS-Diensten bilden.  &lt;br /&gt;
*wird in '''IVS-Referenzarchitekturen von Stereotypen von IVS-Akteuren''', in '''IVS-Architekturen realer IVS-Dienste von konkreten Instanzen von Stereotypen von IVS-Akteuren''' eingenommen.&lt;br /&gt;
&lt;br /&gt;
=== Arten von IVS-Rollen ===&lt;br /&gt;
Generell können zwei Arten von IVS-Rollen mit ganz unterschiedlicher Ausprägung unterschieden werden:&lt;br /&gt;
&lt;br /&gt;
*'''Ökonomische IVS-Rollen''': &lt;br /&gt;
**Entwicklung der notwendigen ökonomischen Rahmenbedingungen (rechtliche Grundlagen, Regeln, Finanzierung, ...) und Bereitstellen der administrativen Ressourcen für das Zustandekommen eines IVS-Dienstes. &lt;br /&gt;
**Administratrives und ökonomisches Management (Governance) des IVS-Dienstes während des Betriebs.&lt;br /&gt;
*'''Technische IVS-Rollen''': &lt;br /&gt;
**Entwicklung der notwendigen technischen Rahmenbedingungen (technische Standards, notwendige IT und Infrastruktur...) und Bereitstellung der betrieblichen Ressourcen für das Zustandekommen eines IVS-Dienstes.&lt;br /&gt;
**Durchführung des technischen Betriebs des IVS-Dienstes.&lt;br /&gt;
&lt;br /&gt;
=== Wertigkeiten von Rollen (Power-Grid) ===&lt;br /&gt;
[[Datei:Power Grid zur Stakeholderanalyse_Konsortium MRK-AMADEUS.JPG|thumb | right | 400px|]]&lt;br /&gt;
&lt;br /&gt;
'''IVS-Rollen haben unterschiedliche Wertigkeiten''' in Bezug auf das Zustandekommen und für den Betrieb eines IVS-Dienstes. Das '''Rollen-Power-Grid Modell''' der Open Group unterscheidet 4 unterschiedliche Wertigkeiten (siehe nebenstehndes Bild).    &lt;br /&gt;
*'''IVS-Schlüsselrollen''' (Power Grid D:Key-Players)&lt;br /&gt;
**ökonomische IVS-Rollen, die für das Zustandekommen von IVS-Diensten erforderlich sind, z.B. durch Schaffung von der notwendigen politischen, rechtlichen und finanziellen Rahmenbedingungen.&lt;br /&gt;
**technische, ohne die ein IVS-Dienst nicht betrieben werden kann und die direkt an der Wertschöpfung eines IVS-Dienstes beteiligt sind.&lt;br /&gt;
*'''Involvierte IVS-Rollen''' (Power Grid C: Keep satisfied)&lt;br /&gt;
**IVS-Rollen, d.h die zwar nicht direkt an der Wertschöpfung eines IVS-Dienstes beteiligt sind, für die der IVS-Dienst aufgrund einer Zusammenarbeit mit den IVS-Schlüsselrollen mit direkten Auswirkungen verbunden ist.&lt;br /&gt;
*'''Interessierte IVS-Rollen''' (Power Grid B: Keep informed)&lt;br /&gt;
**Interessengruppen, die als Interessengemeinschaft von IVS-Diensten betroffen sind&lt;br /&gt;
*'''Sonstige IVS-Rollen''' (Power Grid A: Minimal Effort)&lt;br /&gt;
**IVS-Rollen, die am Rande beteiligt sind, auf die der IVS-Dienst aber weder eine Auswirkung hat noch mit einem Interesse verbunden sind&lt;br /&gt;
&lt;br /&gt;
=== Institutionelle Rollenmodelle als Grundlage der IVS-Wertschöpfung (IVS-Schlüssel-Rollen)===&lt;br /&gt;
&lt;br /&gt;
==== Einführung ====&lt;br /&gt;
&lt;br /&gt;
Für das IVS-Rollenmodell wird ein '''institutioneller Rollenmodell-Ansatz''' herangezogen, der im Projekt [http://www.converge-online.de/ CONVERGE] speziell für die '''Darstellung und Beschreibung von Rollen zur Realsierung von Kooperativen IVS-Diensten''' angewendet wurde.&lt;br /&gt;
&lt;br /&gt;
Im Kontext von IVS-Rollen wird unter '''institutionell''' verstanden, das von einer IVS-Rolle als Unternehmen bzw. Organisation '''ein bestimmtes wirtschaflichtes, operatives und technisches Verhalten und Handeln erwartbar''' ist (z.B. Straßenverkehrsbehörden genehmigen und ordnen an, Öffentliche Straßenbetreiber managen Verkehr kollektiv, private Navigationsdienstleister sind gewinnorintert und berechnen die Route nach den Wünschen des individuellen Kunden...)  &lt;br /&gt;
&lt;br /&gt;
Der Ansatz der institutionellen Rollenmodelle benötigt '''zwei Inputvektoren'''. Hierzu müssen die '''ökonomischen und technischen IVS-Rollen''' identifiziert werden.&lt;br /&gt;
&lt;br /&gt;
=== Ökonomisches IVS-Rollenmodell ===&lt;br /&gt;
Bei den ökonomischen Rollen werden im Wesentlichen die '''klassischen betriebswirtschaftlichen Rollen''' vorgegeben und '''durch die spezifischen, durch die Wertschöpfung geprägten, Rollen ersetzt'''. Der konzeptionelle Charakter des Ansatzes erfordert einen relativ hohen Abstraktionsgrad der Rollen. Daher werden die für die Untersuchung abgeleiteten Rollen als Meta-Rollen bezeichnet. &lt;br /&gt;
&lt;br /&gt;
'''Ökonomische IVS-Rollen''' sind:&lt;br /&gt;
*'''IVS-Business Management''' &lt;br /&gt;
** Die Rolle umfasst im Rahmen der '''Einführungsphase die Entscheidungsbefugnis zur Einführung von IVS-Diensten''' und im Rahmen der '''Betriebsphase sowohl strategische als auch operative Änderungen''', in der Art und Weise wie die IVS-Dienste betrieben werden, durchzusetzen. &lt;br /&gt;
**Wird diese Rolle durch eine '''staatliche Institution''' wahrgenommen, umfassen die damit verbundenen Aktionen das klassische Spektrum über '''Dienstanweisungen, Rechtsverordnungen, Gesetze, Direktiven''' und andere. &lt;br /&gt;
**Wird diese Rolle durch eine '''private Institution''' wahrgenommen, umfasst sie die Funktion der '''Unternehmensführung'''.&lt;br /&gt;
 &lt;br /&gt;
*'''IVS-Service-Angebot''' &lt;br /&gt;
**Die Rolle erfasst alle Aktionen, die eine '''IVS-spezifische Wertschöpfung durch Services''' schaffen. Das schließt die '''Konzeption des Services''' im Allgemeinen ein, wie auch die Entscheidung darüber, '''wer den Service anbietet und wie dieser bepreist''' wird. &lt;br /&gt;
**Die Entscheidung darüber, ob der Service '''selbst erstellt oder durch Dritte angeboten''' wird, liegt allerdings im '''Entscheidungsbereich der IVS-Business Management-Rolle'''. &lt;br /&gt;
&lt;br /&gt;
*'''IVS-Human Resources''' &lt;br /&gt;
**Die Rolle ist eine '''zentrale Rolle für die Umsetzung der IVS-Dienste'''. Die Kernaufgabe ist die '''Bereitstellung und der zielorientierte Einsatz von Personal''', um IVS-Dienste einzuführen und zu betreiben. &lt;br /&gt;
**In der '''konzeptionellen Planung eines IVS-Dienstes werden die Institutionen identifiziert'''. Im Falle der Umsetzung wird diese Rolle '''von den relevanten Institutionen so konkretisiert''', dass eine personelle Zuordnung ermöglicht wird. &lt;br /&gt;
&lt;br /&gt;
*'''IVS-Financial Management''' &lt;br /&gt;
**Diese Rolle soll sicherstellen, dass sowohl die '''Anfangsinvestitionen als auch die Ersatzinvestitionen finanziert''' werden können. Wie sich die '''Finanzierung gestaltet''', hängt hier auch davon ab, ob eine '''staatliche Institution oder eine private''' Institution in der Finanzierungsverantwortung steht. &lt;br /&gt;
**Im Falle '''staatlicher Institutionen''' dürften '''steuer- und/oder gebührenfinanzierte Lösungen''' im Vordergrund stehen. &lt;br /&gt;
**'''Private Investitionen''' können neben der '''Innenfinanzierung''' auf die '''klassischen Instrumente der Außenfinanzierung (Beteiligungsfinanzierung, Fremdfinanzierung)''' und Sonderformen der Finanzierung (Factoring) zurückgreifen.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Controlling''' &lt;br /&gt;
**Diese Rolle umfasst vor allem Aufgaben des '''internen Rechnungswesens'''. Neben der richtigen Erfassung der Kosten und Erlöse erfüllt das '''IVS-Controlling eine Unterstützungsfunktion für die Meta-Rolle IVS-Business Management'''. &lt;br /&gt;
**Auch hier ist im Rahmen der Umsetzung darauf zu achten, dass die zu erfassenden '''ökonomischen Größen unterschiedlich definiert''' werden können, wenn es sich entweder um '''staatliche''' oder '''private Institutionen''' handelt. &lt;br /&gt;
**Bei einer '''staatlichen Ausübung''' dieser Rolle können z.B. neben den für den Betrieb notwendigen '''betriebswirtschaftlichen Kosten und Erlösen auch gesamtwirtschaftliche Kosten und gesamtwirtschaftliche Nutzen''' erfasst werden, um die Entscheidungen über Einführung und Betrieb von IVS-Diensten unter volkswirtschaftlichen Gesichtspunkten zu optimieren.&lt;br /&gt;
&lt;br /&gt;
==== Technisches IVS-Rollenmodell ====&lt;br /&gt;
&lt;br /&gt;
Als Vorschlag für eine Technisches Rollenmodell wird ein Modell herangezogen, das im '''Projekt EasyWay speziell für die Darstellung und Beschreibung von Wertschöpfungsketten und -netzwerken''' für Verkehrsinformationsdienste entwickelt worden und in folgender Abbildung dargestellt ist:&lt;br /&gt;
&lt;br /&gt;
[[datei:IVSWertschöpfungsmodell.png | thumb | center | 500px | EasyWay-Wertschöpfungskette für Verkehrsinformationsdienste]]&lt;br /&gt;
&lt;br /&gt;
Das Modell enthält vier IVS-Rollen, die typischerweise zum Aufbau einer Informationslogistikette erforderlich sind:&lt;br /&gt;
&lt;br /&gt;
* ''' IVS-Inhalteanbieter''' (IVS-Content Provider)&lt;br /&gt;
**erstes Glied in der Wertschöpfungskette und Quelle, in der Regel auch Eigentümer (IVS-Content Owner) der in den IVS-Diensten verwendeten Daten und Informationen&lt;br /&gt;
**erfasst und verwaltet die Daten und Informationen, hält die Rechte zur Nutzung und Verteilung der Daten&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Dienstbetreiber''' (IVS-Service Operator)&lt;br /&gt;
**sammelt und verfeinert Rohdaten und -Informationen der IVS-Inhalteanbieter zu verwertbaren Mehrwert-Informationen (Schaffung von Added Value)&lt;br /&gt;
**wendet dazu unterschiedliche Methoden (Fusion von Daten, spezielle Algorithmen, Verkehrsmodelle...) an&lt;br /&gt;
**erzeugt Informationen mit identischem Inhalt für unterschiedliche IVS-Dienstanbieter und unterschiedliche IVS-Endgeräte von IVS-End-Nutzern (PC-Websites, PDAs, Smartphones usw.)  &lt;br /&gt;
**kann Clearing-Funktion bereitstellen, um die vollständige Kompatibilität unterschiedlicher IVS-Dienste zu unterstützen.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Kommunikationsnetzwerkbetreiber''' (IVS-Communication Network Provider)&lt;br /&gt;
**muss zuverlässige und ausreichend flexible Kommunikationskanäle für die nahtlose Verbindung von IVS-End-Nutzern, IVS-Endgeräten in Fahrzeugen, IVS-Straßeninfrastruktur und IVS-Dienste-Zentren bereitstellen&lt;br /&gt;
**ist verantwortlicher IVS-Schlüsselakteur für die Verbindung verschiedener Akteure mit unterschiedlichen Anforderungen &lt;br /&gt;
**seine Flexibilität ist ein Schlüsselfaktor, weil sich dies auf die Glaubwürdigkeit und Nutzung der Dienste durch Endkunden auswirkt.&lt;br /&gt;
**wird immer mehr selbst zum Inhalteanbieter (Mobilfunkbetreiber) &lt;br /&gt;
&lt;br /&gt;
*'''IVS-Dienstanbieter''' (IVS-Service Provider)&lt;br /&gt;
**realisiert und ist direkte Schnittstelle zum IVS-End-Nutzer &lt;br /&gt;
**muss neben der IVS-End-Nutzer-Information alle Funktionen für die Beziehung zum IVS-End-Nutzer bereitstellen (Rechnungsstellung, Kundenverwaltung oder Marketing, …)&lt;br /&gt;
**greift oft auf IVS-Dienste anderer IVS-Dienstanbieter zurück&lt;br /&gt;
**ist oft auch in der Rolle IVS-Dienstebetreibers&lt;br /&gt;
&lt;br /&gt;
*'''IVS-End-Nutzer '''&lt;br /&gt;
**ist Kunde des IVS-Dienstanbieters &lt;br /&gt;
**nutzt Informationen für private oder geschäftliche Zwecke&lt;br /&gt;
**keine homogene Gruppe, Anforderungen abhängig von persönlichen Anforderungen/Vorlieben und dem Nutzungszweck&lt;br /&gt;
&lt;br /&gt;
==== Weitere IVS-Rollen (IVS-Stakeholder)====&lt;br /&gt;
Neben den direkt an der Wertschöpfung beteiligten IVS-Rollen gibt es weitere wichtige IVS-Rollen: z.B.&lt;br /&gt;
* Technikhersteller und -lieferanten&lt;br /&gt;
* Standardisierungsorganisationen&lt;br /&gt;
* Verbände und Vertreter von Interessensgruppen&lt;br /&gt;
&lt;br /&gt;
==== Stereotypen von IVS-Akteuren als Instanzen von IVS-Rollen ==== &lt;br /&gt;
Im konkreten Falle der Konzeption, Einführung und des Betriebs eines IVS-Dienstes werden Rollen von konkreten IVS-Akteuren eingenommen. Folgende Liste zeigt Sterotypen von IVS-Akteuren: &lt;br /&gt;
&lt;br /&gt;
* '''Öffentliche Institutionen'''&lt;br /&gt;
** Gesetzgeber/Regulierungsbehörde&lt;br /&gt;
** Finanz- und Fördermittelgeber&lt;br /&gt;
** Öffentlicher Baulastträger&lt;br /&gt;
** Öffentlicher Straßenbetreiber&lt;br /&gt;
** Straßenverkehrsbehörde (Polizei)&lt;br /&gt;
** Öffentlicher Content- und Serviceoperator (Wetterdienst ...)  &lt;br /&gt;
** Öffentlicher Service Provider (Landesmeldestellen, Öffentliche Rundfunkanstalten, ...)&lt;br /&gt;
**...&lt;br /&gt;
&lt;br /&gt;
* '''Öffentliche/Private Institutionen'''&lt;br /&gt;
** Daten- und Informations-Broker (MDM)&lt;br /&gt;
** Standardisierungsorganistionen&lt;br /&gt;
&lt;br /&gt;
* ''' Private Content- und Serviceprovider '''&lt;br /&gt;
** Private Contentprovider, Serviceoperator und Serviceprovider (Navigationsdienstleister ...)&lt;br /&gt;
&lt;br /&gt;
* '''Industrie'''&lt;br /&gt;
** Verkehrstechnik-Industrie&lt;br /&gt;
** IKT-Industrie&lt;br /&gt;
** Autommobilindustrie&lt;br /&gt;
** Automobilzulieferer&lt;br /&gt;
** Kommunikationsinfrastrukturindustrie&lt;br /&gt;
&lt;br /&gt;
== Erfassung und Beschreibung von IVS-Rollen ==&lt;br /&gt;
=== Ziel der Erfassung von IVS-Rollen ===&lt;br /&gt;
Für die Entwicklung einer IVS-Referenzarchitektur oder die IVS-Architektur eines realen IVS-Dienstes, müssen in diesem Schritt die IVS-Rollen in die IVS-Wertschöpfung zu involvierenden IVS-Akteure beteiligenden IVS-Stakeholder erfasst und beschrieben werden.&lt;br /&gt;
&lt;br /&gt;
===Identifizierung der IVS-Rollen und ihre Beschreibung ===&lt;br /&gt;
&lt;br /&gt;
Für die Erfassung und Beschreibung der IVS-Rollen ist es zunächst - evtl. schon als Vorbereitung für den Schritt [[IVS-Architekturvision | Entwicklung einer IVS-Architekturvision ]] - erforderlich, eine erste Vorstellung für den IVS-Dienst selbst zu entwickeln und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöfungskette/im IVS-Wertschöpfungsnetzwerk wie folgt zu veranschaulichen.&lt;br /&gt;
&lt;br /&gt;
* Beschreibung (evtl. Visualisierung) des IVS-Dienstes und des damit verbundenen Nutzens für den Endkunden &lt;br /&gt;
* Beschreibung der dazu erforderlichen IVS-Informationslogistikkette &lt;br /&gt;
* Identifizierung der an der Wertschöpfung zu beteiligenden IVS-Rollen mit&lt;br /&gt;
** dem Grad der Beteiligung&lt;br /&gt;
** den wichtigsten Anliegen und Geschäftsanforderungen (Business Cases)&lt;br /&gt;
** deren Bedenken und Perspektiven&lt;br /&gt;
&lt;br /&gt;
In einem zweiten Schritt können die so identifizierten IVS-Rollen wie folgt weiter differenziert werden:&lt;br /&gt;
*Rechtsform und Aufgaben &lt;br /&gt;
*Geschäftsstrtegie und [https://de.wikipedia.org/wiki/Gesch%C3%A4ftsmodell IVS-Geschäftsmodell(e)] (Businness-Case) &lt;br /&gt;
*Kern-/Zusatzgeschäfte (Inhalte und Ziele), Finanzierungsmodelle &lt;br /&gt;
*Organisationsform, Schlüsselressourcen und Partnerschaften &lt;br /&gt;
*Wertschöpfungsprozesse &lt;br /&gt;
*Informationsstrukturen &lt;br /&gt;
*IT (IT-Dienste und IT-Infrastrukturen inkl. Datenbestand, Datenschnittstellen/Vernetzung&lt;br /&gt;
&lt;br /&gt;
=== Ergebnissdarstellung der Identifzierung der IVS-Rollen ===&lt;br /&gt;
&lt;br /&gt;
Zur Ergebnisdarstellung stellt die IVS-Rahmenarchitektur zwei Templates bereit: &lt;br /&gt;
&lt;br /&gt;
====[[Stakeholder-Erfassung | Das IVS-Rollen-Map Template]]====&lt;br /&gt;
Das IVS-Rollen-Map Template ist ein '''IVS-Architekturdeliverable (siehe [[IVS-RollenMap-Template | IVS-Rollen Map]])''', das die Stereoptypen von IVS-Akteuren und IVS-Stakeholdern deklariert und mit Ihren geschäftsanleigen und IVS-Rollen beschreibt.  &lt;br /&gt;
Außerdem '''klassifiziert es die Bedeutung von IVS-Akteuren und IVS-Stakeholdern''', die sie über ihre Rolle für den IVS-Dienst bzw. die IVS-Dienste-Kategorie erlangen (Power-Grid)&lt;br /&gt;
&lt;br /&gt;
Beispiele von IVS-Rollenbeschreibungen von IVS-Akteurs-Stereotypen mit Hilfe des IVS-Rollen-Map Template zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;7&amp;quot; | IVS-Rollenbeschreibung &lt;br /&gt;
|+&lt;br /&gt;
!IVS-Rolle für die IVS-Wertschöpfung !! IVS-Metarolle  !! IVS-Akteur ('''Ö'''=Ökonomische Rolle, '''T'''=Technische Rolle), IVS-Stakeholder  !! Schlüsselanliegen der IVS-Rolle !!IVS-Capabilities / IVS-Verantwortlichkeiten !!  Wertigkeit der IVS-Rolle (gemäß Power Grid)!!&lt;br /&gt;
IVS-Akteur bwz. IVS-Akteurs-Stereotyp) &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Dienst-Ersteller''' &lt;br /&gt;
(IVS-Dienst erstellen und an IVS-Dienst-Betreiber übergeben)&lt;br /&gt;
|IVS-Business und Financial Management&lt;br /&gt;
|IVS-Akteur (Ö)&lt;br /&gt;
|Erstellung von IVS-Diensten nach wirtschaflichen und technischen Grundsätzen&lt;br /&gt;
|Beschaffung der Finanzmittel für und Erstellung von IVS-Diensten   &lt;br /&gt;
|Key Player&lt;br /&gt;
|Öffentlicher Baulastträger&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''VM-Inhalte-Anbieter'''&lt;br /&gt;
(Statische und dynamische Verkehrsmanagementstrategien und -informationen  erheben und bereitstellen) und VM-Sercice-Betreiber&lt;br /&gt;
|IVS-Inhalte Anbieter (auch IVS-Inhalteeigentümer)&lt;br /&gt;
|IVS-Akteur (Ö und T)&lt;br /&gt;
|Verkehr nach politischen Vorgaben und fachlichen Grundsätzen optimal managen   &lt;br /&gt;
|Verkehrsmanagementstrategien und -informationen zur Realzeit feststellen&lt;br /&gt;
|Key Player&lt;br /&gt;
|Öffentlicher Straßenbetreiber (Verkehrsmanagement-Abteilung)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Baustellen-Inhalte-Anbieter''' &lt;br /&gt;
(Baustelleninformationen erheben und bereitstellen)&lt;br /&gt;
|IVS-Inhalte Anbieter (auch IVS-Inhalteeigentümer)&lt;br /&gt;
|IVS-Akteur (T)&lt;br /&gt;
|Sicherstellung der StVO-Konformität von Baustellen &lt;br /&gt;
|Genehmigung von Baustellen, Anordnung von Sperrungen und Umleitungen für Baustellen auf Fahrbahnen, Geh- und Radwegen nach StVO § 45(1)&lt;br /&gt;
|Key Player&lt;br /&gt;
|Straßenverkehrsbehörde&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Parken-Inhalte-Anbieter'''&lt;br /&gt;
(Statische und dynamischen Parkdaten erheben und bereitstellen)&lt;br /&gt;
|IVS-Inhalte Anbieter (auch IVS-Inhalteeigentümer)&lt;br /&gt;
|IVS-Akteur (T)&lt;br /&gt;
|Wirtschaftlicher Betrieb kostenpflichtiger Parkierungsanlagen &lt;br /&gt;
|Besetztgrad zuverlässig und in Realzeit erheben und publizieren&lt;br /&gt;
|Key Player&lt;br /&gt;
|Betreiber von kostenpflichtigen Parkierungsanlagen&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Dienste System-Lieferant''' &lt;br /&gt;
(Systeme, Software und Infrastruktur von IVS-Diensten anforderungsgerecht herstellen, liefern und unterhalten)&lt;br /&gt;
|Technikhersteller und -lieferant &lt;br /&gt;
|IVS-Stakeholder&lt;br /&gt;
|Herstellung und Verkauf von wettbewerbsfähigen Systemen, Software und Infrastruktur von IVS-Diensten &lt;br /&gt;
|Herstellung, Lieferung, Implementierung  und Unterhaltung sowie Vetrieb von Systemen, Software und Infrastruktur von IVS-Diensten&lt;br /&gt;
|Keep Informed&lt;br /&gt;
|Hersteller von Systemen, Software und Infrastruktur von IVS-Diensten&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
====[[IVS-Rollenkonzept#IVS-Rolle |Das IVS-Rollen Template]] ====&lt;br /&gt;
Das IVS-Rollen Template ist ein '''IVS-Architekturbaustein (siehe [[IVS-Rolle|IVS-Rolle]])''', mit dem Stereotypen von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.&lt;br /&gt;
&lt;br /&gt;
Ein Beispiel für die Beschreibung eines IVS-Akteurs in einer konkreten IVS-Rolle mit Hilfe des IVS-Rollen-Templates zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | Stammdaten der IVS-Rolle &lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Rolle''' (für die IVS-Wertschöpfung)&lt;br /&gt;
|Statische und dynamische Verkehrsmanagementstrategien und -informationen der städtsichen Seite erheben und bereitstellen &lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Art der IVS-Rolle''' {IVS-Akteur, IVS-Stakeholder}&lt;br /&gt;
|IVS-Akteur ('''Ö'''konomische und '''T'''echnische IVS-Rolle)&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Metarolle'''&lt;br /&gt;
|IVS-Inhalteanbieter (auch IVS-Inhalteeigentümer)&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Akteur(e) bzw. IVS-Akteurs-Stereotyp(en)''' für diese IVS-Rolle:&lt;br /&gt;
|Öffentlicher Straßenbetreiber Stadt (Amt für Verkehrsmanagement, Düsseldorf)&lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | Ziele und Interessen&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Verantwortungsbereich'''&lt;br /&gt;
|&lt;br /&gt;
*Zuständig für Planung, Bau, Betrieb und Unterhaltung der IVS-Infrastruktur der Stadt. &lt;br /&gt;
*Als Bauherr der rechtlich und wirtschaftlich verantwortliche Auftraggeber für die Errichtung der IVS-Infrastruktur und in diesem Sinne auch für die Projektierung, Auftragsvergabe, Bauabwicklung- und -überwachung, Abnahme  und den Betrieb der ITS-Infrastruktur sowie für die Anforderungen, die aus dieser Rolle erwachsen.&lt;br /&gt;
*Als Betreiber rechtlich und wirtschaftlich verantwortlich für den Betrieb des der IVS-Infrastruktur. Als Stellvertreter des Bürgers/ Verkehrsteilnehmers verantwortlich für die Sicherstellung von Sicherheit und Komfort des Verkehrsablaufs, die mit dem Einsatz des Systems bezweckt werden, sowie die Umsetzung und Einhaltung der Anforderungen, die aus dieser Rolle erwachsen.&lt;br /&gt;
Beim hoheitsübergreifenden Verkehrsmanagement in der Rolle des Ansprechpartners und verantwortlichen IVS-Akteurs auf der Seite der Stadt  &lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Ziele und Interessen Rolle'''&lt;br /&gt;
|&lt;br /&gt;
*Verkehrliche Ziele: Sicherstellung der Sicherheit und Leichtigkeit des Verkehrsablaufs für alle Nutzer des städtischen Straßennetzes.&lt;br /&gt;
*Betriebliche Ziele: Hohe Stabilität und Verfügbarkeit der IVS-Infrastruktur; hohe Sicherheit und Performance der Abläufe im System; hohe Qualität der bereitgestellten Informationen; effektive, wartungsarme und im Betrieb kostengünstige der IVS-Infrastruktur; leichte und intuitive Handhabung (geringe Aufwendungen für Einarbeitung und Schulungsmaßnahmen); große Flexibilität und *Anpassungsfähigkeit auf die Anforderungen des Alltags; anforderungsgerechtes Leistungsspektrum bei überschaubarer Komplexität&lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | Aufgaben und Interessen&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Aufgaben'''&lt;br /&gt;
|&lt;br /&gt;
*Umsetzung der gemeinsam mit der Landesseite vereinbarten Verkehrsmanagementstrategien mit Wirkung im kommunalen Netzbereich. Diese können im Kontext eines Strategie- und Informationsverbundes mit anderen Baulastträgern (andere Kommune, Land) und/oder mit privaten Dienstanbietern erweitert werden. Unter dem Betrachtungsfokus des baulastträger- und privatwirtschaftsübergreifenden Strategie- und Informationsverbundes, stehen folgende Aufgaben im Vordergrund:&lt;br /&gt;
**Strategiemanagement vorhersehbarer Ereignisse&lt;br /&gt;
**Management unvorhersehbarer Ereignisse&lt;br /&gt;
**Baulastträgerübergreifende Kooperation &lt;br /&gt;
***Anforderung von gemeinsam vereinbarten Schaltungen im Netz des jeweils anderen Baulastträgers. Strategieabgleich zwischen Baulastträgern auf Basis vordefinierten Strategien. &lt;br /&gt;
***Austausch von Betriebszuständen und Meldungen &lt;br /&gt;
**Austausch von Verkehrsdaten (LOS, Q, V usw.) für das gesamte Netz oder auch nur für den Netzübergangsbereich &lt;br /&gt;
**Kooperation mit Privaten&lt;br /&gt;
&lt;br /&gt;
Die vordergründige Anwendung des zuständigkeits-übergreifenden Verkehrsmanagements ist die Alternativroutensteuerung. Im Kontext eines baulastträger- und/oder privatwirtschaftsübergreifenden Verbundes müssen aber auch die Bedürfnissen von Privaten IVS-Akteuren durch z.B. Strategieabgleich, Bereitstellen von Verkehrsdaten, Meldungen und Betriebszuständen Rechnung getragen werden. Voraussetzung ist eine planerische und organisatorische Abstimmung von Maßnahmen im Vorfeld.&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Prozessbeteiligung'''&lt;br /&gt;
|&lt;br /&gt;
*Planung von zuständigkeitsübergreifenden Verkehrsmanagementstrategien mit dem Land &lt;br /&gt;
*Austausch von Verkehrsdaten mit dem Land &lt;br /&gt;
*Abstimmung der Strategieauswahl mit dem Land im Falle von Stau und besonderen Ereignissen (Maßnahmenaustauschliste)&lt;br /&gt;
*Austausch von Verkehrsdaten und Alternativrouten mit Privaten Service Providern (Strategiekonformes Routen)&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Interaktion mit andern IVS-Rollen'''&lt;br /&gt;
|Statische und dynamische Verkehrsmanagementstrategien und -informationen der Landesseite erheben und bereitstellen  &lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | Daten und Informationen&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Benötigte Daten / Informationen'''&lt;br /&gt;
|Verkehrsdaten und Maßnahmenanforderungen &lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Erzeugte Daten / Informationen'''&lt;br /&gt;
|Aktualisierte Maßnahmenaustauschliste &lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | IVS-Capabilities&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Fähigkeiten'''&lt;br /&gt;
|&lt;br /&gt;
*Erstellung und Visualisierung von Betriebszuständen und von zu einem Verkehrslagebericht aufbereitete Verkehrsdaten&lt;br /&gt;
*Senden und Empfangen von Maßnahmenaustauschlisten&lt;br /&gt;
*Senden und Empfangen von Bestätigungen von Maßnahmenanforderungen mittels Versand einer aktualisierten Maßnahmenaustauschliste&lt;br /&gt;
*Weitergabe von Routenempfehlungen&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Voraussetzungen'''&lt;br /&gt;
|&lt;br /&gt;
*Leistungsfähige straßenseitige und zentralenseitige IVS-Infrastruktur  &lt;br /&gt;
*Leitstelle für Verkehrsmanagement mit online- und Realzeit- Interaktionsmöglichkeiten mit anderen IVS-Akteuren  &lt;br /&gt;
*Für zuständigkeitsübergreifendes Verkehrsmanagement ausgebildetes, erfahrenes Personal   &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Requirement Management als Hilfestellung zur Identifiaktion von Anforderungen an IVS-Rollen===&lt;br /&gt;
&lt;br /&gt;
Mithilfe des Requirements-Management können '''Anforderungen an IVS-Rollen identifiziert''' werden. Um Anforderungen zu ermitteln, kann die '''Technik der Business-Szenarios''' angewandt werden. Sie dient der Identifikation und Dokumentation von Anforderungen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: IVS-Anforderungen-Template_00-00-01-1.PNG | 500px | IVS-Anforderung Template ]]&lt;br /&gt;
&lt;br /&gt;
Für die Formulierung der Requirements in natürlicher Sprache empfiehlt sich die Verwendung einer im Requirements Engineering erprobten und empfohlenen '''Satzschablone''': &lt;br /&gt;
&lt;br /&gt;
[[Datei: Schablone_ReqEng.jpg | 500px | Requirements Schablone ]]&lt;br /&gt;
Quelle: Pohl/Rupp (2015)&lt;br /&gt;
&lt;br /&gt;
Vorteil der '''Satzschablone ist die klare Syntax''' und sie hilft außerdem dabei, '''übliche Fehler bei der Formulierung zu vermeiden'''.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Rollenkonzept&amp;diff=7676</id>
		<title>IVS-Rollenkonzept</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Rollenkonzept&amp;diff=7676"/>
		<updated>2016-10-18T07:12:27Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Definition */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Grundlagen ==&lt;br /&gt;
&lt;br /&gt;
Die Befassung mit Rollen und Geschäftsmodellen im Kontext von IVS setzt die Verfügbarkeit eines Modells voraus, das die Semantik für eine typisierte Beschreibung der Rollen liefert und das von allen Beteiligten als Diskussions- und Beschreibungsgrundlage akzeptiert wird. &lt;br /&gt;
&lt;br /&gt;
=== Definition ===&lt;br /&gt;
''' IVS-Rolle...'''&lt;br /&gt;
*ist ein '''IVS-Architekturbaustein''', mit dem Stereotypen von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.&lt;br /&gt;
*ist ein '''signifikanter Bestandteil von IVS-Wertschöpfungsketten für IVS-Informationslogistik''', der von '''IVS-Akteuren und IVS-Stakeholdern''' je nach Erforderniss des zu realisierenden IVS-Dienstes eingenommen wird, wobei ein einzelner IVS-Akteur oder IVS-Stakeholder eine oder mehrere IVS-Rollen besetzen kann.&lt;br /&gt;
*'''operationalisiert seine IVS-Fähigkeiten und IVS-Verantwortlichkeiten in Geschäftsprozessen''' in Form von '''Aktivitäten''', die mit den Aktivitäten anderer IVS-Rollen die IVS-Geschäftsprozesse von IVS-Diensten bilden.  &lt;br /&gt;
*wird in '''IVS-Referenzarchitekturen von Stereotypen von IVS-Akteuren''', in '''IVS-Architekturen realer IVS-Dienste von konkreten Instanzen von Stereotypen von IVS-Akteuren''' eingenommen.&lt;br /&gt;
&lt;br /&gt;
=== Arten von IVS-Rollen ===&lt;br /&gt;
Generell können zwei Arten von IVS-Rollen mit ganz unterschiedlicher Ausprägung unterschieden werden:&lt;br /&gt;
&lt;br /&gt;
*'''Ökonomische IVS-Rollen''': &lt;br /&gt;
**Entwicklung der notwendigen ökonomischen Rahmenbedingungen (Rechtliche Grundlagen, Regeln, Finanzierung, ...) und Bereitstellen der administrativen Ressourcen für das Zustandekommen eines IVS-Dienstes &lt;br /&gt;
**administratrives und ökonomisches Management (Governance) des IVS-Dienstes während Betriebs&lt;br /&gt;
*'''Technische IVS-Rollen''': &lt;br /&gt;
**Entwicklung der notwendigen technischen Rahmenbedingungen (technische Standards, notwendige IT und Infrastruktur...) und und Bereitstellung der betrieblichen Ressourcen für das Zustandekommen eines IVS-Dienstes&lt;br /&gt;
**Durchführung des technischen Betriebs des IVS-Dienstes&lt;br /&gt;
&lt;br /&gt;
=== Wertigkeiten von Rollen (Power-Grid) ===&lt;br /&gt;
[[Datei:Power Grid zur Stakeholderanalyse_Konsortium MRK-AMADEUS.JPG|thumb | right | 400px|]]&lt;br /&gt;
&lt;br /&gt;
'''IVS-Rollen haben unterschiedliche Wertigkeiten''' in Bezug auf das Zustandekommen und für den Betrieb eines IVS-Dienstes. Das '''Rollen-Power-Grid Modell''' der Open Group unterscheidet 4 unterschiedliche Wertigkeiten (siehe nebenstehndes Bild).    &lt;br /&gt;
*'''IVS-Schlüsselrollen''' (Power Grid D:Key-Players)&lt;br /&gt;
**ökonomische IVS-Rollen, die für das Zustandekommen von IVS-Diensten erforderlich sind, z.B. durch Schaffung von der notwendigen politischen, rechtlichen und finanziellen Rahmenbedingungen.&lt;br /&gt;
**technische, ohne die ein IVS-Dienst nicht betrieben werden kann und die direkt an der Wertschöpfung eines IVS-Dienstes beteiligt sind.&lt;br /&gt;
*'''Involvierte IVS-Rollen''' (Power Grid C: Keep satisfied)&lt;br /&gt;
**IVS-Rollen, d.h die zwar nicht direkt an der Wertschöpfung eines IVS-Dienstes beteiligt sind, für die der IVS-Dienst aufgrund einer Zusammenarbeit mit den IVS-Schlüsselrollen mit direkten Auswirkungen verbunden ist.&lt;br /&gt;
*'''Interessierte IVS-Rollen''' (Power Grid B: Keep informed)&lt;br /&gt;
**Interessengruppen, die als Interessengemeinschaft von IVS-Diensten betroffen sind&lt;br /&gt;
*'''Sonstige IVS-Rollen''' (Power Grid A: Minimal Effort)&lt;br /&gt;
**IVS-Rollen, die am Rande beteiligt sind, auf die der IVS-Dienst aber weder eine Auswirkung hat noch mit einem Interesse verbunden sind&lt;br /&gt;
&lt;br /&gt;
=== Institutionelle Rollenmodelle als Grundlage der IVS-Wertschöpfung (IVS-Schlüssel-Rollen)===&lt;br /&gt;
&lt;br /&gt;
==== Einführung ====&lt;br /&gt;
&lt;br /&gt;
Für das IVS-Rollenmodell wird ein '''institutioneller Rollenmodell-Ansatz''' herangezogen, der im Projekt [http://www.converge-online.de/ CONVERGE] speziell für die '''Darstellung und Beschreibung von Rollen zur Realsierung von Kooperativen IVS-Diensten''' angewendet wurde.&lt;br /&gt;
&lt;br /&gt;
Im Kontext von IVS-Rollen wird unter '''institutionell''' verstanden, das von einer IVS-Rolle als Unternehmen bzw. Organisation '''ein bestimmtes wirtschaflichtes, operatives und technisches Verhalten und Handeln erwartbar''' ist (z.B. Straßenverkehrsbehörden genehmigen und ordnen an, Öffentliche Straßenbetreiber managen Verkehr kollektiv, private Navigationsdienstleister sind gewinnorintert und berechnen die Route nach den Wünschen des individuellen Kunden...)  &lt;br /&gt;
&lt;br /&gt;
Der Ansatz der institutionellen Rollenmodelle benötigt '''zwei Inputvektoren'''. Hierzu müssen die '''ökonomischen und technischen IVS-Rollen''' identifiziert werden.&lt;br /&gt;
&lt;br /&gt;
=== Ökonomisches IVS-Rollenmodell ===&lt;br /&gt;
Bei den ökonomischen Rollen werden im Wesentlichen die '''klassischen betriebswirtschaftlichen Rollen''' vorgegeben und '''durch die spezifischen, durch die Wertschöpfung geprägten, Rollen ersetzt'''. Der konzeptionelle Charakter des Ansatzes erfordert einen relativ hohen Abstraktionsgrad der Rollen. Daher werden die für die Untersuchung abgeleiteten Rollen als Meta-Rollen bezeichnet. &lt;br /&gt;
&lt;br /&gt;
'''Ökonomische IVS-Rollen''' sind:&lt;br /&gt;
*'''IVS-Business Management''' &lt;br /&gt;
** Die Rolle umfasst im Rahmen der '''Einführungsphase die Entscheidungsbefugnis zur Einführung von IVS-Diensten''' und im Rahmen der '''Betriebsphase sowohl strategische als auch operative Änderungen''', in der Art und Weise wie die IVS-Dienste betrieben werden, durchzusetzen. &lt;br /&gt;
**Wird diese Rolle durch eine '''staatliche Institution''' wahrgenommen, umfassen die damit verbundenen Aktionen das klassische Spektrum über '''Dienstanweisungen, Rechtsverordnungen, Gesetze, Direktiven''' und andere. &lt;br /&gt;
**Wird diese Rolle durch eine '''private Institution''' wahrgenommen, umfasst sie die Funktion der '''Unternehmensführung'''.&lt;br /&gt;
 &lt;br /&gt;
*'''IVS-Service-Angebot''' &lt;br /&gt;
**Die Rolle erfasst alle Aktionen, die eine '''IVS-spezifische Wertschöpfung durch Services''' schaffen. Das schließt die '''Konzeption des Services''' im Allgemeinen ein, wie auch die Entscheidung darüber, '''wer den Service anbietet und wie dieser bepreist''' wird. &lt;br /&gt;
**Die Entscheidung darüber, ob der Service '''selbst erstellt oder durch Dritte angeboten''' wird, liegt allerdings im '''Entscheidungsbereich der IVS-Business Management-Rolle'''. &lt;br /&gt;
&lt;br /&gt;
*'''IVS-Human Resources''' &lt;br /&gt;
**Die Rolle ist eine '''zentrale Rolle für die Umsetzung der IVS-Dienste'''. Die Kernaufgabe ist die '''Bereitstellung und der zielorientierte Einsatz von Personal''', um IVS-Dienste einzuführen und zu betreiben. &lt;br /&gt;
**In der '''konzeptionellen Planung eines IVS-Dienstes werden die Institutionen identifiziert'''. Im Falle der Umsetzung wird diese Rolle '''von den relevanten Institutionen so konkretisiert''', dass eine personelle Zuordnung ermöglicht wird. &lt;br /&gt;
&lt;br /&gt;
*'''IVS-Financial Management''' &lt;br /&gt;
**Diese Rolle soll sicherstellen, dass sowohl die '''Anfangsinvestitionen als auch die Ersatzinvestitionen finanziert''' werden können. Wie sich die '''Finanzierung gestaltet''', hängt hier auch davon ab, ob eine '''staatliche Institution oder eine private''' Institution in der Finanzierungsverantwortung steht. &lt;br /&gt;
**Im Falle '''staatlicher Institutionen''' dürften '''steuer- und/oder gebührenfinanzierte Lösungen''' im Vordergrund stehen. &lt;br /&gt;
**'''Private Investitionen''' können neben der '''Innenfinanzierung''' auf die '''klassischen Instrumente der Außenfinanzierung (Beteiligungsfinanzierung, Fremdfinanzierung)''' und Sonderformen der Finanzierung (Factoring) zurückgreifen.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Controlling''' &lt;br /&gt;
**Diese Rolle umfasst vor allem Aufgaben des '''internen Rechnungswesens'''. Neben der richtigen Erfassung der Kosten und Erlöse erfüllt das '''IVS-Controlling eine Unterstützungsfunktion für die Meta-Rolle IVS-Business Management'''. &lt;br /&gt;
**Auch hier ist im Rahmen der Umsetzung darauf zu achten, dass die zu erfassenden '''ökonomischen Größen unterschiedlich definiert''' werden können, wenn es sich entweder um '''staatliche''' oder '''private Institutionen''' handelt. &lt;br /&gt;
**Bei einer '''staatlichen Ausübung''' dieser Rolle können z.B. neben den für den Betrieb notwendigen '''betriebswirtschaftlichen Kosten und Erlösen auch gesamtwirtschaftliche Kosten und gesamtwirtschaftliche Nutzen''' erfasst werden, um die Entscheidungen über Einführung und Betrieb von IVS-Diensten unter volkswirtschaftlichen Gesichtspunkten zu optimieren.&lt;br /&gt;
&lt;br /&gt;
==== Technisches IVS-Rollenmodell ====&lt;br /&gt;
&lt;br /&gt;
Als Vorschlag für eine Technisches Rollenmodell wird ein Modell herangezogen, das im '''Projekt EasyWay speziell für die Darstellung und Beschreibung von Wertschöpfungsketten und -netzwerken''' für Verkehrsinformationsdienste entwickelt worden und in folgender Abbildung dargestellt ist:&lt;br /&gt;
&lt;br /&gt;
[[datei:IVSWertschöpfungsmodell.png | thumb | center | 500px | EasyWay-Wertschöpfungskette für Verkehrsinformationsdienste]]&lt;br /&gt;
&lt;br /&gt;
Das Modell enthält vier IVS-Rollen, die typischerweise zum Aufbau einer Informationslogistikette erforderlich sind:&lt;br /&gt;
&lt;br /&gt;
* ''' IVS-Inhalteanbieter''' (IVS-Content Provider)&lt;br /&gt;
**erstes Glied in der Wertschöpfungskette und Quelle, in der Regel auch Eigentümer (IVS-Content Owner) der in den IVS-Diensten verwendeten Daten und Informationen&lt;br /&gt;
**erfasst und verwaltet die Daten und Informationen, hält die Rechte zur Nutzung und Verteilung der Daten&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Dienstbetreiber''' (IVS-Service Operator)&lt;br /&gt;
**sammelt und verfeinert Rohdaten und -Informationen der IVS-Inhalteanbieter zu verwertbaren Mehrwert-Informationen (Schaffung von Added Value)&lt;br /&gt;
**wendet dazu unterschiedliche Methoden (Fusion von Daten, spezielle Algorithmen, Verkehrsmodelle...) an&lt;br /&gt;
**erzeugt Informationen mit identischem Inhalt für unterschiedliche IVS-Dienstanbieter und unterschiedliche IVS-Endgeräte von IVS-End-Nutzern (PC-Websites, PDAs, Smartphones usw.)  &lt;br /&gt;
**kann Clearing-Funktion bereitstellen, um die vollständige Kompatibilität unterschiedlicher IVS-Dienste zu unterstützen.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Kommunikationsnetzwerkbetreiber''' (IVS-Communication Network Provider)&lt;br /&gt;
**muss zuverlässige und ausreichend flexible Kommunikationskanäle für die nahtlose Verbindung von IVS-End-Nutzern, IVS-Endgeräten in Fahrzeugen, IVS-Straßeninfrastruktur und IVS-Dienste-Zentren bereitstellen&lt;br /&gt;
**ist verantwortlicher IVS-Schlüsselakteur für die Verbindung verschiedener Akteure mit unterschiedlichen Anforderungen &lt;br /&gt;
**seine Flexibilität ist ein Schlüsselfaktor, weil sich dies auf die Glaubwürdigkeit und Nutzung der Dienste durch Endkunden auswirkt.&lt;br /&gt;
**wird immer mehr selbst zum Inhalteanbieter (Mobilfunkbetreiber) &lt;br /&gt;
&lt;br /&gt;
*'''IVS-Dienstanbieter''' (IVS-Service Provider)&lt;br /&gt;
**realisiert und ist direkte Schnittstelle zum IVS-End-Nutzer &lt;br /&gt;
**muss neben der IVS-End-Nutzer-Information alle Funktionen für die Beziehung zum IVS-End-Nutzer bereitstellen (Rechnungsstellung, Kundenverwaltung oder Marketing, …)&lt;br /&gt;
**greift oft auf IVS-Dienste anderer IVS-Dienstanbieter zurück&lt;br /&gt;
**ist oft auch in der Rolle IVS-Dienstebetreibers&lt;br /&gt;
&lt;br /&gt;
*'''IVS-End-Nutzer '''&lt;br /&gt;
**ist Kunde des IVS-Dienstanbieters &lt;br /&gt;
**nutzt Informationen für private oder geschäftliche Zwecke&lt;br /&gt;
**keine homogene Gruppe, Anforderungen abhängig von persönlichen Anforderungen/Vorlieben und dem Nutzungszweck&lt;br /&gt;
&lt;br /&gt;
==== Weitere IVS-Rollen (IVS-Stakeholder)====&lt;br /&gt;
Neben den direkt an der Wertschöpfung beteiligten IVS-Rollen gibt es weitere wichtige IVS-Rollen: z.B.&lt;br /&gt;
* Technikhersteller und -lieferanten&lt;br /&gt;
* Standardisierungsorganisationen&lt;br /&gt;
* Verbände und Vertreter von Interessensgruppen&lt;br /&gt;
&lt;br /&gt;
==== Stereotypen von IVS-Akteuren als Instanzen von IVS-Rollen ==== &lt;br /&gt;
Im konkreten Falle der Konzeption, Einführung und des Betriebs eines IVS-Dienstes werden Rollen von konkreten IVS-Akteuren eingenommen. Folgende Liste zeigt Sterotypen von IVS-Akteuren: &lt;br /&gt;
&lt;br /&gt;
* '''Öffentliche Institutionen'''&lt;br /&gt;
** Gesetzgeber/Regulierungsbehörde&lt;br /&gt;
** Finanz- und Fördermittelgeber&lt;br /&gt;
** Öffentlicher Baulastträger&lt;br /&gt;
** Öffentlicher Straßenbetreiber&lt;br /&gt;
** Straßenverkehrsbehörde (Polizei)&lt;br /&gt;
** Öffentlicher Content- und Serviceoperator (Wetterdienst ...)  &lt;br /&gt;
** Öffentlicher Service Provider (Landesmeldestellen, Öffentliche Rundfunkanstalten, ...)&lt;br /&gt;
**...&lt;br /&gt;
&lt;br /&gt;
* '''Öffentliche/Private Institutionen'''&lt;br /&gt;
** Daten- und Informations-Broker (MDM)&lt;br /&gt;
** Standardisierungsorganistionen&lt;br /&gt;
&lt;br /&gt;
* ''' Private Content- und Serviceprovider '''&lt;br /&gt;
** Private Contentprovider, Serviceoperator und Serviceprovider (Navigationsdienstleister ...)&lt;br /&gt;
&lt;br /&gt;
* '''Industrie'''&lt;br /&gt;
** Verkehrstechnik-Industrie&lt;br /&gt;
** IKT-Industrie&lt;br /&gt;
** Autommobilindustrie&lt;br /&gt;
** Automobilzulieferer&lt;br /&gt;
** Kommunikationsinfrastrukturindustrie&lt;br /&gt;
&lt;br /&gt;
== Erfassung und Beschreibung von IVS-Rollen ==&lt;br /&gt;
=== Ziel der Erfassung von IVS-Rollen ===&lt;br /&gt;
Für die Entwicklung einer IVS-Referenzarchitektur oder die IVS-Architektur eines realen IVS-Dienstes, müssen in diesem Schritt die IVS-Rollen in die IVS-Wertschöpfung zu involvierenden IVS-Akteure beteiligenden IVS-Stakeholder erfasst und beschrieben werden.&lt;br /&gt;
&lt;br /&gt;
===Identifizierung der IVS-Rollen und ihre Beschreibung ===&lt;br /&gt;
&lt;br /&gt;
Für die Erfassung und Beschreibung der IVS-Rollen ist es zunächst - evtl. schon als Vorbereitung für den Schritt [[IVS-Architekturvision | Entwicklung einer IVS-Architekturvision ]] - erforderlich, eine erste Vorstellung für den IVS-Dienst selbst zu entwickeln und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöfungskette/im IVS-Wertschöpfungsnetzwerk wie folgt zu veranschaulichen.&lt;br /&gt;
&lt;br /&gt;
* Beschreibung (evtl. Visualisierung) des IVS-Dienstes und des damit verbundenen Nutzens für den Endkunden &lt;br /&gt;
* Beschreibung der dazu erforderlichen IVS-Informationslogistikkette &lt;br /&gt;
* Identifizierung der an der Wertschöpfung zu beteiligenden IVS-Rollen mit&lt;br /&gt;
** dem Grad der Beteiligung&lt;br /&gt;
** den wichtigsten Anliegen und Geschäftsanforderungen (Business Cases)&lt;br /&gt;
** deren Bedenken und Perspektiven&lt;br /&gt;
&lt;br /&gt;
In einem zweiten Schritt können die so identifizierten IVS-Rollen wie folgt weiter differenziert werden:&lt;br /&gt;
*Rechtsform und Aufgaben &lt;br /&gt;
*Geschäftsstrtegie und [https://de.wikipedia.org/wiki/Gesch%C3%A4ftsmodell IVS-Geschäftsmodell(e)] (Businness-Case) &lt;br /&gt;
*Kern-/Zusatzgeschäfte (Inhalte und Ziele), Finanzierungsmodelle &lt;br /&gt;
*Organisationsform, Schlüsselressourcen und Partnerschaften &lt;br /&gt;
*Wertschöpfungsprozesse &lt;br /&gt;
*Informationsstrukturen &lt;br /&gt;
*IT (IT-Dienste und IT-Infrastrukturen inkl. Datenbestand, Datenschnittstellen/Vernetzung&lt;br /&gt;
&lt;br /&gt;
=== Ergebnissdarstellung der Identifzierung der IVS-Rollen ===&lt;br /&gt;
&lt;br /&gt;
Zur Ergebnisdarstellung stellt die IVS-Rahmenarchitektur zwei Templates bereit: &lt;br /&gt;
&lt;br /&gt;
====[[Stakeholder-Erfassung | Das IVS-Rollen-Map Template]]====&lt;br /&gt;
Das IVS-Rollen-Map Template ist ein '''IVS-Architekturdeliverable (siehe [[IVS-RollenMap-Template | IVS-Rollen Map]])''', das die Stereoptypen von IVS-Akteuren und IVS-Stakeholdern deklariert und mit Ihren geschäftsanleigen und IVS-Rollen beschreibt.  &lt;br /&gt;
Außerdem '''klassifiziert es die Bedeutung von IVS-Akteuren und IVS-Stakeholdern''', die sie über ihre Rolle für den IVS-Dienst bzw. die IVS-Dienste-Kategorie erlangen (Power-Grid)&lt;br /&gt;
&lt;br /&gt;
Beispiele von IVS-Rollenbeschreibungen von IVS-Akteurs-Stereotypen mit Hilfe des IVS-Rollen-Map Template zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;7&amp;quot; | IVS-Rollenbeschreibung &lt;br /&gt;
|+&lt;br /&gt;
!IVS-Rolle für die IVS-Wertschöpfung !! IVS-Metarolle  !! IVS-Akteur ('''Ö'''=Ökonomische Rolle, '''T'''=Technische Rolle), IVS-Stakeholder  !! Schlüsselanliegen der IVS-Rolle !!IVS-Capabilities / IVS-Verantwortlichkeiten !!  Wertigkeit der IVS-Rolle (gemäß Power Grid)!!&lt;br /&gt;
IVS-Akteur bwz. IVS-Akteurs-Stereotyp) &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Dienst-Ersteller''' &lt;br /&gt;
(IVS-Dienst erstellen und an IVS-Dienst-Betreiber übergeben)&lt;br /&gt;
|IVS-Business und Financial Management&lt;br /&gt;
|IVS-Akteur (Ö)&lt;br /&gt;
|Erstellung von IVS-Diensten nach wirtschaflichen und technischen Grundsätzen&lt;br /&gt;
|Beschaffung der Finanzmittel für und Erstellung von IVS-Diensten   &lt;br /&gt;
|Key Player&lt;br /&gt;
|Öffentlicher Baulastträger&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''VM-Inhalte-Anbieter'''&lt;br /&gt;
(Statische und dynamische Verkehrsmanagementstrategien und -informationen  erheben und bereitstellen) und VM-Sercice-Betreiber&lt;br /&gt;
|IVS-Inhalte Anbieter (auch IVS-Inhalteeigentümer)&lt;br /&gt;
|IVS-Akteur (Ö und T)&lt;br /&gt;
|Verkehr nach politischen Vorgaben und fachlichen Grundsätzen optimal managen   &lt;br /&gt;
|Verkehrsmanagementstrategien und -informationen zur Realzeit feststellen&lt;br /&gt;
|Key Player&lt;br /&gt;
|Öffentlicher Straßenbetreiber (Verkehrsmanagement-Abteilung)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Baustellen-Inhalte-Anbieter''' &lt;br /&gt;
(Baustelleninformationen erheben und bereitstellen)&lt;br /&gt;
|IVS-Inhalte Anbieter (auch IVS-Inhalteeigentümer)&lt;br /&gt;
|IVS-Akteur (T)&lt;br /&gt;
|Sicherstellung der StVO-Konformität von Baustellen &lt;br /&gt;
|Genehmigung von Baustellen, Anordnung von Sperrungen und Umleitungen für Baustellen auf Fahrbahnen, Geh- und Radwegen nach StVO § 45(1)&lt;br /&gt;
|Key Player&lt;br /&gt;
|Straßenverkehrsbehörde&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Parken-Inhalte-Anbieter'''&lt;br /&gt;
(Statische und dynamischen Parkdaten erheben und bereitstellen)&lt;br /&gt;
|IVS-Inhalte Anbieter (auch IVS-Inhalteeigentümer)&lt;br /&gt;
|IVS-Akteur (T)&lt;br /&gt;
|Wirtschaftlicher Betrieb kostenpflichtiger Parkierungsanlagen &lt;br /&gt;
|Besetztgrad zuverlässig und in Realzeit erheben und publizieren&lt;br /&gt;
|Key Player&lt;br /&gt;
|Betreiber von kostenpflichtigen Parkierungsanlagen&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Dienste System-Lieferant''' &lt;br /&gt;
(Systeme, Software und Infrastruktur von IVS-Diensten anforderungsgerecht herstellen, liefern und unterhalten)&lt;br /&gt;
|Technikhersteller und -lieferant &lt;br /&gt;
|IVS-Stakeholder&lt;br /&gt;
|Herstellung und Verkauf von wettbewerbsfähigen Systemen, Software und Infrastruktur von IVS-Diensten &lt;br /&gt;
|Herstellung, Lieferung, Implementierung  und Unterhaltung sowie Vetrieb von Systemen, Software und Infrastruktur von IVS-Diensten&lt;br /&gt;
|Keep Informed&lt;br /&gt;
|Hersteller von Systemen, Software und Infrastruktur von IVS-Diensten&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
====[[IVS-Rollenkonzept#IVS-Rolle |Das IVS-Rollen Template]] ====&lt;br /&gt;
Das IVS-Rollen Template ist ein '''IVS-Architekturbaustein (siehe [[IVS-Rolle|IVS-Rolle]])''', mit dem Stereotypen von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.&lt;br /&gt;
&lt;br /&gt;
Ein Beispiel für die Beschreibung eines IVS-Akteurs in einer konkreten IVS-Rolle mit Hilfe des IVS-Rollen-Templates zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | Stammdaten der IVS-Rolle &lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Rolle''' (für die IVS-Wertschöpfung)&lt;br /&gt;
|Statische und dynamische Verkehrsmanagementstrategien und -informationen der städtsichen Seite erheben und bereitstellen &lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Art der IVS-Rolle''' {IVS-Akteur, IVS-Stakeholder}&lt;br /&gt;
|IVS-Akteur ('''Ö'''konomische und '''T'''echnische IVS-Rolle)&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Metarolle'''&lt;br /&gt;
|IVS-Inhalteanbieter (auch IVS-Inhalteeigentümer)&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Akteur(e) bzw. IVS-Akteurs-Stereotyp(en)''' für diese IVS-Rolle:&lt;br /&gt;
|Öffentlicher Straßenbetreiber Stadt (Amt für Verkehrsmanagement, Düsseldorf)&lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | Ziele und Interessen&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Verantwortungsbereich'''&lt;br /&gt;
|&lt;br /&gt;
*Zuständig für Planung, Bau, Betrieb und Unterhaltung der IVS-Infrastruktur der Stadt. &lt;br /&gt;
*Als Bauherr der rechtlich und wirtschaftlich verantwortliche Auftraggeber für die Errichtung der IVS-Infrastruktur und in diesem Sinne auch für die Projektierung, Auftragsvergabe, Bauabwicklung- und -überwachung, Abnahme  und den Betrieb der ITS-Infrastruktur sowie für die Anforderungen, die aus dieser Rolle erwachsen.&lt;br /&gt;
*Als Betreiber rechtlich und wirtschaftlich verantwortlich für den Betrieb des der IVS-Infrastruktur. Als Stellvertreter des Bürgers/ Verkehrsteilnehmers verantwortlich für die Sicherstellung von Sicherheit und Komfort des Verkehrsablaufs, die mit dem Einsatz des Systems bezweckt werden, sowie die Umsetzung und Einhaltung der Anforderungen, die aus dieser Rolle erwachsen.&lt;br /&gt;
Beim hoheitsübergreifenden Verkehrsmanagement in der Rolle des Ansprechpartners und verantwortlichen IVS-Akteurs auf der Seite der Stadt  &lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Ziele und Interessen Rolle'''&lt;br /&gt;
|&lt;br /&gt;
*Verkehrliche Ziele: Sicherstellung der Sicherheit und Leichtigkeit des Verkehrsablaufs für alle Nutzer des städtischen Straßennetzes.&lt;br /&gt;
*Betriebliche Ziele: Hohe Stabilität und Verfügbarkeit der IVS-Infrastruktur; hohe Sicherheit und Performance der Abläufe im System; hohe Qualität der bereitgestellten Informationen; effektive, wartungsarme und im Betrieb kostengünstige der IVS-Infrastruktur; leichte und intuitive Handhabung (geringe Aufwendungen für Einarbeitung und Schulungsmaßnahmen); große Flexibilität und *Anpassungsfähigkeit auf die Anforderungen des Alltags; anforderungsgerechtes Leistungsspektrum bei überschaubarer Komplexität&lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | Aufgaben und Interessen&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Aufgaben'''&lt;br /&gt;
|&lt;br /&gt;
*Umsetzung der gemeinsam mit der Landesseite vereinbarten Verkehrsmanagementstrategien mit Wirkung im kommunalen Netzbereich. Diese können im Kontext eines Strategie- und Informationsverbundes mit anderen Baulastträgern (andere Kommune, Land) und/oder mit privaten Dienstanbietern erweitert werden. Unter dem Betrachtungsfokus des baulastträger- und privatwirtschaftsübergreifenden Strategie- und Informationsverbundes, stehen folgende Aufgaben im Vordergrund:&lt;br /&gt;
**Strategiemanagement vorhersehbarer Ereignisse&lt;br /&gt;
**Management unvorhersehbarer Ereignisse&lt;br /&gt;
**Baulastträgerübergreifende Kooperation &lt;br /&gt;
***Anforderung von gemeinsam vereinbarten Schaltungen im Netz des jeweils anderen Baulastträgers. Strategieabgleich zwischen Baulastträgern auf Basis vordefinierten Strategien. &lt;br /&gt;
***Austausch von Betriebszuständen und Meldungen &lt;br /&gt;
**Austausch von Verkehrsdaten (LOS, Q, V usw.) für das gesamte Netz oder auch nur für den Netzübergangsbereich &lt;br /&gt;
**Kooperation mit Privaten&lt;br /&gt;
&lt;br /&gt;
Die vordergründige Anwendung des zuständigkeits-übergreifenden Verkehrsmanagements ist die Alternativroutensteuerung. Im Kontext eines baulastträger- und/oder privatwirtschaftsübergreifenden Verbundes müssen aber auch die Bedürfnissen von Privaten IVS-Akteuren durch z.B. Strategieabgleich, Bereitstellen von Verkehrsdaten, Meldungen und Betriebszuständen Rechnung getragen werden. Voraussetzung ist eine planerische und organisatorische Abstimmung von Maßnahmen im Vorfeld.&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Prozessbeteiligung'''&lt;br /&gt;
|&lt;br /&gt;
*Planung von zuständigkeitsübergreifenden Verkehrsmanagementstrategien mit dem Land &lt;br /&gt;
*Austausch von Verkehrsdaten mit dem Land &lt;br /&gt;
*Abstimmung der Strategieauswahl mit dem Land im Falle von Stau und besonderen Ereignissen (Maßnahmenaustauschliste)&lt;br /&gt;
*Austausch von Verkehrsdaten und Alternativrouten mit Privaten Service Providern (Strategiekonformes Routen)&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Interaktion mit andern IVS-Rollen'''&lt;br /&gt;
|Statische und dynamische Verkehrsmanagementstrategien und -informationen der Landesseite erheben und bereitstellen  &lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | Daten und Informationen&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Benötigte Daten / Informationen'''&lt;br /&gt;
|Verkehrsdaten und Maßnahmenanforderungen &lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Erzeugte Daten / Informationen'''&lt;br /&gt;
|Aktualisierte Maßnahmenaustauschliste &lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;2&amp;quot; | IVS-Capabilities&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''IVS-Fähigkeiten'''&lt;br /&gt;
|&lt;br /&gt;
*Erstellung und Visualisierung von Betriebszuständen und von zu einem Verkehrslagebericht aufbereitete Verkehrsdaten&lt;br /&gt;
*Senden und Empfangen von Maßnahmenaustauschlisten&lt;br /&gt;
*Senden und Empfangen von Bestätigungen von Maßnahmenanforderungen mittels Versand einer aktualisierten Maßnahmenaustauschliste&lt;br /&gt;
*Weitergabe von Routenempfehlungen&lt;br /&gt;
|-&lt;br /&gt;
|- style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|'''Voraussetzungen'''&lt;br /&gt;
|&lt;br /&gt;
*Leistungsfähige straßenseitige und zentralenseitige IVS-Infrastruktur  &lt;br /&gt;
*Leitstelle für Verkehrsmanagement mit online- und Realzeit- Interaktionsmöglichkeiten mit anderen IVS-Akteuren  &lt;br /&gt;
*Für zuständigkeitsübergreifendes Verkehrsmanagement ausgebildetes, erfahrenes Personal   &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Requirement Management als Hilfestellung zur Identifiaktion von Anforderungen an IVS-Rollen===&lt;br /&gt;
&lt;br /&gt;
Mithilfe des Requirements-Management können '''Anforderungen an IVS-Rollen identifiziert''' werden. Um Anforderungen zu ermitteln, kann die '''Technik der Business-Szenarios''' angewandt werden. Sie dient der Identifikation und Dokumentation von Anforderungen.&lt;br /&gt;
&lt;br /&gt;
[[Datei: IVS-Anforderungen-Template_00-00-01-1.PNG | 500px | IVS-Anforderung Template ]]&lt;br /&gt;
&lt;br /&gt;
Für die Formulierung der Requirements in natürlicher Sprache empfiehlt sich die Verwendung einer im Requirements Engineering erprobten und empfohlenen '''Satzschablone''': &lt;br /&gt;
&lt;br /&gt;
[[Datei: Schablone_ReqEng.jpg | 500px | Requirements Schablone ]]&lt;br /&gt;
Quelle: Pohl/Rupp (2015)&lt;br /&gt;
&lt;br /&gt;
Vorteil der '''Satzschablone ist die klare Syntax''' und sie hilft außerdem dabei, '''übliche Fehler bei der Formulierung zu vermeiden'''.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7465</id>
		<title>IVS-Geschäftsziele</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7465"/>
		<updated>2016-10-12T08:18:32Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Einführung */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Einführung ==&lt;br /&gt;
&lt;br /&gt;
[[Datei: Business-Motivation-Model-top.png | thumb | 300 px | right | Übersichtsdarstellung des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
[[Datei: BMM.png | thumb | 300 px | right | Bestandteile des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
Um die Diskussion über die Formulierung von '''Ziel- und Realisierungsvorstellungen für IVS-Dienste''' von vorneherein auf eine methodisch konsistente und für jeden nachvollziehbare Basis zu stellen, wird im folgenden auf das&lt;br /&gt;
[[Media: Formal-15-05-20.pdf | '''Business Motivation Model''']] (BMM, Version 1.3) der [https://en.wikipedia.org/wiki/Business_Motivation_Model ''' OMG - Open Managment Group'''] zurückgegriffen.&lt;br /&gt;
&lt;br /&gt;
Das BMM-Business Motivation Modell (siehe nebenstehende Abbildung) beleuchtet die '''Anforderungen an das Business (Geschäft)''' eines Unternehmens/einer Organisation auf verschiedenen Ebenen, um gründlich und präzise zu erfassen und zu begründen:&lt;br /&gt;
*'''warum''' ein Unternehmen/eine Organisation '''handeln''' will (oder soll), &lt;br /&gt;
*worauf das Handeln abzielt und '''was am Ende erreicht werden soll''',&lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation plant, '''dorthin zu kommen''' und &lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation die erreichten '''Ergebnisse bewertet'''.&lt;br /&gt;
&lt;br /&gt;
Für die Beschreibung des &amp;quot;Business&amp;quot; definiert und verwendet das BMM verschiedene &lt;br /&gt;
Elemente (semantische Konzepte), die zueinander in Beziehung gesetzt werden. &lt;br /&gt;
Die wichtigsten Elemente sind:&lt;br /&gt;
*'''Ends''': ''Was'' (im Gegensatz zu ''Wie'') das Unternehmen/die Organisation - am Ende - erreichen möchte.&lt;br /&gt;
*'''Means''': ''Wie'' - mit welchen (Hilfs-)Mitteln - das Unternehmen/die Organisation beabsichtigt, seine ''Ends'' zu erreichen. &lt;br /&gt;
*'''Directives''': Die ''Regeln und Grundsätze'', die die verfügbaren Means einschränken bzw. regulieren. &lt;br /&gt;
*'''Influencers''': ''Einflussfaktoren'', die Änderungen erforderlich machen, während ein Unternehmen/eine Organisation mit den Means oder der Erreichung der Ends befasst ist. Influencers sind per Definition neutral.&lt;br /&gt;
*'''Assessment''': Eine ''Beurteilung'' eines Influencers, der die Fähigkeit eines Unternehmens bei der Erreichung seiner Ends oder Anwendung seiner Means beeinflusst.&lt;br /&gt;
&lt;br /&gt;
== Das Ends-Konzept (Formulierung von Zielvorstellungen) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
Im Kontext der Ziele-Diskussion für IVS-Dienste ist zunächst das '''Ends'''-Konzept von Bedeutung. Ends beschreiben, was ein Business (am Ende) sein will bzw. '''wo ein Business (am Ende) stehen will'''. Ends selber geben keine Auskunft darüber, wie sie erreicht werden sollen. Wenn wir den Business-Begriff auf den IVS-Dienst übertragen, d.h. '''wenn wir einen IVS-Dienst als Business begreifen und interpretieren''', hilft das Ends-Konzept, Ziele auf ihre Bedeutung hin sematisch zu differenzieren.&lt;br /&gt;
&lt;br /&gt;
=== Ends-Kategorien ===&lt;br /&gt;
&lt;br /&gt;
[[Datei: Ends-Konzept.png | thumb | 300 px | right | Ends-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie nebenstehndes UML-Diagramm zeigt, sind Ends kategorisiert als '''Vision''' and '''Desired Results'''. Desired Results als '''Goals''' und '''Objectives'''.&lt;br /&gt;
&lt;br /&gt;
*Eine '''Vision''' ist eine generelles Bild dafür, was ein Business zukünftig sein oder werden möchte. '''Hinweis''': das Business Motivation Model kann eingesetzt werden, auch wenn eine Vision nicht explizit festgelegt wurde.&lt;br /&gt;
*'''Desired Results (dts: gewünschte Ergebnisse)''', differenziert als '''Goals (dts: generelle Zielsetzung/Oberziel/Zweck)''' und '''Objectives (dts: messbare Einzelziele)''', sind spezifischer als Visionen: &lt;br /&gt;
**Ein '''Goal (dts: qualitatives Ziel)''' ist vom Wesen her eher langfristig ausgerichtet und eher qualitativ als quantitativ festgelegt. Es sollte jedoch gerade noch so zukunftsnah sein, dass dafür messbare Einzelziele definiert werden können.&lt;br /&gt;
**Ein '''Objective (dts: quantitatives Ziel)''' ist ein Schritt auf dem Weg hin zum generellen Ziel. Es quantifiziert ein stückweit das generelle Ziel. Es muss mit einem End-Datum verknüpft sein und es müssen Kriterien festgelegt sein, um darüber feststellen zu können, ob es erreicht wurde oder nicht. Messbare Einzelziele bilden die messbare Grundlage dafür, ob ein Forschritt in Richtung der Erfüllung der generellen Zielsetzung erreicht wurde.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Ends-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Visionen (BMM = Visions) ====&lt;br /&gt;
Jedes Unternehmen/jede Organisation hat natürliche Visionen, wo die Reise hingehen soll, d.h. wo das Unternehmen/die Organisation z.B. in 10 Jahren stehen will. Visionen sind aber '''oft nicht oder nur unscharf formuliert''' und treten in der Realität des Alltags oft in den Hintergrund. Für IVS allerdings haben Visionen eine große Bedeutung, weil IVS und IVS-Dienste im '''Kontext politischer und gesellschaftlicher Diskussionen über Verkehr, Transport und Mobilität einen große Rolle''' spielen.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Visionen''' für unterschiedliche IVS-Zielfelder zeigt folgende Tabelle:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== Ergebnisse (Nutzen und Wirkung) von IVS-Diensten (BMM  = Desired results)====  &lt;br /&gt;
Mit einem IVS-Dienst werden nicht nur Visionen sondern '''stets auch konkrete Ziele''' verfolgt. Für das Engagement von IVS-Akteuren und IVS-Stakeholdern soll sich ein bestimmter '''Gegenwert in Form eines Ergebnisses (IVS-Nutzen/IVS-Wirkung)''' einstellen.&lt;br /&gt;
 &lt;br /&gt;
Grundsätzlich ist natürlich für jeden IVS-Dienst '''das große Ganze''', also der IVS-Nutzen und den damit verbundenen  Mehrwert für den späteren IVS-End-Nutzer '''im Fokus zu behalten''' und gemeinsam daraufhin zu arbeiten. IVS-Nutzen entsteht, wenn IVS-End-Nutzer oder IVS-End-Nutzerkollektive Zugriff auf IVS-Informationen haben, um eigene IVS-Entscheidungen sicher, zuverlässing, schnell und effektiv treffen zu können.&lt;br /&gt;
 &lt;br /&gt;
In Abhängigkeit der '''rechtlichen Ausgangssituation von IVS-Akteuren oder Stakeholdern''' (privat oder öffentlich rechtlich) werden generelle IVS-Zielsetzungen in der Regel ganz '''unterschiedlich und ggfs. auch konfliktär formuliert und interpretiert'''.&lt;br /&gt;
&lt;br /&gt;
*für '''privatwirtschafliche finanzierte Unternehmen''' steht bei der Zielformulierung der eigene Business Case und der mit einem IVS-Dienst oder der Komformität zu einer IVS-Architekturvorgabe verbundene wirtschaftliche Mehrwert für das Unternehmen im Vordergrund. Somit sind privatrechtliche Unternehmen naturgemäß eher auf den individuellen IVS-Nutzen von solchen Kunden ausgerichtet, die letztendlich bereit sind, für den IVS-Dienst direkt oder indierekt zu bezahlen.&lt;br /&gt;
&lt;br /&gt;
*für '''steuerfinanzierte Institutionen des öffentlichen Rechts''' steht bei der Zielformulierung die Umsetzung politischer Vorgaben und genereller gesellschaftpolitischer Ziele (Daseinsvorsorge) und der mit einem IVS-Dienst verbundene Mehrwert für ein End-Nutzer-Kollektiv im Vordergrund. Naturgemäß sind Institutionen des öffentlichen Rechts auf den kollektiven Nutzen der &amp;quot;Kunden&amp;quot; ausgerichtet, die Steuern zahlen. &lt;br /&gt;
&lt;br /&gt;
Um privat-und steuerfinanzierten Nutzen von IVS-Diensten zu unterscheiden werden die Begriffe '''IVS-Nutzen (privatfinanziert)''' und '''IVS-Wirkung (steuerfinanziert)''' verwendet. IVS-Nutzen und IVS-Wirkung können als rein '''Qualitative IVS-Ziele''' (BMM = Goals) formuliert werden und/oder als '''Quantitative IVS-Ziele''' (BMM = Objectives) quantitativ messbar sein.  &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für Qualitative und Quantitative IVS-Ziele''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! Qualitative IVS-Ziele (Goals)!! Quantitative IVS-Ziele (Objectives)&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung von Auffahrunfällen&lt;br /&gt;
*Reduzierung von Unfällen in Baustellen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung der Unfallhäufigkeit in Folge von Staus um X% &lt;br /&gt;
*Reduzierung der Unfälle mit LKW um X%&lt;br /&gt;
*Reduzierung von Folgeunfällen bei Stau um X%&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung des Energieverbrauchs&lt;br /&gt;
*Reduzierung der Schadstoffemissionen&lt;br /&gt;
*Reduzierung der Lärmbelastungen&lt;br /&gt;
|&lt;br /&gt;
*Kraftstoffverbrauch um X% reduzieren&lt;br /&gt;
*CO2-Ausstoß um X% reduzieren &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
*Kontinuierliche Verbesserung des Modal Split von Pendlern&lt;br /&gt;
|&lt;br /&gt;
*Verbesserung der Nutzerfreundlichkeit bei der Anfrage von Reisealternativen der multimodalen Reiseplanung&lt;br /&gt;
*Aufklärung und Information der Reisenden&lt;br /&gt;
|&lt;br /&gt;
*Verkürzen der Latenzeit von der Reiseanfrage bis zur Präsentation der Reiseroute auf &amp;lt; 5 Sekunden&lt;br /&gt;
*Umstieg von 10 % der bisherigen PKW-Fahrer auf ÖPNV&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Da IVS-Dienste in der Regel nur durch die Kooperation und Zusammenarbeit ganz unterschiedlicher IVS-Akteure entstehen, müssen sich diese sich letzendlich auf gemeinsame Ziele verständigen ('''Zwang zum Konsens''').&lt;br /&gt;
&lt;br /&gt;
== Das Means-Konzept (das (Hilfs-)Mittel-Konzept) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
&lt;br /&gt;
Ein (Hilfs-)Mittel repäsentiert jede Art von spezieller Fähigkeit, System, Technologie, Regelwerk, Instrument oder Methode etc., die in Anspruch genommen, aktiviert oder verstärkt werden kann, um Ziele (Ends) zu erreichen. Hilfs-(Mittel) sagen jedoch weder etwas über Schritte (Geschäftsprozesse und -abläufe) aus, die notwendig sind um sie zu nutzen, noch über Verantwortlichkeiten für solche Aufgaben, sondern lediglich über die Fähigkeiten, die mit den (Hilfs-)mitteln verbunden sind und die einsetzbar sind, um die gewünschten Ergebnisse (Ends) zu erzielen.&lt;br /&gt;
&lt;br /&gt;
Wenn man (Hilfs-)Mittel beschreibt, ist es auch nützlich zu dokumentieren, wer das (Hilfs-)Mittel zu welchem Zeitpunkt einsetzt, sodass für die Zukunft als Referenz ein Prüfpfad exisitiert.&lt;br /&gt;
&lt;br /&gt;
===Hilfs-(Mittel)-Kategorien ===&lt;br /&gt;
[[Datei: Means-Konzept.png | thumb | 300 px | right | Übersichtsdarstellung über das Means-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie im nebenstehenden UML-Diagramm sichtbar lässt sich das (Hilfs-)Mittel-Konzept als  Hierarchie darstellen und begreifen. &lt;br /&gt;
&lt;br /&gt;
Insofern können (Hilfs-)Mittel sein:&lt;br /&gt;
*eine '''Mission''' (Handlungsoption, Aktion, Auftrag)&lt;br /&gt;
*:Eine '''Mission''' oder auch '''Handlungsoption''' bezeichnet, wie ihr Gegenstück '''Vision''', einen Langzeit-Ansatz, der auf die Erfüllung der Vision fokussiert ist. Wie die Vision ist die Mission nicht sehr spezifisch formuliert. Die Entscheidung für eine Handlungsoption sollte sich danach richten, wie Ressourcen, Fähigkeiten, Fertigkeiten und Kompetenzen, auf die eine Unternehmen/eine Organisation zurückgreifen kann, am besten genutzt werden können, um die formulierten Ziele auch tatsächlich zu erreichen.&lt;br /&gt;
*ein '''Handlungsmuster''' (strategisch oder taktisch)&lt;br /&gt;
*:In gewisser Weise, sind '''Handlungsmuster''' von grundsätzlicher Natur. Sie sind jedoch stumpfe Instrumente, wenn sie nicht durch entsprechende Direktiven gestützt werden, um eine reale Chance zu haben, erfolgreich zu sein.  &lt;br /&gt;
*eine '''Direktive''' (Geschäftspolitik, Geschäftsregel)  &lt;br /&gt;
*:Im Gegensatz zu Handlungsmustern, können '''Direktiven (Vorschriften und Richtlinien)''' nicht für sich alleine stehen. Vielmehr geben sie den Handlungsmustern den richtigen Schliff. Mit anderen Worten stellen sie sicher, dass Handlungsmuster in intelligenter Weise innerhalb von Grenzen angewendet werden, die für ein Unternehmen/eine Unternehmung akzeptabel bzw. optimal sind. Kurz formuliert, Direktiven repräsentieren das verschlüsselte (z.B. in schriftlicher Form dokumentierte) Wissen, das einem Handlungsmuster die Chance auf den höchstmöglichen Erfolg eröffnet. &lt;br /&gt;
*:Eine Direktive hat auch etwas zu tun mit Führung und Lenkung. Im Gegensatz dazu identifiziert ein Handlungsmuster den aktiven Ansatz auf dem Weg hin zu den Ends. Ein Handlungsmuster ist immer aktionsorientiert.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Means-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Missionen/IVS-Handlungsoptionen (BMM = Missions) ====&lt;br /&gt;
IVS-Missionen sind '''IVS-Handlungsoptionen''', die zum Ausdruck bringen, auf welche '''Art von IVS-Diensten in welcher Kombination''' man grundsätzlich zurückgreifen kann bzw. welche Art von IVS-Diensten in welcher Kombination am besten geignet sind, um der mit der Vision formulierten Zielvorstellung näher zu kommen. Die Entscheidung für eine Art von IVS-Diensten bzw. Kombination von Diensten und ihre spezifische Ausgestaltung sollte sich danach richten, wie '''ganz aktuell z.b. finanzielle und personelle Ressourcen sowie Fähigkeiten, Fertigkeiten, Kompetenzen und Technologien am besten eingesetzt werden''', um die formulierten Ziele zu erreichen. IVS-Handlungsoptionen müssen jedoch einen als '''realistisch erachteten Zeithorizont''' haben. So sollten z.B. IVS-Dienste, die im betrachteten Zeitraum noch nicht die erforderliche Technologiereife erreicht haben, nicht als IVS-Handlungsoption in Erwägung gezogen werden.&lt;br /&gt;
&lt;br /&gt;
Beispiele für IVS-Handlungsoptionen zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! IVS-Handlungsoption (Mission)  &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport&lt;br /&gt;
|Einsatz von Kooperativen IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport&lt;br /&gt;
|&lt;br /&gt;
*Einsatz von energieverbrauchsdämpfenden IVS-Diensten (ITS und C-ITS)&lt;br /&gt;
*Vermehrtes Feinstaubmanagement &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (jederzeit, an jedem Ort)&lt;br /&gt;
|Einsatz von in Realzeit arbeitenden multimodalen IVS-Informationsdiensten &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Handlungsmuster (BMM = Course of action) ==== &lt;br /&gt;
'''IVS-Handlungsmuster''' geben vor, '''wie bei man bei der Wahl einer IVS-Mission/IVS-Handlungsoption am besten vorgeht'''. IVS-Handlungsmuster definieren '''was zu tun ist''', aber '''nicht wie gut etwas zu tun''' ist. IVS-Performance-Kriterien werden mit den Zielen formuliert, die durch Handlungsmuster unterstützt werden. IVS-Handlungsmuster zielen nicht immer unmittelbar auf die Erreichung von Ergebnissen. Manche sind sinnvoll, um andere IVS-Handlungsmuster zu ermöglichen. &lt;br /&gt;
&lt;br /&gt;
IVS-Handlungsmuster werden unterschieden nach: &lt;br /&gt;
*'''IVS-Strategien...'''&lt;br /&gt;
**sind eher '''langzeitorientiert''' und '''breit''' angelegt. &lt;br /&gt;
**sind als Merkmale, die strategische Einflussfaktoren und Rahmenbedingungen repräsentieren, '''wesentlich für den Erfolg eines IVS-Handlungsmusters'''. &lt;br /&gt;
**legen für IVS-Handlungsmuster beste Vorgehensweisen, widerspruchsfreie Verhaltensmuster, Positionierungen und Sichtweisen der IVS-Aktueure bei der Modellierung, Planung, Realisierung und dem Betrieb von Intelligenten Verkehrssystemen fest.&lt;br /&gt;
**sind Schlüsselfaktoren, die oftmals über '''Erfolg oder Misserfolg von IVS-Diensten''' entscheiden. Zu den strategischen Merkmalen gehören insbesondere Finanzierungskonzepte, aber oft auch zu schaffende rechtliche Rahmenbedingungen und technologische Voraussetzungen. Diese müssen frühzeitig identifiziert und realisiert werden, um von Vornherein die Machbarkeit von IVS-Diensten sicherzustellen.&lt;br /&gt;
 &lt;br /&gt;
*'''IVS-Taktiken...'''&lt;br /&gt;
**sind eher '''auf kurze Sicht angelegt. &lt;br /&gt;
**werden gewählt, um die gewünschten '''Ergebnisse auch bestmöglich sicherzustellen'''&lt;br /&gt;
**können zur Implementierung mehrerer IVS-Strategien beitragen.&lt;br /&gt;
&lt;br /&gt;
So wie IVS-Handlungsmuster mit den gewünschten Ergebnissen (IVS-Nutzen, IVS-Wirkung) eines IVS-Dienstes korrespondieren, sind '''IVS-Strategien''' auf die '''generelle Zielsetzung''' ausgerichtet. IVS-Taktiken werden hingegen gewählt, um die '''gewünschten Ergebnisse''' auch bestmöglich '''sicherzustellen''' (wobei dieser Zusammenhang nicht zwangsweise gilt). &lt;br /&gt;
'''IVS-Strategien und IVS-Taktiken sind nicht scharf voneinander getrennt'''. Im Einzelfall muss jeder für sich entscheiden, nach welchen Kriterien er beide definiert.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Handlungsmuster''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
! rowspan=&amp;quot;2&amp;quot; | IVS-Zielfeld !! rowspan=&amp;quot;2&amp;quot; | IVS-Handlungsoption (Mission) !! colspan=&amp;quot;2&amp;quot; |IVS-Handlungsmuster &lt;br /&gt;
|+&lt;br /&gt;
! !! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Implementierung von IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellen-Slotmanagement&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von energieverbrauchsfreundlichen IVS-Diensten&lt;br /&gt;
*Einrichtung von (dynamischen) Umweltzonen (bei Feststellung erhöhter Werte werden Maßnahmen wie Fahrverbote o.ä. ergriffen) &lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten &lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation &lt;br /&gt;
|&lt;br /&gt;
*Angebot von Push-Diensten&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Richtlinen (IVS-Politik und IVS-Regeln) (BMM = Directives) ====&lt;br /&gt;
&lt;br /&gt;
'''IVS-Richtlinien geben den IVS-Handlungsmustern sozusagen &amp;quot;die richtige Richtung&amp;quot;'''. Sie führen und lenken die Ausführung der IVS-Handlungsmuster nach politischen Vorgaben und anerkannten Regeln.&lt;br /&gt;
&lt;br /&gt;
*Auf der einen Seite ist mit IVS-Richtlinien '''Einschränkung''' verbunden. Durch Vorgabe von IVS-Richtlinien soll sichergestellt werden, dass IVS-Handlungsmuster - möglichst in intelligenter Weise - '''innerhalb vorgegebener Grenzen''' angewendet werden.&lt;br /&gt;
&lt;br /&gt;
*Auf der anderen Seite repräsentieren IVS-Richtlinien das verschlüsselte, in der Regel in schriftlicher Form '''dokumentierte Wissen''', das einem '''Handlungsmuster die Chance auf den höchstmöglichen Erfolg''' eröffnet.&lt;br /&gt;
 &lt;br /&gt;
IVS-Richtlinien werden kategorisiert nach:&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Politik(-richtlinien''')&lt;br /&gt;
**Grundsätzlich ist es Aufgabe der (IVS)-Politik zu '''regulieren''', d.h. die Anwendung von IVS in Form politischer (auch gesetzlicher) Vorgaben zu regeln oder-  mit anderen Worten ausgedrückt - '''zu steuern und zu führen''' und damit die angewandten IVS-Strategien und IVS-Taktiken zu gestalten.&lt;br /&gt;
**IVS-Politik legt fest, '''was getan werden darf, aber auch was getan werden muss''', und gibt an, wie oder '''in welchen Grenzen''' etwas getan werden kann.&lt;br /&gt;
** Im Vergleich zu IVS-Regeln ist '''IVS-Politik weniger strukturiert''' und auch weniger detailliert formuliert. '''IVS-Politik''' ist in diesem Sinne auch '''nicht direkt &amp;quot;ausführbar&amp;quot;'''.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Regeln (auch IVS-Prinzipien)'''&lt;br /&gt;
**IVS-Regeln leiten sich von der IVS-Politik ab und sind '''ausführbare IVS-Richtlinien'''. &lt;br /&gt;
**Sie müssen auch als solche definiert sein und aus Konsistenz- und Vollständigkeitsgründen muss '''ihre Ausführung überwacht und überprüft''' werden. &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Richtlinien''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!! rowspan=&amp;quot;2&amp;quot; |IVS- Zielfeld !! colspan=&amp;quot;2&amp;quot; | IVS-Handlungsmuster (Course of actions) !! colspan=&amp;quot;2&amp;quot; | (IVS-Richtlinien) Directive&lt;br /&gt;
|+&lt;br /&gt;
! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) !! IVS-Politik (Business Policy) !! IVS-Regeln  und IVS-Prinzipien (Business Rules)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellenmanagment&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
*Verstärtker Einsatz von Grüne-Welle Assistenten auf lichtsignalgereglten Strecken  &lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
*Implementation von Grüne-Welle Assistenten ab einer einer Morgenspitze &amp;gt; X Kfz/h   &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation&lt;br /&gt;
|&lt;br /&gt;
*Open-Data Initiative &lt;br /&gt;
|&lt;br /&gt;
*Schnittstellen grundsätzlich als DATEX II-Profile&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7464</id>
		<title>IVS-Geschäftsziele</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7464"/>
		<updated>2016-10-12T08:17:01Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Ergebnisse (Nutzen und Wirkung) von IVS-Diensten (BMM  = Desired results) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Einführung ==&lt;br /&gt;
&lt;br /&gt;
[[Datei: Business-Motivation-Model-top.png | thumb | 300 px | right | Übersichtsdarstellung des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
[[Datei: BMM.png | thumb | 300 px | right | Bestandteile des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
Um die Diskussion über die Formulierung von '''Ziel- und Realisierungsvorstellungen für IVS-Dienste''' von vorneherein auf eine methodisch konsistente und für jeden nachvollziehbare Basis zu stellen, wird im folgenden auf das&lt;br /&gt;
[[Media: Formal-15-05-20.pdf | '''Business Motivation Model''']] (BMM, Version 1.3) der [https://en.wikipedia.org/wiki/Business_Motivation_Model ''' OMG - Open Managment Group'''] zurückgegriffen.&lt;br /&gt;
&lt;br /&gt;
Das BMM-Business Motivation Modell (siehe nebenstehende Abbildung) beleuchtet die '''Anforderungen an das Business (Geschäft)''' eines Unternehmens/einer Organisation auf verschiedenen Ebenen, um gründlich und präzise zu erfassen und zu begründen:&lt;br /&gt;
*'''warum''' ein Unternehmen/eine Organisation '''handeln''' will (oder soll), &lt;br /&gt;
*worauf das Handeln abzielt und '''was am Ende erreicht werden soll''',&lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation plant, '''dorthin zu kommen''' und &lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation die erreichten '''Ergebnisse bewertet'''.&lt;br /&gt;
&lt;br /&gt;
Für die Beschreibung des &amp;quot;Business&amp;quot; definiert und verwendet das BMM verschiedene &lt;br /&gt;
Elemente (semantische Konzepte), die zueinander in Beziehung gesetzt werden. &lt;br /&gt;
Die wichtigsten Elemente sind:&lt;br /&gt;
*'''Ends''': ''Was'' (im Gegensatz zu ''Wie'') das Unternehmen/die Organisation - am Ende - erreichen möchte.&lt;br /&gt;
*'''Means''': ''Wie'' - mit welchen (Hilfs-)Mitteln - das Unternehmen/die Organisation beabsichtigt, seine ''Ends'' zu erreichen. &lt;br /&gt;
*'''Directives''': Die ''Regeln und Grundsätze'', die die verfügbaren Means einschränken bzw. regulieren. &lt;br /&gt;
*'''Influencers''': ''Einflussfaktoren'', die Änderungen erforderlich machen, während ein Unternehmen/eine Organisation mit den Means oder der Erreichung der Ends befasst ist. Influencers sind per Definition neutral.&lt;br /&gt;
*'''Assessment''': Eine ''Beurteilung'' eines Influencers, der die Fähigkeit eines Unternehmens bei der Erreichung seiner Ends oder Anwendung seiner Means beeinflusst.&lt;br /&gt;
&lt;br /&gt;
== Das Ends-Konzept (Formulierung von Zielvorstellungen) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
Im Kontext der Ziele-Diskussion für IVS-Dienste ist zunächst das '''Ends'''-Konzept von Bedeutung. Ends beschreiben, was ein Business (am Ende) sein will bzw. '''wo ein Business (am Ende) stehen will'''. Ends selber geben keine Auskunft darüber, wie sie erreicht werden sollen. Wenn wir den Business-Begriff auf den IVS-Dienst übertragen, d.h. '''wenn wir einen IVS-Dienst als Business begreifen und interpretieren''', hilft das Ends-Konzept, Ziele auf ihre Bedeutung hin sematisch zu differenzieren.&lt;br /&gt;
&lt;br /&gt;
=== Ends-Kategorien ===&lt;br /&gt;
&lt;br /&gt;
[[Datei: Ends-Konzept.png | thumb | 300 px | right | Ends-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie nebenstehndes UML-Diagramm zeigt, sind Ends kategorisiert als '''Vision''' and '''Desired Results'''. Desired Results als '''Goals''' und '''Objectives'''.&lt;br /&gt;
&lt;br /&gt;
*Eine '''Vision''' ist eine generelles Bild dafür, was ein Business zukünftig sein oder werden möchte. '''Hinweis''': das Business Motivation Model kann eingesetzt werden, auch wenn eine Vision nicht explizit festgelegt wurde.&lt;br /&gt;
*'''Desired Results (dts: gewünschte Ergebnisse)''', differenziert als '''Goals (dts: generelle Zielsetzung/Oberziel/Zweck)''' und '''Objectives (dts: messbare Einzelziele)''', sind spezifischer als Visionen: &lt;br /&gt;
**Ein '''Goal (dts: qualitatives Ziel)''' ist vom Wesen her eher langfristig ausgerichtet und eher qualitativ als quantitativ festgelegt. Es sollte jedoch gerade noch so zukunftsnah sein, dass dafür messbare Einzelziele definiert werden können.&lt;br /&gt;
**Ein '''Objective (dts: quantitatives Ziel)''' ist ein Schritt auf dem Weg hin zum generellen Ziel. Es quantifiziert ein stückweit das generelle Ziel. Es muss mit einem End-Datum verknüpft sein und es müssen Kriterien festgelegt sein, um darüber feststellen zu können, ob es erreicht wurde oder nicht. Messbare Einzelziele bilden die messbare Grundlage dafür, ob ein Forschritt in Richtung der Erfüllung der generellen Zielsetzung erreicht wurde.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Ends-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Visionen (BMM = Visions) ====&lt;br /&gt;
Jedes Unternehmen/jede Organisation hat natürliche Visionen, wo die Reise hingehen soll, d.h. wo das Unternehmen/die Organisation z.B. in 10 Jahren stehen will. Visionen sind aber '''oft nicht oder nur unscharf formuliert''' und treten in der Realität des Alltags oft in den Hintergrund. Für IVS allerdings haben Visionen eine große Bedeutung, weil IVS und IVS-Dienste im '''Kontext politischer und gesellschaftlicher Diskussionen über Verkehr, Transport und Mobilität einen große Rolle''' spielen.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Visionen''' für unterschiedliche IVS-Zielfelder zeigt folgende Tabelle:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== Ergebnisse (Nutzen und Wirkung) von IVS-Diensten (BMM  = Desired results)====  &lt;br /&gt;
Mit einem IVS-Dienst werden nicht nur Visionen sondern '''stets auch konkrete Ziele''' verfolgt. Für das Engagement von IVS-Akteuren und IVS-Stakeholdern soll sich ein bestimmter '''Gegenwert in Form eines Ergebnisses (IVS-Nutzen/IVS-Wirkung)''' einstellen.&lt;br /&gt;
 &lt;br /&gt;
Grundsätzlich ist natürlich für jeden IVS-Dienst '''das große Ganze''', also der IVS-Nutzen und den damit verbundenen  Mehrwert für den späteren IVS-End-Nutzer '''im Fokus zu behalten''' und gemeinsam daraufhin zu arbeiten. IVS-Nutzen entsteht, wenn IVS-End-Nutzer oder IVS-End-Nutzerkollektive Zugriff auf IVS-Informationen haben, um eigene IVS-Entscheidungen sicher, zuverlässing, schnell und effektiv treffen zu können.&lt;br /&gt;
 &lt;br /&gt;
In Abhängigkeit der '''rechtlichen Ausgangssituation von IVS-Akteuren oder Stakeholdern''' (privat oder öffentlich rechtlich) werden generelle IVS-Zielsetzungen in der Regel ganz '''unterschiedlich und ggfs. auch konfliktär formuliert und interpretiert'''.&lt;br /&gt;
&lt;br /&gt;
*für '''privatwirtschafliche finanzierte Unternehmen''' steht bei der Zielformulierung der eigene Business Case und der mit einem IVS-Dienst oder der Komformität zu einer IVS-Architekturvorgabe verbundene wirtschaftliche Mehrwert für das Unternehmen im Vordergrund. Somit sind privatrechtliche Unternehmen naturgemäß eher auf den individuellen IVS-Nutzen von solchen Kunden ausgerichtet, die letztendlich bereit sind, für den IVS-Dienst direkt oder indierekt zu bezahlen.&lt;br /&gt;
&lt;br /&gt;
*für '''steuerfinanzierte Institutionen des öffentlichen Rechts''' steht bei der Zielformulierung die Umsetzung politischer Vorgaben und genereller gesellschaftpolitischer Ziele (Daseinsvorsorge) und der mit einem IVS-Dienst verbundene Mehrwert für ein End-Nutzer-Kollektiv im Vordergrund. Naturgemäß sind Institutionen des öffentlichen Rechts auf den kollektiven Nutzen der &amp;quot;Kunden&amp;quot; ausgerichtet, die Steuern zahlen. &lt;br /&gt;
&lt;br /&gt;
Um privat-und steuerfinanzierten Nutzen von IVS-Diensten zu unterscheiden werden die Begriffe '''IVS-Nutzen (privatfinanziert)''' und '''IVS-Wirkung (steuerfinanziert)''' verwendet. IVS-Nutzen und IVS-Wirkung können als rein '''Qualitative IVS-Ziele''' (BMM = Goals) formuliert werden und/oder als '''Quantitative IVS-Ziele''' (BMM = Objectives) quantitativ messbar sein.  &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für Qualitative und Quantitative IVS-Ziele''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! Qualitative IVS-Ziele (Goals)!! Quantitative IVS-Ziele (Objectives)&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung von Auffahrunfällen&lt;br /&gt;
*Reduzierung von Unfällen in Baustellen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung der Unfallhäufigkeit in Folge von Staus um X% &lt;br /&gt;
*Reduzierung der Unfälle mit LKW um X%&lt;br /&gt;
*Reduzierung von Folgeunfällen bei Stau um X%&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung des Energieverbrauchs&lt;br /&gt;
*Reduzierung der Schadstoffemissionen&lt;br /&gt;
*Reduzierung der Lärmbelastungen&lt;br /&gt;
|&lt;br /&gt;
*Kraftstoffverbrauch um X% reduzieren&lt;br /&gt;
*CO2-Ausstoß um X% reduzieren &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
*Kontinuierliche Verbesserung des Modal Split von Pendlern&lt;br /&gt;
|&lt;br /&gt;
*Verbesserung der Nutzerfreundlichkeit bei der Anfrage von Reisealternativen der multimodalen Reiseplanung&lt;br /&gt;
*Aufklärung und Information der Reisenden&lt;br /&gt;
|&lt;br /&gt;
*Verkürzen der Latenzeit von der Reiseanfrage bis zur Präsentation der Reiseroute auf &amp;lt; 5 Sekunden&lt;br /&gt;
*Umstieg von 10 % der bisherigen PKW-Fahrer auf ÖPNV&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Da IVS-Dienste in der Regel nur durch die Kooperation und Zusammenarbeit ganz unterschiedlicher IVS-Akteure entstehen, müssen sich diese sich letzendlich auf gemeinsame Ziele verständigen ('''Zwang zum Konsens''').&lt;br /&gt;
&lt;br /&gt;
== Das Means-Konzept (das (Hilfs-)Mittel-Konzept) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
&lt;br /&gt;
Ein (Hilfs-)Mittel repäsentiert jede Art von spezieller Fähigkeit, System, Technologie, Regelwerk, Instrument oder Methode etc., die in Anspruch genommen, aktiviert oder verstärkt werden kann, um Ziele (Ends) zu erreichen. Hilfs-(Mittel) sagen jedoch weder etwas aus über Schritte (Geschäftsprozesse und -abläufe), die notwendig sind um sie zu nutzen, noch über Verantwortlichkeiten für solche Aufgaben, sondern lediglich über die Fähigkeiten, die mit den (Hilfs-)mitteln verbunden sind un die einsetzbar sind, um die gewünschten Ergebnisse (Ends) zu erzielen.&lt;br /&gt;
&lt;br /&gt;
Wenn man (Hilfs-)Mittel beschreibt, ist es auch nützlich zu dokumentieren, wer das (Hilfs-)Mittel zu welchem Zeitpunkt einsetzt, sodass für die Zukunft als Referenz ein Prüfpfad exisitiert.&lt;br /&gt;
&lt;br /&gt;
===Hilfs-(Mittel)-Kategorien ===&lt;br /&gt;
[[Datei: Means-Konzept.png | thumb | 300 px | right | Übersichtsdarstellung über das Means-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie im nebenstehenden UML-Diagramm sichtbar lässt sich das (Hilfs-)Mittel-Konzept als  Hierarchie darstellen und begreifen. &lt;br /&gt;
&lt;br /&gt;
Insofern können (Hilfs-)Mittel sein:&lt;br /&gt;
*eine '''Mission''' (Handlungsoption, Aktion, Auftrag)&lt;br /&gt;
*:Eine '''Mission''' oder auch '''Handlungsoption''' bezeichnet, wie ihr Gegenstück '''Vision''', einen Langzeit-Ansatz, der auf die Erfüllung der Vision fokussiert ist. Wie die Vision ist die Mission nicht sehr spezifisch formuliert. Die Entscheidung für eine Handlungsoption sollte sich danach richten, wie Ressourcen, Fähigkeiten, Fertigkeiten und Kompetenzen, auf die eine Unternehmen/eine Organisation zurückgreifen kann, am besten genutzt werden können, um die formulierten Ziele auch tatsächlich zu erreichen.&lt;br /&gt;
*ein '''Handlungsmuster''' (strategisch oder taktisch)&lt;br /&gt;
*:In gewisser Weise, sind '''Handlungsmuster''' von grundsätzlicher Natur. Sie sind jedoch stumpfe Instrumente, wenn sie nicht durch entsprechende Direktiven gestützt werden, um eine reale Chance zu haben, erfolgreich zu sein.  &lt;br /&gt;
*eine '''Direktive''' (Geschäftspolitik, Geschäftsregel)  &lt;br /&gt;
*:Im Gegensatz zu Handlungsmustern, können '''Direktiven (Vorschriften und Richtlinien)''' nicht für sich alleine stehen. Vielmehr geben sie den Handlungsmustern den richtigen Schliff. Mit anderen Worten stellen sie sicher, dass Handlungsmuster in intelligenter Weise innerhalb von Grenzen angewendet werden, die für ein Unternehmen/eine Unternehmung akzeptabel bzw. optimal sind. Kurz formuliert, Direktiven repräsentieren das verschlüsselte (z.B. in schriftlicher Form dokumentierte) Wissen, das einem Handlungsmuster die Chance auf den höchstmöglichen Erfolg eröffnet. &lt;br /&gt;
*:Eine Direktive hat auch etwas zu tun mit Führung und Lenkung. Im Gegensatz dazu identifiziert ein Handlungsmuster den aktiven Ansatz auf dem Weg hin zu den Ends. Ein Handlungsmuster ist immer aktionsorientiert.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Means-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Missionen/IVS-Handlungsoptionen (BMM = Missions) ====&lt;br /&gt;
IVS-Missionen sind '''IVS-Handlungsoptionen''', die zum Ausdruck bringen, auf welche '''Art von IVS-Diensten in welcher Kombination''' man grundsätzlich zurückgreifen kann bzw. welche Art von IVS-Diensten in welcher Kombination am besten geignet sind, um der mit der Vision formulierten Zielvorstellung näher zu kommen. Die Entscheidung für eine Art von IVS-Diensten bzw. Kombination von Diensten und ihre spezifische Ausgestaltung sollte sich danach richten, wie '''ganz aktuell z.b. finanzielle und personelle Ressourcen sowie Fähigkeiten, Fertigkeiten, Kompetenzen und Technologien am besten eingesetzt werden''', um die formulierten Ziele zu erreichen. IVS-Handlungsoptionen müssen jedoch einen als '''realistisch erachteten Zeithorizont''' haben. So sollten z.B. IVS-Dienste, die im betrachteten Zeitraum noch nicht die erforderliche Technologiereife erreicht haben, nicht als IVS-Handlungsoption in Erwägung gezogen werden.&lt;br /&gt;
&lt;br /&gt;
Beispiele für IVS-Handlungsoptionen zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! IVS-Handlungsoption (Mission)  &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport&lt;br /&gt;
|Einsatz von Kooperativen IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport&lt;br /&gt;
|&lt;br /&gt;
*Einsatz von energieverbrauchsdämpfenden IVS-Diensten (ITS und C-ITS)&lt;br /&gt;
*Vermehrtes Feinstaubmanagement &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (jederzeit, an jedem Ort)&lt;br /&gt;
|Einsatz von in Realzeit arbeitenden multimodalen IVS-Informationsdiensten &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Handlungsmuster (BMM = Course of action) ==== &lt;br /&gt;
'''IVS-Handlungsmuster''' geben vor, '''wie bei man bei der Wahl einer IVS-Mission/IVS-Handlungsoption am besten vorgeht'''. IVS-Handlungsmuster definieren '''was zu tun ist''', aber '''nicht wie gut etwas zu tun''' ist. IVS-Performance-Kriterien werden mit den Zielen formuliert, die durch Handlungsmuster unterstützt werden. IVS-Handlungsmuster zielen nicht immer unmittelbar auf die Erreichung von Ergebnissen. Manche sind sinnvoll, um andere IVS-Handlungsmuster zu ermöglichen. &lt;br /&gt;
&lt;br /&gt;
IVS-Handlungsmuster werden unterschieden nach: &lt;br /&gt;
*'''IVS-Strategien...'''&lt;br /&gt;
**sind eher '''langzeitorientiert''' und '''breit''' angelegt. &lt;br /&gt;
**sind als Merkmale, die strategische Einflussfaktoren und Rahmenbedingungen repräsentieren, '''wesentlich für den Erfolg eines IVS-Handlungsmusters'''. &lt;br /&gt;
**legen für IVS-Handlungsmuster beste Vorgehensweisen, widerspruchsfreie Verhaltensmuster, Positionierungen und Sichtweisen der IVS-Aktueure bei der Modellierung, Planung, Realisierung und dem Betrieb von Intelligenten Verkehrssystemen fest.&lt;br /&gt;
**sind Schlüsselfaktoren, die oftmals über '''Erfolg oder Misserfolg von IVS-Diensten''' entscheiden. Zu den strategischen Merkmalen gehören insbesondere Finanzierungskonzepte, aber oft auch zu schaffende rechtliche Rahmenbedingungen und technologische Voraussetzungen. Diese müssen frühzeitig identifiziert und realisiert werden, um von Vornherein die Machbarkeit von IVS-Diensten sicherzustellen.&lt;br /&gt;
 &lt;br /&gt;
*'''IVS-Taktiken...'''&lt;br /&gt;
**sind eher '''auf kurze Sicht angelegt. &lt;br /&gt;
**werden gewählt, um die gewünschten '''Ergebnisse auch bestmöglich sicherzustellen'''&lt;br /&gt;
**können zur Implementierung mehrerer IVS-Strategien beitragen.&lt;br /&gt;
&lt;br /&gt;
So wie IVS-Handlungsmuster mit den gewünschten Ergebnissen (IVS-Nutzen, IVS-Wirkung) eines IVS-Dienstes korrespondieren, sind '''IVS-Strategien''' auf die '''generelle Zielsetzung''' ausgerichtet. IVS-Taktiken werden hingegen gewählt, um die '''gewünschten Ergebnisse''' auch bestmöglich '''sicherzustellen''' (wobei dieser Zusammenhang nicht zwangsweise gilt). &lt;br /&gt;
'''IVS-Strategien und IVS-Taktiken sind nicht scharf voneinander getrennt'''. Im Einzelfall muss jeder für sich entscheiden, nach welchen Kriterien er beide definiert.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Handlungsmuster''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
! rowspan=&amp;quot;2&amp;quot; | IVS-Zielfeld !! rowspan=&amp;quot;2&amp;quot; | IVS-Handlungsoption (Mission) !! colspan=&amp;quot;2&amp;quot; |IVS-Handlungsmuster &lt;br /&gt;
|+&lt;br /&gt;
! !! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Implementierung von IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellen-Slotmanagement&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von energieverbrauchsfreundlichen IVS-Diensten&lt;br /&gt;
*Einrichtung von (dynamischen) Umweltzonen (bei Feststellung erhöhter Werte werden Maßnahmen wie Fahrverbote o.ä. ergriffen) &lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten &lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation &lt;br /&gt;
|&lt;br /&gt;
*Angebot von Push-Diensten&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Richtlinen (IVS-Politik und IVS-Regeln) (BMM = Directives) ====&lt;br /&gt;
&lt;br /&gt;
'''IVS-Richtlinien geben den IVS-Handlungsmustern sozusagen &amp;quot;die richtige Richtung&amp;quot;'''. Sie führen und lenken die Ausführung der IVS-Handlungsmuster nach politischen Vorgaben und anerkannten Regeln.&lt;br /&gt;
&lt;br /&gt;
*Auf der einen Seite ist mit IVS-Richtlinien '''Einschränkung''' verbunden. Durch Vorgabe von IVS-Richtlinien soll sichergestellt werden, dass IVS-Handlungsmuster - möglichst in intelligenter Weise - '''innerhalb vorgegebener Grenzen''' angewendet werden.&lt;br /&gt;
&lt;br /&gt;
*Auf der anderen Seite repräsentieren IVS-Richtlinien das verschlüsselte, in der Regel in schriftlicher Form '''dokumentierte Wissen''', das einem '''Handlungsmuster die Chance auf den höchstmöglichen Erfolg''' eröffnet.&lt;br /&gt;
 &lt;br /&gt;
IVS-Richtlinien werden kategorisiert nach:&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Politik(-richtlinien''')&lt;br /&gt;
**Grundsätzlich ist es Aufgabe der (IVS)-Politik zu '''regulieren''', d.h. die Anwendung von IVS in Form politischer (auch gesetzlicher) Vorgaben zu regeln oder-  mit anderen Worten ausgedrückt - '''zu steuern und zu führen''' und damit die angewandten IVS-Strategien und IVS-Taktiken zu gestalten.&lt;br /&gt;
**IVS-Politik legt fest, '''was getan werden darf, aber auch was getan werden muss''', und gibt an, wie oder '''in welchen Grenzen''' etwas getan werden kann.&lt;br /&gt;
** Im Vergleich zu IVS-Regeln ist '''IVS-Politik weniger strukturiert''' und auch weniger detailliert formuliert. '''IVS-Politik''' ist in diesem Sinne auch '''nicht direkt &amp;quot;ausführbar&amp;quot;'''.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Regeln (auch IVS-Prinzipien)'''&lt;br /&gt;
**IVS-Regeln leiten sich von der IVS-Politik ab und sind '''ausführbare IVS-Richtlinien'''. &lt;br /&gt;
**Sie müssen auch als solche definiert sein und aus Konsistenz- und Vollständigkeitsgründen muss '''ihre Ausführung überwacht und überprüft''' werden. &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Richtlinien''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!! rowspan=&amp;quot;2&amp;quot; |IVS- Zielfeld !! colspan=&amp;quot;2&amp;quot; | IVS-Handlungsmuster (Course of actions) !! colspan=&amp;quot;2&amp;quot; | (IVS-Richtlinien) Directive&lt;br /&gt;
|+&lt;br /&gt;
! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) !! IVS-Politik (Business Policy) !! IVS-Regeln  und IVS-Prinzipien (Business Rules)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellenmanagment&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
*Verstärtker Einsatz von Grüne-Welle Assistenten auf lichtsignalgereglten Strecken  &lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
*Implementation von Grüne-Welle Assistenten ab einer einer Morgenspitze &amp;gt; X Kfz/h   &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation&lt;br /&gt;
|&lt;br /&gt;
*Open-Data Initiative &lt;br /&gt;
|&lt;br /&gt;
*Schnittstellen grundsätzlich als DATEX II-Profile&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7463</id>
		<title>IVS-Geschäftsziele</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7463"/>
		<updated>2016-10-12T08:12:21Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* IVS-Visionen (BMM = Visions) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Einführung ==&lt;br /&gt;
&lt;br /&gt;
[[Datei: Business-Motivation-Model-top.png | thumb | 300 px | right | Übersichtsdarstellung des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
[[Datei: BMM.png | thumb | 300 px | right | Bestandteile des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
Um die Diskussion über die Formulierung von '''Ziel- und Realisierungsvorstellungen für IVS-Dienste''' von vorneherein auf eine methodisch konsistente und für jeden nachvollziehbare Basis zu stellen, wird im folgenden auf das&lt;br /&gt;
[[Media: Formal-15-05-20.pdf | '''Business Motivation Model''']] (BMM, Version 1.3) der [https://en.wikipedia.org/wiki/Business_Motivation_Model ''' OMG - Open Managment Group'''] zurückgegriffen.&lt;br /&gt;
&lt;br /&gt;
Das BMM-Business Motivation Modell (siehe nebenstehende Abbildung) beleuchtet die '''Anforderungen an das Business (Geschäft)''' eines Unternehmens/einer Organisation auf verschiedenen Ebenen, um gründlich und präzise zu erfassen und zu begründen:&lt;br /&gt;
*'''warum''' ein Unternehmen/eine Organisation '''handeln''' will (oder soll), &lt;br /&gt;
*worauf das Handeln abzielt und '''was am Ende erreicht werden soll''',&lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation plant, '''dorthin zu kommen''' und &lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation die erreichten '''Ergebnisse bewertet'''.&lt;br /&gt;
&lt;br /&gt;
Für die Beschreibung des &amp;quot;Business&amp;quot; definiert und verwendet das BMM verschiedene &lt;br /&gt;
Elemente (semantische Konzepte), die zueinander in Beziehung gesetzt werden. &lt;br /&gt;
Die wichtigsten Elemente sind:&lt;br /&gt;
*'''Ends''': ''Was'' (im Gegensatz zu ''Wie'') das Unternehmen/die Organisation - am Ende - erreichen möchte.&lt;br /&gt;
*'''Means''': ''Wie'' - mit welchen (Hilfs-)Mitteln - das Unternehmen/die Organisation beabsichtigt, seine ''Ends'' zu erreichen. &lt;br /&gt;
*'''Directives''': Die ''Regeln und Grundsätze'', die die verfügbaren Means einschränken bzw. regulieren. &lt;br /&gt;
*'''Influencers''': ''Einflussfaktoren'', die Änderungen erforderlich machen, während ein Unternehmen/eine Organisation mit den Means oder der Erreichung der Ends befasst ist. Influencers sind per Definition neutral.&lt;br /&gt;
*'''Assessment''': Eine ''Beurteilung'' eines Influencers, der die Fähigkeit eines Unternehmens bei der Erreichung seiner Ends oder Anwendung seiner Means beeinflusst.&lt;br /&gt;
&lt;br /&gt;
== Das Ends-Konzept (Formulierung von Zielvorstellungen) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
Im Kontext der Ziele-Diskussion für IVS-Dienste ist zunächst das '''Ends'''-Konzept von Bedeutung. Ends beschreiben, was ein Business (am Ende) sein will bzw. '''wo ein Business (am Ende) stehen will'''. Ends selber geben keine Auskunft darüber, wie sie erreicht werden sollen. Wenn wir den Business-Begriff auf den IVS-Dienst übertragen, d.h. '''wenn wir einen IVS-Dienst als Business begreifen und interpretieren''', hilft das Ends-Konzept, Ziele auf ihre Bedeutung hin sematisch zu differenzieren.&lt;br /&gt;
&lt;br /&gt;
=== Ends-Kategorien ===&lt;br /&gt;
&lt;br /&gt;
[[Datei: Ends-Konzept.png | thumb | 300 px | right | Ends-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie nebenstehndes UML-Diagramm zeigt, sind Ends kategorisiert als '''Vision''' and '''Desired Results'''. Desired Results als '''Goals''' und '''Objectives'''.&lt;br /&gt;
&lt;br /&gt;
*Eine '''Vision''' ist eine generelles Bild dafür, was ein Business zukünftig sein oder werden möchte. '''Hinweis''': das Business Motivation Model kann eingesetzt werden, auch wenn eine Vision nicht explizit festgelegt wurde.&lt;br /&gt;
*'''Desired Results (dts: gewünschte Ergebnisse)''', differenziert als '''Goals (dts: generelle Zielsetzung/Oberziel/Zweck)''' und '''Objectives (dts: messbare Einzelziele)''', sind spezifischer als Visionen: &lt;br /&gt;
**Ein '''Goal (dts: qualitatives Ziel)''' ist vom Wesen her eher langfristig ausgerichtet und eher qualitativ als quantitativ festgelegt. Es sollte jedoch gerade noch so zukunftsnah sein, dass dafür messbare Einzelziele definiert werden können.&lt;br /&gt;
**Ein '''Objective (dts: quantitatives Ziel)''' ist ein Schritt auf dem Weg hin zum generellen Ziel. Es quantifiziert ein stückweit das generelle Ziel. Es muss mit einem End-Datum verknüpft sein und es müssen Kriterien festgelegt sein, um darüber feststellen zu können, ob es erreicht wurde oder nicht. Messbare Einzelziele bilden die messbare Grundlage dafür, ob ein Forschritt in Richtung der Erfüllung der generellen Zielsetzung erreicht wurde.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Ends-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Visionen (BMM = Visions) ====&lt;br /&gt;
Jedes Unternehmen/jede Organisation hat natürliche Visionen, wo die Reise hingehen soll, d.h. wo das Unternehmen/die Organisation z.B. in 10 Jahren stehen will. Visionen sind aber '''oft nicht oder nur unscharf formuliert''' und treten in der Realität des Alltags oft in den Hintergrund. Für IVS allerdings haben Visionen eine große Bedeutung, weil IVS und IVS-Dienste im '''Kontext politischer und gesellschaftlicher Diskussionen über Verkehr, Transport und Mobilität einen große Rolle''' spielen.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Visionen''' für unterschiedliche IVS-Zielfelder zeigt folgende Tabelle:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== Ergebnisse (Nutzen und Wirkung) von IVS-Diensten (BMM  = Desired results)====  &lt;br /&gt;
Mit einem IVS-Dienst werden nicht nur Visionen sondern '''stets auch konkrete Ziele''' verfolgt. Für das Engagement von IVS-Akteuren und IVS-Stakeholdern soll sich ein bestimmter '''Gegenwert in Form eines Ergebnisses (IVS-Nutzen/IVS-Wirkung)''' einstellen.&lt;br /&gt;
 &lt;br /&gt;
Grundsätzlich ist natürlich für jeden IVS-Dienst '''das große Ganze''', also der IVS-Nutzen und den damit verbundenen  Mehrwert für den späteren IVS-End-Nutzer '''im Fokus zu behalten''' und gemeinsam daraufhin zu arbeiten. IVS-Nutzen entsteht, wenn IVS-End-Nutzer oder IVS-End-Nutzerkollektive Zugriff auf IVS-Informationen haben, um eigene IVS-Entscheidungen sicher, zuverlässing, schnell und effektiv treffen zu können.&lt;br /&gt;
 &lt;br /&gt;
In Abhängigkeit der '''rechtlichen Ausgangssituation von IVS-Akteuren oder Stakeholdern''' (privat oder öffentlich rechtlich) werden generelle IVS-Zielsetzungen in der Regel ganz '''unterschiedlich und ggfs. auch konfliktär formuliert und interpretiert'''.&lt;br /&gt;
&lt;br /&gt;
*für '''privatwirtschafliche finanzierte Unternehmen''' steht bei der Zielformulierung der eigene Business Case und der mit einem IVS-Dienst oder der Komformität zu einer IVS-Architekturvorgabe verbundene wirtschaftliche Mehrwert für das Unternehmen im Vordergrund. Somit sind privatrechtliche Unternehmen naturgemäß eher auf den individuellen IVS-Nutzen von solchen Kunden ausgerichtet, die letztendlich bereit sind, für den IVS-Dienst direkt oder indierekt zu bezahlen.&lt;br /&gt;
&lt;br /&gt;
*für '''steuerfinanzierte Institutionen des öffentlichen Rechts''' steht bei der Zielformulierung die Umsetzung politischer Vorgaben und genereller gesellschaftpolitischer Ziele (Daseinsvorsorge) und der mit einem IVS-Dienst verbundene Mehrwert für ein End-Nutzer-Kollektiv im Vordergrund. Naturgemäß sind Institutionen des öffentlichen Rechts auf den kollektiven Nutzen der &amp;quot;Kunden&amp;quot; ausgerichtet, die Steuern zahlen. &lt;br /&gt;
&lt;br /&gt;
Um privat-und steuerfinanzierten Nutzen von IVS-Diensten zu unterscheiden werden die Begriffe '''IVS-Nutzen (privatfinanziert)''' und '''IVS-Wirkung (steuerfinanziert)''' verwendet. IVS-Nutzen und IVS-Wirkung können als rein '''Qualitative IVS-Ziele''' (BMM = Goals) formuliert werden und/oder als '''Quantitative IVS-Ziele''' (BMM = Objectives) quantitativ messbar sein.  &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für Qualitative und Quantitative IVS-Ziele''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! Qualitative IVS-Ziele (Goals)!! Quantitative IVS-Ziele (Objectives)&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung von Auffahrunfällen&lt;br /&gt;
*Reduzierung von Unfällen in Baustellen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung der Unfallhäufigkeit in Folge von Staus um X% &lt;br /&gt;
*Reduzierung der Unfälle mit LKW um X%&lt;br /&gt;
*Reduzierung von Folgeunfällen bei Stau um X%&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung des Energieverbrauchs&lt;br /&gt;
*Reduzierung der Schadstoffemissionen&lt;br /&gt;
*Reduzierung der Lärmbelastungen&lt;br /&gt;
|&lt;br /&gt;
*Kraftstoffverbrauch um X% reduzieren&lt;br /&gt;
*CO2-Ausstoß um X% reduzieren &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
*Kontinuierliche Verbesserung des Modal Split von Pendlern&lt;br /&gt;
|&lt;br /&gt;
*Verbesserung der Nutzerfreundlichkeit bei der Anfrage von Reisealternativen der multimodalen Reiseplanung&lt;br /&gt;
*Aufklärung und Information der Reisenden&lt;br /&gt;
|&lt;br /&gt;
*Verkürzen der Latenzeit von der Reiseanfrage bis zur Präsentation der Reiseroute auf &amp;lt; 5 Sekunden&lt;br /&gt;
*10 % der bisherigen PKW-Fahrer steigen auf ÖPNV um&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Da IVS-Dienste in der Regel nur durch die Kooperation und Zusammenarbeit ganz unterschiedlicher IVS-Akteure entstehen, müssen sich diese sich letzendlich auf gemeinsame Ziele verständigen ('''Zwang zum Konsens''').&lt;br /&gt;
&lt;br /&gt;
== Das Means-Konzept (das (Hilfs-)Mittel-Konzept) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
&lt;br /&gt;
Ein (Hilfs-)Mittel repäsentiert jede Art von spezieller Fähigkeit, System, Technologie, Regelwerk, Instrument oder Methode etc., die in Anspruch genommen, aktiviert oder verstärkt werden kann, um Ziele (Ends) zu erreichen. Hilfs-(Mittel) sagen jedoch weder etwas aus über Schritte (Geschäftsprozesse und -abläufe), die notwendig sind um sie zu nutzen, noch über Verantwortlichkeiten für solche Aufgaben, sondern lediglich über die Fähigkeiten, die mit den (Hilfs-)mitteln verbunden sind un die einsetzbar sind, um die gewünschten Ergebnisse (Ends) zu erzielen.&lt;br /&gt;
&lt;br /&gt;
Wenn man (Hilfs-)Mittel beschreibt, ist es auch nützlich zu dokumentieren, wer das (Hilfs-)Mittel zu welchem Zeitpunkt einsetzt, sodass für die Zukunft als Referenz ein Prüfpfad exisitiert.&lt;br /&gt;
&lt;br /&gt;
===Hilfs-(Mittel)-Kategorien ===&lt;br /&gt;
[[Datei: Means-Konzept.png | thumb | 300 px | right | Übersichtsdarstellung über das Means-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie im nebenstehenden UML-Diagramm sichtbar lässt sich das (Hilfs-)Mittel-Konzept als  Hierarchie darstellen und begreifen. &lt;br /&gt;
&lt;br /&gt;
Insofern können (Hilfs-)Mittel sein:&lt;br /&gt;
*eine '''Mission''' (Handlungsoption, Aktion, Auftrag)&lt;br /&gt;
*:Eine '''Mission''' oder auch '''Handlungsoption''' bezeichnet, wie ihr Gegenstück '''Vision''', einen Langzeit-Ansatz, der auf die Erfüllung der Vision fokussiert ist. Wie die Vision ist die Mission nicht sehr spezifisch formuliert. Die Entscheidung für eine Handlungsoption sollte sich danach richten, wie Ressourcen, Fähigkeiten, Fertigkeiten und Kompetenzen, auf die eine Unternehmen/eine Organisation zurückgreifen kann, am besten genutzt werden können, um die formulierten Ziele auch tatsächlich zu erreichen.&lt;br /&gt;
*ein '''Handlungsmuster''' (strategisch oder taktisch)&lt;br /&gt;
*:In gewisser Weise, sind '''Handlungsmuster''' von grundsätzlicher Natur. Sie sind jedoch stumpfe Instrumente, wenn sie nicht durch entsprechende Direktiven gestützt werden, um eine reale Chance zu haben, erfolgreich zu sein.  &lt;br /&gt;
*eine '''Direktive''' (Geschäftspolitik, Geschäftsregel)  &lt;br /&gt;
*:Im Gegensatz zu Handlungsmustern, können '''Direktiven (Vorschriften und Richtlinien)''' nicht für sich alleine stehen. Vielmehr geben sie den Handlungsmustern den richtigen Schliff. Mit anderen Worten stellen sie sicher, dass Handlungsmuster in intelligenter Weise innerhalb von Grenzen angewendet werden, die für ein Unternehmen/eine Unternehmung akzeptabel bzw. optimal sind. Kurz formuliert, Direktiven repräsentieren das verschlüsselte (z.B. in schriftlicher Form dokumentierte) Wissen, das einem Handlungsmuster die Chance auf den höchstmöglichen Erfolg eröffnet. &lt;br /&gt;
*:Eine Direktive hat auch etwas zu tun mit Führung und Lenkung. Im Gegensatz dazu identifiziert ein Handlungsmuster den aktiven Ansatz auf dem Weg hin zu den Ends. Ein Handlungsmuster ist immer aktionsorientiert.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Means-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Missionen/IVS-Handlungsoptionen (BMM = Missions) ====&lt;br /&gt;
IVS-Missionen sind '''IVS-Handlungsoptionen''', die zum Ausdruck bringen, auf welche '''Art von IVS-Diensten in welcher Kombination''' man grundsätzlich zurückgreifen kann bzw. welche Art von IVS-Diensten in welcher Kombination am besten geignet sind, um der mit der Vision formulierten Zielvorstellung näher zu kommen. Die Entscheidung für eine Art von IVS-Diensten bzw. Kombination von Diensten und ihre spezifische Ausgestaltung sollte sich danach richten, wie '''ganz aktuell z.b. finanzielle und personelle Ressourcen sowie Fähigkeiten, Fertigkeiten, Kompetenzen und Technologien am besten eingesetzt werden''', um die formulierten Ziele zu erreichen. IVS-Handlungsoptionen müssen jedoch einen als '''realistisch erachteten Zeithorizont''' haben. So sollten z.B. IVS-Dienste, die im betrachteten Zeitraum noch nicht die erforderliche Technologiereife erreicht haben, nicht als IVS-Handlungsoption in Erwägung gezogen werden.&lt;br /&gt;
&lt;br /&gt;
Beispiele für IVS-Handlungsoptionen zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! IVS-Handlungsoption (Mission)  &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport&lt;br /&gt;
|Einsatz von Kooperativen IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport&lt;br /&gt;
|&lt;br /&gt;
*Einsatz von energieverbrauchsdämpfenden IVS-Diensten (ITS und C-ITS)&lt;br /&gt;
*Vermehrtes Feinstaubmanagement &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (jederzeit, an jedem Ort)&lt;br /&gt;
|Einsatz von in Realzeit arbeitenden multimodalen IVS-Informationsdiensten &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Handlungsmuster (BMM = Course of action) ==== &lt;br /&gt;
'''IVS-Handlungsmuster''' geben vor, '''wie bei man bei der Wahl einer IVS-Mission/IVS-Handlungsoption am besten vorgeht'''. IVS-Handlungsmuster definieren '''was zu tun ist''', aber '''nicht wie gut etwas zu tun''' ist. IVS-Performance-Kriterien werden mit den Zielen formuliert, die durch Handlungsmuster unterstützt werden. IVS-Handlungsmuster zielen nicht immer unmittelbar auf die Erreichung von Ergebnissen. Manche sind sinnvoll, um andere IVS-Handlungsmuster zu ermöglichen. &lt;br /&gt;
&lt;br /&gt;
IVS-Handlungsmuster werden unterschieden nach: &lt;br /&gt;
*'''IVS-Strategien...'''&lt;br /&gt;
**sind eher '''langzeitorientiert''' und '''breit''' angelegt. &lt;br /&gt;
**sind als Merkmale, die strategische Einflussfaktoren und Rahmenbedingungen repräsentieren, '''wesentlich für den Erfolg eines IVS-Handlungsmusters'''. &lt;br /&gt;
**legen für IVS-Handlungsmuster beste Vorgehensweisen, widerspruchsfreie Verhaltensmuster, Positionierungen und Sichtweisen der IVS-Aktueure bei der Modellierung, Planung, Realisierung und dem Betrieb von Intelligenten Verkehrssystemen fest.&lt;br /&gt;
**sind Schlüsselfaktoren, die oftmals über '''Erfolg oder Misserfolg von IVS-Diensten''' entscheiden. Zu den strategischen Merkmalen gehören insbesondere Finanzierungskonzepte, aber oft auch zu schaffende rechtliche Rahmenbedingungen und technologische Voraussetzungen. Diese müssen frühzeitig identifiziert und realisiert werden, um von Vornherein die Machbarkeit von IVS-Diensten sicherzustellen.&lt;br /&gt;
 &lt;br /&gt;
*'''IVS-Taktiken...'''&lt;br /&gt;
**sind eher '''auf kurze Sicht angelegt. &lt;br /&gt;
**werden gewählt, um die gewünschten '''Ergebnisse auch bestmöglich sicherzustellen'''&lt;br /&gt;
**können zur Implementierung mehrerer IVS-Strategien beitragen.&lt;br /&gt;
&lt;br /&gt;
So wie IVS-Handlungsmuster mit den gewünschten Ergebnissen (IVS-Nutzen, IVS-Wirkung) eines IVS-Dienstes korrespondieren, sind '''IVS-Strategien''' auf die '''generelle Zielsetzung''' ausgerichtet. IVS-Taktiken werden hingegen gewählt, um die '''gewünschten Ergebnisse''' auch bestmöglich '''sicherzustellen''' (wobei dieser Zusammenhang nicht zwangsweise gilt). &lt;br /&gt;
'''IVS-Strategien und IVS-Taktiken sind nicht scharf voneinander getrennt'''. Im Einzelfall muss jeder für sich entscheiden, nach welchen Kriterien er beide definiert.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Handlungsmuster''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
! rowspan=&amp;quot;2&amp;quot; | IVS-Zielfeld !! rowspan=&amp;quot;2&amp;quot; | IVS-Handlungsoption (Mission) !! colspan=&amp;quot;2&amp;quot; |IVS-Handlungsmuster &lt;br /&gt;
|+&lt;br /&gt;
! !! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Implementierung von IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellen-Slotmanagement&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von energieverbrauchsfreundlichen IVS-Diensten&lt;br /&gt;
*Einrichtung von (dynamischen) Umweltzonen (bei Feststellung erhöhter Werte werden Maßnahmen wie Fahrverbote o.ä. ergriffen) &lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten &lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation &lt;br /&gt;
|&lt;br /&gt;
*Angebot von Push-Diensten&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Richtlinen (IVS-Politik und IVS-Regeln) (BMM = Directives) ====&lt;br /&gt;
&lt;br /&gt;
'''IVS-Richtlinien geben den IVS-Handlungsmustern sozusagen &amp;quot;die richtige Richtung&amp;quot;'''. Sie führen und lenken die Ausführung der IVS-Handlungsmuster nach politischen Vorgaben und anerkannten Regeln.&lt;br /&gt;
&lt;br /&gt;
*Auf der einen Seite ist mit IVS-Richtlinien '''Einschränkung''' verbunden. Durch Vorgabe von IVS-Richtlinien soll sichergestellt werden, dass IVS-Handlungsmuster - möglichst in intelligenter Weise - '''innerhalb vorgegebener Grenzen''' angewendet werden.&lt;br /&gt;
&lt;br /&gt;
*Auf der anderen Seite repräsentieren IVS-Richtlinien das verschlüsselte, in der Regel in schriftlicher Form '''dokumentierte Wissen''', das einem '''Handlungsmuster die Chance auf den höchstmöglichen Erfolg''' eröffnet.&lt;br /&gt;
 &lt;br /&gt;
IVS-Richtlinien werden kategorisiert nach:&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Politik(-richtlinien''')&lt;br /&gt;
**Grundsätzlich ist es Aufgabe der (IVS)-Politik zu '''regulieren''', d.h. die Anwendung von IVS in Form politischer (auch gesetzlicher) Vorgaben zu regeln oder-  mit anderen Worten ausgedrückt - '''zu steuern und zu führen''' und damit die angewandten IVS-Strategien und IVS-Taktiken zu gestalten.&lt;br /&gt;
**IVS-Politik legt fest, '''was getan werden darf, aber auch was getan werden muss''', und gibt an, wie oder '''in welchen Grenzen''' etwas getan werden kann.&lt;br /&gt;
** Im Vergleich zu IVS-Regeln ist '''IVS-Politik weniger strukturiert''' und auch weniger detailliert formuliert. '''IVS-Politik''' ist in diesem Sinne auch '''nicht direkt &amp;quot;ausführbar&amp;quot;'''.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Regeln (auch IVS-Prinzipien)'''&lt;br /&gt;
**IVS-Regeln leiten sich von der IVS-Politik ab und sind '''ausführbare IVS-Richtlinien'''. &lt;br /&gt;
**Sie müssen auch als solche definiert sein und aus Konsistenz- und Vollständigkeitsgründen muss '''ihre Ausführung überwacht und überprüft''' werden. &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Richtlinien''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!! rowspan=&amp;quot;2&amp;quot; |IVS- Zielfeld !! colspan=&amp;quot;2&amp;quot; | IVS-Handlungsmuster (Course of actions) !! colspan=&amp;quot;2&amp;quot; | (IVS-Richtlinien) Directive&lt;br /&gt;
|+&lt;br /&gt;
! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) !! IVS-Politik (Business Policy) !! IVS-Regeln  und IVS-Prinzipien (Business Rules)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellenmanagment&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
*Verstärtker Einsatz von Grüne-Welle Assistenten auf lichtsignalgereglten Strecken  &lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
*Implementation von Grüne-Welle Assistenten ab einer einer Morgenspitze &amp;gt; X Kfz/h   &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation&lt;br /&gt;
|&lt;br /&gt;
*Open-Data Initiative &lt;br /&gt;
|&lt;br /&gt;
*Schnittstellen grundsätzlich als DATEX II-Profile&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7462</id>
		<title>IVS-Geschäftsziele</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7462"/>
		<updated>2016-10-12T08:10:35Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Ends-Kategorien */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Einführung ==&lt;br /&gt;
&lt;br /&gt;
[[Datei: Business-Motivation-Model-top.png | thumb | 300 px | right | Übersichtsdarstellung des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
[[Datei: BMM.png | thumb | 300 px | right | Bestandteile des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
Um die Diskussion über die Formulierung von '''Ziel- und Realisierungsvorstellungen für IVS-Dienste''' von vorneherein auf eine methodisch konsistente und für jeden nachvollziehbare Basis zu stellen, wird im folgenden auf das&lt;br /&gt;
[[Media: Formal-15-05-20.pdf | '''Business Motivation Model''']] (BMM, Version 1.3) der [https://en.wikipedia.org/wiki/Business_Motivation_Model ''' OMG - Open Managment Group'''] zurückgegriffen.&lt;br /&gt;
&lt;br /&gt;
Das BMM-Business Motivation Modell (siehe nebenstehende Abbildung) beleuchtet die '''Anforderungen an das Business (Geschäft)''' eines Unternehmens/einer Organisation auf verschiedenen Ebenen, um gründlich und präzise zu erfassen und zu begründen:&lt;br /&gt;
*'''warum''' ein Unternehmen/eine Organisation '''handeln''' will (oder soll), &lt;br /&gt;
*worauf das Handeln abzielt und '''was am Ende erreicht werden soll''',&lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation plant, '''dorthin zu kommen''' und &lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation die erreichten '''Ergebnisse bewertet'''.&lt;br /&gt;
&lt;br /&gt;
Für die Beschreibung des &amp;quot;Business&amp;quot; definiert und verwendet das BMM verschiedene &lt;br /&gt;
Elemente (semantische Konzepte), die zueinander in Beziehung gesetzt werden. &lt;br /&gt;
Die wichtigsten Elemente sind:&lt;br /&gt;
*'''Ends''': ''Was'' (im Gegensatz zu ''Wie'') das Unternehmen/die Organisation - am Ende - erreichen möchte.&lt;br /&gt;
*'''Means''': ''Wie'' - mit welchen (Hilfs-)Mitteln - das Unternehmen/die Organisation beabsichtigt, seine ''Ends'' zu erreichen. &lt;br /&gt;
*'''Directives''': Die ''Regeln und Grundsätze'', die die verfügbaren Means einschränken bzw. regulieren. &lt;br /&gt;
*'''Influencers''': ''Einflussfaktoren'', die Änderungen erforderlich machen, während ein Unternehmen/eine Organisation mit den Means oder der Erreichung der Ends befasst ist. Influencers sind per Definition neutral.&lt;br /&gt;
*'''Assessment''': Eine ''Beurteilung'' eines Influencers, der die Fähigkeit eines Unternehmens bei der Erreichung seiner Ends oder Anwendung seiner Means beeinflusst.&lt;br /&gt;
&lt;br /&gt;
== Das Ends-Konzept (Formulierung von Zielvorstellungen) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
Im Kontext der Ziele-Diskussion für IVS-Dienste ist zunächst das '''Ends'''-Konzept von Bedeutung. Ends beschreiben, was ein Business (am Ende) sein will bzw. '''wo ein Business (am Ende) stehen will'''. Ends selber geben keine Auskunft darüber, wie sie erreicht werden sollen. Wenn wir den Business-Begriff auf den IVS-Dienst übertragen, d.h. '''wenn wir einen IVS-Dienst als Business begreifen und interpretieren''', hilft das Ends-Konzept, Ziele auf ihre Bedeutung hin sematisch zu differenzieren.&lt;br /&gt;
&lt;br /&gt;
=== Ends-Kategorien ===&lt;br /&gt;
&lt;br /&gt;
[[Datei: Ends-Konzept.png | thumb | 300 px | right | Ends-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie nebenstehndes UML-Diagramm zeigt, sind Ends kategorisiert als '''Vision''' and '''Desired Results'''. Desired Results als '''Goals''' und '''Objectives'''.&lt;br /&gt;
&lt;br /&gt;
*Eine '''Vision''' ist eine generelles Bild dafür, was ein Business zukünftig sein oder werden möchte. '''Hinweis''': das Business Motivation Model kann eingesetzt werden, auch wenn eine Vision nicht explizit festgelegt wurde.&lt;br /&gt;
*'''Desired Results (dts: gewünschte Ergebnisse)''', differenziert als '''Goals (dts: generelle Zielsetzung/Oberziel/Zweck)''' und '''Objectives (dts: messbare Einzelziele)''', sind spezifischer als Visionen: &lt;br /&gt;
**Ein '''Goal (dts: qualitatives Ziel)''' ist vom Wesen her eher langfristig ausgerichtet und eher qualitativ als quantitativ festgelegt. Es sollte jedoch gerade noch so zukunftsnah sein, dass dafür messbare Einzelziele definiert werden können.&lt;br /&gt;
**Ein '''Objective (dts: quantitatives Ziel)''' ist ein Schritt auf dem Weg hin zum generellen Ziel. Es quantifiziert ein stückweit das generelle Ziel. Es muss mit einem End-Datum verknüpft sein und es müssen Kriterien festgelegt sein, um darüber feststellen zu können, ob es erreicht wurde oder nicht. Messbare Einzelziele bilden die messbare Grundlage dafür, ob ein Forschritt in Richtung der Erfüllung der generellen Zielsetzung erreicht wurde.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Ends-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Visionen (BMM = Visions) ====&lt;br /&gt;
Jedes Unternehmen/jede Organisation hat natürliche Visionen, wo die Reise hingehen soll, wo man z.B. in 10 Jahren stehen will. Visionen sind aber '''oft nicht oder nur unscharf formuliert''' und treten in der Realität des Alltags oft in den Hintergrund. Für IVS allerdings haben Visionen eine große Bedeutung, weil IVS und IVS-Dienste im '''Kontext politischer und gesellschaftlicher Diskussionen über Verkehr, Transport und Mobilität einen große Rolle''' spielen.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Visionen''' für unterschiedliche IVS-Zielfelder zeigt folgende Tabelle:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== Ergebnisse (Nutzen und Wirkung) von IVS-Diensten (BMM  = Desired results)====  &lt;br /&gt;
Mit einem IVS-Dienst werden nicht nur Visionen sondern '''stets auch konkrete Ziele''' verfolgt. Für das Engagement von IVS-Akteuren und IVS-Stakeholdern soll sich ein bestimmter '''Gegenwert in Form eines Ergebnisses (IVS-Nutzen/IVS-Wirkung)''' einstellen.&lt;br /&gt;
 &lt;br /&gt;
Grundsätzlich ist natürlich für jeden IVS-Dienst '''das große Ganze''', also der IVS-Nutzen und den damit verbundenen  Mehrwert für den späteren IVS-End-Nutzer '''im Fokus zu behalten''' und gemeinsam daraufhin zu arbeiten. IVS-Nutzen entsteht, wenn IVS-End-Nutzer oder IVS-End-Nutzerkollektive Zugriff auf IVS-Informationen haben, um eigene IVS-Entscheidungen sicher, zuverlässing, schnell und effektiv treffen zu können.&lt;br /&gt;
 &lt;br /&gt;
In Abhängigkeit der '''rechtlichen Ausgangssituation von IVS-Akteuren oder Stakeholdern''' (privat oder öffentlich rechtlich) werden generelle IVS-Zielsetzungen in der Regel ganz '''unterschiedlich und ggfs. auch konfliktär formuliert und interpretiert'''.&lt;br /&gt;
&lt;br /&gt;
*für '''privatwirtschafliche finanzierte Unternehmen''' steht bei der Zielformulierung der eigene Business Case und der mit einem IVS-Dienst oder der Komformität zu einer IVS-Architekturvorgabe verbundene wirtschaftliche Mehrwert für das Unternehmen im Vordergrund. Somit sind privatrechtliche Unternehmen naturgemäß eher auf den individuellen IVS-Nutzen von solchen Kunden ausgerichtet, die letztendlich bereit sind, für den IVS-Dienst direkt oder indierekt zu bezahlen.&lt;br /&gt;
&lt;br /&gt;
*für '''steuerfinanzierte Institutionen des öffentlichen Rechts''' steht bei der Zielformulierung die Umsetzung politischer Vorgaben und genereller gesellschaftpolitischer Ziele (Daseinsvorsorge) und der mit einem IVS-Dienst verbundene Mehrwert für ein End-Nutzer-Kollektiv im Vordergrund. Naturgemäß sind Institutionen des öffentlichen Rechts auf den kollektiven Nutzen der &amp;quot;Kunden&amp;quot; ausgerichtet, die Steuern zahlen. &lt;br /&gt;
&lt;br /&gt;
Um privat-und steuerfinanzierten Nutzen von IVS-Diensten zu unterscheiden werden die Begriffe '''IVS-Nutzen (privatfinanziert)''' und '''IVS-Wirkung (steuerfinanziert)''' verwendet. IVS-Nutzen und IVS-Wirkung können als rein '''Qualitative IVS-Ziele''' (BMM = Goals) formuliert werden und/oder als '''Quantitative IVS-Ziele''' (BMM = Objectives) quantitativ messbar sein.  &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für Qualitative und Quantitative IVS-Ziele''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! Qualitative IVS-Ziele (Goals)!! Quantitative IVS-Ziele (Objectives)&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung von Auffahrunfällen&lt;br /&gt;
*Reduzierung von Unfällen in Baustellen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung der Unfallhäufigkeit in Folge von Staus um X% &lt;br /&gt;
*Reduzierung der Unfälle mit LKW um X%&lt;br /&gt;
*Reduzierung von Folgeunfällen bei Stau um X%&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung des Energieverbrauchs&lt;br /&gt;
*Reduzierung der Schadstoffemissionen&lt;br /&gt;
*Reduzierung der Lärmbelastungen&lt;br /&gt;
|&lt;br /&gt;
*Kraftstoffverbrauch um X% reduzieren&lt;br /&gt;
*CO2-Ausstoß um X% reduzieren &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
*Kontinuierliche Verbesserung des Modal Split von Pendlern&lt;br /&gt;
|&lt;br /&gt;
*Verbesserung der Nutzerfreundlichkeit bei der Anfrage von Reisealternativen der multimodalen Reiseplanung&lt;br /&gt;
*Aufklärung und Information der Reisenden&lt;br /&gt;
|&lt;br /&gt;
*Verkürzen der Latenzeit von der Reiseanfrage bis zur Präsentation der Reiseroute auf &amp;lt; 5 Sekunden&lt;br /&gt;
*10 % der bisherigen PKW-Fahrer steigen auf ÖPNV um&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Da IVS-Dienste in der Regel nur durch die Kooperation und Zusammenarbeit ganz unterschiedlicher IVS-Akteure entstehen, müssen sich diese sich letzendlich auf gemeinsame Ziele verständigen ('''Zwang zum Konsens''').&lt;br /&gt;
&lt;br /&gt;
== Das Means-Konzept (das (Hilfs-)Mittel-Konzept) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
&lt;br /&gt;
Ein (Hilfs-)Mittel repäsentiert jede Art von spezieller Fähigkeit, System, Technologie, Regelwerk, Instrument oder Methode etc., die in Anspruch genommen, aktiviert oder verstärkt werden kann, um Ziele (Ends) zu erreichen. Hilfs-(Mittel) sagen jedoch weder etwas aus über Schritte (Geschäftsprozesse und -abläufe), die notwendig sind um sie zu nutzen, noch über Verantwortlichkeiten für solche Aufgaben, sondern lediglich über die Fähigkeiten, die mit den (Hilfs-)mitteln verbunden sind un die einsetzbar sind, um die gewünschten Ergebnisse (Ends) zu erzielen.&lt;br /&gt;
&lt;br /&gt;
Wenn man (Hilfs-)Mittel beschreibt, ist es auch nützlich zu dokumentieren, wer das (Hilfs-)Mittel zu welchem Zeitpunkt einsetzt, sodass für die Zukunft als Referenz ein Prüfpfad exisitiert.&lt;br /&gt;
&lt;br /&gt;
===Hilfs-(Mittel)-Kategorien ===&lt;br /&gt;
[[Datei: Means-Konzept.png | thumb | 300 px | right | Übersichtsdarstellung über das Means-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie im nebenstehenden UML-Diagramm sichtbar lässt sich das (Hilfs-)Mittel-Konzept als  Hierarchie darstellen und begreifen. &lt;br /&gt;
&lt;br /&gt;
Insofern können (Hilfs-)Mittel sein:&lt;br /&gt;
*eine '''Mission''' (Handlungsoption, Aktion, Auftrag)&lt;br /&gt;
*:Eine '''Mission''' oder auch '''Handlungsoption''' bezeichnet, wie ihr Gegenstück '''Vision''', einen Langzeit-Ansatz, der auf die Erfüllung der Vision fokussiert ist. Wie die Vision ist die Mission nicht sehr spezifisch formuliert. Die Entscheidung für eine Handlungsoption sollte sich danach richten, wie Ressourcen, Fähigkeiten, Fertigkeiten und Kompetenzen, auf die eine Unternehmen/eine Organisation zurückgreifen kann, am besten genutzt werden können, um die formulierten Ziele auch tatsächlich zu erreichen.&lt;br /&gt;
*ein '''Handlungsmuster''' (strategisch oder taktisch)&lt;br /&gt;
*:In gewisser Weise, sind '''Handlungsmuster''' von grundsätzlicher Natur. Sie sind jedoch stumpfe Instrumente, wenn sie nicht durch entsprechende Direktiven gestützt werden, um eine reale Chance zu haben, erfolgreich zu sein.  &lt;br /&gt;
*eine '''Direktive''' (Geschäftspolitik, Geschäftsregel)  &lt;br /&gt;
*:Im Gegensatz zu Handlungsmustern, können '''Direktiven (Vorschriften und Richtlinien)''' nicht für sich alleine stehen. Vielmehr geben sie den Handlungsmustern den richtigen Schliff. Mit anderen Worten stellen sie sicher, dass Handlungsmuster in intelligenter Weise innerhalb von Grenzen angewendet werden, die für ein Unternehmen/eine Unternehmung akzeptabel bzw. optimal sind. Kurz formuliert, Direktiven repräsentieren das verschlüsselte (z.B. in schriftlicher Form dokumentierte) Wissen, das einem Handlungsmuster die Chance auf den höchstmöglichen Erfolg eröffnet. &lt;br /&gt;
*:Eine Direktive hat auch etwas zu tun mit Führung und Lenkung. Im Gegensatz dazu identifiziert ein Handlungsmuster den aktiven Ansatz auf dem Weg hin zu den Ends. Ein Handlungsmuster ist immer aktionsorientiert.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Means-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Missionen/IVS-Handlungsoptionen (BMM = Missions) ====&lt;br /&gt;
IVS-Missionen sind '''IVS-Handlungsoptionen''', die zum Ausdruck bringen, auf welche '''Art von IVS-Diensten in welcher Kombination''' man grundsätzlich zurückgreifen kann bzw. welche Art von IVS-Diensten in welcher Kombination am besten geignet sind, um der mit der Vision formulierten Zielvorstellung näher zu kommen. Die Entscheidung für eine Art von IVS-Diensten bzw. Kombination von Diensten und ihre spezifische Ausgestaltung sollte sich danach richten, wie '''ganz aktuell z.b. finanzielle und personelle Ressourcen sowie Fähigkeiten, Fertigkeiten, Kompetenzen und Technologien am besten eingesetzt werden''', um die formulierten Ziele zu erreichen. IVS-Handlungsoptionen müssen jedoch einen als '''realistisch erachteten Zeithorizont''' haben. So sollten z.B. IVS-Dienste, die im betrachteten Zeitraum noch nicht die erforderliche Technologiereife erreicht haben, nicht als IVS-Handlungsoption in Erwägung gezogen werden.&lt;br /&gt;
&lt;br /&gt;
Beispiele für IVS-Handlungsoptionen zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! IVS-Handlungsoption (Mission)  &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport&lt;br /&gt;
|Einsatz von Kooperativen IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport&lt;br /&gt;
|&lt;br /&gt;
*Einsatz von energieverbrauchsdämpfenden IVS-Diensten (ITS und C-ITS)&lt;br /&gt;
*Vermehrtes Feinstaubmanagement &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (jederzeit, an jedem Ort)&lt;br /&gt;
|Einsatz von in Realzeit arbeitenden multimodalen IVS-Informationsdiensten &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Handlungsmuster (BMM = Course of action) ==== &lt;br /&gt;
'''IVS-Handlungsmuster''' geben vor, '''wie bei man bei der Wahl einer IVS-Mission/IVS-Handlungsoption am besten vorgeht'''. IVS-Handlungsmuster definieren '''was zu tun ist''', aber '''nicht wie gut etwas zu tun''' ist. IVS-Performance-Kriterien werden mit den Zielen formuliert, die durch Handlungsmuster unterstützt werden. IVS-Handlungsmuster zielen nicht immer unmittelbar auf die Erreichung von Ergebnissen. Manche sind sinnvoll, um andere IVS-Handlungsmuster zu ermöglichen. &lt;br /&gt;
&lt;br /&gt;
IVS-Handlungsmuster werden unterschieden nach: &lt;br /&gt;
*'''IVS-Strategien...'''&lt;br /&gt;
**sind eher '''langzeitorientiert''' und '''breit''' angelegt. &lt;br /&gt;
**sind als Merkmale, die strategische Einflussfaktoren und Rahmenbedingungen repräsentieren, '''wesentlich für den Erfolg eines IVS-Handlungsmusters'''. &lt;br /&gt;
**legen für IVS-Handlungsmuster beste Vorgehensweisen, widerspruchsfreie Verhaltensmuster, Positionierungen und Sichtweisen der IVS-Aktueure bei der Modellierung, Planung, Realisierung und dem Betrieb von Intelligenten Verkehrssystemen fest.&lt;br /&gt;
**sind Schlüsselfaktoren, die oftmals über '''Erfolg oder Misserfolg von IVS-Diensten''' entscheiden. Zu den strategischen Merkmalen gehören insbesondere Finanzierungskonzepte, aber oft auch zu schaffende rechtliche Rahmenbedingungen und technologische Voraussetzungen. Diese müssen frühzeitig identifiziert und realisiert werden, um von Vornherein die Machbarkeit von IVS-Diensten sicherzustellen.&lt;br /&gt;
 &lt;br /&gt;
*'''IVS-Taktiken...'''&lt;br /&gt;
**sind eher '''auf kurze Sicht angelegt. &lt;br /&gt;
**werden gewählt, um die gewünschten '''Ergebnisse auch bestmöglich sicherzustellen'''&lt;br /&gt;
**können zur Implementierung mehrerer IVS-Strategien beitragen.&lt;br /&gt;
&lt;br /&gt;
So wie IVS-Handlungsmuster mit den gewünschten Ergebnissen (IVS-Nutzen, IVS-Wirkung) eines IVS-Dienstes korrespondieren, sind '''IVS-Strategien''' auf die '''generelle Zielsetzung''' ausgerichtet. IVS-Taktiken werden hingegen gewählt, um die '''gewünschten Ergebnisse''' auch bestmöglich '''sicherzustellen''' (wobei dieser Zusammenhang nicht zwangsweise gilt). &lt;br /&gt;
'''IVS-Strategien und IVS-Taktiken sind nicht scharf voneinander getrennt'''. Im Einzelfall muss jeder für sich entscheiden, nach welchen Kriterien er beide definiert.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Handlungsmuster''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
! rowspan=&amp;quot;2&amp;quot; | IVS-Zielfeld !! rowspan=&amp;quot;2&amp;quot; | IVS-Handlungsoption (Mission) !! colspan=&amp;quot;2&amp;quot; |IVS-Handlungsmuster &lt;br /&gt;
|+&lt;br /&gt;
! !! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Implementierung von IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellen-Slotmanagement&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von energieverbrauchsfreundlichen IVS-Diensten&lt;br /&gt;
*Einrichtung von (dynamischen) Umweltzonen (bei Feststellung erhöhter Werte werden Maßnahmen wie Fahrverbote o.ä. ergriffen) &lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten &lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation &lt;br /&gt;
|&lt;br /&gt;
*Angebot von Push-Diensten&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Richtlinen (IVS-Politik und IVS-Regeln) (BMM = Directives) ====&lt;br /&gt;
&lt;br /&gt;
'''IVS-Richtlinien geben den IVS-Handlungsmustern sozusagen &amp;quot;die richtige Richtung&amp;quot;'''. Sie führen und lenken die Ausführung der IVS-Handlungsmuster nach politischen Vorgaben und anerkannten Regeln.&lt;br /&gt;
&lt;br /&gt;
*Auf der einen Seite ist mit IVS-Richtlinien '''Einschränkung''' verbunden. Durch Vorgabe von IVS-Richtlinien soll sichergestellt werden, dass IVS-Handlungsmuster - möglichst in intelligenter Weise - '''innerhalb vorgegebener Grenzen''' angewendet werden.&lt;br /&gt;
&lt;br /&gt;
*Auf der anderen Seite repräsentieren IVS-Richtlinien das verschlüsselte, in der Regel in schriftlicher Form '''dokumentierte Wissen''', das einem '''Handlungsmuster die Chance auf den höchstmöglichen Erfolg''' eröffnet.&lt;br /&gt;
 &lt;br /&gt;
IVS-Richtlinien werden kategorisiert nach:&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Politik(-richtlinien''')&lt;br /&gt;
**Grundsätzlich ist es Aufgabe der (IVS)-Politik zu '''regulieren''', d.h. die Anwendung von IVS in Form politischer (auch gesetzlicher) Vorgaben zu regeln oder-  mit anderen Worten ausgedrückt - '''zu steuern und zu führen''' und damit die angewandten IVS-Strategien und IVS-Taktiken zu gestalten.&lt;br /&gt;
**IVS-Politik legt fest, '''was getan werden darf, aber auch was getan werden muss''', und gibt an, wie oder '''in welchen Grenzen''' etwas getan werden kann.&lt;br /&gt;
** Im Vergleich zu IVS-Regeln ist '''IVS-Politik weniger strukturiert''' und auch weniger detailliert formuliert. '''IVS-Politik''' ist in diesem Sinne auch '''nicht direkt &amp;quot;ausführbar&amp;quot;'''.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Regeln (auch IVS-Prinzipien)'''&lt;br /&gt;
**IVS-Regeln leiten sich von der IVS-Politik ab und sind '''ausführbare IVS-Richtlinien'''. &lt;br /&gt;
**Sie müssen auch als solche definiert sein und aus Konsistenz- und Vollständigkeitsgründen muss '''ihre Ausführung überwacht und überprüft''' werden. &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Richtlinien''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!! rowspan=&amp;quot;2&amp;quot; |IVS- Zielfeld !! colspan=&amp;quot;2&amp;quot; | IVS-Handlungsmuster (Course of actions) !! colspan=&amp;quot;2&amp;quot; | (IVS-Richtlinien) Directive&lt;br /&gt;
|+&lt;br /&gt;
! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) !! IVS-Politik (Business Policy) !! IVS-Regeln  und IVS-Prinzipien (Business Rules)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellenmanagment&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
*Verstärtker Einsatz von Grüne-Welle Assistenten auf lichtsignalgereglten Strecken  &lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
*Implementation von Grüne-Welle Assistenten ab einer einer Morgenspitze &amp;gt; X Kfz/h   &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation&lt;br /&gt;
|&lt;br /&gt;
*Open-Data Initiative &lt;br /&gt;
|&lt;br /&gt;
*Schnittstellen grundsätzlich als DATEX II-Profile&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7461</id>
		<title>IVS-Geschäftsziele</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7461"/>
		<updated>2016-10-12T08:08:33Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Einführung */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Einführung ==&lt;br /&gt;
&lt;br /&gt;
[[Datei: Business-Motivation-Model-top.png | thumb | 300 px | right | Übersichtsdarstellung des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
[[Datei: BMM.png | thumb | 300 px | right | Bestandteile des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
Um die Diskussion über die Formulierung von '''Ziel- und Realisierungsvorstellungen für IVS-Dienste''' von vorneherein auf eine methodisch konsistente und für jeden nachvollziehbare Basis zu stellen, wird im folgenden auf das&lt;br /&gt;
[[Media: Formal-15-05-20.pdf | '''Business Motivation Model''']] (BMM, Version 1.3) der [https://en.wikipedia.org/wiki/Business_Motivation_Model ''' OMG - Open Managment Group'''] zurückgegriffen.&lt;br /&gt;
&lt;br /&gt;
Das BMM-Business Motivation Modell (siehe nebenstehende Abbildung) beleuchtet die '''Anforderungen an das Business (Geschäft)''' eines Unternehmens/einer Organisation auf verschiedenen Ebenen, um gründlich und präzise zu erfassen und zu begründen:&lt;br /&gt;
*'''warum''' ein Unternehmen/eine Organisation '''handeln''' will (oder soll), &lt;br /&gt;
*worauf das Handeln abzielt und '''was am Ende erreicht werden soll''',&lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation plant, '''dorthin zu kommen''' und &lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation die erreichten '''Ergebnisse bewertet'''.&lt;br /&gt;
&lt;br /&gt;
Für die Beschreibung des &amp;quot;Business&amp;quot; definiert und verwendet das BMM verschiedene &lt;br /&gt;
Elemente (semantische Konzepte), die zueinander in Beziehung gesetzt werden. &lt;br /&gt;
Die wichtigsten Elemente sind:&lt;br /&gt;
*'''Ends''': ''Was'' (im Gegensatz zu ''Wie'') das Unternehmen/die Organisation - am Ende - erreichen möchte.&lt;br /&gt;
*'''Means''': ''Wie'' - mit welchen (Hilfs-)Mitteln - das Unternehmen/die Organisation beabsichtigt, seine ''Ends'' zu erreichen. &lt;br /&gt;
*'''Directives''': Die ''Regeln und Grundsätze'', die die verfügbaren Means einschränken bzw. regulieren. &lt;br /&gt;
*'''Influencers''': ''Einflussfaktoren'', die Änderungen erforderlich machen, während ein Unternehmen/eine Organisation mit den Means oder der Erreichung der Ends befasst ist. Influencers sind per Definition neutral.&lt;br /&gt;
*'''Assessment''': Eine ''Beurteilung'' eines Influencers, der die Fähigkeit eines Unternehmens bei der Erreichung seiner Ends oder Anwendung seiner Means beeinflusst.&lt;br /&gt;
&lt;br /&gt;
== Das Ends-Konzept (Formulierung von Zielvorstellungen) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
Im Kontext der Ziele-Diskussion für IVS-Dienste ist zunächst das '''Ends'''-Konzept von Bedeutung. Ends beschreiben, was ein Business (am Ende) sein will bzw. '''wo ein Business (am Ende) stehen will'''. Ends selber geben keine Auskunft darüber, wie sie erreicht werden sollen. Wenn wir den Business-Begriff auf den IVS-Dienst übertragen, d.h. '''wenn wir einen IVS-Dienst als Business begreifen und interpretieren''', hilft das Ends-Konzept, Ziele auf ihre Bedeutung hin sematisch zu differenzieren.&lt;br /&gt;
&lt;br /&gt;
=== Ends-Kategorien ===&lt;br /&gt;
&lt;br /&gt;
[[Datei: Ends-Konzept.png | thumb | 300 px | right | Ends-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie nebenstehndes UML-Diagramm zeigt, sind Ends kategorisiert als '''Vision''' and '''Desired Results'''. Desired Results als '''Goals''' und '''Objectives'''.&lt;br /&gt;
&lt;br /&gt;
*Eine '''Vision''' ist eine generelles Bild dafür, was ein Business zukünftig sein oder werden möchte. '''Hinweis''': das Business Motivation Model kann eingesetzt werden, auch wenn eine Vision nicht explizit festgelegt wurde&lt;br /&gt;
*'''Desired Results (dts: gewünschte Ergebnisse)''', differenziert als '''Goals (dts: generelle Zielsetzung/Oberziel/Zweck)''' und '''Objectives (dts: messbare Einzelziele)''', sind spezifischer als Visionen: &lt;br /&gt;
**Ein '''Goal (dts: qualitatives Ziel)''' ist vom Wesen her eher langfristig ausgerichtet und eher qualitativ als quantitativ festgelegt. Es sollte jedoch gerade noch so zukunftsnah sein, dass dafür messbare Einzelziele definiert werden können.&lt;br /&gt;
**Ein '''Objective (dts: quantitatives Ziel)''' ist ein Schritt auf dem Weg hin zum generellen Ziel. Es quantifiziert ein stückweit das generelle Ziel. Es muss mit einem End-Datum verknüpft sein und es müssen Kriterien festgelegt sein, um darüber feststellen zu können, ob es erreicht wurde oder nicht. Messbare Einzelziele bilden die messbare Grundlage dafür, ob ein Forschritt in Richtung der Erfüllung der generellen Zielsetzung erreicht wurde.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Ends-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Visionen (BMM = Visions) ====&lt;br /&gt;
Jedes Unternehmen/jede Organisation hat natürliche Visionen, wo die Reise hingehen soll, wo man z.B. in 10 Jahren stehen will. Visionen sind aber '''oft nicht oder nur unscharf formuliert''' und treten in der Realität des Alltags oft in den Hintergrund. Für IVS allerdings haben Visionen eine große Bedeutung, weil IVS und IVS-Dienste im '''Kontext politischer und gesellschaftlicher Diskussionen über Verkehr, Transport und Mobilität einen große Rolle''' spielen.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Visionen''' für unterschiedliche IVS-Zielfelder zeigt folgende Tabelle:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== Ergebnisse (Nutzen und Wirkung) von IVS-Diensten (BMM  = Desired results)====  &lt;br /&gt;
Mit einem IVS-Dienst werden nicht nur Visionen sondern '''stets auch konkrete Ziele''' verfolgt. Für das Engagement von IVS-Akteuren und IVS-Stakeholdern soll sich ein bestimmter '''Gegenwert in Form eines Ergebnisses (IVS-Nutzen/IVS-Wirkung)''' einstellen.&lt;br /&gt;
 &lt;br /&gt;
Grundsätzlich ist natürlich für jeden IVS-Dienst '''das große Ganze''', also der IVS-Nutzen und den damit verbundenen  Mehrwert für den späteren IVS-End-Nutzer '''im Fokus zu behalten''' und gemeinsam daraufhin zu arbeiten. IVS-Nutzen entsteht, wenn IVS-End-Nutzer oder IVS-End-Nutzerkollektive Zugriff auf IVS-Informationen haben, um eigene IVS-Entscheidungen sicher, zuverlässing, schnell und effektiv treffen zu können.&lt;br /&gt;
 &lt;br /&gt;
In Abhängigkeit der '''rechtlichen Ausgangssituation von IVS-Akteuren oder Stakeholdern''' (privat oder öffentlich rechtlich) werden generelle IVS-Zielsetzungen in der Regel ganz '''unterschiedlich und ggfs. auch konfliktär formuliert und interpretiert'''.&lt;br /&gt;
&lt;br /&gt;
*für '''privatwirtschafliche finanzierte Unternehmen''' steht bei der Zielformulierung der eigene Business Case und der mit einem IVS-Dienst oder der Komformität zu einer IVS-Architekturvorgabe verbundene wirtschaftliche Mehrwert für das Unternehmen im Vordergrund. Somit sind privatrechtliche Unternehmen naturgemäß eher auf den individuellen IVS-Nutzen von solchen Kunden ausgerichtet, die letztendlich bereit sind, für den IVS-Dienst direkt oder indierekt zu bezahlen.&lt;br /&gt;
&lt;br /&gt;
*für '''steuerfinanzierte Institutionen des öffentlichen Rechts''' steht bei der Zielformulierung die Umsetzung politischer Vorgaben und genereller gesellschaftpolitischer Ziele (Daseinsvorsorge) und der mit einem IVS-Dienst verbundene Mehrwert für ein End-Nutzer-Kollektiv im Vordergrund. Naturgemäß sind Institutionen des öffentlichen Rechts auf den kollektiven Nutzen der &amp;quot;Kunden&amp;quot; ausgerichtet, die Steuern zahlen. &lt;br /&gt;
&lt;br /&gt;
Um privat-und steuerfinanzierten Nutzen von IVS-Diensten zu unterscheiden werden die Begriffe '''IVS-Nutzen (privatfinanziert)''' und '''IVS-Wirkung (steuerfinanziert)''' verwendet. IVS-Nutzen und IVS-Wirkung können als rein '''Qualitative IVS-Ziele''' (BMM = Goals) formuliert werden und/oder als '''Quantitative IVS-Ziele''' (BMM = Objectives) quantitativ messbar sein.  &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für Qualitative und Quantitative IVS-Ziele''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! Qualitative IVS-Ziele (Goals)!! Quantitative IVS-Ziele (Objectives)&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung von Auffahrunfällen&lt;br /&gt;
*Reduzierung von Unfällen in Baustellen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung der Unfallhäufigkeit in Folge von Staus um X% &lt;br /&gt;
*Reduzierung der Unfälle mit LKW um X%&lt;br /&gt;
*Reduzierung von Folgeunfällen bei Stau um X%&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung des Energieverbrauchs&lt;br /&gt;
*Reduzierung der Schadstoffemissionen&lt;br /&gt;
*Reduzierung der Lärmbelastungen&lt;br /&gt;
|&lt;br /&gt;
*Kraftstoffverbrauch um X% reduzieren&lt;br /&gt;
*CO2-Ausstoß um X% reduzieren &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
*Kontinuierliche Verbesserung des Modal Split von Pendlern&lt;br /&gt;
|&lt;br /&gt;
*Verbesserung der Nutzerfreundlichkeit bei der Anfrage von Reisealternativen der multimodalen Reiseplanung&lt;br /&gt;
*Aufklärung und Information der Reisenden&lt;br /&gt;
|&lt;br /&gt;
*Verkürzen der Latenzeit von der Reiseanfrage bis zur Präsentation der Reiseroute auf &amp;lt; 5 Sekunden&lt;br /&gt;
*10 % der bisherigen PKW-Fahrer steigen auf ÖPNV um&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Da IVS-Dienste in der Regel nur durch die Kooperation und Zusammenarbeit ganz unterschiedlicher IVS-Akteure entstehen, müssen sich diese sich letzendlich auf gemeinsame Ziele verständigen ('''Zwang zum Konsens''').&lt;br /&gt;
&lt;br /&gt;
== Das Means-Konzept (das (Hilfs-)Mittel-Konzept) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
&lt;br /&gt;
Ein (Hilfs-)Mittel repäsentiert jede Art von spezieller Fähigkeit, System, Technologie, Regelwerk, Instrument oder Methode etc., die in Anspruch genommen, aktiviert oder verstärkt werden kann, um Ziele (Ends) zu erreichen. Hilfs-(Mittel) sagen jedoch weder etwas aus über Schritte (Geschäftsprozesse und -abläufe), die notwendig sind um sie zu nutzen, noch über Verantwortlichkeiten für solche Aufgaben, sondern lediglich über die Fähigkeiten, die mit den (Hilfs-)mitteln verbunden sind un die einsetzbar sind, um die gewünschten Ergebnisse (Ends) zu erzielen.&lt;br /&gt;
&lt;br /&gt;
Wenn man (Hilfs-)Mittel beschreibt, ist es auch nützlich zu dokumentieren, wer das (Hilfs-)Mittel zu welchem Zeitpunkt einsetzt, sodass für die Zukunft als Referenz ein Prüfpfad exisitiert.&lt;br /&gt;
&lt;br /&gt;
===Hilfs-(Mittel)-Kategorien ===&lt;br /&gt;
[[Datei: Means-Konzept.png | thumb | 300 px | right | Übersichtsdarstellung über das Means-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie im nebenstehenden UML-Diagramm sichtbar lässt sich das (Hilfs-)Mittel-Konzept als  Hierarchie darstellen und begreifen. &lt;br /&gt;
&lt;br /&gt;
Insofern können (Hilfs-)Mittel sein:&lt;br /&gt;
*eine '''Mission''' (Handlungsoption, Aktion, Auftrag)&lt;br /&gt;
*:Eine '''Mission''' oder auch '''Handlungsoption''' bezeichnet, wie ihr Gegenstück '''Vision''', einen Langzeit-Ansatz, der auf die Erfüllung der Vision fokussiert ist. Wie die Vision ist die Mission nicht sehr spezifisch formuliert. Die Entscheidung für eine Handlungsoption sollte sich danach richten, wie Ressourcen, Fähigkeiten, Fertigkeiten und Kompetenzen, auf die eine Unternehmen/eine Organisation zurückgreifen kann, am besten genutzt werden können, um die formulierten Ziele auch tatsächlich zu erreichen.&lt;br /&gt;
*ein '''Handlungsmuster''' (strategisch oder taktisch)&lt;br /&gt;
*:In gewisser Weise, sind '''Handlungsmuster''' von grundsätzlicher Natur. Sie sind jedoch stumpfe Instrumente, wenn sie nicht durch entsprechende Direktiven gestützt werden, um eine reale Chance zu haben, erfolgreich zu sein.  &lt;br /&gt;
*eine '''Direktive''' (Geschäftspolitik, Geschäftsregel)  &lt;br /&gt;
*:Im Gegensatz zu Handlungsmustern, können '''Direktiven (Vorschriften und Richtlinien)''' nicht für sich alleine stehen. Vielmehr geben sie den Handlungsmustern den richtigen Schliff. Mit anderen Worten stellen sie sicher, dass Handlungsmuster in intelligenter Weise innerhalb von Grenzen angewendet werden, die für ein Unternehmen/eine Unternehmung akzeptabel bzw. optimal sind. Kurz formuliert, Direktiven repräsentieren das verschlüsselte (z.B. in schriftlicher Form dokumentierte) Wissen, das einem Handlungsmuster die Chance auf den höchstmöglichen Erfolg eröffnet. &lt;br /&gt;
*:Eine Direktive hat auch etwas zu tun mit Führung und Lenkung. Im Gegensatz dazu identifiziert ein Handlungsmuster den aktiven Ansatz auf dem Weg hin zu den Ends. Ein Handlungsmuster ist immer aktionsorientiert.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Means-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Missionen/IVS-Handlungsoptionen (BMM = Missions) ====&lt;br /&gt;
IVS-Missionen sind '''IVS-Handlungsoptionen''', die zum Ausdruck bringen, auf welche '''Art von IVS-Diensten in welcher Kombination''' man grundsätzlich zurückgreifen kann bzw. welche Art von IVS-Diensten in welcher Kombination am besten geignet sind, um der mit der Vision formulierten Zielvorstellung näher zu kommen. Die Entscheidung für eine Art von IVS-Diensten bzw. Kombination von Diensten und ihre spezifische Ausgestaltung sollte sich danach richten, wie '''ganz aktuell z.b. finanzielle und personelle Ressourcen sowie Fähigkeiten, Fertigkeiten, Kompetenzen und Technologien am besten eingesetzt werden''', um die formulierten Ziele zu erreichen. IVS-Handlungsoptionen müssen jedoch einen als '''realistisch erachteten Zeithorizont''' haben. So sollten z.B. IVS-Dienste, die im betrachteten Zeitraum noch nicht die erforderliche Technologiereife erreicht haben, nicht als IVS-Handlungsoption in Erwägung gezogen werden.&lt;br /&gt;
&lt;br /&gt;
Beispiele für IVS-Handlungsoptionen zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! IVS-Handlungsoption (Mission)  &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport&lt;br /&gt;
|Einsatz von Kooperativen IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport&lt;br /&gt;
|&lt;br /&gt;
*Einsatz von energieverbrauchsdämpfenden IVS-Diensten (ITS und C-ITS)&lt;br /&gt;
*Vermehrtes Feinstaubmanagement &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (jederzeit, an jedem Ort)&lt;br /&gt;
|Einsatz von in Realzeit arbeitenden multimodalen IVS-Informationsdiensten &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Handlungsmuster (BMM = Course of action) ==== &lt;br /&gt;
'''IVS-Handlungsmuster''' geben vor, '''wie bei man bei der Wahl einer IVS-Mission/IVS-Handlungsoption am besten vorgeht'''. IVS-Handlungsmuster definieren '''was zu tun ist''', aber '''nicht wie gut etwas zu tun''' ist. IVS-Performance-Kriterien werden mit den Zielen formuliert, die durch Handlungsmuster unterstützt werden. IVS-Handlungsmuster zielen nicht immer unmittelbar auf die Erreichung von Ergebnissen. Manche sind sinnvoll, um andere IVS-Handlungsmuster zu ermöglichen. &lt;br /&gt;
&lt;br /&gt;
IVS-Handlungsmuster werden unterschieden nach: &lt;br /&gt;
*'''IVS-Strategien...'''&lt;br /&gt;
**sind eher '''langzeitorientiert''' und '''breit''' angelegt. &lt;br /&gt;
**sind als Merkmale, die strategische Einflussfaktoren und Rahmenbedingungen repräsentieren, '''wesentlich für den Erfolg eines IVS-Handlungsmusters'''. &lt;br /&gt;
**legen für IVS-Handlungsmuster beste Vorgehensweisen, widerspruchsfreie Verhaltensmuster, Positionierungen und Sichtweisen der IVS-Aktueure bei der Modellierung, Planung, Realisierung und dem Betrieb von Intelligenten Verkehrssystemen fest.&lt;br /&gt;
**sind Schlüsselfaktoren, die oftmals über '''Erfolg oder Misserfolg von IVS-Diensten''' entscheiden. Zu den strategischen Merkmalen gehören insbesondere Finanzierungskonzepte, aber oft auch zu schaffende rechtliche Rahmenbedingungen und technologische Voraussetzungen. Diese müssen frühzeitig identifiziert und realisiert werden, um von Vornherein die Machbarkeit von IVS-Diensten sicherzustellen.&lt;br /&gt;
 &lt;br /&gt;
*'''IVS-Taktiken...'''&lt;br /&gt;
**sind eher '''auf kurze Sicht angelegt. &lt;br /&gt;
**werden gewählt, um die gewünschten '''Ergebnisse auch bestmöglich sicherzustellen'''&lt;br /&gt;
**können zur Implementierung mehrerer IVS-Strategien beitragen.&lt;br /&gt;
&lt;br /&gt;
So wie IVS-Handlungsmuster mit den gewünschten Ergebnissen (IVS-Nutzen, IVS-Wirkung) eines IVS-Dienstes korrespondieren, sind '''IVS-Strategien''' auf die '''generelle Zielsetzung''' ausgerichtet. IVS-Taktiken werden hingegen gewählt, um die '''gewünschten Ergebnisse''' auch bestmöglich '''sicherzustellen''' (wobei dieser Zusammenhang nicht zwangsweise gilt). &lt;br /&gt;
'''IVS-Strategien und IVS-Taktiken sind nicht scharf voneinander getrennt'''. Im Einzelfall muss jeder für sich entscheiden, nach welchen Kriterien er beide definiert.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Handlungsmuster''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
! rowspan=&amp;quot;2&amp;quot; | IVS-Zielfeld !! rowspan=&amp;quot;2&amp;quot; | IVS-Handlungsoption (Mission) !! colspan=&amp;quot;2&amp;quot; |IVS-Handlungsmuster &lt;br /&gt;
|+&lt;br /&gt;
! !! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Implementierung von IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellen-Slotmanagement&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von energieverbrauchsfreundlichen IVS-Diensten&lt;br /&gt;
*Einrichtung von (dynamischen) Umweltzonen (bei Feststellung erhöhter Werte werden Maßnahmen wie Fahrverbote o.ä. ergriffen) &lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten &lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation &lt;br /&gt;
|&lt;br /&gt;
*Angebot von Push-Diensten&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Richtlinen (IVS-Politik und IVS-Regeln) (BMM = Directives) ====&lt;br /&gt;
&lt;br /&gt;
'''IVS-Richtlinien geben den IVS-Handlungsmustern sozusagen &amp;quot;die richtige Richtung&amp;quot;'''. Sie führen und lenken die Ausführung der IVS-Handlungsmuster nach politischen Vorgaben und anerkannten Regeln.&lt;br /&gt;
&lt;br /&gt;
*Auf der einen Seite ist mit IVS-Richtlinien '''Einschränkung''' verbunden. Durch Vorgabe von IVS-Richtlinien soll sichergestellt werden, dass IVS-Handlungsmuster - möglichst in intelligenter Weise - '''innerhalb vorgegebener Grenzen''' angewendet werden.&lt;br /&gt;
&lt;br /&gt;
*Auf der anderen Seite repräsentieren IVS-Richtlinien das verschlüsselte, in der Regel in schriftlicher Form '''dokumentierte Wissen''', das einem '''Handlungsmuster die Chance auf den höchstmöglichen Erfolg''' eröffnet.&lt;br /&gt;
 &lt;br /&gt;
IVS-Richtlinien werden kategorisiert nach:&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Politik(-richtlinien''')&lt;br /&gt;
**Grundsätzlich ist es Aufgabe der (IVS)-Politik zu '''regulieren''', d.h. die Anwendung von IVS in Form politischer (auch gesetzlicher) Vorgaben zu regeln oder-  mit anderen Worten ausgedrückt - '''zu steuern und zu führen''' und damit die angewandten IVS-Strategien und IVS-Taktiken zu gestalten.&lt;br /&gt;
**IVS-Politik legt fest, '''was getan werden darf, aber auch was getan werden muss''', und gibt an, wie oder '''in welchen Grenzen''' etwas getan werden kann.&lt;br /&gt;
** Im Vergleich zu IVS-Regeln ist '''IVS-Politik weniger strukturiert''' und auch weniger detailliert formuliert. '''IVS-Politik''' ist in diesem Sinne auch '''nicht direkt &amp;quot;ausführbar&amp;quot;'''.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Regeln (auch IVS-Prinzipien)'''&lt;br /&gt;
**IVS-Regeln leiten sich von der IVS-Politik ab und sind '''ausführbare IVS-Richtlinien'''. &lt;br /&gt;
**Sie müssen auch als solche definiert sein und aus Konsistenz- und Vollständigkeitsgründen muss '''ihre Ausführung überwacht und überprüft''' werden. &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Richtlinien''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!! rowspan=&amp;quot;2&amp;quot; |IVS- Zielfeld !! colspan=&amp;quot;2&amp;quot; | IVS-Handlungsmuster (Course of actions) !! colspan=&amp;quot;2&amp;quot; | (IVS-Richtlinien) Directive&lt;br /&gt;
|+&lt;br /&gt;
! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) !! IVS-Politik (Business Policy) !! IVS-Regeln  und IVS-Prinzipien (Business Rules)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellenmanagment&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
*Verstärtker Einsatz von Grüne-Welle Assistenten auf lichtsignalgereglten Strecken  &lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
*Implementation von Grüne-Welle Assistenten ab einer einer Morgenspitze &amp;gt; X Kfz/h   &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation&lt;br /&gt;
|&lt;br /&gt;
*Open-Data Initiative &lt;br /&gt;
|&lt;br /&gt;
*Schnittstellen grundsätzlich als DATEX II-Profile&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7460</id>
		<title>IVS-Geschäftsziele</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsziele&amp;diff=7460"/>
		<updated>2016-10-12T08:06:23Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Einführung */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Einführung ==&lt;br /&gt;
&lt;br /&gt;
[[Datei: Business-Motivation-Model-top.png | thumb | 300 px | right | Übersichtsdarstellung des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
[[Datei: BMM.png | thumb | 300 px | right | Bestandteile des BMM - Business Motivation Modells]]&lt;br /&gt;
&lt;br /&gt;
Um die Diskussion über die Formulierung von '''Ziel- und Realisierungsvorstellungen für IVS-Dienste''' von vorneherein auf eine methodisch konsistente und für jeden nachvollziehbare Basis zu stellen, wird im folgenden auf das&lt;br /&gt;
[[Media: Formal-15-05-20.pdf | '''Business Motivation Model''']] (BMM, Version 1.3) der [https://en.wikipedia.org/wiki/Business_Motivation_Model ''' OMG - Open Managment Group'''] zurückgegriffen.&lt;br /&gt;
&lt;br /&gt;
Das BMM-Business Motivation Modell (siehe nebenstehende Abbildung) beleuchtet die '''Anforderungen an das Business (Geschäft)''' eines Unternehmens/einer Organisation auf verschiedenen Ebenen, um gründlich und präzise zu erfassen und zu begründen:&lt;br /&gt;
*'''warum''' ein Unternehmen/eine Organisation '''handeln''' will (oder soll), &lt;br /&gt;
*worauf das Handeln abzielt und '''was am Ende erreicht werden soll''',&lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation plant, '''dorthin zu kommen''' und &lt;br /&gt;
*'''wie''' ein Unternehmen/eine Organisation die erreichten '''Ergebnisse bewertet'''.&lt;br /&gt;
&lt;br /&gt;
Für die Beschreibung des &amp;quot;Business&amp;quot; definiert und verwendet das BMM verschiedene &lt;br /&gt;
Elemente (semantische Konzepte), die zueinander in Beziehung gesetzt werden. &lt;br /&gt;
Die wichtigsten Elemente sind:&lt;br /&gt;
*'''Ends''': ''Was'' (im Gegensatz zu ''Wie'') das Unternehmen/die Organisation - am Ende - erreichen möchte&lt;br /&gt;
*'''Means''': ''Wie'' - mit welchen (Hilfs-)Mitteln - das Unternehmen/die Organisation beabsichtigt, seine ''Ends'' zu erreichen &lt;br /&gt;
*'''Directives''': Die ''Regeln und Grundsätze'', die die verfügbaren Means einschränken bzw. regulieren &lt;br /&gt;
*'''Influencers''': ''Einflussfaktoren'', die Änderungen erforderlich machen, während ein Unternehmen/eine Organisation mit den Means oder der Erreichung der Ends befasst ist. Influencers sind per Definition neutral.&lt;br /&gt;
*'''Assessment''': Eine ''Beurteilung'' eines Influencers, der die Fähigkeit eines Unternehmens bei der Erreichung seiner Ends oder Anwendung seiner Means beeinflusst.&lt;br /&gt;
&lt;br /&gt;
== Das Ends-Konzept (Formulierung von Zielvorstellungen) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
Im Kontext der Ziele-Diskussion für IVS-Dienste ist zunächst das '''Ends'''-Konzept von Bedeutung. Ends beschreiben, was ein Business (am Ende) sein will bzw. '''wo ein Business (am Ende) stehen will'''. Ends selber geben keine Auskunft darüber, wie sie erreicht werden sollen. Wenn wir den Business-Begriff auf den IVS-Dienst übertragen, d.h. '''wenn wir einen IVS-Dienst als Business begreifen und interpretieren''', hilft das Ends-Konzept, Ziele auf ihre Bedeutung hin sematisch zu differenzieren.&lt;br /&gt;
&lt;br /&gt;
=== Ends-Kategorien ===&lt;br /&gt;
&lt;br /&gt;
[[Datei: Ends-Konzept.png | thumb | 300 px | right | Ends-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie nebenstehndes UML-Diagramm zeigt, sind Ends kategorisiert als '''Vision''' and '''Desired Results'''. Desired Results als '''Goals''' und '''Objectives'''.&lt;br /&gt;
&lt;br /&gt;
*Eine '''Vision''' ist eine generelles Bild dafür, was ein Business zukünftig sein oder werden möchte. '''Hinweis''': das Business Motivation Model kann eingesetzt werden, auch wenn eine Vision nicht explizit festgelegt wurde&lt;br /&gt;
*'''Desired Results (dts: gewünschte Ergebnisse)''', differenziert als '''Goals (dts: generelle Zielsetzung/Oberziel/Zweck)''' und '''Objectives (dts: messbare Einzelziele)''', sind spezifischer als Visionen: &lt;br /&gt;
**Ein '''Goal (dts: qualitatives Ziel)''' ist vom Wesen her eher langfristig ausgerichtet und eher qualitativ als quantitativ festgelegt. Es sollte jedoch gerade noch so zukunftsnah sein, dass dafür messbare Einzelziele definiert werden können.&lt;br /&gt;
**Ein '''Objective (dts: quantitatives Ziel)''' ist ein Schritt auf dem Weg hin zum generellen Ziel. Es quantifiziert ein stückweit das generelle Ziel. Es muss mit einem End-Datum verknüpft sein und es müssen Kriterien festgelegt sein, um darüber feststellen zu können, ob es erreicht wurde oder nicht. Messbare Einzelziele bilden die messbare Grundlage dafür, ob ein Forschritt in Richtung der Erfüllung der generellen Zielsetzung erreicht wurde.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Ends-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Visionen (BMM = Visions) ====&lt;br /&gt;
Jedes Unternehmen/jede Organisation hat natürliche Visionen, wo die Reise hingehen soll, wo man z.B. in 10 Jahren stehen will. Visionen sind aber '''oft nicht oder nur unscharf formuliert''' und treten in der Realität des Alltags oft in den Hintergrund. Für IVS allerdings haben Visionen eine große Bedeutung, weil IVS und IVS-Dienste im '''Kontext politischer und gesellschaftlicher Diskussionen über Verkehr, Transport und Mobilität einen große Rolle''' spielen.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Visionen''' für unterschiedliche IVS-Zielfelder zeigt folgende Tabelle:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== Ergebnisse (Nutzen und Wirkung) von IVS-Diensten (BMM  = Desired results)====  &lt;br /&gt;
Mit einem IVS-Dienst werden nicht nur Visionen sondern '''stets auch konkrete Ziele''' verfolgt. Für das Engagement von IVS-Akteuren und IVS-Stakeholdern soll sich ein bestimmter '''Gegenwert in Form eines Ergebnisses (IVS-Nutzen/IVS-Wirkung)''' einstellen.&lt;br /&gt;
 &lt;br /&gt;
Grundsätzlich ist natürlich für jeden IVS-Dienst '''das große Ganze''', also der IVS-Nutzen und den damit verbundenen  Mehrwert für den späteren IVS-End-Nutzer '''im Fokus zu behalten''' und gemeinsam daraufhin zu arbeiten. IVS-Nutzen entsteht, wenn IVS-End-Nutzer oder IVS-End-Nutzerkollektive Zugriff auf IVS-Informationen haben, um eigene IVS-Entscheidungen sicher, zuverlässing, schnell und effektiv treffen zu können.&lt;br /&gt;
 &lt;br /&gt;
In Abhängigkeit der '''rechtlichen Ausgangssituation von IVS-Akteuren oder Stakeholdern''' (privat oder öffentlich rechtlich) werden generelle IVS-Zielsetzungen in der Regel ganz '''unterschiedlich und ggfs. auch konfliktär formuliert und interpretiert'''.&lt;br /&gt;
&lt;br /&gt;
*für '''privatwirtschafliche finanzierte Unternehmen''' steht bei der Zielformulierung der eigene Business Case und der mit einem IVS-Dienst oder der Komformität zu einer IVS-Architekturvorgabe verbundene wirtschaftliche Mehrwert für das Unternehmen im Vordergrund. Somit sind privatrechtliche Unternehmen naturgemäß eher auf den individuellen IVS-Nutzen von solchen Kunden ausgerichtet, die letztendlich bereit sind, für den IVS-Dienst direkt oder indierekt zu bezahlen.&lt;br /&gt;
&lt;br /&gt;
*für '''steuerfinanzierte Institutionen des öffentlichen Rechts''' steht bei der Zielformulierung die Umsetzung politischer Vorgaben und genereller gesellschaftpolitischer Ziele (Daseinsvorsorge) und der mit einem IVS-Dienst verbundene Mehrwert für ein End-Nutzer-Kollektiv im Vordergrund. Naturgemäß sind Institutionen des öffentlichen Rechts auf den kollektiven Nutzen der &amp;quot;Kunden&amp;quot; ausgerichtet, die Steuern zahlen. &lt;br /&gt;
&lt;br /&gt;
Um privat-und steuerfinanzierten Nutzen von IVS-Diensten zu unterscheiden werden die Begriffe '''IVS-Nutzen (privatfinanziert)''' und '''IVS-Wirkung (steuerfinanziert)''' verwendet. IVS-Nutzen und IVS-Wirkung können als rein '''Qualitative IVS-Ziele''' (BMM = Goals) formuliert werden und/oder als '''Quantitative IVS-Ziele''' (BMM = Objectives) quantitativ messbar sein.  &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für Qualitative und Quantitative IVS-Ziele''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! Qualitative IVS-Ziele (Goals)!! Quantitative IVS-Ziele (Objectives)&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport auf Bundesautobahnen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung von Auffahrunfällen&lt;br /&gt;
*Reduzierung von Unfällen in Baustellen&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung der Unfallhäufigkeit in Folge von Staus um X% &lt;br /&gt;
*Reduzierung der Unfälle mit LKW um X%&lt;br /&gt;
*Reduzierung von Folgeunfällen bei Stau um X%&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport bis zum Jahr 2050&lt;br /&gt;
|&lt;br /&gt;
*Reduzierung des Energieverbrauchs&lt;br /&gt;
*Reduzierung der Schadstoffemissionen&lt;br /&gt;
*Reduzierung der Lärmbelastungen&lt;br /&gt;
|&lt;br /&gt;
*Kraftstoffverbrauch um X% reduzieren&lt;br /&gt;
*CO2-Ausstoß um X% reduzieren &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Der informierte Reisende (zu jeder Zeit, an jedem Ort)&lt;br /&gt;
*Kontinuierliche Verbesserung des Modal Split von Pendlern&lt;br /&gt;
|&lt;br /&gt;
*Verbesserung der Nutzerfreundlichkeit bei der Anfrage von Reisealternativen der multimodalen Reiseplanung&lt;br /&gt;
*Aufklärung und Information der Reisenden&lt;br /&gt;
|&lt;br /&gt;
*Verkürzen der Latenzeit von der Reiseanfrage bis zur Präsentation der Reiseroute auf &amp;lt; 5 Sekunden&lt;br /&gt;
*10 % der bisherigen PKW-Fahrer steigen auf ÖPNV um&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Da IVS-Dienste in der Regel nur durch die Kooperation und Zusammenarbeit ganz unterschiedlicher IVS-Akteure entstehen, müssen sich diese sich letzendlich auf gemeinsame Ziele verständigen ('''Zwang zum Konsens''').&lt;br /&gt;
&lt;br /&gt;
== Das Means-Konzept (das (Hilfs-)Mittel-Konzept) ==&lt;br /&gt;
=== Einführung ===&lt;br /&gt;
&lt;br /&gt;
Ein (Hilfs-)Mittel repäsentiert jede Art von spezieller Fähigkeit, System, Technologie, Regelwerk, Instrument oder Methode etc., die in Anspruch genommen, aktiviert oder verstärkt werden kann, um Ziele (Ends) zu erreichen. Hilfs-(Mittel) sagen jedoch weder etwas aus über Schritte (Geschäftsprozesse und -abläufe), die notwendig sind um sie zu nutzen, noch über Verantwortlichkeiten für solche Aufgaben, sondern lediglich über die Fähigkeiten, die mit den (Hilfs-)mitteln verbunden sind un die einsetzbar sind, um die gewünschten Ergebnisse (Ends) zu erzielen.&lt;br /&gt;
&lt;br /&gt;
Wenn man (Hilfs-)Mittel beschreibt, ist es auch nützlich zu dokumentieren, wer das (Hilfs-)Mittel zu welchem Zeitpunkt einsetzt, sodass für die Zukunft als Referenz ein Prüfpfad exisitiert.&lt;br /&gt;
&lt;br /&gt;
===Hilfs-(Mittel)-Kategorien ===&lt;br /&gt;
[[Datei: Means-Konzept.png | thumb | 300 px | right | Übersichtsdarstellung über das Means-Konzept des Business Motivation Model]]&lt;br /&gt;
&lt;br /&gt;
Wie im nebenstehenden UML-Diagramm sichtbar lässt sich das (Hilfs-)Mittel-Konzept als  Hierarchie darstellen und begreifen. &lt;br /&gt;
&lt;br /&gt;
Insofern können (Hilfs-)Mittel sein:&lt;br /&gt;
*eine '''Mission''' (Handlungsoption, Aktion, Auftrag)&lt;br /&gt;
*:Eine '''Mission''' oder auch '''Handlungsoption''' bezeichnet, wie ihr Gegenstück '''Vision''', einen Langzeit-Ansatz, der auf die Erfüllung der Vision fokussiert ist. Wie die Vision ist die Mission nicht sehr spezifisch formuliert. Die Entscheidung für eine Handlungsoption sollte sich danach richten, wie Ressourcen, Fähigkeiten, Fertigkeiten und Kompetenzen, auf die eine Unternehmen/eine Organisation zurückgreifen kann, am besten genutzt werden können, um die formulierten Ziele auch tatsächlich zu erreichen.&lt;br /&gt;
*ein '''Handlungsmuster''' (strategisch oder taktisch)&lt;br /&gt;
*:In gewisser Weise, sind '''Handlungsmuster''' von grundsätzlicher Natur. Sie sind jedoch stumpfe Instrumente, wenn sie nicht durch entsprechende Direktiven gestützt werden, um eine reale Chance zu haben, erfolgreich zu sein.  &lt;br /&gt;
*eine '''Direktive''' (Geschäftspolitik, Geschäftsregel)  &lt;br /&gt;
*:Im Gegensatz zu Handlungsmustern, können '''Direktiven (Vorschriften und Richtlinien)''' nicht für sich alleine stehen. Vielmehr geben sie den Handlungsmustern den richtigen Schliff. Mit anderen Worten stellen sie sicher, dass Handlungsmuster in intelligenter Weise innerhalb von Grenzen angewendet werden, die für ein Unternehmen/eine Unternehmung akzeptabel bzw. optimal sind. Kurz formuliert, Direktiven repräsentieren das verschlüsselte (z.B. in schriftlicher Form dokumentierte) Wissen, das einem Handlungsmuster die Chance auf den höchstmöglichen Erfolg eröffnet. &lt;br /&gt;
*:Eine Direktive hat auch etwas zu tun mit Führung und Lenkung. Im Gegensatz dazu identifiziert ein Handlungsmuster den aktiven Ansatz auf dem Weg hin zu den Ends. Ein Handlungsmuster ist immer aktionsorientiert.&lt;br /&gt;
&lt;br /&gt;
=== Übertragung des Means-Konzept auf IVS ===&lt;br /&gt;
==== IVS-Missionen/IVS-Handlungsoptionen (BMM = Missions) ====&lt;br /&gt;
IVS-Missionen sind '''IVS-Handlungsoptionen''', die zum Ausdruck bringen, auf welche '''Art von IVS-Diensten in welcher Kombination''' man grundsätzlich zurückgreifen kann bzw. welche Art von IVS-Diensten in welcher Kombination am besten geignet sind, um der mit der Vision formulierten Zielvorstellung näher zu kommen. Die Entscheidung für eine Art von IVS-Diensten bzw. Kombination von Diensten und ihre spezifische Ausgestaltung sollte sich danach richten, wie '''ganz aktuell z.b. finanzielle und personelle Ressourcen sowie Fähigkeiten, Fertigkeiten, Kompetenzen und Technologien am besten eingesetzt werden''', um die formulierten Ziele zu erreichen. IVS-Handlungsoptionen müssen jedoch einen als '''realistisch erachteten Zeithorizont''' haben. So sollten z.B. IVS-Dienste, die im betrachteten Zeitraum noch nicht die erforderliche Technologiereife erreicht haben, nicht als IVS-Handlungsoption in Erwägung gezogen werden.&lt;br /&gt;
&lt;br /&gt;
Beispiele für IVS-Handlungsoptionen zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! IVS-Zielfeld !! IVS-Vision !! IVS-Handlungsoption (Mission)  &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Unfallfreier Verkehr und Transport&lt;br /&gt;
|Einsatz von Kooperativen IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|Emmisionsfreier Verkehr und Transport&lt;br /&gt;
|&lt;br /&gt;
*Einsatz von energieverbrauchsdämpfenden IVS-Diensten (ITS und C-ITS)&lt;br /&gt;
*Vermehrtes Feinstaubmanagement &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|Der informierte Reisende (jederzeit, an jedem Ort)&lt;br /&gt;
|Einsatz von in Realzeit arbeitenden multimodalen IVS-Informationsdiensten &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Handlungsmuster (BMM = Course of action) ==== &lt;br /&gt;
'''IVS-Handlungsmuster''' geben vor, '''wie bei man bei der Wahl einer IVS-Mission/IVS-Handlungsoption am besten vorgeht'''. IVS-Handlungsmuster definieren '''was zu tun ist''', aber '''nicht wie gut etwas zu tun''' ist. IVS-Performance-Kriterien werden mit den Zielen formuliert, die durch Handlungsmuster unterstützt werden. IVS-Handlungsmuster zielen nicht immer unmittelbar auf die Erreichung von Ergebnissen. Manche sind sinnvoll, um andere IVS-Handlungsmuster zu ermöglichen. &lt;br /&gt;
&lt;br /&gt;
IVS-Handlungsmuster werden unterschieden nach: &lt;br /&gt;
*'''IVS-Strategien...'''&lt;br /&gt;
**sind eher '''langzeitorientiert''' und '''breit''' angelegt. &lt;br /&gt;
**sind als Merkmale, die strategische Einflussfaktoren und Rahmenbedingungen repräsentieren, '''wesentlich für den Erfolg eines IVS-Handlungsmusters'''. &lt;br /&gt;
**legen für IVS-Handlungsmuster beste Vorgehensweisen, widerspruchsfreie Verhaltensmuster, Positionierungen und Sichtweisen der IVS-Aktueure bei der Modellierung, Planung, Realisierung und dem Betrieb von Intelligenten Verkehrssystemen fest.&lt;br /&gt;
**sind Schlüsselfaktoren, die oftmals über '''Erfolg oder Misserfolg von IVS-Diensten''' entscheiden. Zu den strategischen Merkmalen gehören insbesondere Finanzierungskonzepte, aber oft auch zu schaffende rechtliche Rahmenbedingungen und technologische Voraussetzungen. Diese müssen frühzeitig identifiziert und realisiert werden, um von Vornherein die Machbarkeit von IVS-Diensten sicherzustellen.&lt;br /&gt;
 &lt;br /&gt;
*'''IVS-Taktiken...'''&lt;br /&gt;
**sind eher '''auf kurze Sicht angelegt. &lt;br /&gt;
**werden gewählt, um die gewünschten '''Ergebnisse auch bestmöglich sicherzustellen'''&lt;br /&gt;
**können zur Implementierung mehrerer IVS-Strategien beitragen.&lt;br /&gt;
&lt;br /&gt;
So wie IVS-Handlungsmuster mit den gewünschten Ergebnissen (IVS-Nutzen, IVS-Wirkung) eines IVS-Dienstes korrespondieren, sind '''IVS-Strategien''' auf die '''generelle Zielsetzung''' ausgerichtet. IVS-Taktiken werden hingegen gewählt, um die '''gewünschten Ergebnisse''' auch bestmöglich '''sicherzustellen''' (wobei dieser Zusammenhang nicht zwangsweise gilt). &lt;br /&gt;
'''IVS-Strategien und IVS-Taktiken sind nicht scharf voneinander getrennt'''. Im Einzelfall muss jeder für sich entscheiden, nach welchen Kriterien er beide definiert.&lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Handlungsmuster''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
! rowspan=&amp;quot;2&amp;quot; | IVS-Zielfeld !! rowspan=&amp;quot;2&amp;quot; | IVS-Handlungsoption (Mission) !! colspan=&amp;quot;2&amp;quot; |IVS-Handlungsmuster &lt;br /&gt;
|+&lt;br /&gt;
! !! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) &lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|Implementierung von IVS-Diensten mit hoher Sicherheitswirkung&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellen-Slotmanagement&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von energieverbrauchsfreundlichen IVS-Diensten&lt;br /&gt;
*Einrichtung von (dynamischen) Umweltzonen (bei Feststellung erhöhter Werte werden Maßnahmen wie Fahrverbote o.ä. ergriffen) &lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten &lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation &lt;br /&gt;
|&lt;br /&gt;
*Angebot von Push-Diensten&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==== IVS-Richtlinen (IVS-Politik und IVS-Regeln) (BMM = Directives) ====&lt;br /&gt;
&lt;br /&gt;
'''IVS-Richtlinien geben den IVS-Handlungsmustern sozusagen &amp;quot;die richtige Richtung&amp;quot;'''. Sie führen und lenken die Ausführung der IVS-Handlungsmuster nach politischen Vorgaben und anerkannten Regeln.&lt;br /&gt;
&lt;br /&gt;
*Auf der einen Seite ist mit IVS-Richtlinien '''Einschränkung''' verbunden. Durch Vorgabe von IVS-Richtlinien soll sichergestellt werden, dass IVS-Handlungsmuster - möglichst in intelligenter Weise - '''innerhalb vorgegebener Grenzen''' angewendet werden.&lt;br /&gt;
&lt;br /&gt;
*Auf der anderen Seite repräsentieren IVS-Richtlinien das verschlüsselte, in der Regel in schriftlicher Form '''dokumentierte Wissen''', das einem '''Handlungsmuster die Chance auf den höchstmöglichen Erfolg''' eröffnet.&lt;br /&gt;
 &lt;br /&gt;
IVS-Richtlinien werden kategorisiert nach:&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Politik(-richtlinien''')&lt;br /&gt;
**Grundsätzlich ist es Aufgabe der (IVS)-Politik zu '''regulieren''', d.h. die Anwendung von IVS in Form politischer (auch gesetzlicher) Vorgaben zu regeln oder-  mit anderen Worten ausgedrückt - '''zu steuern und zu führen''' und damit die angewandten IVS-Strategien und IVS-Taktiken zu gestalten.&lt;br /&gt;
**IVS-Politik legt fest, '''was getan werden darf, aber auch was getan werden muss''', und gibt an, wie oder '''in welchen Grenzen''' etwas getan werden kann.&lt;br /&gt;
** Im Vergleich zu IVS-Regeln ist '''IVS-Politik weniger strukturiert''' und auch weniger detailliert formuliert. '''IVS-Politik''' ist in diesem Sinne auch '''nicht direkt &amp;quot;ausführbar&amp;quot;'''.&lt;br /&gt;
&lt;br /&gt;
*'''IVS-Regeln (auch IVS-Prinzipien)'''&lt;br /&gt;
**IVS-Regeln leiten sich von der IVS-Politik ab und sind '''ausführbare IVS-Richtlinien'''. &lt;br /&gt;
**Sie müssen auch als solche definiert sein und aus Konsistenz- und Vollständigkeitsgründen muss '''ihre Ausführung überwacht und überprüft''' werden. &lt;br /&gt;
&lt;br /&gt;
'''Beispiele für IVS-Richtlinien''' zeigt folgende Tabelle:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!! rowspan=&amp;quot;2&amp;quot; |IVS- Zielfeld !! colspan=&amp;quot;2&amp;quot; | IVS-Handlungsmuster (Course of actions) !! colspan=&amp;quot;2&amp;quot; | (IVS-Richtlinien) Directive&lt;br /&gt;
|+&lt;br /&gt;
! !! IVS-Strategie (Strategy) !! IVS-Taktik (Tactics) !! IVS-Politik (Business Policy) !! IVS-Regeln  und IVS-Prinzipien (Business Rules)&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Sicherheit&lt;br /&gt;
|&lt;br /&gt;
Vermeidung staubedingter Unfälle&lt;br /&gt;
*Vermeidung von Staubildung&lt;br /&gt;
*Vorbeugung von Auffahrunfällen bei Stau&lt;br /&gt;
*...&lt;br /&gt;
Vermeidung von Unfällen an Baustellen&lt;br /&gt;
*Baustellenmanagment&lt;br /&gt;
*Baustellenwarnung&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs&lt;br /&gt;
*Warnung von Stau(-Enden)&lt;br /&gt;
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis...)&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Emissionen&lt;br /&gt;
|&lt;br /&gt;
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen&lt;br /&gt;
*Vermeidung von energieverschwendenen Brems-und Anfahrvarhalten an Lichtsignalanlagen&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen&lt;br /&gt;
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*Verdichtung des Messtellennetzes  &lt;br /&gt;
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken &lt;br /&gt;
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)&lt;br /&gt;
*Verstärtker Einsatz von Grüne-Welle Assistenten auf lichtsignalgereglten Strecken  &lt;br /&gt;
|&lt;br /&gt;
*Abstand zwischen Anzeigequerschnitten &amp;lt; 2 km&lt;br /&gt;
*&amp;quot;Vermeidung&amp;quot; vor &amp;quot;Warnung&amp;quot;&lt;br /&gt;
*Implementation von Grüne-Welle Assistenten ab einer einer Morgenspitze &amp;gt; X Kfz/h   &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|-style=&amp;quot;vertical-align:top;&amp;quot;&lt;br /&gt;
|Mobilität&lt;br /&gt;
|&lt;br /&gt;
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten&lt;br /&gt;
*...&lt;br /&gt;
|&lt;br /&gt;
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive, verkehrsmittelneutrale Reiseinformation&lt;br /&gt;
|&lt;br /&gt;
*Open-Data Initiative &lt;br /&gt;
|&lt;br /&gt;
*Schnittstellen grundsätzlich als DATEX II-Profile&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsprozess-Template&amp;diff=7453</id>
		<title>IVS-Geschäftsprozess-Template</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Gesch%C3%A4ftsprozess-Template&amp;diff=7453"/>
		<updated>2016-10-11T15:36:54Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* IVS-Geschäftsprozess... */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== IVS-Geschäftsprozess... ===&lt;br /&gt;
* ist ein IVS-Architekturbaustein, zur Beschreibung von durchzuführenden Aktivitäten, um eine IVS-Dienstekategorie bzw. einen IVS-Dienst umzusetzen.&lt;br /&gt;
* ordnet die einzelnen Aktivitäten bestimmten IVS-Rollen bzw. IVS-Akteuren zu.&lt;br /&gt;
* legt die Reihenfolge der Aktivitäten fest.&lt;br /&gt;
* verwendet IVS-Informationsobjekte als Input bzw. Output, der zwischen IVS-Rollen bzw. IVS-Akteuren ausgetauscht wird.&lt;br /&gt;
&lt;br /&gt;
=== Template als Grafik ===&lt;br /&gt;
[[Datei: IVS-Geschäftsprozess-Template_00-00-03.png | 500px | IVS-Geschäftprozess ]]&lt;br /&gt;
&lt;br /&gt;
=== Template als Word-Datei ===&lt;br /&gt;
[[Medium:IVS-Geschäftsprozess-Katalog_00-00-03.docx | IVS-Geschäftprozesse]] &lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Informationsobjekt-Template&amp;diff=7452</id>
		<title>IVS-Informationsobjekt-Template</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Informationsobjekt-Template&amp;diff=7452"/>
		<updated>2016-10-11T15:35:14Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* IVS-Informationsobjekt... */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== IVS-Informationsobjekt(e)... ===&lt;br /&gt;
* ist ein IVS-Architekturbaustein, der die semantische Beschreibung inhaltlich zusammengehöriger Informationen beschreibt.&lt;br /&gt;
* wird als Input bzw. Output in IVS-Geschäftsprozessen verwendet.&lt;br /&gt;
* werden in IVS-Datenmodellen beschrieben und verwendet.&lt;br /&gt;
&lt;br /&gt;
=== Template als Grafik ===&lt;br /&gt;
[[Datei: IVS-Informationsobjekt-Template 00-00-01.png | 500px | IVS-Informationsobjekt-Template ]]&lt;br /&gt;
&lt;br /&gt;
=== Template als Datei===&lt;br /&gt;
&lt;br /&gt;
[[Medium:IVS-Informationsobjekt-Katalog_00-00-01.docx | IVS-Informationsobjekt-Katalog]]&lt;br /&gt;
&lt;br /&gt;
[[Medium:IVS-Informationsobjekt-Katalog_Los1_00-00-01.docx | IVS-Informationsobjekt-Katalog (vorausgefülltes Beispiel)]]&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Datenmodell-Template&amp;diff=7451</id>
		<title>IVS-Datenmodell-Template</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Datenmodell-Template&amp;diff=7451"/>
		<updated>2016-10-11T15:34:10Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* IVS-Datenmodell... */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== IVS-Datenmodell...===&lt;br /&gt;
* ist ein IVS-Architekturbaustein, der IVS-Informationsobjekte enthält und IVS-Referenzierungen zur Beschreibung von Orten verwendet.&lt;br /&gt;
* wird in einer IVS-Domäne entwickelt und ist historisch gewachsen.&lt;br /&gt;
* wird in IVS-Schnittstellen verwendet.&lt;br /&gt;
&lt;br /&gt;
=== Template als Grafik===&lt;br /&gt;
[[Datei: IVS-Datenmodell-Template 00-00-01.PNG | 500px | IVS-Datenmodell-Template ]]&lt;br /&gt;
&lt;br /&gt;
=== Template als Word-Datei===&lt;br /&gt;
[[Medium:IVS-Datenmodell-Katalog_00-00-01.docx | IVS-Datenmodell-Katalog]]&lt;br /&gt;
&lt;br /&gt;
[[Medium:IVS-Datenmodell-Katalog_Los1_00-00-01.docx | IVS-Datenmodell-Katalog (vorausgefülltes Beispiel)]]&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Ortsreferenzierung&amp;diff=7450</id>
		<title>IVS-Ortsreferenzierung</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Ortsreferenzierung&amp;diff=7450"/>
		<updated>2016-10-11T15:31:49Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* IVS-Ortsreferenzierung... */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== IVS-Ortsreferenzierung...===&lt;br /&gt;
* ist ein IVS-Architekturbaustein, der verwendet wird, um geographische Orte zu beschreiben.&lt;br /&gt;
* wird in verschiedenen (nicht nur IVS-) Domänen entwickelt und ist historisch gewachsen.&lt;br /&gt;
* wird in IVS-Datenmodellen verwendet, um den Ort, an dem oder für den eine Information gilt, zu beschreiben.&lt;br /&gt;
* kann teilweise und oft nur ''verlustbehaftet'' in andere Ortsreferenzierungen umgerechnet werden.&lt;br /&gt;
&lt;br /&gt;
=== Template als Grafik===&lt;br /&gt;
[[Datei:IVS-Ortsreferenzierung-Template_00-00-01.png | 500px | IVS-Ortsreferenzierung-Template ]]&lt;br /&gt;
&lt;br /&gt;
=== Template als Word-Datei===&lt;br /&gt;
[[Medium:IVS-Ortsreferenzierungs-Katalog_00-00-01.docx | IVS-Ortsreferenzierungs-Katalog]]&lt;br /&gt;
&lt;br /&gt;
[[Medium:IVS-Ortsreferenzierungs-Katalog_Los1_00-00-01.docx | IVS-Ortsreferenzierungs-Katalog (vorausgefülltes Beispiel)]]&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capability&amp;diff=7449</id>
		<title>IVS-Capability</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capability&amp;diff=7449"/>
		<updated>2016-10-11T15:30:15Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* Definition */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== IVS-Capabilitiy ==&lt;br /&gt;
&lt;br /&gt;
=== Definition ===&lt;br /&gt;
Mit Capability wird eine (Geschäfts-)Fähigkeit bezeichnet, die eine Organisation, Person oder System besitzt. Capabilities werden typischerweise mit allgemeinen bzw. übergeordneten Begriffen benannt und erfordern typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können.&lt;br /&gt;
&lt;br /&gt;
=== Template als Grafik ===&lt;br /&gt;
&lt;br /&gt;
[[Datei: IVS-Capability-Template_00-00-01.PNG | 500px | IVS-Capability-Template ]]&lt;br /&gt;
&lt;br /&gt;
=== Template als Word-Datai ===&lt;br /&gt;
&lt;br /&gt;
[[Medium:IVS-Capability-Template_00-00-01.docx | IVS-Capability-Template]]&lt;br /&gt;
&lt;br /&gt;
[[Medium:IVS-Capability-Template-Katalog_00-00-01.docx | IVS-Capability-Template-Katalog]] &lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
	<entry>
		<id>http://wikiivs.albrechtconsult.com/index.php?title=IVS-Schnittstelle&amp;diff=7448</id>
		<title>IVS-Schnittstelle</title>
		<link rel="alternate" type="text/html" href="http://wikiivs.albrechtconsult.com/index.php?title=IVS-Schnittstelle&amp;diff=7448"/>
		<updated>2016-10-11T15:28:56Z</updated>

		<summary type="html">&lt;p&gt;Pfähler: /* IVS-Schnittstelle */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== IVS-Schnittstelle... ===&lt;br /&gt;
&lt;br /&gt;
*ist ein IVS-Architekturbaustein, der dem Austausch von Informationen zwischen Systemen dient.&lt;br /&gt;
*entspricht einer Schnittstellenspezifikation, die aus der Festlegung eines Protokolls und eines Datenmodells besteht.&lt;br /&gt;
*wird von IVS-Anwendungen verwendet und durch diese realisiert.&lt;br /&gt;
&lt;br /&gt;
=== Template als Grafik===&lt;br /&gt;
[[Datei: IVS-Schnittstellen-Template_00-00-01.png | 500px | IVS-Schnittstelle]]&lt;br /&gt;
&lt;br /&gt;
=== Template als Word-Datei===&lt;br /&gt;
[[Medium:IVS-Schnittstellen-Katalog_00-00-01.docx | IVS-Schnittstellen-Katalog]]&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[Hauptseite|&amp;lt;&amp;lt; Zurück zur Hauptseite]]&lt;/div&gt;</summary>
		<author><name>Pfähler</name></author>
		
	</entry>
</feed>