Database Reference
In-Depth Information
werden, dass sich um wichtige IT-Systeme eigene Königreiche
bilden, die versuchen, sich abzukapseln, um beispielsweise
Schnittstellenprojekte zu anderen Systemen abzublocken. Die-
ser Abwehrreflex resultiert aus der Angst heraus, nicht mehr
länger unentbehrlich zu sein.
Es gibt selbstverständlich auch Bereiche, wo eine Zentralisie-
rung wünschenswert oder nötig ist. Dazu gehören beispiels-
weise Gruppen, die die firmenweiten IT-Standards festlegen,
oder Bereiche, die für den Unterhalt der IT Infrastruktur zu-
ständig sind. Den PC-Support kann man zwar ebenfalls zentral
organisieren, doch die einzelnen PC-Supporter sollten den zu
betreuenden Bereichen fest zugeteilt werden. Das Outsourcen
des PC-Supportes führt nur dazu, dass die Benutzer verärgert
werden und alles still steht. Die erhofften Kosteneinsparungen
treten dabei nur dann ein, wenn die auftretende Produktivitäts-
verschlechterung in der Bilanz nicht berücksichtigt wird.
4.13.9
Die Dokumentation oder kein Schwein schaut rein
Bezüglich Dokumentation gelten drei Grundsätze:
1.
Die Dokumentation wird sowieso nie gelesen.
2.
Die Dokumentation ist sowieso nie à jour.
3.
Für die Dokumentation hat man sowieso nie Zeit.
Punkt 1
kann jeder betätigen, der schon einmal im Support
gearbeitet hat und Benutzeranfragen beantworten musste. Die
meisten der so genannten 1st-Level-Anfragen betreffen Funktio-
nalitäten der Software, die genau so in der Online-Hilfe stehen,
wie man sie dann am Telefon beantworten muss. Viele Benut-
zer sind schlicht zu faul, die Dokumentation zu lesen. Dies ist
vermutlich auch der Grund, warum die Benutzerdokumenta-
tion vielfach nur noch in elektronischer Form als Online-Hilfe
auf der CD zum Programm mitgeliefert wird und Handbücher
nachbestellt werden müssen (die werden dann genauso wenig
gelesen).
Etwas anders verhält es sich mit der technischen Dokumenta-
tion, die für Programmänderungen benötigt wird. Bei Daten-
bankapplikationen gehört das Datenmodell und die Beschrei-
bung der Tabellenattribute dazu. Stored Procedures sollten mit
einem Programmablaufplan (z. B. Flow-Chart (igitt!), Nasi-
Schneidermann- oder Michael Jackson-Struktogramm) doku-
mentiert werden. Für Programme, die mit objektorientierter
