KM: Muss es denn immer gleich ein DMS sein?

Kürzlich ist ein wichtiger Ordner verschwunden, der zur gemeinsamen Befüllung in einem unserer "öffentlichen" Laufwerke abgelegt war. Das gab vielleicht Hektik. Im Nachhinein stellte sich heraus, dass ein Nutzer den Ordner per drag and drop kopieren wollte und dabei ausversehen über dem falschen Ordner losgelassen hatte, natürlich im Verschiebemodus. Als er den Fehler bemerkte, drückte er sofort auf Abbrechen - damit war dann vieles weg und manches durcheinander. Kurze Zeit später schon schwirrten diverse aber nicht gerade aktuelle Stände der Dateien herum.

Wie konnte das passieren? In aller Kürze: Die Rechte waren nicht restriktiv genug gesetzt, die Verzeichnisstruktur verwirrend und kompliziert. Es gab kein geordnetes Versionsmanagement.

Lessons learned? Nachdem die IT-Abteilung per Backup den Ordner wiederhergestellt hatte, ging alles genau so weiter wie bisher.

Und damit komme ich auf das Thema DMS (Dokumentenmanagementsystem). Denn solche Ereignisse geben natürlich Wasser auf die Mühlen der Verkäufer teurer Softwarelösungen.

Ein DMS ist sicher keine schlechte Sache. Das oben geschilderte Horror-Szenario wäre uns bestimmt erspart geblieben. Doch verursacht es natürlich auch hohe Kosten, zum einen während der Einführung, zum anderen auch im Betrieb, z.B. durch fortwährend nötige Mitarbeiterschulungen. Denn was nutzt das tollste System, wenn die Dokumente weiterhin auf der lokalen Platte schlummern.

Deswegen stellt sich die Frage, ob es nicht ein einfacherer Ansatz auch tun kann, gerade in kleineren und mittleren Unternehmen. Zum Beispiel die umsichtige Nutzung von Bordmitteln wie etwa gemeinsamen Laufwerken mit einer durchdachten und intuitiven Struktur sowie sorgfältig vergebenen Rechten. Wenn eine Datei oder ein Verzeichnis logisch an mehrere Orte passt, so müssen die entsprechenden Verknüpfungen existieren um soweit irgend möglich Redundanzen zu vermeiden.
Um eine überlegte Struktur herzustellen, müssen Verantwortlichkeiten verteilt werden, so dass in jeder Arbeitsgruppe oder Abteilung ein Dokumentenmanager bestimmt wird. Diese müssten sich bei Bedarf austauschen, um die Gesamtstruktur zu harmonisieren.
Weiterhin müssten die Nutzer angehalten werden, ihren Dateien aussagekräftige Namen zu geben und, wo irgend möglich, Metadaten nach einem festen Schema beizufügen.
Je nach Größe der Gemeinschaft müsste es Leute geben, die regelmäßig alle öffentlichen Laufwerke auf Einhaltung der oben genannten Regeln inspizieren und bei Bedarf nachhaken.

Doch all das kann nur unter einer Bedingung überhaupt funktionieren: Der Chef muss mit gutem Beispiel vorangehen.

Wer diese Aussagen jetzt als Binsenweisheiten abtut, der sollte einen Blick in die gängige Unternehmenspraxis werfen.

COM: Netzausfall - Fluch oder Segen?

Heute gab es in der Arbeit einen Totalausfall des Netzes, ich weiß bis jetzt nicht warum. Eines jedoch wurde mir aufs Deutlichste bewusst: Ohne Netz läuft kaum noch etwas. Viele Leute saßen fast etwas hilflos vor ihren schwarzen Monitoren (IT-Abteilung hatte gebeten, alle Rechner runterzufahren).

Doch für mich war diese Zeit ein absoluter Segen. Endlich konnte ich einmal ohne schlechtes Gewissen alle Fragen, die mir schon immer unter den Nägeln brannten, die ich aber bisher "nicht zu stellen gewagt hatte", loswerden. Alle hatten die nötige Ruhe, um mir die Zusammenhänge zu erklären und über neue Ideen zu diskutieren.

Meine Forderung: Ein Netzausfall pro Woche, mindestens drei Stunden! Für das Zwischenmenschliche, zum Nachdenken und Fragenstellen.

EII: Praxisschock 3 - Insellösungen

Insellösungen werden allseits verdammt. Dennoch wird in der Praxis das Schaffen neuer Insellösungen mehr als begünstigt. Wenn man als Informatiker eine gute Arbeit macht, bestehende Anwendungen sicherer und wartbarer redesigned und sorgfältig SWPÄ-Wünsche umsetzt, verdient man sich keine Lorbeeren bei der Führung. Wenn man jedoch ein neues Programm erstellt, welches eine angebliche Lücke füllt, gibt es schnelle Anerkennung: "Die tun was!" Da ist es absolut egal, ob sich die neue Anwendung sauber in die bestehende Anwendungslandschaft einpasst, ob sie sauber designed ist, etc. Für den Nutzer zählt halt nur das Ergebnis - und die Führung ist nun einmal zumeist Nutzer.

Deshalb hilft meiner Meinung nach die gewaltvolle Einführung von SAP o.ä. allein kaum weiter. Stattdessen müsste ein Gesinnungswandel bei den Leuten herbeigeführt werden. Oft gibt es eine ebenbürtige Alternative zum Schaffen einer eigenen Applikation. Die Führung muss sich dessen insbesondere bewusst sein und tolle neue bunte Programme kritisch hinterfragen. Welchen Mehrwert bringt uns dieses Programm? Kann dieser Mehrwert auch anders erreicht werden? Wie ist es um die Wartbarkeit des Programms bestellt? Gibt es eine Entwickler- und eine Nutzerdokumentation? Wie ist der Entwicklungsprozess abgelaufen und wie passt sich das Programm in die bereits bestehende Anwendungslandschaft ein?

Bitte nicht falsch verstehen. Innovative neue Ideen sind absolut zu bestärken, es darf gern etwas ausprobiert werden, aber bevor man das Programm offiziell übernimmt, gilt es halt, die o.g. Fragen zu beantworten.
Ohne Experte zu sein, würde ich also auf die Frage, ob man etwa SAP einführen solle, mit einem "Ja, aber" antworten. Der Schritt ist sicher richtig, allerdings besteht die ernstzunehmende Gefahr, das schon kurze Zeit später neue Insellösungen wie Pilze aus dem Boden schießen, wenn sich nichts an der Einstellung insbesondere der Führungskräfte ändert. Deshalb dürfte nach der Einführung nicht Schluss sein, sondern es müsste eine kontinuierliche Überwachung der Softwarelandschaft geben.
Ist es zu schwierig, die Einstellung der Leute zu ändern, so muss nach Alternativen gesucht werden. Eine Möglichkeit wäre es beispielsweise, dass neue Programme erstellt werden dürfen, diese aber bestimmte Schnittstellen zur Verfügung stellen müssten. Das würde zu einer zwar dezentralen und heterogenen, dafür aber wenigstens gekoppelten Anwendungslandschaft führen, ein Schritt in Richtung Service-Oriented Architecture.

COM: Praxisschock 2 - SWPÄ-Maßnahmen verwalten

Wie man es macht, es ist verkehrt.

Erlebnis 1:
Ich wurde von jemandem aus meiner Abteilung, den ich nicht kannte, angesprochen und um den Einbau einer neuen Funktion in eine bestehende Webanwendung gebeten. Da ich noch relativ neu war und nicht genau wusste, wie das Anfordern einer SWPÄ (Softwarepflege/-änderung)-Maßnahme zu funktionieren hat, bat ich die Person, einen formlosen Antrag zu schreiben mit einer kurzen Beschreibung der gewünschten Funktion und des Nutzerkreises, der davon profitieren solle.
Dann hörte ich eine Weile nichts mehr davon - bis ich einen kleinen Anschiss von meinem Chef bekam, dass ich freundlicher zu den Nutzern sein müsste, weil diese ja der Grund für meine Existenz überhaupt wären. Die mir fremde Person hatte wohl eine wichtige Position innerhalb der Abteilung inne und war es gewohnt, dass ihre Wünsche sofort umgesetzt werden. Deshalb hatte sie mein Verhalten zum Anlass genommen, sich bei meinem Chef über mich zu beschweren.

Erlebnis 2:
Aus Erfahrungen lernt man ja bekanntlich. Als das nächste Mal jemand an mich herantrat und eine neue Funktion forderte, die für mich inhaltlich auch Sinn ergab, zögerte ich nicht lange und implementierte diese. Kurze Zeit später kam ein anderer aufgebrachter Nutzer zu mir und schimpfte, dass er jetzt noch ein sinnloses Feld mehr zu befüllen hätte. Ich sollte ihm doch die Arbeit mit meiner Anwendung erleichtern und sie nicht, wie wohl geschehen, schwerer machen. Wenn ich zukünftig etwas implementieren wolle, sollte ich das doch vorher mit den Nutzern absprechen.

Was kann daraus nur die Lehre sein? Es muss einen formalen und vom Chef abgesegneten Weg geben, den alle SWPÄ-Maßnahmen gehen müssen. Im Rahmen dessen muss die Priorisierung des Vorhabens und die Absprache mit anderen Nutzern erfolgen.

DB: Praxisschock 1 - Datenbankdesign

Was nützen die tollsten theoretischen Kenntnisse, knackfrisch aus der Vorlesung, wenn man ein System pflegen soll, in dem diese absolut keine Berücksichtigung finden? Ich gebe gern ein Beispiel aus meiner persönlichen kurzen Erfahrung. Wir haben auf Arbeit eine Access-"Datenbank" mit nur einer Tabelle, die aus zig extrem dünn besetzten Spalten mit Namen wie u.a. KODE0 bis KODE9 besteht. Als ich das redesignen wollte, haben die Nutzer geschimpft.

Grund war, dass Sie, insbesondere jedoch die "Power-User", in diese Datenbank so schön leicht an der Nutzeroberfläche vorbei von der Seite reinwurschteln (Reinwurschtability) konnten - und das sollte gefälligst auch so bleiben... Außerdem gestaltet sich das Design einer Oberfläche mit einer eleganten Datenbankstruktur ungleich schwieriger, weil man dann die eingebauten Helferleins nicht so gut benutzen kann (Stichwort View-Updates). Und die Spalten mit den kryptischen Namen, so hieß es, ermöglichten eine unglaubliche Flexibilität.

Und so bleibt einfach alles beim Alten.

Sonstiges: Ziel dieses Blogs

In diesem Blog sollen Erfahrungen aus der Informatik-Praxis geschildert werden, damit sich andere darüber amüsieren oder vielleich sogar die eine oder andere Lehre daraus ziehen können. Ich wünsche viel Spaß beim Lesen.