Basic HTML-Version
CM
Controller
magazin 6/04 - Mark Wahl
TCO-Analysen (Total Cost of Ownership)
von Gärtner und der Metagroup emp–
fiehlt es sich, hier auf die Zuordnung indi–
rekter Kosten zu verzichten und nur die
direkt zurechenbaren Kosten aufzustel–
len. Dies erhöht die spätere Vergleichbar–
keit und ist im Übrigen auch viel billiger^"
Dabei bietet sich an, dieses Projektcon–
trolling über die gesamten Lebenszyklus–
phasen bzw. Projektphasen hinweg durch–
zuführen. So hat man im Prinzip bereits
alles getan, was zur Ermittlung einer TCO
notwendig ist. Ob man das nunTCO,Life-
Cycle-Costing oder Projektcontrolling
nennt, ist im Endeffekt egal; wichtig ist
nur, dass man die Kosten über alle Pro–
jektphasen hinweg ermittelt.
Nachdem das ITProjekt beendet ist, geht
das zu erstellende Vorhaben, also das,
worum es im IT-Projekt ging, in die beste–
hende IT-lnfrastruktur über In der Regel
werden ja im ITProjekt Anwendungen
erstellt oder Plattformen migriert; d. h.
das, was am Ende herauskommt, geht in
die bestehende Infrastruktur über, ersetzt
evtl. Bestehendes, aber muss in die be–
stehende IT-Architektur integriertwerden.
Ab diesem Zeitpunkt macht es Sinn, die
Zahlen des ITProjektcontrolling in das IT
Architekturcontrolling überzuleiten.
IT-Architektur-Controlling
Ist ein ITProjekt erfolgreich abgeschlos–
sen worden, vedagert sich das Augen–
merk darauf, den laufenden Betrieb zu
optimieren. Hier geht es darum, Transpa–
renz in den Kostenblock der IT-Architek–
tur zu bringen. Dies ist eine Aufgabe, die
häufig gescheut wird, obwohl gerade die
Kostenanalyse die Ausgangsbasis weite–
rer Überiegungen darstellt.
Wer nicht weiß, welche Kosten von wel–
cher ITPlattform verursacht werden, kann
keine fundierten weiterreichenden Ent–
scheidungen treffen. Existieren günstige–
re IT-Plattformen, die dieselben Leistun–
gen erbringen? Sind externe IT-Dienstlei–
ster günstiger, als das eigene Betreiben
dieser ITPlattform? Welche Kosten sollen
dem Fachbereich für diese und jene FT
Leistung in Rechnung gestellt werden? All
diese Fragen lassen sich erst dann eindeu–
tig beantworten, wenn ein ausreichender
Grad an Kostentransparenz bzgl. der IT
Architektur hergestellt wurde. Aber wieso
gestaltet sich diese Aufgabe so schwierig?
Die IT-Abteilungen waren es in der Ver–
gangenheit häufig gewohnt, auf plötz–
lich anfallende Probleme aus den Fach–
bereichen mit schnell umsetzbaren IT
Lösungen zu reagieren. In der Vergan–
genheit ging es primär darum, dass die
zu findende Lösung ad hoc und unkom–
pliziert ein bestehendes Problem der End–
anwender bzw. des Fachbereichs löst.
Wie viel das kostet und ob das jemand
anderes billiger machen kann, war zweit–
rangig. Da der Endanwender bzw. der
Fachbereich die Kosten der Implementie–
rung der einzelnen Lösungen nicht be–
zahlen musste - eine innerbetriebliche
Kosten- und Leistungsverrechnung ist in
den meisten mittelständischen Unterneh–
men bis heute noch nicht realisiert - hat
sich niemand dafür interessiert, ob die
neue Lösung in die bestehende ITArchi–
tektur passt und ob das kostenoptimal
ist." Das Ergebnis waren IT-Architektu–
ren, die heterogen und diffus gewachsen
sind und ohne eine klare Aufstellung der
verursachenden Kosten.
Nun sind die Zeiten der großen Budgets
vorbei und plötzlich will jeder wissen,
wie effizient und effektiv die IT-Abteilung
arbeitet. Plötzlich werden Fragen nach
Kosten- und Nutzendimensionen gestellt
und die IT-Abteilung wird zur Rechen–
s cha f t aufgeforder t . Nun sol len
Machbarkeitsstudien und betriebswirt–
schaftliche Kosten- und Nutzenanalysen
von Menschen erstellt werden, die bis
dto damit zu kämpfen hatten, dass ihre
Systeme laufen und wenig Abstürze ver–
ursacht werden. Dabei wird häufig ver–
gessen, mit welchen Menschen man es
in IT-Abteilungen zu tun hat. Hier sind
Technikbegeisterte anzutreffen, die dar–
an Freude haben, Probleme auf techni–
schem Weg zu lösen; die ein Erfolgserieb-
nis haben, wenn nach tagelangem Pro–
bieren und Tüfteln endlich der Fehler im
Programm oder an der Hardware gefun–
den wurde.
Die IT-Abteilungen müssen heute - ge–
nau wie jede andere Abteilung imUnter–
nehmen - lernen, unternehmerisch zu
denken; d. h. sich kostenbewusst zu ver–
halten, moderne Methoden des Con–
trolling einzusetzen und sich damit auch
nach oben abzusichern. Doch man darf
sie damit nicht alleine lassen. Der Fach–
bereich muss ebenso lernen, dass er nicht
einfach die optimalste Lösung veriangen
kann, ohne sich an den Kosten zu beteili–
gen. Dabei sitzt die IT-Abteilung häufig in
der Klemme. Sie muss sich gegenüber
dem Fachgereich wettbewerbsfähig zei–
gen. Kann sie nicht eine Lösung bieten.
die ein besseres oder zumindest gleich
gutes Preis-/Leistungsverhältnis auf–
weist, wie Angebote externer Firmen,
dann droht ihr zunehmend der Vertust
interner Aufträge. Stets schwebt das Da–
moklesschwert des Outsourcing über ihr
Sie muss also nachweisen, dass siemit
externen Angeboten konkurrieren kann.
Das kann sie aber nur, wenn sie nachwei–
sen kann, was ihre internen Angebote
kosten und welche Leistungen damit ver–
bunden sind. Hier kommt nun das IT-
Controlling zum Einsatz. Bevor Leistun–
gen definiert und Kosten aufgestellt wer–
den, muss zuerst darüber nachgedacht
werden, aufweiche Weise dies am besten
geschehen kann. Die interne IT-Abteilung
ist hier am besten beraten, wenn sie die
Flucht nach vorne antritt. D. h. nicht den
Kopf in den Sand steckt, sondern ihre
Transparenz und Vergleichbarkeit mit
externen Dritten erhöht. Unter dieser
Prämisse bietet sich an, die internen Ko–
sten so aufzustellen und zu ermitteln,
damit sie mit den Angeboten externer
Firmen am leichtesten vergleichbar sind.
Fußnoten
' Helmut Krcmar: Informationsmanagement und
Controlling - Siamesische Zwillinge oder feindli–
che Brüder, August 1988. In: Rechnungswesen
und EDV, Hrsg.: A.-W. Scheer, Physica: Heidel–
berg, 1988, S. 269-291.
^ Computerwoche Nr. 14 vom 04.04.2003, Bei–
trag: „Die ITmuss das Rechnen lernen"
ä vgl. Spitta, Thorsten / Schmidpeter, Helmut
(2002): IVControlling in einem Systemhaus -
Eine Fallstudie, in Wirtschaftsinformatik 44
(2002)2, S. 141-150, S. 1 41.
" Vgl. Wirtschaftsinformatik Heft 03/2004, elek–
t ronisch
veröf fent l icht :
php?sid = 1202
= Vgl. Küpper, H.-U. (1997): Controlling, 2. Aufl.,
Schäffer-Poeschel, Stuttgart.
' Vgl. Schöne, K. (1997): Control l ing der
Informationsinfrastruktur - Entwicklungsstand,
Gestaltungskonzeption und Perspektiven, Gab–
ler (DUV), Wiesbaden.
' Vgl. Spitta, T. (1998): IVControlling in mittelstän–
dischen Industrieunternehmen - Ergebnisse ei–
ner empirischen Studie, Wirtschaftsinformatik
40(1998), H.5, S. 424-433.
" Vgl. Standish Group (1994): The Chaos Report,
elektronisch
veröf fent l icht ,
chaos_1994_3.php
' Vgl. Krcmar et al. (2000): IVControlling auf dem
Prüfstand, Gabler (Wiesbaden).
Vgl. Computerwoche vom 4.4.2002: TCO: Mon–
ster oder Sparschwein?, elektronisch veröffent–
l icht :
index.cfm?pageid = 254&artid = 34585&type =
detail&kw = tco %20monster
' ' Vgl. Spitta, T. (1998): IV-Controlling in mittelstän–
dischen Industrieuntrnehmen - Ergebnisse ei–
ner empirischen Studie, Wirtschaftsinformatik
40(1998), H.5, S. 424-433.
•
518