Konzeption und Entwicklung eines kennzahlenbasierten Management Cockpits zum Monitoring der unternehmensinternen Kommunikation

Transkript

1 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Wirtschaftsinformatik Konzeption und Entwicklung eines kennzahlenbasierten Management Cockpits zum Monitoring der unternehmensinternen Kommunikation Maren Steinkamp

2

3 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Wirtschaftsinformatik Konzeption und Entwicklung eines kennzahlenbasierten Management Cockpits zum Monitoring der unternehmensinternen Kommunikation Design and development of a metric-based management cockpit for monitoring unified communication in an enterprise Bearbeiter: Maren Steinkamp Aufgabensteller: Prof. Dr. Florian Matthes Betreuer: Dipl.-Inf. Christian M. Schweda Datum: 12. Mai 2010

4

5 Ich versichere, dass ich diese Bachelorarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. München, den 14. Mai 2010 Maren Steinkamp

6

7 Eine Veröffentlichung der vorliegenden Arbeit oder von Teilen daraus ist nur mit Genehmigung der Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK gestattet.

8

9 Zusammenfassung Unified Communications (UC) ist ein aktueller Trend der Kommunikationstechnik, der durch die Konvergenz von Telekommunikation, Informationstechnologie und Unternehmensanwendungen entstanden ist. Durch eine Integration von allen wichtigen Kommunikationsmedien im Unternehmen und deren Einbindung in die Kommunikationsprozesse des Unternehmens soll die Effizienz der Kommunikation und somit auch die Produktivität der Mitarbeiter gesteigert werden. Diese Steigerung der Kommunikationseffizienz ist derzeit aber nur schwer nachweisbar. Da die Einführung eines Unified Communications Systems jedoch von hohen Kosten begleitet wird, sind viele Unternehmen an dem tatsächlichen Nutzen von UC-Systemen interessiert. Aus diesem Bedarf heraus wird im Rahmen dieser Arbeit in Kooperation mit der Fraunhofer Einrichtung für Systeme der Kommunikationstechnik die Grundlage für ein System zur Analyse und Visualisierung der Effizienzsteigerung durch UC-Systeme entwickelt. Das Unified Communications Management Cockpit (UCMC) visualisiert mit Hilfe von verschiedenen Kennzahlen die Nutzung des UC-Systems durch die Mitarbeiter und bietet somit unter anderem die Möglichkeit, die Nutzung des UC-Systems auf Optimierungspotenziale hin zu analysieren. ix

10

11 Abstract Unified Communications (UC), an evolving trend in the field of communications technology, results from the ongoing convergence of telecommunication, information technology and business applications. By integrationg all important communication media with each other and with the company s communication processes, UC aims to optimize the communication efficiency in a company, and thus ultimately also the employees productivity. At present, providing evidence for the actual enhancement of communication efficiency is difficult. Given that the introduction of an UC-system has high cost implications, many companies are interested in the actual benefits of UC-systems. Within this thesis and in cooperation with Fraunhofer Einrichtung für Systeme der Kommunikationstechnik, the basis for a system for analysis and visualization of the communication efficiency s enhancement through UC-systems has been developed. The Unified Communications Management Cockpit (UCMC) visualizes the UC-system s utilization employing several performance figures and hence, among other features, allows to analyze the UC-system s utilization and to reveal potential for optimization. xi

12 xii

13 Inhaltsverzeichnis Zusammenfassung Abstract Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis ix xi xiv xv xvii I Einleitung und Grundlagen 1 1 Einleitung Motivation Zielsetzung der Arbeit Vorgehensweise Aufbau der Arbeit Theoretische Grundlagen Kommunikation im Unternehmen Kommunikation Kommunikationsmedien Unternehmensinterne Kommunikation Effiziente Kommunikation im Unternehmen Kommunikationsanalyse Unified Communications Konzept Motivation und Hintergrund Unified Communications-Systeme Potenzial und Nutzen Herausforderungen UC in deutschen Unternehmen II Unified Communications Management Cockpit 25 3 Anforderungsanalyse Produkteinsatz Funktionale Anforderungen xiii

14 Inhaltsverzeichnis Produktfunktionen Darzustellende Informationen (MC Elemente) Nichtfunktionale Anforderungen Anforderungen an die Qualität Sonstige Anforderungen Entwurf Architekturentwurf Tier-Architektur Model-View-Controller Verwendete Technologien Entwurf eines integrierenden Datenbankschemas Implementierung Implementierung des UCMC mit Adobe AIR Benutzeroberfläche Überblick über die Architektur Umsetzung von MVC Struktur der Konfigurationsdateien Umsetzung der Datenbank mit SQLite III Fazit und Ausblick 57 6 Fazit und Ausblick 59 Literaturverzeichnis 63 Appendix 67 A Microsoft Datenbankschema des OCS R2 67 B Erläuterung des logischen Datenbankschemas 69 C Kennzahlenkatalog der Klasse ChartData.as 77 D SQL-Definition der SQLite-Datenbank 81 D.1 Alle Tabellen ohne Fremdschlüssel D.2 Definition der benötigten Views D.3 Tabellen mit Fremdschlüssel xiv

15 Abkürzungsverzeichnis AIR API CSS DBMS ERM ESK FMC IKT IM MVC OCS RIA UC UCMC UML VoIP Adobe Integrated Runtime Application Programming Interface Cascading Stylesheet Datenbankmanagementsystem Entity-Relationship-Modell Einrichtung für Systeme der Kommunikationstechnik Fixed-Mobile-Convergence Informations- und Kommunikationstechnik Instant Messaging Model-View-Controller Office Communications Server Rich Internet Application Unified Communications Unified Communications Management Cockpit Unified Modeling Language Voice-over-IP xv

16 Inhaltsverzeichnis xvi

17 Abbildungsverzeichnis 2.1 Relevante Eigenschaften interpersonaler Kommunikation (eigene Darstellung) Das Media-Richness-Modell nach Daft und Lengel (nach [PRW01]) Module eines UC-Systems (eigene Darstellung) Grundlegender Aufbau des UCMC Anwendungsfalldiagramm für das UCMC Im UCMC darzustellende MC-Elemente Entity-Relationship-Modell des Datenbankschemas Logisches Datenbankschema Screenshot des UCMC mit Erläuterungen Paketdiagramm des UCMC Vereinfachtes Klassendiagramm des UCMC Umsetzung von MVC im UCMC xvii

18

19 Teil I Einleitung und Grundlagen 1

20

21 1 Einleitung 1.1 Motivation Durch neue organisatorische Strukturen muss heutzutage ein Großteil der Kommunikation im Unternehmen über zeitliche, geografische und organisatorische Grenzen hinweg stattfinden. Das Kommunikationsvolumen pro Mitarbeiter sowie die Anzahl der verfügbaren Kommunikationsmedien sind in den letzten Jahren angestiegen [Ber08]. Parallel zur damit verbundenen Zunahme der Komplexität der Kommunikation im Unternehmen gab es aber auch Fortschritte in der Kommunikationstechnik. So verwenden mittlerweile viele Unternehmen IP-basierte Infrastrukturen und moderne softwarebasierte Kommunikationsmedien. Ein weiterer Trend der Kommunikationstechnik sind Unified Communications (UC) Systeme. Diese versuchen, den neuen Anforderungen an die Kommunikation gerecht zu werden, indem sie bisher separierte Kommunikationsmedien bündeln und um Funktionalitäten, wie Präsenzsignalisierung und die Integration von Unternehmenssoftware, erweitern. Durch den Einsatz von UC-Systemen soll die Effizienz der Kommunikation im Unternehmen gesteigert werden. Die erwarteten Effizienzsteigerungen lassen sich in der Praxis bisher nur schwer überprüfen. Dies liegt unter anderem daran, dass Kommunikationseffizienz kein wohldefinierter Begriff ist, von vielen verschiedenen, teils subjektiven Faktoren abhängt und somit nur schwer messbar ist. Es herrscht allerdings Einigkeit darüber, dass der maximale Unternehmensnutzen aus UC nur dann erzielt werden kann, wenn zum einen die technische Implementierung und Integration des UC-Systems erfolgreich war und zum anderen die Mitarbeiter mit dem UC-System sowie all seinen Funktionalitäten zufrieden sind und diese auch nutzen. 1.2 Zielsetzung der Arbeit In dieser Arbeit soll die Grundlage für ein umfassendes System zur Analyse der Potenziale von UC-Systemen, insbesondere zur Analyse der Effizienzsteigerung durch UC-Systeme, gelegt werden. Der erste Schritt auf dem Weg zu diesem System soll eine Anwendung zur Messung der Nutzung von UC-Systemen sein. Zu diesem Zweck sollen im Rahmen der Arbeit die Grundlagen für ein Management Cockpit entwickelt werden, welches relevante Kennzahlen über die Nutzung eines UC-Systems in geeigneter Form grafisch aufbereitet. Das Management Cockpit soll die Möglichkeit bieten, die Nutzung des UC-Systems im Unternehmen zu analysieren und Hilfestellung bei der Abgabe von Optimierungs- und Handlungsempfehlungen geben. Dafür soll sich das Management Cockpit ausgelesener Loggingdaten aus dem Betrieb verschiedener UC-Systeme bedienen, die auf Basis eines zu entwickelnden Schemas aggregiert und einer Visualisierungskomponente zugeführt werden. Eine besondere Herausforderung der Arbeit stellt dabei die Schaffung einer erweiterbaren Softwarearchitektur dar, die die zukünftige Verwendung von Logginginformatio- 3

22 1 Einleitung nen aus dem Betrieb weiterer UC-Systeme erlaubt. Desweiteren muss die Architektur eine flexible Grundlage für Anpassungen an das Kennzahlensystem sowie die grafischen Darstellungsformen darstellen. 1.3 Vorgehensweise In einem ersten Schritt wurden, basierend auf einer umfassenden Literaturrecherche, die Theorie und die Grundprinzipien von Kommunikation im Unternehmen und von UC- Systemen erarbeitet. Insbesondere fand hierbei auch eine Auseinandersetzung mit dem Begriff Kommunikationseffizienz statt. Desweiteren fand eine Einarbeitung in die UC- Systeme, welche der Fraunhofer Einrichtung für Systeme der Kommunikationstechnik (ESK) zur Verfügung stehen, sowie deren Loggingdaten statt. Mit Hilfe der im ersten Schritt gewonnenen Erkenntnisse wurden im Anschluss die Anforderungen an das Management Cockpit erhoben. Hierbei wurde durch zahlreiche Gespräche mit dem verantwortlichen Mitarbeiter der Fraunhofer ESK auch geklärt, welche speziellen Anforderungen die Fraunhofer ESK an das Management Cockpit stellt. In der sich anschließenden Entwurfsphase sind die Softwarearchitektur und das der Anwendung zugrundeliegende Datenbankschema entworfen worden. Bei der Erstellung des Datenbankschemas wurde zunächst ein konzeptuelles Modell erstellt, welches den Sachverhalt unternehmensinterne, mittelbare Kommunikation darstellt. Dieses ist im Anschluss in ein implementierungsnahes logisches Schema überführt worden. Im Anschluss an die Entwurfsphase wurde das Management Cockpit entsprechend der in der Entwurfsphase getroffenen Entscheidungen implementiert, wobei die eigentliche Anwendung mit Adobe AIR und die Datenbank mit SQLite umgesetzt wurde. 1.4 Aufbau der Arbeit Der Aufbau dieser Arbeit entspricht im Wesentlichen der im vorangegangen Abschnitt vorgestellten Vorgehensweise. Die Ergebnisse der Literaturrecherche und Überlegungen während der ersten Phase werden in Kapitel 2 dieser Arbeit näher erläutert. Es wird zunächst ein Verständnis von Kommunikation und deren Eigenschaften erarbeitet und anschließend auf die Themen Unternehmenskommunikation und UC-Systeme sowie deren Potenziale und Herausforderungen eingegangen. Eine Präsentation der Ergebnisse der Anforderungsanalyse befinden sich in Kapitel 3. Dabei werden zuerst die funktionalen Anforderungen an Hand eines Anwendungsfalldiagramms beschrieben und danach die nichtfunktionalen Anforderungen an das System definiert. Kapitel 4 beinhaltet die Ergebnisse der Entwurfsphase. Es findet eine Besprechung der Details der entworfenen Softwarearchitektur und eine Vorstellung der für die Umsetzung ausgewählten Technologien und ihrer Besonderheiten statt. Desweiteren werden die beim Datenbankentwurf erstellten Modelle präsentiert. Kapitel 5 enthält eine Beschreibung relevanter Aspekte der Implementierung. Dabei wird insbesondere auf die Umsetzung der Architektur und des Model- View-Controller-Architekturmusters eingegangen. Zudem befindet sich in diesem Kapitel eine detaillierte Beschreibung, wie die Anforderung, dass das Management Cockpit um weitere Informationen und Kennzahlen erweiterbar sein soll, umgesetzt wurde. Im letzten Kapitel werden die Erkenntnisse dieser Arbeit zusammengefasst, und ein Überblick über 4

23 1.4 Aufbau der Arbeit die Perspektiven der erstellten Anwendung gegeben. Es werden Aspekte angesprochen, die in dieser Arbeit nicht berücksichtigt werden konnten und Erweiterungsmöglichkeiten für das Management Cockpit aufgezeigt. 5

24 1 Einleitung 6

25 2 Theoretische Grundlagen Zur Schaffung einer wissenschaftlichen Basis für diese Arbeit werden im Verlauf dieses Kapitels einige theoretische Grundlagen und Begriffe diskutiert. Inhaltlich relevante Bezugsthemen für das Unified Communications Management Cockpit sind die Kommunikation im Unternehmen und Unified Communications. 2.1 Kommunikation im Unternehmen Ausgehend von einer Definition des Begriffes Kommunikation werden in diesem Unterkapitel die für die Unternehmenskommunikation relevanten Aspekte hervorgehoben. Es wird zudem ein Überblick über die verschiedenen Kommunikationsmedien gegeben. Im Anschluss werden die Bereiche der unternehmensinternen Kommunikation dargestellt, die für diese Arbeit von Bedeutung sind. In diesem Rahmen spielen insbesondere auch die Begriffe effiziente Kommunikation und Kommunikationsanalyse eine Rolle Kommunikation Kommunikation ist ein Begriff, der häufig sowohl in der Alltags- als auch in der Wissenschaftssprache anzutreffen ist. Der Begriff kann somit unterschiedlich definiert werden und die Definition kann verschieden weit gefasst sein. In der folgenden Ausführung soll versucht werden, ein Verständnis des Begriffes Kommunikation zu schaffen, das sich auf die Kommunikation im Unternehmen anwenden lässt. Eine Definition, die eine gute Ausgangslage für die Ausarbeitung der für die Kommunikation im Unternehmen relevanten Eigenschaften von Kommunikation bietet, befindet sich im Politiklexikon der Bundeszentrale für politische Bildung [SK06]: (lat.) Kommunikation bezeichnet den Austausch von Informationen zwischen zwei oder mehreren Personen. Als elementare Notwendigkeit menschlicher Existenz und wichtigstes soziales Bindemittel kann Kommunikation über Sprache, Mimik, Gestik, durch schriftlichen Austausch, Medien etc. stattfinden. Zu unterscheiden sind a) interpersonale Kommunikation (unmittelbar und mittelbar zwischen Personen), b) Massen-Kommunikation (wenige Journalisten bereiten Informationen auf, die von vielen Lesern konsumiert werden) und c) Gruppen-Kommunikation (innerhalb bestimmter, organisierter sozialer Gruppen, Verbände, Parteien). Für den in dieser Arbeit betrachteten Teil der Kommunikation im Unternehmen ist nur die interpersonale Kommunikation von Bedeutung, welche oft auch als zwischenmenschliche Kommunikation bezeichnet wird. Aus diesem Grund wird auf die besonderen Merkmale der Massen- und Gruppenkommunikation im Folgenden nicht weiter eingegangen. 7

26 2 Theoretische Grundlagen Die interpersonale Kommunikation kann zwischen zwei oder mehreren Personen stattfinden. Ersteres wird als 1:1-Kommunikation und letzteres als 1:n-Kommunikation bezeichnet. Zudem kann zwischen unmittelbarer und mittelbarer Kommunikation unterschieden werden. Sobald sich die Kommunikationspartner nicht mehr zur selben Zeit am selben Ort befinden, wird Kommunikation erst durch den Einsatz von Kommunikationsmedien möglich und man spricht von mittelbarer oder vermittelter Kommunikation. Unmittelbare Kommunikation kann nur stattfinden, wenn sich die Kommunikationsteilnehmer zur selben Zeit am selben Ort befinden und direkt miteinander kommunizieren können. Diese Art der Kommunikation wird oft auch als direkte Kommunikation bezeichnet. Eine weitere Möglichkeit zur Klassifizierung von Kommunikation ist die Unterscheidung von synchroner und asynchroner Kommunikation. Synchrone Kommunikation bedeutet, dass die Personen zur selben Zeit miteinander kommunizieren und somit direkt auf Kommunikationsbeiträge reagieren können. Dies ist zum Beispiel bei einem face-to-face Gespräch oder einem Telefongespräch der Fall. Asynchrone Kommunikation hingegen findet zeitlich versetzt statt. Hierzu zählen beispielsweise der Versand eines Briefes oder einer Mail. Während unmittelbare Kommunikation immer synchron stattfindet, kann mittelbare Kommunikation sowohl synchron als auch asynchron stattfinden. Axiome der Kommunikation Kommunikationsmodelle sind wissenschaftliche Modelle, die versuchen, möglichst genau zu beschreiben, was Kommunikation ist und wie sie funktioniert. Die Axiome der Kommunikation nach Watzlawick, Beavin und Jones bilden ein bekanntes Kommunikationsmodell, welches auch als Grundlage für die Ausarbeitung vieler weiterer Modelle diente. Ausgehend von verschiedenen Grundeigenschaften zwischenmenschlicher Kommunikation haben sie fünf Axiome hergeleitet. Diese Axiome beziehen sich auf die interpersonale Kommunikation und erweitern den bisher eingeführten Kommunikationsbegriff um weitere wichtige Merkmale. 1. Axiom Man kann nicht nicht kommunizieren. 2. Axiom Jede Kommunikation besitzt einen Inhalts- und einen Beziehungsaspekt. 3. Axiom Die Beziehung zwischen Kommunikationspartnern ist durch die Interpunktion von Kommunikationsabläufen geprägt. 4. Axiom Menschliche Kommunikation bedient sich digitaler und analoger Modalitäten. 5. Axiom Kommunikation kann auf symmetrischen und komplementären Beziehungen beruhen. (In Anlehnung an [WBJ90]) Mit dem ersten Axiom sagt Watzlawick, dass jede Form von Verhalten Kommunikation ist und somit auch einen Mitteilungscharakter besitzt. Ein Mensch kann nicht nicht kommunizieren und Kommunikation kann auch nonverbal und unbewusst stattfinden. Schon das wortlose Vorbeigehen an einer anderen Person stellt somit Kommunikation dar. Das zweite Axiom besagt, dass jede Kommunikation einen Inhalts- und einen Beziehungsaspekt besitzt. Während durch den Inhaltsaspekt Sachinformationen übermittelt werden, 8

27 2.1 Kommunikation im Unternehmen bezieht der Beziehungsaspekt sich auf das Verhältnis zwischen den Kommunikationspartnern. Der Beziehungsaspekt enthält Informationen darüber, wie der Inhaltsaspekt vom Empfänger interpretiert werden soll. Durch dieses Axiom verdeutlicht Watzlawick, dass Kommunikation auch die soziale Beziehung zwischen den Kommunikationsteilnehmern beeinflussen kann. Je deutlicher und einfacher die Beziehung zwischen den Kommunikationsteilnehmern ist, desto weniger Aufwand wird für die Klärung des Beziehungsaspektes benötigt und desto leichter können Informationen übermittelt werden [PRW01, S. 93ff]. Für Watzlawick hat Kommunikation kein Anfang und kein Ende, sondern verläuft immer kreisförmig. Die Kommunikationsteilnehmer gliedern sich jedoch jeden Kommunikationsprozess in unterscheidbare Abschnitte (Interpunktion) und interpretieren somit ihr eigenes Verhalten oft als Reaktion auf das Verhalten der anderen Kommunikationsteilnehmer. Das dritte Axiom sagt, dass diese Interpunktion von Kommunikationsabläufen die Beziehung zwischen den Kommunikationspartnern entscheidend prägt. Mit dem vierten Axiom wird zwischen digitaler und analoger Kommunikation unterschieden. Das Mittel der digitalen Kommunikation ist nach Watzlawick die schriftliche und mündliche Sprache. Sie ist auf Grund ihrer eindeutigen Syntax vor allem für die Übermittlung des Inhaltsaspektes geeignet. Die analoge Kommunikation entspricht der nonverbalen Kommunikation (Mimik, Gestik, Tonlage, etc.). Sie hat eine weniger eindeutige Syntax und dient meist zur Übermittlung des Beziehungsaspektes (vgl. [PRW01, S. 94f]). Die analoge Sprache kann nur bei unmittelbarer Kommunikation in vollem Umfang verwendet werden, bei der mittelbaren Kommunikation hängt die mögliche Verwendung stark von dem gewählten Medium ab. Während beispielsweise bei Telefonaten die Tonlage übermittelt werden kann, ist dies bei s nicht möglich. Das fünfte Axiom unterscheidet zwischen symmetrischen und komplementären Kommunikationsbeziehungen. Eine symmetrische Kommunikationsbeziehung besteht zwischen Personen gleicher sozialer Position, wie z.b. zwischen gleichgestellten Kollegen. Eine komplementäre Kommunikationsbeziehung besteht hingegen, wenn die Kommunikationspartner eine unterschiedliche soziale Position haben. Sie zeichnet sich oft durch eine Unterordnung oder Abhängigkeitsbeziehung aus, wie es beispielsweise zwischen einem Vorgesetzten und dessen Mitarbeiter der Fall ist. Zusammenfassung interpersonale Kommunikation Abbildung 2.1 gibt einen Überblick über die für diese Arbeit relevanten Eigenschaften von Kommunikation und skizziert grob deren Zusammenhänge. In der vorliegenden Arbeit werden weitere Begriffe verwendet, die hier kurz erläutert werden sollen, um sicherzugehen, dass ein einheitliches Verständnis dieser Begriffe gegeben ist. Kommunikationsprozess Im Bereich der interpersonalen Kommunikation entspricht ein Kommunikationsprozess einem Kommunikationsakt. Jede Kommunikation stellt somit einen Kommunikationsprozess dar. Ein Kommunikationsprozess ist meistens nicht genau definiert, sondern frei gestaltbar. Insbesondere im Bereich der formellen Kommunikation im Unternehmen gibt es jedoch auch definierte und vorgegebene Kommunikationsprozesse. Diese stehen oft in Zusammenhang mit Geschäftsprozessen (vgl. Abschnitt 2.1.3). 9

28 2 Theoretische Grundlagen Kommunikationsmedien Asynchron Synchron Interpersonale Kommunikation entweder oder immer Mittelbar Unmittelbar Zwei oder mehr Teilnehmer abh. von Medium und Digitale Modalitäten Analoge Modalitäten Interpunktion stark gering stark Symmetrische Beziehung Komplementäre Beziehung Inhaltsaspekt Beziehungsaspekt Verwendung von Übermittlung von z.b. stark = starke Übermittlung des...aspektes durch Modalitäten Abbildung 2.1: Relevante Eigenschaften interpersonaler Kommunikation (eigene Darstellung) Kommunikationsaufgabe Im Rahmen dieser Arbeit wird unter Kommunikationsaufgabe der zu vermittelnde Inhaltsaspekt von Kommunikation verstanden Kommunikationsmedien Es gibt eine Vielzahl an Kommunikationsmedien, welche die mittelbare Kommunikation ermöglichen. Mittelbare Kommunikation wird in Unternehmen oft auch als IKT-gestützte Kommunikation bezeichnet, wobei IKT für Informations- und Kommunikationstechnik steht. Krcmar definiert IKT in [Krc10, S. 30] wie folgt: Informations- und Kommunikationstechnik (IKT) ist die Gesamtheit der zur Speicherung, Verarbeitung und Kommunikation zur Verfügung stehenden Ressourcen sowie die Art und Weise, wie diese Ressourcen organisiert sind. Zu den Ressourcen der IKT gehören auch alle verfügbaren Kommunikationsmedien. Bei Kommunikationsmedien handelt es sich meist um technische Hilfsmittel, es existieren aber auch nicht technische Kommunikationsmedien, wie beispielsweise der klassische Brief. Eine weitere Möglichkeit zur Klassifikation von Kommunikationsmedien ist die Unterscheidung zwischen synchronen und asynchronen Kommunikationsmedien. Sowohl synchrone Kommunikationsmedien wie Telefon und Instant Messaging als auch asynchrone 10

29 2.1 Kommunikation im Unternehmen Kommunikationsmedien wie Mails und Internetforen haben laut Schick [Sch07] mehrere Vor- und Nachteile: Bei synchronen Kommunikationsmedien können die Kommunikationsteilnehmer auf Äußerungen anderer Kommunikationsteilnehmer reagieren und Feedback geben. Zudem besteht bei der Nutzung synchroner Medien die Möglichkeit, dass die Kommunikationsteilnehmer den Erfolg der Kommunikation direkt kontrollieren können. Es können leichter Emotionen vermittelt werden und Vertrauen sowie Vertraulichkeit aufgebaut werden. Nachteilig bei der Kommunikation über synchrone Kommunikationsmedien ist, dass diese Art der Kommunikation oft zeitaufwändig ist, die übermittelten Informationen nur schwer oder gar nicht archiviert werden können und die Qualität der Kommunikation stark von den Kommunikationsfähigkeiten der Kommunikationsteilnehmer abhängt. Große Vorteile asynchroner Kommunikationsmedien sind somit vor allem der geringere Zeitaufwand und die Archivierbarkeit der Kommunikation. Da es bei asynchroner Kommunikation schwerer ist, Emotionen zu übermitteln, eignet sie sich insbesondere für die Übermittlung des Inhaltsaspektes. Der Beziehungsaspekt der Kommunikation ist bei asynchroner Kommunikation deutlich schwerer zu übermitteln [Sch07]. Wahl des Kommunikationsmediums Bereits bei der Unterscheidung von synchronen und asynchronen Kommunikationsmedien wird deutlich, dass die einzelnen Kommunikationsmedien für unterschiedlich komplexe Kommunikationsaufgaben unterschiedlich gut geeignet sind. Picot, Reichwald und Wigand präzisieren diese Theorie in [PRW01, S. 106f]. Sie beschreiben die Wechselwirkung, die zwischen der Kommunikationsaufgabe, dem Kommunikationsmedium und der Kommunikation besteht: Die Aufgabe beeinflusst die Form der erforderlichen Kommunikationsaktivität. Im Gegenzug ist die Qualität des Ergebnisses der Aufgabe abhängig von der Kommunikation zwischen den verschiedenen Aufgabenträgern. Die Wahl des Kommunikationsmediums wird nun einerseits von der Art der jeweiligen Aufgabe (und somit auch von der erforderlichen Kommunikationsform) beeinflusst und andererseits hat sie selbst Einfluss auf die Erfüllung der Aufgabe und die Qualität des Kommunikationsprozesses. Es gibt verschiedene Theorien, die versuchen, den Einsatz und die Auswahl von bestimmten Kommunikationsmedien zu erklären. Eine Theorie ist die Media-Richness-Theorie von Daft und Lengel. Sie unterscheidet zwischen armen und reichen Kommunikationsmedien und beruht auf der Annahme, dass technische und nicht-technische Kommunikationsmedien unterschiedlich gut geeignet sind, analoge und digitale Informationen authentisch zu übertragen. Dementsprechend ist beispielsweise der Austausch von Dokumenten (Briefpost) eine arme Kommunikationsform mit einem niedrigen Media- Richness-Grad, während eine Videokonferenz einen sehr hohen Media-Richness-Grad besitzt. In einer Videokonferenz kommen ähnlich wie beim face-to-face-gespräch mehrere Kommunikationskanäle parallel zum Einsatz (Sprache, Tonfall, Mimik, Gestik), das Gegenüber kann direktes Feedback geben und es besteht die Möglichkeit, Emotionen zu übermitteln, die vom Kommunikationspartner direkt wahrgenommen werden können (vgl. [PRW01, S. 111ff]). 11

30 Niedrig Mittel 2 Theoretische Grundlagen Media Richness Face-to-Face Dialog Videokommunikation Telefon / Telefonkonferenz Overcomplication Mehrdeutigkeit, zu viele Nebeninformationen Voice Mail Instant Messaging Telefax Briefpost / Dokumentation Oversimplification Unpersönlich, kein Feedback Niedrig Mittel Hoch Komplexität der Aufgabe Abbildung 2.2: Das Media-Richness-Modell nach Daft und Lengel (nach [PRW01]) Abbildung 2.2 zeigt das von Daft und Lengel auf Grundlage empirischer Untersuchungen erstellte Media-Richness-Modell. Sie klassifizieren die unterschiedlichen Kommunikationsmedien nach ihrem Media-Richness-Grad und die zu erfüllenden Kommunikationsaufgaben nach ihrer Komplexität. Dementsprechend ist die richtige Wahl des Kommunikationsmediums abhängig von der Komplexität der zu erfüllenden Aufgabe. Ein Medium mit einem hohen Media-Richness-Grad ist somit nicht zwingend das beste Kommunikationsmedium. Der Einsatz reicher Kommunikationsmedien ist vielmehr umso effektiver, je komplexer die Aufgabe ist, während der Einsatz armer Kommunikationsmedien die Effektivität umso mehr steigert, je strukturierter die zugrunde liegende Aufgabe ist [PRW01, S. 112]. Wählt man jedoch ein Medium, mit einem hohen Media-Richness- Grad für eine Aufgabe geringer Komplexität, erschwert man sich die Lösung der Aufgabe (Overcomplication). Wählt man im Gegenzug ein Kommunikationsmedium mit niedrigem Media-Richness-Grad für eine sehr komplexe Aufgabe ist dies ebenfalls nicht angemessen, da die Komplexität der Aufgabe durch das gewählte Medium nicht vollständig übermittelt werden kann und die Aufgabe somit unangemessen vereinfacht wird (Oversimplification). Die Media-Richness-Theorie bezieht sich hauptsächlich auf die Angemessenheit eines Kommunikationsmediums in Abhängigkeit von einer Kommunikationsaufgabe. Sie versucht zu erklären, welche Medien für welche Art von Kommunikationsaufgabe genutzt 12

31 2.1 Kommunikation im Unternehmen werden sollten, um die Kommunikation möglichst effektiv zu gestalten. Hierbei ist nicht zu vergessen, dass der Nutzer der Kommunikationsmedien sein Medium nicht unbedingt nur nach dem Kriterium Effektivität auswählt, sondern seine Medienwahl noch durch weitere Einflussfaktoren beeinflusst werden kann. Die Theorie der subjektiven Medienakzeptanz nennt als Einflussfaktoren auf die Medienwahl den persönlichen Arbeitsstil und die Kommunikationspräferenzen des Einzelnen. Die Medienwahl hängt stark von dem individuell wahrgenommenen Nutzen und der wahrgenommenen Bequemlichkeit ab. Eine weitere Theorie, der Social-Influence-Ansatz, nennt als Einflussfaktor die Akzeptanz des Mediums im Umfeld des Kommunikationspartners [PRW01, S. 107]. Kommuniziert beispielsweise der Vorgesetzte ausschließlich per Mail und meidet Telefonate, so wird der Mitarbeiter auch bei komplexen Aufgaben eher eine Mail verfassen, als den Vorgesetzten anzurufen Unternehmensinterne Kommunikation Die unternehmensinterne Kommunikation ist einer von zwei Bereichen der Unternehmenskommunikation. Während die externe Kommunikation sich an die Umwelt des Unternehmens richtet (Lieferanten, Organisationen, Werbung, Public Relations, etc.), umfasst die interne Kommunikation sämtliche Kommunikationsvorgänge zwischen den Mitarbeitern eines Unternehmens. Sie lässt sich in formelle und informelle Kommunikation unterteilen und kann zwischen Mitarbeitern am gleichen Standort oder an unterschiedlichen Standorten stattfinden. Im letztgenannten Fall handelt es sich zwangsweise um mittelbare Kommunikation, während bei Mitarbeitern am selben Standort die Kommunikation sowohl mittelbar als auch unmittelbar stattfinden kann. Im Allgemeinen lässt sich sagen, dass ein großer Teil der unternehmensinternen Kommunikation IKT-gestützt ist. Formelle Kommunikation Bei der formellen Kommunikation handelt es sich um die geplante Kommunikation im Unternehmen, welche meist unabhängig von den einzelnen Personen organisiert ist. Zur formellen Kommunikation gehören zum einen sämtliche Kommunikationsprozesse, die im Rahmen eines definierten Geschäftsprozesses oder Kommunikationsflusses stattfinden, und zum anderen alle im Vorhinein geplanten Kommunikationsvorgänge (Besprechungen, geplante Telefonkonferenzen, etc.). Weitere Eigenschaften der formellen Kommunikation sind, dass sie oft dokumentiert ist bzw. sein muss und dass neben Zeitpunkt und Ort auch das Thema und der Ablauf der Kommunikation meistens im Vorhinein festgelegt werden bzw. durch organisatorische Vorgaben vorgegeben sind. Die Funktionen der formellen Kommunikation sind aufgabenbezogen (Informationsweitergabe, schnelleres Problemlösen, Koordination der Zusammenarbeit) [HvBBC99]. Informelle Kommunikation Als informelle Kommunikation wird sämtliche spontane, nicht geplante Kommunikation im Unternehmen bezeichnet. Sie findet zu einem zufälligen Zeitpunkt mit zufälligen Teilnehmern statt und wird meistens nicht dokumentiert. Im Gegensatz zur formellen Kommunikation handelt es sich um unstrukturierte Prozesse, welche nicht vorhersehbar und 13

32 2 Theoretische Grundlagen nicht wiederkehrend sind. Das Thema dieser Kommunikationsvorgänge wird meist nicht im Vorhinein festgelegt [HvBBC99]. In den letzten Jahren wurde immer stärker deutlich, dass informelle Kommunikation auf Grund ihrer sozialen Funktionen, wie z.b. der Teambildung oder dem Abgleich von Interessensgebieten, einen großen Beitrag zum Unternehmenserfolg leisten kann. Die Motivation und Arbeitsleistung von Mitarbeitern können durch soziale Einflussfaktoren, wie z.b. ein angenehmes Arbeitsklima durch freundlichen Umgang der Mitarbeiter untereinander, verbessert werden. Zusätzlich zu den sozialen Aspekten werden im Rahmen informeller Kommunikationsvorgänge auch oft konkrete inhaltliche Informationen übermittelt [BSvBS97], welche den Mitarbeiter beim erfolgreichen Abschluss von Aufgaben und Geschäftsprozessen helfen. Ziele der unternehmensinternen Kommunikation Die unternehmensinterne Kommunikation hat als Teilbereich der Unternehmenskommunikation einen substanziellen Beitrag zur Umsetzung von Vision, Mission, Zielen und Strategien im Unternehmen zu leisten [Sch07, S. 9]. Die Ziele für die formelle interne Unternehmenskommunikation werden aus den übergeordneten Unternehmenszielen abgeleitet. So lassen sich ähnlich wie für Geschäftsprozesse auch quantitative und qualitative Ziele für fest definierte Kommunikationsprozesse bestimmen. Im Bereich der informellen Kommunikation ist dies allerdings nicht möglich, da die Kommunikation oft spontan und ohne vorher festgelegtes Ziel stattfindet. Dennoch hat natürlich auch jeder informelle Kommunikationsprozess ein Ziel. Dieses ist jedoch meist nicht quantitativ zu erfassen und ist für jeden Kommunikationsvorgang unterschiedlich. Ein Ziel eines informellen Kommunikationsvorgangs im Unternehmen kann sowohl ein Arbeitsziel als auch ein persönliches Ziel sein. Mögliche Ziele sind beispielsweise das Abschließen eines Kompromisses, der Hinzugewinn von Informationen oder die Herstellung eines Kontaktes. Oft weiß nur jeder einzelne Kommunikationsteilnehmer, welches Ziel er mit der Kommunikation verfolgt. Es ist sogar möglich, dass der Kommunikationsteilnehmer sein Ziel nur unbewusst verfolgt. Die verschiedenen Kommunikationsteilnehmer können unterschiedliche Ziele für den gleichen informellen Kommunikationsvorgang haben. Die Ziele von informeller Kommunikation im Unternehmen sind somit meist durch qualitative Aspekte bestimmt und stark subjektiv Effiziente Kommunikation im Unternehmen Zur Effizienz von Kommunikation Der Begriff Effiziente Kommunikation (oder Kommunikationseffizienz ) begegnet einem sehr häufig in den Bereichen der Kommunikation, Kommunikationstechnik und Kommunikationssysteme. Dennoch handelt es sich um keinen wohldefinierten Begriff. Ein Grund hierfür ist sicherlich, dass allein schon der Begriff Kommunikation sehr unterschiedlich definiert werden kann. Ausgehend von einem allgemeinen Verständnis von Effizienz und dem in dieser Arbeit verwendetem Verständnis von Kommunikation, wird im Folgenden erläutert, was im Rahmen dieser Arbeit unter effizienter Kommunikation verstanden wird. 14

33 2.1 Kommunikation im Unternehmen Effizienz Im Unterschied zur Effektivität ( Die richtigen Dinge tun ) geht es bei der Effizienz darum, die Dinge richtig zu tun. Nach der ISO-Norm 9000:2000 beschreibt sie das Verhältnis zwischen dem erreichten Ergebnis und den eingesetzten Ressourcen. In vielen Fällen entspricht die Effizienz somit der Wirtschaftlichkeit (Verhältnis Input zu Output, Leistung zu Kosten). Bei dem Versuch, die ISO-Norm 9000 auf Kommunikation zu beziehen, wird schnell deutlich, dass zunächst einmal die Begriffe eingesetzte Ressourcen und erreichtes Ergebnis von Kommunikation geklärt werden müssen: Im Bereich der unternehmensinternen Kommunikation und aufbauend auf dem dieser Arbeit zugrunde liegenden Verständnis von Kommunikation liegt es nahe, die für die Kommunikation verwendeten Kommunikationsmedien und den benötigten Zeitaufwand der Kommunikationsteilnehmer als eingesetzte Ressourcen zu betrachten. Im Bereich der unmittelbaren Kommunikation entsprechen die eingesetzten Ressourcen dementsprechend nur dem Zeitaufwand (Arbeitsstunden) der Kommunikationsteilnehmer. Der Output ( erreichtes Ergebnis ) von Kommunikation ist wesentlich schwerer zu bestimmen. Ein Ansatzpunkt ist, dass das erreichte Ergebnis in jedem Fall in Zusammenhang mit den Kommunikationszielen stehen muss. So wäre zum Beispiel der Grad der Erreichung der mit der Kommunikation verfolgten Ziele eine mögliche Messgröße für den Output. Die Kommunikationsziele sind aber, wie in Abschnitt beschrieben, zumindest im Bereich der informellen Kommunikation, stark subjektiv und nicht allgemein definierbar. Deshalb wäre die exakte Messung eines solchen Wertes in der Praxis schwierig. Da der Input von Kommunikation wesentlich genauer bestimmt werden kann als der Output und zudem die Vielfalt an Kommunikationsmedien im Unternehmen (=Ressourcen) immer weiter zunimmt, bietet es sich an, sich bei der Betrachtung von Effizienz auf den Input von Kommunikation zu konzentrieren. Bei gleich bleibendem Output gilt, dass, wenn der Input verkleinert wird, sich die Effizienz erhöht. Als Input wurde im vorherigen Abschnitt das verwendete Kommunikationsmedium und der benötigte Zeitaufwand festgelegt. Je weniger Zeit benötigt wird, desto effizienter wird die Kommunikation. Das Kommunikationsmedium spielt eine entscheidene Rolle bei der Beschleunigung der Kommunikation, da die benötigte Zeit für die Kommunikation auch von dem gewählten Medium abhängt. Basierend auf dieser Diskussion und auf Grund der nicht vorhandenen Definition von effizienter Kommunikation wird in dieser Arbeit effiziente Kommunikation hauptsächlich als effiziente Nutzung von Kommunikationsmedien betrachtet. Effiziente Nutzung der Kommunikationsmedien Die Zahl der Kommunikationsmedien im Unternehmen hat in den letzten Jahren stetig zugenommen. Einem Mitarbeiter stehen meist mehrere Kommunikationsmedien zur Verfügung. Diese Kommunikationsmedien eignen sich unterschiedlich gut für die Unterstützung einzelner Kommunikationsaufgaben bzw. zur Erreichung von Kommunikationszielen. Die Wahl des Kommunikationsmediums beeinflusst den Ablauf und vor allem die Dauer des Kommunikationsvorganges sowie das Ergebnis der Kommunikation und hat somit einen entscheidenden Einfluss auf die Effizienz der Kommunikation. Es gibt verschiedene Ansätze, die versuchen zu erklären, welches Medium für welche Kommu- 15

34 2 Theoretische Grundlagen nikationsaufgabe am besten geeignet ist (vgl. Abschnitt 2.2). Die bereits erwähnte Media- Richness-Theorie bezieht sich zwar hauptsächlich auf die Effektivität von Kommunikation, jedoch sind die Einflussfaktoren durchaus auch für die Effizienz von Kommunikation relevant. Zusammenfassend lässt sich sagen, dass die Wahl des Kommunikationsmediums von der jeweiligen Aufgabe (formelle Kommunikation) bzw. dem persönlichen Kommunikationsziel (informelle Kommunikation) abhängig gemacht werden sollte. Die Erfüllung einer Kommunikationsaufgabe kann je nach gewählten Kommunikationsmedium unterschiedlich zeitaufwändig sein. Desweiteren können jedoch auch weiche Faktoren, wie z.b. der Zeitpunkt oder die Akzeptanz des Kommunikationsmediums im Umfeld des Kommunikationsteilnehmers die Wahl des Kommunikationsmediums beeinflussen. Zwar lässt sich für bestimmte Kommunikationsprozesse der formellen Kommunikation eindeutig bestimmen, welches Medium den Prozess am besten unterstützt, und so werden in Unternehmen oft auch Vorgaben bzgl. der Medienwahl für einige Kommunikationsprozesse gemacht, jedoch ist dies insbesondere im Bereich der informellen Kommunikation kaum möglich. In diesem Bereich lässt sich die Effizienz der genutzten Kommunikationsmedien auf Grund der unterschiedlichen Ziele informeller Kommunikation nicht einfach bestimmen. Vielmehr bestimmt der Kommunikationsteilnehmer durch seine subjektive Wahrnehmung, ob er den Kommunikationsvorgang mit dem gewählten Kommunikationsmedium als effizient empfunden hat oder nicht. Ursachen ineffizienter Kommunikation Berlecon Research hat leitende Angestellte von großen Unternehmen nach der Effizienz der Unternehmenskommunikation befragt [Ber08]. Als Ursachen für die ineffiziente Kommunikation im Unternehmen wurden unter anderem folgende Punkte angesprochen: Die häufigste Ursache ineffizienter Kommunikation ist das Fehlen von Funktionalitäten für den Benutzer, sobald dieser unterwegs, d.h. nicht an seinem Arbeitsplatz, ist. Diese fehlenden Funktionalitäten verursachen, dass viele Mitarbeiter ihre Kommunikation als nicht effizient wahrnehmen. Eine weitere häufig genannte Ursache ist die hohe Anzahl vergeblicher Kontaktversuche. Um herauszufinden, ob ein Ansprechpartner gerade erreichbar ist, müssen oft mehrere Telefonate geführt werden. Dies nimmt viel Zeit in Anspruch, die auch sinnvoller genutzt werden könnte. Ein weiteres Hindernis für effiziente Kommunikation ist die Vielzahl und Komplexität der Anwendungen und Endgeräte. Hier wird im Besonderen die nicht intuitive Bedienbarkeit der Kommunikationsmedien thematisiert. Zudem sind sich einige Mitarbeiter nicht aller unterstützten Funktionalitäten der Medien bewusst. Weitere Ursachen der ineffizienten Kommunikation sind das Fehlen des visuellen Kontaktes mit den Kommunikationspartnern, das Heraussuchen und Eingeben von Kontaktinformationen, der häufige Wechsel zwischen Anwendungen und Endgeräten, die fehlende Anbindung von Mitarbeitern im Home-Office und das immer größer werdende Mailaufkommen. Daneben wünschen sich viele Anwender eine Art Nutzungsrichtlinie, welche allgemeine Verhaltensregeln für die Nutzung der Kommunikationsmedien vorschlägt (z.b. welches Medium für welchen Anlass/Gesprächspartner) Kommunikationsanalyse Die Untersuchung der Kommunikationsprozesse (formelle Kommunikation) im Unternehmen wird als Kommunikationsanalyse bezeichnet. Das Ziel der Kommunikationsana- 16

35 2.1 Kommunikation im Unternehmen lyse ist es, Ineffizienzen und offensichtliche sowie verdeckte Störungen der Kommunikation aufzudecken. Bei einer offensichtlichen Störung sind sich die Kommunikationsteilnehmer der Störung bewusst und sie wissen, dass das gewünschte Ergebnis nicht erzielt wurde. Eine verdeckte Störung hingegen wird von allen oder einigen Kommunikationsteilnehmern nicht als Störung wahrgenommen, wie es beispielsweise bei Missverständnissen der Fall ist. Um dieses Ziel zu erreichen, ist es wichtig, hierarchisch und organisatorisch geprägte Kommunikationsrichtungen und qualitative sowie quantitative Einflussfaktoren der Kommunikation zu untersuchen [Kom]. Da Änderungen im Kommunikationsverhalten der Mitarbeiter sich in der Regel nicht direkt auf das Betriebsergebnis auswirken, sondern erst mit einer zeitlichen Verzögerung Wirkung zeigen, ist es wichtig, eventuelle Kommunikationsstörungen und Ineffizienzen frühzeitig zu erkennen, so dass diese behoben werden können, bevor sie ihren negativen Einfluss auf das Betriebsergebnis ausüben können. Eine Methode zur frühzeitigen und gezielten Erkennung von Veränderungen ist die Mitarbeiterbefragung. Ein Beispiel für eine wissenschaftlich fundierte Kommunikationsanalyse durch Mitarbeiterbefragung ist KomminO. KomminO ist ein Werkzeug, welches die interne Kommunikation in formalen Organisationen (Unternehmen mit Organisationsstruktur, öffentliche Verwaltung) erfassen soll. KomminO setzt dabei stark auf die subjektive Beurteilung der Kommunikationsprozesse durch die Mitarbeiter. Es wird ein Fragebogen verwendet, der die verschiedenen Aspekte der Kommunikation mit dem Vorgesetzten, den Kollegen und bei Führungskräften auch den unterstellten Mitarbeitern erhebt [SR]. Hierbei werden die folgenden sieben Aspekte der Kommunikation überprüft: 1. Bedeutung der Kommunikation: Für wie wichtig hält der Befragte die Kommunikation mit bestimmten Personengruppen für die Erledigung der eigenen Aufgaben? 2. Kommunikationsqualität: Wie beurteilt der Befragte die Qualität der Kommunikation mit bestimmten Personengruppen? 3. Verwertbarkeit der Informationsmenge: Erhält der Befragte eine brauchbare und verwertbare Menge oder eine zu große Menge an Informationen? 4. Vertrauen in den Kommunikationspartner: Vertraut der Befragte seinen Kommunikationspartnern und geht er davon aus, dass die von ihm weitergegebenen Informationen nicht zu seinem Nachteil verwendet werden? 5. Feedback: Erhält der Befragte von den unterschiedlichen Personengruppen Rückmeldung zu seinem Kommunikationsverhalten? 6. Informationsweitergabe - Umfang: Gibt der Befragte oft umfassende Informationen mit vielen Einzelheiten oder eher komprimierte Informationen weiter? 7. Informationsweitergabe - Kanaloffenheit: Kann der Befragte Informationen ohne Hindernisse und rechtzeitig an Mitarbeiter weitergeben? Durch die Anwendung von KomminO kann ein Gesamtbild der organisationsinternen Kommunikation inklusive der verschiedenen Organisationseinheiten und Kommunikationsrichtungen erstellt werden. Mit KomminO kann die Qualität der formellen (und teilweise der informellen) Kommunikation zwischen Mitarbeitern des Unternehmens analy- 17

36 2 Theoretische Grundlagen siert werden. Es werden jedoch keinerlei quantitative Merkmale oder Merkmale zur Nutzung verschiedener Kommunikationsmedien erhoben. 2.2 Unified Communications In diesem Unterkapitel werden das theoretische Konzept von Unified Communications und die praktische Umsetzung in Form von Unified Communications Systemen vorgestellt. Zudem werden die Potenziale und Herausforderungen von Unified Communications diskutiert Konzept Der Begriff Unified Communications (kurz: UC) kommt aus dem Englischen und bedeutet vereinheitlichte Kommunikation, wird aber oft auch mit integrierter Kommunikation übersetzt. UC und UC-Systeme sind ein aktueller Trend der Kommunikationstechnik. Das Ziel von Unified Communications ist es, durch eine Zusammenlegung aller Kommunikationsdienste und eine Integration mit Präsenzfunktionen und Unternehmenssoftware, die Erreichbarkeit von Kommunikationspartnern bei verteilter Arbeit zu verbessern und so geschäftliche Prozesse zu beschleunigen [PRT08]. Jeder Mitarbeiter soll von jedem Ort aus auf jedem Gerät kommunizieren können und dabei die Anwendungen einsetzen können, die sich im jeweiligen Stadium des Kommunikationsvorganges am besten eignen Motivation und Hintergrund Die Komplexität der Kommunikation in Unternehmen hat in den letzten Jahren bedeutend zugenommen. Das Kommunikationsvolumen pro Mitarbeiter ist angestiegen und die Vielfalt der zur Verfügung stehenden Kommunikationsmedien hat sich vergrößert [Ber08]. Zudem hat sich die organisatorische Struktur von Unternehmen geändert. Die Internationalisierung und das vermehrte Eingehen von Kooperationen mit externen Partnern führen dazu, dass viele Mitarbeiter über zeitliche, geografische und organisatorische Grenzen hinweg mit anderen Personen zusammenarbeiten und kommunizieren müssen. Bei dieser verteilten Teamarbeit sind die Hauptherausforderungen das Management der teaminternen Kommunikation und die schlechte Erreichbarkeit der Teammitglieder. Oft fehlt das Wissen, ob und wie andere Teammitglieder erreichbar sind, und es werden mehrere Versuche (mit verschiedenen Kommunikationsmedien) benötigt, bis ein Teammitglied erreicht wird. Auf Grund all dieser Entwicklungen wuchs die Nachfrage nach einer besseren Nutzungsmöglichkeit der Kommunikationsmedien im Unternehmen. Auf Anbieterseite waren die Treiber zur Entwicklung von UC-Systemen einerseits die Fortschritte in der Übertragungstechnologie und die Entwicklung softwarebasierter Kommunikationsmedien. Andererseits beeinflussten weitere Trends, wie der Trend zu IP-basierten Infrastrukturen und zur Konvergenz der Telekommunikation, Informationstechnologie und Unternehmenssoftware die Entwicklung von UC-Systemen (vgl. [Krc10] und [Ber08]). 18

37 2.2 Unified Communications Unified Communications-Systeme UC-Systeme setzen das Konzept von Unified Communications um, indem sie traditionelle und neue Kommunikationsmedien, wie , Voice-over-IP Telefonie und Endgeräte mit Präsenzinformationen und Unternehmenssoftware, wie ERP-oder CRM-Systemen integrieren [Krc10]. Sie sind aus der Konvergenz der Informations- und Kommunikationstechnologie entstanden. Kernmodule Nach [PRT08] und [RT09] sind für die vollständige Umsetzung von Unified Communications in einem Unternehmen mehrere Module notwendig. Diese Module lassen sich wiederum zwei Hauptkomponenten von UC-Systemen zuordnen. Es ist möglich, die einzelnen Module schrittweise zu implementieren. So müssen die Unternehmen nicht von heute auf morgen ihre aktuelle Kommunikationstechnik ersetzen, sondern können sich langsam einem vollständigen UC-System annähern. Mit jedem weiteren implementierten Modul erhöht sich das Potenzial des UC-System, jedoch steigen auch die Kosten an. Die Module und Komponenten sind in Abbildung 2.3 grafisch dargestellt und werden im Folgenden näher erläutert. Medien und Infrastruktur UC System Medienunabhängige und medienübergreifende Dienste Kommunikationsmedien Fixed-Mobile- Convergence Collaboration Tools Voice-over-IP + Endgeräte Präsenzsignalisierung Kontexteinbettung Medienintegration Abbildung 2.3: Module eines UC-Systems (eigene Darstellung) 19

38 2 Theoretische Grundlagen Voice-over IP / IP-Infrastruktur + Endgeräte Voice-over-IP (VoIP), d.h. die Übertragung von Sprache über IP-Infrastruktur und die Bereitstellung von entsprechenden Endgeräten (z.b. VoIP-Telefone, Softclients), ist die Grundlage für ein UC-System. VoIP erweitert oder ersetzt die traditionelle Telefonie im Unternehmen. Dieses Modul ist für den physischen Datentransport verantwortlich und besteht aus Hardware- und Softwarekomponenten. Kommunikationsmedien Zu diesem Modul zählen alle Kommunikationsmedien, die nicht auf der VoIP-Technologie basieren, wie beispielsweise , Instant Messaging und Mobiltelefone. Jedes Unternehmen kann frei entscheiden, wie viele verschiedene und welche Kommunikationsmedien den Mitarbeitern zur Verfügung gestellt werden. Fixed-Mobile-Convergence Unter Fixed-Mobile-Convergence (FMC) wird die Einbindung von mobilen Endgeräten (z.b. über die firmeninternen WLAN-Netze) verstanden. Fest- und Mobilfunknetze sollen zusammenwachsen, d.h. dass der Anwender sein Endgerät an jedem Ort benutzen kann und gleiche bzw. ähnliche Funktionen wie an seinem Arbeitsplatz zur Verfügung hat. Medienintegration Bei der Medienintegration werden alle Kommunikationsmedien und Endgeräte unter einer logischen, IP-basierten Steuerungsschicht zusammengefasst, die ein regelbasiertes Management von Kommunikationvorgängen und einen zentralen Zugriff auf alle Nachrichten ermöglicht. Dieses regelbasierte Managementsystem unterstützt den Anwender bei der Verwaltung und der Auswahl der für die jeweilige Kommunikationssituation geeigneten Medien. Zu diesem Modul gehören Funktionen wie die regelbasierte Anrufweiterleitung und das One-Number-Concept. So werden z.b. eingehende Kommunikationsvorgänge automatisch entsprechend den definierten Regeln auf die vom Anwender bevorzugten und gerade verfügbaren Endgeräte weitergeleitet. Die zugrunde liegenden Weiterleitungsregeln können sehr komplex sein und unter anderem vom Kommunikationspartner, der Tageszeit oder dem aktuell verwendeten Endgerät abhängen. Jeder Nutzer hat zudem nur eine einzelne Rufnummer und ist unter dieser auf sämtlichen Endgeräten erreichbar (One-Number-Concept). Präsenzsignalisierung Die Präsenzsignalisierung umfasst Funktionen zum Management der eigenen Verfügbarkeit und zur Übermittlung des eigenen Verfügbarkeitsstatus an einen ausgewählten Personenkreis. Die Signalisierung des Präsenzstatus ist wesentlich umfangreicher als bei normalen Instant-Messaging Programmen. So kann der Präsenzstatus beispielsweise auf Geräteebene ermittelt, auf Gruppenebene aggregiert und in bereits integrierten Softwareprogrammen angehangen werden. Collaboration Tools Collaboration Tools sind Anwendungen zur Unterstützung der Zusammenarbeit von räumlich und zeitlich getrennten Teams durch Sprachkonferenzfunktionen, die synchrone Nutzung von Anwenderprogrammen, einen gemeinsamen Kalender oder eine gemeinsame Dokumentenverwaltung. Beispiele für Collaboration Tools sind Web Conferencing, Whiteboards und Application Sharing. 20

39 2.2 Unified Communications Kontexteinbettung Unter der Kontexteinbettung wird die Einbettung der UC-Funktionalitäten in den Arbeitskontext der Anwender, d.h. in die Unternehmensprozesse und Drittanwendungen, wie ERP- und CRM-Systeme, verstanden. Hierzu gehört beispielsweise das Anhängen von Präsenzinformationen an beliebige Objekte in Drittanwendungen oder die direkte Initiierung von Kommunikation aus einer Drittanwendung heraus. (vgl. [PRT08] und [RT09]) Anbieter von UC-Systemen Die Anbieterlandschaft im Bereich Unified Communications ist sehr heterogen. Viele Unternehmen bieten nur Teilkomponenten eines UC-Systems an. Somit wird der Markt einerseits durch Wettbewerb beherrscht, andererseits sind die Unternehmen teilweise auch auf eine Kooperation untereinander angewiesen. Die Anbieter kommen aus Bereichen mit verschiedenen technischen Hintergründen. Bekannte Anbieter von UC-Systemen aus dem Bereich der Desktop-Anwendungen sind IBM und Microsoft. Alcatel-Lucent, Avaya und Siemens kommen aus dem Bereich der Kommunikationsinfrastruktur. Ein weiterer Anbieter, Cisco Systems, kommt aus dem Bereich der Netzinfrastruktur. Mittlerweile werden UC-Systeme auch von Netzbetreibern, wie beispielsweise der Deutschen Telekom, als Hosting-Lösung angeboten. Microsoft und Cisco sind zwei der größten Anbieter von UC-Lösungen. Bei beiden Anbietern setzt sich die vollständige UC-Lösung aus mehreren Komponenten zusammen. Bei Microsoft ist der zentrale Bestandteil der Microsoft Office Communications Server (OCS). Er bietet Präsenzinformationen, Instant Messaging (mit dem Office Communicator), Konferenzfunktionen (Audio, Video, Web) und VoIP-Funktionen. Eine weitere Komponente ist der Microsoft Exchange Server, welcher Funktionen für den -Verkehr, den Kalender und die Kontaktverwaltung bietet. Weitere Komponenten der Microsoft UC-Lösung sind beispielsweise die Endgeräte. Microsoft bietet auch eine Cloud-Version seiner UC- Produkte mit leicht eingeschränktem Funktionsumfang an (Microsoft Office Communications Online, Microsoft Exchange Online, Microsoft Office Live Meeting). Für ein Cisco UC-System ist die Kommunikationsinfrastruktur, bestehend aus Routern, Switches, Voice Gateways, Voice Servers etc., grundlegend. Weitere Komponenten sind die Cisco-IP-Telefone und die Unified Communications Anwendungen. Die zentrale Unified Communications Anwendung von Cisco ist der Call Manager, weitere Anwendungen sind beispielsweise Cisco Unified Presence, Cisco Unified Personal Communicator und das Cisco Unified Contact Center Potenzial und Nutzen Grundsätzlich sollen UC-Systeme die Effizienz der Kommunikation im Unternehmen erhöhen, indem die Ursachen ineffizienter Kommunikation behoben werden (vgl. Abschnitt 2.1.4). In Anlehnung an [RT09] können die Potenziale von Unified Communications an Hand von vier verschiedenenen Bereichen klassifiziert werden. 21

40 2 Theoretische Grundlagen Organisation Unified Communications ermöglicht neue Organisationsformen, da verteilte Kommunikation (1:1 oder Konferenz/Teamarbeit) in einem Maße unterstützt wird, wie es vorher nie der Fall war. Dadurch wird zum Beispiel die standortübergreifende Zusammenarbeit von Mitarbeitern stark unterstützt und beschleunigt. Insbesondere durch die Collaboration Tools (Application Sharing, gemeinsame Arbeit an Dokumenten) und deren Integration mit Präsenzinformationen und Geschäftsprozessen kann die Aufgabenverteilung in Teamarbeiten deutlich effizienter gestaltet werden. Zudem ist durch die Videokommunikation eine viel persönlichere Kommunikation auf Distanz möglich geworden. In vielen Fällen kann nun ein vorher noch unabdingbares persönliches Treffen durch Videotelefonat oder -konferenz ersetzt werden. Auch die mobile Kommunikation wird durch UC gestärkt. Mitarbeiter, die sich auf einer Geschäftsreise oder im Home-Office befinden, haben eine bessere Anbindung über Kommunikationsmedien und durch ihren Präsenzstatus können unnötige Unterbrechungen durch eingehende Kommunikation vermieden werden. Gruppen und Prozesse Unified Communications ermöglicht neue Arbeitsroutinen. So können beispielsweise die Mitglieder verteilter Teams differenziert miteinander kommunizieren und vielfältige neue Technologien wie Application Sharing oder eine gemeinsame Dokumentenverwaltung nutzen. Auch hier erhöht insbesondere die Verknüpfung dieser Technologien mit Präsenzinformationen das Potenzial. So kann vor der Initiierung einer Gruppenarbeit sichergestellt werden, dass alle Teilnehmer wirklich verfügbar sind. Sollte dies nicht der Fall sein, kann durch den gemeinsamen Team-Kalender der nächstmögliche, für alle Gruppenteilnehmer mögliche Termin gefunden werden. Durch Unified Communications können zudem einige Geschäftsprozesse neu definiert und verbessert werden. Ein Beispiel für einen solchen Geschäftsprozess ist der Genehmigungsprozess von Anträgen. Dieser kann nun dynamisch und in Abhängigkeit des Präsenzstatus der Personen einer Genehmigungsstufe gestaltet werden. Somit kann vermieden werden, dass dringende Anträge auf Grund von Abwesenheit einzelner Personen nicht schnellstmöglich bearbeitet werden. So kann immer der aktuell schnellste Genehmigungsweg ermittelt werden. Individuell Neben dem Nutzen und den Potenzialen von Unified Communications für das Unternehmen bzw. für verteilte Kommunikation gibt es natürlich auch Potenziale für den individuellen Anwender. Sie können aktiv ihren eigenen Präsenzstatus und ihre Kommunikationsmedien verwalten. Der Benutzer kann selbst entscheiden, wer ihn wann kontaktieren darf und mit welchem Medium er die eingehende Kommunikation annimmt. Dadurch können unerwünschte Störungen durch eingehende Kommunikation minimiert werden und der Anwender kann mehr Zeit für seine eigentliche Arbeit nutzen. Zudem steigert sich die Erreichbarkeit des Anwenders. Seine Kommunikationspartner wissen genau, wann sie ihn erreichen können und verschwenden keine Zeit für unnötige Kontaktversuche. Der Anwender ist mit einem voll integrierten UC-System selbst in der Lage, seine Kom- 22

41 2.2 Unified Communications munikationsaktivitäten möglichst effizient zu gestalten, indem er das beste Kommunikationstool für die jeweilige Aufgabe wählt und somit die Funktionalitäten des UC-Systems richtig nutzt. Infrastruktur Auf der Ebene der technischen Infrastruktur zählen vor allem die Kostenvorteile durch einen Wechsel zu IP-basierten Infrastrukturen zu den großen Potenzialen von UC. Zudem wird durch einheitliche VoIP-basierte Firmennetzwerke und Kommunikationskanäle die Komplexität der vorhandenen Kommunikationstechnik reduziert. Zusammenfassend lässt sich sagen, dass der maximale Unternehmensnutzen einer Unified Communications Lösung nur erzielt werden kann, wenn einerseits die technische Implementierung und Integration des Systems funktioniert und andererseits das System von den Mitarbeitern richtig genutzt und akzeptiert wird und sie mit dem System zufrieden sind. Alle im vorhergehenden Abschnitt erläuterten Potenziale können nur realisiert werden, wenn die Mitarbeiter das UC-System mit seinem vollen Funktionsumfang nutzen. Somit besteht eine große Herausforderung bei der Einführung eines UC-Systems in einem Unternehmen darin, den Mitarbeitern das System näher zu bringen und Akzeptanz für das System im Unternehmen zu schaffen. Auf weitere Herausforderungen wird im folgenden Abschnitt näher eingegangen Herausforderungen Neben dem großen Potenzial von Unified Communications gibt es natürlich auch Herausforderungen, insbesondere bezüglich der Implementierung eines UC-Systems. Auch die Herausforderungen lassen sich nach [RT09] in die bereits genannten vier Bereiche einordnen. Organisation Bei der Einführung eines Unified Communications Systems in einem Unternehmen besteht eine große Herausforderung darin, die Einführung ausreichend zu kommunizieren und das UC-System in die existierende Kommunikationskultur einzubetten. Die Mitarbeiter müssen über die Einführung des neuen Systems mit all seinen Funktionen und Möglichkeiten informiert sein. Zudem müssen organisationsinterne Regeln für die Nutzung des neuen Systems erarbeitet und kommuniziert werden. Gruppen und Prozesse Durch die vielseitigen Möglichkeiten, welche die Collaboration Tools eines UC-Systems bieten, brauchen die Anwender Zeit und Unterstützung für das Testen und Ausprobieren des Systems. Nur wenn der Nutzer das System kennt und beherrscht, kann er es erfolgreich verwenden. Diese Zeit fehlt den Anwendern jedoch oft und so kommt es meist 23

42 2 Theoretische Grundlagen nicht zu einem richtigen Kennenlernen des Systems. Die durch die Einführung des UC- Systems neugestalteten Geschäftsprozesse müssen von den Mitarbeitern verstanden und akzeptiert werden. So ist auch im Bereich der Gruppenkommunikation und Geschäftsprozesse eine Schulung der Mitarbeiter und eine gute Kommunikation der Potenziale von UC notwendig. Individuell Auch im Bereich des individuellen UC-Nutzers muss dieser für den Umgang und den Nutzen von UC sensibilisiert werden. Der UC-Nutzer muss bereit sein, sich mit dem System auseinanderzusetzen und es zu erlernen. Ist dieser Wille nicht vorhanden, kann das UC-System seinen Nutzen nie ganz entfalten. Außerdem muss dem Nutzer die Angst vor der Präsenzsignalisierung genommen werden. Viele Nutzer befürchten durch den Präsenzstatus z.b. von ihren Vorgesetzten überwacht zu werden. Infrastruktur Eine vollständige Migration vom aktuellen Kommunikationssystem zu einer IP-basierten Infrastruktur muss sehr gut geplant werden. So kann die technische Integration von Altsystemen und bestehenden Kommunikations-Endgeräten zu Problemen führen. Auch die Integration von Komponenten und Endgeräten verschiedener Anbieter kann Schwierigkeiten bereiten. (vgl. [RT09]) Zusammenfassend lässt sich sagen, dass die beiden größten Herausforderungen bei der Einführung von Unified Communicatons die erfolgreiche technische Implementierung sowie die Motivation der Mitarbeiter, das neue System zu erlernen und effizient zu nutzen, sind. Zudem darf nicht vergessen werden, dass die Einführung eines UC-Systems auch mit hohen Kosten verbunden ist UC in deutschen Unternehmen Aus einer Studie von Berlecon [Ber09] zum aktuellen Stand (April 2009) von Unified Communications in deutschen Unternehmen geht hervor, dass sich die Mehrheit deutscher Unternehmen (79%) intensiv mit UC beschäftigt. Mehr als die Hälfte aller Unternehmen hat UC bereits umgesetzt bzw. plant die Umsetzung innerhalb der nächsten Monate. Nur für jedes fünfte Unternehmen ist UC derzeit kein Thema. Bei den großen Unternehmen fällt die Bilanz sogar noch positiver aus: UC wurde in 60% der großen Unternehmen bereits umgesetzt und ist bei nur 6% noch kein Thema. Trotz der bereits weitreichenden Umsetzung des UC-Konzeptes in deutschen Unternehmen ist der Bereich der Anwendungsintegration bisher vernachlässigt worden. So haben 50% der Unternehmen, für die UC relevant ist, die Integration in Unternehmenssoftware bisher weder umgesetzt noch geplant. 24

43 Teil II Unified Communications Management Cockpit 25

44

45 3 Anforderungsanalyse In diesem Kapitel werden die Anforderungen an das Unified Communications Management Cockpit (UCMC) erhoben. Dabei werden zunächst die Anwendungsbereiche und Zielgruppen der Anwendung bestimmt. Im Anschluss werden alle weiteren Anforderungen erhoben und es wird nach [GBBK10] zwischen funktionalen und nichtfunktionalen Anforderungen unterschieden. 3.1 Produkteinsatz: Anwendungsbereiche und Zielgruppen Das Unified Communications Management Cockpit soll ein Monitoring der unternehmensinternen, mittelbaren Kommunikation ermöglichen. Es richtet sich an Unternehmen, welche ein Unified Communications System verwenden und die an einer Quantifizierung des Nutzens des Systems interessiert sind. In diesen Unternehmen hat Kommunikation einen hohen Stellenwert und effiziente Kommunikation wird als wichtiger Erfolgsfaktor angesehen. Wie bereits in Kapitel erläutert, haben Unified Communications Systeme ein sehr großes Potenzial in verschiedenen Bereichen. Oft wird das Potenzial durch die vielfältigen Funktionalitäten und Möglichkeiten von Unified Communication Systemen begründet. Die zwei wichtigsten Erfolgsfaktoren eines UC-Systems sind die technische Implementierung und die Nutzung und Akzeptanz des Systems durch die Mitarbeiter. Während ersteres sehr leicht überprüft werden kann, ist letzteres schwer festzustellen. Das UCMC soll nun die Nutzung des UC-Systems visualisieren und somit einen Ausgangspunkt zur Analyse der Nutzung und Akzeptanz des Systems sowie zur Identifikation von Verbesserungspotenzialen bieten. Eine Zielgruppe des UCMC sind Mitarbeiter auf Managementpositionen (UC Manager). Sie haben die Möglichkeit, die gesamte Nutzung des UC-Systems im Unternehmen bzw. ihrer Abteilung zu analysieren, mögliche Optimierungspotenziale zu identifizieren und gegebenenfalls Handlungsempfehlungen für die Nutzer des UC-Systems abzuleiten. Eine weitere Zielgruppe sind die Nutzer des UC-Systems (UC User). Sie können mit Hilfe des UCMC ihr eigenes Kommunikationsverhalten untersuchen und gegebenenfalls optimieren. Für die Nutzung des UCMC werden vom UC Manager und UC User Basiskenntnisse im Umgang mit Computern und Büroanwendungen vorausgesetzt. Daneben werden keine weiteren besonderen Fähigkeiten oder Kenntnisse erwartet. Jeder Mitarbeiter, der im normalen Arbeitsalltag mit Rechnern zu tun hat, soll keinerlei Schwierigkeiten bei der Verwendung des UCMCs haben. Vom Administrator werden ein gutes technisches Verständnis und Erfahrungen im Bereich Datenbanken erwartet. Er muss zudem bereit sein, sich näher mit der Applikation auseinanderzusetzen, um die Datenbankinhalte aktualisieren und Benutzeranfragen bearbeiten 27

46 3 Anforderungsanalyse zu können. 3.2 Funktionale Anforderungen In diesem Abschnitt werden die funktionalen Anforderungen an das System erhoben. Funktionale Anforderungen beschreiben die Funktionen, die das System zur Verfügung stellen soll [GBBK10] Produktfunktionen Grundlegender Aufbau des UCMC Um die vom Unified Communications Management Cockpit zu erfüllenden Funktionen begrifflich genauer definieren und beschreiben zu können, wird hier zunächst kurz auf die Definition und die Funktion eines Management Cockpits im Allgemeinen eingegangen und anschließend ein Modell der wesentlichen Konzepte und Begriffe des UCMC erstellt (Abbildung 3.1). Die in der Abbildung verwendeten Begriffe werden im Anschluss textuell näher erläutert. Ein Management Cockpit ist die strukturierte und kompakte Darstellung aller wesentlichen Informationen über ein Steuerungsobjekt, üblicherweise grafisch aufbereitet und auf Basis eines Software-Systems. [Küt06, S. 250]. Für den Manager entscheidungsrelevante Kennzahlen werden grafisch visualisert. Hierbei werden oft mehrere Kennzahlen kombiniert und als Charts oder mit Statussymbolen oder Trendentwicklungen versehen dargestellt. Ist die Anzahl der darzustellenden Kennzahlen sehr hoch, so werden diese in Kategorien eingeteilt und auf verschiedenen Seiten repräsentiert. Ziel eines Management Cockpits ist eine adäquate Visualisierung von entscheidungsrelevanten Daten für das Management und die Unterstützung der Entscheidungsfindung. Eine wichtige Anforderung an ein Management Cockpit ist eine hohe Benutzungsfreundlichkeit. MC Element: Ein MC Element entspricht einem grafischem Element im UCMC, welches eine oder mehrere Information(en) darstellt. Bei einem MC Element kann es sich um ein Diagramm (Balken-, Punkt-, Kreisdiagramm), eine Tabelle oder eine einfache Kennzahl handeln. Kennzahl: Eine Kennzahl ist nach [Küt06] ein Zahlenwert, der zu einem bestimmten Berichtszeitpunkt eine quantitative Aussage über die geplante oder tatsächliche Ausprägung eines Merkmals eines Steuerungsobjekts macht. Dabei ist ein Steuerungsobjekt ein Service, Prozess, System oder Projekt in einem Unternehmen, welches von einem Startzustand in einen Zielzustand überführt werden soll. Beim UCMC ist das Steuerungsobjekt die unternehmensinterne Kommunikation. Tabelle: Eine Tabelle im UCMC kann mehrere Kennzahlen beinhalten. Sie ist immer zweispaltig, die erste Spalte enthält den Namen der Kennzahl, die zweite den zugehörigen Wert. Diese Darstellungsform ist insbesondere dann gut geeignet, wenn man an den absoluten Werten von verschiedenen Kennzahlen interessiert ist und diese direkt vergleichen möchte. Balkendiagramm: Das Balkendiagramm ist eine Darstellungsform, bei der die jeweiligen Kennzahlen durch mehrere Balken nebeneinander repräsentiert werden. So können 28

47 3.2 Funktionale Anforderungen MC Element Position * * Cockpit Site Chart Table Key figure BarChart PieChart PlotChart Abbildung 3.1: Grundlegender Aufbau des UCMC die Werte gut miteinander verglichen werden und Unterschiede aufgezeigt werden. Ein Balkendiagramm ist insbesondere dann geeignet, wenn die Anzahl an darzustellenden Werten relativ gering ist. Punktdiagramm: Bei einem Punktdiagramm werden Wertepaare in einer zweidimensionalen Fläche eingetragen. Es eignet sich gut als Darstellungsform, wenn viele Werte dargestellt werden sollen und nicht das einzelne Wertepaar, sondern die Gesamtheit der Werte von Bedeutung ist. So kann mit Punktdiagrammen beispielsweise die Streuung von Werten visualisiert werden. Kreisdiagramm: Ein Kreisdiagramm gibt einen Überblick über das Ganze und seine Anteile beziehungsweise über die Zusammensetztung. Es sollte im UCMC verwendet werden, wenn das Verhältnis einzelner Werte zu ihrer Gesamtheit von Interesse ist und es sich um eine kleine Anzahl an darzustellenden Kennzahlen handelt. Cockpit Site: Eine Cockpit Site ist eine Seite der Anwendung und entspricht somit einer Kategorie. Sie beinhaltet mehrere MC Elemente. Position: Die Position bestimmt, an welcher Position sich ein MC Element auf einer Cockpit Site befindet und welche Größe ein MC Element hat. Anwendungsfalldiagramm Die vom UCMC zu erfüllenden Produktfunktionen sind in in Abbildung 3.2 auf Seite 30 als UML2.0-Anwendungsfalldiagramm grafisch dargestellt. Die Anforderungen sind in der Form /UCxx/ eindeutig durchnummeriert, damit im weiteren Verlauf der Arbeit auf einzelne Anforderungen Bezug genommen werden kann. Zudem werden die Anforderungen und Akteure im Folgenden in natürlicher Sprache beschrieben. UC User: Ein UC User ist ein Nutzer des UC-Systems im Unternehmen. Er möchte einen 29

48 3 Anforderungsanalyse /UC10/ Cockpit Site anzeigen UC Management Cockpit /UC11/ Cockpit Site exportieren /UC12/ Cockpit Site drucken /UC21/ MC-Element- Auswahl exportieren /UC30/ MC Element exportieren UC User /UC40/ Benutzerauthentifizierung /UC41/ Passwort anfordern /UC60/ Zeitraum bestimmen /UC42/ Account anfragen UC Manager /UC51/ Applikationshilfe aufrufen /UC50/ Elementbeschreibung aufrufen /UC70/ Datenbankinhalt aktualisieren /UC80/ Account anlegen Administrator /UC82/ Passwortanfragen bearbeiten /UC81/ Account löschen Abbildung 3.2: Anwendungsfalldiagramm für das UCMC 30

49 3.2 Funktionale Anforderungen Überblick über seine persönliche Nutzung des UC-Systems. Bei der Nutzung des Management Cockpits sieht er im Gegensatz zum UC Manager nur seine personenbezogenen Nutzungsinformationen (gefilterte Informationen). UC Manager: Ein UC Manager ist ein leitender Angestellter im Unternehmen, in dem das Management Cockpit verwendet wird. Er möchte einen Überblick über die gesamte Nutzung des UC-Systems in seinem Unternehmen oder Unternehmensbereich haben. Jeder UC Manager ist auch ein UC User und kann sich seine gefilterten, personenbezogenen Informationen anzeigen lassen. Administrator: Der Administrator des Management Cockpits ist ein technischer Mitarbeiter des Unternehmens, in dem das UCMC eingesetzt wird (IT-Fachkraft). Er ist Verantwortlicher für den Betrieb der Applikation und für die monatliche Aktualisierung der dem Management Cockpit zugrunde liegenden Datenbankinhalte. Daneben ist er für die Benutzerverwaltung zuständig. /UC10/ Cockpit Site anzeigen: Der UC User kann wählen, welche ihm zur Verfügung stehende Cockpit Site angezeigt werden soll. Es kann immer nur genau eine Cockpit Site angezeigt werden. /UC11/ Cockpit Site exportieren: Der UC User kann die momentan ausgewählte Cockpit Site als PDF-Datei exportieren und an einem frei wählbaren Ort im Dateisystem abspeichern. /UC12/ Cockpit Site drucken: Der UC User kann die momentan ausgewählte Cockpit Site drucken. /UC21/ MC-Element-Auswahl exportieren: Der UC User kann mehrere MC-Elemente (seitenübergreifend) auswählen und diese Auswahl als PDF-Datei exportieren und an einem frei wählbaren Ort im Dateisystem abspeichern. /UC30/ MC-Element exportieren: Der UC User kann ein MC-Element als JPG-Datei exportieren und an einem frei wählbaren Ort im Dateisystem abspeichern. /UC40/ Benutzerauthentifizierung: Der UC User kann sich an der Anwendung mit seinem Benutzernamen ( -adresse) und Passwort anmelden, damit ihm nur die nutzerabhängigen MC-Elemente mit gefilterten Daten angezeigt werden. Der Anwender kann sich zudem wieder vom System abmelden. /UC41/ Passwort anfordern: Sollte der UC User sein Passwort verlegt oder vergessen haben, so kann er dieses beim Administrator anfordern. /UC42/ Account anfragen: Der UC User kann einen Benutzeraccount anfordern, sollte er noch keine Zugangsdaten für das UC Management Cockpit haben. /UC50/ MC Element-Beschreibung aufrufen: Der UC User kann zu jedem MC Element einen Beschreibungstext (Hilfetext) aufrufen. 31

50 3 Anforderungsanalyse /UC51/ Applikationshilfe aufrufen: Der UC User kann die Applikationshilfe aufrufen und wieder schließen. /UC60/ Zeitraum bestimmen: Der UC User wählt den Monat, auf welchen sich die angezeigten MC Elemente beziehen sollen. /UC70/ Datenbankinhalt aktualisieren: Der Administrator kann den Inhalt der dem UC Management Cockpit zugrunde liegenden Datenbank aktualisieren. /UC80/ Account anlegen: Der Administrator kann einen neuen Benutzer für das Management Cockpit anlegen und Berechtigungen (UC Manager / UC User) zuordnen. /UC81/ Account löschen: Der Administrator kann einen existierenden Benutzer löschen. /UC82/ Passwortanfragen bearbeiten: Der Administrator beantwortet Passwortanfragen von Benutzern. Annahmen und Abhängigkeiten In dieser Arbeit soll die erste Version des UCMC mit begrenztem Funktionsumfang erstellt werden. Zunächst sollen die Anwendungsfälle /UC10/, /UC11/, /UC12/, /UC21/, /UC30/, /UC50/, /UC51/ und /UC60/ implementiert werden. Diese Anwendungsfälle sollen nur für den Anwender UC Manager umgesetzt werden, die spezifischen Funktionen des UC User (insbesondere Filterung der Daten zur benutzerabhängigen Darstellung und Benutzerauthentifikation) sind in dieser Arbeit nicht umzusetzen. Die Umsetzung der zu implementierenden Funktionen soll jedoch so erfolgen, dass eine Erweiterbarkeit der Applikation hinsichtlich der zusätzlichen Funktionen gegeben ist. Die erste Version des UCMC soll somit eine gut erweiterbare Grundlage für eine umfassende Anwendung zur Analyse des Nutzens und der Potenziale von UC-Systemen darstellen Darzustellende Informationen (MC Elemente) Das UCMC soll die in Abbildung 3.3 genannten Informationen über die Nutzung der Kommunikationsmedien im Unternehmen beinhalten. Eine Information entspricht hierbei einem MC-Element. Es handelt sich bei diesen Informationen nicht um ein wissenschaftlich erarbeitetes Kennzahlensystem, sondern um eine Menge als sinnvoll erachteter Informationen über die Nutzung des UC-Systems in einem Unternehmen. Das zu entwickelnde Datenbankschema soll den Sachverhalt unternehmensinterne, mittelbare Kommunikation möglichst vollständig darstellen, die genannten Informationen sollen hierbei als Ausgangspunkt für die Entwicklung des Datenbankschemas dienen. Zunächst soll sich der Sachverhalt auf die im Unternehmen am häufigsten benutzten Kommunikationsmedien, nämlich Telefon, Mail und Instant Messaging beschränken. Das Datenmodell soll jedoch erweiterbar sein, so dass weitere Kommunikationsmedien integriert werden können. Durch die vollständige Modellierung des Sachverhaltes und nicht nur der für das provisorische Kennzahlensystem benötigten Informationen soll das System nach Fertigstellung 32

51 3.2 Funktionale Anforderungen ID Kat. Name Beschreibung (# = Anzahl) I01 IM Übersicht absolute Kennzahlen (# IM Sessions gesamt, # gesendeter Dateien, # IM Sessions abteilungsintern, # IM Sessions abteilungsübergreifend) I02 IM Abteilung # IM Sessions abteilungsintern vs. abteilungsübergreifend I03 IM Gesendete Dateien # gesendeter Dateien nach Dateityp I04 IM IM-Session Initiierung # IM Sessions nach Initiierungstyp I05 IM Zeitblock # IM Sessions nach Zeitblock (8h-12h, 12h-18h, 18h-8h) I06 IM Teilnehmerzahl # IM Sessions mit 2 Teilnehmern vs. > 2 Teilnehmer I07 IM Präsenzstatus Präsenzstatus des IM-Sessions Teilnehmers zu Sessionbeginn M01 Mail Übersicht absolute Kennzahlen (# Mails gesamt, # Mails mit Anhang, # Mail abteilungsintern, # Mail abteilungsübergreifend M02 Mail Destination # Mails abteilungsintern vs. abteilungsübergreifend M03 Mail Wichtigkeit # Mails nach Wichtigkeit (HOCH, MITTEL, NIEDRIG) M04 Mail Mailanhang # Mails mit Anhang nach Dateityp M05 Mail Initiierung der Mail # Mail nach Initiierungstyp M06 Mail Zeitblock # Mail nach Zeitblock (8h-12h, 12h-18h, 18h-8h) M07 Mail Präsenzstatus # Mails nach Präsenzstatus des Empfängers M08 Mail # Mailempfänger # Mails mit 1 Empfänger, vs. > 1 Empfänger T01 Telefonie Übersicht absolute Kennzahlen (# Anrufversuche (gesamt), # Anrufe (erfolgreich), # Anrufversuche (nicht erfolgreich), # Telefonkonferenzen T02 Telefonie Destination # Anrufe (erfolgreich) abteilungsintern vs. abteilungsübergreifend T03 Telefonie Anruferfolg # Anrufe (erfolgreich) vs. # Anrufversuche (nicht erfolgreich) T04 Telefonie Erfolglose Anrufe nicht erfolgreiche Anrufversuche je Grund (CallTerminationCause) T05 Telefonie Anrufinitiierung Anrufversuche (erf. + nicht erf.) nach Iniitierungstyp T06 Telefonie Anrufinitiierung 2 Anrufversuche (gesamt) nach Initiierungstyp + # erfolgreicher Anrufe je Initiierungstyp T07 Telefonie Anrufentgegennahme # erfolgreiche Anrufe nach Anrufentgegennahme-Typ T08 Telefonie Zeitblock # erfolgreiche Anrufe nach Zeitblock (8h-12h, 12h-18h, 18h-8h) T09 Telefonie Dauer (Anruf) # Anrufe nach Dauer (0-2, 2-5, 5-15, >15 min) T10 Telefonie Präsenzstatus # Anrufe (gesamt) nach Präsenzstatus des Angerufenen + davon # erfolgreiche Anrufe T11 Telefonie Telko Destination # Telefonkonferenzen abteilungsintern vs. abteilungsübergreifend T12 Telefonie Telko Dauer # Telefonkonferenzen nach Dauer (0-5, 5-15, 15-45, >45 min) Abbildung 3.3: Im UCMC darzustellende MC-Elemente 33

52 3 Anforderungsanalyse die Möglichkeit bieten, auf Grundlage des implementierten Datenmodells weitere MC- Elemente zu definieren und darzustellen. 3.3 Nichtfunktionale Anforderungen In diesem Abschnitt werden die nichtfunktionalen Anforderungen an die Anwendung näher beschrieben. Nichtfunktionale Anforderungen sind Anforderungen an Qualitätseigenschaften des Systems und der Funktionen, sowie an den Entwicklungsprozess, einzuhaltende Standards und gesetzliche Rahmenbedingungen [GBBK10]. Die in diesem Abschnitt formulierten Anforderungen beziehen sich auf das UCMC im Gesamten. Anforderungen, die für den in dieser Arbeit umzusetzenden Teil nicht von Bedeutung sind, werden der Vollständigkeit halber dennoch erwähnt und sind mit einem * markiert Anforderungen an die Qualität Kriterium Sehr wichtig Wichtig Weniger wichtig Unwichtig Benutzbarkeit - Verständlichkeit x - Bedienbarkeit x - Erlernbarkeit x Effizienz x Portierbarkeit x Sicherheit* x Wartbarkeit x Zuverlässigkeit - Wiederherstellbarkeit* x - Fehlertoleranz x Tabelle 3.1: Nichtfunktionale Anforderungen an das UCMC Tabelle 3.1 zeigt einen Überblick über die nichtfunktionalen Anforderungen an die Qualität des UCMC. Im Folgenden werden die für das UCMC sehr wichtigen Kriterien näher erläutert und der Bezug zum UCMC wird hergestellt. Benutzbarkeit Die Benutzbarkeit ist nach [LCM + 04] eine Menge von Merkmalen, die den Aufwand beschreibt, der verwendet werden muss, um die Anwendung zu verstehen, zu erlernen und zu nutzen. Zu diesen Merkmalen gehören die Verständlichkeit der Software, die Bedienbarkeit, d.h. der benötigte Aufwand für die Bedienung der Anwendung und die Erlernbarkeit. Die Erlernbarkeit entspricht dem Aufwand, die Nutzung der Anwendung zu erlernen. Das UCMC soll eine äußerst einfach zu bedienende und schnell erlernbare Anwendung sein. Der Nutzer soll die Anwendung nach einer kurzen Orientierungsphase direkt mit all ihren Funktionen nutzen können und auf keinerlei Schwierigkeiten bei der Bedienung 34

53 3.3 Nichtfunktionale Anforderungen der Anwendung stoßen. Zudem soll die Hilfefunktion alle Funktionen der Anwendung verständlich beschreiben. Auf Grund oben genannter Anforderungen haben alle Kriterien des Bereiches Benutzbarkeit eine sehr hohe Wichtigkeit für das UCMC. Portierbarkeit Die Portierbarkeit beschreibt die Eignung der Anwendung, von einer Umgebung in eine andere übertragen werden zu können. Bei der Umgebung kann es sich um die Hardware-, Software- oder organisatorische Umgebung handeln (vgl. [LCM + 04]). Das UCMC soll ohne großen Aufwand auf verschiedenen Rechnern installiert werden können, ohne dass die Anwendung hierfür angepasst werden muss. Insbesondere sollen das Microsoft- und Linux-Betriebssystem unterstützt werden. Zudem soll der Aufwand für die Installation gering sein Sonstige Anforderungen Der Kunde (Fraunhofer ESK) wünscht, dass das Unified Communications Management Cockpit als Desktopapplikation realisiert wird. Ein weiterer Kundenwunsch ist es, SQLite als dem UCMC zugrundeliegende Datenbank zu verwenden. 35

54 3 Anforderungsanalyse 36

55 4 Entwurf 4.1 Architekturentwurf In diesem Abschnitt soll eine Softwarearchitektur für das UCMC entworfen werden, die die im vorherigen Kapitel erhobenen Anforderungen möglichst optimal unterstützt Tier-Architektur Als grundlegendes Architekturmuster wird eine 2-Tier-Architektur verwendet. Dabei hat jede Tier hat eine eindeutige Verantwortlichkeit im System. Die erste Tier ist die Anwendung, mit der der Benutzer arbeitet. Die Anwendung kümmert sich um die Darstellung der Benutzerschnittstelle und die Anwendungslogik, d.h. im Fall des UCMC die eigentliche Verarbeitung der Daten. Die zweite Tier, das Backend, ist ein Datenbankmanagementsystem (DBMS). Es ist verantwortlich für die Datenhaltung im System. Die Kommunikation zwischen den beiden Tiers verläuft unidirektional. Die Anwendung greift auf die Datenbank zu, das DBMS hat jedoch keinen Zugriff auf die Anwendung. Für das UCMC wurde die 2-Tier-Architektur ausgewählt, weil die Datenbasis des UCMC umfangreich ist und somit eine Trennung von Datenhaltung und Präsentation als sinnvoll erachtet wurde. Da der Zugriff auf die Datenbank durch das UCMC nur lesend erfolgt und eine Datenmanipulation sowie komplexe Abläufe nicht notwendig sind, wurde darauf verzichtet, eine 3-Tier-Architektur umzusetzen Model-View-Controller Das UCMC ist eine Anwendung, bei der die Benutzerinteraktion und die Benutzerschnittstelle eine sehr große Rolle spielen. Aus diesem Grund soll für die Anwendung das für interaktive Anwendungen typische Architekturmuster Model-View-Controller (MVC) verwendet werden. Die grundlegende Idee der MVC-Architektur ist die Trennung von Daten (Model), Präsentation (View) und Programmsteuerung (Controller). Das Model kapselt hierbei die Daten und gegebenenfalls die mit den Daten in Zusammenhang stehenden Funktionalitäten. Es ist unabhängig von der Präsentation der Daten sowie der Interaktion des Benutzers mit der Anwendung. Die View stellt die entsprechenden Daten, die sie von dem Model erhält, für den Benutzer dar und nimmt die Interaktion des Benutzers mit der Anwendung entgegen. Diese übergibt sie dann in Form von Ereignissen an den Controller, welcher nun dem Model kommuniziert, welche Daten geändert werden müssen. In einigen Fällen kommuniziert der Controller auch direkt mit der View, beispielsweise wenn die Benutzerinteraktion nur eine Änderung der View und keine Änderung von Daten im Modell hervorruft [GBBK10]. Mit dieser Trennung wird erreicht, dass der Programmentwurf flexibel ist. Eine spätere 37

56 4 Entwurf Änderung oder Erweiterung der Anwendung wird vereinfacht, da die einzelnen Komponenten austauschbar sind und wiederverwendet werden können. Eine strikte Anwendung von MVC verbessert so insbesondere die Übersichtlichkeit und Wartbarkeit der Anwendung. Während bei einer typischen MVC-Anwendung vor allem die einfache Austauschbarkeit von Präsentation und Verhalten der Anwendung, d.h. von View und Controller, von großer Bedeutung ist, ist dies beim UCMC nicht unbedingt gefordert. Vielmehr ist die Hauptanforderung an die View des UCMC, dass möglichst einfach neue MC-Elemente und Cockpit Sites definiert und hinzugefügt werden können. Somit soll das UCMC keine vordefinierte View, sondern eine flexible und erweiterbare View haben, die erst zur Laufzeit, ausgehend von einer Konfiguration, erstellt wird. Zu Gunsten dieser Funktionalität wurde beim UCMC die strenge Trennung von Model, View und Controller nicht vollständig, sondern nur zu großen Teilen umgesetzt. Im folgenden Abschnitt wird nun erläutert, wie das MVC-Architekturmuster beim UCMC verwendet werden soll und welche Funktionen die jeweiligen Komponenten erfüllen. Model: Das Model enthält hautpsächlich die für die MC-Elemente grundlegenden Daten und die SQL-Anfragen, um diese Daten aus der Datenbank zu beziehen. Zudem enthält es die Funktionalitäten, die direkt mit den Daten in Verbindung stehen, wie beispielsweise die Verbindung zum Datenbankmanagementsystem. View: Die View des UCMC besteht zum einen aus den grafischen Komponenten, die für die Darstellung der Benutzerschnittstelle nötig sind. Zum anderen enthält sie aber auch die benötigten Funktionalitäten zum Aufbau der Kategorien und MC-Elemente, ausgehend von einer Konfigurationsdatei, sowie weitere Funktionalitäten, die ausschließlich Einfluss auf die View haben. Ein Beispiel für eine solche Funktionalität ist der Wechsel der angezeigten Kategorie. Hierbei wird die View verändert, aber es besteht kein Bezug zu Werten im Model. Controller: Der Controller wird von der View bei einigen Interaktionen des Benutzers mit der Anwendung benachrichtigt und ist dann für die Benachrichtigung des Models zuständig. Im Falle des UCMC ist der Controller somit für die Kommunikation zwischen View und Model bei einem Wechsel des Anzeigemonats sowie für weitere Funktionen wie den PDF-Export verantwortlich Verwendete Technologien Adobe AIR Im Rahmen des Entwurfsprozesses wurde die Entscheidung getroffen, das UCMC als Adobe AIR Anwendung umzusetzen. AIR steht für Adobe Integrated Runtime. Ausschlaggebend für die Entscheidung für diese Technologie waren die nichtfunktionalen Anforderungen, dass das UCMC als Desktopapplikation realisiert und SQLite als Datenbank verwendet werden soll. Außerdem ist die Benutzbarkeit und Portierbarkeit der Anwendung von hoher Bedeutung. Wie im Folgenden noch näher erläutert werden wird, wird SQLite 38

57 4.1 Architekturentwurf direkt von AIR unterstützt und AIR Applikationen laufen problemlos auf verschiedenen Betriebssystemen, wodurch eine sehr gute Portierbarkeit gegeben ist. Ein weiteres wichtiges Kriterium für AIR war, dass die vorhandenen AIR Komponenten grafisch ansprechend sind und viele die Benutzbarkeit erhöhende Funktionen einfach integriert werden können. Adobe AIR ermöglicht es, Desktopapplikationen mit den Technologien von Webanwendungen zu realisieren. Hierfür bietet es eine Laufzeitumgebung und ein Application Programming Interface (API), welche verschiedenste Funktionen bereitstellen. Die Laufzeitumgebung sorgt dafür, dass die Anwendung auf allen Betriebssystemen lauffähig ist. Zudem dient sie als Vermittler zwischen der Anwendung und dem jeweiligen Betriebssystem. Die API bietet typische Funktionen für Desktopapplikationen, wie z.b. Copy and Paste, Zugriff auf das Betriebssystem und das Netzwerk, Drag and Drop, Software Updates und die Installation direkt von Webseiten. Eine weitere Funktion der API ist die Unterstützung von lokalen SQLite Datenbanken und die Integration und Darstellung von PDF-Inhalten durch Nutzung einer auf dem Rechner installierten Instanz des Adobe Readers. Zu den von AIR unterstützten Technologien gehören unter anderem HTML, Flex, JavaScript und Ajax [Pfe09]. Flex Die am häufigsten verwendete Technologie bei der Erstellung von Adobe AIR Desktopapplikationen ist Adobe Flex. Es basiert auf der Flash-Technologie und ist ein Open Source Framework zur Entwicklung von plattformunabhängigen Rich Internet Applications (RIA). Flex Applikationen werden im Flashplayer dargestellt und es werden zwei Programmiersprachen verwendet: MXML und Action Script. MXML ist eine deklarative, XML-basierte Programmiersprache. Mit ihr kann der Aufbau der Benutzeroberfläche und das Layout der Benutzeroberflächenkomponenten einer Flex-Applikation beschrieben werden. Es können auch einige nichtoptische Aspekte der Anwendung deklarativ mit MXML definiert werden. ActionScript hingegen ist eine prozedurale, objektorientierte Programmiersprache. Sie wird zur Definition der clientseitigen Logik und der dynamischen Aspekte einer Flex-Anwendung verwendet [Pfe09]. Ein MXML-Tag entspricht einer ActionScript Klasse oder Eigenschaft. Bei der Kompilierung der Anwendung analysiert Flex dann die MXML-Tags und generiert die entsprechenden ActionScript-Klassen. ActionScript kann hierdurch auch in einer MXML-Datei innerhalb eines Script-Tags verwendet werden. Zudem können ActionScript-Dateien verwendet, ActionScript-Klassen importiert und Komponenten in ActionScript erstellt und in der Flex-Anwendung verwendet werden. SQLite SQLite ist eine OpenSource C-Programmbibliothek, die ein relationales Datenbanksystem enthält. SQLite unterstützt einen Großteil des SQL92-Standards und die folgenden fünf Datentypen: NULL, INTEGER, REAL, TEXT, BLOB. Man kann in der Definition von Tabellen jedoch auch viele weitere Datentypen verwenden, z.b. BOOLEAN oder DATE, diese werden dann von SQLite automatisch, entsprechend fünf bestehender Konvertierungsregeln 1, einem der fünf Grundtypen zugeordnet

58 4 Entwurf Ausschlaggebendes Kriterium für die Wahl von SQLite als Datenbank war, dass die Datenbank nicht serverbasiert ist und nicht installiert werden muss, sondern aus einer einzigen Datei besteht, die sehr einfach in das Programm integriert werden kann. Die Datenbank kann so zusammen mit dem Programm installiert werden und benötigt keine Administration. Ein Problem bei der Verwendung von SQLite ist, dass Fremdschlüssel nicht unterstützt werden. Bei der Definition von Tabellen können sie definiert werden, die Einhaltung wird jedoch nicht überprüft. Diese fehlende Funktionalität wurde allerdings unter Berücksichtigung der Vorteile von SQLite hingenommen. Da das UCMC nur lesend auf die Datenbank zugreift, ist die fehlende Fremdschlüsselunterstützung nur für das monatliche Einfügen von neuen Daten relevant. Die fehlende Funktionalität ist ein bekanntes Defizit von SQLite und es besteht die Möglichkeit, die Datenkonsistenz beim Einfügen neuer Daten über Trigger zu gewährleisten. Im Laufe der Implementierungsphase dieser Arbeit hat sich herausgestellt, dass SQLite Fremdschlüssel nun seit Version unterstützt. Zu diesem Zeitpunkt war die Implementierung der Arbeit schon weit fortgeschritten und es wurde darauf verzichtet, die neuere Version von SQLite zu verwenden. Eine weiterer Nachteil von SQLite ist die fehlende Funktion, die Datenbank durch Benutzerbzw. Zugriffsrechte zu schützen. Der Zugriff auf die Datenbank ist abhängig von den Zugriffsrechten im Dateisystem. Für das UCMC spielt dies zunächst keine Rolle, da auf die Datenbank nur indirekt über die Anwendung zugegriffen wird. 4.2 Entwurf eines integrierenden Datenbankschemas Das UCMC soll die benötigten Daten für die Darstellung der MC-Elemente durch Zugriff auf eine Datenbank erhalten. In diesem Abschnitt wird ein Datenbankschema für diese Datenbank entwickelt. Das Schema soll die Möglichkeit zur Berechnung der in Abschnitt genannten Informationen bieten. Das resultierende Datenmodell soll zudem Daten aus verschiedenen Quellen, wie z.b. dem Microsoft OCS und dem Cisco Unified Communications Manager, aufnehmen können und erweiterbar sein. Vorrangiges Ziel der Modellierung ist jedoch eine möglichst optimale Darstellung der gewünschten Informationen und des Sachverhaltes mittelbare, unternehmensinterne Kommunikation, und nicht eine möglichst gute Kompatibilität zu den Modellen von Cisco und Microsoft. Beim Entwurf des Datenmodells wird, ausgehend von dem zu modellierenden Sachverhalt, zunächst ein konzeptuelles Schema erstellt. Dieses versucht, möglichst nah an dem zu modellierenden Sachverhalt zu bleiben, es ist jedoch zur Implementierung der Datenbank ungeeignet. Aus diesem Grund wird im Anschluss das konzeptuelle Schema in ein logisches Schema überführt (vgl. [KE09]). Das logische Schema ist implementierungsnah und beachtet die Konzepte und Einschränkungen des zum Einsatz kommenden Datenbanksystems. Als Ausgangspunkte zur Erstellung des Datenmodells dienen das Datenbankschema des Archiving CDR Servers des Microsoft OCS (Version 3, Release 2) und die Struktur der Call Detail Records (CDR) des Cisco Unified Communications Managers (Version 7.0). Das Datenbankschema des OCS Archiving Server befindet sich in Anhang A. 40

59 4.2 Entwurf eines integrierenden Datenbankschemas Als Darstellungsform für das konzeptuelle Schema wurde das Entity-Relationship-Modell gewählt. Abbildung 4.1 auf Seite 42 zeigt das erarbeitete Modell. Aus Gründen der Übersichtlichkeit wurden statische Elemente, wie beispielsweise die Rolle eines Telefonkonferenzteilnehmers, nicht explizit als weiteres Element, sondern nur als Attribut modelliert. Zudem wurden die Attribute von Beziehungen zusammengefasst. Es hat sich herausgestellt, dass die als Ausgangspunkte betrachteten Strukturen keine große Hilfestellung für den Entwurf des Datenmodells leisten konnten. Beide Quellen enthalten nur wenige relevante Informationen für das Datenmodell des UCMC. So hat sich nach ausführlichen Recherchen ergeben, dass beim Cisco Call Manager kein direkter Zugriff auf die CDR-Datenbank möglich ist und somit auch die Datenbankstruktur nicht eingesehen werden kann. Über ein Cisco Verwaltungstool kann lediglich eine Textdatei mit den CDR-Inhalten exportiert werden. Die Struktur dieser Datei ist allerdings unübersichtlich. Zudem sind nur Daten über die Nutzung des Kommunikationsmediums Telefon verfügbar. Die Datenbankstruktur des Archiving CDR Servers von Microsoft hingegen enthält Daten über die Nutzung von Telefon und Instant Messaging. Diese Daten beziehen sich jedoch mehr auf die technischen Aspekte der Kommunikation und sind für den Zweck des UCMC deswegen nicht uneingeschränkt verwendbar. Es wird beispielsweise in keinen der beiden Quellen der Präsenzstatus, welcher für das UCMC eine sehr bedeutende Information ist, geloggt. Das konzeptuelle Schema wurde in ein relationales Schema, dargestellt als UML Klassendiagramm in Abbildung 4.2, überführt. Dieses Schema dient schließlich als Grundlage für die Implementierung der Datenbank. Eine detaillierte Beschreibung der einzelnen Relationen befindet sich in Anhang B. Bei der Konzeption des logischen Schemas wurden die Besonderheiten der SQLite-Datenbank (vgl ) beachtet. Es werden nur die fünf Grunddatentypen von SQLite verwendet, die Datumsangaben werden als UNIX-Time (INTEGER) gespeichert. Aus Gründen der Übersichtlichkeit und des logischen Aufbaus des Schemas wurden, obwohl erstmal nicht implementierbar, auch Fremdschlüssel modelliert. Beim Entwurf des Datenmodells wurde viel Wert auf Konsistenz und Vermeidung von Redundanz gelegt. Merkmale, die UC-systemabhängig sind, wie beispielsweise die Anzahl und Benennung der Präsenzstati, wurden in statische Tabellen ausgegliedert und können durch eine einfache Änderung dieser Tabelle an das jeweilige UC-System angepasst werden. Das erarbeitete Modell bietet zudem eine gute Grundlage für eine eventuelle Erweiterung des Modells um andere Kommunikationsmedien, und bereits integrierte Kommunikationsmedien lassen sich problemlos um weitere Eigenschaften erweitern. 41

60 4 Entwurf User userid IMMessage IMSession File Mail Call datetime IMMessageID IMSessionID filetype filename fileid datetime priority mailid initiationtype pickuptype "callterminationcause" callid sends 1 n belongs to n 1 IMSession SentFiles n Attachment n m sends receives m n 1 n Caller n Participant n m IMMessageID IMSessionID IMMessageID sip IMSessionID sip datetimejoin datetimeleave role IMSessionID fileid datetime sentby result fileid mailid mailid mailaddress mailid mailaddress callid phonenumber initiationtype initiationtype name SIP PhoneNumber MailAddress has has has n n n datetimeconnect datetimedisconnect 1 Recipient 1 n callid phonenumber CallConference Participant n m conferenceid phonenumber datetimejoin datetimeleave role conferencelid phonenumber SIP mailaddress m department PresenceStatus has n m code description user presencestatus datetimefrom datetimeto Abbildung 4.1: Entity-Relationship-Modell des Datenbankschemas 42

61 4.2 Entwurf eines integrierenden Datenbankschemas PresenceStatus PK code INTEGER type TEXT(10) UserPresence PK,FK1 user INTEGER PK datetimefrom INTEGER FK2 presence INTEGER datetimeto INTEGER User PK userid INTEGER name TEXT(10) department TEXT(10) Phonenumber PK phonenumber TEXT(10) FK1 user INTEGER Mailaddress PK mailaddress TEXT(10) FK1 user INTEGER MailRec PK,FK1 mail INTEGER PK,FK2 address TEXT(10) SIP PK sip TEXT(10) FK1 user INTEGER ConfParticipant PK,FK1 phonenumber TEXT(10) PK,FK3 conference INTEGER datetimejoin INTEGER datetimeleave INTEGER FK2 role INTEGER Role PK roleid INTEGER CallConference PK conferenceid INTEGER role CHAR(10) Mail PK mailid INTEGER datetime INTEGER priority TEXT(10) FK1 initiationtype INTEGER FK2 sentby TEXT(10) IMMessage PK IMMesssageID INTEGER FK1 sentby TEXT(10) FK2 session INTEGER datetime INTEGER IMSessionPart PK,FK1 participant TEXT(10) PK,FK2 session INTEGER datetimejoin INTEGER datetimeleave INTEGER FK3 role INTEGER CallTerminationCause PK code INTEGER cause TEXT(10) PickupType PK code INTEGER type TEXT(10) IMSession PK IMSessionID INTEGER Call Attachment PK,FK1 file INTEGER PK,FK2 mail INTEGER InitiationType PK code INTEGER type TEXT(10) FileType PK code INTEGER File PK fileid INTEGER filename TEXT(10) FK1 filetype INTEGER FK1 initiationtype INTEGER IMSessionSentFiles PK datetime INTEGER PK,FK2 participant TEXT(10) PK,FK2 session INTEGER FK1 file INTEGER result TEXT(10) PK callid INTEGER FK1 initiationtype INTEGER FK2 pickuptype INTEGER FK3 callterminationcause INTEGER datetimeconnect INTEGER datetimedisconnect INTEGER FK5 numbercalling TEXT(10) FK7 numbercalled TEXT(10) type TEXT(10) Abbildung 4.2: Logisches Datenbankschema 43

62 4 Entwurf 44

63 5 Implementierung Im Anschluss an die Entwurfsphase wurden die Datenbank und die Anwendung entsprechend der im Entwurf getroffenen Entscheidungen umgesetzt. Dieses Kapitel soll einen Überblick über die Ergebnisse und über einige während der Implementierungsphase aufgetretene Probleme geben. 5.1 Implementierung des UCMC mit Adobe AIR Im Folgenden wird die Implementierung des UCMC mit Adobe AIR näher beschrieben. Als Entwicklungsumgebung für die Implementierung wurde der Adobe Flex Builder 3 verwendet. Es wurden alle geforderten funktionalen Anforderungen umgesetzt. Der Anwendungsfall /UC12/ Cockpit Site drucken wurde jedoch nur indirekt realisiert. Um eine Cockpit Site zu drucken, muss man sie zunächst als PDF-Datei exportieren. Diese wird dann in einem neuen Fenster angezeigt und kann dort über die Funktionen des Adobe Readers gedruckt werden. Zusätzlich wurden weitere die Benutzungsfreundlichkeit steigernde Funktionalitäten eingebaut, wie etwa die Möglichkeit MC-Elemente zu minimieren und maximieren. Dies ermöglicht dem Benutzer die Ansicht der jeweiligen Kategorien zu personalisieren. Auf Grund der hohen Anforderungen an die Benutzerfreundlichkeit und das Aussehen mussten einige Einschränkungen bezüglich der Performance der Anwendung gemacht werden. So wird für die problemlose Ausführung des UCMC ein Rechner mit mindestens 1,6GHz und ca. 1GB RAM-Speicher empfohlen Benutzeroberfläche Abbildung 5.1 zeigt die Benutzeroberfläche des UCMC Überblick über die Architektur Das UML-Paketdiagramm in Abbildung 5.2 stellt die Paketstruktur des UCMC dar. Der eigentliche Code der Anwendung befindet sich im Paket source. Das Paket view-config enthält Konfigurationsdateien zum Aufbau und Layout der Benutzeroberfläche. Auf diese Dateien wird in Abschnitt näher eingegangen. Im Paket database ist die SQLite- Datenbankdatei und im Paket assets sind Grafikdateien, welche innerhalb der Anwendung verwendet werden, enthalten. In Abbildung 5.3 wird das Paket source detailliert auf Klassenebene dargestellt. Dabei wird auf eine vereinfachte Darstellungsform, angelehnt an UML2.0-Klassendiagramme zurückgegriffen, um die Übersichtlichkeit zu steigern. Attribute und Funktionen sowie Multiplizitäten wurden nicht abgebildet. Zudem handelt es sich bei den Beziehungen MCELayoutManager - DragHighlight, MCE- LayoutManager - MCElement und MCElement - MCElementContentBase nicht um Assoziationen im Sinne eines UML-Klassendiagramms. Die jeweils an zweiter Stelle 45

64 5 Implementierung Abbildung 5.1: Screenshot des UCMC mit Erläuterungen genannten Objekte sind nicht als Eigenschaften der ersten Klasse im Code wiederzufinden, sondern die erstgenannte Klasse oder eine Eigenschaft der Klasse beinhaltet ein oder mehrere Objekte der ersten Klasse als Kind einer grafischen Komponente. Im Folgenden werden die einzelnen Klassen des source -Paketes und deren Funktionen näher erläutert: UCMC.mxml Die Klasse UCMC.mxml ist die Hauptklasse des UCMC. Sie enthält die WindowedApplication -Komponente von AIR, die das Hauptfenster der Anwendung darstellt. In der Klasse UCMC.mxml werden eine Instanz des Modells und des Controllers erstellt. Zudem wird die MainView-Komponente angelegt und der Aufbau der View initiiert. Paket controller : Controller.as Die Klasse Controller.as stellt die Controller-Komponente des Model-View-Controller-Architekturprinzips dar. Sie enthält eine Referenz auf die MainView und das Model. Der Controller wird durch die View beim Auftreten von Interaktionen des Benutzers, wie dem Wechsel des Anzeigemonats und dem Klick auf einen Export- oder Hilfe-Button, benachrichtigt. Im Anschluss benachrichtigt er das Model über das entsprechende Ereignis bzw. initiiert die notwendigen Funktionen. 46

65 5.1 Implementierung des UCMC mit Adobe AIR source view-config categories.xml styles.css <<import>> assets datasources view controller <<import>> <<import>> util model <<import>> UCMC.mxml components mcelements <<import>> database Abbildung 5.2: Paketdiagramm des UCMC Paket model : ChartData.as Die Klasse ChartData.as ist ein Teil des Modells der Anwendung. Sie enthält die Kennzahlen, die für die Darstellung der in der Anforderungsanalyse beschriebenen MC-Elemente gebraucht werden (siehe Abschnitt 3.2.2). Desweiteren beinhaltet sie die SQL-Statements zur Gewinnung der einzelnen Kennzahlen aus der Datenbank. Eine Übersicht über alle derzeit in ChartData.as enthaltenen Kennzahlen befindet sich in Anhang C. Neben den Kennzahlen speichert die Klasse noch den aktuell angezeigten Monat und ein Objekt der Klasse DataAccess.as. Letzteres ermöglicht der Klasse die Herstellung einer Verbindung zur Datenbank und die Ausführung von SQL-Statements. Zudem enthält die Klasse ChartData.as die Funktionalitäten zur Benachrichtigung der MC-Elemente nach erfolgreicher Aktualisierung der Kennzahlen bei einer Änderung des Anzeigemonats. Für diese Klasse wurde das Entwurfsmuster Singleton verwendet. Es existiert also nur genau eine Instanz der Klasse und es gibt einen globalen Zugriffspunkt auf diese Instanz [GHJV04]. Hiermit wird sichergestellt, dass alle MC-Elemente auf die gleiche Datenbasis zurückgreifen und auch nur eine Datenbasis bei einem Wechsel des Anzeigemonats aktualisiert werden muss. Alle Klassen, die eine Referenz auf die Instanz der ChartData- Klasse haben, sind nach dem Entwurfsmuster Beobachter [GHJV04] realisiert. Dies sind die Klassen MainView.mxml und MCElementContentBase.as. Während die Klasse MainView einige Eigenschaften der ChartData-Klasse über Flex-DataBinding beobachtet, benachrichtigt die ChartData-Klasse seine Beobachter des Typs MCElementContentBase über eine Aktualisierung der Daten durch Auslösung eines Ereignisses. 47

66 5 Implementierung PDFCreationEvent.as UCMC.mxml PDFCreation.as DataAccess.as HelpWindow.mxml Controller.as MonthChooser.as MainView.mxml ChartData.as DragHighlight.mxml MCELayoutManager.as MCElement.as MCEStateChangeEvent.as DataObject.as MCElementContentBase.as MCE_BarChartContent.mxml MCE_PieChartContent.mxml MCE_PlotChartContent.mxml MCE_TableContent.mxml Abbildung 5.3: Vereinfachtes Klassendiagramm des UCMC Klassen des Paketes view MainView.mxml Die Klasse MainView enthält sämtliche Elemente der Benutzeroberfläche innerhalb des Anwendungsfensters. Hierzu gehören sowohl die obere Leiste mit der Kategorieauswahl, der Monatsanzeige sowie den Funktionsschaltflächen, der untere Bereich zur Anzeige von Informationstexten als auch der Hauptbereich der Anwendung mit den MC-Elementen (vgl. Benutzeroberfläche des UCMC, Abbildung 5.1). Neben diesen grafischen Elementen enthält die Klasse MainView.mxml vor allem Funktionen zum Aufbau des Hauptbereichs der Benutzeroberfläche, ausgehend von der Konfigurationsdatei categories.xml, sowie Funktionen zur Benachrichtigung des Controllers bei bestimmter Interaktion des Benutzers mit dem System. Für den Aufbau des Hauptbereichs liest die Klasse MainView.mxml die Datei categories.xml ein und erstellt zunächst für jede Kategorie einen MCELayoutManager. Anschließend werden die MC-Elemente erstellt. Dabei wird zunächst jedem MC-Element der Content, das heißt das eigentli- 48

67 5.1 Implementierung des UCMC mit Adobe AIR che Diagramm oder die Tabelle, hinzugefügt. Hierfür wird ein Strategiepattern [GHJV04] verwendet. Die einzelnen Strategien entsprechen in diesem Fall keinen Algorithmen, sondern einer Darstellungsstrategie. Die Klasse MainView fügt den jeweiligen MC-Elementen ein Objekt vom Typ MCElementContentBase als Kind hinzu. Hierdurch muss sie nicht über eine konkrete Darstellungsstrategie, wie beispielsweise PieChart oder Table, entscheiden. Die Entscheidung, welche Darstellungsstrategie letztendlich gewählt wird, fällt erst im Konstruktor des MCElementContentBase-Objektes. Dort wird dann auf Grundlage der Informationen in categories.xml entschieden, welcher MC-Elementtyp (=Darstellungsstrategie) tatsächlich verwendet wird. Dem Container des MCELayoutManagers werden schließlich die einzelnen fertig konstruierten MC-Elemente der Kategorie hinzugefügt. Klassen des Paketes view.mcelements MCELayoutManager.as Die Klasse MCELayoutManager.as ist für die Anordnung der MC-Elemente innerhalb einer Kategorie verantwortlich. Dementsprechend gibt es in der Anwendung einen MCELayoutManager pro Kategorie. Dieser wird durch die Klasse MainView beim Aufbau der View initialisiert und enthält einen Canvas-Container, welcher wiederum sämtliche MC-Elemente der Kategorie enthält. Zudem speichert der MCELayoutManager den aktuellen Status (normal, minimiert oder maximiert) der MC- Elemente und ordnet die MC-Elemente entsprechend dieser Informationen an. Bei einem Status- oder Positionswechsel eines MC-Elementes durch den Benutzer der Anwendung wird die Klasse MCELayoutManager.as durch das betroffene MC-Element benachrichtigt und führt direkt eine Aktualisierung des Layouts durch. MCElement.as Die Klasse MCElement.as erweitert die Klasse Panel und stellt das Fenster eines MC-Elementes dar. Sie ist für alle ein MC-Element betreffenden grafischen Funktionen, wie einen Statuswechsel, den Export als JPG-Datei oder die Anzeige des zugehörigen Hilfetextes, verantwortlich. Neben der Funktionsleiste enthält ein MC-Element jeweils ein Kind von einem beliebigen Untertyp von MCElementContentBase. MCEStateChangeEvent.as Das MCEStateChangeEvent enthält drei Konstanten (minimize, restore, maximize) und wird bei einem Statuswechsel eines MC-Elementes durch dieses ausgelöst, so dass der MCELayoutManager mit einer Aktualisierung des Layouts reagieren kann. MCElementContentBase.as Die MCElementContentBase-Klasse ist die Oberklasse für die Klassen MCE BarChartContent, MCE PieChartContent, MCE PlotChart- Content und MCE TableContent. Sie definiert die vom eigentlichen Inhaltstyp unabhängigen Funktionen, wie zum Beispiel das Einlesen der XML-Datei, welche die darzustellenden Kennzahlen enthält. Zudem wird in einer statischen Methode dieser Klasse auf Grundlage der Informationen aus categories.xml entschieden, welche konkrete Unterklasse bzw. Darstellungsstrategie (vgl Mainview.mxml) verwendet wird. Der Zugriff auf die Unterklassen erfolgt ausschließlich über die Klasse MCElementContentBase. 49

68 5 Implementierung MCE xxxcontent.mxml Die Klassen MCE TableContent, MCE PieChartContent, MCE PlotChartContent und MCE BarChartContent entsprechen der Darstellungsstrategie des MC-Elements, das heißt dem Diagramm oder der Tabelle. Sie beinhalten die Diagramm- bzw. Tabellenkomponente, Eigenschaften sowie Funktionen, die vom jeweiligen Diagrammtyp abhängig sind, wie beispielsweise eine Legende oder DataTip- Funktion. Sie sind jeweils eine Unterklasse von MCElementContentBase.as und nutzen die in dieser Klasse definierten Funktionen zur Anzeige und Aktualisierung der Daten des Diagramms bzw. der Tabelle. Im Entwurf bzw. der Anforderungsanalyse wurde zudem die einfache Kennzahl als Darstellungsform ausgewählt. Auf die Implementierung der Darstellungsform wurde jedoch verzichtet, da sie für das UCMC letztendlich nicht von großer Relevanz ist und ebenso gut als Tabelle mit einer Kennzahl dargestellt werden kann. DataObject.as Die Klasse DataObject.as wird von MCElementContentBase.as für die Speicherung der Inhalte der eingelesenen XML-Datei verwendet. In einem DataObject werden die in einem <item> -Tag der XML-Datei vorhandenen Informationen gespeichert. Bei einer Aktualisierung des Monats können so auf einfache Weise alle DataObjects eines MC-Elements iteriert und die entsprechenden Werte aktualisiert werden. Klassen des Paketes view.components HelpWindow.mxml Die MXML-Komponente HelpWindow stellt das Hilfefenster und deren Inhalt dar. Die Hilfetexte zu den MC-Elementen werden aus der Konfigurationsdatei categories.xml entnommen. MonthChooser.as Die ActionScript-Komponente MonthChooser entspricht der Komponente zur Auswahl des Anzeigemonats. Sie erweitert die Klasse DateChooser und greift auf deren Eigenschaften und Funktionen zurück. DragHighlight.mxml Die MXML-Komponente DragHighlight definiert eine einfache graphische Komponente, welche für die Drag n Drop-Funktion der MC-Elemente verwendet wird. Klassen des Paketes util PDFCreation.as PDFCreation.as stellt die Funktionen zur Erzeugung und Anzeige eines PDF-Dokumentes innerhalb der Anwendung zur Verfügung. Für die Erzeugung des PDF-Dokumentes wird die OpenSource Bibliothek AlivePDF 1 verwendet. Die Anzeige von PDF-Dokumenten innerhalb der Anwendung ist eine Funktion von Adobe AIR. Das Programm verwendet hierfür die auf dem System installierte Version des Adobe Acrobat Readers

69 View Controller Model 5.1 Implementierung des UCMC mit Adobe AIR PDFCreationEvent.as Das PDFCreationEvent wird von der Klasse PDFCreation verwendet, um den Fortschritt der Erzeugung des PDF-Dokuments anzuzeigen und den Controller über das Ende des PDF-Erzeugungsprozesses zu informieren. DataAccess.as Die Klasse DataAccess.as beinhaltet sämtliche Funktionalitäten, die in Zusammenhang mit dem Zugriff auf die SQLite-Datenbank stehen. So enthält sie die Funktionen zum Herstellen und Beenden der Datenbankverbindung, zur Ausführung von SQL-Statements und Verwendung der Ergebnisse Umsetzung von MVC Wie dem Klassendiagramm zu entnehmen ist und im Architekturentwurf bereits angesprochen wurde, ist die strenge Trennung von Model, View und Controller beim UCMC nicht vollständig realisiert worden. Abbildung 5.4 zeigt die letztendliche Umsetzung des MVC-Konzeptes im Programmcode des UCMC. Datenaktualisierung bei Monatswechsel Erzeugung und Anzeige von PDF-Dateien Anwendungshilfe aktualisiert Repräsentation der Kennzahlen SQL-Statements für Kennzahlen Verbindung zur DB und Anfragen an DB Controller.as ChartData.as aktualisiert informiert grafische Darstellung der Benutzerschnittstelle generischer Aufbau der Benutzerschnittstelle (Kategorien und MC-Elemente) nach categories.xml View-bezogene Funktionen Wechsel der angezeigten Kategorie MC-Element Verhalten (Minimieren, Maximieren, ) JPG-Export Elementhilfe MainView.mxml Klassen des Paketes MCElements Klassen des Paketes Components stellt dar liest verweist auf Definition der Daten eines MC-Elementes [mceid_mcename].xml verweist auf categories.xml Konfiguration Abbildung 5.4: Umsetzung von MVC im UCMC Die Abbildung verdeutlicht die Funktionen, die von der jeweiligen Komponente erfüllt werden, und nennt die zur Komponente gehörenden Klassen. Die Abweichung von der strengen Trennung von Model, View und Controller ist auf die Anforderung der Flexibilität bezüglich der dargestellten MC-Elemente zurückzuführen. Auf Grund dieser Anforderung sollte vermieden werden, dass die einzelnen MC-Elemente in ActionScript oder 51