Erfolgsfaktorenanalyse (ERFAN)

Inhaltsverzeichnis[Verbergen]

Lernziele

Sie kennen den Zweck der Erfolgsfaktorenanalyse und die Vorgehensweise bei ihrer Anwendung. Sie können ihre Bedeutung für die strategische IT-Planung erklären. Sie sind in der Lage, die für eine strategische Situationsanalyse relevanten Erfolgsfaktoren zu identifizieren und zu beschreiben. Sie wissen, wie der IT-Erfolg gemessen wird und wie er gezielt verbessert werden kann. Sie kennen die Weiterentwicklung der Erfolgsfaktorenanalyse zur Schlüsselfaktorenanalyse und können ihre Zweckmäßigkeit beurteilen.

Definitionen und Abkürzungen

  • Besichtigungsanalyse (inspection analysis) = Form der Istzustandserfassung, deren Zweck durch bloßes Besichtigen erreicht werden kann; Ergebnisse werden meist zur Vorbereitung einer tiefer gehenden Analyse verwendet.

  • Erfolgsfaktor (success factor) = Eigenschaft der IT, deren positive Ausprägung zur Schaffung und Sicherung von Unternehmenserfolg beiträgt.

  • Fragebogenmethode (questionnaire technique) = schriftliche Form der Befragung mit einer geordneten Menge von offenen und/oder geschlossenen Fragen.

  • Interdependenzanalyse (interdependence analysis) = Untersuchung der Beziehungen zwischen zwei Objektmengen, um deren gegenseitige Beeinflussung festzustellen.

  • kritischer Erfolgsfaktor (critical success factor) = Erfolgsfaktor, von dessen Ausprägung der Unternehmenserfolg entscheidend abhängt.

  • Leistung (performance) = von den Befragten geschätzter Beitrag eines Erfolgsfaktors zum Unternehmenserfolg.

  • Leistungsdifferenz (performance gap) = Unterschied zwischen Priorität und Leistung je Erfolgsfaktor.

  • Priorität (priority) = von den Befragten subjektiv eingeschätzte Wichtigkeit eines Erfolgsfaktors bezüglich seines Beitrags zum Unternehmenserfolg.

  • Schlüsselbereich (key domain) = nach den Eigenschaften Service, Kommunikation, Personal und Positionierung geordnete Menge von Erfolgsfaktoren.

  • Schlüsselfaktor (key factor) = Kombination Erfolgsfaktor/Wettbewerbsfaktor, die für den Beitrag der IT zum Unternehmenserfolg von besonderer Bedeutung ist.

  • SERVQUAL = Service Quality; Ansatz zur multiattributiven Messung der Qualität von Dienstleistungen.

  • Stichprobe (sample) = nach einem Auswahlverfahren (z. B. dem der Zufälligkeit) festgelegter Teil der Grundgesamtheit, von dem gefordert wird, dass er repräsentativ ist.

  • Totalerhebung (total survey) = Form der Querschnittsanalyse, bei der Merkmale aller Untersuchungseinheiten einer statistischen Grundgesamtheit erfasst werden.

  • Wettbewerbsfaktor (competitive factor) = den Wettbewerb kennzeichnende Eigenschaft des Marktes, in dem ein Unternehmen tätig ist (z. B. Lieferzeit, Qualität, Preis).

Zweck der Erfolgsfaktorenanalyse
Erfolgsfaktoren
Erhebungstechnik und Messmethoden
Vorgehensweise bei der Erfolgsfaktorenanalyse
Beurteilung der Erfolgsfaktorenanalyse
Weiterentwicklung der Erfolgsfaktorenanalyse

Forschungsbefunde

Kang/Bradley berichten über die Messung des IT-Erfolgs der von der IT-Abteilung angebotenen Dienstleistungen (performance measurement of IT department) in einer Fallstudie mit einem von ihnen modifizierten SERVQUAL-Ansatz, bei dem zwei „IT service dimension factors“ (entsprechen den Schlüsselbereichen der Erfolgsfaktorenanalyse), und zwar personal attributes und service attributes, verwendet werden (im Unterschied zu vier Faktoren bei SERVQUAL). Trotz mancher Einschränkungen kommen die Autoren zu dem Schluss, dass dieser Ansatz gut geeignet ist, um die Qualität von internen IT-Dienstleistungen zu messen.

Kagan, H. / Bradley, G.: Measuring the Performance of Internal Services: Is SERVQUAL the Answer? In: Neely, Aufl.. (ed.): Performance Measurement 2000. Proc. of the 2. Int. Conf. on Performance Measurement, University of Cambridge, 19.-21. July 2000, 283-290


Heinrich/Pomberger berichten über Befunde der wissenschaftlichen Begleitbeobachtung von Projekten, in denen die Erfolgsfaktorenanalyse verwendet wurde, u. a. (sieben Fallstudien mit Aktionsforschung, Untersuchungszeitraum 1998-2002):

  • Anzahl der Erfolgsfaktoren: Das Maximum ergibt sich aus der verwendeten Nummerie-rung von A bis Z. Werden mehr als 26 Erfolgsfaktoren identifiziert, sind Zusammenfassungen erforderlich, die • problemloser realisierbar sind als Weglassungen. Andererseits sollte das Maximum ausgeschöpft werden, um den Informationsgehalt der Messergebnisse zu maximieren und ihre Zuverlässigkeit bezüglich des Gesamterfolgs zu erhöhen; dies ist durch Zerlegung meist möglich. Auf den Zeitaufwand und die Durchführungskosten hat die Anzahl der verwendeten Erfolgsfaktoren kaum einen Einfluss.
  • Beurteilbarkeit: Diese wird mit der Anzahl der missing items, die mit etwa 2 % vernachlässigbar klein ist, gemessen. Die Teilnehmer sind ausdrücklich angehalten, eine Beurteilung nicht vorzunehmen, wenn die Erklärung eines Erfolgsfaktors nicht verständlich ist oder wenn sie sich als Beurteiler überfordert fühlen. Ob dieser Aufforderung nachgekommen wird, lässt sich nicht kontrollieren.
  • Messgenauigkeit: Ein quantitatives Maß dafür steht nicht zur Verfügung, so dass sich Aussagen dazu an der Zufriedenheit der Auftraggeber und der Teilnehmer an den Befragungen orientieren. Die hohe Zufriedenheit der Auftraggeber wird aus der Tatsache abgeleitet, dass die Empfehlungen zur strategischen Maßnahmenplanung zum Großteil akzeptiert und umgesetzt wurden. Die hohe Zufriedenheit der Teilnehmer (insbesondere die der Benutzer) wird aus deren Zustimmung zu den präsentierten Messergebnissen abgeleitet.
  • Durchführungskosten: Die Kosten für die externen Projektbegleiter ergeben sich aus dem Zeitaufwand, bewertet mit einem Honorarsatz. Die internen Kosten ergeben sich aus dem Zeitaufwand für die Arbeitsgruppe und die Teilnehmer an der Befragung, bewertet zu Opportunitätskosten. Die Kosten für die Durchführung einer Erfolgsfaktorenanalyse betragen – je nach Größe der Arbeitsgruppe und der Anzahl Teilnehmer – zwischen € 22.000 und € 37.000.
  • Durchführungszeitraum: Dieser wird als Differenz zwischen dem Tag, an dem die Identifizierung der Erfolgsfaktoren beginnt, und dem Tag, an dem die Ergebnisse der Erfolgsfaktorenanalyse präsentiert werden, gemessen. Das Minimum beträgt etwa vier Arbeitswochen; es wird wegen der erforderlichen Terminabstimmung zwischen den beteiligten Stakeholders und den externen Projektbegleitern nur selten erreicht. Ein Zeitraum von acht Arbeitswochen ist realistisch; dieser sollte nicht wesentlich überschritten werden.

Heinrich, L. J. / Pomberger, G.: Erfolgsfaktorenanalyse – Instrument für das strategische IT-Controlling. In: HMD 217/2001, 19-28


Demonstrationsbeispiel

Die Erfolgsfaktorenanalyse wird mit der Schlüsselfaktorenanalyse so erweitert, dass eine explizite Beziehung zwischen Eigenschaften der IT (als Erfolgsfaktoren) und Eigenschaften des Marktes (als Wettbewerbsfaktoren) hergestellt wird. Schlüsselfaktoren entstehen durch Kombination von Erfolgsfaktoren mit Wettbewerbsfaktoren. Zur übersichtlichen Darstellung dieser Kombinationen wird eine Matrix verwendet, in deren Zeilen (oder Spalten) die Erfolgsfaktoren A bis maximal Z gemäß Erfolgsfaktorenanalyse und in deren Spalten (oder Zeilen) die Wettbewerbsfaktoren 1 bis n stehen, letztere z. B. als Ergebnis der Wettbewerbsanalyse im Rahmen der strategischen Situationsanalyse, oder sie sind als Ergebnis der strategischen Unternehmensplanung bekannt. Jede Kombination Erfolgsfaktor/Wettbewerbsfaktor wird daraufhin geprüft, ob sie für den Beitrag der IT zum Unternehmenserfolg (Wertbeitrag der IT) von besonderer Bedeutung ist. Wenn ja, ist sie Schlüsselfaktor. Das Vorgehen bei der Schlüsselfaktorenanalyse entspricht ansonsten dem bei der Erfolgsfaktorenanalyse.

Bei einer Anwendung der Schlüsselfaktorenanalyse lagen 26 Erfolgsfaktoren und acht Wettbewerbsfaktorenvor, das sind 208 Kombinationen. Davon wurden 45 als Schlüsselfaktoren identifiziert. Die Abbildung zeigt die Leistungsdifferenzen, also den Unterschied zwischen Priorität und Leistung je Schlüsselfaktor. Sie könnenanalog interpretiert werden wie die Leistungsdifferenzen der Erfolgsfaktoren. Priorität und Leistung wurden durch das Top-Management aus Sicht des Gesamtunternehmens und durch das IT-Management aus Sicht des IT-Bereichs beurteilt.

ERFAN_Leistungsdifferenzen_der_Schlsselfaktoren

Abb.: Leistungsdifferenzen der Schlüsselfaktoren

Quelle

Heinrich, L. J.: Informationsmanagement – Planung, Überwachung und Steuerung der Informationsinfrastruktur. 7. A., München/Wien 2002, 392f.

Aufgabenverweise

Fallstudienverweis

Kontrollfragen

  1. Welcher Zweck wird mit der Anwendung der Erfolgsfaktorenanalyse verfolgt?

  2. Mit welchen Arbeitsschritten wird bei der Erfolgsfaktorenanalyse vorgegangen?

  3. Welche Fragen umfasst der Fragebogen für die Datenerhebung?

  4. Warum wird der IT-Erfolg sowohl aus Einzelurteilen berechnet als auch durch Befragung direkt erfasst?

  5. Wodurch unterscheiden sich Erfolgsfaktorenanalyse und Schlüsselfaktorenanalyse?

Quellen

  • Alloway, R. M.: Strategic Planning for Data Processing. Seminarunterlage des M.I.T. Industrial Liasion Program, Cambridge/Mass. 1985

  • Bayer, B.: Kann man Benutzerzufriedenheit messen? Erfahrungen bei der An­wen­dung der Erfolgsfaktorenanalyse. In: Information Management 3/1987, 6-11

  • Heinrich, L. J. / Pomberger, G.: Erfolgsfaktorenanalyse - Instrument für das strategische IT-Controlling. In: HMD - Praxis der Wirtschaftsinformatik 217/2001, 19-28

  • Heinrich, L. J.: Informationsmanagement – Planung, Überwachung und Steuerung der Informationsinfrastruktur. 7. A., München/Wien 2002, 392f.

  • Kang, H. / Bradley, G.: Measuring the Performance of Internal Services: Is SERVQUAL the Answer? In: Neely, A. (Ed.): Performance Measurement 2000. Proc. of the 2. Int. Conf. on Performance Measurement, University of Cambridge, 19.-21. July 2000, 283-290

  • Rockart, J. F.: The Changing Role of the Information Systems Executive. A Critical Success Factors Perspective. In: Sloan Management Review 1/1982, 3-13

Vertiefungsliteratur

  • Heinrich, L. J. / Häntschel, I.: Messen der Benutzerzufriedenheit - Instrument und Anwendungserfahrungen. In: Schweiggert, F. / Stickel, E. (Hrsg.): Informationstechnik und Organisation. Stuttgart 1995, 39-54

  • Heinrich, L. J. / Häntschel, I.: Messen des Erfolgs des Benutzer-Service. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 189/1996, 75-97

  • Heinrich, L. J. / Häntschel, I. / Pomberger, G.: Information Systems Diagnosis. In: Zupancic, J. (Ed.): Evolution and Challenges in System Development. New York et al. 1999, 187-197

  • Abbildungsarchiv: Erfolgsfaktorenanalyse (ERFAN)

Einführung und Grundlegung (EINGR)

Inhaltsverzeichnis[Verbergen]
Grundlegende Begriffe
Andere IM-Ansätze
Zur Einordnung in Wissenschaftsdisziplinen
Zur Gliederung des Lernstoffs

Forschungsbefunde

Schlögl berichtet als Ergebnis einer szientometrischen Studie (quantitative Analyse der IM-Kernpublikationen, Titelwortsuche, Untersuchungszeitraum 1999) zusammengefasst zu folgenden Erkenntnissen (S. 5): Sprunghaftes Ansteigen des Publikationsvolumens zu Be-ginn der 1980er Jahre. „Man kann also davon ausgehen, dass es sich bei Informationsmanagement um kein Modethema handelt.“ Mit der Autoren-Kozitationsanalyse wurden Informationswissenschaft und Wirtschaftsinformatik bzw. Information Systems (IS) als Referenzdisziplinen identifiziert. Informationswirtschaft konzentriert sich auf die Informationsinhalte; der Fokus von Wirtschaftsinformatik bzw. IS „… liegt im effektiven Einsatz von computerbasierten Informationssystemen in Organisationen (technologieorientiertes Informationsmanagement).“ Mit einer Inhaltsanalyse wurden die Ergebnisse der szientometrischen Studie verfeinert. Im Ergebnis wird u. a. festgestellt, dass die meisten Autoren aus dem Bereich Wirtschaftsinformatik bzw. IS die Auffassung vertreten, dass Informationsmanagement die Planung, Organisation und Kontrolle der IT-Infrastruktur umfasst.

 

Schlögl, Ch.: Bestandsaufnahme Informationsmanagement. Wiesbaden 2001



Teubner/Klein
formulieren folgenden Befund einer Bestandsaufnahme zum Informations-management (Inhaltsanalyse, N = 5 aktueller deutschsprachiger Lehrbücher, Erscheinungs-jahr zwischen 2000 und 2002): „Ein Konsens darüber, was eigentlich Informationsmanage-ment ist und welche Rolle ihm im Rahmen der Wirtschaftsinformatik zukommen sollte, ist nicht erkennbar.“ (S. 25) Das vorliegende Lehr- und Handbuch wird in seiner 7. Aufl. 2002 als „… das erste deutschsprachige Jehrbuch zum IM und zudem wohl auch das am stärksten rezipierte Werk“ bezeichnet. (S. 3)

 

Teubner, A. / Klein, St.: Bestandsaufnahme aktueller deutschsprachiger Lehrbücher zum Informationsmanagement. Arbeitsbericht Nr. 86 des Instituts für Wirtschaftsinformatik der Universität Münster, März 2002



Herzwurm/Stelzer
haben die Forschungsinhalte der im deutschen Sprachraum verbreiteten Wirtschaftsinformatik denen des Information Systems (IS), der im anglo-amerikanischen Raum verbreiteten Wissenschaftsdisziplin bzw. Teildisziplin des Business Administration, gegenübergestellt, u. a. mit folgenden Ergebnissen (Inhaltsanalyse anhand der nach Wissenschaftskriterien ausgewählten Zeitschriften WIRTSCHAFTSINFORMATIK und HMD bzw. MIS Quarterly und Communications of the ACM, N = 2410 zwischen 1994 und 2001 publizierte Beiträge):

• eines der beiden Top-Forschungsthemen der Wirtschaftsinformatik ist Informationsmanagement;
• in der IS-Forschung nimmt Informationsmanagement eine alle anderen Themen überragende Stellung ein.

Da von der These ausgegangen werden kann, dass sich die Wirtschaftsinformatik-Forschung in Art, Umfang und Bedeutung an Praxisproblemen orientiert, stützen diese Befunde die im Abschnitt „Zur Einordnung in Lehrgebiete“ begründete Zweckmäßigkeit, ja Notwendigkeit der angemessenen Berücksichtigung von Informationsmanagement im Lehrbetrieb. Dieses Lehr- und Handbuch hat sich in den bisherigen sieben Auflagen als ein Hilfsmittel zur Erfüllung dieser Forderung erwiesen.

 

Herzwurm, G. / Stelzer, D.: Wirtschaftsinformatik versus Information Systems – Eine Gegenüberstellung der Forschungsinhalte zweier Wissenschaftsdisziplinen. Unveröffentlichtes Manuskript. www.herzwurm.de. Abruf am 15.11.2004

Aus der Praxis

Kontrollfragen

  1. Welche Phänomene werden mit Information, Wissen und Daten sowie mit Management bezeichnet?

  2. Wie kann das Konstrukt Informationsmanagement erklärt werden?

  3. Welche Gemeinsamkeiten und welche Unterschiede bestehen zwischen der Informationsfunktion und anderen betrieblichen Funktionen?

  4. elche IM-Ansätze gibt es neben dem leitungszentrierten Ansatz und wodurch unterscheiden sie sich?

  5. Welche Bedeutung haben die sogenannten Analyseebenen für die Beurteilung des Erklärungsbedarfs eines Wissenschaftsgebiets und damit des Informationsmanagements?

Quellen

  • Biethahn, J. / Mucksch, H. / Ruf, W.: Ganzheitliches Informationsmanagement. München 1990

  • Carr, N. G.: IT Doesn't Matter. In: Harvard Business Review 5/ 2003, 41–49

  • Earl, M. (Ed.): Information Management – The Strategic Dimension. Oxford 1989

  • Erek, K. / Schmidt, N.-H. / Zarnekow, R. / Kolbe, L. M.: Nachhaltiges Informationsmanagement – Strategische Optionen und Vorgehensmodell zur Umsetzung. http://subs.emis.de/LNI/Proceedings/Proceedings154/gi-proc-154-312.pdf; Abruf 2.5.2011

  • Finkelstein, C.: Information Engineering. Strategic Systems Development. Reading/MA 1992

  • Heinrich, L. J. / Heinzl, A. / Riedl, R.: Wirtschaftsinformatik – Einführung und Grundlegung. 4. Aufl., Springer, Berlin et al. 2011

  • Herzwurm, G. / Stelzer, D.: Wirtschaftsinformatik versus Information Systems – Eine Gegenüberstellung. Ilmenauer Beiträge zur Wirtschaftsinformatik Nr. 2008-01 zugleich Stuttgarter Schriften zur Unternehmenssoftware – Arbeitsbericht Nr. 2. Ilmenau, Stuttgart 2008

  • Hosenfeld Consulting: http://www.ho-con.de/infoman.htm; Abruf 2.5.2011

  • INTARGIA Managementberatung: www.intargia.com/deutsch/veranstaltungen/targion/index.php; Abruf 5.5.2011

  • IT-Beauftragte der Bundesregierung (BfIT): 1. Newsletter zu Green-IT: http://www.umweltbundesamt.de/produkte/dokumente/newsletter_bfit_intelligente_vergabe.pdf; Abruf 2.5.2011

  • König, W. / Ludwig, J.-Ch.: Vergleichende Buchbesprechung „Informationsmanagement“. In: WIRTSCHAFTSINFORMATIK 4/1993, 405–410

  • Krcmar, H.: Informationsmanagement. 5. A., Berlin et al. 2010 14 Einführung und Grundlegung

  • Kuhlen, R.: Informationsmarkt. Chancen und Risiken der Kommerzialisierung von Wissen. Konstanz 1995

  • Martin, J.: Information Engineering. Book I Introduction. Englewood Cliffs/NJ 1989, Book II Planning & Analysis. Englewood Cliffs/NJ 1990, Book III Design Construction. Englewood Cliffs/NJ 1990

  • Mertens, P., Wirtschaftsinformatik – Von den Moden zum Trend. In: König, W. (Hrsg.), Wirtschaftsinformatik '95, Wettbewerbsfähigkeit – Innovation – Wirtschaftlichkeit. Heidelberg 1995, 25–64

  • Österle, H. / Brenner, W. / Hilbers, K.: Unternehmensführung und Informationssystem. Der Ansatz des St. Galler Informationssystem-Management. 2. A., Stuttgart 1992

  • Pfohl, H.-Chr.: Produktionsfaktor „Information“ in der Logistik. In: Institut für Logistik der Deutschen Gesellschaft für Logistik (Hrsg.): Informationssysteme in der Logistik. Dortmund 1985

  • Probst, G. J. B. / Raub, S. / Romhardt, K.: Wissen managen. Wie Unternehmen ihre wertvollste Ressource optimal nutzen. 5. A., Wiesbaden 2006

  • Renkema, T. J. W.: The IT Value Quest. How to Capture the Business Value of IT-Based Infrastructure. Chichester et al. 1999

  • Roszak, T.: Der Verlust des Denkens. Über die Mythen des Computer-Zeitalters. München 1986

  • Schmidt, N.-H. / Erek, K. / Kolbe, L. M. / Zarnekow, R.: Nachhaltiges Informationsmanagement. In: WIRTSCHAFTSINFORMATIK 5/2009, 463-466 (WI – SCHLAGWORT)

  • Schmidt-Reindl, K. M.: Informationsmanagement erobert Unternehmen und Behörden. In: GMD-Spiegel 1988, 67–72

  • Schwarzer, B. / Krcmar, H.: Zur Prozessorientierung des Informationsmanagements. In: WIRTSCHAFTSINFORMATIK 1/1995, 33–39

  • Seibt, D.: Begriff und Aufgaben des Informationsmanagements – ein Überblick. In: Preßmar, B. (Hrsg.): Informationsmanagement. Wiesbaden 1993, 3–30

  • Shannon, C. E. / Weaver, W.: Mathematical Theory of Communication. 4. Ed., Urbana/Ill. 1968

  • Szyperski , N.: Gesamtbetriebliche Perspektiven des Informationsmanagements. In: Strunz, H. (Hrsg.): Planung in der Datenverarbeitung. Von der DV-Planung zum Informations-Management. Berlin et al. 1985, 6–20

  • Teubner, A. / Klein, St.: Bestandsaufnahme aktueller deutschsprachiger Lehrbücher zum Informationsmanagement. Arbeitsbericht Nr. 86 des Instituts für Wirtschaftsinformatik der Universität Münster, März 2002

  • Wiener, N.: Cybernetics or Control and Communication in the Animal and the Machine. Boston 1948

  • Wilder, R. P.: The Continuing Revolution of Information Systems Planning. In: Strunz, H. (Hrsg.): Planung in der Datenverarbeitung. Von der DV-Planung zum Informations-Management. Berlin et al. 1985, 21–37

  • Wittmann, W.: Information. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Stuttgart 1980, 894–904

  • Zarnekow, R.: Produktorientiertes Informationsmanagement. In: Zarnekow, R. / Brenner, W. / Grohmann, H. (Hrsg.): Informationsmanagement. Konzepte und Strategien für die Praxis. Heidelberg 2004, 41–56

  • Zarnekow, R. / Brenner, W. / Pilgram, U.: Integriertes Informationsmanagement. Berlin/Heidelberg 2005

Vertiefungsliteratur

  • Beier, D.: Informationsmanagement aus Sicht der Betriebswirtschaftslehre. Frankfurt a. M. et al. 2002

  • Hochstein, A. / Brenner, W. / Uebernickel, F.: Operations Management and IS. In: Proceedings oft he Twelfth Ammericas Conference on Information Systems. Acapulco, Mexiko, August 2006

  • Leimstoll, U.: Informationsmanagement in mittelständischen Unternehmen. Frankfurt a. M. et al. 2001

  • Peterhans, M.: Informationsmanagement – Theoretische Grundlagen und Führungskonzept. Zürich 1996

  • Pietsch, T. / Martiny, L. / Klotz, M.: Strategisches Informationsmanagement. Bedeutung und organisatorische Umsetzung. 4. A., Berlin 2004

  • Voß, St. / Gutenschwager, K.: Informationsmanagement. Berlin et al. 2001

  • Schlögl, C.: Bestandsaufnahme Informationsmanagement. Wiesbaden 2001

  • Stickel, E.: Informationsmanagement. München/Wien 2001

  • Teubner, A. / Klein, St.: Vergleichende Buchbesprechung „Informationsmanagement“. In: WIRTSCHAFTSINFORMATIK 4/2002, 285–299

  • Wall, F.: Informationsmanagement – Eine ökonomische Integration von Controlling und Wirtschaftsinformatik. München 2006

Links

Datenmanagement (DATEM)

Inhaltsverzeichnis[Verbergen]

Lernziele

Sie kennen den Zweck des Datenmanagements und seine Aufgaben. Sie wissen, welche Funktionen ein Data Warehouse für das Business Intelligence übernimmt und wie unstrukturierte Daten für betriebliche Entscheidungen zugänglich gemacht werden können. Sie kennen die Bedeutung von Metadaten für das Datenmanagement. Sie wissen, mit welchen Merkmalen Datenqualität spezifiziert werden kann und kennen Aufgabenträger des Datenmanagements.

Definitionen und Abkürzungen

  • BI = Business Intelligence.

  • Data Dictionary = Datenkatalog; System zur Verwaltung von Metadaten.

  • Daten (data) = Information, die zum Zweck der Verarbeitung formalisiert dargestellt ist und aus der andere Information abgeleitet werden kann.

  • Datenbanksystem (database system) = Kombination aus einem DBMS und einer oder mehreren Datenbanken.

  • Datenmodell (data model) = Beschreibung des Inhalts, der Struktur und der Bedeutung von Daten, in der Regel mit der Entity-Relationship-Notation.

  • Datenqualität (data quality) = Gesamtheit der Anforderungen an Daten.

  • Datensystem (data system) = Abbildung der Wirklichkeit in Daten für die Aufgaben eines Unternehmens.

  • DBMS = Database Management System; Datenbankmanagementsystem. Synonym: Datenbankverwaltungssystem.

  • DW = Data Warehouse; 1993 von Inmon geprägte Bezeichnung für eine von den operativen Datenbeständen getrennte, integrierte Datenbasis zur Entscheidungsunterstützung.

  • FASMI = Fast Analysis of Shared Multidimensional Information; 1995 von Pendse/Creeth geprägter Begriff zur Charakterisierung von OLAP.

  • Metadaten (meta data) = Daten, mit denen Nutzdaten beschrieben werden.

  • OLAP = Online Analytical Processing; 1993 von Codd/Codd/Salley geprägter Begriff zur multidimensionalen Analyse von Daten in DW.

  • OLTP = Online Transaction Processing; transaktionsorientierte Verarbeitung von Daten in operativen Datenbanksystemen.

  • OMG = Object Management Group; Konsortium von IT-Herstellern, das Standards für die herstellerunabhängige Entwicklung von Informationssystemen verfasst.

  • SQL = Structured Query Language; Datenbanksprache für relationale Datenbanken.

  • strukturierte Daten (structured data) = Daten, für deren Elemente eine bestimmte Anordnung bzw. Struktur vorgeschrieben ist (z. B. in operativen Datenbanken oder DW). Synonym: formatierte Daten.

  • unstrukturierte Daten (unstructured data) = Daten, für deren Elemente keine bestimmte Anordnung bzw. Struktur vorgeschrieben ist (z. B. Texte, Grafiken, Präsentationen, Tabellenkalkulationen, Videos, Audios). Synonyme: unformatierte oder formatfreie Daten.

Zweck des Datenmanagements
Ziele und Aufgaben des Datenmanagements
Business Intelligence
Metadatenmanagement
Datenqualität
Aufgabenträger des Datenmanagements

Forschungsbefunde

Unger/Kemper berichten über Ergebnisse einer Studie zur Verbreitung selbstständiger BI-Organisationseinheiten sowie Charakteristika ihrer organisatorischen Implementierung (internetbasierte Online-Umfrage unter Mitarbeitern deutscher Unternehmen, „die eine hohe Affinität zum Themenbereich Business Intelligence bzw. Data Warehousing aufweisen“; 403 auswertbare Antworten; Rücklaufquote 49,6 %; Untersuchungszeitraum 2006):
75 % der Unternehmen (bezogen auf 326 Antworten) entwickeln und betreiben bereits seit vier und mehr Jahren integrierte BI-Lösungen.
Unter den eingesetzten BI-Lösungen (318 Antworten, Mehrfachnennungen möglich) dominieren Berichtssysteme (89 %) und Ad-hoc-Analysesysteme (82 %). Des Weiteren finden modellgestützte Analysesysteme (45 %), freie Datenrecherchen (49 %) sowie auf betriebswirtschaftlichen Konzepten beruhende Systeme (46 %) Anwendung.
24 % der Unternehmen (bezogen auf 403 Antworten) sehen keine Notwendigkeit, eine BI-Organisationseinheit einzuführen. 76 % verfügen über eine entsprechende Einheit oder planen ihre Einführung (Einheit bei 65 % existent, bei 11 % in Planung).
Es besteht ein statistisch signifikanter Zusammenhang zwischen Unternehmensgröße und Existenz bzw. Planung von BI-Organisationseinheiten. Die befragten Unternehmen sehen zwar mehrheitlich eigenständige BI-Organisationseinheiten als erforderlich an, allerdings treiben insbesondere große und sehr große Unternehmen die Etablierung solcher Einheiten voran.
In 71 % der Unternehmen (bezogen auf 288 Antworten) sind die BI-Einheiten dem IT-Bereich zugeordnet. In 14 % sind eigenständige Einheiten direkt unterhalb der Geschäftsführungsebene implementiert. Bei 15 % der Unternehmen ist die Einheit einem betrieblichen Fachbereich zugeordnet. Kleinere Unternehmen (Umsatz < 100 Mio. Euro) bevorzugen eine Integration direkt unterhalb der Geschäftsführungsebene. Mit zunehmender Größe der Unternehmen wächst die Tendenz, die BI-Einheiten als Bestandteil der zentralen IT-Bereiche zu integrieren.
30 % der Unternehmen geben an, bis 100 Gigabyte Datenvolumen der BI-Datenhaltung zu betreuen, 25 % 101 bis 1000 Gigabyte, 31 % 1 bis 5 Terabyte und 14 % > 5 Terabyte.
Die Unternehmensberatung Accenture untersuchte Datenmanagement und BI in Europa und Nordamerika (Web-gestützte Befragung von 162 CIOs im März 2007; 63 % in multinationalen, 27 % in nationalen Großunternehmen, keine Angaben zu Grundgesamtheit und Untersuchungszeitraum). 29 % der Befragten geben an, lediglich minimale Anstrengungen zur Verbesserung der Datenqualität unternommen zu haben. 55 % berichten über Programme zur Sicherstellung der Datenqualität in einzelnen Systemen mit kritischen Daten. Nur in 16 % der befragten Unternehmen ist Datenqualität zentraler Bestandteil des Datenmanagements. Allerdings geben 78 % der Befragten an, letzteres in den nächsten drei Jahren realisieren zu wollen. 34 % berichten, Stammdaten nicht über die Grenzen einzelner Anwendungssysteme hinaus zu managen, obwohl 27 % der Unternehmen über ein unternehmensweites Stammdatenmanagement verfügen. 98 % der Befragten wollen innerhalb von drei Jahren ein Stammdatenmanagement implementiert haben, 75 % geben an, dass dies unternehmensweit gültig sein soll. Lediglich in 10 % der befragten Unternehmen gibt es ein wirksames Programm zum Metadatenmanagement. 52 % berichten, keine nennenswerten Bemühungen zur Planung und Steuerung sowie zum Qualitätsmanagement von Metadaten zu unternehmen. 57 % gehen davon aus, dass BI in den nächsten drei Jahren als entscheidender Faktor genutzt wird, um sich von Wettbewerbern abzusetzen, allerdings nutzten 61 % der befragten Unternehmen zum Zeitpunkt der Untersuchung BI noch nicht, um Wettbewerbsvorteile zu erzielen. 39 % der Unternehmen sind lediglich in der Lage, einfache Berichte zu erzeugen, weitere 39 % können Daten nur in einzelnen, eng abgegrenzten Systemen („Silos“) auswerten. Lediglich 22 % geben an, unternehmensweite umfassende Analysen mit betrieblichen Daten durchführen zu können. 76 % der Befragten streben an, innerhalb von drei Jahren unternehmensweite Datenanalysen durchführen zu können.

Accenture: Cultivating high performance through information management. Findings from the Accenture CIO survey 2007: Business intelligence. 2008. http://www.accenture.com; Abruf: 10. Juni 2011

Accenture: Cultivating high performance through information management. Findings from the Accenture CIO survey 2007: Data management and architecture. 2008. http://www.accenture.com; Abruf: 10. Juni 2011


Marcolini berichtet über Ergebnisse von Tests mit großen Datenbeständen, die zeigen, dass das Datenvolumen durch Komprimierung bei Anwendung stringorientierter Methoden auf 55 % bis 60 % reduziert werden kann. Bei Anwendung vertikaler, strukturorientierter Methoden kann das Datenvolumen auf 20 % bis 25 % reduziert werden.

Marcolini, M.: Komprimieren mit FLAM. In: COM – Siemens Computermagazin 6/1986, 41-42


Wang/Kon haben ein Rahmenkonzept für Total Data Quality Management mit den Dimensionen „components of the continuous data quality enhancement process“ (MAI = Measurement, Analysis, Improvement) und „perspectives on which to base solutions“ (ETO = Economics, Technology, Organizations) entwickelt. In empirischen Studien stellten die Autoren u. a. fest, dass 77 % der Liefermängel, die zu einem Umsatzverlust von rd. 1 Mio. US$ führten, auf mangelhafte Datenqualität zurückzuführen waren.
Wang, R. Y. / Kon, H. B.: Toward Total Data Quality Management (TDQM). In: Wang, R. Y. (Ed.): Information Technology in Action. Englewood Cliffs/NY 1993, 179-200


Neumann et al. haben mit dem folgenden Ergebnis den Migrationsaufwand ermittelt und mit dem Aufwand für eine komplette Neuentwicklung verglichen (Fallstudie, 53 ADABAS-Dateien mit rd. 1500 Anwendungen): Der Migrationsaufwand beträgt fünf, der Aufwand für die Neuentwicklung 20 Personenjahre. Mit dem vorgeschlagenen Portierungsmodell wird also eine Aufwandsreduzierung um den Faktor 4 gegenüber der Neuentwicklung erreicht.
Neumann, K. / Koschel, A. / Porscha, W.: Eine Portierungsstrategie für ADABAS-Datenbestände und -Anwendungen nach DB2. In: WIRTSCHAFTSINFORMATIK, 4/1993, 339-345


Schlögl berichtet über die Ergebnisse einer empirischen Untersuchung zum Datenmanagement u. a. (Stichprobenanalyse, N = 11, Interviewtechnik, Untersuchungszeitraum Mitte 1994): Eine unternehmensweite Informationsbedarfsplanung wird in fünf Unternehmen durchgeführt; in zwei Unternehmen existiert ein unternehmensweites Datenmodell; fünf Unternehmen haben Datenelemente-Standards entwickelt; fünf Unternehmen verwenden ein Datenkatalog-System.
Schlögl, Ch.: Ausprägungsgrad des Datenmanagements in steirischen Großunternehmen. In: In: Rauch, W. et al. (Hrsg.): Mehrwert von Information – Professionalisierung der Informationsarbeit. Konstanz 1994, 527-535


Jeusfeld/Jarke berichten über ein Forschungsprojekt, das sich mit Qualitätsmanagement in Data Warehouses beschäftigt. Ein erstes Ergebnis ist eine Variante des Goal-Question-Metric-Ansatzes, die über die Metadatenbank des Data Warehouses operationalisiert wird. Ziel ist eine Entwurfsmethode, mit der ein Data Warehouse so entworfen wird, dass die Qualitätsforderungen der Beteiligten berücksichtigt werden. Dazu ist zunächst ein Rahmenkonzept erforderlich, mit und in dem die Qualitätsforderungen formuliert und ihr gegebener Erfüllungsgrad analysiert werden kann.
Jeusfeld, M. A. / Jarke, M.: Qualitätsanalyse im Data Warehousing. Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!. Abruf am 11.10.2004


Röthlin berichtet über die Ergebnisse einer Studie zum Datenqualitätsmanagements in ERP-Systemen (schriftliche Befragung Schweizer ERP-Anbieter, N = 111, R rd. 45 %). Themen waren die Relevanz der Datenqualität, der Marktauftritt in Bezug auf Datenqualität, technische und betriebliche Einflussfaktoren auf die Datenqualität sowie die Verbreitung von Sicherungsmaßnahmen. Die Studie zeigt, dass Datenqualität im Marktauftritt der ERP-Anbieter eine wichtige Rolle spielt; ERP wird mit hoher Datenqualität assoziiert. Bei den Einflussfaktoren auf die Datenqualität zeigte sich, dass Benutzerschulung als wichtigste Einflussgröße angesehen wird, gefolgt von Support Organisation und Dokumentation.

Röthlin, M.: Datenqualitätsmanagement in ERP-Systemen von Schweizer Unternehmen. Arbeitsbericht 156, Institut für Wirtschaftsinformatik der Universität Bern, 12/2003

Aus der Praxis

Hill/Ariyachandra/Frolick berichten, dass 50 bis 60 % der Projekte zur Einführung von DW in Unternehmen nicht zum geplanten Termin fertiggestellt werden, die Plankosten überschreiten und/oder nicht die geforderte Qualität erreichen. Auf der Grundlage von publizierten Erfahrungen mit Projekten formulieren sie zehn Prinzipien die zum Scheitern von DW-Projekten beitragen:

  1. Implementierung eines DW ohne Berücksichtigung der Unternehmensziele sowie ohne Unterstützung durch Führungskräfte (create now, strategize later).

  2. Implementierung eines DW für einen aktuellen, spezifischen BI-Bedarf und nicht zur Deckung von sich mittel- bis langfristig entwickelnden Informationsbedarfen (build the DW as a solution to a specific BI project/need).

  3. Implementierung eines DW ohne Machbarkeitsstudie oder Pilotprojekt (save time and money: skip the pilot/proof of concept).

  4. Entwicklung eines DW als umfangreichen, zentralisierten Datenbestand, bei gleichzeitiger Vernachlässigung anwendungsspezifischer Segmente (Data-marts) (assume users will patiently wait for the release).

  5. Sparsame Kommunikation über Projektziele und Projektfortschritt mit Auftraggebern und DW-Anwendern (with project management communication, less is more).

  6. fehlende oder mangelhafte Analyse von Kosten und Nutzen des DW (don’t worry about what erveryone else is doing).

  7. Ignorieren von Warnzeichen, insbesondere mangelnde Unterstützung durch Führungskräfte und fehlende Akzeptanz der Nutzer (run the red lights or do not stop at checkpoints).

  8. Fällen wichtiger Entscheidungen ausschließlich durch IT-Fachleute statt durch alle an der DW-Implementierung beteiligten Interessengruppen (delegate all technology decisions to IT).

  9. Unterschätzung des Aufwands für das Extrahieren, Transformieren und Laden (ETL) von Daten aus operativen Systemen in das DW (there’s no need to get into the weeds with something like ETL development).

  10. Beauftragung von preisgünstigen, aber wenig erfahrenen Beratern und Softwarelieferanten sowie Nutzung von unausgereiften Softwareprodukten (choose a low-cost consultant/vendor).

Hill, A. / Ariyachandra, T. / Frolick, M.: 10 Principles to Ensure Your Data Warehouse Implementation is a Failure. In: International Journal of Business Intelligence Research 2/2011, 37-47


Wixom et al. beschreiben Erfahrungen mit dem DW-gestützten BI bei der amerikanischen Fluggesellschaft Continental Airlines. In diesem Unternehmen wird seit 1998 ein DW betrieben, ursprünglich zur Unterstützung der Preisgestaltung und zur Auswertung von Daten aus einem Vielfliegerprogramm, später auch zur Analyse von Lohn- und Gehaltsdaten sowie im Rahmen des Qualitätsmanagements bzw. der Betriebssicherheit. Das DW stellt Daten für 70 Anwendungen und 1400 Anwender in über 75 Niederlassungen weltweit bereit. Ein Team von 15 Mitarbeitern betreibt, wartet und erweitert das DW. Wixom et al. fassen folgende Empfehlungen zusammen, die aus Erfahrungen mit BI im Laufe von zehn Jahren bei Continental Airlines gesammelt wurden: Es sollten standardisierte Namenskonventionen, normalisierte Datenstrukturen und benutzerfreundliche, einfach verständliche Metadaten verwendet werden. Abgesehen von wenigen Ausnahmen (z. B. Lohn- und Gehaltsdaten oder Kreditkartennummern von Passagieren) sollten Nutzer des DW Zugriff auf alle Daten erhalten, um möglichst flexibel Analysen betreiben zu können. Daten sollten als Vermögensgegenstand des Unternehmens betrachtet und entsprechend sorgfältig behandelt werden. Mitarbeiter eines DW-Teams sollten sowohl fundierte Datenbankkenntnisse als auch Erfahrungen in den Anwendungsbereichen haben, welche die Daten nutzen.
Laut einer Untersuchung von The Data Warehouse Institute (zitiert nach Computer Zeitung 38/2007, 8) ist der Kunde das am häufigsten in Stammdaten definierte Objekt. In der Regel wird der Begriff Kunde von verschiedenen Fachabteilungen eines Unternehmens unterschiedlich verstanden. So definiert der Versand z. B. Personen und Organisationen, an die ein Produkt versendet worden ist, als Kunden, während in der Buchführung nur Rechnungsempfänger als Kunden bezeichnet werden. 13 % der Untersuchungsteilnehmer geben an, dass es in ihrem Unternehmen nur eine Definition von Kunde gibt. 50 % berichten über ca. zehn verschiedene Definitionen, 19 % über 50 oder mehr Definitionen von Kunde in ihrem Unternehmen. Eine ähnliche Begriffsvielfalt gibt es bei Stammdaten zu Produkten, Mitarbeitern und Lieferanten. Dies bedingt, dass Stammdatenmanagement in erster Linie als Aufgabe der Fach- und erst in zweiter Linie als Aufgabe der IT-Abteilungen verstanden werden muss.

Methodenverweise

Fallstudienverweis

Kontrollfragen

  1. Welche Argumente stützen die Behauptung, Daten seien ein wirtschaftliches Gut?
  2. Worin besteht der Unterschied zwischen OLAP und Data Mining?
  3. Welche Ziele werden mit Business Intelligence verfolgt?
  4. Wie lässt sich Metadatenmanagement wirtschaftlich rechtfertigen?
  5. Mit welchen QM-Maßnahmen kann der Forderung nach angemessener Datenqualität entsprochen werden?
  6. Worin besteht der Zweck des Datenmanagements?
  7. Welche Aufgaben des Datenmanagements lassen sich unterscheiden?
  8. Worin besteht der Unterschied zwischen OLAP und Data Mining?
  9. Welche Funktion haben Metadaten im Datenmanagement?
  10. Mit welchen Attributen kann Datenqualität beschrieben werden?

Quellen

  • Accenture: Cultivating high performance through information management. Findings from the Accenture CIO survey 2007: Business intelligence. 2008. http://www.accenture.com; Abruf: 10. Juni 2011

  • Accenture: Cultivating high performance through information management. Findings from the Accenture CIO survey 2007: Data management and architecture. 2008. http://www.accenture.com; Abruf: 10. Juni 2011

  • Becker, J. / Rosemann, M. / Schütte, R.: Grundsätze ordnungsmäßiger Modellierung. In: WIRTSCHAFTSINFORMATIK 5/1995, 435–445

  • Chamoni, P. / Gluchowski, P.: Analytische Informationssysteme: Business Intelligence-Technologien und Anwendungen 3. A., Berlin/Heidelberg/New York 2006

  • Chaudhuri, S. / Dayal, U.: An Overview of Data Warehousing and OLAP Technology. In: ACM SIGMOD Record 1/1997, 65–74

  • Chen, P. P.-S.: Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned. Lecturing Notes in Computer Sciences. In: Broy, M. / Denert, E. (Hrsg.): Software Pioneers: Contributions to Software Engineering. Berlin 2002, 100–114

  • Chen, P. P.-S.: The Entity-Relationship Model - Toward a Unified View of Data. In: ACM Transactions on Database Systems 1/1976, 9–36

  • Codd, E. F. / Codd, S. B. / Salley, C. T.: Providing OLAP to User-Analysts: An IT Mandate. Ann Arbor 1993

  • Dippold, R. et al.: Unternehmensweites Datenmanagement. Von der Datenbankadministration bis zum Informationsmanagement. 4. A., Braunschweig/Wiesbaden 2005

  • Dumslaff, U. / Lempp, P.: Studie IT-Trends 2011. Zukunft sichern in der Krise. Berlin 2011. http://www.de.capgemini.com; Abruf 15. Juni 2011

  • Feldman, S.: The high cost of not finding information. 2004. http://www.kmworld.com; Abruf: 10. Juni 2011

  • Feldman, S. et al.: The Hidden Costs of Information Work. IDC Whitepaper. Framingham 2005. http://www.interwoven.com; Abruf: 10. Juni 2011

  • Hawking, D.: Challenges in enterprise search. In: Schewe, K.-D. / Williams, H. (Hrsg.): Proceedings of the Fifteenth Australasian Database Conference. Dunedin, New Zealand 2004, 15–24

  • Hill, A. / Ariyachandra, T. / Frolick, M.: 10 Principles to Ensure Your Data Warehouse Implementation is a Failure. In: International Journal of Business Intelligence Research 2/2011, 37–47

  • Inmon, W. H.: Building the Data Warehouse. 4. A., Indianapolis 2005

  • Kappelman, L. A.: Some Strategic Y2K Blessings. In: IEEE Software 2/2000, 42-46

  • Kemper, H.-G. / Mehanna, W. / Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen. Eine Einführung in die IT-basierte Managementunterstützung. 2. A., Wiesbaden 2006

  • Naumann, F.: Datenqualität. In: Informatik Spektrum 1/2007, 27–31

  • o.V.: Firmen gehen Management von Stammdaten oft falsch an. In: Computer Zeitung 38/2007, 8

  • Pendse, N. / Creeth, R.: The OLAP Report. New York 1995

  • Röthlin, M.: Management of Data Quality in Enterprise Resource Planning Systems. Lohmar, Köln 2010

  • Rohweder, J. P. et al.: Informationsqualität - Definitionen, Dimensionen und Begriffe. 2007. http://www.dgiq.de, Abruf: 22.05.2008

  • Unger, C. / Kemper, H.-G.: Organisatorische Rahmenbedingungen der Entwicklung und des Betriebs von Business Intelligence – Ergebnisse einer empirischen Studie. In: Bichler, K. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2008. Berlin 2008, 141–153

  • Wang, R. / Strong, D.: Beyond Accuracy: What Data Quality Means to Data Consumers. In: Journal of Management Information Systems 4/1996, 5–34

  • Wixom, B. H. et al.: Continental Airlines Continues to Soar with Business Intelligence In: Information Systems Management 2/2008, 102–112

Vertiefungsliteratur

  • Baars, H. / Kemper, H.-G.: Management Support with Structured and Unstructured Data - An Integrated Business Intelligence Framework. In: Information Systems Management 2/2008, 132–148

  • Devlin, B.: Data warehouse: from architecture to implementation. 6. A., Reading 2000

  • Elmasri, R. / Navathe, S. B.: Grundlagen von Datenbanksystemen. 3. A., München 2002

  • Eppler, M. J.: Managing Information Quality. Increasing the Value of Information in Knowledge-intensive Products and Processes. Berlin, Heidelberg 2003

  • Salton, G. / McGill, M. J.: Information Retrieval - Grundlegendes für Informationswissenschaftler. Hamburg et al. 1987

  • Stock, W. G. / Stock, M.: Wissensrepräsentation. Informationen auswerten und bereitstellen. München 2008

  • Vetter, M.: Aufbau betrieblicher Informationssysteme mittels pseudo-objektorientierter, konzeptioneller Datenmodellierung. 8. A., Stuttgart 1998

Informationsmaterial

Normen

  • ISO 15836:2009 Information and documentation - The Dublin Core metadata element set

  • ISO/IEC 19502:2005 Information technology - Meta Object Facility (MOF)

  • ISO/IEC 19503:2005 Information technology - XML Metadata Interchange (XMI)

Controlling (CONTR)

Inhaltsverzeichnis[Verbergen]

Lernziele

Sie kennen den Zweck des IT-Controllings einschließlich der Prozesse zur Schaffung, Aufrechterhaltung und Nutzung der Informationsinfrastruktur. Sie kennen die Funktionen des Controllings und können sie erläutern. Sie kennen die Gliederung der Grundfunktion in Teilfunktionen. Sie wissen, wie Controlling-Objekte gebildet werden. Sie können alternative Organisationskonzepte des IT-Controllings erläutern und ihre Eignung beurteilen. Sie kennen Unterschiede und Gemeinsamkeiten von Controlling und Revision.

Definitionen und Abkürzungen

  • Abweichung (deviation) = Unterschied zwischen dem Wert eines Attributs im Sollzustand und dem Wert desselben Attributs im Istzustand.

  • IFRS = International Financial Reporting Standards; Sammlung von Regeln für die Rechnungslegung zwecks internationaler Vergleichbarkeit von Jahresabschlüssen.

  • Kontrolle (inspection) = Teil der betrieblichen Aufgabe Überwachung, welcher der Beobachtung des tatsächlichen Verhaltens und seiner Beurteilung anhand von Verhaltenserwartungen durch prozessunabhängige Personen dient.

  • Koordination (coordination) = Abstimmung der Tätigkeiten mehrerer Aufgabenträger, zwischen deren Aufgaben Interdependenz besteht.

  • Messen (measuring) = Zuordnen von Zahlen oder anderen Symbolen zu Eigenschaften von Objekten, Ereignissen oder Situationen nach einem festgelegten Verfahren.

  • Messgröße (measuring figure) = Eigenschaft eines Objekts, deren Ausprägung mit einer Messmethode ermittelt werden kann. Synonym: Metrik.

  • Messgrößentransformation (measuring figure transformation) = Vorschrift zum Überführen von Messgrößen in einen Wert, der mit dem Sollwert des Controlling-Ziels verglichen werden kann.

  • Messinstrument (measuring instrument) = organisatorisches, hardwaremäßiges und/oder softwaremäßiges Werkzeug zum Messen.

  • Messobjekt (measuring entity) = Element des Controlling-Objekts (z. B. IT-Abteilung), das den Zielinhalt des Messziels beschreibt (z. B. Personalkosten).

  • Messpunkt (measuring point) = Stelle eines Messobjekts, an der eine Messgröße erfasst werden kann (z. B. Projekttagebuch).

  • Messmethode (measuring technique) = Verfahren zum Messen (z. B. Messen der Komplexität von Software mit dem Function-Point-Verfahren).

  • Messziel (measuring goal) = operationales und für bestimmte Messzwecke wirtschaftlich verwendbares Ziel (z. B. Wirtschaftlichkeit).

  • Metrik (metric) = Synonym für Messgröße.

  • Steuerung (control) = betriebliche Aufgabe, die mit geeigneten Maßnahmen auf Abweichungen reagiert, um die bei der Planung getroffenen Entscheidungen durchzusetzen.

  • Überwachung (monitoring) = betriebliche Aufgabe der Beobachtung und Beurteilung, die in die Teilaufgaben Revision und Kontrolle gegliedert ist.

Zweck des Controllings
Controlling-Objekte
Controlling-Aufgaben
Organisation des Controllings
Projektcontrolling und Projektplanung
Controlling-Instrumente
Controlling und Revision

Forschungsbefunde

Schöne hat zum Entwicklungsstand (besser gesagt: zur Verbreitung) des IT-Controllings in deutschen Großunternehmen Folgendes festgestellt (schriftliche Befragung, N = 436, R = 16,3 %, Untersuchungszeitraum 12/1992 bis 3/1993): „Über die Hälfte“ der Unternehmen haben ein IT-Controlling, davon 3 % „auf hohem Niveau“. 23 % sind dabei, IT-Controlling zu implementieren. 8 % befinden sich in einer Konzeptionsphase. 3 % geben an, die Einführung langfristig zu planen. Unklare Vorstellungen oder keine Pläne haben 7 %. Ergebnisse einer aktuellen Vergleichsstudie sind nicht bekannt.
Schöne, K.: Controlling der Informationsinfrastruktur. Entwicklungsstand, Gestaltungskon­zep­tion, Perspektiven. Wiesbaden 1997

Spitta bezweifelt den behaupteten Wahrheitswert derartiger Befunde wegen der bei der Befragung verwendeten Fragetechnik („Abfrage von Meinun­gen“). Mit einer eigenen Befragung wird auf Faktenerhebung abgezielt (nur geschlossene Fragen, nur wenige Einschätzungen abgefragt, keine Schätzungen quantitativer Daten, N = 244 mittelständische Industrie­unternehmen im Raum Ostwestfalen-Lippe, R = 38,8 %, Untersuchungszeitraum 1996). Als Befunde werden berichtet: Die organisatorische Einbindung des IT-Controllings oder wenigstens die Existenz einer zentralen formalen Aufgabe mit diesem Namen ist schwach ausgeprägt. Nur 19 Unternehmen betreiben IT-Controlling „durch das [Unternehmens-] Controlling“ (6) oder „durch Controlling und IT-Bereich“ (13) gegenüber 76 Unternehmen, die „niemand“ (31) oder „IT-Bereich“ (45) genannt haben. Das daraus erkennbare, überwiegende Selbstcontrolling ohne zentrale Anbindung wird vom Autor als insgesamt schwache Ausprägung des Controlling-Gedankens interpretiert. (Vgl. auch die in Lern­einheiten KENNZ und KOLER berichteten Befunde.)
Spitta, T.: IV-Controlling in mittelständischen Industrieunternehmen – Ergebnisse einer empirischen Studie. In: WIRT­SCHAFTSINFORMATIK 5/1998, 424-433

Heise et al. erweiterten eine Unternehmensmodellierungsmethode um Konzepte zur Unterstützung des IT-Controllings mit dem Ziel, die Transparenz der Wirkungen des IT-Einsatzes zu erhöhen. Dazu unterstützt die Methode u. a. die Identifizierung, Zuordnung und Bewertung von IT-Kosten und IT-Nutzen zu Geschäftsprozessen und IT-Ressourcen. Durch Berücksichtigung unterschiedlicher Perspektiven verspricht die Methode, die Kommunikation zwischen IT-Management, IT-Controlling und Fachabteilungen zu verbessern.

Heise, D. et al.: Erweiterung einer Unternehmensmodellierungsmethode zur Unterstützung des IT-Controllings. In: Bichler, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik. Berlin 2008, 1017-1028


Roithmayr stellt u. a. fest (Feldstudien in 13 Unternehmen, Untersuchungszeitraum 1981-1985), dass „situationsgerechte Messvorschriften“ häufig fehlen; meist sind auch die Ziele für die Planung, Überwachung und Steuerung der IT auf allen drei Managementebenen nicht oder nicht umfassend genug gesetzt. Heinrich/Sterrer kommen zum gleichen Ergebnis (Interviewmethode, N = 12 EDV-Leiter in 12 Unternehmen in Oberösterreich, Untersuchungszeitraum 1985).

Roithmayr, F.: Controlling von Informations- und Kommunikationssystemen. München/Wien 1988
Heinrich, L. J. / Sterrer, G.: Ziele von Informationssystemen – Ergebnisse einer empirischen Studie. In: Information Management 1/1987, 48-53


Krcmar berichtet über den Stand des IV-Controlling in Deutschland u. a. (Stichprobenanalyse, schriftliche Befragung N = 206, Untersuchungszeitraum 1991): IV-Controlling wird überwiegend als Instrument zur Unterstützung strategischer Unternehmensziele verstanden, also als Verbindungsglied zwischen Unternehmensstrategie und Informationsverarbeitung. Bezüglich der Controlling-Objekte stehen die Ressourcen Information, Personal und Software einschließlich ihrer Beschaffungsprozesse, die Bereitstellung eines Berichtssystems sowie die Beurteilung der geplanten und vorhandenen Informationssysteme bezüglich ihrer strategischen Relevanz im Vordergrund. Zum Stand der Implementierung des IV-Controlling wird festgestellt: Nur 12,6 % verfügen über jahrelange Erfahrung, 50,5 % haben IV-Controlling „ansatzweise“ implementiert und 31,1 % haben die Notwendigkeit der Implementierung erkannt.

Krcmar, H.: Informationsverarbeitungs-Controlling. In: Information Management 2/1992, 6-18


Suter kommt auf Grund einer Untersuchung Schweizer Unternehmen, in denen der IV-Bereich lediglich Unterstützungsfunktion hat, u. a. zu folgenden Ergebnissen (Fragebogenmethode, N = 120, R = 53 %, Untersuchungszeitraum 1993): Über 50 % der Befragten befanden sich in der Entwicklungsphase für ein IV-Controlling, rd. 7 % verfügten über längere Erfahrungen, rd. 43 % hatten kein IV-Controlling und planten kurzfristig keine Einführung, was den Einsatz einzelner Controlling-Instrumente aber nicht ausschließt.


Weber untersuchte den Einfluss persönlicher Faktoren auf das Controlling und das Zusammenspiel zwischen Führungskraft und Controller (parallele schriftliche Befragung von Führungskräften und Controllern). Es zeigten sich deutliche Abweichungen zwischen Eigenwahrnehmung und Fremdwahrnehmung. Unter den Aufgaben, bei denen Controller Führungskräfte vorrangig unterstützen, wird Bereitstellung von Informationssystemen genannt. Führungskräfte schätzen Controller überwiegend als „bremsend“ und „kleinlich“ ein („Erbsenzähler“); Controller sehen in Führungskräften Macher und Promotoren, die emotional und mit einer Vorliebe für intuitive Beurteilung von Zusammenhängen ihre Unternehmen führen. Mit den Leistungen ihrer Controller sind Führungskräfte überwiegend zufrieden; in großen Unternehmen (über 5.000 Mitarbeiter) ist die Zufriedenheit deutlich geringer als in kleinen Unternehmen, was primär auf die geringere „Intensität der Zusammenarbeit zwischen Führungskraft und Controller“ zurückzuführen ist; diese kann folglich als ein Erfolgsfaktor des Controlling bezeichnet werden.
Weber, J.: Einführung in das Controlling. 10. Aufl., Poeschel, Stuttgart 2004, zitiert nach F.A.Z. vom 5.6.2000, 32

Aus der Praxis

Methodenverweise

Kontrollfragen

  1. Welche Überlegungen sind für das Festlegen von Controlling-Objekten relevant?

  2. Aus welchen Elementen besteht das Aufgabensystem des Controllings?

  3. Welche Arbeitsschritte kennzeichnen das Vorgehen beim Entwickeln von Messmethoden?

  4. Welche Anforderungen an die Qualifikation von Controllern stellt die erfolgreiche Wahrnehmung der Innovationsaufgabe des Controllings und über welche Kompetenz müssen sie verfügen?

  5. Wie ist der Stand der Forschung zum IT-Controlling zu beurteilen und welche Forschungsfragen oder Forschungsgegenstände sind beispielsweise zu beantworten bzw. zu bearbeiten?

  6. Welche Objekte sind für das IT-Controlling typisch?

  7. In welche Teilaufgaben wird die Grundfunktion des Controllings gegliedert?

  8. Was bedeutet die Koordinationsfunktion des Controllings?

  9. Was bedeutet die Innovationsfunktion des Controllings?

  10. Welche Unterschiede bzw. Gemeinsamkeiten bestehen zwischen Controlling und Revision?

Quellen

  • Baumöl, U.: IT-Controlling – Stand und Herausforderungen. In: CONTROLLING 12/2008, 649–654

  • Brun, R.: Planen – Messen – Steuern: Die Kernprozesse von IT-Governance und ITR-Controlling. In: IM Information Management & Consulting 2/2008, 60–68

  • Frank, U. / Hofmann, G. R.: IT-Controlling und IT-Produktivität. Editorial zu WIRTSCHAFTSINFORMATIK 3/2009, 233–234

  • Goeken, M. / Patas, J.: Wertbeitrag der IT als Gegenstand der IT-Governance und des IT-Controllings. In: CONTROLLING12/2009, 650–655

  • Hirsch, B. / Hammer, D. / Mäder, O. B. / Kauerhoff, M.: Wirtschaftsprüfung und Controlling – Ausgestaltung der institutionellen Zusammenarbeit. In: CONTROLLING 1/2009, 39–47

  • Horváth, P.: Controlling. 11. A., München 2009

  • Kütz, M.: IT-Controlling für die Praxis. Konzeption und Methoden. Heidelberg 2005

  • Seibt, D.: Informationsmanagement und Controlling. In: WIRTSCHAFTSINFORMATIK 2/1990, 116–126

  • Son, S. / Gladyszewski, Th.: Return on IT-Controlling 2005 – eine empirische Untersuchung zum Einfluss des IT-Controllings auf die unternehmensweite IT Performance. Arbeitsbericht, E-Finance Lab Frankfurt a. M., Kontakt: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

  • Strecker, St.: IT-Performance-Management – Zum gegenwärtigen Stand der Diskussion, In: CONTROLLING 10/2008, 513–518

  • von Dobschütz, L.: IV-Controlling. Theoretische Sicht und praktische Bedeutung. In: CONTROLLING 5/1995, 306–312

Vertiefungsliteratur

  • Gadatsch, A. / Mayer, E.: Masterkurs IT-Controlling. Wiesbaden 2005

  • Jaspersen, T.: IT-Controlling für Mittel- und Kleinbetriebe. Berlin 2005

  • Kargl, H. / Kütz, M.: IV-Controlling. 5. A., München 2007

  • Reichmann, T.: Controlling mit Kennzahlen und Management-Tools. 7. A., München 2006

  • von Dobschütz, L. et al.: (Hrsg.): IV-Controlling. Wiesbaden 2000

  • Wall, F.: Informationsmanagement – Eine ökonomische Integration von Controlling und Wirtschaftsinformatik. München 2006

  • Abbildungsarchiv: Controlling (CONTR)

Architektur der Informationsinfrastruktur

Inhaltsverzeichnis[Verbergen]

Lernziele

Sie können die Rolle der Architektur für das Informationsmanagement erläutern. Sie kennen verschiedene Teilarchitekturen der Informationsinfrastruktur und können Gemeinsamkeiten und Unterschiede aufzeigen. Sie kennen Metamodelle für Architekturen und können deren typische Eigenschaften beschreiben. Sie haben einen Überblick über Teilaufgaben der Entwicklung von sowie über Gestaltungsziele und Konstruktionsregeln für Architekturen.

Definitionen und Abkürzungen

  • Anwendungsarchitektur (application architecture) = Beschreibung der Funktionalität und des Zusammenhangs der Anwendungssysteme eines Unternehmens oder Aufgabengebiets.

  • Architektur (architecture) = Organisation eines Systems, die sich in seinen Komponenten und deren Beziehungen zueinander sowie zum Systemumfeld manifestiert.

  • Architekturprinzipien (architecture principles) = Gestaltungsziele und Konstruktionsregeln für Architekturen.

  • ARIS = Architektur integrierter Informationssysteme; Metamodell zur Modellierung computergestützter Informationssysteme vom Fachkonzept bis zur Implementierung.

  • Datenarchitektur (data architecture) = Beschreibung der für das Unternehmen wesentlichen Datenbestände, insbesondere der Datenbanken und Data-Warehouse-Systeme, und ihrer strukturellen Beziehungen.

  • Geschäftsarchitektur (business architecture) = Beschreibung der Organisation eines Unternehmens, der wesentlichen Komponenten, Ressourcen und deren Beziehungen sowie der Austauschbeziehungen des Unternehmens mit seiner Umwelt.

  • Informationssystemarchitektur (information systems architecture) = Beschreibung der informationstechnischen Infrastruktur, der Daten und Anwendungsprogramme, der von dem Informationssystem unterstützten Aufgaben sowie der dazu benötigten Aufbau- und Ablauforganisation des entsprechenden Unternehmensteils.

  • Komponente (component) = Bestandteil einer Architektur, der sich aus verschiedenen Elementen zusammensetzen kann.

  • Softwarearchitektur (software architecture) = Beschreibung der Komponenten eines Softwaresystems sowie deren Schnittstellen und Beziehungen untereinander.

  • TOGAF = The Open Group Architecture Framework; Metamodell, Vorgehensmodell und unterstützende Werkzeuge zur Entwicklung von Unternehmensarchitekturen.

  • technische Infrastrukturarchitektur (infrastructure/platform architecture) = Beschreibung der Struktur und der Beziehungen der technischen Komponenten, welche für den Betrieb der Anwendungssysteme notwendig sind.

  • Unternehmensarchitektur (enterprise architecture) = Beschreibung der Struktur eines Unternehmens aus betriebswirtschaftlicher Sicht, der strategischen Ziele sowie der Verfahren und Ressourcen zur Realisierung dieser Ziele.

Zweck der Architektur der Informationsinfrastruktur
Funktionen von Architekturen
Architekturbegriff
Teilarchitekturen
Metamodelle für Architekturen
Entwicklung von Architekturen
Architekturprinzipien

Forschungsbefunde

Schmidt/Buxmann/Sokolovsky berichten über eine explorative Untersuchung zum Status quo des IT-Architekturmanagements in der deutschsprachigen Kreditwirtschaft (Expertenbefragung, N = 28 per Suchmaschinenrecherche ermittelte Führungs- und Fachkräfte des IT-Architekturmanagements großer Banken aus Deutschland und der Schweiz, R = 14 Befragungsteilnehmer, Untersuchungszeitraum Dezember 2005 bis März 2006). Architekturmanagement ist unter den befragten Instituten weit verbreitet. Es ist in fast allen Unternehmen als eigenständige Funktion etabliert und institutionalisiert, allerdings erst seit wenigen Jahren. Die einzelnen Implementierungen unterscheiden sich zum Teil erheblich. Architekturmanagement wird von allen Teilnehmern als Kernaufgabe betrachtet, die nicht ausgelagert werden kann. Nur wenige Unternehmen orientieren sich an Standards oder Leitfäden (z. B. TOGAF). Die am häufigsten mit der Architektur verbundenen Zwecke sind die Erhöhung bzw. Aufrechterhaltung der IT-Effizienz und der IT-Flexibilität. Die Aussagen einiger Teilnehmer lassen den Schluss zu, dass der Erfolg des Architekturmanagements wesentlich von einer intensiven Kommunikation mit den Stakeholdern und einer starken Praxisorientierung abhängt. Bei zu starker Formalisierung droht Akzeptanz- und Bedeutungsverlust.

Schmidt, C. / Buxmann, P. / Sokolovsky, Z.: IT-Architekturmanagement in Banken. Ergebnisse einer leitfadengestützten Expertenbefragung. In: Oberweis, A. et al. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. 8. Internationale Tagung Wirtschaftsinformatik Karlsruhe, 28. Februar - 2. März 2007. Bd. 2. Karlsruhe 2007, 723–740


In dem Forschungsprojekt Softwarekartographie des Lehrstuhls für Software Engineering betrieblicher Informationssysteme der Technischen Universität München werden Modelle und Methoden zur Beschreibung von Anwendungslandschaften entwickelt. Laut Lankes/ Matthes/Wittenburg besteht das Ziel der Softwarekartographie darin, unter Rückgriff auf Erkenntnisse und Methoden der Kartographie komplexe Anwendungslandschaften in Unternehmen systematisch darzustellen und damit die Übersicht über die Anwendungsarchitektur zu verbessern.

Lankes, J. / Matthes, F. / Wittenburg, A.: Softwarekartographie: Systematische Darstellung von Anwendungslandschaften. In: Ferstl, O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005. eEconomy, eGovernment, eSociety. Heidelberg 2005, 1443–1462


Hildbrand schlägt ein Referenzmodell für Informationssystem-Architekturen (ISA) vor, mit dem versucht werden soll, „… systematisch alle relevanten Aspekte zu integrieren, um somit eine gemeinsame Basis für weitere Arbeiten zu schaffen“. Er weist darauf hin, dass das Modell auch dazu verwendet werden kann, „… um ein Informationssystem zur Verwaltung der Informationssystem-Architekturen zu entwickeln. Dieses Meta-Informationssystem … könnte sehr sinnvoll bei der sich immer komplexer und damit schwieriger gestaltenden Verwendung der Informationstechnologie – quasi als ISA-Dictionary – eingesetzt werden“. Anmerkung: In der Fachliteratur finden sich keine Belege dafür.

Hildbrand, K.: Ein Referenzmodell für Informationssystem-Architekturen. In: Information Management 3/1992, 6-12


Matthes/Wittenburg haben im Forschungsprojekt Softwarekartographie den Istzustand der Beschreibungstechniken für Anwendungslandschaften in namhaften deutschen Unterneh-men erfasst und die Unternehmen nach ihren Anforderungen und relevanten Aspekten der Architekturbeschreibung befragt. Darauf aufbauend wird ein Modell zur integrierten Beschreibung von Architekturen und zur Visualisierung von Schnittstellen entwickelt, das zwischen einer technischen und einer fachlichen Sicht unterscheidet.

Matthes, F. / Wittenburg, Aufl..: Softwarekartographie – Visualisierung von Anwendungslandschaften und ihrer Schnittstellen. In: Dadam, P. / Reichert, M. (Hrsg.): Informatik 2004 – Informatik verbindet Bd. 2. Bonn 2004, 71-75

Aus der Praxis

Starke/Hruschka haben ein Metamodell zur Dokumentation von Software- und IT-Architekturen entwickelt und in verschiedenen Praxisprojekten erprobt und verfeinert. Dieses Metamodell ist unter der Bezeichnung arc42-Template im Internet frei verfügbar (http://www.arc42.de).

Starke, G. / Hruschka, P.: Eine Strukturvorlage zur effektiven Dokumentation von Software- und IT Architekturen. In: Oberweis, A. et al. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. 8. Internationale Tagung Wirtschaftsinformatik Karlsruhe, 28.02. – 02.03.2007. Bd. 2. Karlsruhe 2007, 77–88


Youngs et al. stellen den Architecture Description Standard vor, der als Hilfsmittel für die Beschreibung von Architekturen für Mitarbeiter und Kunden von IBM entwickelt wurde. In dem Standard werden Begriffe und Beschreibungsmittel für Referenzarchitekturen vorgestellt.

Youngs, R. et al.: A Standard for Architecture Description. In: IBM Systems Journal 1/1999, 32–50


Unter der Bezeichnung Enterprise Architecture Management werden Softwarewerkzeuge angeboten, welche die Entwicklung von Architekturen unterstützen. Zu diesen Werkzeugen gehören der ARIS IT Architect der IDS Scheer AG und planningIT der alfabet meta-modeling AG. Das Institute for Enterprise Architecture Developments (IFEAD) betreibt eine Website, auf der unter anderem eine Übersicht über verschiedene Softwarewerkzeuge zur Entwicklung von Architekturen gegeben wird (http://www.enterprise-architecture.info).

Kontrollfragen

  1. Welches sind die wichtigsten Funktionen einer Architektur?
  2. Welche Teilarchitekturen der Informationsinfrastruktur kennen Sie?
  3. Worin unterscheiden sich die Ihnen bekannten Metamodelle für Architekturen?
  4. Wie kann beim Entwickeln einer Architektur vorgegangen werden?
  5. Welchen Inhalt haben die Prinzipien zur Gestaltung von Architekturen?

Quellen

  • Becker, J. / Rosemann, M. / Schütte, R.: Grundsätze ordnungsmäßiger Modellierung. In: WIRTSCHAFTS­INFORMATIK 5/1995, 435-445

  • Foegen, M. / Battenfeld, J.: Die Rolle der Architektur in der Anwendungsentwicklung. In: Informatik Spektrum 5/2001, 290-301

  • Hafner, M. / Winter, R.: Vorgehensmodell für das Management der unternehmensweiten Applikationsarchitektur. In: Ferstl, O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005. eEconomy, eGovernment, eSociety. Heidelberg 2005, 627-646

  • Huang, J.: Future Space: A New Blueprint for Business Architecture. In: Harvard Business Review 2/2001, 149-161

  • Krcmar, H: Bedeutung und Ziele von Informationssystem-Architekturen. In: WIRTSCHAFTSINFORMATIK 5/1990, 395-402

  • Lankes, J. / Matthes, F. / Wittenburg, A.: Softwarekartographie: Systematische Darstellung von Anwendungslandschaften. In: Ferstl, O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005. eEconomy, eGovernment, eSociety. Heidelberg 2005, 1443-1462

  • Scheer, A.-W.: ARIS - Vom Geschäftsprozess zum Anwendungssystem. 4. A., Berlin 2002

  • Schmidt, C. / Buxmann, P. / Sokolovsky, Z.: IT-Architekturmanagement in Banken. Ergebnisse einer leitfadengestützten Expertenbefragung. In: Oberweis, A. et al. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. 8. Internationale Tagung Wirtschaftsinformatik Karlsruhe, 28. Februar - 2. März 2007. Bd. 2. Karlsruhe 2007, 723-740

  • Sinz, E. J.: Unternehmensarchitekturen in der Praxis - Architekturdesign am Reißbrett vs. situationsbedingte Realisierung von Informationssystemen. In: WIRTSCHAFTSINFORMATIK 4/2004, 315-316

  • Sowa, J. F. / Zachmann, J. A.: Extending and Formalizing the Framework for Information Systems Architecture. In: IBM Systems Journal 3/1992, 590-616

  • Starke, G. / Hruschka, P.: Eine Strukturvorlage zur effektiven Dokumentation von Software- und IT Architekturen. In: Oberweis, A. et al. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. 8. Internationale Tagung Wirtschaftsinformatik Karlsruhe, 28.02. - 02.03.2007. Bd. 2. Karlsruhe 2007, 77-88

  • The Open Group (Hrsg.): TOGAF (The Open Group Architecture Framework) Version 8.1.1 "Enterprise Edition". http://www.opengroup.org; Abruf: 06.01.2009

  • Vitruvius, M. P.: De Architectura Libri Decem. Zehn Bücher über Architektur. Wiesbaden 2004

  • Vogel, O. et al.: Software-Architektur. Grundlagen - Konzepte - Praxis. München 2005

  • Winter, R.: Architektur braucht Management. In: WIRTSCHAFTSINFORMATIK 4/2004, 317-319

  • Youngs, R. et al.: A Standard for Architecture Description. In: IBM Systems Journal 1/1999, 32-50

  • Zachmann, J. A.: A Framework for Information Systems Architecture. In: IBM Systems Journal 3/1987, 276-292

  • Zachmann, J. A.: Zachman Enterprise Framework 2. http://www.zachmaninternational.com; Abruf: 07.01.2009

Vertiefungsliteratur

  • Aier, S. / Riege, C. / Winter, R.: Unternehmensarchitektur - Literaturüberblick und Stand der Praxis. In: WIRT­SCHAFTS­­INFORMATIK 4/2008, 292-304

  • Bass, L. / Clements, P. / Kazman, R.: Software Architecture in Practice. 2. A., Reading et al. 2003

  • Dern, G.: Management von IT-Architekturen. Leitlinien für die Ausrichtung, Planung und Gestaltung von Informationssystemen. 2. A., Wiesbaden 2006

  • Matthes, F.: Softwarekartographie. In: Informatik Spektrum 6/2008, 527-536

  • Schekkerman, J.: Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice. Victoria, Canada 2008

Informationsmaterial

Normen

  • IEEE 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems -Description

  • ISO/IEC 42010:2007 Systems and software engineering - Recommended practice for architectural description of software-intensive systems

  • Abbildungsarchiv: Architektur der Informationsinfrastruktur (ARCHI)