[sage] Warum ich keine Bandlaufwerke mag

[Benedikt Stockebrand]

Moin zum xten,

"Ralph J.Mayer" <rmayer at vinotech.de> writes:

> im Grunde ist es, wie immer, ein BWL-Problem:
> - Wie lange darf ein Service ausfallen?
> - Welche Kosten entstehen dabei?
>
> Die Fragen können und müssen Euch die mit den Schlipsen beantworten.

im Grunde ist es oft genug ein Fall von Kompetenzgerangel: Die Fragen
lassen sich so einfach oft nicht beantworten, das wollen die
entsprechenden Leute nicht zugeben -- und außerdem kann es nicht sein,
dass "Schlipse" Dir als kleinem Techniker zuarbeiten müssen.

Wobei alleine schon Deine Wortwahl ("Schlipse") vermuten lässt, dass
Du mit Umgebungen zu tun hast, in denen dieses Phänomen ein handfestes
Problem ist.

> [...]
> Das ergibt dann den endgültigen Plan. Als Admin lässt man sich das
> Alles schriftlich bestätigen, weißt schriftlich auf die
> Schwachstellen hin und ist damit erst Mal aus dem Schneider.

Das funktioniert nur in Umgebungen, in denen Schriftform bei solchen
Sachen etabliert ist.  Das gilt oft genug nicht bei kleinen oder
mittelständischen Unternehmen, in denen sich das Management (so es
sich da überhaupt so nennen lassen will) Entscheidungen über
Ausgaben nicht aus der Hand nehmen lässt.

> Wenn es kein Budget gibt, dann ist es eben so. Der mit dem Schlips
> wird entsprechend bezahlt um genau für diese Entscheidung den Kopf
> hin zuhalten.

Er hat aber möglicherweise auch gelernt, wie man sich bei solchen
Sachen aus der Affäre zieht -- in dysfunktionalen (typischerweise
größeren) Unternehmen ist das oft genug Voraussetzung, um im
Management Karriere machen zu können.

> Und wenn dann ein Konzept vorsieht, daß eine Sekretärin jeden Morgen
> ein Band wechselt, dann würde ich genau diesem Schlips, der den
> Wechsler aus Kostengründen verweigert hat, die Verantwortung aufs
> Auge drücken, daß auch die Krankheits/Urlaubsvertretung das Band
> wechselt.

Ich habe ein paar Umgebungen gesehen, in denen Du damit im Leben nicht
durchkommst.  Da ist das Backup Dein Problem, denn Du hast schließlich
das Konzept geschrieben und überhaupt, mit diesem Low-Level-Kram hat
das Management nichts zu tun.

Und die Argumentation ist grundsätzlich noch nicht einmal verkehrt,
denn Du bist derjenige, der von der Materie die notwendige Ahnung hat
und eine praktikable Lösung konzipieren sollte.

> In so ein Konzept kann man dann auch Dinge schreiben wie:
> - Aufbau Hardwaremonitoring, Aufwand 4 Tage
> - wöchentliche Begehung aller Serverräume, Aufwand jeweils 2h
> - Austausch Bänder einmal im Jahr, Aufwand ...

Das *ist* allerdings hilfreich -- auch weil man selbst ein Gespür
dafür bekommt, was wirtschaftlich sinnvoll ist.  Ich würde allerdings
zu eigenen Zwecken auch gleich noch mit entsprechenden Stundensätzen
die Kosten ausrechnen.

Dabei geht es mir nicht darum, dass die "Schlipse" die
Grundrechenarten nicht beherrschen, sondern dass man als Techniker
durchaus schonmal diese Zahlen aus den Augen verliert -- und im
Zweifelsfall auch den "Schlipsen" wenigstens einen gewissen Grad von
kaufmännischem Denken zeigt.

> Ja, so ein Konzept zu schreiben kostet Zeit. Aber es ist besser 
> investierte Zeit als irgendwas zu frickeln, die Verantwortung dafür zu 
> tragen und im Worst Case die A-Karte zu haben.

Es geht hier nicht um's "Frickeln", sondern um sinnvolle
Lösungsansätze.  Dass man manchmal sehen muss, wie man aus den am
Markt verfügbaren Lösungen die für die eigenen Zwecke sinnvollsten
auswählt und einrichtet, gehört zum Job.  Und bei denen muss man
normalerweise genau hinsehen und die zugrundeliegenden (und in den
Hochglanzbroschüren normalerweise nicht beschriebenen) Ansätze mit den
eigenen Anforderungen abgleichen.

Außerdem gibt es immer wieder Umgebungen, die so atypisch sind, dass
man mit Lösungen von der Stange nicht weiterkommt.  Leute mit wenig
Erfahrung neigen dazu, voreilig eigene Lösungen zu bauen, Leute mit
viel Erfahrung mit einem einzelnen Produkt oder Lösungsansatz
versuchen oft, damit nicht sauber lösbare Anforderungen irgendwie doch
zu erschlagen oder alternative Ansätze von vorneherein auszuschließen.
Die letzte Variante hatten wir in diesem Thread im Zusammenhang mit
USB-Sticks und Wechselplatten, und genau deshalb finde ich
Diskussionen wie diese hier so wertvoll.

Im Übrigen würde ich noch sehr genau zwischen einem technischen
Konzept und einer Entscheidungsvorlage für das Management
unterscheiden.  Beide richten sich an grundlegend andere Zielgruppen
mit unterschiedlichem Vorwissen, unterschiedlicher Sprache und
unterschiedlichen Zielsetzungen.  Wenn man beides zusammenpackt läuft
man nur Gefahr, dass einem das Management in technische Fragen
reinredet und man anschließend als Verfasser des Konzepts der
Schuldige ist, wenn's in die Hose geht.

> ITIL hat auch gute Seiten :)

Ja, aber es führt auch dazu, dass Leute Konzepte schreiben, mit denen
sie sich bestmöglich aus der Verantwortung ziehen, statt konstruktive
Lösungen zu bringen.

Sorry, ist wirklich nicht böse gemeint, aber ITIL, ISO9000 und wie sie
alle heißen führen oft genug zu solchen Entwicklungen, wenn man diesem
Phänomen nicht aktiv entgegenwirkt.  Deshalb haben sie bei manchen
Technikern so einen schlechten Ruf -- das beruht auf handfesten
schlechten Erfahrungen.


Viele Grüße,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/