Zweck des Qualitätsmanagement-Handbuchs

Das Qualitätsmanagement­-Hand­buch (QMHB) ist ein Dokument mit Weisungs­cha­rak­ter, das die Qualitätspolitik, das Qualitätsmanagementsystem (QM-System) und alle für Qualität be­deutsamen Vorge­hensweisen im Un­ter­nehmen festhält. Das QMHB ist Grund­lage für die ständige Weiterentwicklung des QM-Sy­stems sowie für seine unter­neh­mens­interne und externe Beurteilung (z.B. die Beur­teilung der Qualitäts­fähigkeit des Unternehmens durch poten­tielle Kunden). Das QMHB ist Teil der for­mellen Anerkennung des QM-Systems (Zer­tifizierung, vgl. Lern­ein­heit NORMQ) und dient in allen Fragen des Qualitäts­mana­gements als Bezugs­do­ku­ment. ISO 9001 Element 5.6.5 Quality Manual fordert den Nachweis eines QMHB mit folgendem Inhalt und dem Hinweis, dass dieses nicht notwendigerweise ein separates Doku­ment sein muss:

• a description of the elements of the quality management system and their inter­action;
• the systems level procedures or references thereto.

Die Grobgliederung des QMHB ist wie folgt:

• Teil 1 enthält verschiedene Hinweise zur Organisation, Herausgabe und Pflege des QMHB.
• Teil 2 enthält die Beschreibung der Elemente des QM-Systems (in der Regel QM-Elemente gem. ISO 9001:2000).
• Teil 3 enthält Anhänge (z.B. ein Glossar der verwendeten Abkürzungen und Be­griffe) und Verweise auf andere Unterlagen, die im Zusammenhang mit dem QMHB von Bedeutung sind.

Im Sinn der hierarchischen Dokumentation ist das QMHB das Dokument der ersten Ebene. Da es auch der Kommunikation nach au­ßen (insbesondere gegenüber Kunden) dient und damit Dritten (z.B. Mitbe­wer­bern) prinzipiell zugänglich ist, enthält es keine Einzelheiten über die Verfahren (und damit über die angewende­ten QM-Maßnahmen), mit denen die Herstellung der Produkte und Dienstleistun­gen geregelt ist, sondern lediglich einen Überblick über die QM-Verfahrensanweisungen (QMVA).

Eine QMVA ist eine dokumentierte Anwei­sung oder Anleitung, die grundsätz­liche Vorgehens­weisen, Prozesse, Abläufe oder einzelne Tätigkeiten zum Inhalt hat und Auskunft darüber gibt, wer was zu machen hat und wie dies erfolgen soll. Die Detailliertheit der Beschrei­bung ist abhängig von der Bedeu­tung, welche die Anweisung oder Anleitung in bezug auf mögliche Fehlerquellen hat. Im Sinn der Dokumentation des QM-Systems ist die QMVA ein Dokument der zweiten Ebene. Dokumente der dritten Ebene sind Arbeits-, Prüf- und Dienstanwei­sungen.

Beispielunternehmen RACON/GRZ

Im folgenden wird der Inhalt des QMHB - im Sprachgebrauch der genannten Unternehmen als Unternehmenshandbuch bezeichnet - der RACON SOFTWARE Ges.m.b.H., Linz, und des Genos­senschafts-Rechen­zentrum (GRZ) Linz Ges.m.b.H. zunächst im Überblick und dann am Beispiel der Darstellung von drei Unter­neh­mensprozessen gezeigt (Stand Jänner 2001). Dies erfolgt mit freundlicher Geneh­migung der Geschäftsführung der beiden Unternehmen (im folgenden mit RACON /GRZ bezeichnet) mit Hinweis auf die ausschließliche Verwendung für Lehrz­wecke.

Die Entwicklung des QM-Systems der RACON/GRZ - im Sprachgebrauch der genannten Unternehmen als Managementsystem bezeichnet - begann im Oktober 1993, die Einführung und Zertifizierung erfolgte im Juni 1995 (erste Re-Zertifi­zierung Oktober 1998, nächste Re-Zertifizierung September 2001). Zertifizierer ist die ÖQS (vgl. Lern­einheit QUAMA). Im Mai 2000 erfolgte die Umstellung auf ein prozessorientiertes Managementsystem mit dem Ziel der Verankerung des Pro­zessdenkens auf allen Unter­nehmensebenen und der transparenten Dar­stellung der Geschäftsprozesse, im Sprachgebrauch der genannten Unternehmen als Unter­neh­mensprozesse bezeichnet. Damit im Zusammenhang sollte die Doku­mentation in Papierform drastisch - „von mehreren Ordnern auf einen Schnellhefter“ - redu­ziert werden (z.B. durch Vermeidung von Redundanz bei der Darstellung der QMVA für unterschiedliche Prozesse und durch Verlagern der Dokumentations­ebenen zwei und drei auf Datenbanken).

Die Institutionalisierung des QM ist wie folgt geregelt: Qualitätsbeauftragter (QB) ist ein Mitglied der Geschäftsführung. Eine mit zwei Personen besetzte QM-Stelle, die an den QB berichtet, koordiniert alle Maßnahmen zur Projekt- und Pro­zess­qualität (PPQ). Die für Projekt- und Prozessqualität zuständigen Instanzen sind die Prozessverantwortlichen (Prozesseigner). Elf Mitarbeiter der beiden Unter­neh­men sind als interne Auditoren tätig. In allen Organisationseinheiten wird min­destens einmal in drei Jahren ein internes Audit durchgeführt. Audit-Aufträge erteilt der QB auf Vorschlag der PPQ. Zweimal jährlich werden Management-Re­views durchgeführt. Vierteljährliche Auditorenver­samm­lungen dienen dem Erfah­rungsaustausch zwi­schen den internen Auditoren; eine jährliche Auditoren­klausur dient insbesondere zur Weiterentwicklung des Managementsystems, aber auch der Weiter­bildung.

Managementsystem RACON/GRZ

Das Managementsystem besteht aus den drei „Säulen“ Unterneh­menspolitik (mit Aussagen zur Unternehmenskultur, Kundenpolitik, Leit­linien zur Qualität usw.), Unternehmensziele (mit Teilzielen für Abteilungen, Teams und Prozesse) und Unternehmensprozesse zur Erreichung der genannten Ziele und damit zur Erfül­lung der Kundenforderungen. Unternehmensprozesse sind wie folgt gruppiert:

• Managementprozesse schaffen die Rahmenbedingungen für das Management­system. Vier Managementprozesse wurden identifiziert:

1. 1. Unternehmens­darstel­lung
   2. Managementsystem
   3. Strategie & Planung
   4. Unternehmensver­bes­se­rung

• Kundenprozesse dienen der Realisierung der vom Kunden geforderten Pro­dukte und Dienstleistungen. Sieben Kundenprozesse wurden identifiziert:

1. Hardware- und Software-Installation
2. Hotline/Service
3. Netzwerkdienste
4. Rechenzentrumsbetrieb
5. Schulung
6. Software-Analyse und -Entwicklung
7. Systemsoftware

• Unterstützungsprozesse sind nach Innen orientiert und bilden eine wichtige Basis oder eine Unterstützung für die Management- und Kundenprozesse. Elf Unterstützungsprozesse wurden identi­fi­ziert (z.B. Beschaffung, Nachkalkulation /Controlling, Software Engineering).

Abbildung QMHB-1 zeigt die Vernetzung der drei Arten von Unternehmens­pro­zessen zum Managementsystem analog zur Darstellung der Prozessorientierung in ISO 9001:2000 (vgl. Lerneinheit NORMQ); Beschaffung wird beispielhaft für Unterstützungsprozesse genannt.

Unternehmenshandbuch RACON/GRZ

Die Dokumentation des Managementsystems RACON/GRZ im Unternehmens­handbuch ist unabhängig von der in der ISO 9001:2000 verwendeten Struktur; im Vordergrund stehen nicht „Elemente“, sondern die Unternehmensprozesse. Diese sind aufgaben- und abteilungsübergreifend organisiert. Folgende Gliederung wird verwendet:

• Unternehmenspolitik
• Unternehmensbeschreibung
• Unternehmensziele
• Unternehmensprozesse (Untergliederung wie oben angegeben)

Die Dokumentation des Managementsystems ist auf diversen Lotus Notes-Daten­baken und auszugsweise auch auf den Webseiten abgelegt. Auch wird auch das interne Auditing verwaltet (vom Audit-Auftrag bis zum Audit-Bericht einschließ­lich der Maßnahmen für Qualitätsverbesserungen). Bei der Bearbeitung der Maß­nahmen im Sinn einer kontinuierlichen Verbesserung der Unternehmensprozesse werden alle Anregungen koordiniert, unabhängig davon, ob sie aus internen oder externen Audits, von den Prozessverantwortlichen oder von einzelnen Mitarbeitern stam­men. Neben diesen QM-spezifischen Daten­banken gibt es eine Reihe weiterer (z.B. Projektdatenbanken) für verschiedene Nutzungszwecke im Rahmen des Management­systems (z.B. zur Wissensspeicherung und als Ideenbörse). Die Ein­schulung neuer Mitarbeiter in das Managementsystem wird durch ein Web-basiertes Training (WBT), einem multimedialen Lernprogramm mit dem Namen „Q4U“ unterstützt.

Managementprozess „Unternehmensverbesserung“

Dieser Prozess ist wie folgt in Teilprozesse gegliedert (nach der Aufzählung wird die Dokumentation von Teilprozess G - Qualitätsaufzeichnungen wiedergegeben):

A - Kontinuierliche Verbesserung

B - Managment Review

C - Interne und externe Audits

D - Korrektur- und Vorbeugungsmaßnahmen

E - Lenkung von Fehlern

F - Lenkung der Dokumente

G - Qualitätsaufzeichnungen

H - Qualitätsplanung

Prozess

Beschreibung

Die Qualitätsaufzeichnungen dienen zum Nachweis qualitätsrelevanter Tatsachen bzw. Zustände, die in GRZ/RACON auftreten. Mittels der erstellten Aufzeich­nungen werden auch die von den Kunden geforderten Nachweise über die Eigen­schaften eines Produktes erbracht. Aufzeichnungen beschreiben einen Istzustand zu einem bestimmten Zeitpunkt. Sie werden auch als Nachweisdokumente be­zeichnet. Sie dürfen nach Erstellung nicht mehr geändert werden. Beispiele sind: Berichte (Audit-, Installations-, Service-, Kundenbesuchs-, Testbericht), Fehlerbe­schrei­bungen, Protokolle, Lieferscheine.

Neben Vorgabe- und Nachweisdokumenten gibt es noch Hilfsaufzeichnungen, Checklisten etc. Diese können evtl. zu einem Nachweisdokument werden (z.B. eine ausgefüllte Checkliste als Nachweis für eine erbrachte Tätigkeit).

Lebenszyklus der Qualitätsaufzeichnungen

1. Erstellung

Ein Dokument wird von den dafür zuständigen Personen erstellt. Ersichtlich müs­sen sein:

• Dokumenten-Identifikation mit Versionskennung: sollte eine Versionsnummer oder eine andere eindeutige Versionskennung sein. Die aktuelle Version muss leicht und eindeutig identifizierbar sein.
• Zuordnung zu Produkt oder Projekt oder Thema
• Ersteller und Erstellungsdatum

2. Änderung

Nachweisdokumente dürfen nach der erfolgten Erstellung nicht mehr geändert wer­den. Sie beschreiben einen Istzustand zu einem bestimmten Zeitpunkt.

3. Verteilung

Die Verteilung hat durch den Ersteller oder die zuständige Organisationseinheit zu

erfolgen. Alle vom Dokument Betroffenen oder im Verteiler Genannten müssen von der Ausgabe des Dokuments wirksam verständigt werden.

4. Aufbewahrung

Die Aufbewahrung hat so zu erfolgen, dass die Dokumente leicht wiederauffindbar sind und sicher vor Beschädigung und Veränderungen bewahrt werden. Die Auf­bewahrung kann auch elektronisch erfolgen. Vertrauliche Nachweisdokumente sind so aufzubewahren, dass die Vertraulichkeit gewährleistet bleibt. Als Aufbe­wahrungsdauer für qualitätsrelevante Dokumente gelten 7 Jahre nach Projekt­abschluss, falls nicht eine andere Festlegung erfolgt.

5. Beseitigung

Nach Ablauf der Aufbewahrungsfristen können die Nachweisdokumente - wenn sie nicht mehr benötigt werden - entsorgt werden. Dies hat in angemessener Form zu erfolgen.

Kundenprozess „Software-Analyse und -Entwicklung“

Prozess

Prozessbeschreibung

1. Prüfung der Kundenanfrage

Kundenanfragen werden vom zuständigen Produktverantwortlichen (PV) oder einer von Geschäftsführung bzw. Abteilungsleiter beauftragten Person auf die gene­relle Realisierbarkeit geprüft. Dabei wird beurteilt und festgelegt, ob es sich um eine kostenpflichtige Änderung, laufende Wartung oder einen Neuauftrag han­delt. Falls notwendig, werden für die Beurteilung vom Kunden Detailan­forde­rungen erhoben. Das Ergebnis wird dem Kunden als formlose Stellungnahme retourniert. Im Fall laufender Wartung wird die Anfrage für künftige Releases evi­dent gehalten.

2. Machbarkeitsprüfung

Wünscht der Kunde eine Machbarkeitsprüfung oder Realisierung bzw. entscheidet der PV für eine solche Prüfung, wird die Machbarkeit im Detail geprüft. Dabei prüft der PV (oder ein dafür bestimmter Projektleiter) in Abstimmung mit allen notwendigen Experten (z.B. Organisatoren, SW-Entwicklung, System-SW-Ent­wick­lung, Software-Engineering, Netzwerkdienste, RZ-Betrieb, Sicherheit im LAN) die technischen Voraussetzungen, die Machbarkeit und die Kosten für die Realisierung, sowie mögliche Realisierungstermine unter Berücksichtigung ver­fügbarer Ressourcen.

Falls notwendig, werden vom Kunden Details zu den Anforderungen eingeholt. Gesetzliche Anforderungen sind zu berücksichtigen. Die Ergebnisse dieser Prü­fung gehen an den Kunden zur Entscheidung.

3. Vertragsprüfung

Der erteilte Auftrag wird formal vom PV geprüft. Falls der Kunde Änderungen fordert und diese Einfluss auf Kosten haben, wird ein neues Angebot erstellt.

4. Projektplanung

Spätestens jetzt wird ein Projektleiter (PL) und bei neuen Produkten der künftige Pro­duktverantwortliche nominiert. Der PL entscheidet, ob ein Arbeitsauftrag oder ein Projektplan erstellt wird. Es werden die in der NOTES-Projektdatenbank (oder ver­gleichbaren Systemen) vorhandenen Formularvorlagen verwendet.

Falls Auswirkungen auf Netzwerk- oder HW-Ressourcen oder Systemsoftware zu erwarten oder Kundenschulungen vereinbart sind, werden auch die dafür zustän­digen Stellen in die Planung einbezogen. Sicherheitsrelevante Auswirkungen wer­den in der Sicherheitsinformationsdatenbank dokumentiert. Bei Erstel­lung von Folgereleases werden die evidenten Fehler und Vorbeugungsmaß­nahmen in der Projektplanung mit berücksichtigt.

5. Analyse/Design

Die dokumentierten Forderungen des Kunden werden vom Projektteam analysiert. Es wird das Datenbankdesign, das SW-Design, die Bedieneroberfläche, die Auftei­lung in Funktionen und Module, deren Funktionsweise sowie die Schnittstellen zu anderen Systemen festgelegt. Dazu werden detaillierte Informationen vom Kunden eingeholt.

6. Review der Designergebnisse

Die Ergebnisse von Analyse/Design werden von all jenen Stellen geprüft, die an der Entwicklung beteiligt sind. Geprüft wird, ob die Kundenforderungen erfüllt werden und das Design der gültigen internen Richtlinien für Analyse/Design und SW-Entwicklung entspricht. Die Ergebnisse der Überprüfung werden dokumen­tiert.

7. SW-Entwicklung

Auf der Grundlage des geprüften Designs erfolgt die Umsetzung durch die SW-Entwickler des Projektteams. Berücksichtigt werden dabei die gültigen Richtlinien für SW-Entwicklung. Dann sind auch die notwendigen Vorkehrungen für die Kennzeichnung und Rückverfolgbarkeit der SW-Produkte und für die Siche­rung/Archivierung der Entwicklungsergebnisse festgelegt.

Die Bereitstellung der Infrastruktur für die SW-Entwicklung erfolgt im Rahmen des Supportprozesses „Software-Engineering“. Für die SW-Entwicklung benötigte externe Ressourcen (z.B. Hardware, Software, Leasingpersonal) werden über den Supportprozess „Beschaffung“ bereitgestellt.

Vom Kunden beigestellte Produkte bzw. über den Supportprozess „Beschaffung“ bereitgestellte Produkte (die in der zu entwickelnden Software Eingang finden) werden vom Projektleiter auf ihre Eignung geprüft.

8. Dokumentation

Möglichst parallel zur SW-Entwicklung wird auch die Dokumentation erstellt. Die

programminterne Dokumentation ist entsprechend der gültigen Richtlinien für SW-Entwicklung zu führen. Falls im Projektplan/Arbeitsauftrag vereinbart, wer­den ONLINE-Bedienerhilfe, Produktbeschreibung und/oder Handbuch erstellt. Jedenfalls wird eine Installationsanleitung erstellt. Die erforderlichen Informa­tionen werden den zuständigen Mitarbeitern für „HOTLINE/Service“ und bei ver­einbarten Kundenschulungen auch den dafür zuständigen Mitarbeitern weiter­gegeben.

9. Tests

Die im Projektplan/Arbeitsauftrag definierte Stelle überprüft, ob die Software den Kundenforderungen sowie allgemeinen Anforderungen (Performance, Bedien­bar­keit, Stabilität u.a.) entspricht. Die Ergebnisse der Tests werden in einem Test­be­richt dokumentiert. Erkannte Mängel werden im Teilprozess SW-Entwicklung be­hoben. Die Tests sollen einerseits auf den Erfahrungen früherer ähnlicher Pro­jekte bzw. früherer Releases basieren und andererseits den Funktionsumfang des Pro­jekts (z.B. lt. ORG-Vorschlag) berücksichtigen.

10. Freigabe

Nach erfolgreichen Tests erfolgt die Abnahme durch den Kunden (oder dessen fachlichen Vertreter) und das Produkt wird durch den Projektleiter freigegeben. Die Freigabe wird formlos dokumentiert, alle Projektbeteiligten werden informiert. Eine Freigabe trotz Fehlern oder Mängeln ist mit dem Kunden abzustimmen und als Sonderfreigabe zu dokumentieren. Solche Fehler oder Mängel sind jedenfalls für die laufende Wartung evident zu halten.

11. Projekt-Review

Abhängig von der Größe und Komplexität des Projekts wird ggf. ein Projekt-Review durchgeführt. In diesem Review betrachtet das Projektteam den Projekt­verlauf kritisch und überlegt Verbesserungsmaßnahmen für das Produkt und auch die Prozesse. Maßgebliche Inputs sind: Nachkalkulation der Aufwände (vor allem Arbeitsaufwand), Testberichte, Vergleich Plan-/Isttermine und vor allem Erfah­rungen des Projektteams.

12. Produktwartung

Anforderungen für die Produktwartung kommen entweder durch Kundenanfragen, durch Informationen aus HOTLINE/Service, aus aufgetretenen Fehlern oder durch Projekt-Reviews. Der PV sammelt diese Anforderungen und entscheidet, welche Korrekturen oder Verbesserungen als eigene Projekte abgewickelt werden und welche im Zuge von neuen Releases mitgeplant werden. Jedenfalls werden die Kor­rekturen und Verbesserungen gesammelt und evident gehalten. Wartungs­aufträge bzw. Wartungsprojekte werden mittels Arbeitsaufträgen abgewickelt.

Weiters gilt

• Ziele des Kundenprozesses „Software-Analyse und -Entwicklung“ in der aktu­ellen Fassung
• Messgrößen für den Kundenprozess „Software-Analyse und Entwicklung“ in der aktuellen Fassung
• SWE-Richtlinien, die für den Prozess bzw. für die betroffenen Bereiche gültig sind
• Gesetzliche Anforderungen, soweit für den Prozess oder das Projekt zutreffend

Unterstützungsprozess „Beschaffung“

Prozess

Prozessbeschreibung

1. Ermittlung und Genehmigung der Anforderung

nur wenn anfordernde Stelle = INTERN

Die interne Anforderung wird von der anfordernden Stelle ermittelt und doku­mentiert (z.B. die zu beschaffende Software / benötigte Hardware für einen Kun­den, Anforderungen an Leasingpersonal, Anforderungen an zugekaufte Software, ...) und in Form eines Beschaffungsdokumentes an die beschaffende Stelle (z.B. Einkauf) weitergeleitet. Die Anforderung muss bereits von der zuständigen Stelle (GF, Abteilungsleiter, Fachbereichsleiter,...) bewilligt sein.

2. Prüfung der Beschaffungsdokumente

Die Beschaffungsdokumente (von anfordernden internen Stellen oder von externen Kunden) werden von der beschaffenden Stelle formell (auf Vollständigkeit und Angemessenheit) geprüft, ob das zu beschaffende Produkt oder die Dienstleistung ausreichend und klar beschrieben ist (z.B. ist Release bei Software angegeben, ist die Hardwarebestellung vollständig, wurden die Anforderung an Leasingpersonal angeführt). Für den Inhalt der Beschaffungsdokumente ist die anfordernde Stelle verantwortlich (z.B. Anzahl von PC, fachliche Anforderungen an Leasingpersonal, welches Release bei Software,...).

3. Beschaffung von Produkten / Dienstleistungen

Die beschaffende Stelle wählt den Lieferanten aus (z.B. aus Lieferantenkartei, durch Einholen von Angeboten oder ggf. auf Wunsch der anfordernden Stelle) und führt die Bestellung durch. Die Lieferanten werden nach folgenden Kriterien aus­gewählt: Lieferzeit, Preis, bisherige Erfahrungen, bestehende Verträge, .... Darüber hinaus werden neue Lieferanten in die Lieferantenkartei aufgenommen.

4. Verfolgung offener Bestellungen

Der Status der Bestellungen wird von der beschaffenden Stelle verfolgt. Sie urgiert beim Lieferanten wegen nicht termingerechter Lieferungen von Pro­dukten/Dienst­leistungen.

5. Wareneingang / Bereitstellung der Dienstleistung

Die anfordernde Stelle nimmt das bestellte Produkt/die bereitgestellte Dienst­leistung entgegen und prüft diese auf Vollständigkeit, Qualität (z.B. Liefer­schein­kontrolle, Prüfung der erbrachten Leistung vom Leasingpersonal,...) und informiert die beschaffende Stelle über die erfolgte Lieferung bzw. erbrachte Leistung. Diese leitet den Verrechnungsvorgang ein.

6. Bewertung des Lieferanten

Auf Basis der erbrachten Leistung werden die Lieferanten (z.B. Leasing­unter­nehmen) bewertet/beurteilt.

Normen

ÖNORM EN ISO 9000: Qualitätsmanagementsysteme - Grundlagen und Begriffe / Quality management systems - Fundamentals and vocabulary (ISO 9000:2000)

ÖNORM ISO 9000-3: Qualitätsmanagement und Qualitäts­siche­rungs­normen; Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software

ÖNORM EN ISO 9001: Qualitätsmanagement-Systeme - Anforderungen / Quality management systems - Requirements (ISO 9001:2000)

ÖNORM EN ISO 9004: Qualitätsmanagementsysteme - Leitfaden zur Leistungs­ver­bes­se­rung / Quality management systems - Guidance for performance improvements (ISO 9004:2000)