• This topic has 17 Antworten, 5 Stimmen, and was last updated vor 3 years by Peter.
3 Antworten anzeigen - 16 bis 18 (von insgesamt 18)
  • Autor
    Beiträge
  • #28006
    Peter
    Participant

    Hallo Herbert,

    Zitat von dir:

    „Wärmeabgabe ist kein Fehler sondern ein zu tolerierender Nebeneffekt, kann aber sehr Wohl auch wieder eine Randbedingung oder Anforderung für den Lampenschirm Designer sein.

    Du sagst ja selber es eine Anforderung werden kann, beachte ich diese nicht kann sogar ein Brand ausbrechen. Nun kann man zwei Wege gehen.

    1. Die Anforderung ist dem Entwickler bekannt, kein Risiko fertig (finde ich sehr Gefährlich). Da er auch nur ein Mensch ist und auch mal was vergessen kann.

    2. Ich mache eine Risikobewertung, dazu muss man sagen das nicht jede Anforderung eine Bewertung benötigt, aber wenn durch die Anforderung eine Funktion beeinflusst/verändert etc. wird muss ich diese in der Funktion der Anwendung mit betrachten, sei es als Funktion mit entsprechendem Fehler oder in einer Funktion mit der sich nun ein neuer Fehler ergibt. So erhalte ich eine gute Risikobewertung meines Systems. Ansonsten könnten Punkte durchschlüpfen.

    Idee dazu: stellen wir uns vor wir Entwickeln diese Lampe mit Lampenschirm, der Designer kennt die „Randbedingung“ das die Wärme enorm ist und ausreicht Material in Brand zu setzen, da er aber Designtechnisch die Lampe nah am Material haben muss (z.B. wegen der Design Vorgabe etc.) wählt er bewusst ein Material das schwer entflammbar ist.

    Soweit alles OK, nun 1 Jahr später geht ein anderer Einkäufer über das Produkt und sieht Material das enorm teuer ist und ersetzt das durch ein billiges Material (was auch Brennbar ist). Er bekommt Lob und schaut nicht in die FMEA.

    Habe ich in der FMEA nun die Randbedingung enthalten und oder sogar mit einem Risiko Versehen ist es Technisch wie soll ich sagen Adressiert und Dokumentiert…klar ist dies ein gestricktes und sehr simples Beispiel aber wenn man ein Elektromechanisches System hat mit Software dazu wird eine kleine „Randbedingung“ schnell zu zig Unterfunktionen in einer FMEA dies sollte man mitführen oder über die Funktion darstellen ansonsten bekommt man schnell keinen Überblick mehr und macht eine Risikobewertung die zwar Oberflächlich i.O. ist aber eben die schlimmen Fehler nicht darstellt.

    Wie schon gesagt das Thema ist schwer zu fassen und noch schwerer im Text zu Beschreiben… finde ich. Darum hat sich der VDA/AIAG Band so vermute ich hier auch schwer getan.

    Aber das P-Diagramm hilft mir die Übersicht zu Bewahren und hat mir schon oft neue Funktionen gezeigt als wir mit dem Team durch gegangen sind, denn oft sind die Fehler die wir übersehen genau die welche zu Ausfällen oder Problemen führen.

    Zudem sollte man nicht zu Strikt eine Vorgabe auslegen da man dann keinen Freiraum mehr hat.

    Wenn man durch einen kleinen Satz eine Funktion mit einbringt welche das Team und der Moderator als korrekt ansehen ist es i.O. ob es später wirklich nützlich ist sieht man bei der ehrlichen Bewertung mit den Maßnahmen.

    Fazit:

    Zu so einem Thema sollte man sich mal in einer Runde Unterhalten, Textlich ist das schwer und auch dann sehr Interpretierbar, man könnte jetzt zu meinem Beispiel oben sagen, ja aber es gibt Normen die Vorschreiben welche Entfernung zur Leuchtquelle usw. aber es soll ein simples Beispiel sein.

    APIS könnte auch bei solchen Runden dabei sein und sich das anhören wo „der Schuh zwickt“ denn nur so können sie Reagieren und evtl. das Programm anpassen.

    Trotzdem nochmals danke für die vielen Anregungen und ich sehe alleine durch die vielen Meinungen das hier eigentlich wenig Klarheit herrscht 🙂

    Gruß Peter

    #28010
    Herbert
    Participant

    Hallo Peter, Sabotage wird normalerweise in der FMEA nicht betrachtet, erwartungsgemäßer Missbrauch aber schon. Wenn z.B. das verliebte Paar ein rotes Tuch über den Lampenschirm hängt um die Stimmung zu heben :-). Das kennt man ja aus verschiedenen Love Story Filmen etc. Das es dabei zu einem Brand kommen könnte sollte man in Betracht ziehen, wenn das nicht sogar schon in Realität passiert ist. Oder zum Trocknen der frisch gewaschen Socken 🙂 . Maßnahme Lampenschirm Design verhindert einen Brand, durch ausreichenden Sicherheitsabstand oder Schutzsicherung, oder Hinweis in der Gebrauchsanleitung. Bei deinem Beispiel, der Änderung nach 1 Jahr, ist natürlich die FMEA vor der Änderung anzupassen und das durch die Änderung veränderte Risiko aufzuzeigen. Deshalb finde ich gut, wenn eine Zuordnung zu den Anforderungen, Pflichtenheft dokumentiert ist. Den Ansatz, jeder Funktion eine Anforderung unterzuordnen finde ich nicht geglückt, da z.B. in der Prozess FMEA die Anforderung Sauberkeit / Reinraum für den gesamten Prozess gilt und nicht nur bei einem Prozess. Wir missbrauchen dafür häufig die Benutzdefinierten Attribute. Wenn man die Toollandschaft betrachtet haben hier andere z.B. DOORS, etc. die Nase vorn. PS: Auch die DRBFM fokussiert die Änderung der Anforderungen bei Änderungen, also das macht schon Sinn. Mich würde mal interessieren, wer die Anforderungen von APIS zum Requirements Engineering nutzt?

    Den Vorschlag eines Workshops mit APIS zum P-Diagramm finde ich gut.

    Übrigens: Ich kenne das P-Diagramm als Hilfsmittel bei DoE und DoE kann eine Maßnahme in der FMEA sein, einen direkten Zusammenhang sehe ich immer noch nicht. Lasse mich aber gerne vom Gegenteil überzeugen. Ich halte es für ein gutes Werkzeug im benannten Kontext, siehe Taguchi.

    Durchaus komplexes Thema, deshalb hatte sich die AG auch 3 Jahre Zeit genommen, um die FMEA Community mit alten Ford Ideen neu zu verwirren. Ich antworte zu diesem Thema nun nicht mehr, denn APIS hilft unser Disput  hier auch nicht weiter.

    #28016
    Peter
    Participant

    Hallo Herbert,

    von Sabotage spreche ich nicht das ist ja selbstverständlich das wir dies nicht in einer FMEA Bewerten.

    Zu den anderen Punkten gehe ich nicht im Detail ein da dies per Text nicht eindeutig ist und viel Zeit kosten würde.

    Zum Thema P-Diagramm siehe Vortrag von Chad Johnson – P-Diagramm (2019-Vortrag in Magdeburg).

    Interessant finde ich aber die Aussage Disput von dir?

    Ein Forum ist zum Meinungsaustausch da, und ich finde das APIS sehr wohl von unserer Diskussion profitiert da sie sehen wo noch Diskussionsbedarf besteht.

    Einen Disput sehe ich hier nicht 🙂

    Ganz im Gegenteil, ich finde die vielen Ansätze Super, auch um zu sehen wie andere Vorgehen.

    Gruß Peter

3 Antworten anzeigen - 16 bis 18 (von insgesamt 18)
  • Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.