Hat von euch noch jemand den Eindruck? Irgendwie finde ich das absolut unproduktiv. Zugegebenermaßen nicht völlig unproduktiv, aber wenn ich die Stunden ansehe die da mit 5 Leuten am Tisch verbracht werden, dann glaube ich dass man die Zeit wesentlich effektiver nutzen könnte als mit so einer dämlichen FMEA...
Fehlermöglichkeits- und Einflussanalyse. http://de.wikipedia.org/wiki/FMEA Bei uns für jedes Projekt vorgeschrieben. Daraus sollte dann das Lastenheft hervorgehen. Dabei hat kein Mensch Zeit erstmal vor nem Projekt wochenlang mit so nem Mist rumzumachen, wo man noch nichtmal überschauen kann was denn im Produkt drin sein wird, und somit kann man auch nicht wirklich gute Aussagen treffen woran es scheitern könnte. Aber wenn die das so wollen geb ich mein bestes :-)
Also ich mach gerne mal eine FMEA wenn ich nen Schaltplan fertig habe. Das "Murphy's Law Brainstroming" hilft um spätere Risiken zu minimieren. Die Zeit ist an der Stelle gut investiert im Verhältnis zu dem, was man später reinbuttern müsste umd noch etwas zu beheben...
Die Zeit, die man in eine FMEA steckt bekommt man vervielfacht wieder zurück. Wichtig ist nur, diese in einem recht frühen Stadium durchzuführen. Wir machen Sie mit einem Moderator der Firma MOC**.
Bei der FMEA gehts anscheinend überwiegend um Hardware, auch wenn im Wiki auch was von Software-FMEA steht. Das scheint mir zum Thema zu passen, da meine Softwarekollegen neuerdings "Poker spielen": http://www.scolab.ch/the-agile-way-of-collaboration.html http://de.wikipedia.org/wiki/Agile_Softwareentwicklung#Kritische_Betrachtung "Es ist umstritten, ob der Entstehungsprozess von Software so gut verstanden wird, dass eine planmäßige Herstellung möglich ist" Ähnliches würde ich auch zur Hardwareentwicklung sagen, Murphys Gesetz lauert überall. Kann so ein Team aus vielen Abteilungen mehr Fehler im Voraus finden, als der Einzelne, der sich in seinem Anteil wirklich auskennt? Eher reden die paar Leute, die zu allem immer etwas zu sagen haben, und der Rest nickt dazu. Oder es reden zwei miteinander über ein Detailproblem und der Rest langweilt sich.
> auch wenn im Wiki auch was von Software-FMEA steht. ne FMEA kann man auch über Software machen. Macht man aber nicht: Weil es für Software bessere Methoden gibt. >Kann so ein Team aus vielen Abteilungen mehr Fehler im Voraus finden, als der Einzelne, der sich in seinem Anteil wirklich auskennt? Es ist nicht das Team, das die Schwachstellen findet. Es ist das systematische Vorgehen bei einer FMEA. >Oder es reden zwei miteinander über ein Detailproblem und der Rest langweilt sich. Deswegen gibt es den Moderator. Der lässt Diskussionen über Detail kurzzeitig zu und sorgt dann dafür, dass man wieder vorankommt. Es gibt gute und schlechte FMEAs. Es liegt zu 50% am Moderator, zu 50% am Team. Ich könnte nen guten empfehlen.
also ich habe bisher auch nur Schrott-FMEA's mitgemacht, muss aber nicht heißen, das es auch besser geht. Was nützt mir eine FMEA noch, wenn ich schon meinen 2. oder 3. Hardwarestand auf dem Tisch habe. Dann wird die FMEA nur noch durchgeführt, um den Prozessschritt einzuhalten und in die nächste Entwicklungssphase übergehen zu können.
Eine FMEA ist nur so gut, wie die Leute die daran teilnehmen. (bzw. deren Einstellung zum Thema) Habe auch schon gute und schlechte FMEAs miterlebt.Bie uns sind sie wegen der ISO61508 compliance unerlässlich und haben bereits öfters Handlungsbedarf aufgezeigt, der von einer einzelnen Person nicht enteckt worden währe. just my 0.02€
Solcher Prozess-Krempel wird zunehmend gern in Firmen gemacht, um die Risiken bei Projekten zu minimieren. Insbesondere dort, wo man nicht begriffen hat, dass der schleichende Abbau von interner Fachkompetenz mit solchen Krücken nicht kompensiert werden kann. An manchen Stellen forciert man das sogar: Fachkompetenz wird immer unwichtiger, Entwicklungskosten für Vorentwicklungsprojekte kann man sich sparen - man hat ja jetzt entsprechende Prozesse. Das Schöne daran ist, dass man viele Leute damit auf völlig unproduktive Weise beschäftigen kann und beim Platzen des Projektes oft die Schuld nicht eindeutig zuordnen kann. Und das Management fühlt sich sicherer, denn man hat ja jetzt Prozesse, die man versteht und ist unabhängig(er) von technischen Kompetenzen, die man schlecht einschätzen kann. Zur eigentlichen Frage: Vernünftig benutzt, sind solche Werkzeuge durchaus sinnvoll. In der Regel werden sie aber missbraucht (siehe oben) oder verstärken noch Bürokratie und senken drastisch die Produktivität. Ich habe schon Projekte gesehen, bei denen vielleicht 10% der Entwickler wirklich noch entwickelt haben und der Rest hat sich gegenseitig mit Prozessen und Abstimmungsgesprächen blockiert...
Wie der Vorredner denke ich auch das es eben nur ein Tool ist welches eine gewisse systematik einbringt und eben vom Management verstanden wird... mehr aber auch nicht... Es ersetzt eben nicht Kompetenzen und Erfahrungen... Habe jedoch schon erlebt das "der" Entwickler einfach Designblind geworden ist und einfach einen Bock oder auch mehrere Boecke eingebaut hat ... aber da hilft vieleicht eher ein Design Review mit mehrerern Leuten... Viel Spass noch bei der FMEA...
richtig Design Review find ich gut und hilfreich. Der Witz bei unseren FMEA's ist, da gibt es ein "schönes", spezielles Tool. Dort wird eingetragen der vermeitliche Fehler und die Abstellmaßname. Und dann kommt der Witz, dann werden Punkte vergeben, wie hoch das Risiko der Eintrittswahrscheinlichkeit ist. Das wird aber immer so geschätzt, gewürfelt, geraten oder was auch immer, dass die Gesamtpunktzahl ausreicht um weiter zu kommen.
Wenn Du hier bereits einen Fehler findest, findet ihn schonmal der Kunde nicht. DAs spart richtig Geld, Nerven und Ansehen beim Kunden
Also die Erfahrung zeigt dass wenn man verifizierte Hardware-Komponenten/Design parts verwendet dann ist das Risiko recht klein und FMEA ist dann überflüssig. Die meisten Firmen haben nur dicke Ordner damit angelegt, Haufen Stunden vertrödelt und sein lassen weil es einfach ineffizient ist. Ich kann mir schon bestimmte Bereiche vorstellen wo dieses Verfahren wichtig wäre, aber in den meisten Fällen sind es motivierte und erfahrene Mitarbeiter die mögliche Fehler gut voraussehen können.
Michael S. schrieb: > Ich habe schon Projekte gesehen, bei denen vielleicht 10% der Entwickler > wirklich noch entwickelt haben und der Rest hat sich gegenseitig mit > Prozessen und Abstimmungsgesprächen blockiert... Wahre Worte. Die 10% sollten sich dann aber dringend intensiv mit der FMEA beschäftigen, um "den bösen Prozess" zu besänftigen. Denn entwickelt wird ohnehin in China.
Viele Leute, die per Anweisung durch Chef sich mit FMEA von heute auf morgen befassen sollen, haben zunächst nur die Abkürzung übersetzt, aber den tieferen Sinn und die Methodik der FMEA bei weitem nicht verstanden und schon gar verinnerlicht. Eine FMEA, für HW und SW halte ich für dringend erforderlich, um so möglichen Ursachen für kurz- oder langfristige Ausfallrisiken in Entwicklungs- und Fertigungsprozessen, einschließlich der Servitierung des Produktes über die Lebenszeit beim Kundendienst, schon früh zu begegnen. Stichwort: Kritikalität und Sicherheitsrelevanz. Wer möchte schon seine ausgelieferte Teile mit kurz- oder langfristigen Ausfällen wieder reinkommen sehen? Oder Anschlussaufträge, die zum Konkurrenten gehen weil die Qualität nicht stimmt? Da muss man schon vorher aus eigenem Antrieb und/oder durch Kundenforderung die nötigen Schritte tun und die Grundlagen möglicher Ausfallrisiken schaffen. Ein gutes QM-System und eine gute FMEA sind notwendige Schritte in dieser Richtung - und machen sich auf Dauer bezahlt, wenn sie denn auch von der GF ernst genommen werden. Wenn Kunden die FMEA fordern, dann muss die eigene erarbeitete FMEA in das Kunden-FMEA-Konstrukt nahtlos passen, um akzeptiert zu werden. Auch hier ist natürlich ein Dialog zwischen den Fachleuten des Kunden und des Auftragnehmers erfordlich, um am Ende eine formale und nachprüfbare Akzeptanz zu erhalten. Rausmogeln oder Schlamperei geht hier nicht...
Da ne kurze Geschichte der FMEA: https://www.kvp.de/allgemein/kurzuebersicht-eine-kurze-geschichte-der-fmea/ Erfunden hats die NASA, klar die wollen wissen wo ihre Rakete explodieren Könnte, bevor sie explodiert - damit man ne Chance hat die Explosion konstruktiv zu verhindern. Leider hacken auch bei der NASA manche darauf rum, das es unnötiger Papierkram ist -> bis ein Space Shuttle explodiert, weil einer nicht glauben wollte das Dichtungsringe bei Frost an Elastizität verlieren und so eine fatale Ereigniskette möglich machen ... https://de.wikipedia.org/wiki/STS-51-L#Weitere_Ergebnisse_der_Ungl%C3%BCcks-Untersuchungen
In unserer Runde fragte der FMEA-Moderator allen Ernstes, was denn im Falle eine Erdbebens mit dem zu entwickelnden Gerät (Industrieautomatisierung) passieren würde, es würde dann doch kaputtgehen... Wenn man sonst keine Sorgen hat.
Beitrag #6615005 wurde von einem Moderator gelöscht.
Markus schrieb: > In unserer Runde fragte der FMEA-Moderator allen Ernstes, was denn im > Falle eine Erdbebens mit dem zu entwickelnden Gerät > (Industrieautomatisierung) passieren würde, es würde dann doch > kaputtgehen... Wenn man sonst keine Sorgen hat. In Japan hat man diese Sorgen aber. Da baut man auch schon mal Züge so, das sie auch bei der bei einem Erdbeben zu erwarteten Stromausfall manövrierbar bleiben: https://www.stern.de/reise/fernreisen/japan--erster-erdbebensicherer-zug-nimmt-den-betrieb-auf-9327404.html
Beitrag #6615144 wurde von einem Moderator gelöscht.
Christoph db1uq K. schrieb: > Eher reden die paar Leute, die zu allem immer etwas zu sagen haben, und > der Rest nickt dazu. Oder es reden zwei miteinander über ein > Detailproblem und der Rest langweilt sich. 1. Da wurde, wie leider oft, die idealerweise heterogene Gruppe für diese FMEA-Workshop-Sitzing falsch ausgesucht. Scheinbar sitzen zwei Universalgelehrte, der Moderator und 5 Zuhörer im (virtuellen) Raum. Wie wäre es, die Zuhörer durch kompetente Leute, die überschneidende Fachkenntnisse haben, zu ersetzen? Außerdem muss man auch nicht bei jeder Sitzung alle dabei haben. Man muss nicht in jedem Termin alle Disziplinen am Tisch sitzen haben. 2. Dann wird das Heterogene-Gruppe-Prinzip von einzelnen Leuten falsch verstanden. "Da reden immer nur 2 Leute, die vom aktuellen Diskussionspunkt was verstehen." Ja so funktioniert das. Jede für den jeweiligen Termin nötige fachliche Disziplin muss in 2 Leuten vertreten sein. Klar dass dann nur die beiden diskutieren. 3. Bestätigung mit Reviews. Lass mich raten, ihr unterzieht die entstandene FMEA dann einem Review im Inspektion-Stil. Da stimme ich dir zu, wenn man das so macht ist es Zeitverschwendung. Das Dokument, die FMEA, wurde jederzeit bereits durch mehrere Leute und immer Leute der benötigten Kompetenzen erstellt. Es wird also bei Erstellung bereits implizit gereviewed. Jemand schrieb in irgendeinem Beitrag: > Fast immer kommt bei uns in den FMEA-Runden das raus was man eh schon > wusste Ist doch gut, dass ihr Erfahrung habt und selber denken könnt und ich meine das auch so. Das alles, "was man eh schon wusste", kann ja in der FMEA dokumentiert werden. Oder ist das nicht nötig, da zuwenig Risiken auf euren Produkten lasten? Beim Thema Produkthaftung ist man übrigens notfalls als Einzelperson dran... Übrigens, bei modularer Entwicklung (Baukasten) kann man gerne die Dokumentation genau so modular mit in die Produkte, die die Baukastenteile einsetzen, weitergeben. mfg mf Edit: Bezug auf gelöschten Post entfernt
:
Bearbeitet durch User
Überaus interessant wenn einen seine eigenen Aussagen online fast 12 Jahre später wieder einholen :-) Das sieht so aus als wäre ich von einem damaligen Projekt ziemlich genervt gewesen. Mittlerweile sehe ich das sehr viel differenzierter. Vielleicht auch weil sich die Methodik weiter entwickelt hat, oder auch weil diese mittlerweile besser verstanden und umgesetzt wird. Die Frage von damals würde heute so auf jeden Fall nicht mehr stellen. Einige Leute hier haben es ja sehr schön beschrieben worin die Vorzüge liegen, wenn man sie richtig anwendet. Das war bestimmt damals nicht anders, wird aber aus meiner Sicht bei Projekten mit denen ich jetzt zu tun habe sehr viel besser umgesetzt.
Vielen Dank, dass du nach so langer Zeit noch einmal die "Hosen runterlässt" und ein Fazit ziehst. Denn der Originalpost und das Fazit decken sich durchaus mit meiner Wahrnehmung. Die FMEA steht und fällt damit, wie die beteiligten Personen sie durchführen. Die Nützlichkeit der FMEA reicht dann von völlig nutzlos bis: "ach, da hat ja noch keiner dran gedacht. Da müssen wir was tun."
MiWan schrieb: > Die FMEA steht und fällt damit, wie die beteiligten > Personen sie durchführen. Everything is easy with the right tool. But a fool with tool is still a fool.
FMEA zerlegt einen komplexen Sachverhalt in viele überschaubare Teilaspekte, die dann einzeln betrachtet, bewertet und gleichzeitig dokumentiert werden. Es ist somit das ideale Werkzeug um Menschen "abzuholen", deren techn. Begabung beschissen ist oder die keine Zeit oder Lust haben selbst zu denken und daher alles vorgekaut brauchen.
David schrieb: > Es ist somit das ideale Werkzeug um Menschen "abzuholen", deren techn. > Begabung beschissen ist Es kann halt nicht jeder hochbegabt sein.
Um was für eine FMEA geht es? Prozess? Ist relativ einfach, einfach Bauteil für Bauteil durchgehen z.B. Schraube: Vergessen? Falsche Schraube? Falsches Drehmoment? ==> Da ist übermässige Intelligenz nicht so wichtig. Design? Schon schwieriger, weil der Entwickler wird schon keine absichtlichen Fehler eingebaut haben, und was Ihm als mögliche (Design-)Fehler eingefallen sind, wird er vorher überprüft haben. Spannend sind ja die möglichen Fehler, an die noch keiner gedacht hat. Da braucht es einen guten Moderator, um mit gezielten Fragen Schwachstellen aufzudecken. Software (gehört zu Design): spannend.
>FMEA = unsinnige Zeitvernichtung?
Nein. Wenn Du das aber schon in Frage stellt, ist vermutlich euer
Moderator schlecht.
Beitrag #6615499 wurde von einem Moderator gelöscht.
Stephan S. schrieb: > Dabei hat kein Mensch Zeit erstmal vor nem > Projekt wochenlang mit so nem Mist rumzumachen, wo man noch nichtmal > überschauen kann was denn im Produkt drin sein wird, und somit kann man > auch nicht wirklich gute Aussagen treffen woran es scheitern könnte. > Aber wenn die das so wollen geb ich mein bestes :-) Dann hast Du doch das erste, sehr kritische Problem / Risiko erkannt: Die Anforderungen sind noch unklar! Was würdest Du den jetzt lieber machen? Mit der Umsetzung beginnen? ;-)
Beitrag #6615575 wurde von einem Moderator gelöscht.
Stephan S. schrieb: > Hat von euch noch jemand den Eindruck? Irgendwie finde ich das > absolut > unproduktiv. Zugegebenermaßen nicht völlig unproduktiv, aber wenn ich > die Stunden ansehe die da mit 5 Leuten am Tisch verbracht werden, dann > glaube ich dass man die Zeit wesentlich effektiver nutzen könnte als mit > so einer dämlichen FMEA... Für dämliche Leute ja...
Irgendwie sind alle Beiträge im Tenor "hat keinen Nutzen" fast 12 Jahre alt. Es gibt keinen Grund, dagegenzuhalten.
Eine richtig gemachte FMEA ist sehr sinnvoll, jeder dort entdeckte Klopper spart später richtig Ärger, auch wenn es später niemand danken wird, denn: there is no glory in prevention. Die Detaildiskussionen zu denen nur 2 oder 3 Leute etwas beitragen können, muss man dann in Splinter-Meetings auslagern. Das ist Sache des Moderators und das verstehen auch alle Teilnehmer, die am Erfolg wirklich interessiert sind. Markus schrieb: > In unserer Runde fragte der FMEA-Moderator allen Ernstes, was denn im > Falle eine Erdbebens mit dem zu entwickelnden Gerät > (Industrieautomatisierung) passieren würde, es würde dann doch > kaputtgehen... Wenn man sonst keine Sorgen hat. Ich habe schon ganze Schaltanlagen auf dem Shaker gesehen. Es gibt Dinge, die sollten auch nach einem Erdbeben noch funktionieren, und da ist es dann auch richtig dieses vor der Installation zu testen.
Nachtrag: Hier das Video einer Kühlanlage beim Erdbebentest: https://www.esa.int/ESA_Multimedia/Videos/2018/05/Earthquake-strength_testing
FMEAs sollte man nicht verteufeln. Es ist eine Methode die einem hilft systematisch nochmal alles zu überprüfen. Leitete vor kurzem als Moderator eine FMEA. Frage der genervten Entwickler: für was soll das gut sein? Wir entwickeln schließlich nicht dass erste Mal ein XYZ Gerät. 1Stunde später hatten wir 2 kritische Designfehler entdeckt... Dass Problem an Entwicklung sind oft wir Ingenieure. Glauben immer wir sind die besten und machen keine Fehler...
Walter T. schrieb: > Irgendwie sind alle Beiträge im Tenor "hat keinen Nutzen" fast 12 Jahre > alt. Es gibt keinen Grund, dagegenzuhalten. Hat dir das dein Moderator im letzten Kaizen GoDo gesagt? Deine Schlussfolgerung ist allerdings verfrüht. Mach erst mal eine 5-Why Analyse und dann einen 8D-Report. Vorher kann man da gar nichts mit Sicherheit sagen.
Beitrag #6619042 wurde von einem Moderator gelöscht.
Cyblord -. schrieb: > Hat dir das dein Moderator im letzten Kaizen GoDo gesagt? Nein. Das Datum an den Beiträgen
A. S. schrieb: > Cyblord -. schrieb: >> Hat dir das dein Moderator im letzten Kaizen GoDo gesagt? > > Nein. Das Datum an den Beiträgen Na du bist ja ein ganz ausgeschlafener Bursche was? Aber dich kriegen wir auch noch Lean.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.