Strategisches IT-Management

Im IT-Management gibt es eine Vielzahl von strategischen Aufgaben (vgl. Boynton et al., 1994). Laut Resch (n. d.) sind „Strategische IT-Management-Aufgaben … von grundsätzlicher Natur und bestimmen die Nutzung der IT für und durch die Organisation als Ganzes.“ Im Folgenden sollen nun zwei dieser Aufgaben erläutert werden. Nämlich einerseits die Entwicklung einer IS Strategie und zudem der Aufbau der IS Architektur.

IS Strategie-Konzepte

Nach Chen et al. (2010) können drei verschieden Konzepte aufgezeigt werden (S. 233). Diese werden nun im Detail betrachtet.

Das erste Konzept bezeichnet die „IS Strategy as the Use of IS to Support Business Strategy“ (Chen et al., 2010, S. 238). Voraussetzung für dieses Konzept ist eine bestehende Unternehmensstrategie, an die die geplante IS Strategie angepasst werden kann. Wählt ein Unternehmen zum Beispiel eine Kostenführerschaft-Strategie, so wird die IS Strategie so festgelegt, dass sie dem Unternehmen hilft Kosten zu sparen. Zum Beispiel durch eine Automatisierung von Prozessen. Aufgrund der extremen Ausrichtung am Geschäft und den Geschäftsprozessen wird dieses Konzept als „business centric“ (Chen et al., 2010, S. 240) bezeichnet. Die IS Strategie wird dabei nicht als eine eigene Strategie bezeichnet, sondern stellt einen wesentlichen Teil der Business Strategie dar. Durch die enge Verbundenheit von IS und Business Strategie wird das Alignment ohne weiteres zu tun automatisch erreicht und findet somit a priori statt. Dieses Konzept eignet sich logischerweise allerdings nur für Unternehmen, die eine klare Business Strategie entwickelt haben (vgl. Chen et al., 2010, S. 238 ff.).

Als nächstes Konzept wird das „IS Strategy as the Master Plan oft he IS Function“ (Chen et al., 2010, S. 240) beschrieben. Dieses steht in einem großen Gegensatz zum Ersten, denn dieses Konzept konzentriert sich darauf, die IS function so effizient und effektiv wie möglich zu gestalten. Auch wenn es das Ziel der IS function ist die Performance des Unternehmens zu steigern, konzentriert sich in diesem Fall alles darauf diese Funktion möglichst optimal zu gestalten. Damit dies gelingt werden einerseits sämtliche benötigten IS Güter und IS Werte bestimmt. Beispiele hierfür sind das IT Personal, das benötigte Budget und die benötigte Technologie, die die Infrastruktur beinhaltet. Als nächstes werden diese bestmöglich auf die bereits bestehenden IS Güter aufgeteilt und effizient eingesetzt. Aufgrund der extremen Ausrichtung auf die IT, wird dieses Konzept von Chen et al. (2010) als „IS-centric“ (S. 240) gesehen. Außerdem ist in diesem Fall die IS Strategie völlig losgelöst von der Unternehmensstrategie und kann ohne sie existieren. Dies bietet den Vorteil, dass Firmen ohne Unternehmensstrategie dieses Konzept nutzen können. Es handelt sich hierbei auch um eine funktionale Strategie, da darauf abgezielt wird eine Funktion durch optimales Ressourcenmanagement zu maximieren. Dieses Konzept verfügt allerdings über den Nachteil, dass durch fehlende Unternehmensausrichtung möglicherweise ein Alignment verhindert wird und die IS die Unternehmensperformance sogar verschlechtert. Das angestrebte Alignment muss also ex post erreicht werden und ist nicht automatisch gegeben (vgl. Chen et al., 2010, S. 240 f.).

Das letzte Konzept stellt eine Art Brücke zwischen den zwei zuvor gezeigten dar und wird deshalb als „IS Strategy as the Shared View oft he IS Role Within the Organization“ (Chen et al., 2010, S. 241) bezeichnet. Es geht darum zu klären welche Investitionen in die IT getätigt werden sollen und stellt daher einen dynamischen Prozess dar, der sich nicht an feste Strukturen hält. Besonderheit dieses Konzeptes ist es, dass hierbei vor allem die Perspektive des Top-Managements, welche Rolle die IS im Unternehmen spielen soll, betrachtet wird. Darin liegt auch das Problem, da mögliche auf weiter unten liegenden Ebenen nicht betrachtet werden. Da bei diesem Konzept das gesamte Unternehmen betrachtet wird, wird es als „Organization-centric“ (Chen et al., 2010, S. 241) bezeichnet. Die jeweilige IS Strategie kann zwar als alleinstehend betrachtet werden, jedoch wird sie gleichzeitig mit der Unternehmensstrategie definiert. Daher erfolgt auch der Prozess des Alignment auf einem dynamischen Wege (vgl. Chen et al,. 2010, S. 241 f.).

IS Architektur

„The two criteria of greatest importance in choosing IS architecture are overall and simultaneous efficiency and flexibility.“ (Allen & Boynton, 1991, S. 435). Auf die Frage, wie diese beiden Kiterien erfüllt werden können, geben Allen & Boynton zwei Lösungen vor, die nun aufgezeigt werden.

Das erste Szenario wird als „The Low Road“ (Allen & Boynton, 1991, S. 436) bezeichnet. Bei diesem Szenario handelt es sich um eine vollkommene Dezentralisierung der IS Technologien. Dies bedeutet, dass sämtliche IS und IT Angelegenheiten so tief wie möglich auf jede Ebene des Unternehmens verteilt werden und jede Abteilung selbstständig für ihre Informationssysteme zuständig ist. Damit diese Dezentralisierung funktionieren kann müssen bestimmte Bedingungen, wie miteinander verbundene Kommunikationssysteme, vollständiger Informationszugriff und Bedingungen bezüglich des Datenaustausches erfüllt sein. Damit jeder Abteilungsleiter auf die benötigten Daten zugreifen kann, zielt die Low Road darauf ab, dass im gesamten Unternehmen jeder auf alle Daten zugreifen kann. Dieses System basiert vor allem auf Vertrauen, da hierbei die Gefahr besteht, dass vertrauliche Daten in Hände gelangen, die diese nicht besitzen sollten. Außerdem besteht die Frage, ob wirklich sämtliche Daten für jedermann einsehbar sein sollten. Jedoch besteht der Vorteil darin, dass extrem schnell auf die benötigten Daten zugegriffen werden kann. Nichts desto trotz müssen gewisse Standards beim Datenaustausch festgelegt werden, wie etwa Datenformate oder einheitliche Telefonkommunikation. Diese Aufgabe übernimmt dann im Regelfall eine zentrale IS Organisation. Der Low Road Ansatz geht allerdings davon aus, dass sämtliche Standards hinderlich für die Weiterentwicklung sind und will diese in möglichst geringem Maße halten. Die Vorteile dieses Szenario bestehen darin, dass eine hohe Effektivität erreicht werden kann, da jede Abteilung, die für sie beste Lösung implementieren kann. Außerdem wird eine hohe Effizienz unterstellt, da diese Lösung möglicherweise sehr kostengünstig sein kann. Außerdem verspricht es ein hohes Maß an Innovation, da jeder Abteilungsleiter für sich entscheiden kann welche Technologie eingesetzt wird, ohne Rücksprache halten zu müssen. Dennoch stellen sich auch einige Probleme dar, wie etwa eine fehlende Integrität, wenn jeder seine eigenen Systeme verwendet. Zudem ist es nur mit großem Aufwand möglich den Datenaustausch zu synchronisieren. Zudem besteht die Gefahr, dass Teile des Unternehmens in einen technologischen Rückstand fallen, ohne dies zu bemerken (vgl. Allen & Boynton, 1991, S. 436 ff.).

Die zweite Möglichkeit zur Gestaltung der Architektur wird als „The High Road“ (Allen & Boynton, 1991, S. 440) bezeichnet und steht in völligem Kontrast zu Low Road. Hierbei ist die Rolle des Senior IS Executive ausgeweitet und es gibt eine zentrale IS Organisation. Sämtliche Aktivitäten werden von dieser gesteuert und im gesamten Unternehmen gibt es standardisierte Hardware, Applikationen und Datenerfassungssysteme. Die Vorteile dieses Konzeptes liegen auf der Hand. Einerseits ist es möglich das gesamte System relativ schnell zu erneuern, falls dies nötig ist, da die Entscheidungen at the top getroffen werden und so eine schnelle Entscheidungsfindung möglich ist. Andererseits herrscht bei dieser Lösung vollkommene Integrität und alle Systeme sind kompatibel, da ein hohes Maß an Standardisierung vorherrscht. Zudem bietet dieses Konzept eine hohe Effizienz, da kaum Datenredundanz und ein einheitlicher Datenspeicher vorliegen. Einheitliche Systeme führen auch zu geringeren Wartungskosten.
Aufgrund der Zentralisierung und der „Herrschaft“ des Senior Executives wird dieses Konzept meist strategisch eingesetzt und über eine lange Zeit hinweg geplant. Dennoch besitzt auch die High Road ihre Schwächen. So kann es passieren, dass es zu einer Kostenexplosion kommt, falls die Standardisierung nicht klappt. Durch standardisierte Applikationen kann es außerdem passieren, dass benötigte Funktionen nicht vorhanden sind und auf niedrigeren Ebenen nicht auf die Anforderungen der Abteilungen abgestimmt sind. Zudem steht und fällt die gesamte Architektur mit dem Wissen und Können des Top-Managements. Wird dort eine falsche Entscheidung getroffen, kann dies da ganze Unternehmen betreffen, da die gesamte Architektur zentralisiert ist (vgl. Allen & Boynton, 1991, S. 440 ff.).