Mindestanforderungen an QM-Systeme ISO 90012006-02-28T14:30:58+01:00

QM-Forum Foren Qualitätsmanagement Mindestanforderungen an QM-Systeme ISO 9001

Ansicht von 9 Beiträgen – 1 bis 9 (von insgesamt 9)
  • Autor
    Beiträge
  • Anonym
    Gast
    Beitragsanzahl: 2122

    Welche Punkte der ISO 9001 muss ein QM-System für die Zertifizierung MINDESTENS enthalten? Die meisten Punkte lassen sich z.B. auf DL-Unternehmen (konkret im IT-Bereich) überhaupt nicht anwenden. Wie z.B. Lenkung fehlerhafter Produkte, Kennzeichnung und Rückverfolgbarkeit, und Messung und Prüfung. Die Prozesse ergeben kein direkt messbares Ergebnis. Höchstens ein paar attributive Merkmale. Störung behoben: Ja/Nein.
    Wie lauten die Mindestanforderungen?
    Kann mir da evtl jemand weiterhelfen?
    Danke

    Mary

    pen_26
    Mitglied
    Beitragsanzahl: 411

    Dokumentierte Qualitätspolitik und Qualitätsziele

    Qualitätsmanagementhandbuch

    4.2.3 Lenkung von Dokumenten

    4.2.4 Lenkung von Aufzeichnungen

    8.2.2 Durchführung von internen Audits

    8.3 Lenkung fehlerhafter Produkte

    8.5.2 Korrekturmaßnahmen

    8.5.3 Vorbeugungsmaßnahmen.

    Es kann jede Organisation selber entscheiden ob und wenn ja welche weiteren Prozesse zu dokumentieren sind.
    Wenn Fragen, einfach melden

    Anonym
    Gast
    Beitragsanzahl: 2122

    Danke.
    ..Reicht als Äquivalent zu „Lenkung fehlerhafter Produkte“ evtl. die Lenkung von mögl. Kundenreklamationen? Was sollte bei Dienstleistungen zum Beheben von IT-Störungen sonst lenken?

    KlickKlack
    Mitglied
    Beitragsanzahl: 102

    Hallo Mary,

    es kommen entweder Produkte oder Dienstleistungen als Ergebnisse Deiner Prozesse heraus. Beiden ist gleich, das der Kunde eine bestimmte Anforderung an das Ergebnis hat. Bei beiden kannst Du die Anforderungen aufzeichnen. Du hast zwar bei Dienstleistungen nicht unbedingt eine technische Spezifikation, aber Du hast Rücksprachen mit dem Kunden. Die kannst Du z.B. dokumentieren und die abgesprochenen Änderungen, eben über die Protokolle, zurückverfolgen (natürlich nur, wenn in diesen Meetings auch Beschlüsse gefasst wurden). Die Lenkung fehlerhafter Dienstleistungen erfolgt dann, zumindest meiner Meinung nach, über die Rücksprachen. Hier erfährst Du ja was schlecht gelaufen ist und es können Maßnahmen zur Verbesserung beschlossen werden. Was die Prozessmessung angeht, stell Dir vor Du sollst die Qualität eines Airbags messen. Das geht nicht auf direktem Wege. Es wäre vielleicht eine Überlegung wert, einen indirekten Weg zu finden.

    Gruß,
    Thomas

    Anonym
    Gast
    Beitragsanzahl: 2122

    Und nochmal Danke.
    Bleibt dennoch schwierig. Wenn es nicht gerade um ein Projekt für eine Neuinstallation von wasweißichwas geht, lautet die Kundenanforderung meist: „Macht ma, dass das wieder funktioniert/druckt/nicht laufend abstürzt/das Passwort annimmt etc. pp.
    Und dann funktioniert es in 99% der Fälle hinterher wieder.
    Und das versuch dann mal mit Messkriterien zu belegen. Hach..

    hadi
    Mitglied
    Beitragsanzahl: 44

    Hallo ISO Mary,

    ich glaube dass deine Frage typisch für den gesammten Dienstleistungsbereich ist. Ich kenne ganz ähnliche Schwierigkeiten der „Messbarkeit“ von Ergebnissen auch aus dem Engineering. Aber es gibt auch allgemein bekannte Lösungen bzw. Lösungsansätze die du mit etwas „Transportleistung“ auf dein QMS übertragen kannst. Sehr verbreitete ist die FQA (frequentliy aksed questions)- Methode. Damit kannst du meiner Meinung nach die von dir erwähnten 99% der Fälle wegschaffen, weil du die Frage und die möglichen Antworten darauf bereits kennst. Darüber brauchst du dann nur noch eine Art von Strichlist oder besser ein Ticket-Verfahren (wegen der notwendigen 100%-Erfassung und der Indetifikation = Rückverfolgbarkeit ) führen lassen und der Rest ist Statistik nach Gauß´scher Normalverteilung.
    Wenn du jetzt nach dem Sinn und Zweck fragen solltest, was du mit einer solchen Statistik anfangen kannst und wie sie dir hilft deinen Job zu machen, dann rate ich dir auf die beiden Enden der Glockenkurve zu schauen und zu versuchen, dafür die Gründe sowie Bewertungskriterien zu finden (z.B. DL-Anforderung nicht umgesetzt, weil: Umsetzung zu teuer, nicht wirklich notwendig, nicht erfüllte technische Voraussetzungen, fehlende Qualifikation, u.a.). Damit erhältst du Ansatzpunkte für Verbesserungen. Interessant kann es auch sein, die Veränderung der Kruve über die Zeit zu verfolgen. Werden die Flanken steiler (bei prozentual abgestufter Bewertung des Erfüllungsgrades), bzw. wird der „on top“-Bereich (bei ja/nein- Bewertungen) breiter? Findest du, dass das hier beschriebene Verfahren ein möglicher Weg ist, um dein QMS und seine Wirksamkeit in Bezug auf die Dienstleistungen eures Unternehmens nachzuweisen?

    HBH
    Mitglied
    Beitragsanzahl: 73

    Hallo, ISO-Mary,

    das Problem der Messung kann ich nachvollziehen. Aber wenn ihr 99 von 100 Malen feststellt, dass es klappt, solltet ihr erfassen, was das fehlende eine Mal war. Manchmal hilft ein zweiter Anlauf, dass es klappt, manchmal müsst ihr etwas tüfteln, bis es klappt, manchmal war es einfach nur die Tagesdisposition des Rechners, warum es nicht geklappt hat (wer kennt schon die Gefühle der Bits und Bytes eines Rechners). Wenn ihr versucht, die Fälle zu klassifizieren, könnt ihr mittel- oder langfristig sehen, in welchem Bereich gehäuft Probleme auftauchen und dann versuchen, mit den Problemlösetechniken des QM’s diese Probleme zu lösen. Also ein Heft, eine Datei oder notfalls auch nur eine Strichliste führen. In regelmäßigen Abständen auswerten – und schon habt ihr Möglichkeiten gefunden, wie ihr eure Fehler minimieren könnt.

    Grüße aus dem verschneiten Norden

    Heike

    Anonym
    Gast
    Beitragsanzahl: 2122

    Hallo Hadi,
    Hallo Heike,

    Das genannte eine 1% betrifft meist „höhere Gewalt“. Z.B. ist dann ein Fehler an dem System nicht mehr mit adäquatem Mitteleinsatz zu beheben, dann tauscht man halt aus. Dann ist das Problem im Grunde auch behoben. Oder man holt sich Support bei Herstellern, welchen man dann am Kundensystem umsetzt. Die haben ja ganz andere Möglichkeiten und Testumgebungen etc. Das sind dann die Fälle, die nicht „direkt“ aber dennoch gelöst wurden.
    Ein Ticket-Management-Systen verwenden wir.
    Ich tue mich halt schwer mit der Abgrenzung, wann ein Problem als „nicht gelöst“ gilt. Weil: Eine Lösung bieten wir dem Kunden ja auf jeden Fall (egal wie) an.
    Danke jedenfalls für Eure Tipps. Sehr interessante Denkanstöße. :)

    Mary

    Anonym
    Gast
    Beitragsanzahl: 2122

    Nochmal an Hadi:

    es könnte sein. Ich bin schon mit der Fehlerklassifizierung beschäftigt.

    FAQs funktionieren hier leider nur sehr begrenzt (lt. unseren Service-Technikern), da ganz selten ein Problem mit einem anderen identisch ist. Es handelt sich halt nur sehr bedingt um Benutzerhilfe. Da ist meist schon ein „Eingreifen“ ins System nötig.

Ansicht von 9 Beiträgen – 1 bis 9 (von insgesamt 9)
  • Sie müssen angemeldet sein, um auf dieses Thema antworten zu können.
Nach oben