Kapitel 5 meiner Masterthesis "Outsourcing des IT-Strategieentwicklungsprozesses in österreichischen Klein- und Kleinstunternehmen"

Kapitel 5: Strategische Handlungsanweisungen für Klein- und Kleinstunternehmen in Bezug auf Einsatz von Informationstechnologie


Diese Artikelserie beinhaltet meine Masterthesis “Outsourcing des IT-Strategieentwicklungsprozesses in österreichischen Klein- und Kleinstunternehmen”, welche ich im Rahmen des Universitätslehrgangs Management in Information and Business Technologies an der Alpen-Adria-Universität Klagenfurt geschrieben habe.

  1. Kapitel: Einleitung
  2. Kapitel: Begriffsdefinition
  3. Kapitel: Beachtenswerte Umwelten von Klein- und Kleinstunternehmen in Österreich
  4. Kapitel: Strategische Ziele und kritische Erfolgsfaktoren einer IT-Strategie
  5. Kapitel: Strategische Handlungsanweisungen für Klein- und Kleinstunternehmen in Bezug auf Einsatz von Informationstechnologie
  6. Kapitel: IT-Controlling in Klein- und Kleinstbetrieben
  7. Kapitel: Resümee und Ausblick

5. Strategische Handlungsanweisungen für Klein- und Kleinstunternehmen in Bezug auf Einsatz von Informationstechnologie

5.1. Verknüpfung der strategischen Ziele mit Handlungsanweisungen

Für die im Rahmen der Strategieentwicklung festgelegten Ziele und daraus resultierenden Projekte werden Maßnahmen bzw. Handlungsanweisungen zur Zielerreichung definiert. Die Verknüpfung erfolgt über eine Ursache-Wirkungs-Kette, wie in Abbildung 9 exemplarisch dargestellt wurde. Dabei muss jede Handlungsanweisung einen Wertebeitrag zur Erreichung eines oder mehrerer strategischer Ziele liefern.

Eine IT-Strategie muss individuell für jedes Unternehmen entwickelt werden. Daraus resultiert eine große Zahl möglicher Handlungsanweisungen, deren komplette Ausführung den Rahmen dieser Arbeit sprengen würde. Aus diesem Grund befasst sich der kommende Abschnitt nur exemplarisch mit neun Handlungsfeldern, welche in nahezu allen Unternehmen - unabhängig von Branche und Größe - im Rahmen einer IT-Strategieumsetzung behandelt werden sollten.

5.2. Anforderungs- und Beschaffungsmanagement

Jeder Bezug von Hardware, Software oder IT-Dienstleistung verursacht einen monetären oder personellen Aufwand. Die Menge und Komplexität der Beschaffungsvorgänge zu reduzieren und den Beschaffungsprozess zu steuern ist die Aufgabe des Beschaffungsmanagements. Auch die Verwaltung von Verträgen wie Rahmen-, Einzel- und Wartungsverträgen und die Optimierung1 (Preis, Volumen, Lizenzmodelle) sowie die Entscheidung zwischen Eigenfertigung und Fremdbezug (“Make or Buy”) fällt in den Aufgabenbereich des Beschaffungsmanagements.2

Der Beschaffungsprozess setzt sich zusammen aus dem Anforderungsprozess, dem Bestellprozess, dem Lieferprozess und weiteren Teilprozessen wie in Abbildung 12 exemplarisch gezeigt:3

Abbildung 12: Haupt- und Teilprozesse des Beschaffungsprozesses Abbildung 12: Haupt- und Teilprozesse des Beschaffungsprozesses.4

Im Anforderungsprozess werden die Bedarfsmeldungen gesammelt, kategorisiert und bewertet. Auf Basis der Daten aus dem Anwendungsmanagement (s. Kapitel 5.3), dem Plattformmanagement (s. Kapitel 5.5) und dem Lebenszyklusmanagement (s. Kapitel 5.4) kann für den Bedarf die optimale, zur IT-Strategie passende Lösung ausgewählt werden.5 Die exakten Anforderungen müssen zu diesem Zeitpunkt bereits definiert sein oder an dieser Stelle definiert werden, bevor die Genehmigung ausgestellt wird. Das Anforderungsmanagement dient zusätzlich als zentrale Anlaufstelle für alle Bedarfsmeldungen und kann dadurch die parallele Bestellung verhindern und die unternehmensweite Nutzung vereinbarter Einkaufskonditionen sicherstellen.6 Am Ende des Anforderungsprozesses stehen die Freigabe und die Bestellung.

Der Bestellprozess beschäftigt sich mit der Abwicklung der Bestellungen sowie der Einhaltung der Einkaufs- und Vertragskonditionen. Es ist wichtig, bereits während des Bestellprozesses auf die Gewährleistung der rechtlichen Compliance (s. Kapitel 3.3) zu achten, beispielsweise die richtige Lizensierung von Software.

Der letzte Schritt des Beschaffungsprozesses ist die Abwicklung der Lieferung. Diese umfasst die Übernahme und Zuordnung (Zu welcher Bestellung gehört die gelieferte Ware?), die Prüfung (Wurde die bestellte Ware vollständig und unbeschädigt geliefert?) und die Ablage und Archivierung (zum Beispiel von Lizenzdokumenten).7 Diese Teilprozesse können je nach Unternehmenssituation variieren.

In der Praxis ist das Anforderungs- und Beschaffungsmanagement Klein- und Kleinstunternehmen zumeist ein sehr überschaubarer Bereich, welcher im besten Fall von einer einzelnen Abteilung oder einer einzelnen Person gehandhabt wird. Die Abwicklung des Bestell- und Lieferprozesses sollte auch in diesen Unternehmen ein Standardprozess sein. Ein Dienstleister kann daher hauptsächlich unterstützend im Anforderungsprozess mitwirken, etwa durch die Abstimmung der Anforderungs-spezifikation mit der IT-Strategie und der Händlerauswahl. Zusätzlich kann eine Beratungsfunktion für Compliance-Themen eingenommen werden.

5.3. Anwendungsmanagement

Im Rahmen des Anwendungsmanagements werden die im Unternehmen eingesetzten IT-Anwendungssysteme dokumentiert, bewertet und regelmäßig auf Effektivität und Relevanz im Rahmen der vorgegebenen IT-Architektur geprüft.8

In jedem Unternehmen existieren zahllose Anwendungen, angefangen vom Unternehmensweiten ERP-System bis hin zum einzelnen Excel-Makro9 zur Berechnung einer speziellen Kennzahl. Die Aufgabe des Anwendungsmanagements besteht darin, diese Vielzahl von Anwendungen zu erfassen, den Unternehmensbeitrag zu bewerten und die Anwendung aufgrund dieser Bewertung entweder in den Unternehmensstandard aufzunehmen, in eine bestehende Standardanwendung zu konsolidieren oder aufzulösen.10 Zu diesem Zweck wird eine Liste aller eingesetzten Standardanwendungen angelegt und den Geschäftsprozessen zugeordnet. Kann eine Anwendung keinem Geschäftsprozess zugeordnet werden liefert sie keinen Unternehmensbeitrag und wird aufgelöst.

Die Anwendungsdokumentation wirkt unterstützend bei der Bereinigung der Anwendungs- und Systemlandschaft mit. Als wesentlicher Vorteil ergibt sich die einfache Erkennbarkeit mehrgleisig oder nicht mehr genutzter Anwendungen. Zusätzlich wird die Vereinheitlichung von Anwendungen für vergleichbare Geschäftsprozesse ermöglicht.11 Auch die Zusammenhänge und Abhängigkeiten zwischen den Geschäftsprozessen und Anwendungen (und damit den Anwendungssystemen) werden durch die Dokumentation offensichtlich.12 Diese Informationen erleichtern die Abschätzung der Auswirkungen von Modifikationen an Standardsystemen und diesen als wertvoller Input für das Plattformmanagement.

Die zweckmäßige Führung der Anwendungsdokumentation in einfacher Tabellenform hat sich in der Praxis für kleine Betriebe bewährt. Die Zuordnung der Anwendungen zu den Geschäftsprozessen lässt sich über eine Matrix abbilden und auswerten. Diese Dokumentation sollte zumindest jährlich aktualisiert und geprüft werden.

In Abbildung 13 werden beispielhaft installierte Anwendungen erhoben und Geschäftsprozessen zugeordnet. Anwendungen, welche keinem Prozess zugeordnet sind können so auf einen Blick identifiziert werden:13

Abbildung 13: Beispiel für die Anwendungsdokumentation in Klein- und Kleinstunternehmen Abbildung 13: Beispiel für die Anwendungsdokumentation in Klein- und Kleinstunternehmen.14

Die Führung der Anwendungsdokumentation ist in Klein- und Kleinstunternehmen in den seltensten Fällen eine Kernkompetenz, wodurch das Anwendungsmanagement vollständig an einen Dienstleister vergeben werden kann. Die jährliche Abstimmung der Anwendungsdokumentation erfolgt zwischen der Geschäftsführung beziehungsweise der Abteilungsleitung und dem Dienstleister, während dieser die gesamte Anwendungswartung, -Aktualisierung und -Verwaltung durchführen kann.

5.4. Lebenszyklusmanagement

Das Lebenszyklusmanagement (LifeCycle Management) regelt die Entstehung, den Betrieb und die Ablösung von IT-Systemen. Application LifeCycle Management im Besonderen beschäftigt sich mit der IT-Anwendungslandschaft und war eines der Top-5-Themen in Capgeminis IT-Trends 2012.15 Die Technologielebenszyklen in der IT sind sehr kurz. So beschreibt etwa Moores Gesetz eine Verdopplung der in einem Prozessor verbauten Transistoren alle 18 Monate.16 Auch die Lebenszyklen von Betriebssystemen und Anwendersoftware verkürzen sich zunehmend. Beispielhaft für diese Entwicklung ist der beliebte Web-Browser “Mozilla Firefox” mit einem Lebenszyklus von nur 12 Monaten und einem monatlichen Release-Zyklus.17 Um diese Fülle an neuen und aktualisierten Technologien zu beherrschen benötigt jedes Unternehmen eine umfassende und vorausblickende Strategie.18

Während neue Technologien viele Vorteile mit sich bringen, darunter etwa höhere Performance, mehr Energieeffizienz und eine bessere Unterstützung der Geschäftsprozesse birgt jedes Upgrade auch Risiken. Neben den Kosten für ein Upgrade, das bedeutet Investition in neue Hard- und Software, die Migration auf das neue Systeme und die Schulung der Anwender, muss die Kompatibilität mit allen damit verbundenen Systemen sichergestellt werden.

In den Rahmen des Lebenszyklusmanagement fällt neben der Installation und regelmäßigen Wartung auch die planmäßige Stilllegung und Entsorgung abgelöster IT-Systeme. Darunter fällt etwa die Auflösung von Wartungs- und Lizenzverträgen, fachgerechte Datenlöschung und Entsorgung von Hardware.19

Für Klein- und Kleinstunternehmen ist eine einfache Aufstellung der eingesetzten Systeme und Anwendungen mit grundlegenden Daten zum Lebenszyklus (Garantiezeitraum, Lizenz-Laufzeit, Update-Zeitraum) sinnvoll. Anhand dieser Aufstellung werden im Rahmen einer jährlichen Prüfung die folgenden Fragen beantwortet und gegebenenfalls Maßnahmen ergriffen:

  • Erfüllt das System seinen Zweck und arbeitet es wirtschaftlich?
  • Wie lange kann das System noch wirtschaftlich eingesetzt werden? Wann muss es abgelöst werden?
  • Kann das System im Fehlerfall repariert oder ersetzt werden? Welcher Aufwand ist damit verbunden?
  • Welche Systeme sind damit verbunden? Welcher Aufwand entsteht bei einem Ausfall?

Abbildung 14 zeigt exemplarisch, wie die grundlegenden Lebenszyklusdaten der IT-Systeme eines Kleinstunternehmens in einer einfachen Tabelle abgebildet werden können. Farbige Symbole verdeutlichen akuten und baldigen Handlungsbedarf:

Abbildung 14: Exemplarische IT-Lebenszyklustabelle eines Kleinstunternehmens Abbildung 14: Exemplarische IT-Lebenszyklustabelle eines Kleinstunternehmens.20

Für Klein- und Kleinstbetriebe ist es in den meisten Fällen wirtschaftlicher, die Planung und Aktualisierung der Lebenszyklusdaten, die Inbetriebnahme neuer und Entsorgung alter Systeme sowie die Dokumentation der Abhängigkeiten an einen Outsourcing-Partner zu vergeben.21 Lediglich die jährliche Abstimmung des Handlungsbedarfes muss durch die Geschäftsführung oder die Abteilungsleitung erfolgen.

5.5. Plattformmanagement

Das Plattformmanagement beschäftigt sich mit den Fragen, welche Hard- und Softwarekomponenten im Unternehmen eingesetzt werden, und gibt die Richtlinien für zukünftige Beschaffungsvorgänge vor. Ziel ist es, durch Reduktion auf wenige verschiedene Komponenten einen hohen Grad an Standardisierung und Automatisierung zu erzielen.22 Werden im gesamten Unternehmen dieselben Hardwarekomponenten eingesetzt steigt dadurch implizit die Verfügbarkeit von Ersatzgeräten bzw. Ersatzteilen. Zusätzlich sinken die Schulungskosten für Anwender und technisches Personal.23

In Klein- und Kleinstunternehmen ist es beispielsweise häufig üblich, Hardware aus dem Consumer-Bereich einzusetzen. Während die Anschaffungskosten bei diesen Geräten gegenüber Business-Modellen geringer ist, müssen Consumer-Modelle zur Reparatur in den meisten Fällen an ein Reparaturzentrum des Herstellers gesendet werden. Da hierbei sensible Unternehmensdaten von Dritten eingesehen werden könnten ist dieser Vorgang auch für Kleinunternehmen oft zu riskant. Die Reparatur durch einen Techniker vor Ort ist daher in nahezu allen Fällen die bevorzugte Lösung, die jedoch mit zusätzlichen Kosten verbunden ist. Eine Kostenanalyse im Rahmen des Plattformmanagements hätte bereits im Vorfeld die versteckten Folgekosten aufzeigen können.

Durch die Entwicklung von unternehmens- und abteilungsweiten Plattformstandards lässt sich der Wartungs- und Schulungsaufwand bestehender Systeme noch weiter reduzieren, während die Bereitstellung zusätzlicher Systeme für neue Mitarbeiter rascher abgewickelt werden kann.

Da die Entwicklung eines Plattformstandards technologiegestützt sehr einfach möglich, das Wissen zur Umsetzung in Klein- und Kleinstunternehmen jedoch kaum vorhanden ist bietet sich die Unterstützung durch einen IT-Dienstleister an.24 Dieser kann bei der Entwicklung und Weiterentwicklung des Standards in allen Phasen - von der Konzeption bis zur Umsetzung und Wartung - unterstützend tätig werden.

5.6. Innovationsmanagement

Innovationsmanagement ist vor allem in größeren Unternehmen eine eigenständige und nicht IT-gebundene Managementdisziplin.25 In dieser Arbeit wird jedoch nur auf die direkt mit IT zusammenhängenden Aspekte des Innovationsmanagements eingegangen. Im Folgenden wird daher der Begriff “Innovationsmanagement” mit “IT-Innovationsmanagement” gleichgesetzt.

Innovation ist eines der Kernelemente der Informationstechnologie und kann durch die duale Rolle der IT einem Unternehmen Wettbewerbsvorteile bringen oder neue Geschäftsfelder ermöglichen.26 Innovation bedingt jedoch nicht selten eine Änderung von Prozessen und birgt daher auch Risiken. Keine andere Branche produziert so viele Innovationen in kürzester Zeit wie die IT selbst. Es haben jedoch nicht alle einen hinreichenden Reifegrad erreicht, um den Ansprüchen der unternehmerischen Realität zu genügen.27 Innovation muss daher durch IT-Innovationsmanagement gesteuert werden.

Als Basis für den Innovationsprozess dienen die 10 wichtigsten “Key Business Driver”, welche sich je nach Unternehmensrealität ergeben.28 Die Abstimmung und Bewertung der Innovationsprojekte zwischen den “Key Business Drivers” und der IT-Strategie ist die Hauptaufgabe des Innovationsmanagements.29 Innovationsansätze werden laufend in großer Zahl aus den unterschiedlichsten Quellen - allen voran von Kunden, Lieferanten, Mitbewerbern und den eigenen Mitarbeitern - geliefert. Sie müssen jedoch als solche erkannt, dokumentiert und bewertet werden.

In Klein- und Kleinstunternehmen lässt sich dies am einfachsten durch ein Vorschlagswesen oder in weiterer Folge durch Ideenmanagement realisieren.30 Von Kunden- und Lieferantenseite kommende Innovationsansätze verbergen sich oft hinter Beschwerden oder Kritik und sind daher schwer zu erkennen.31 Eine Kombination des Innovationsmanagements mit dem Beschwerde- und Feedbackmanagement ist daher denkbar.

Wurde ein Innovationsansatz als übereinstimmend mit den “Key Business Drivers” und der IT-Strategie bewertet, wird die Durchführung einer Machbarkeitsanalyse empfohlen. Bei umfangreichen Innovationen empfiehlt sich zusätzlich die Durchführung einer Wirtschaftlichkeitsrechnung. In Klein- und Kleinstunternehmen deren Fokus nicht im IT-Bereich liegt, kann ein Dienstleister den Innovationsmanager bei der Abstimmung mit der IT-Strategie und der Machbarkeitsanalyse unterstützen und Input für die Wirtschaftlichkeitsrechnung liefern.

Bei der Umsetzung der Innovation können die technischen Aspekte (etwa Anpassung und Upgrade der betroffenen IT-Systeme) durch einen Dienstleister durchgeführt werden.

Die organisatorischen Aspekte - also die Anpassung von Unternehmensprozessen - erfordern jedoch auch in kleinen Unternehmen die Steuerung durch den Innovationsmanager, die Geschäfts- oder Abteilungsleitung. Sie können nicht allein durch einen Dienstleister realisiert werden.32

5.7. Risikomanagement

Ausgangspunkte des Risikomanagements sind die Identifikation der Gefahren, ihrer Ursachen und Auswirkungen und die anschließende Analyse und Bewertung der möglichen Risiken.33 Erfasste Gefahren werden anhand der Eintrittswahrscheinlichkeit und der Auswirkungen kategorisiert und in einem Risikographen abgebildet.34 Tabelle 3 stellt einen beispielhaften Risikographen mit den Achsen “Eintrittswahrscheinlichkeit” und “Auswirkung” dar und hilft bei der Einordnung der Risiken in die Prioritätsstufen 1 (rot 🟥, “hohe Priorität”), 2 (gelb 🟨, “normale Priorität”) und 3 (grün 🟩, “niedrige Priorität”).

Auswirkung
Eintrittswahrscheinlichkeit
unbedeutendgeringspürbarkritischkatastrophal
häufig🟨 2🟨 2🟥 1🟥 1🟥 1
möglich🟨 2🟨 2🟨 2🟥 1🟥 1
selten🟩 3🟨 2🟨 2🟨 2🟥 1
sehr selten🟩 3🟩 3🟨 2🟨 2🟨 2
unwahrscheinlich🟩 3🟩 3🟩 3🟨 2🟨 2

Tabelle 3: Beispielhafte Abbildung eines Risikographen.35

Die Gefahren werden in der einfachsten Form in einer Liste gesammelt und nach der über den Risikographen berechneten Priorität geordnet wie in Tabelle 4 beispielhaft dargestellt:

GefahrWahrscheinlichkeitAuswirkungPriorität
Feuerseltenkatastrophal🟥 1
Ausfall der Stromversorgungmöglichkritsch🟥 1
Wasser, Flüssigkeitenseltenkritisch🟨 2
Erdbebenunwahrscheinlichkritisch🟨 2
Ausfall der Internetverbindungmöglichgering🟨 2
Verlust von Schlüsselkräftenmöglichspürbar🟨 2
Vandalismussehr seltengering🟩 3

Tabelle 4: Beispiel - anhand eines Risikographen priorisierte Gefahren.36

Unabhängig von der Priorität muss jedes Risiko bewertet und behandelt werden. So kann ein bekanntes Risiko entweder vermieden, durch personelle, technische oder organisatorische Maßnahmen vermindert oder begrenzt werden.37 Ist ein Risiko nicht vermeidbar, verminderbar oder begrenzbar kann es gegebenenfalls versichert werden, ansonsten muss es akzeptiert und selbst getragen werden und zählt gemeinsam mit den nicht identifizierbaren Risiken als “Restrisiko”. Es ist in jedem Fall notwendig, die Entwicklung der Risiken laufend zu verfolgen und gegebenenfalls Maßnahmen zu ergreifen.

Abbildung 15: Risikobewertung Abbildung 15: Risikobewertung.38

In Klein- und Kleinstunternehmen bewegt sich die Summe der möglichen IT-Risiken, je nach Unternehmensform und Ausrichtung in einem überschaubaren Rahmen. Für eine erste Analyse stellt die Bundessparte “Information und Consulting” der Wirtschaftskammer Österreich (WKO) ein Risikoanalysetool für Kleine und Mittelgroße Unternehmen (KMU) in Form einer Microsoft Excel Tabelle zur Verfügung.39 Die Analyse kann selbständig oder mit Unterstützung eines Dienstleisters durchgeführt werden. Zur Erarbeitung von Maßnahmen sollte auf die Hilfe von Experten zurückgegriffen werden.

5.8. Datenmanagement

Jedes Unternehmen produziert täglich große Mengen an Daten. Durch Emails, Textdokumente, Präsentationen, Auswertungen, Programmcode und Berechnungen aber auch Telefongespräche und persönliche Besprechungen entstehen Daten welche bewertet, verarbeitet und gespeichert oder verworfen werden müssen. Die Erfassung erfolgt entweder automatisiert oder manuell, wobei letztere deutlich fehleranfälliger ist. Das Grundprinzip des Datenmanagements ist es, zu wissen welche Datenbestände es im Unternehmen gibt und sicherzustellen, für alle Daten einen verantwortlichen Eigner mit konkreten Rechten und Pflichten zu definieren.40

Tiemeyer beschreibt die Notwendigkeit, die Übersicht über die Unternehmensdaten nicht zu verlieren als Teil des IT-Architekturmanagements:

Die zur Realisierung von Geschäftsprozessen benötigten Daten müssen identifiziert und dokumentiert sowie mit ihren Beziehungen in einer Datenarchitektur beschrieben werden. Die Beschreibung sollte in einem Modell und einer Darstellungsform erfolgen, die die Gesamtheit der Daten vollständig für alle an Informationssystem-entwicklungsprozessen beteiligten Akteuren verständlich und konsistent wiedergibt.41

Einer der wichtigsten Punkte im Datenmanagement ist der Datenschutz. Unternehmenskritische Daten, vertrauliche und persönliche Daten haben einen höheren Schutzbedarf vor unbefugtem Zugriff, Änderung, Löschung oder Weitergabe. Die wesentlichen Grundbedrohungen im Datenmanagement betreffen die Verfügbarkeit, Integrität und Vertraulichkeit der Daten:42

  • Als verfügbar gelten Daten nur, wenn auch alle Programme, Hardware und sonstige für die Verarbeitung notwendigen Mittel zur Verfügung stehen.
  • Die Integrität der Daten ist nur dann gegeben, wenn sie korrekt und unverfälscht sind.
  • Unter Vertraulichkeit wird verstanden, dass Daten nur von befugten Personen gelesen oder bearbeitet werden können. Das gilt sowohl bei gespeicherten Daten als auch bei der Datenübertragung.

Im ersten Schritt ist es dazu nötig, Daten nach Vertraulichkeit, Sensibilität, Verfügbarkeit und Integrität zu klassifizieren.43 Für Klein- und Kleinstunternehmen hat sich die Klassifizierung in den drei Stufen “vertraulich”, “intern” und “offen” in der Praxis bewährt:

VertraulichkeitBeschreibung
Klasse V
”vertraulich”
Klasse “V” trifft zu, wenn die Informationen unter strafrechtlichem Geheimhaltungsschutz stehen, ihre Preisgabe zudem die Gefahr einer Schädigung der Firmeninteressen schaffen würde oder ihre Geheimhaltung im besonderen Firmeninteresse gelegen ist.
Klasse I
“intern”
Klasse “I” trifft zu, wenn die unbefugte Weitergabe den Firmeninteressen zuwiderlaufen würde.
(z. B.: interner Schriftverkehr, interne Telefonverzeichnisse, Organisationspläne, alle nicht klassifizierten Informationen)
Klasse O
”offen”
Für Informationen die ausdrücklich für die Veröffentlichung freigegeben wurden.
(z. B.: Gesetze, Verordnungen, Pressemitteilungen)

Tabelle 5: Vertraulichkeitsklassen.44

Die Klassifizierung nach Sensibilität erfolgt nach dem österreichischen Datenschutzgesetz §§8-9:45

SensibilitätBeschreibung
Klasse NKlasse N “nicht personenbezogene Informationen”:
Alle Informationen die nicht unter die §§8 und 9 DSG zu subsumieren sind.
Klasse PKlasse P “personenbezogene, nicht sensible Daten”:
Alle Informationen die unter §8 Abs. 1 - 3 zu subsumieren sind.
Klasse STKlasse ST “personenbezogene Daten mit strafrechtlichem Inhalt”:
Alle Informationen die unter §8 Abs. 4 DSG zu subsumieren sind.
Klasse SKlasse S “sensible personenbezogene Daten”:
Alle Informationen die unter §9 DSG zu subsumieren sind.

Tabelle 6: Sensibilitätsklassen.46

Um den Verfügbarkeitsanspruch von IT-Anwendungen und den damit verbundenen Daten darstellen zu können hat sich für kleine Betriebe die Definition der folgenden Verfügbarkeitsklassen bewährt:

VerfügbarkeitBeschreibung
Klasse 1Keine Vorsorge bzw. unkritisch Für die IT-Anwendung werden keine besonderen Vorkehrungen getroffen. Datenverlust bzw. Ausfall der IT-Anwendung auf un¬bestimmte Zeit ist denkbar. Eine Behinderung der Wahrnehmung der Aufgaben der be¬troffenen Organisationseinheiten entsteht dadurch nicht oder nur in einem akzeptablen Ausmaß.
Das Risiko des Datenverlustes bzw. des notwendigen Aufwandes für die Rekonstruktion der Daten wird in Kauf genommen.
Klasse 2Datensicherung Es sind gängige Sicherungsmaßnahmen für die IT-Anwendung vorgesehen, ein Datenverlust ist auszuschließen.
Die IT-Anwendung kann bei technischen Problemen erst nach deren Behebung am ursprünglichen Produktionssystem in Betrieb genommen werden.
Die Sicherung wird an einen externen Ort ausgelagert.
Klasse 3Redundante Infrastruktur Die Infrastruktur für die IT-Anwendung ist derart ausgelegt, eine unterbrechungsfreie Fortführung des Betriebes bei Ausfall einer IT-Komponente durch redundante Auslegung zu ermöglichen.
Die Datenbestände werden zusätzlich gesichert.

Tabelle 7: Verfügbarkeitsklassen.47

Die Daten eines Unternehmens sollten stets mit der höchstmöglichen Integrität zur Verfügung stehen. Hierfür sind technische und organisatorische Maßnahmen (Datensicherung, Schutz vor Viren und Malware, Digitale Signaturen) einzusetzen.48 Für kleine Organisationen empfiehlt sich die Verwendung von zwei Integritätsklassen mit unterschiedlichem Schutzbedarf:

IntegritätBeschreibung
Klasse U
”unkritisch”
Trifft zu, wenn aus einem Integritätsverlust keinerlei Konsequenzen für das Unternehmen zu erwarten sind.
Klasse K
”Kritisch”
Trifft zu, wenn aus einem Integritätsverlust wesentliche Konsequenzen, sowohl finanzieller Art und/oder ein Imageverlust, für das Unternehmen zu erwarten sind.

Tabelle 8: Integritätsklassen.49

Die Sicherung der Datenqualität obliegt immer dem Autor, ebenso die Klassifizierung nach Vertraulichkeit und Sensibilität. Dies bedeutet implizit, dass jedem Mitarbeiter die Regeln im Umgang mit Daten und die Richtlinien zur Klassifizierung vertraut sein müssen.

Im weitesten Sinne trifft dies auch auf externe Berater und Dienstleister zu, sofern diese Zugang zu Unternehmensdaten erhalten.50 Zusätzlich sollten zur Wahrung eines konsistenten Datenstandes Maßnahmen getroffen werden, um Daten möglichst nur einmal zu erfassen und an einer zentralen Stelle zu speichern.

In der Praxis wird oft vergessen, dass auch Daten einem Lebenszyklus unterliegen. Es ist daher eine regelmäßig Prüfung der beschriebenen Datenschutzkriterien unerlässlich. Dabei wird die Verfügbarkeit beispielsweise mit der Durchführung eines Wiederherstellungstests der Datensicherung geprüft.

5.9. Qualitätsmanagement

In den meisten Unternehmen wird Qualitätsmanagement bei IT-Projekten nicht oder nur nebensächlich betrieben wie die Studien der Standish Group regelmäßig belegen.51 Als Grund dafür wird zumeist der hohe Aufwand für Qualitätsmaßnahmen und die geringe Akzeptanz der Mitarbeiter genannt.52 Gleichzeitig ist es kaum möglich, die Kosten (Verluste) durch mangelnde Qualität zu messen ohne vorher in Qualitätsmanagement zu investieren.53 Die Voraussetzung für erfolgreiches Qualitätsmanagement ist demnach volles Management Commitment. Da Qualitätsmanagement in der Literatur bereits umfassend behandelt wurde wird im Rahmen dieser Arbeit nur punktuell auf für Klein- und Kleinstunternehmen kritische Punkte eingegangen.

Qualität bedeutet in der IT zumeist die Erfüllung der vom Auftraggeber zuvor definierten Anforderungen.54 Basis dafür ist, die Anforderungen vollständig auszuformulieren und zu verstehen. Hinzu kommt, dass auch die nicht explizit geäußerten Wünsche erfüllt werden müssen, um in den Augen des Auftraggebers Qualität zu liefern. Diese betreffen meist branchenübliche und anwendungsspezifische Standards sowie gesetzliche Vorschriften. Qualität kann demnach nur erzielt werden, wenn alle expliziten und impliziten Erfordernisse und Erwartungen verstanden und erfüllt werden. Zur erfolgreichen Entwicklung von IT-Projekten gibt es hierzu zwei Ansätze:55

  • Die sequenzielle Entwicklung, zum Beispiel nach dem Wasserfall- oder dem V-Modell.
  • Die iterative Entwicklung, etwa nach RUP (Rational Unified Process) oder - bei Software-Entwicklungsprojekten - Agile Programmierung nach Scrum.

Die sequenzielle Entwicklung legt das Hauptaugenmerk darauf, die Anforderungen möglichst früh exakt zu spezifizieren. Dadurch sinkt das Risiko technischer Fehler - also das Risiko, das Produkt falsch zu entwickeln. Durch den Auftraggeber falsch definierte oder den Auftragnehmer nicht verstandene Anforderungen steigt im Gegenzug jedoch das Risiko fachlicher Fehler, also das falsche Produkt zu entwickeln.56

Der iterative Ansatz basiert auf der Umsetzung der bekannten Anforderungen in kurzen Zyklen und anschließendem Feedback. Durch die raschen Feedbackzyklen ist der Auftraggeber in der Lage, seine Anforderungen in allen Projektphasen mit geringem Aufwand genauer zu definieren. Da zu Beginn des Projektes viele Anforderungen noch nicht definiert sind trägt die iterative Entwicklung ein höheres Risiko durch frühe, falsche Designentscheidungen das Produkt falsch zu entwickeln.57

Abbildung 16 stellt die unterschiedlichen Abläufe der sequenziellen und iterativen Entwicklung schematisch gegenüber:

Abbildung 16: Sequenzielle Entwicklung versus Iterative Entwicklung Abbildung 16: Sequenzielle Entwicklung versus Iterative Entwicklung.58

Die Frage, welcher Ansatz für die Entwicklung von IT-Projekten in kleinen Organisationen zu bevorzugen ist, lässt sich nicht definitiv beantworten. Es kommt viel mehr auf die Rahmenbedingungen des Projektes an. Der iterative Ansatz hilft jedoch, bei kleinen, überschaubaren Projekten den Dokumentations- und Verwaltungsaufwand zu reduzieren und kann diese Projekte beschleunigen ohne die Risiken zu erhöhen. Insbesondere bei den im Rahmen dieser Arbeit im Fokus liegenden internen, zur Umsetzung der IT-Strategie abgewickelten Projekten hilft der iterative Ansatz zudem, die Lücke zwischen Theorie und Praxis zu schließen.59

5.10. Wissensmanagement

Unter dem Begriff “Wissensmanagement” werden alle Tätigkeiten eines Unternehmens im Umgang mit Wissen zusammengefasst. Es wurde in den letzten Jahren zu einem wichtigen Thema in vielen Unternehmen, da zunehmend erkannt wurde, dass ein Großteil des Unternehmenswertes von der Fähigkeit abhängt, Wissen zu erzeugen und zu verwalten.60 Es ist insbesondere in kleinen Organisationen essenziell, das vorhandene Wissen auf mehrere Personen zu verteilen, um es bei einem kurzfristigen Ausfall oder dem Weggang eines Mitarbeiters nicht zu verlieren. Grundsätzlich wird zwischen explizitem und implizitem Wissen unterschieden. Als explizites Wissen wird formal dokumentiertes Wissen bezeichnet, während implizites Wissen nur in den Köpfen der Mitarbeiter vorhanden ist. Das erste Ziel des Wissens-managements ist es, das implizite Wissen der Mitarbeiter zu dokumentieren und somit zu explizitem Wissen zu transformieren. Weiterführend soll das Wissen der einzelnen Mitarbeiter in kooperativen Prozessen auf Organisationsebene mobilisiert und verdichtet werden, um etwa durch Kombination von Wissensträgern Lösungen für komplexe Probleme zu erarbeiten. In diesem Prozess soll nicht nur das Wissen der eigenen Mitarbeiter, sondern auch jenes der Kunden, Lieferanten und Dienstleister mit einfließen.

Der Erfolg von Wissensmanagement ist stark von der Akzeptanz durch die Mitarbeiter abhängig. Die immer noch gebräuchliche “Wissen ist Macht”-Einstellung verhindert die Weitergabe von Wissen an Kollegen. Zusätzlich sind die Wissensmanagement-aktivitäten für den Einzelnen oft aufwändig und der Nutzen nur schwer messbar.61

Die IT-Unterstützung in dieser Phase reicht von Textverarbeitungs- und Präsentationssoftware bis hin zu Audio- und Videobearbeitung. Die generierten Dokumente sollten anschließend in eine Wissensdatenbank eingepflegt werden.

Wissensmanagement ist eine nicht nur auf die IT bezogene Unternehmensdisziplin, welche sich sehr gut durch IT unterstützen lässt. Die technischen Hilfsmittel reichen von Textverarbeitungs- und Präsentationssoftware über Audio- und Videobearbeitung bis hin zu Schulungs- und Wissensdatenbanken. Erfolgreiches Wissensmanagement basiert jedoch hauptsächlich auf den richtigen organisatorischen Abläufen:

Effektives Wissensmanagement bedeutet 80% Unterstützung durch Management und Organisation und 20% Technik.62

Ein Unternehmen kann sein Wissensmanagement daher nicht an einen Dienstleister auslagern, es muss den Grundstein dafür selbst legen. Ein Dienstleister kann jedoch bei der Umsetzung beratend tätig werden und die Bereitstellung und Wartung der nötigen Werkzeuge übernehmen. Zusätzlich können und sollen Dienstleister Inhalte für Wissensmanagement, etwa Dokumentationen, Handbücher und Anleitungen zu den von ihnen betreuten IT-Systemen, liefern.


Footnotes

  1. Vgl. (Groll, 2011, S. 384), (Resch, Brenner, & Schulz, 2009, S. 169f).

  2. Vgl. (Mödritscher, Rausch, & Mussnig, 2007, S. 439f), (Resch, Brenner, & Schulz, 2009, S. 173).

  3. Vgl. (Groll, 2011, S. 384).

  4. Quelle: (Groll, 2011, S. 384) (leicht modifiziert).

  5. Vgl. (Resch, Brenner, & Schulz, 2009, S. 172).

  6. Vgl. (Groll, 2011, S. 385).

  7. Vgl. (Groll, 2011, S. 384).

  8. Vgl. (Schmid, Management von Anwendungssystemen, 2007, S. 175).

  9. Microsoft Excel wird in kleinen Betrieben sehr oft als Allzweckwerkzeug in allen Unternehmensbereichen eingesetzt.

  10. Vgl. (Tiemeyer, Enterprise Architecture Management: IT-Architekturen erfolgreich planen und steuern, 2011, S. 102), (Rüter & Schröder, 2006, S. 108).

  11. Vgl. (Tiemeyer, Enterprise Architecture Management: IT-Architekturen erfolgreich planen und steuern, 2011, S. 128).

  12. Vgl. (Schmid, Management von Anwendungssystemen, 2007, S. 175 und 178f).

  13. Die Matrix stellt die Zuordnung in einem fiktiven Unternehmen dar und dient dem allgemeinen Verständnis.

  14. Quelle: Autor.

  15. Vgl. (Capgemini, 2012, S. 33).

  16. Vgl. (Resch, Brenner, & Schulz, 2009, S. 213).

  17. Vgl. (The Mozilla Foundation, 2013, o. S.).

  18. Vgl. (Schmid, Management von Anwendungssystemen, 2007, S. 204, 217f und 223), (Rüter & Schröder, 2006, S. 213).

  19. Vgl. (Groll, 2011, S. 384), (Schmid, Management von Anwendungssystemen, 2007, S. 212ff).

  20. Quelle: Autor.

  21. Vgl. (Schmid, Management von Anwendungssystemen, 2007, S. 207).

  22. Vgl. (Tiemeyer, Enterprise Architecture Management: IT-Architekturen erfolgreich planen und steuern, 2011, S. 86).

  23. Vgl. (Resch, Brenner, & Schulz, 2009, S. 131).

  24. Vgl. (Schmid, Management von Anwendungssystemen, 2007, S. 207).

  25. Vgl. (Walter, 2005, S. 274f).

  26. Vgl. (Ward & Peppard, 2005, S. 51), (Wintersteiger & Tiemeyer, 2011, S. 65).

  27. Vgl. (Arenz, 2003, S. 117), (Resch, Brenner, & Schulz, 2009, S. 213f).

  28. Vgl. (Arenz, 2003, S. 124).

  29. Vgl. (Resch, Brenner, & Schulz, 2009, S. 222), (Arenz, 2003, S. 127).

  30. Vgl. (Walter, 2005, S. 163).

  31. Vgl. (Walter, 2005, S. 284).

  32. Vgl. (Walter, 2005, S. 278).

  33. Vgl. (Königs, 2006, S. 1 und 30f), (Bergmann & Tiemeyer, 2011, S. 485f), (Schmid K. , 2011, S. 547).

  34. In der Literatur auch „Risikomatrix“ genannt. Vgl. (Königs, 2006, S. 168f), (Ketterer, 2009, S. 9), (Schmid K. , 2011, S. 562ff).

  35. Quelle: in Anlehnung an (Ketterer, 2009, S. 9).

  36. Quelle: Autor.

  37. Vgl. (Schmid K. , 2011, S. 573ff).

  38. Quelle: in Anlehnung an (Ketterer, 2009, S. 10).

  39. Vgl. (WKO, 2010, o. S.).

  40. Vgl. (Wintersteiger & Tiemeyer, 2011, S. 67).

  41. (Tiemeyer, Enterprise Architecture Management: IT-Architekturen erfolgreich planen und steuern, 2011, S. 104).

  42. Vgl. (Walchshofer, 2010, S. 28), (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, S. 135ff).

  43. Vgl. (Schmid K. , IT-Security-Management, 2011, S. 531f).

  44. Quelle: in Anlehnung an (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, S. 136).

  45. Vgl. (Bundeskanzleramt der Republik Österreich, 2010).

  46. Quelle: in Anlehnung an (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, S. 137).

  47. Quelle: in Anlehnung an (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, S. 545).

  48. Vgl. (Schmid K. , IT-Security-Management, 2011, S. 533), (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, S. 38, 47f und 60).

  49. Quelle: Autor.

  50. Vgl. (Schmid K. , IT-Security-Management, 2011, S. 542f).

  51. Vgl. (The Standish Group International, Inc., 2012), (Nehfort, 2011, S. 403).

  52. Vgl. (Nehfort, 2011, S. 405).

  53. Vgl. (Nehfort, 2011, S. 406).

  54. Vgl. (Walter, 2005, S. 190f).

  55. Vgl. (Nehfort, 2011, S. 413ff).

  56. Vgl. (Nehfort, 2011, S. 414).

  57. Vgl. (Nehfort, 2011, S. 417f).

  58. Quelle: (Bittner, 2006, o. S.).

  59. Vgl. (Nehfort, 2011, S. 420).

  60. Vgl. (Laudon, Laudon, & Schoder, 2010, S. 661).

  61. Vgl. (Laudon, Laudon, & Schoder, 2010, S. 667).

  62. (Laudon, Laudon, & Schoder, 2010, S. 671).