Zielplanung (SZIEL)

Inhaltsverzeichnis[Verbergen]

Lernziele

Sie kennen den Zweck der strategischen Zielplanung und den Unterschied zwischen strategischen Zielen des Informationsmanagements und strategischen IT-Zielen. Sie können den Zielcharakter und seine Merkmale erläutern. Sie kennen die Quellen strategischer IT-Ziele und können deren Zielinhalt beschreiben. Sie kennen Vorgehensweisen der strategischen Zielplanung und die Probleme beim Festlegen des Zielmaßstabs. Sie kennen die Bedeutung von IT-Leitbildern für die strategische IT-Planung und exemplarisch deren Inhalt.

Definitionen und Abkürzungen

  • Bottom-up-Ansatz (bottom-up approach) = Vorgehensweise bei Analyse, Entwurf, Testen usw., bei der mit den Systemteilen begonnen wird, die sich auf der untersten Ebene des hierarchisch gegliederten Systems befinden. Im Gegensatz dazu: Top-down-Ansatz.

  • Formalziel (goal) = Ziel, dessen Zielinhalt die Qualität oder Güte beschreibt, mit der ein Sachziel verfolgt werden soll (Wie soll ein Zweck erreicht werden?).

  • Handlungsspielraum (action scope) = mehrdimensionaler Begriff, der Entscheidungsspielraum, Tätigkeitsspielraum und Freiheitsspielraum umfasst.

  • KPI = Key Performance Indicator.

  • Leistung (performance) = Fähigkeit eines Systems, eine bestimmte Aufgabe in vorgegebener Zeit erfüllen zu können (Aufgabenerfüllung pro Zeiteinheit).

  • MTBF = Mean Time Between Failures (mittlerer Zeitabstand zwischen zwei Ausfällen); Maßeinheit für Verfügbarkeit (üblicherweise in Tagen oder Monaten).

  • MTTF = Mean Time To Failure (mittlere Zeitdauer bis zu einem Ausfall); Maßeinheit für Verfügbarkeit (üblicherweise in Stunden).

  • Nutzen (benefit) = subjektiv beeinflusster Wert einer Handlungsalternative zur Befriedigung eines definierten Bedarfs. Synonym: Nutzwert.

  • operational (operational) = Eigenschaft einer Handlungsanweisung, so formuliert zu sein, dass sie von den für sie bestimmten Adressaten befolgt werden kann.

  • Sachziel (objective) = Ziel, dessen Zielinhalt einen Zweck definiert (Was soll erreicht werden?).

  • strategisches IT-Ziel (strategic IT objective) = Ziel, das die langfristige, unternehmensweite und den Wettbewerb positiv beeinflussende Veränderung der IT lenkt.

  • Ziel (objective) = angestrebter Endpunkt eines menschlichen Handlungsprozesses.

  • Zielbeziehung (goal relation) = Tatsache, dass die Erfüllung eines Ziels die Erfüllung eines anderen Ziels beeinflusst.

  • Zielhierarchie (goal hierarchy) = stufenmäßig aufgebaute Ordnung der Elemente eines Zielsystems in Form einer Rangordnung mit von oben nach unten abnehmender Bedeutung.

  • Zielplanung (goal setting) = Prozess des Festlegens (Setzens) von Zielen nach Inhalt, Maßstab, Ausmaß der Zielerreichung und zeitlichem Bezug.

  • Zielsystem (goal system) = geordnete Menge von Zielen, zwischen denen Beziehungen bestehen, die idealtypisch gesehen komplementär, konfliktär oder indifferent sind.

Zweck der strategischen Zielplanung
Zielsystem und Zielhierarchie
Zielcharakter
Vorgehensweise bei der Zielplanung
IT-Leitbilder

Forschungsbefunde

Empirische Untersuchungen bringen so gut wie keine Erkenntnisse bezüglich der strategischen IT-Ziele, die in der Praxis verfolgt werden. Selig hat beispielsweise nur festgestellt, dass seitens der Unternehmensleitung keine aktive Gestaltung des Pla­nungsprozesses erfolgt und dass keine Zie­le und Randbedingungen vorgegeben werden. Heinrich/Sterrer haben über empirisch ermittelte IT-Ziele berichtet; Ansätze für strategische Vorgaben zu diesen administrativen Zielen (insbesondere Ziele für IT-Projekte) konnten nicht identifiziert werden.
Selig, J.: EDV-Management – Eine empirische Untersuchung der Entwicklung von Anwendungssystemen in deutschen Unternehmen. Berlin et al. 1986
Heinrich, L. J. / Sterrer, G.: Ziele von Informationssystemen – Ergebnisse einer empirischen Studie. In: Information Management 1/1987, 48–53


Selig stellt berichtet über Befunde zur strategischen IT-Planung, insbesondere Zielplanung, u. a. (schriftliche Befragung, N = 33, Erhebungszeitraum 1982): Seitens der Unternehmensführung erfolgt keine aktive Gestaltung des Planungsprozesses, Ziele und Randbedingungen werden nicht vorgegeben Was festgestellt wird sind „EDV-Rahmenpläne“ (in 21 Unternehmen), die nicht nur eine strategische Orientierung vermissen lassen, sondern die auch bezüglich des Zeithorizonts eher einen mittelfristigen Charakter haben. Die Unternehmensführung ist in diese Planung nicht ausreichenden involviert. Ein formaler Planungsprozess ist nicht erkennbar.
Selig, J.: EDV-Management – Eine empirische Untersuchung der Entwicklung von Anwendungssystemen in deutschen Unternehmen. Berlin et al. 1986


Heinrich/Sterrer berichten über empirisch ermittelte Ziele der Systementwicklung u. a. (Interviewmethode, N = 12 EDV-Leiter in zwölf Unternehmen in Oberösterreich, Erhebungszeitraum 1985): Allgemein akzeptierte Formalziele sind Akzeptanz, Benutzerfreundlichkeit, Wirtschaftlichkeit und Zuverlässigkeit; Ziele wie Aufgabenbezogenheit und Produktivität werden kaum verwendet. Die Definition des Zielmaßstabs ist sehr unterschiedlich – sogar beim Ziel Wirtschaftlichkeit. Nachfragen nach den verwendeten Messmethoden lassen erkennen, dass es nicht sehr wahrscheinlich ist, dass die genannten Ziele im Sinne einer Controlling-Konzeption tatsächlich geplant und zur Überwachung uns Steuerung der Anwendungssysteme verwendet werden. Insgesamt vermitteln die Befunde den Eindruck, dass der Stand der Zielplanung und der Überwachung und Steuerung der Anwendungssysteme nach dieser Zielplanung sehr gering ist. Ansätze für strategische Vorgaben zu diesen administrativen Zielen (z. B. Ziele für IT-Projekte) konnten nicht identifiziert werden.
Heinrich, L. J. / Sterrer, G.: Ziele von Informationssystemen – Ergebnisse einer empirischen Studie. In: Information Management 1/1987, 48-53


Wallau hat mit einer empirischen Untersuchung (schriftliche Befragung von 51 Benutzern in einem örtlich verteilten Unternehmen, Befragungszeitraum nicht angegeben, vermutlich 1989) die Akzeptanz der Benutzer in Bezug auf ein bestimmtes Informationssystem (ISP = Informationssystem Produktion) erhoben und u. a. festgestellt (hinter jedem Kriterium der Anteil der Ja/Nein-Antworten; die Differenzen zu 100 % ergeben sich aus fehlenden Urteilen): Arbeitserleichterung 72,5 %/7,8 %, Zeitersparnis 64,7 %/13,7 %, geringere Fehlerhäufigkeit 41,2 %/ 11,8 %, höhere Datenaktualität 80,4 %/3,9 %, besserer Einblick in andere betriebliche Bereiche 33,3 %/0, bessere Zusammenarbeit mit anderen betrieblichen Bereichen 33,3 %/0. Trotz guter Ergebnisse besteht Handlungsbedarf für Akzeptanz fördernde Maßnahmen, die sich durch eine Verbesserung von Wirksamkeit und Wirtschaftlichkeit bemerkbar machen würden.
Wallau, S.: Akzeptanz betrieblicher Informationssysteme – eine empirische Untersuchung. Arbeitsberichte zur Wirtschaftsinformatik der Universität Tübingen 2/1990


Schellhaas/Schönecker kommen nach empirischen Untersuchungen (Forschungsprojekt Bürokommunikation) zu der Aussage, dass Bürokommunikation zunächst als Pilotprojekt in einem relativ abgeschlossenen und kommunikationsintensiven Anwendungsgebiet erprobt werden soll; ein solches Anwendungsgebiet kann mit einer Kommunikationsanalyse bestimmt werden. Ein Pilotprojekt lässt sich nicht mit einer Wirtschaftlichkeitsanalyse rechtfertigen, sondern erfordert eine strategisch ausgerichtete Technologieeinsatz-Entscheidung, die sich insbesondere an der Wirksamkeit als Auswahlkriterium orientiert.
Schellhaas, H. / Schönecker, H. G.: Kommunikationstechnik und Anwender. München 1993


Heinrich/Pomberger berichten über Befunde der wissenschaftlichen Begleitbeobachtung von Projekten, in denen die Erfolgsfaktorenanalyse verwendet wurde, bezüglich der strategischen IT-Ziele u. a. (drei Fallstudien mit Aktionsforschung, Untersuchungszeitraum 1998/1999): Die Bedeutung des Zielinhalts Durchdringung nimmt wegen des bereits sehr hohen Durchdringungsgrads deutlich ab. Soweit inhaltliche Bedeutung noch gegeben ist, besteht eine Überschneidung mit dem Zielinhalt von Wirksamkeit. Weiter konnte festgestellt werden, dass die Verwendung von Qualität als genereller Inhalt der Formalziele nicht immer ausreicht, um das explizite Qualitätsstreben der Unternehmensführung auch für die IT-Infrastruktur so zum Ausdruck zu bringen, dass es sich letztlich in den Maßnahmen zur ihrer Veränderung niederschlägt. Von diesem Befund ausgehend ist zu prüfen, ob die Verwendung von Qualität statt von Durchdringung als Zielinhalt zu einem wirklichkeitsnäheren Zielsystem führt.
Heinrich, L. J. / Pomberger, G.: Erfolgsfaktorenanalyse – Instrument für das strategische IT-Controlling. In: HMD 217/2001, 19-28


Mertens stellt fest, dass Ökonomie in der (kapitalistischen) Marktwirtschaft für das Unternehmen Rentabilitätsmaximierung bedeutet und dass sich Wirtschaftlichkeits- und Rentabilitätsmaximierung nicht decken. So genannte Ingenieurziele (z. B. Kostenminimierung, Maximierung der Kapazitätsauslastung) seien theoretisch nur haltbar, wenn zahlreiche Ceteris-Paribus-Klauseln gelten; bei ihrer Verwendung in der Wirtschaftsinformatik sei große Vorsicht geboten.

Mertens, P.: Operiert die Wirtschaftsinformatik mit falschen Unternehmenszielen? In: Becker, J. et al. (Hrsg.): Wissenschaftstheorie und Wirtschaftsinformatik. Wiesbaden 1999, 379-392


Aus der Erfahrung mehrerer Anwendungen der Erfolgsfaktorenanalyse empfehlen Heinrich/Pomberger die Verwendung des Gesamterfolgs als strategisches IT-Ziel, in das – je nach Definition der Erfolgsfaktoren – sowohl wirksamkeits- als auch wirtschaftlichkeitsrelevante Eigenschaften der IT-Infrastruktur eingehen. Wesentlicher Vorteil gegenüber anderen Zielinhalten ist die Quantifizierbarkeit des Gesamterfolgs.

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

Aus der Praxis

Methodenverweise

Kontrollfragen

  1. Wodurch sind Ziele, Zielsysteme und Zielhierarchien gekennzeichnet?

  2. Durch welche Zielkategorien können IT-Ziele systematisiert werden?

  3. Welche strategischen IT-Ziele im Sinne von Formalzielen werden unterschieden?

  4. Wie kann der Zielmaßstab für strategische IT-Ziele festgelegt werden?

  5. Mit welchen Arbeitsschritten wird bei der strategischen Zielplanung vorgegangen?

Quellen

  • Brynjolfsson, E.: Beyond the productivity paradox. In: Communications of the ACM 8/1998, 49-55

  • Brynjolfsson, E.: The productivity paradox of information technology. In: Communications of the ACM 12/1993, 66-77

  • Byrd, T. / Turner, D.: An exploratory eximination of the relationship between flexible IT infrastructure and competitive advantage. In: Information & Management, 1/2001, 41–49

  • Ernst & Young (Hrsg.): IT-Kosten und IT-Performance 2002 – Betriebswirtschaftliche Studie der Schweizer Informatikabteilungen. Bern 2002

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

  • KPMG (Hrsg.): IT-Management 2005. Standortbestimmung und Trends in der Schweizer Informatik. "http://www.kpmg.ch/RIM;"; Abruf: 14.4.2008

  • Mertens, P.: Operiert die Wirtschaftsinformatik mit falschen Unternehmenszielen? - 15 Thesen. In: Becker, J. et al. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie: Bestandsaufnahme und Perspektiven. Wiesbaden 1999, 379-392

Wissensmanagement (WIMAN)

Inhaltsverzeichnis[Verbergen]

Lernziele

Sie wissen, wodurch sich Wissensmanagement von Organisationalem Lernen und Künstlicher Intelligenz unterscheidet. Sie können den Wissensbegriff erläutern und Wissen von Information und Daten abgrenzen. Sie kennen die Aufgaben des Wissensmanagements. Sie können darlegen, welche Strategien des Wissensmanagements unter welchen Bedingungen angemessen sind. Sie kennen Aufgabenträger des Wissensmanagements.

Definitionen und Abkürzungen

  • CKO = Chief Knowledge Officer.

  • Communities of Practice = freiwillig und spontan gebildete Gemeinschaften von intrinsisch motivierten Fachleuten, die eine bestimmte Frage erörtern oder ein Problem lösen wollen.

  • Information (information) = explizites, mitteilbares Wissen.

  • Kompetenzzentrum (competence center, center of excellence) = unternehmensinterne Expertengruppe, welche für spezifische Gebiete Wissen entwickelt.

  • Kodifizierung (codification) = dokumentenbasierte Wissensbewahrung und -verteilung.

  • Künstliche Intelligenz (artificial intelligence) = Automatisierung von intelligentem Verhalten; Repräsentation und automatisierte Verarbeitung von Wissen.

  • Organisationales Lernen (organizational learning) = jegliche, d. h. sowohl zufällige als auch bewusst herbeigeführte, Veränderung der Wissensbasis einer Organisation.

  • Personalisierung (personalization) = personenzentrierte Wissensbewahrung und -verteilung.

  • tacit knowledge = implizites Wissen, welches sich nicht oder nur schwer explizieren lässt.

  • Unternehmenskultur (corporate culture) = Muster von Prämissen (z. B. Normen, Werte und Wahrnehmungen), das von den Unternehmensmitgliedern im Umgang mit der externen und internen Umwelt erlernt und durch Sozialisation weitergegeben wird.

  • Wissen (knowledge) = Gesamtheit der Kenntnisse und Fähigkeiten zur Lösung von Problemen.

  • Wissensbasis (knowledge base, organizational memory) = Gesamtheit des in einem Unternehmen verfügbaren relevanten Wissens.

  • Wissensbestand (knowledge asset) = inhaltlich zusammenhängende Teilmenge der Wissensbasis.

  • Wissensobjekt (knowledge object) = Einheit, die Wissen repräsentiert. Synonym: Wissenselement.

  • Wissenslücke (knowledge gap) = benötigtes, aber nicht verfügbares Wissen. Synonym: Wissensdefizit.

  • Wissensmanagement (knowledge management) = Führungsaufgabe, die sich mit der zielorientierten Nutzung und Weiterentwicklung von Wissen befasst.

  • Wissensmanagementstrategie (knowledge management strategy) = grundsätzliche Festlegungen zur Gestaltung des Wissensmanagements.

  • Wissensträger (knowledge bearer) = Aufgabenträger, der über relevantes Wissen verfügt.

Zweck des Wissensmanagements
Organisationales Lernen und Künstliche Intelligenz
Wissensbegriff
Einflussfaktoren und Handlungsfelder
Aufgaben des Wissensmanagements
Strategien des Wissensmanagements
Aufgabenträger des Wissensmanagements

Forschungsbefunde

Helm/Meckl/Sodeik systematisieren Erfolgsfaktoren des Wissensmanagements auf der Grundlage empirischer Forschung (Sekundäranalyse von 39 Studien mit Ergebnissen zu Erfolgsfaktoren des Wissensmanagements: 32 quantitativ ausgerichtete Querschnittsanalysen, vier Delphi-Studien, die sowohl qualitative als auch quantitative Forschung enthalten und interaktiv auf Erfolgsfaktoren schließen, zwei quantitative Auswertungen von Fallstudien/Wissensprojekten und eine Untersuchung mit Ergebnissen aus Besuchen von Fachmessen und qualitativen Experteninterviews. Der Untersuchungsschwerpunkt der Studien liegt in Nordamerika und Europa; vier der Studien wurden weltweit durchgeführt, fünf bezogen sich ausschließlich auf den deutschsprachigen Raum; Publikationszeitraum der Studien zwischen 1996 und Juni 2004.) Helm/Meckl/Sodeik identifizierten mehr als 80 Erfolgsfaktoren sowie Hindernisse/Barrieren und systematisieren diese mit folgenden Dimensionen, Kategorien und Untersuchungsfeldern: Personal (Personalführung, -motivation und -entwicklung), Struktur (Organisation und Technik), Kultur (Ebene der Organisation und Profil der Akteure) und Wissensmanagement-Aktivitäten (Wissensansammlung und ‑anwendung).


Earl/Scott (Interviews mit 20 CKOs in Nordamerika und Europa, keine Angaben zu Grundgesamtheit und Untersuchungszeitraum) und Guns (Interviews mit 25 CKOs großer Unternehmen in den Vereinigten Staaten, keine Angaben zu Grundgesamtheit und Untersuchungszeitraum) stellen übereinstimmend fest, dass die Hauptaufgaben von CKOs sowohl im technischen als auch im organisatorischen bzw. im sozialen Bereich liegen. Die CKOs sind sowohl dafür verantwortlich, dass geeignete technische Infrastrukturen zur Unterstützung des Wissensmanagements zur Verfügung gestellt werden, als auch dafür, dass ein organisatorisches und soziales Umfeld für die Mitarbeiter geschaffen wird, welches die Bewältigung der Aufgaben des Wissensmanagements erleichtert und die notwendigen Veränderungen unterstützt. Guns identifiziert sieben wesentliche Herausforderungen für einen CKO: „Setting knowledge management strategic priorities, ... getting a knowledge (best practice) database up and running, ... gaining commitment of business leaders to better support a learning environment, ... transforming a centre for shared intelligence into that of intelligence provocateurs, ... putting in place a process for managing intellectual assets, ... obtaining customer satisfaction information from customers in ‚near' real-time, and globalizing knowledge management". (316 f.)


McKeen/Staples untersuchten Aufgaben und Herausforderungen von Knowledge Managern („knowledge management experts who work closely with business units or are even a part of the business unit", 23) (schriftliche Befragung von Teilnehmern einer Konferenz zum Wissensmanagement, keine Angaben zur Größe der Grundgesamtheit; 92 % der Befragungsteilnehmer arbeiten in Nordamerika, 5 % in Europa und 3 % in Asien, Untersuchungszeitraum 2001). Als typische Aufgaben der Knowledge Manager wurden genannt: Einrichtung eines Intranets, Erstellung von Wissensverzeichnissen, Einrichtung von Data Warehouses, Etablierung von unternehmensinternen Netzwerken der Wissensarbeiter, Implementierung von Groupware-Werkzeugen für die unternehmensinterne Zusammenarbeit, Erstellung von Wissenskarten, Einführung wissensintensiver Produkte und Prozesse, Einrichtung neuer Rollen des Wissensmanagements und Implementierung von Entscheidungsunterstützungssystemen. Als größte Herausforderungen bezeichneten die Teilnehmer: Herbeiführung von Verhaltensänderungen der Mitarbeiter, Messung des Wertes und des Leistungsbeitrags von Wissensbeständen (knowledge assets), Rechtfertigung der Nutzung knapper Ressourcen für Wissensmanagementvorhaben. Die drei durchschnittlich am schwächsten ausgeprägten Fähigkeiten des Wissensmanagements in den Unternehmen sind: Messung der Wirkungen des Wissensmanagements, Messung des Wertes von Wissensbeständen und Beförderung der Wissensteilung (knowledge sharing) durch geeignete Anreize.


In der Regel wird vermutet, dass Entscheidungsträger unternehmensinternes Wissen höher schätzen als Wissen von Externen. Dieser Sachverhalt wird auch als Not-invented-here-Syndrom bezeichnet. Menon/Tompson/Choi untersuchten (zwei Fallstudien in amerikanischen Unternehmen und Experimente mit über 130 berufserfahrenen Studierenden in weiterbildenden Managementstudiengängen, Untersuchungszeitraum nicht angegeben), ob Wissen aus internen Quellen tatsächlich höher bewertet wird als Wissen aus externen Quellen. Sie fanden heraus, dass Führungskräfte oft eher bereit sind, Wissen von Externen zu verwenden als von Kollegen oder Mitarbeitern. Menon/Tompson/Choi führen dafür drei Gründe an. Erstens werden Kollegen und Mitarbeiter oft als Rivalen im Streben nach Ansehen, Macht, Bezahlung und Aufstiegschancen angesehen. In dem Maße, in dem Ideen und Ratschläge von Kollegen und Mitarbeitern übernommen werden, verschlechtert sich die eigene, betriebsinterne Wettbewerbsposition. Wird hingegen Wissen von konkurrierenden Unternehmen angenommen, kann sich die Wettbewerbsposition des Unternehmens verbessern. Mitarbeiter, die externes Wissen verwenden, tragen damit zur Sicherheit ihres eigenen Arbeitsplatzes bei. Zweitens kann internes Wissens leichter überprüft und bewertet werden als externes Wissen. Internes Wissen wird oft als minderwertig angesehen, weil dessen Schwachstellen leichter erkannt werden können, als die von externem Wissen. Drittens ist Wissen von Externen oft schlechter zugänglich als internes Wissen. Die Akquisition externen Wissens ist mit höheren Kosten verbunden. Dieses Wissen erscheint daher wertvoller.

Aus der Praxis

Edmundson berichtet über den erfolgreichen Einsatz von Communities of Practice bei Schlumberger, einem international tätigen Unternehmen der Öl- und Gasindustrie. In diesem Unternehmen sind mehr als 5200 Fachkräfte in Communities of Practice zusammengeschlossen, um eine effizientere Wissensverteilung zu ermöglichen. Solche Gemeinschaften haben sich unter anderem zu den Themen IT, Mathematik und Geophysik gebildet. Die Gemeinschaften nutzen Workshops und Websites für die Wissensverteilung.
Laut Birk/Müller besteht die Struktur des Wissensmanagements bei Siemens Medical Solu­tions aus sechs Pfeilern. Im Rahmen des Top Management Supports wurden Führungskräfte benannt, welche für das Wissensmanagement in den Bereichen Führung, Personal, Strategie, Ressourcen, Forschung und Entwicklung, Produktion/Supply Chain, Marketing, Verkauf und Kundendienst zuständig sind. Zur einfacheren Identifikation relevanten Wissens wurde eine unternehmensweite aufgabenorientierte Strukturierung des Wissens verwendet, die es den Mitarbeitern erleichtern soll, relevantes Wissen zu finden. Communities of Practice helfen den oft geografisch verteilten Experten, Wissen auszutauschen. Web-basierte, benutzerfreundliche Informationssysteme erleichtern den Zugang zu kodifiziertem Wissen. Zur Unterstützung des Wissensmanagements haben sich folgende Elemente als hilfreich herausgestellt: ein für das weltweite Wissensmanagement zuständiges Team, Ausbildungs- und Trainingsprogramme zum Wissensmanagement für alle Mitarbeiter, Bewertungskriterien für Wissensbestände und -objekte sowie ein Team, das insbesondere für die Qualitätssicherung von Inhalten zuständig ist, die im Intranet zur Verfügung gestellt werden. Um anfängliche Widerstände gegen das Wissensmanagement zu überwinden, wurde ein Anreizsystem eta­bliert, das insbesondere die Weitergabe individuellen Wissens und die länderübergreifende Zusammenarbeit fördern soll.

Methodenverweise

Kontrollfragen

  1. Worin besteht der Unterschied zwischen implizitem Wissen und tacit knowledge?

  2. Inwiefern unterscheidet sich Wissen von Information?

  3. Wie kann man die Aufgaben des Wissensmanagements strukturieren?

  4. Welches sind typische Aufgaben eines Chief Knowledge Officers?

  5. Welche Wissensmanagementstrategie eignet sich unter welchen Rahmenbedingungen?

Quellen

  • Birk, D. / Müller, M.: KnowledgeSharing@MED - turning knowledge into business. In: Davenport, T. H. / Probst, G. J. B. (Hrsg.): Knowledge Management Case Book. 2. A., Berlin/München 2002, 177-186

  • DeLone, W. H. / McLean, E. R.: The DeLone and McLean Model of Information System Success: A Ten-Year Update. In: Journal of Management Information Systems 4/2003, 9–30

  • Earl, M. J. / Scott, I. A.: What Is a Chief Knowledge Officer? In: Sloan Management Review 2/1999, 29-38

  • Edmundson, H.: Technical Communities of Practice at Schlumberger. In: Knowledge Management Review 2/2001, 20-23

  • Gold, A. H. / Malhotra, A. / Segars, A. H.: Knowledge Management: An Organizational Capabilities Perspective. In: Journal of Management Information Systems 1/2001, 185-214

  • Guns, B.: The Chief Knowledge Officer's Role: Challenges and Competencies. In: Journal of Knowledge Management 4/1998, 315-319

  • Hansen, M. T. / Nohria, N. / Tierney, T.: What's Your Strategy For Managing Knowledge? In: Harvard Business Review. 2/1999, 106-116

  • Helm, R. / Meckl, R. / Sodeik, N.: Systematisierung der Erfolgsfaktoren von Wissensmanagement auf Basis der bisherigen empirischen Forschung. In: Zeitschrift für Betriebswirtschaft 2/2007, 211-241

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

  • Maier, R.: Knowledge Management Systems: Information und Communication Technologies for Knowledge Management. 3. A., Berlin et al. 2007

  • Maier, R. / Hädrich, T.: Modell für die Erfolgsmessung von Wissensmanagementsystemen. In: WIRTSCHAFTSINFORMATIK 5/2001, 497–510

  • McKeen, J. D. / Staples, D. S.: Knowledge Managers: Who They Are and What They Do. In: Holsapple, C. W. (Hrsg.): Handbook on Knowledge Management 1. Knowledge Matters. Berlin/Heidelberg/New York 2003, 21-41

  • Menon, T. / Pfeffer, J.: Valuing Internal vs. External Knowledge: Explaining the Preference for Outsiders. In: Management Science 4/2003, 497-513

  • Menon, T. / Tompson, L. / Choi, H.-S.: Tainted Knowledge vs. Tempting Knowledge: People Avoid Knowledge from Internal Rivals and Seek Knowledge from External Rivals. In: Management Science 8/2006, 1129-1144

  • Nassim, B.: Investigating the Impact of Knowledge Management Factors on New Product Development Perfor- mance. In: International Journal of Knowledge Management 3/2009, 21–37

  • Polanyi, M.: The Tacit Dimension. Gloucester 1983

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

  • Puppe, F.: Künstliche Intelligenz. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. A., Berlin/Heidel­berg/New York 2001, 276-278

  • Riempp, G.: Integriertes Wissensmanagement - Strategie, Prozesse und Systeme wirkungsvoll verbinden. In: HMD - Praxis der Wirtschaftsinformatik 246/2005, 6-19

  • Schütt, P.: The post-Nonaka Knowledge Management. In: Journal of Universal Computer Science 6/2003, 451-462.

  • Stelzer, D.: Wissen. In: Kurbel, K. et al. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik - Online-Lexikon. München 2009, o. S. http://www.enzyklopaedie-der-wirtschaftsinformatik.de

  • von der Oelsnitz, D. / Hahmann, M.: Wissensmanagement. Strategie und Lernen in wissensbasierten Unternehmen. Stuttgart 2003

  • von Krogh, G. / Nonaka, I. / Aben, M.: Making the Most of Your Company´s Knowledge: A Strategic Framework. In: Long Range Planning 4/2001, 421-439

  • Zahn, E.: Wissen und Strategie. In: Bürgel, H. D. (Hrsg.): Wissensmanagement. Berlin et al. 1998, 41-52

Vertiefungsliteratur

  • Alavi, M. / Leidner, D. E.: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. In: MIS Quarterly 1/2001, 107-136

  • Güldenberg, S.: Wissensmanagement und Wissenscontrolling in lernenden Organisationen - Ein systemtheoretischer Ansatz. 4. A., Braunschweig/Wiesbaden 2003

  • North, K.: Wissensorientierte Unternehmensführung. Wertschöpfung durch Wissen. 4. A., Wiesbaden 2005

  • Stelzer, D.: Informations- versus Wissensmanagement - Versuch einer Abgrenzung. In: Kemper, H.-G. / Mülder, W. (Hrsg.): Informationsmanagement. Neue Herausforderungen in Zeiten des E-Business. Lohmar 2003, 25-41

Informationsmaterial

  • Abbildungsarchiv: Wissensmanagement (WIMAN)

Wirtschaftlichkeitsanalyse (WIRTA)

Lernziele

Sie kennen den Zweck von Wirtschaftlichkeitsanalysen bei IT-Investitionen. Sie können Kosten und Nutzen in Kostenarten und Nutzenarten zerlegen. Sie wissen, wie bei der Analyse der Kostenstruktur und bei der Analyse der Nutzenstruktur sowie bei der Analyse der Beziehungszusammenhänge zwischen Kosten und Nutzen vorgegangen wird. Sie kennen den Unterschied zwischen Wirtschaftlichkeitsanalysen und Wirtschaftlichkeitsrechnungen.

Definitionen und Abkürzungen

  • Analyse (analysis) = möglichst exakte Bestimmung und Charakterisierung von Teilen eines Systems (eines Ganzen) sowie der Beziehungen der Teile untereinander und zum Ganzen mit dem Zweck, das Ganze zu erklären.
  • Kennzahl (metric) = Zahl über Daten mit konzentrierter Aussagekraft zur Planung, Überwachung und Steuerung sowie zur Diagnose eines Systems.
  • Kosten (costs) = mit Geldeinheiten bewertete Konsequenzen einer Leistung bezüglich ihres Verzehrs an Gütern und/oder Diensten.
  • Kosten-Nutzen-Analyse (cost value analysis) = Variante der Nutzwertanalyse, bei der die Kosten der Alternativen zunächst nicht in das Zielsystem aufgenommen werden; nach der Ermittlung des Nutzwerts wird dieser mit dem Kostenwert in Beziehung gesetzt.
  • Kostenart (cost item) = Ergebnis der Zerlegung von Kosten nach der Art des Verbrauchs an Gütern und/oder Dienstleistungen.
  • Kostenstruktur (cost structure) = Zusammensetzung von Kosten nach Kostenart und Kostenhöhe bzw. relativer Anteil der Kosten je Kostenart.
  • Lebenszyklus (life cycle) = nach Phasen strukturierte Lebensdauer eines Objekts (z. B. ein Produkt oder eine Dienstleistung).
  • Lebenszyklusmodell (life cycle model) = geordnete Menge von Phasen, die ein Produkt oder eine Dienstleistung in bestimmter Anordnung zwingend durchläuft.
  • Leistung (performance) = Fähigkeit eines Systems, in quantitativer oder qualitativer Hinsicht eine bestimmte Aufgabe zu erfüllen.
  • Leistungsmanagement (performance management) = Managementprozess, dessen Zweck die Analyse der Leistung und deren zielgerichtete Beeinflussung ist.
  • Nutzen (benefit) = Wert einer Handlungsalternative zur Befriedigung eines definierten Bedarfs. Synonym: Nutzwert.
  • OR = Operations Research; Anwendung mathematischer Methoden zur Vorbereitung und Herbeiführung optimaler Entscheidungen.
  • Prognose (forecast) = Voraussage einer zukünftigen Entwicklung oder eines zukünftigen Zustands auf Grundlage systematisch ermittelter Daten und Verwendung wissenschaftlicher Erkenntnisse.
  • Projektplanung (project planning) = Prüfung der Realisierbarkeit der Anforderungen eines Projekts durch Herausarbeitung seiner organisatorischen, technischen, personellen, rechtlichen und wirtschaftlichen Konsequenzen (z. B. Aufgabenplanung, Terminplanung).

Zweck der Wirtschaftlichkeitsanalyse

Zweck der Wirtschaftlichkeitsanalyse ist es, Systeme oder Systementwürfe sowie Produkte und Dienstleistungen, aber auch die Entwicklung und/oder den Einsatz von Methoden und Werkzeugen, kurz: jede Art von Investition im IT-Bereich unter dem Formalziel Wirtschaftlichkeit zu beurteilen. Dies erfolgt durch Analyse, d. h. durch Zerlegen des betrachteten Objekts in Teile, das Untersuchen dieser Teile und das Zusammenfassen der Beurteilungen zu einem Befund, nämlich dem der Wirtschaftlichkeit.

Unter Wirtschaftlichkeit wird die Eigenschaft eines Objekts verstanden, bezüglich einer geplanten oder tatsächlichen Kostensituation in einem bestimmten Verhältnis zu einer Bezugsgröße (z. B. der günstigsten Kostensituation) oder bezüglich seiner Leistungssituation (z. B. Nutzen oder Nutzwert) in einem bestimmten Verhältnis zu einer Bezugsgröße (z. B. dem mit Kosten bewerteten Einsatz an Produktionsfaktoren zur Erbringung einer Leistung) zu stehen (vgl. Lerneinheit SZIEL). Ergebnis einer Wirtschaftlichkeitsanalyse ist das Kosten-Nutzen-Verhältnis des untersuchten Objekts. Im Mittelpunkt der folgenden Erklärung stehen Analyseobjekte, deren Gegenstand die Entwicklung neuer oder die wesentliche Veränderung bestehender Informationssysteme ist (Entwicklungsprojekte). Je nach Analyseobjekt sind objektspezifische Anpassungen des Analysemodells erforderlich.

Das Ergebnis eines Entwicklungsprojekts ist dann wirtschaftlich, wenn die Kosten der Entwicklung und Einführung (rollout) zuzüglich der Kosten der Nutzung (Nutzungs- oder Betriebskosten) des Projektergebnisses und der späteren Änderungen daran (z. B. Wartungskosten, Reengineering-Kosten) bezogen auf den geplanten Einsatzzeitraum einschließlich der Kosten der Entsorgung unter dem erwarteten Nutzen liegen. Der Nutzungszeitraum wird häufig als Lebenszyklus bezeichnet, weil er mehrere unterschiedliche „Lebensphasen“ umfasst (vgl. Lerneinheit LEMAN). Lebenszykluskosten sind die für den gesamten Lebenszyklus prognostizierten Kosten. Das sind nicht nur die Kosten des IT-Bereichs, sondern auch Kosten, die durch den IT-Einsatz in den Fachbereichen verursacht werden (z. B. für einen IT-Koordinator), sowie Kosten für Leistungen, die von anderen Fachbereichen für den IT-Bereich erbracht werden (z. B. Leistungen des Rechnungswesens, des Controllings oder der Revision). Die Gesamtheit dieser Kosten wird als Total Cost of Ownership (TCO) bezeichnet. Werden die TCO durch die Anzahl Nutzungsjahre dividiert, wird von jährlichen Lebenszykluskosten gesprochen. Nach dieser Terminologie ist das Projektergebnis dann wirtschaftlich, wenn seine Lebenszykluskosten unter dem erwarteten Nutzen für den gesamten Lebenszyklus liegen. Beim Vergleich nutzengleicher Alternativen gilt, dass die Alternative optimal ist, deren Lebenszykluskosten kleiner sind als die der anderen Alternativen.

Für die Evaluierung der Leistungssituation ist zu berücksichtigen, dass Leistungen nur teilweise quantitativ erfasst werden können; viele Leistungen sind häufig das Resultat einer Schätzung oder nur qualitativ erfassbar. Deshalb ist es erforderlich, neben der üblichen Wirtschaftlichkeitsanalyse eine umfassende Beurteilung der Kosten- und Leistungssituation durchzuführen (z. B. mit einer Nutzwertanalyse, vgl. Lerneinheit NUTZW). Dabei wird für alle definierten Projektziele das Ausmaß der Zielerreichung ermittelt und über das gesamte Zielsystem der Nutzwert bestimmt. Die Ergebnisse der Wirtschaftlichkeitsanalyse gehen als Ausmaß der Zielerreichung für das Projektziel Wirtschaftlichkeit in die Nutzwertanalyse ein.

Anforderungen der Wirtschaftlichkeitsanalyse

Eine Wirtschaftlichkeitsanalyse für ein Entwicklungsprojekt kann erst durchgeführt werden, wenn die Ergebnisse verschiedener Teile der Projektplanung vorliegen (z. B. Aufgabenplanung, Personalplanung, Sachmittelplanung und Terminplanung bei Projekten der Systementwicklung). Diese Planungen bestimmen mit ihrem sachlichen Lösungsvorschlag die voraussichtlichen Kosten der Entwicklung, Einführung, Nutzung und Weiterentwicklung sowie mit den geplanten Funktionen und Leistungen den Nutzen des Projektergebnisses. Grundproblem der Wirtschaftlichkeitsanalyse ist, dass ein Projekt bzw. sein Ergebnis in seiner Wirkung auf Kosten und Nutzen nicht isoliert betrachtet werden kann; mit der Verwendung von Wirtschaftlichkeitsmodellen wird versucht, dieses Problem zu lösen (vgl. den gleichnamigen Abschnitt weiter unten).

Die Analyse der Wirtschaftlichkeit erfordert Prognosen über Kosten und Nutzen und ist mit Unsicherheit behaftet. Je später ein Kostenfaktor oder ein Nutzenfaktor in der Zukunft wirksam wird, desto unsicherer ist die Aussage, die zum Analysezeitpunkt über seine tatsächliche Höhe gemacht werden kann. Kostenprognosen sind grundsätzlich sicherer als Nutzenprognosen, und Entwicklungskosten sind grundsätzlich genauer prognostizierbar als die erst während der Einführung und häufig auch erst während der Nutzung entstehenden Betriebskosten und Wartungskosten. Nutzenprognosen werden durch kurze Lebenszyklen der Technologien erschwert, da Erfahrungswerte schnell veralten. Die Wirtschaftlichkeitsanalyse muss je nach Projektumfang und Projektdauer in bestimmten Projektphasen bzw. an deren Ende (z. B. an den Meilensteinterminen) überprüft, korrigiert, vertieft und schließlich, nach der Systemeinführung, verifiziert werden (Ex-post-Evaluierung, vgl. Lerneinheit TECHM).

Mit diesem planmäßigen Nachjustieren der Wirtschaftlichkeitsanalyse soll auch ihre willkürliche Verwendung (z. B. zum „Abwürgen“ eines Projekts) sowie eine Verwendung, die sich nur am Projektnotstand orientiert (z. B. zum Nachweis der weiterhin bestehenden Wirtschaftlichkeit) vermieden werden. An welchen Terminen bzw. bei Vorliegen welcher Zwischenergebnisse im Projektverlauf weitere Wirtschaftlichkeitsanalysen durchgeführt werden, sollte durch die Projektplanung festgelegt werden, die sich an den Anforderungen des verwendeten Vorgehensmodells orientiert (vgl. Lerneinheit VOMOD). Dies schließt nicht aus, dass sie auch ad hoc veranlasst werden können (z. B. durch den Lenkungsausschuss, vgl. Lerneinheit STRUK, auf Grund von Feststellungen der projektbegleitenden Revision, vgl. Lerneinheit REVIS).

Vorgehensweise der Wirtschaftlichkeitsanalyse

Im wörtlichen und eigentlichen Sinne heißt Wirtschaftlichkeitsanalyse Folgendes:

  • Analyse der Kostenstruktur,
  • Analyse der Nutzenstruktur und
  • Analyse der Beziehungen zwischen Kosten und Nutzen.

Die Betonung liegt auf Analyse, nicht auf Ermittlung einzelner Indikatoren für Wirtschaftlichkeit (z. B. Amortisationsdauer bei einer statischen Methode oder interner Zinsfuß bei einer dynamischen Methode der Wirtschaftlichkeitsrechnung, vgl. weiter unten).

Analyse der Kostenstruktur

Kostenstruktur ist die Höhe und Zusammensetzung der Kosten nach Kostenarten, die für die Aufgaben der Entwicklung und Einführung (Entwicklungskosten), der Nutzung oder des Betriebs (Nutzungskosten oder Betriebskosten) und der Wartung (Wartungskosten) eines Informationssystems entstehen. Entwicklungskosten, Betriebskosten und Wartungskosten können wie folgt in Kostenarten gegliedert werden (Mindestgliederung):

  • Personalkosten und Personal-Nebenkosten (wie Löhne, Gehälter, Sozialleistungen, Arbeitsplatzkosten),
  • Hardwarekosten (wie Mietkosten bzw. Abschreibungen und Wartungskosten),
  • Softwarekosten (wie Lizenz- und Wartungskosten bei Fremdbezug bzw. Abschreibungen bei Fremdbezug oder Eigenfertigung),
  • Netzkosten (wie Leitungskosten und Kosten für Transportdienste),
  • Materialkosten (wie für Formulare, Datenträger, Mikrofilme),
  • Energiekosten im Rechenzentrum (wie Stromverbrauch für Hardwarebetrieb und Klimatisierung) und im Büroumfeld (wie Stromverbrauch für PCs und Arbeitsplatzdrucker),
  • Kosten für Büroausstattung und -geräte,
  • Grundstücks- und Gebäudekosten (wie Pacht, Miete und Instandhaltung) und
  • Fremdkosten (wie Beratungskosten und Kosten für Outsourcing).

Zweck der Kostenartengliederung ist es, die Kostenarten zu identifizieren, bei denen sich Höhe und Zusammensetzung der Kosten im geplanten Zustand (Sollzustand) gegenüber dem gegenwärtigen Zustand (Istzustand) wesentlich verändern. Dabei kann die Verwendung der für die Kosten- und Leistungsrechnung üblichen Kostenstruktur hilfreich sein, obwohl diese grundsätzlich einen anderen Zweck erfüllt (vgl. Lerneinheit KOLER). Dadurch kann für das geplante Informationssystem eine Kostenstruktur sichtbar gemacht werden, die gegenüber dem Istzustand und/oder einem anderen Vergleichszustand (z. B. dem branchenüblichen oder bestmöglichen) vorteilhaft ist. Die Veränderung (Kostenreduzierung und/oder Kostenverschiebung) muss beurteilt werden.

Die Analyse der Kostenarten erfolgt in der Reihenfolge ihrer relativen Bedeutung an den Gesamtkosten (d. h. die Kostenart mit der relativ größten Bedeutung werden zuerst untersucht). Aussagen über die Kostenstruktur allein können zu Fehlschlüssen führen, da jede einzelne Kostenart auch die Höhe der Gesamtkosten und über die Höhe der Gesamtkosten die relative Bedeutung der anderen Kostenarten bestimmt. Aus der Kostenstruktur allein lässt sich nicht erkennen, ob das Kostenniveau zu hoch ist; dies kann nur durch Gegenüberstellung der Kosten mit anderen Kennzahlen oder dadurch beurteilt werden, dass die Kosten mit absoluten Zahlen von Alternativen oder mit Sollgrößen verglichen werden (z. B. mit einem Competitive Benchmarking, vgl. Lerneinheit MEGPM).

Bei der Analyse der Kostenstruktur werden auch die Kosten erfasst und untersucht, die Gemeinkosten sind; dies erfolgt methodisch mit der Gemeinkosten-Wertanalyse. Analog zur Vorgehensweise bei der Wertanalyse werden die Gemeinkosten daraufhin untersucht, ob die sie verursachenden Funktionen für die Erreichung des Zwecks des Untersuchungsobjekts unbedingt erforderlich (Hauptfunktionen), nur erforderlich (Nebenfunktionen) oder überflüssig sind. Bei der Durchführung der Gemeinkosten-Wertanalyse wird von der Annahme ausgegangen, dass ein bestimmter Teil, etwa zwischen einem Viertel bis einem Drittel, der die Gemeinkosten verursachenden Funktionen überflüssig ist, so dass auf sie verzichtet werden kann, ohne die vom Anwender genutzte Funktionalität und geforderte Leistung des Untersuchungsobjekts zu verringern. Ohne eine solche realistische Annahme über das Verbesserungspotenzial lohnt sich erfahrungsgemäß eine Wertanalyse nicht.

Zweck der Wertanalyse (WA) ist es, den Wert eines Objekts (WA-Objekt) durch ein Mehr an Funktionserfüllung und/oder ein Weniger an Kosten zur Realisierung der Funktionserfüllung zu steigern. Die Benennung „Wert“ wird auch verwendet, wenn außer den Kosten noch andere Faktoren betrachtet werden (z. B. Zuverlässigkeit, Verfügbarkeit von Ressourcen, Zeit). Dabei ist nicht das WA-Objekt in seiner physischen Realisierung Mittelpunkt der Betrachtung, sondern dessen Funktionen und der Wert der Funktionserfüllung für die Benutzer. Diese Sichtweise entspricht der für Entwicklungsprojekte typischen Methodik, die zwischen logischem Modell (Systementwurf) und physischem Modell (Systemimplementierung) unterscheidet und die fordert, sich von den physischen Attributen des Istzustands zu lösen und physische Attribute des Sollzustands als alternative Realisierungsmöglichkeiten eines logischen Modells des Sollzustands zu verstehen (vgl. dazu Heinrich/Heinl/Riedl, 116 f.).

Zur Ergänzung zur Kostenstrukturanalyse und zur Analyse des Kostenniveaus kann durch eine Kostenverlaufsanalyse der Einfluss sprungfixer Kosten transparent gemacht werden. Für viele IT-Betriebsmittel typisch ist, dass eine steigende Arbeitslast bis zur Kapazitätsgrenze ohne wesentliche Änderung des Systemverhaltens (z. B. der Transaktionszeiten) möglich, bei Erreichen der Kapazitätsgrenze die Erweiterung der Kapazität des betreffenden Betriebsmittels bzw. die Anschaffung weiterer Betriebsmittel erforderlich ist.

Analyse der Nutzenstruktur

Nutzenstruktur ist die Zusammensetzung des Nutzens nach Nutzenarten oder Nutzenfaktoren und deren Ausmaß; es gelten die Aussagen analog, die zur Analyse der Kostenstruktur gemacht wurden. Folgende Nutzenfaktoren werden unterschieden: direkt monetär messbarer Nutzen, indirekt monetär messbarer Nutzen und nicht monetär messbarer Nutzen.

  • Ein direkt monetär messbarer Nutzen entsteht durch Kostensenkung (Minderkosten des geplanten Systems gegenüber dem bestehenden). Technologieunterstützung führt zu Kostensenkung, wenn durch geringere Kosten für Betriebsmittel höhere Personalkosten, und andere Sachkosten ersetzt werden. Zur Messung des monetären Nutzens werden die Werte der Kostenrechnung des bestehenden Systems gemäß Kosten- und Leistungsrechnung (vgl. Lerneinheit KOLER) den Kosten des geplanten Systems gegenübergestellt.
  • Der indirekt monetär messbare Nutzen hat zwei Formen. Erstens können durch Technologieunterstützung Kosten gesenkt werden (z. B. Lagerkosten durch Verringerung des Lagerbestands). Zweitens kann durch Produktivitätssteigerung eine zukünftige Kostensteigerung vermieden werden (z. B. durch Marktausdehnung oder Sortimentserweiterung). Die Erfassung des indirekt monetär messbaren Nutzens erfolgt über eine Erfassung von Mengen (z. B. Umsatzsteigerung) und deren Bewertung (z. B. mit Marktpreisen oder Verrechnungspreisen).
  • Der nicht monetär messbare Nutzen entsteht durch organisatorische und personelle Veränderungen wie Verbesserung der Qualität von Entscheidungen durch besseres Informationsangebot, Verbesserung der innerbetrieblichen und zwischenbetrieblichen Kommunikation und Erhöhung der Fachkompetenz der Mitarbeiter und der Arbeitszufriedenheit. An die Stelle der (direkten oder indirekten) Nutzenmessung tritt eine Nutzenschätzung.

Analyse der Kosten-Nutzen-Beziehungen

Bei der Analyse der Beziehungen zwischen Kostenstruktur und Nutzenstruktur handelt es sich um ein umfassendes Verfahren der Gliederung und Aufbereitung der beiden Bezugsgrößen der Wirtschaftlichkeit, also der Kosten und des Nutzens. Dabei werden die einzelnen Kostenarten und Nutzenarten so miteinander vernetzt, dass eine zahlenmäßige Abbildung der Beziehungszusammenhänge hergestellt wird. Damit lässt sich der komplexe Zusammenhang zwischen Kosten und Nutzen auf kausale bzw. funktionale Einflussgrößen zurückführen. Gefragt wird also danach, welche Nutzenart welche Kostenart(en) verursacht bzw. – umgekehrt betrachtet – welche Kostenart welche Nutzenart(en) generiert. Von den Antworten dazu ausgehend wird wertanalytisch untersucht, durch welche Veränderungen der Kostenstruktur und/oder der Nutzenstruktur die Wirtschaftlichkeit positiv beeinflusst werden kann, indem Funktionen und/oder Leistungen des Analyseobjekts verändert werden bzw. auf sie verzichtet wird (Änderung des durch Anforderungsanalyse erstellten Anforderungsprofils).

Wegen der Abhängigkeiten der einzelnen Kostenarten und Nutzenarten voneinander lassen sich derartige Beziehungszusammenhänge oft nur schwer isolieren und quantifizieren. Dies führt zu der Forderung, die Kostenstruktur und die Nutzenstruktur nicht zu fein zu wählen. Zwischen einer zu feinen Gliederung und einer zu groben Gliederung muss ein Kompromiss gefunden werden. Kennzahlen über Beziehungszusammenhänge, die aus umfassenden Analysen gewonnen werden (z. B. aus Branchenuntersuchungen), lassen im Vergleich mit Plandaten oder mit Daten anderer Alternativen erkennen, wo Schwachstellen bestehen und wo Maßnahmen zur Verbesserung der Wirtschaftlichkeit angesetzt werden können (vgl. auch Lerneinheit KENNZ). Auch eine nur verbale Beschreibung der Beziehungszusammenhänge ist erfahrungsgemäß hilfreich, wenn eine Quantifizierung nicht möglich ist.

Aktivierung von Entwicklungskosten

Für die Analyse der Kostenhöhe, der Kostenstruktur und des Kostenverlaufs sowie für Zwecke der Kosten- und Leistungsrechnung (vgl. Lerneinheit KOLER) werden auch bei Eigenfertigung die Entwicklungskosten zu Herstellungskosten aktiviert und daraus Abschreibungen ermittelt. In der Regel erfolgt eine lineare Abschreibung über drei bis vier Jahre. Handels- und steuerrechtlich ist – nach deutscher und österreichischer Rechtslage – eine Aktivierung der Entwicklungskosten dagegen nur bei Fremdbezug zulässig (§ 197 Abs. 2 bzw. § 248 Abs. 2 HGB). Das Aktivierungsverbot dient primär dem Gläubigerschutz (Vorsichtsprinzip), widerspricht aber einer periodengerechten Erfolgsermittlung und der Vermittlung eines möglichst getreuen Bildes der Vermögens- und Ertragslage. In der Fachliteratur (z. B. bei Pirker) wird ein Aktivierungswahlrecht vorgeschlagen, wobei die Aktivierung an das Vorliegen einer verlässlichen Kosten- und Leistungsrechnung gebunden ist. Damit verbunden sein soll die Verpflichtung zu einem gesonderten Ausweis der aktivierten Beträge, zur Festlegung eines begrenzten Abschreibungszeitraums und zu einer Ausschüttungssperre sowie Erläuterungspflichten im Anhang zum Jahresabschluss. Die International Accounting Standards (IAS) erlauben die Aktivierung unter folgenden Voraussetzungen:

  • Das Produkt ist klar definiert und die im Zusammenhang mit ihm entstandenen Kosten lassen sich direkt zuordnen und zuverlässig bestimmen.
  • Die technische Durchführbarkeit des Produkts kann nachgewiesen werden.
  • Das Unternehmen beabsichtigt, das Produkt zu vermarkten oder selbst zu verwenden.
  • Ein Markt für das Produkt ist vorhanden oder – sofern es nur intern genutzt werden soll – kann sein Nutzen für das Unternehmen nachgewiesen werden.
  • Ausreichende Ressourcen für die Durchführung und den Abschluss des Projekts und den Vertrieb oder Einsatz des Produkts sind vorhanden oder ihre Verfügbarkeit kann nachgewiesen werden.

Softwareaktivierung in diesem Sinne darf nicht mit der häufig gleich bezeichneten Sicherungsmaßnahme zum Kopierschutz verwechselt werden, die treffender Produktaktivierung genannt wird (vgl. Lerneinheit VERMA).

Wirtschaftlichkeitsrechnungen

Entscheidende Schwäche der Verfahren der Wirtschaftlichkeitsrechnung ist, dass nur monetäre Größen verwendet und qualitative Wirkungen nicht berücksichtigt werden. Sie ersetzen die Wirtschaftlichkeitsanalyse daher nicht, können sie aber ergänzen. Für eine umfassende Beurteilung der Wirtschaftlichkeit ist es zweckmäßig, Verfahren zu verwenden, die mehrere Einzelansätze kombinieren. Nach dem Zeitpunkt der Durchführung werden zwei Formen der Wirtschaftlichkeitsrechnung unterschieden, Planungsrechnungen und Kontrollrechnungen.

  • Planungsrechnungen ermitteln die Wirtschaftlichkeit vor der Entscheidung (ex ante), um die im Sinne der Zielsetzung optimale Handlungsalternative zu ermitteln; es handelt sich um Soll-Soll-Vergleiche.
  • Kontrollrechnungen ermitteln während und/oder nach der Entscheidung (ex post), inwieweit die Zielplanung verwirklicht werden konnte; es handelt sich um Soll/Ist-Vergleiche.

Für das Technologiemanagement sind sowohl Planungsrechnungen als auch Kontrollrechnungen von Bedeutung. Die meisten Methoden der Wirtschaftlichkeitsrechnung sind für einfache, meist monetäre Ziele entwickelt worden. Sie werden nach dem verwendeten mathematischen Modelltyp in zwei Gruppen geordnet, nämlich Ermittlungsmodelle (Methoden der Investitionsrechnung) und quantitative Entscheidungsmodelle (OR-Modelle). Beide Modelltypen werden zur Beantwortung der folgenden Fragen verwendet:

  • Ist eine geplante Investition (z. B. ein Entwicklungsprojekt) unter bestimmten Voraussetzungen „absolut“ vorteilhaft?
  • Welche von mehreren alternativen Investitionen (z. B. mehrere Entwicklungsprojekte) ist unter bestimmten Voraussetzungen vorteilhafter?

Für die Beantwortung der zweiten Frage muss die Forderung nach der absoluten Vorteilhaftigkeit erfüllt sein.

Ermittlungsmodelle

Diese verwenden entweder statische oder dynamische Methoden. Der wesentliche Unterschied besteht darin, dass statische Methoden keine zeitlichen Gesichtspunkte im Entstehen der Einzahlungen und Auszahlungen berücksichtigen, während dies bei dynamischen Methoden der Fall ist (z. B. zu Verrechungspreisen bewertete Erlöse interner IT-Leistungen als Einzahlungen und Anschaffungskosten für IT-Betriebsmittel zur Erbringung dieser Leistungen als Auszahlungen, vgl. Lerneinheit KOLER). Da in der Wirklichkeit Einzahlungen und Auszahlungen zu unterschiedlichen Zeitpunkten stattfinden und da ihr Wert umso höher ist, je früher sie entstehen (et vice versa), entsprechen dynamische Methoden eher der Wirklichkeit als statische Methoden. Der daraus folgenden größeren Genauigkeit der dynamischen Methoden steht die leichtere praktische Handhabung der statischen Methoden gegenüber.

Statische Methoden sind Kostenvergleichsrechnung, Gewinnvergleichsrechnung, Rentabilitätsrechnung und Amortisationsrechnung.

  • Die Kostenvergleichsrechnung stellt die Kosten der Alternativen einander gegenüber. In den Kostenvergleich werden alle Kostenarten einbezogen, in denen sich die Alternativen unterscheiden. Optimal ist die Alternative mit den geringsten Kosten.
  • Die Gewinnvergleichsrechnung erweitert die Kostenvergleichsrechnung um die Erlöse; es wird der Gewinn der Alternativen als Differenz zwischen Erlösen und Kosten ermittelt. Optimal ist die Alternative mit dem höchsten Gewinn.
  • Mit der Rentabilitätsrechnung wird der Durchschnittsgewinn einer Periode (z. B. ein Jahr oder der gesamte Lebenszyklus) zum durchschnittlich gebundenen Kapital in Beziehung gesetzt. Ergebnis ist die Durchschnittsverzinsung des durchschnittlich gebundenen Kapitals (Rentabilität). Optimal ist die Alternative mit der höchsten Rentabilität.
  • Mit der Amortisationsrechnung wird der Zeitraum ermittelt, in dem das für eine Alternative eingesetzte Kapital aus den Rückflüssen wiedergewonnen wird (Amortisationszeit). Optimal ist die Alternative mit der kürzesten Amortisationszeit.

Dynamische Methoden sind verschiedene Vermögenswertmethoden und Zinssatzmethoden.

  • Vermögenswertmethoden ermitteln den Vermögenszuwachs während der Planperiode bei gegebenem Zinssatz. Zu dieser Methodengruppe gehören die Kapitalwertmethode (auch Vermögensbarwertmethode genannt) und die Vermögensendwertmethode. Die Kapitalwertmethode bezieht die Zahlungen auf den Beginn der Planperiode; für die Finanzmittelaufnahme und -anlage wird ein einheitlicher Zinssatz verwendet. Die Vermögensendwertmethode bezieht die Zahlungen auf das Ende der Planperiode; Aufnahmezinssatz und Anlagezinssatz sind nicht identisch.
  • Zinssatzmethoden ermitteln einen Zinssatz bei gegebenem Vermögenszuwachs von Null während der Planperiode. Zu dieser Methodengruppe gehören die Interne-Zinssatz-Methode und die Sollzinssatz-Methode. Die Interne-Zinssatz-Methode bestimmt den Zinssatz aus den Zahlungen; Zinssätze sind nicht vorgegeben. Die Sollzinssatz-Methode bestimmt eine obere Schranke für den Aufnahmezinssatz (Soll) aus den Zahlungen unter Berücksichtigung eines exogenen Habenzinssatzes (Anlagezinssatz).

Die Brauchbarkeit der Investitionsrechnungsmethoden zur Beurteilung der Wirtschaftlichkeit von IT-Investitionen, insbesondere die von IT-Projekten wie Entwicklungsprojekte, ist relativ gering. Um Investitionsbudgets konkurrierende Projekte lassen sich damit sehr gut beurteilen; dies ist aber eine Aufgabe des Portfoliomanagements und damit der strategischen Maßnahmenplanung (vgl. Lerneinheit SPLAN). Für eine Reihe von Auswahlproblemen bei IT-Projekten eignen sich die theoretisch wenig anspruchsvollen statischen Methoden besser als die theoretisch genaueren dynamischen Methoden.

Quantitative Entscheidungsmodelle

Diese Modelle ermitteln die Vorteilhaftigkeit der Alternativen im Hinblick auf ein bestimmtes Ziel. Dazu gehören analytische Methoden und Simulation. Bei Verwendung analytischer Methoden wird das zu lösende Problem (Realproblem) in ein mathematisches Problem (Formalproblem) übertragen. Auf das Formalproblem können verschiedene mathematische Methoden zur Problemlösung angewendet werden (z. B. die Simplex-Methode, ein Verfahren der linearen Programmierung). Das Ergebnis der Lösung des Formalproblems wird auf die Wirklichkeit übertragen, und man erhält so die Lösung des Realproblems. Die Anwendbarkeit analytischer Methoden zur Beurteilung der Wirtschaftlichkeit von IT-Investitionen ist deshalb gering, weil sich die komplexe Wirklichkeit nur selten mit einem vertretbaren Aufwand als mathematisches Modell abbilden lässt.

Besonderes Kennzeichen der Simulation ist die ausdrückliche Problembezogenheit, das heißt, es wird ein konkretes Problem der Wirklichkeit untersucht. Simulationsmodelle sind daher meist stochastische Modelle. . Ihre entscheidende Stärke ist, dass das zu untersuchende System wirklichkeitsnah abgebildet werden kann. Eine Simulationsstudie ist dann zweckmäßig, wenn eine oder mehrere der folgenden Bedingungen für die Problemlösung von Bedeutung sind:

  • Die Wirklichkeit ist zu komplex und/oder zu kompliziert, um sie als ein geschlossen lösbares Formalproblem abbilden zu können; analytische Methoden versagen deshalb.
  • Modellieren und Experimentieren, das heißt das Beobachten des Systemverhaltens am Modell, führen zu einem besseren Problemverständnis.
  • Durch analytische und numerische Methoden ermittelte Problemlösungen können durch Simulation überprüft (verifiziert bzw. falsifiziert) werden.
  • Durch Simulation kann auch das dynamische Verhalten eines Systems, das heißt sein Verhalten im Zeitablauf, beobachtet werden.
  • Durch Simulation können die Auswirkungen gezielter Veränderungen eines Parameters oder einer Kombination von Parametern auf bestimmte Eigenschaften des Systems untersucht werden.

Probleme, die bei einer Simulationsstudie auftreten können, sind:

  • Das Modellieren ist im Allgemeinen mit einem relativ großen Aufwand verbunden.
  • Da jeder Simulationslauf (Modelllauf) eines stochastischen Simulationsmodells nur eine Ausprägung eines stochastischen Prozesses ist, müssen mehrere, oft sehr viele Simulationsläufe durchgeführt werden.
  • Der große Umfang an quantitativen Daten als Ergebnis einer Simulationsstudie erweckt den Anschein eines hohen, nicht immer gegebenen Wahrheitsgehalts, der durch grafische Animation verstärkt wird.
  • Simulation ermittelt keine Problemlösung, sondern zeigt lediglich die Konsequenzen von Entscheidungsalternativen auf; sie hat eher Prognosefunktion als Problemlösungsfunktion.

Simulation besitzt im mathematischen Sinne keine zum Optimum führende Suchstrategie. Im Vordergrund stehen Heuristiken für die Auswahl der untersuchten Alternativen.

Wirtschaftlichkeitsmodelle

Da Ergebnisse von Entwicklungsprojekten im Sinne neuer oder wesentliche veränderter Informationssysteme nicht nur Veränderungen an einzelnen betrieblichen Funktionen (z. B. für bestimmte Aufgaben und nur an bestimmten Arbeitsplätzen), sondern an ganzen Prozessketten (im Sinne von Geschäftsprozessen) oder an wesentlichen Teilen davon hervorrufen, muss die Analyse der Wirtschaftlichkeit funktions- und arbeitsplatzübergreifend bis unternehmensweit angelegt werden. Zudem muss bedacht werden, dass erfahrungsgemäß das Nutzenpotenzial nicht bei einzelnen Tätigkeiten der Prozesskette liegt, sondern zwischen ihnen und zu anderen Prozessketten, an den Schnittstellen also. Mehrstufige Wirtschaftlichkeitsmodelle berücksichtigen diese Einflüsseverwendet. Ein Wirtschaftlichkeitsmodell, das einen Stufen- oder Ebenenansatz verwendet, kann als Referenzmodell dienen. Beispielsweise werden in einem vierstufigen Wirtschaftlichkeitsmodell folgende Wirtschaftlichkeitsstufen oder Wirtschaftlichkeitsebenen unterschieden (nach Reichwald):

  • W1: Isolierte technologiebezogene Wirtschaftlichkeit, mit der Kosten und Nutzen erfasst werden, die unmittelbar dem Technologieeinsatz zuzurechnen sind.
  • W2: Subsystembezogene Wirtschaftlichkeit, mit der die vom Einsatzkonzept und anderen situativen Bedingungen abhängigen Kosten und der Nutzen im Hinblick auf die Arbeitsabläufe erfasst werden.
  • W3: Gesamtorganisationale Wirtschaftlichkeit, mit der die Kosten zur Aufrechterhaltung der Anpassungsfähigkeit und Funktionsstabilität sowie kostenrelevante Humanaspekte und der damit bewirkte Nutzen erfasst werden.
  • W4: Gesellschaftliche Wirtschaftlichkeit, mit der negative Auswirkungen (als Kosten) und positive Auswirkungen (als Nutzen) auf die Unternehmensumwelt erfasst werden.

Bei der Nutzenmessung wird zwischen quantitativen und qualitativen Ausprägungen unterschieden. Bei Verwendung der vier genannten Wirtschaftlichkeitsebenen sowie der Kosten und den beiden Nutzenkategorien ergibt sich eine 12-Felder-Matrix für die Beurteilung der Wirtschaftlichkeit. Verdichtungen und Saldierungen sollen vermieden werden, um die Wirtschaftlichkeit stufenweise sichtbar zu machen (vgl. Abbildung WIRTA-1). Durch die Verwendung des Controlling-Ansatzes (vgl. Lerneinheit CONTR) wird aus der „Ein-Zeitpunkt-Betrachtung“ der Wirtschaftlichkeitsanalyse ein Prozess, der einen Abschnitt im Regelkreis des Controllings darstellt. Beispielsweise kann für ein Vertriebsinformationssystem ein Regelkreis aufgebaut werden, wenn der Vertrieb zusätzliche IT-Kosten über die Erhöhung der Vertriebsziele (z. B. Erhöhung des Deckungsbeitrags) direkt kompensieren kann.

Wirtschaftlichkeitsmodell

Abb. WIRTA-1: (Quelle: Reichwald)

Forschungsbefunde

Mertens stellt fest, dass Ökonomie in der Marktwirtschaft für die Unternehmung Rentabilitätsmaximierung bedeutet und dass sich Wirtschaftlichkeits- und Rentabilitätsmaximierung nicht decken. So genannte Ingenieurziele (z. B. Kostenminimierung, Maximierung der Kapazitätsauslastung) seien theoretisch nur haltbar, wenn zahlreiche Ceteris-Paribus-Klauseln gelten; bei Verwendung dieser Klauseln in der Wirtschaftsinformatik sei große Vorsicht geboten.
Mertens, P.: Operiert die Wirtschaftsinformatik mit falschen Unternehmenszielen? In: Becker, J. et al. (Hrsg.): Wissenschaftstheorie und Wirtschaftsinformatik. Wiesbaden 1999, 379-392


Heinrich/Ambichl haben am Beispiel von Client-Server-Architekturen die Entwicklung und Verwendung von Simulationsmodellen zur Ermittlung der Vorteilhaftigkeit der Alternativen (hier Datenbank-Server vs. File-Server) im Hinblick auf das Ziel Leistung gezeigt. Mit dem Ergebnis dieser Simulationsstudie wurde die Lösung eines Entscheidungsproblems des Auftraggebers unterstützt und die Anwendbarkeit der Simulation als Methode der Wirtschaftlichkeitsanalyse nachgewiesen. Das Untersuchungsdesign kann Referenzmodell für andere Simulationsstudien zur Ermittlung der Wirtschaftlichkeit von IT-Betriebsmitteln sein.

Heinrich, L. J. / Ambichl, E.: Ergebnisse einer Leistungsbewertung von Client-Server-Architekturen. In: Krcmar, H. (Hrsg.): Client-Server-Architekturen. Halbergmoos 1993, 55–101


Högler schlägt vor, die relevanten, projektspezifischen Erfolgsfaktoren in die Wirtschaftlichkeitsanalyse einzubeziehen und bezeichnet dieses Vorgehen als holistische Wirtschaftlichkeitsanalyse, die „…aufgrund ihrer Modularität in ihrer Komplexität an die Bedürfnisse des Unternehmens angepasst werden kann.“ (2) Die Identifikation der Erfolgsfaktoren soll „automatisch“ erfolgen. Die als Framework vorliegende Dokumentation des Vorgehens lässt eine Beurteilung seiner Praxistauglichkeit nicht zu.

Högler, T.: Framework für eine holistische Wirtschaftlichkeitsanalyse mobiler Systeme. Dissertationsprojekt, Institut AIFB, Universität Karlsruhe. http://gi-mms.de/mms2006/kurzbeitraege/hoegler.pdf; Abruf 3.11.2008

Potthof hat zum Zusammenhang zwischen IV-Einsatz und wirtschaftlichem Erfolg u. a. festgestellt (Inhaltsanalyse einschlägiger Publikationen empirischer Studien): „Es besteht eine unzureichende Kenntnis der Auswirkungen des IV-Einsatzes innerhalb eines Unternehmens sowie darüber, welchen Einfluss die IV auf den ‚business value’ tatsächlich hat und welche anderen Faktoren hier einwirken. ....... Der Erfolg von IV-Investitionen hängt in großem Maße vom Faktor Mensch ab, denn Fehlerpotentiale liegen bei der Investitionsentscheidung sowie der Einführung und Nutzung von IV-Technologien und -Systemen.“

Potthof, I.: Empirische Studien zum wirtschaftlichen Erfolg der Informationsverarbeitung. In: WIRTSCHAFTSINFORMATIK 40/1998, 54-65


Befunde verschiedener empirischer Studien (zitiert nach Brynjolfsson/Hitt) besagen, dass rd. die Hälfte der Nutzenwirkung des IT-Einsatzes durch unternehmensübergreifende Faktoren (z. B. Netzwerkeffekte, staatliche Infrastruktur, Ausbildung) bestimmt, die andere Hälfte von unternehmensspezifischen Faktoren beeinflusst wird. Von Unwirtschaftlichkeit des IT-Einsatzes kann daher trotz des IT-Paradoxons nicht die Rede sein, da erst der Einsatz neuer Technologien zu Qualitäts- und Serviceverbesserungen, veränderten Arbeitsbedingungen oder Erschließung neuer Märkte führt. Der Nutzen der IT hängt von einer Reihe von Faktoren ab, welche vom Anwender gestaltet werden müssen, um die Wirtschaftlichkeit von IT-Investitionen zu gewährleisten.
Brynjolfsson, E. / Hitt, L. M: Paradox lost? Firm-level evidence on the returns to information systems spending, in: Management Science 4/1996, 541-558


Hitt/Brynjolfsson berichten über Ergebnisse einer Studie der Wharton School u. a. wie folgt: Durch IT-Einsatz wurden für die Kunden Werte geschaffen und die Produktivität der untersuchten Unternehmen gesteigert; ein Anstieg der Rentabilität konnte nicht nachgewiesen werden.
Hitt, L. M. / Brynjolfsson, E.: Productivity, Business Profitability, and Consumer Surplus. Three different Measures of Information Technology Value. In: MIS Quarterly, 20/1996, 141-142

Aus der Praxis

In der Praxis wird häufig die Frage nach dem Wertbeitrag der IT gestellt, also die Frage; welchen Beitrag die IT zum Unternehmenserfolg leistet, und das IT-Management wird aufgefordert, diese Frage zu beantworten. Dies kann nur so verstanden werden, dass nach dem Beitrag gefragt wird, den das Ergebnis einer bestimmten IT-Investition (z. B. eines Entwicklungsprojekts oder Beschaffungsprojekts) zum Unternehmenserfolg leistet. Dieser Beitrag zum Unternehmenswert ist als die Nutzen-Kosten-Differenz einer jeden IT-Investition ex post mit einer Wirtschaftlichkeitsanalyse ausreichend genau zu ermitteln. Die Frage, die sich auf „die IT im Unternehmen insgesamt“ bezieht, ist nur rhetorischer Art; sie ist nicht gar nicht zu beantworten. IT-Manager sollten mit der Gegenfrage reagieren: Wer fragt eigentlich nach dem Wertbeitrag des Marketings oder der Logistik? (Ergebnis der Erörterung der Frage „IT-Manager – Dienstleister oder Innovator?“ in einem Workshop des ipo.)

Nach Kossow, Projektleiter und Seniorberater der PROJECT CONSULT Unternehmensberatung Kampffmeyer GmbH, Hamburg, eine produkt- und herstellerunabhängige Beratungsgesellschaft für Informationsmanagement (IM), ist TCO „…ein anerkanntes Abrechnungsverfahren, um Verbrauchern und Unternehmen dabei zu helfen, alle anfallenden Kosten von Investitionsgütern (insbesondere in der IT) … abzuschätzen. Dabei werden nicht nur die Anschaffungskosten berücksichtigt, sondern alle Aspekte der späteren Nutzung … der betreffenden Komponenten. Somit können bekannte Kostentreiber oder auch versteckte Kosten möglicherweise bereits im Vorfeld einer Investitionsentscheidung identifiziert werden.“

Aufgabenverweise

  • Wirtschaftlichkeitsanalysen erfordern die meisten strategischen und administrativen IM-Aufgaben.

Kontrollfragen

  1. Wie sollten die Lebenszykluskosten für eine Wirtschaftlichkeitsanalyse gegliedert werden?

  2. Wie erfolgt die Analyse der Beziehungszusammenhänge zwischen Kosten und Nutzen?

  3. Durch welche Merkmale unterscheiden sich Wirtschaftlichkeitsanalysen von Wirtschaftlichkeitsrechnungen?

  4. Unter welchen Voraussetzungen können Entwicklungskosten aktiviert werden?

  5. Was leistet ein Wirtschaftlichkeitsmodell mehr als eine typische Wirtschaftlichkeitsanalyse?Wann wird eine IT-Investition als wirtschaftlich bezeichnet?

  6. Wie können die Kosten und wie kann der Nutzen gegliedert werden?

  7. Wie ist die Brauchbarkeit von Wirtschaftlichkeitsrechnungen zu beurteilen?

Quellen

  • Heinrich, L. J. / Ambichl, E.: Ergebnisse einer Leistungsbewertung von Client-Server-Architekturen. In: Krcmar, H. (Hrsg.): Client-Server-Architekturen. Herausforderungen an das Informations­management. Halbergmoos 1993, 55-101

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

  • Högler, T.: Framework für eine holistische Wirtschaftlichkeitsanalyse mobiler Systeme. Dissertationsprojekt, Institut AIFB, Universität Karlsruhe. http://gi-mms.de/mms2006/kurzbeitraege/hoegler.pdf; Abruf: 3.11.2008

  • ipo: Stellenbild des Informationsmanagers. http://www.ipo.jku.at/index.php?menuid=103; Abruf: 19.5.2008

  • Kossow, R.: http://www.erpmanager.de/magazin/artikel_1339_tco_total_cost_ownership_wirtschaftlichkeit.html; Abruf 20.5.2011

  • Mertens, P.: Operiert die Wirtschaftsinformatik mit falschen Unternehmenszielen? - 15 Thesen. In: Becker, J. et al. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie: Bestandsaufnahme und Perspektiven. Wiesbaden 1999, 379-392

  • Ott, H. J.: Wirtschaftlichkeitsanalyse von EDV-Investitionen mit dem WARS-Modell am Beispiel der Einführung von CASE. In: WIRT­SCHAFTS­IN­FOR­MA­TIK 6/1993, 522-531

  • Pirker, S.: Bilanzierung von Software. Wien 1992

  • Reichwald, R.: Ein mehrstufiger Bewertungsansatz zur wirtschaftlichen Leistungsbeurteilung der Bürokommunikation. In: Hoyer, R. H. / Kölzer, G. (Hrsg.): Wirtschaftlichkeitsrechnungen im Bürobereich. Berlin 1987, 23-33

Vertiefungsliteratur

  • Blohm, H. / Lüder, K. / Schaefer, C.: Investition – Schwachstellenanalyse des Investitionsbereichs und Investitionsrechnung. 9. A., München 2006

  • Faisst, U. / Prokein, O. / Wegemann, N.: Ein Modell zur dynamischen Investitionsrechnung von IT-Sicherheitsmaßnahmen. In: Zeitschrift für Betriebswirtschaft 5/2007, 511–538

  • Lercher, H. J.: Wertanalyse an Informationssystemen. Wiesbaden 2000

  • Pauls, W.: Wirtschaftlichkeitsanalyse analytischer Informationssysteme. Saarbrücken 2007

  • Sprenger, J. / Klages, M. / Breitner, M. H.: Wirtschaftlichkeitsanalyse für die Auswahl, die Migration und den Betrieb eines Campus-Management-Systems. In: WIRTSCHAFTSINFORMATIK 4/2010, 211–223

  • Zarnekow, R. / Scheeg, J. / Brenner, W.: Untersuchung der Lebenszykluskosten von IT-Anwendungen. In: WIRTSCHAFTSINFORMATIK 3/2004, 181–187

Normen

  • EN 1325-1: Value Management, Wertanalyse, Funktionenanalyse Wörterbuch, Teil 1: Wertanalyse und Funktionenanalyse.

  • ÖNORM A 6757: Wertanalyse-Management: Planung, Durchführung und Controlling der Wertanalyse.
  • Abbildungsarchiv: Wirtschaftlichkeitsanalyse (WIRTA)

Vorgehensmodelle (VOMOD)

Lernziele

Sie wissen, für welche Zwecke Vorgehensmodelle verwendet werden. Sie kennen die Bedeutung von Vorgehensmodellen für Entwicklung und Wartung der Informationsinfrastruktur. Sie haben einen Überblick über typische Vorgehensmodelle für die Softwareentwicklung und können erklären, unter welchen Umständen sie sinnvoll eingesetzt werden können.

Definitionen und Abkürzungen

  • agil (agile) = von großer Beweglichkeit zeugend, wendig; Bündel von Eigenschaften einer Klasse von Vorgehensmodellen und Entwicklungstechniken. Substantiv: Agilität.

  • Aktivität (activity) = in sich geschlossene Folge von Tätigkeiten, deren Unterbrechung kein sinnvolles Ergebnis liefert. Synonyme: Arbeitsschritt, Operation.

  • inkrementell (incremental) = schrittweise.

  • Iteration (iteration) = Wiederholung einer bestimmten Folge von Aktivitäten.

  • Konfiguration (configuration) = Menge definierter Elemente eines Systems, die zu einem bestimmten Zeitpunkt gemeinsam eine Aufgabe erfüllen sollen und dazu in Wirkungsweise und Schnittstellen aufeinander abgestimmt sind.

  • Phase (phase) = Gruppierung von Aktivitäten.

  • Phasenmodell (phase model) = systematische Gliederung einer Aufgabe in mehrere aufeinander folgende Phasen, die inhaltlich, technisch und organisatorisch unterscheidbar sind, charakteristische Ziele haben, Methoden erfordern und Ergebnisse erzeugen.

  • PMBOK = Project Management Body of Knowledge; Empfehlungen des Project Management Institutes zum Projektmanagement.

  • Prince2 = PRojects IN Controlled Environments; britischer Projektmanagementstandard.

  • Prozess (process) = Menge von Teilprozessen, Prozess- und Arbeitsschritten, die durch einen Input, interne Funktionen und einen Output gekennzeichnet ist.

  • Release (release) = Version eines Systems, die an den Auftraggeber ausgeliefert wird.

  • RUP = Rational Unified Process.

  • sequenziell (sequential) = aufeinander folgend; der Reihe nach.

  • Scrum = engl. Gedränge, ein agiles Vorgehensmodell.

  • Tailoring = Anpassung (z. B. eines Vorgehensmodells) an die aktuelle Aufgabe.

  • UML = Unified Modeling Language.

  • Validierung (validation) = Prüfung der Tauglichkeit eines Objektes für die vorgesehene Aufgabe.

  • Verifizierung (verification) = Prüfung eines Objektes gegen die Spezifikation.

  • Version (version) = Ausprägung eines Systemelements zu einem bestimmten Zeitpunkt.

  • V-Modell XT = Vorgehensmodell, extreme tailoring; Entwicklungsstandard für IT-Systeme des Bundes (Deutschland).

  • XP = Extreme Programming.

Abbildungen

VOMOD-2

VOMOD-4

VOMOD-5

VOMOD-6

 

Zweck von Vorgehensmodellen
Merkmale von Vorgehensmodellen
Kategorisierung von Vorgehensmodellen
Entwicklung von Vorgehensmodellen
Aufgabentypen in Vorgehensmodellen
Vorgehensmodelle für die Softwareentwicklung
Vorgehensmodelle für andere Aufgaben
Forschungsbefunde
Aus der Praxis

Aufgabenverweise

Kontrollfragen

  1. Welche Kategorien von Vorgehensmodellen werden unterschieden und welche Eigenschaften haben sie?

  2. Welche Aufgabentypen werden in Vorgehensmodellen beschrieben?

  3. Wodurch zeichnen sich agile Vorgehensmodelle aus?

  4. Wie lässt sich folgende These begründen? „Je schlechter die Zeiten, desto leichter die Vorgehensmodelle.“

  5. Worin besteht der Unterschied zwischen einem Vorgehensmodell und einem Reifegradmodell?

  6. Worin besteht der Unterschied zwischen dem V-Modell und dem V-Modell XT?

Quellen

  • Balzert, H.: Lehrbuch der Softwaretechnik: Softwaremanagement. 2. A., Heidelberg 2008

  • Beck, K. / Andres, C.: Extreme Programming Explained: Embrace Change. 2. A., Reading 2004

  • Beck, K.: Embracing Change with Extreme Programming. In: Computer 10/1999, 70-79

  • Beck, K.: Extreme Programming Explained: Embrace Change. Reading 2000

  • Boehm, B. W.: A Spiral Model of Software Development and Enhancement. In: IEEE Computer 5/1988, 61-72

  • Boehm, B. W.: Guidelines for Verifying and Validating Software Requirements and Design Specifications. In: Samet, P. A. (Hrsg.): EURO IFIP: Proceedings of the European Conference on Applied Information Technology. Amsterdam et al. 1979, 711-719

  • Boehm, B. W.: Software Engineering Economics. Englewood Cliffs 1981

  • Guntamukkala, V. / Wen, H. J. / Tarn, J. M.: An Empirical Study of Selecting Software Development Life Cycle Models. In: Human Systems Management 4/2006, 265-278

  • 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

  • Jacobson, I. / Booch, G. / Rumbaugh, J.: The unified software development process. Amsterdam 1999

  • Joecks, F.: Kurzbericht: SCRUM & V-Modell XT in einem Projekt. München 2010; http://www.bpm-soa-center.com Abruf 28. Juni 2011

  • o. V.: V-Modell XT Version 1.3 Berlin 2008

  • Kruchten, P.: The Rational Unified Process. An Introduction. 3. A., Amsterdam 2004

  • Office of Government Commerce: Managing Successful Projects with PRINCE2. London 2005

  • Project Management Institute: A Guide to the Project Management Body of Knowledge: PMBOK Guide. 4. A., Newton Square 2010

  • Royce, W.: Managing the Development of Large Software Systems. In: Proceedings, IEEE WESCON August/1970, 1-9

Vertiefungsliteratur

  • Becker, J. / Knackstedt, R. / Pöppelbuß, J.: Entwicklung von Reifegradmodellen für das IT-Management - Vorgehensmodell und praktische Anwendung. In: WIRTSCHAFTSINFORMATIK 3/2009, 249–260

  • Cockburn, A.: Crystal Clear: A Human-Powered Methodology for Small Teams. Amsterdam 2004

  • Hruschka, P.: Agility. (Rück)-Besinnung auf Grundwerte in der Softwareentwicklung. In: Informatik Spektrum 6/2003, 397–401

  • Kneuper, R. / Wiemers (Hrsg.), M.: Leichte Vorgehensmodelle. 8. Workshop der Fachgruppe 5.11 der Gesellschaft für Informatik e. V. (GI). Aachen 2001

  • Langer, P. et al.: Vorgehensmodelle für die Entwicklung hybrider Produkte – eine Vergleichsanalyse. In: Schumann, M. et al. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2010. Göttingen 2010, 2043–2056

  • Padberg, F. / Tichy, W.: Schlanke Produktionsweisen in der modernen Softwareentwicklung. In: WIRTSCHAFTSINFORMATIK 3/2007, 162–170

  • Rausch, A. / Broy, M.: Das V-Modell XT: Grundlagen, Erfahrungen und Werkzeuge. Heidelberg 2008

  • Schwaber, K. / Beedle, M.: Agile Software Development with Scrum. Upper Saddle River 2001

  • Thomas, O. / Leyking, K. / Scheid, M.: Serviceorientierte Vorgehensmodelle: Überblick, Klassifikation und Vergleich. In: Informatik-Spektrum 4/2010, 363–379

  • Versteegen, G.: Projektmanagement mit dem Rational Unified Process. Berlin et al. 2000

Informationsmaterial

Normen

  • IEEE 1074-2006: IEEE Standard for Developing a Software Project Life Cycle Process

  • ISO 10007:2003: Quality management systems - Guidelines for configuration management

  • ISO/IEC 12207:2008: Systems and software engineering - Software life cycle processes

  • ISO/IEC 15288:2008: Systems and software engineering - System life cycle processes

Links

Vertragsmanagement (VERMA)

Lernziele

Sie kennen den Zweck des Vertragsmanagements, die Vertragszwecke und die sich daraus ergebenden Aufgaben. Sie wissen, wie diese Aufgaben institutionalisiert werden. Sie kennen Vertragstypen und Vertragsarten und wissen, um welchen Vertragstyp es sich bei welchem Vertragsgegenstand handelt. Sie kennen den Inhalt und die Gliederung von Hardware- und Softwareverträgen sowie den Zweck von Modellverträgen.

Definitionen und Abkürzungen

  • Angebot (tender) = zeitlich befristeter Vertragsantrag eines potenziellen Auftragnehmers an einen potenziellen Auftraggeber über die Realisierung eines Beschaffungsprojekts.

  • Auftrag (order) = Aufforderung zur Erbringung einer definierten Leistung.

  • Auftraggeber (orderer) = natürliche oder juristische Person, die einen Auftrag vergibt.

  • Auftragnehmer (contractor) = natürliche oder juristische Person, die einen Auftrag übernimmt und i. d. R. auch durchführt (Hersteller, Softwarehaus, Systemhaus).

  • CISG = United Nations Convention on Contracts for the International Sale of Goods.

  • Cookie = kleine Datei, die der Betreiber einer Website einem Nutzer beim Aufruf dieser Seite auf dessen Computer kopiert (wörtlich Keks).

  • DRM = Digital Rights Management.

  • ERMS = Enterprise Rights Management System.

  • ITCL = IT Contract Library; eine Moduldatenbank zur Vertragsgestaltung.

  • Lizenz (license) = vertragliche Einräumung eines Rechts zur Nutzung eines Objekts.

  • Mantelvereinbarung (blanket agreement) = Vertrag mit Vertragsinhalten, die längerfristig gültig und daher für mehrere Verträge relevant sind. Synonym: Rahmenvertrag.

  • Nutzungsrecht (usufructuary right) = Recht, das den Inhaber einer Nutzungsbewilligung berechtigt, ein urheberrechtlich geschütztes Werk im vereinbarten Umfang zu nutzen.

  • OCG = Österreichische Computergesellschaft.

  • Produktaktivierung (product activation) = Form des Softwareschutzes zur Verhinderung von Softwarepiraterie. Synonym: Softwareaktivierung.

  • Risiko (risk) = Kombination aus zu erwartender Häufigkeit bzw. Eintrittswahrscheinlichkeit eines gefährdenden Ereignisses und dem beim Ereigniseintritt zu erwartenden Schadensausmaß.

  • Vertrag (contract) = das durch Antrag und Annahme zwischen zwei oder mehreren Personen zum Abschluss gelangende Rechtsgeschäft.

  • Vertragsbestand (contract inventory) = Gesamtheit der im Unternehmen vorhandenen Verträge über die Lieferung und Wartung von Produkten und das zur Verfügung stellen von Dienstleistungen des IT-Markts.

  • Vertragsrecht (contract law) = Recht, das die zwischen Privatpersonen oder juristischen Personen frei verhandelten und vereinbarten Rechtsbeziehungen regelt.

  • Vorgehensmodell = (procedure model) = Prozess zum Lösen eines Problems, der in Modellphasen abgebildet ist.

Zweck des Vertragsmanagements
Vertragszwecke
Aufgaben des Vertragsmanagements
Lizenzmanagement
Institutionalisierung des Vertragsmanagements
Vertragstypen und Vertragsarten
Vertragsinhalt und Vertragsgliederung
Mustervertrag bzw. Modellvertrag
Werkzeuge des Vertragsmanagements
Abrechnungsmodelle
Aus der Praxis

Kontrollfragen

  1. Welche Aufgaben hat das Vertragsmanagement?
  2. Durch welche Besonderheiten ist Lizenzmanagement als Teil des Vertragsmanagements gekennzeichnet?
  3. Wie sollte das Vertragsmanagement institutionalisiert sein?
  4. Welche Zwecke werden mit Muster- bzw. Modellverträgen verfolgt?
  5. Was sind Abrechnungs-, Kosten- oder Preismodelle als Vertragsbestandteil?
  6. Um welchen Vertragstyp handelt es sich, wenn Nutzungsrechte an Standardsoftware erworben bzw. überlassen werden bzw. wenn Nutzungsrechte an Individualsoftware erworben bzw. überlassen werden?

Quellen

  • Abrechnungsmodelle für Cloud Services: http://www.cloud-practice.de; Abruf 4.4.2011

  • CUNO: http://www.consono.de/index.php/de/sapso/clmsams; Abruf 3.4.2011

  • Heusler, B. / Roland, M.: IT-Vertragsrecht. Zürich 2004

  • Heussen, B. (Hrsg.): Handbuch Vertragsverhandlung und Vertragsmanagement. 3. A., Köln 2007

  • IIR-Arbeitskreis DV-Revision: Prüfung der Software-Lizenzen. In: Zeitschrift Interne Revision 1+2/1999, 20–34

  • Jaburek, W. J.: Handbuch der EDV-Verträge. Musterverträge für Anwender und Anbieter Bd. I. 3. A., Wien 2000

  • Jaburek, W. J.: Handbuch der EDV-Verträge. Musterverträge für Anwender und Anbieter Bd. II., Wien 2003

  • Michels, J. K.: http://www.jomi1.com/; Abruf 4.3.2011

  • Pfarl, W. (Hrsg.): IT-Verträge – Handbuch für Praktiker. Wien 2007

  • Spider Contract: http://www.brainwaregroup.com/index.php?id=812; Abruf 3.4.2011

  • Straub, W.: „Legal Engineering“ – Was Juristen und Ingenieure voneinander lernen könnten. Neue Zürcher Zeitung vom 15./16.5.2004, 54

Vertiefungsliteratur

  • Achilles, W.-A. (Hrsg.): Kommentar zum UN-Kaufrecht (CISG). 2. A., München 2011

  • Becker, E. / Buhse, W. / Günnewig, D. / Rump, N. (Eds.): Digital Rights Management – Technological, Economic, Legal and Political Aspects. Lecture Notes in Computer Science 2770. Berlin/Heidelberg 2003

  • Groll, T.: 1x1 des Lizenzmanagements. Praxisleitfaden für Lizenzmanager. 2. A., München 2010

  • Madauss, B. J.: Handbuch Projektmanagement. 7. A., Stuttgart 2006 (insbes. Kapitel XIII Vertragsmanagement im Projekt)

  • Marly, J.: Software-Überlassungsverträge. 4. A., München 2004

  • Redeker, H.: Handbuch der IT-Verträge. Loseblattwerk, Berlin 2000 ff.

Informationsmaterial

  • CICS Table of Contracting States: http://www.cisg.law.pace.edu/cisg/countries/cntries.html; Abruf 8.5.2011

  • OCG-Arbeitskreis EDV-Leistungsverträge (Hrsg.): Musterverträge für Software Bd. 1 Kauf- und Mietvertrag, Bd. 2 Werkverträge, Bd. 3 Wartungsvertrag. OCG-Schriftenreihe Bde. 38, 63 und 108, Wien 1987, 1997 und 1998
  • SWICO/SVD (Hrsg.): Vertragsmodelle – Beschaffungsverträge, Dienstleistungsverträge, Projektverträge, Übrige Verträge. 2. A., Zürich 1999

Normen und Standards

  • DIN 69905: Projektabwicklung, Begriffe. 1997

  • IEEE Standard 729-1983: Glossary of Software Engineering Terminology

  • ISO/IEC 19770-1: Software Asset Management. 2006