www.der-wirtschaftsingenieur.de

Ishikawa-Diagramme dienen der Darstellung von Ursachen, die zu einer Wirkung führen und wurden vom japanischen Chemiker Ishikawa Kaoru 石川馨 erfunden. Die Wirkung kann positiv sein, meistens werden in Ishikawa-Diagrammen jedoch negative Wirkungen (Fehler) dargestellt, welche untersucht werden.

Ein alternativer Begriff für ein Ishikawa-Diagramm ist Ursache-Wirkung-Diagramm (bzw. engl. Cause and Effect Diagram).

Diese Art der Diagrammgestaltung soll Ursachen darstellen, die zu einem definierten Fehler führen. Ishikawa-Diagramme finden daher insbesondere Anwendung im Qualitätsmanagement. Auch in Fachbereichen, welche sehr viele Faktoren bzw. Parameter berücksichtigen müssen, beispielsweise die Fertigung und Logistik, sind Ishikawa-Diagramme eine verbreitete Technik zur Veranschaulichung.

Ishikawa-Diagramme sind beispielsweise eine häufige Methode zur Analyse-Darstellung von Fehlerursachsen im Sinne von Poka Yoke in der Fertigung.

(mehr…)

Poka-Yoke ポカヨケ („dumme Fehler – Vermeidung“) ist eine Ideologie, welche mit vielfältige Ansätze unternimmt, um Prozesse in der Fertigung, insbesondere Montage, zu optimieren. Der Schwerpunkt unter der Zielsetzung von Poka-Yoke, die Null-Fehler-Produktion anzustreben und näherungsweise zu erreichen.  Werden Fehler festgestellt, wird die Ursache ergründet. Lässt sich die Ursache vermeiden, so wird sie im Sinne von Poka-Yoke so gut wie möglich abgestellt und tritt bestenfalls gar nicht mehr auf.

Poka-Yoke war ursprünglich eine Initiative von Dr. Shingo, Shigeo (新郷 重夫), welcher auch als Mitbegründer des Toyota Produktionssystems gilt, wovon Poka-Yoke wiederum ein Kernbestandteil ist. Poka-Yoke steht unter dem Dach von Kaizen 改善 (“stetiges Verbesserungsstreben”).

(mehr…)

Produktanforderung

Eine Produktanforderung ist eine Vorgabe von zu erfüllenden Eigenschaften/Merkmalen eines Produkts oder einer Komponente und damit eine Aussage über eine notwendige Soll -Beschaffenheit oder -Fähigkeit.

Ergonomische und wirtschaftliche Software muss eine Robustheit gegenüber Fehlern bei der Benutzung aufweisen (Error Tolerance).

Die Fehlerrobustheit betrifft sowohl die Zuverlässigkeit der Arbeitsergebnisse (Berechnungen) als auch der Zuverlässigkeit der Software selbst (Software-Stabilität).

Eine zu lange Zahl oder Zeichenkette oder Daten, welche in einem anderen Format erwartet wurden, können das Arbeitsergebnis unbrauchbar machen oder gar zum Programmabsturz führen.

Wird eine Zahl beispielsweise vom Typ Integer erwartet, ist das Eingabefeld auf die richtige maximale Länge zu begrenzen und zu prüfen, ob die Eingabedaten tatsächlich nur Zahlen (und nicht etwa Sonderzeichen oder Buchstaben) enthalten. Wird ein Datum erwartet, ist nicht nur die richtige Länge zu begrenzen, sondern auch ein (möglichst gängiges) Format zu definieren und auf Einhaltung zu prüfen.

Fehler können bei jeder Eingabe durch den Benutzer aus Unwissenheit, Unerfahrenheit, Missgeschick oder Unaufmerksamkeit erfolgen. Es gilt daher, dem Benutzer niemals zu vertrauen, sondern alle Eingaben auf Fehlerfreiheit zu überprüfen. Der Benutzer wird diese kritische Einstellung gegenüber seinen Eingaben mit Vertrauen in die Programmzuverlässigkeit würdigen.

Ein weiterer Aspekt ist die gezielte Ausnutzung eines Fehlers (SQL-Injection, gezielte Herbeiführung eines Buffer-Overflows für Exploits u.a.), welche durch Fehlerrobustheit so weit wie möglich erschwert werden soll.

Fehlerhafte Eingaben müssen korrigierbar sein. Trotz fehlerhafter Eingaben muss das beabsichtigte Arbeitsergebnis nur mit geringem oder besser gar keinem Korrekturaufwand (durch selbstständige Fehlerkorrektur) erreicht werden können.

Der Benutzer soll auf Fehler hingewiesen und zur Korrektur aufgefordert oder ihm diese empfohlen werden. Fehlermeldungen sowie Korrekturaufforderungen müssen verständlich, sachlich und konstruktiv formuliert und logisch, aber leicht nachvollziehbar strukturiert sein (abhängig von der Komplexität und vom zu erwartenden Kenntnisstand der Benutzer, können “logisch” und “nachvollziehbar” zwei gegensätzliche Adjektive sein!).

Eine selbstständige Fehlerkorrektur durch das System gilt als kritisch und sollte dem Benutzer angezeigt werden, so dass er die Korrektur bestätigen oder ggf. abändern kann.

Zur Fehlermeldung gehören Fehlererkennung, wo ein Fehler auftrat, warum er auftrat (Erklärung eines kausalen Zusammenhangs) sowie ggf. Empfehlungen zur zukünftigen Fehlervermeidung.

Durch sinnvolle Gestaltung der Mensch-Maschine-Schnittstelle (Fehlerprävention) durch sinnvolle Strukturierung, Benennung, Beschriftung und weiterführenden Informationen, soll das Auftreten von Fehlern bereits von vorne herein unwahrscheinlich werden. So sollte das richtige Format z. B. für ein Datum oder eine Telefonnummer vorgegeben werden (idealerweise mit Beispiel), bestenfalls aber kann der Benutzer sofort an Hand der Eingabefeldgestaltung das zu verwendende Format erkennen.

Bei der Software-Entwicklung ist ein systemeigenes Fehlermanagement zu überlegen. Ein solches Fehlermanagement soll negative Auswirkungen (z. B. Zeitverlust) von Fehlern begrenzen. Dazu gehört u.a. die Reversibilität von
Fehlern (z. B. mit UNDO-Funktionen zum rückgängig machen von Eingabeschritten). Je komplexer die Software wird, desto schwieriger sind allerdings i.d.R. auch der Entwurf und die Implementierung einer Reversibilität.

Ergonomie betrifft nicht nur Stühle, Schreibtische und sonstige Büromöbel, sondern auch Anzeigen und Steuerelemente (im Büro, Cockpit, Konsolen, Anlagen usw.). Die Ergonomie ist daher auch Einflussgeber in der Produktgestaltung im Maschinenbau und der Elektrotechnik. Sehr viele Anzeigen und Steuerelemente, welche vor 10 Jahren noch Hebel und analoge Anzeigen waren, sind heute digitalisiert und als Software realisiert. Die Ergonomie spielt daher auch immer mehr in der Software-Entwicklung eine Rolle. (mehr…)

Die Verantwortungsmatrix ist Teil einer guten Dokumentation im Qualitätsmanagement. Mit einer Verantwortungsmatrix werden Verantwortungen und Informationsrechte über einen Tätigkeitsbereich (z. B. die Fertigungsplanung oder  Kundenabnahme) den Abteilungen zugewiesen.

V = Verantwortung; MV = Mitverantwortung; I = Informationsempfänger

Wie bei allen Dokumenten im Qualitätsmanagement, ist auch die Verantwortungsmatrix mit Hinweisen über Ersteller, Prüfer, Erstellungs- und Prüfungsdatum sowie umfassende Änderungshinweise zu versehen.

In der Software-Entwicklung müssen Entwicklungsergebnisse immer verifiziert und validiert werden. Dazu werden White-Box- und Black-Box-Tests verwendet.

White-Box-Test (WB-Test):
Hier haben die Tester Zugriff auf und Kenntnis über die Entwicklung der Software (Quellcode, Entwicklungsumgebung, Diagramme [UML etc.] sowie Dokumentation). Da quasi in das Programm “hineingesehen” wird, wird auch seltener vom “Glass-Box-Test” gesprochen.

1. Stufe: Dieselben Programmier, die die Software programmiert haben, führen den Test durch
2. Stufe: Andere Programmierer, welche sich jedoch in den Code hineinarbeiten, führen den Test durch

Black-Box-Test (BB-Test):
Hier haben die Tester keinen Zugriff auf und idealerweise auch keine Kenntnis über die Entwicklung der Software.

1. Stufe: Tester, welche als Kunden auftreten (echter Kunde oder nur “simulierter” Kunde) testet die Software (vor allem Funktionstests)
2. Stufe: Tester, welche Erfahrung mit Software-Tests (z. B. Penetration Tests) haben und sich in die Auftragsspezifikationen hineinarbeiten, führen den Test durch (vor allem Stresstests) (mehr…)

Mit fehlerhaften Produkten kann ein produzierendes Unternehmen unterschiedlich verfahren. In einem sorgfältig operierenden Unternehmen gibt es Prüfverfahren und dafür ausgebildete Prüfer, die fehlerhafte Produkte erkennen. Dennoch muss jeder Mitarbeiter in der Lage sein, einen (auch zufällig) gefundenen Fehler anzuzeigen.

Normgerecht muss ein dokumentiertes Verfahren zur Sicherstellung bzw. Lenkung fehlerhafter Produkte im Unternehmen eingerichtet sein. (mehr…)

Es ist eine Zertifizierung des Qualitätsmanagements für Betriebe fast aller Branchen nach der DIN EN ISO 9001 möglich.

Diese Zertifizierung bietet dem Unternehmen viele Vorteile, denn auf dem Weg zur Zertifizierung wird sich das Unternehmen selbst verbessern, nach der Zertifizierung wird das Vertrauen seitens der Kunden (und so weniger Kundenaudits) und Mitwirkenden gegenüber dem Unternehmen gestärkt. Das Unternehmen wird auf dem Weg zur Zertifizierung eine effiziente Aufbau- und Ablauforganisation einrichten.

Dem Unternehmen wird die Werbung mit dem Zertifikat ermöglicht, ist das Zertifikat eine Markteintrittsbarriere, so wird dieser Markt mit der erfolgreichen Zertifizierung erschlossen. Das Zertifikat ist somit ein echter, möglicherweise ein entscheidender Wettbewerbsvorteil.

Es ist zudem wahrscheinlich, dass das Unternehmen nach der Zertifizierung eine Kostensenkung durch verbesserte Prozesse erfährt und die Kosten langfristig mit der Zertifizierung für den Betrieb positiv beeinflusst werden. (mehr…)

Die Prüfmittel zur Produkt-/Prozesskontrolle müssen organisiert und funktionstüchtig gehalten werden, dies ist Teil des Prüfmittelmanagements. Prüfmittel sind Messinstrumente, welche überprüft, gewartet und kalibriert werden müssen, um genügend genaue Werte zuverlässig messen zu können.

Ohne ein gutes Prüfmittelmanagement kann das gesamte Eignung des Qualitätsmanagement hinfällig werden! (mehr…)