Qualitätsziele und Managementreview für Software

[Sheridan]

#22986

Hallo,

derzeit unterstüzte ich meine Firma bei der Einführung eines ISO 9001:2000 Qualitätsmangements.

Soweit haben wir nun alle Prozesse definiert (zB Ablauf Projektmanagement, Vorgehensmodell für die Softwareentwicklung, etc.).

Nun sind wir bei dem Teil der Qualitätsmanagement der sich internes Audit und Managementreview nennt, wo das Qualitätsmanagement bewertet wird.

Um das QM-System zu bewerten sind Qualitätsziele und Messgrößen notwendig.

Da wir eine kleine Firma sind (6 Leute), dachte ich,dass es eigentlich ausreichend ist, quartälsmäßig alle Leute zu befragen, wie gut die Prozesse umgesetzt wurden, und wo es Verbesserungsmöglichkeiten gibt,

Das ist aber offenbar nicht genug, wir brauchen auch Messgrößen und Qualitätsziele. Und das ist uns etwas zu wenig griffig, was wir da definieren sollen.

Daher wollte ich mal in die Runde fragen, ob es hier Leute gibt, die in Softwarefirmen arbeiten, und vielleicht berichten können, welche Qualitätsziele und Messgrößen verwendet werden.

So ad-Hoc fallen mir folgende Qualitätsziele ein:
– 4 interne Audits für jeden Bereich (Organisations, Personalorganisation, Projektmanagement, Softwareentwicklung, Infrastrurkut) pro jahr

– Steigerung der Stabilität der bestehenden Software (Bsp. Codeabdeckung mind. 70%)

– Max. Abbarbeitungsdauer eines Fehlers (Software mit Support) innerhalb einer Woche (70%)

Ob die allerdings wirklich aussagekräftig sind und auch gelebt werden ist eine andere Frage. Letze beiden Punkte könnte man ja über Berichte leicht erstellen (MS Test bzw. Auswertung der Supportanfragen in einer Datenbank).

Bin schon gespannt auf die Antworten…

Vielen Dank

[qualitaet-2006]

#48080

Hallo,

eine Kennzahl der Kennzahl wegen halte ich für unsinning. Überlegt euch, welche Kennzahlen für das Unternehmen wichtig sind und arbeitet mit diesen.

Genauso ist es mit Zielen. Definiert für euch wichtige Ziele und beurteilt dann im QM-Review die Erreichung dieser Ziele.

Zitat:

Max. Abbarbeitungsdauer eines Fehlers (Software mit Support) innerhalb einer Woche (70%)
—–>
Das halte ich für ein gutes, wichtiges und auch messbares Ziel.

Ein Ziel kann aber auch etwas viel einfacheres sein:

Der LQ wird beauftragt, ein neues QMH herauszugeben, in dem die Zuständigkeiten (Organigramm) und das QM-System den betrieblichen Veränderungen angepasst werden.
Termin: 3. Quartal 2007

Löst euch davon, irgendetwas Unsinniges festzulegen, bloß weil ihr damit die exterenn Auditoren beeindrucken wollt, aber selber nichts davon habt.
Wenn diese nicht mit dem vorhandenen zufrieden sind, habt ihr eine interessante Diskussion und erhaltet entsprechende Verbesserungsvorschläge (bei guten externen Auditoren).

Freundliche Grüße
Stefan

— Auf der Straße zum Erfolg sind immer wieder Baustellen —

[Sheridan]

#48082

Hallo Stefan,

Zitat:
eine Kennzahl der Kennzahl wegen halte ich für unsinning. Überlegt euch, welche Kennzahlen für das Unternehmen wichtig sind und arbeitet mit diesen.

Ja da bin ich bei Dir/Ihnen. Das ist eben auch der Grund für das Posting,da uns nichts einfällt, was uns aus aktueller Sicht weiterhilft. Es soll vorallem sinnvoll und auch gelebt werden und leicht ermittelt werden können.

Selbst wenn wir das Q-Ziel mit der Fehlerabarbeitungsrate hernehmen und einmal pro Quartal über einen Bericht evaluieren, stellen wir uns die Frage, was ein schlechtes Ergebnis bringen soll (bei einem guten Ergebnis sind wir froh und lassen es wie es ist). Bei einem schlechten (zB nur 65% oder gar 50%) ist die Frage, was man für Konsequenzen daraus ableiten soll?

Weil dieses eine konkrete Bsp ist auch nur aus den Fingern gesaugt, damit irgendwas da ist. Obs sinnvoll ist, ist eben für uns irgendwie noch ein Verständnisproblem…

Vielen Dank
Georg

[Sheridan]

#48083

daher würde ich mich über beispiele freuen (sei es aus der software branche oder jeden anderen)

[Frank_Hergt]

#48088

Hallo Sheridan!

Wie sieht’s denn aus mit Kundenreklamationen, Nachbesserungen nach Freigabe, Supporteinsätzen usw.? Imho die wichtigsten Kennzahlen überhaupt.

Schöne Grüße

Frank

„There’s no problem too great for running away from it!“ (Charlie Braun)

[Sheridan]

#48092

Hall Frank,

danke für den Tipp. Habe auch versucht unsere Frimenphilosophie als Ausgangsbasis zu verwenden und die Qualitätsmerkmale einer Software darauf aufgerollt:

H. ist seit mehr als 15 Jahren als Anbieter von E.-Systemen für Unternehmen aus der … erfolgreich tätig.
Q-Ziel: Erhöhung der Zuverlässigkeit und Änderbarkeit bestehender Produkte
Q-Ziel: Ständige Verbesserung der Benutzbarkeit (Dokumentation, Benutzeroberfläche)

Für unsere Kunden haben wir eine Softwareplattform – das H. Framework – entwickelt, die es ermöglicht, auf Basis von Standardkomponenten, E. Systeme für die Bereiche … zu erstellen.

Q-Ziel: Erhöhung der Zuverlässigkeit und Änderbarkeit des Frameworks.

Dank unserer langjährigen Erfahrung in der Erfassung, Analyse und Verwaltung großer Datenmengen, konnten wir uns in unserem Heimatmarkt als einer der führenden Anbieter hochperformanter Z…systeme etablieren.
Unser Z.System ist mittlerweile in der zweiten Produktgeneration verfügbar und wird von Unternehmen unterschiedlicher Branchen eingesetzt, um chronologisch erfasste Daten effizient zu verwalten.

Q-Ziel: Ständige Optimierung der Effizienz von Datenbanken und EDM Systemen
Die Gründung des Unternehmens mit Sitz in … erfolgte im Jahr 1991 durch … und …. H. blickt mit seinen 15 hoch qualifizierten Mitarbeitern auf eine unabhängige und eigenständige Unternehmensentwicklung zurück.
Seit unserer Firmengründung sind wir ein kompetenter und zuverlässiger Partner für unsere Kunden. Als H. Kunde profitieren Sie von unserer offenen Informationspolitik, die das Vertrauen von Mitarbeitern und Geschäftspartnern gleichermaßen stärkt.

Q-Ziel: Optimierung und Dokumentation des Wissensmanagements, sowie der internen und externen Kommunikation.

[qualyman]

#48095

Hallo Sheridan,

bin kein „Softwareler“, bin „Hardwareler“ in der Automobilindustrie, was aber auch nichts zur Sache beiträgt.

Möchte nur was zu Deinen Kennzahlen bzw. Q-Zielen schreiben.

„Q-Ziel: Erhöhung der Zuverlässigkeit und Änderbarkeit bestehender Produkte“

„Q-Ziel: Ständige Verbesserung der Benutzbarkeit (Dokumentation, Benutzeroberfläche)“

Ich hätte da Probleme der Nachweisführung, da hier keine Messgrößen dabei sind, anhand derer man die wirkliche oder „Verbesserung“, „Erhöhung“, „Reduzierung“ erkennen kann.

Ist etwa so wie die Antwort bei einem Audit „Wir haben uns erheblich verbessert!“
Ja gut, wo hat eine Verbesserung denn stattgefunden? „Überall natürlich!“

Wo sind die ZDF (Zahlen, Daten, Fakten)?

Will sagen, ohne Vergleichsgröße (Anzahl, prozentuale Verbesserung , Umsatzsteigerung in € oder %, Reduzierung der Durchlaufzeiten von X auf Y Tagen usw.) hast Du einfach keine Nachweise!

Also, Glückauf bei der Festlegung von Kennzahlen!

Gute Zeit!

Qualyman – Qualitäter aus Überzeugung und Leidenschaft, auch wenn´s mal Leiden schafft!

info ad quality minus first dot de

[Sheridan]

#48098

Hallo qualyman,

danke für deinen Einwand. Das man Messgrößen braucht ist mir inzwischen (leider) auch klar (wie gesagt, dachte es genügen interne Befragungen).

Da mir ad-Hoc keine besseren Messgrößen einfallen (ausser vielleicht Codeabdeckung, sprich wieviel % Code wurde – automatisch oder manuel – getestet, salopp formuliertoder Abbarbeitungsrate von Fehlermeldungen), wollte ich das von einer anderene Seite aufziehen, nämlich zuerst möglichst (naheliegendee) Q-Ziele definieren und darauf aufbauen schauen, ob man es auch messen kann bzw. welche Messgröße geeignet ist!

[Autor]

Beiträge