Hallo Felde,
die Frage lautete "EDV-Organisation nach DIN ISO 9001:2000"!
Deine Vorschläge sind absolut richtig und sinnvoll. Genau das erwarte ich von der Fachkompetenz eines guten Administrators.
Du must jedoch unterscheiden, was muss ich in einem QMH nach der 9001 tatsächlich regeln und nachweisen. Im QMH befinden sich nur verbindliche Richtlinien zur Datensicherheit, Nachweisketten, Wiederauffindbarkeit und Sicherung von Daten.
Ich greife jedoch nicht so tief in die Autonomie meines Admin ein und erkläre ihm, wie er einen Server zu installieren hat. Er hat lt. Arbeitsvertrag zu gewährleisten, dass das EDV-Netz funktioniert und die Datensicherheit gewährleistet ist.
Genau so erwarte ich auch (das muss ich allerdings tatsächlich prüfen), dass sich mehrere Administratoren sinnvoll organisieren und keiner zum Admin-Gott im Unternehmen avanciert. Gewisse Abhängigkeiten kannst du auch über ein QMH nicht vermeiden.
Du scheinst Ahnung von der Materie zu haben. Wie werden eigentlich Softwarelösungen richtig validiert? Wie wird die Programmierung einer Softwarelösung für einen anderen Programmierer nachvollziehbar dokumentiert? Der Aufwand für Auskommentierung eines Programmes ist häufig exorbitant.
Viele Grüße

Vivian

An dieser Stelle sei allen, die hier auf meine Problemstellung geantwortet haben, sehr herzlich gedankt. Für eine etwaige Verfahrensanweisung (nach der alten Norm 9001:1994 hatten wir die auch) müssen wir wohl etwas aktuelles erstellen.
Viele Grüsse
Christian

Hallo Zusammen
Ihr habt jetzt sehr viele Punkte, die im Bereich EDV zu regeln sind aufgelistet. Macht auch alles Sinn!
Wie sieht es bei Euch mit der Datenqualität aus? Stimmen die Adressdaten, PPS-Informationen, Rückmeldungen, usw.? Wie sieht es mit dem Aufräumen von Datenmüll aus? Ist unter Datensicherheit eigentlich nur der sichere Zugriff oder auch die Richtigkeit der Daten gemeint? Meiner Meinung nach wird diesem Thema etwas wenig Aufmerksamkeit geschenkt. Wir werten immer mehr Daten zu Kennzahlen aus, aber die Sicherstellung der Richtigkeit ist kein grosses Thema.
Ich habe schon mehrere Projekte im Bereich Altdatenmigration durchgeführt. Dabei werden Daten aus Altsystemen in neue EDV-Systeme übernommen. Ihr könnt Euch nicht vorstellen, wie falsch diese Daten oft waren!
Freundliche Grüsse
Florian Padrutt



qm-online.ch

Hallo Florian,
mein Ziel ist es, die Daten in dem Arbeitsstand zu speichern, der zum Zeitpunkt der Auslieferung an den Kunden aktuell war, bzw. genau den Auslieferungsstand dokumentiert - wichtige Entwicklungsstände werden natürlich auch gesichert.
Mit Daten wird unwahrscheinlich geschlampt. Ich habe auch schon in die Abgründe der Datensicherheit und Datenrichtigkeit geschaut. Dem Datenmüll, der sich vor allem auf lokalen Rechnern tummelt, kommt man kaum bei.
Welche Erfahrungen hast du aus der Altdatenmigration? Unsere Kunden halten uns an, unsere Daten 30 Jahre aufzubewahren und lesbar zu halten. Für bezahlbare Tipps wäre ich dankbar.
Viele Grüße in die Schweiz
Vivian

Hallo,
um solche Dinge einfach und sinnvoll zu lösen sollen Sie einmal unter "www.wissIntra.de" nachlesen. Hier haben wir, für unsere Abläufe eine obtimale Lösung gefunden.
Viel Spaß und Gruß
Tanja

Hallo Vivian,
Du hast recht, dass dies alles nicht gar so viel mit Lenkung von Dokumenten im allgemeinen Sinne
hat. Andererseits bringen Dir die schönsten VA nichts, wenn Dir Deine Grundlage fehlt: EDV.
Was bringt Dir ein Backup, wenn keiner weiss, wie er das komplett abgebrannte EDV-Zentrum wieder
aufzubauen hat. Klar, es ist alles möglich, aber in welcher Zeit?
Es gibt unzählige Möglichkeiten, die erst auf den zweiten Blick damit zu tun haben.
Leider machen sich die wenigsten Gedanken darüber.
Wo steht bei Euch, was ein Admin können und tun muss? Wo dokumentiert er?
Software:
SW sollte optimalerweise "top-down" entwickelt werden.
Das heisst erstellen einer Spezifikation, danach Design und erst dann den Code.
Verifiziert wird dann durch Code-Reviews, Modul-Test, Modul-Integration-Tests und Hardware-Software-Integration-Tests.
Danach folgen die Systemtests am Gesamtprodukt.
Um sicher zu gehen, dass auch alles korrekt umgesetzt wurde gibt es Reviews von Spec, Design
und Code. Zusätzlich wird mit Tracebility gearbeitet, die zeigt, ob alle Requirements umge-
setzt worden sind und zusätzlich, ob alle Requirements abgetestet worden sind.
Diesen SW-Entwicklungsablauf wird auch "V-Modell" genannt.
Wir in der Luftfahrt haben SW auf diesem Wege zu erstellen (gem. RTCA DO178B). Je nach Kritikalität
wird dann lediglich der Umfang reduziert.
Die Validation wird durch die Integration erreicht, denn das Produkt sollte ja richtig
funktionieren. Fehler liegen dann entweder bei der Umsetzung oder bei der Spezifikation selbst.
Andere Bereiche betreiben keinen solchen Aufwand.
Hier wird ein Lasten- und Pflichtenheft erstellt und dann losgelegt.
Dokumentation sollte hier auf jeden Fall in Form eines standardisierten Funktions-/Modulkopfes
erfolgen. Dieser muss eine Kurzbeschreibung der Funktion/Moduls, die Übergabeparameter-
Beschreibung, die benutzten globalen Variablen und die Rückgabewerte aufweisen.
Zusätzlich sind die Code-Zeilen mit mehr "Hirnschmalz" zu kommentieren.
Jede Zeile muss nicht sein. Man sollte eben daran denken, dass man den Code in 2-3 Jahren selber
noch verstehen sollte.

Die Zeit, die ich bei der Erstellung des Codes spare, wenn ich nicht dokumentiere, vervielfacht
sich bei den nächsten Modifikationen.
Was auf jeden Fall auch Sinn macht, ist es eine grobe Architektur der SW zu dokumentieren.
Modifikationen werden dadurch schneller, da weniger Einarbeitungszeit nötig sein wird.
Wieder einmal ein paar Gedanken. ;o)
Grüssle
Felde