Martin Schölkmann Student der Wirtschaftswissenschaften, Lüneburg
Offenkundige Diskrepanzen zwischen Zielvorstellung (Nutzen) und tatsächlichen
Auswirkungen der Zielverfolgung (Kosten) zu erkennen, scheint mitunter eine zu große Anforderung darzustellen, Zwar muß unter den DV-Verantwortlichen unserer Tage niemand mehr eine solche Fehleinschätzung mit dem Leben bezahlen, aber der Schleudersitz kann den Betroffenen unter Umständen schon recht weit zurückwerfen, Da sitzt er dann und fragt sich, wie das Drama seinen Lauf nehmen konnte. Auf einmal waren die DV-Kosten ins Laufen geraten, dem Unternehmen bis an den Hals gestiegen, die Investition führte sich selbst ad absurdum.
Die Art der Fehlkalkulation ist klassisch, für DB-Planungen aber leider fast typisch. Towner vergleicht die Kosten eines Datenbank-Systems plastisch mit dem berühmten Eisberg, von dem man ja bekanntlich zunächst nur die Spitze (=DB-Paket-Kosten) sieht. dessen größerer Teil sich aber unter der Wasseroberfläche befindet und daher in den meisten Fällen erst dann ungefähr erkannt wird, wenn es bereits zu spät ist. Vorbeugen ist besser als klagen, präziseste Planung wird darum zum Muß. Daß es dabei weder mit System-Evaluationen noch mit Cost/ Benefit-Analysen allein getan ist sollte selbstverständlich seine ist es aber nicht. Es stellt sich daher zwangsläufig die Frage nach dem Planungshorizont.
Der Entscheidungsablauf bei der Auswahl eines DB-Systems ist ein Wechselspiel. Fachlich muß der DV-Leiter die Verantwortung gegenüber dem Finanzvorstand übernehmen, sich also jeweils die Zustimmung sichern, Von finanzieller Verantwortung ist er zunächst befreit. Fest steht zu diesem Zeitpunkt meist nur der Entschluß, ein DB-System zu implementieren. Der DV-Leiter hat es verstanden, das absolute Muß zu verdeutlichen und vorab eine positive Grundeinstellung bei den finanziell Verantwortlichen zu erzeugen. Planung in dieser eher noch undifferenzierten Phase kann nur die Ausschaltung von Prestige-Überlegungen sein. Nun wird jeder Betroffene derlei Gedanken entrostet von sich weisen, doch sollte man berücksichtigen, daß die Vorstellung von einer Korrelation zwischen Ansehen und Budget noch weit verbreitet ist.
Was nach dieser Selbstprüfung folgt, ist die gezielte Auswahl eines Paketes. Man beschreitet also den Weg vom Allgemeinen ins Detail. Es müssen konkrete Vorstellungen über das zu lösende Problem und die Anforderungen an das System entwickelt werden. Diese gilt es zu formulieren und mit den Angeboten zu vergleichen.
Die eigentliche Planungsarbeit besteht zunächst in der Evaluation verschiedener Systeme. Es ist zu prüfen
- ob und welche der gestellten Anforderungen erfüllt werden;
-mit welchem Aufwand das geschieht.
Die erste Frage meint eine Untersuchung des Komforts und des Leistungsangebots der Systeme. Was bietet der Hersteller, was kann man davon gebrauchen? Vorsicht ist geboten, denn meist erweist sich später, daß zum effektiven Einsatz zusätzliche Komponenten benötigt werden, die in der Planungsphase nicht mit einkalkuliert wurden, das Produkt im Cost/Benefit-Vergleich günstiger dastehen ließen und folglich vom Verkäufer natürlich auch nicht erwähnt wurden. Hardselling ist Trumpf. Das von einigen Anbietern betriebene Unbundling stellt den Anwender vor die unabdingliche Aufgabe, die Angebote bis ins i-Tüpfelchen zu untersuchen, sich gegebenenfalls schriftliche Zusicherungen auszubedingen, wo eine weite rechtliche Auslegung möglich erscheint. Weist der Anbieter die Nachfrage nach einer bestimmten Komponente mit dem Hinweis ab, diese werde im Anfangsstadium ja noch nicht benötigt, sei "in der Entwicklung" und somit rechtzeitig verfügbar, so sollte man hellhörig werden. Auch vom Ausweichen auf zusätzlichen Fremd-Software-Support kann nur abgeraten werden. Komplette Support-Software aus einer Hand ist ein Prinzip, an dem kein Weg vorbeiführt.
Wie sieht nun die "Grundausstattung" eines solchen DB-Systems aus? Neben der eigentlichen DBMS-Software gehören dazu sicher
- Übersetzer (DB-Schema, Anwendungsprogrammierung, physische Speicherstrukturierung)
- Utilities (Initialisierung, Datensicherung/Wiederanlauf, Reorganisation, Umstrukturierung, zentraler Datenschütz, Multithread)
Daneben meist unabdingbar zum effektiven Betrieb - darüber sollte man sich klar werden - sind, Umstellungssoftware, Data Dictionary, Report Writer, TP-Monitor, Text-Editor und Online-Query-Paket.
Geht man davon aus, daß in Zukunft die Entwicklung der Kommunikation zwischen dezentral angelegten Datenbanken weiter an Bedeutung gewinnen wird, so sollte auch das Vorhandensein einer kompatiblen Schnittstelle erfragt werden. All diese "Päckchen" lassen die ursprünglichen Kosten der DB-Software gut und gerne um den Faktor 2 ansteigen, je nachdem, was man zu brauchen glaubt oder was einem eingeredet wird. Vor bösen Überraschungen ist man dabei nie sicher.
Darüber darf nicht vergessen werden, daß mit der Implementierung auch nicht unerhebliche Hardware-Erweiterungen verbunden sein können. Dabei sollte man wie beim Metzger vorgehen: Es darf ruhig etwas mehr sein, will man nicht ständig den Kapazitätsabgrund vor Augen haben.
Wurde nun unter Berücksichtigung aller Einstiegs-Eventualitäten, also auch des Umstellungsaufwandes und des vom Anbieter offerierten, Supports bei der Implementierung, eine Entscheidung zugunsten eines Systems getroffen, so brauchen , die, Planungen dennoch, wie sich zeigen wird, nicht vollständig gewesen zu sein. Ein besonderer Aspekt kommt nämlich meist zu kurz, und das ist die Personalfrage.
Der Anwender steht plötzlich vor dem Problem des Einbeinigen, dem ein gewiefter Vertreter Rollschuhe verkauft hatte. Um das teure System kostenadäquat nutzen zu können, muß er seine DV-Crew "hochbilden" oder aufstocken. Beides ist mit erheblichen Kosten verbunden. Das Training selbst wird da permanent zur teuren Angelegenheit, sofern es nicht kostenerhöhender Bestandteil des DB-Paketes war. Doch meist ist es mit den üblichen Einführungslehrgängen getan, die bewirken, daß der Anwender "das Ding am Laufen halten kann". Soll jene später das Instrument Datenbank optimal eingesetzt werden, die Performance gesteigert werden, so reicht das vermittelte Wissen nie und, nimmer aus. Voraussetzung für das Erreichen des systemspezifischen Leistungsoptimums ist das gezielte System-Tuning, das das teure Wissen eines Spezialisten erforderlich macht.
Die Aufstockung der Mannschaft um einen hochdotierten DB-Administrator wird nötig, ist in der Regel aber sehr schwierig und kostenintensiv. Hier meldet sich zumessen mal der Personalchef mit einem erbosten "Das hätten Sie aber wissen müssen!". Zudem heißt Suchen nicht auch unbedingt Finden. Wer den Markt für DB-Spezialisten kennt, weiß wovon die Rede ist. Der großen Nachfrage steht ein weit geringeres Angebot gegenüber, der Fluktuation auf dem Sektor versucht man den Riegel eines hohen Salärs vorzuschieben. Wohl dem, der seinen Spezi hat! Eine an der Fachhochschule Nordost-Niedersachsen in Lüneburg unter Leitung von Prof. D. Grawe durchgeführte minutiöse Untersuchung von DV-Aibeitsmarkt-Anforderungen anhand der Auswertung von über, 11 000 Stellenausschreibungen verdeutlichte diesen Tatbestand, DB-Spezialisten gehörten zu den, meistumworbensten DV-Werkern. Da muß man dann unter, Umständen nehmen, was man kriegen kann, das heißt eine längere unproduktive, Einarbeitungsphase in Kauf nehmen oder aus der eigenen Mannschaft, einen geeigneten Mitarbeiter aussuchen und ausbilden, was eher noch teurer und langwieriger werden dürfte. Beide Alternativen ziehen auf jeden Fall erhebliche Folgekosten nach sich, die in der Phase der ursprünglichen Planung zu häufig übersehen und folglich nicht berücksichtigt werden. Dadurch schlagen erzielte Kosteneinsparungen aus der Implementierung (soweit überhaupt exakt quantifizierbar) schnell ins Negative um.
Allen eventuellen Einwürfen zum Trotz bin ich von der Notwendigkeit der zentralen DB-Administration fest überzeugt. Eine Datenbank ist wie jede DV-Umgebung ein dynamisches System, das mit der Entwicklung Schritt halten muß soll sich die einmal getätigte Investition auch auf lange Sicht rentieren. Der Analytiker aus der Anwendung ist mit dem Tuning der internen (physischen) Struktur überfordert, der Systemprogrammierer dürfte seine Probleme bei der Optimierung von Anwender-Programmen haben. Der Blick für beides, das Charakteristikum des DB-Administrators, ist jedoch Voraussetzung für rationelle Koordinierung, die Erweiterung der ursprünglichen DB-Planung um diese personelle Komponente also zwingend.