 |
|
Sortieren nach:
Datum - neue zuerst |
Datum - alte zuerst |
Bewertung
|
|
|
In den zitierten Textstellen sieht man auch sehr schön den Unterschied zwischen "Shall" und "Should" der von Manchen nicht erkannt wird.
Wenn im OM-A einer Airline steht, dass nach Rückfrage mit dem Lotsen eine rote Stopbar überquert werden darf dann ist das auch so genehmigt, wenn das OM-A diesen Passus nicht aufweist wird es eben nicht gemacht.
Im Übrigen muss ein Stopbar nicht unbedingt defekt sein um kurzzeitig nicht abgeschaltet werden zu können sondern es gibt auch Logikschaltungen, bei denen zwei Stopbars an verschiedenen intersections nicht innerhalb eines bestimmten Zeitfensters geichzeitig deaktiviert werden können, ein gleichzeitiger Lineup aber trotzdem praktikabel sein kann und daher durchgeführt wird (idealerweise erklärt der Lotse das dann kurz)....
|
|
|
|
|
Der Unterschied in der Bedeutung zwischen "shall" und "should" ist zu gering und m.E. irrelevant, vor allem in einem Text, bei dem es auf Eindeutigkeit ankommt. Tatsächlich ist der Unterschied in der Praxis nicht vorhanden – und auch praktisch keinem Muttersprachler überhaupt ein Begriff!.
Den Rest kann icht nicht beurteilen ;-)
|
|
|
|
|
Echt? Gerade in Texten zu Normen oder Standards wird shall (mandatory requirement, synonym zu "must") von should (requirement, deviation permissible) unterschieden. Ist das nur Rechtsanwälten des englischen Sprachraums geläufig?
|
|
|
|
|
Shall/should ist absoluter Standard in englischsprachigen Regeltexten. Oft wird es zu Beginn auch noch explizit erklärt.
|
|
|
|
|
Da ist es für eine deutsche Behörde doch wesentlich einfacher mit deutschen Regelungen umzugehen, nämlich "soll heißt muss wenn kann" :-)
|
|
|
|
|
"wollen hätten wir schon können, aber dürfen ham wir uns nicht 'traut!"
|
|
|
|
|
"Wenn im OM-A einer Airline steht, dass nach Rückfrage mit dem Lotsen eine rote Stopbar überquert werden darf dann ist das auch so genehmigt, wenn das OM-A diesen Passus nicht aufweist wird es eben nicht gemacht."
Entscheidender, als das was im OM (was ich im privaten Bereich ohnehin nicht habe) steht, wäre für mich, um eine eingeschaltete Stopbar zu überqueren, dass der Lotse mich, d.h. das Flugzeug, zweifelsfrei an genau dieser Position erkennen (sehen) kann und mir dann erklärt, warum ich trotz "Rot" kreuzen darf. Der Sinn der Stopbars ist m.E. doch in erster Linie, dass bei "low-visbility" die Gefahr einer Verwechselung des aktuellen Standortes verhindert werden soll. Wenn wir z.B. beide glauben, dass ich auf "A" stehe, tatsächlich aber auf "B" bin, und der Lotse ein Kreuzen in "A" erlaubt und dort auch die Stopbar ausschaltet, bleibt sie für mich in "B" natürlich an und ich kreuze nicht!
Bei dem katastrophalen Unfall in Mailand 2001 (C525/MD87) z.B. vermutete der Lotse die C525, die er nicht sehen konnte, an einer ganz anderen Stelle (R5, heute N), als sie tatsächlich war (R6, heute K) - und die Crew der C525 sich selbst auch! Hätte er dort eine funktionierende Stopbar ausgeschaltet, hätte eine solche an der Postition der C525 weiter geleuchtet. So kann es Leben retten, wenn ich bei "Rot", trotz mündlicher Freigabe, erst mal stehenbleibe, bis die Situation für alle vollständig geklärt ist.
|
|
|
|
|
Beispiel einer "Should / Shall" Definition aus einem englischen technischen Regelwerk
-
Should rules are advisory rules. They strongly suggest the recommended way of doing things.
-
Shall rules are mandatory requirements. They must be followed and they require verification (either automatic or manual).
VG Mark
|
|
|
|
|
Ich glaube diese Diskussion gab es hier schon einmal, dass "should" trotzdem mit "mandatory" gleichgesetzt und mit "shall" verwechselt wird überrascht mich jetzt.
|
|
|
|
|
@Willi, genau dieser Fall in Mailand/Linate fiel mir sofort ein. ich habe da einen Fliegerfreund (Martin S. aus Reichelsheim) verloren. Er saß vorn in der C525....
|
|
|
|
|
Ok,
ich kannte im Zusammenhang mit Flugzeug-Wartung nur die Thematik mit "recommended", das vom LBA gern als MUSS ausgelegt wird. Interessanterweise sind die Engländer noch bornierter und verlangen bei "recommended" items laut Cirrus-Checkliste oft den Austausch/die Überholung.
|
|
|
|
|
Ich kenn zu den Worten Must, Shall, Recommended,... eine sehr präzise Definition, die auch hier trifft:
https://tools.ietf.org/html/rfc2119
Merke: Auch in anderen Bereichen als der Fliegerei gab es die Diskussion. Nur hat man sich bei der IETF dann vor mittlerweile 20 Jahren auf diese Definition geeinigt, damit allen (auch denjenigen, die Englisch nicht als Muttersprache nutzen) die Lage bei den Spezifikationen klar ist.
Olaf
|
|
|
|
|
Ich liebe die präzisen Formulierungen in Internet RFCs. Zählt zu meiner Frühstückslektüre.
|
|
|
|
|
Yep,
mein lieblings-RFC ist der mit "Internet Protocol over aviation carriers". Warum der aber von einem 1.4. stammt ... ;-)
Olaf
|
|
|
|
|
|
|
|
|
|
So ein typischer SAP Consultant würde jetzt sagen: "SAP can do this" ;-)
Irgendwie habe ich dieses immer als Lautmalerei in meinem Gedächtnis wenn ich an eine ganz besondere Firma denke, die für einen Millionenbetrag zuerst SAP ausgerollt hat, ein halbes Jahr keine EDI Protokolle auswerten konnte und fast von den Banken den Gnadenschuß erhalten hätte. Nur um dann, als SAP endlich so einigermaßen lief zu Microsoft Navision in der Cloud zu wechseln... auf die nächsten verbrannten Millionen. Daß die Mitarbeiter weiterhin alles in Excel machen kann man da schon fast als Qualitätsmerkmal betrachten. Bestes Beispiel wie einige Wenige (GF) mit der Verantwortung und wirtschaftlichen Existenz von vielen andern (Angestellten) umgehen. Ob hier Checkisten auch helfen könnten?
|
|
|
|
|
|
|
|
|
|
Daß die Mitarbeiter weiterhin alles in Excel machen kann man da schon fast als Qualitätsmerkmal betrachten. Bestes Beispiel wie einige Wenige (GF) mit der Verantwortung und wirtschaftlichen Existenz von vielen andern (Angestellten) umgehen. Ob hier Checkisten auch helfen könnten?
...mhmm, klar, weil die "Wenigen (GF)" natürlich alles Armleuchter sind. Als GF mit Verantwortung für eine IT-Abteilung habe ich Checklisten im Rahmen eines vernünftigen Change Management eingeführt, weil das einfach ein sehr effektiver und effizienter Ansatz ist, IT-Projekte, die ich in technischer Hinsicht nicht durchdringen kann, auf ihre Auswirkungen hin zu kontrollieren. Punkt 1 auf der Checkliste ist: Macht das meine Dienstleistung für den Kunden besser? Da kann man schon mal ganz viel wegstreichen und mir scheint das eine Frage zu sein, die relativ selten gestellt wird.
Hinsichtlich der vorgebrachten Argumente aus der Ärzteschaft, dass Checklisten letztlich nicht adäquat seien, weil die Menschen zu verschieden sind und der Einsatz von Checklisten zum Ausschalten des Gehirns führt - diesen Vorwand höre ich auch oft von Piloten. "Nein, ich gehe das lieber alles bewusst durch" oder hinsichtlich Notfallchecklisten: "Nein, Notfälle sind so verschieden, besser man löst das mit einem wachen Geist" - ich halte diese Einwände für schwach. Ich stimme zu, Checklisten sind keine to do Listen. Wenn man sie nicht als solche einsetzt, ist die Gefahr, dass sie von unserem Kopf als Bedienungsanleitungen missverstanden werden, relativ gering.
Wer regelmäßig checklisten (auf Papier oder aus dem Kopf) einsetzt, wird feststellen, wie oft ein item überraschenderweise noch offen war.
Wenn man den o.g. Artikel noch einmal in Ruhe anschaut - da geht es ja um ganz konkrete statistisch nachweisbare Auswirkungen durch den Einsatz von Checklisten. Und die zeigen, dass sie den Operationssaal im Durchschnitt sicherer machen.
Ich glaube auch, dass solche breiten Studien der einzige Weg sind, die Diskussion um Checklisten zu entscheiden, ansonsten lassen sich immer Fälle konstruieren, in denen der Gebrauch einer Checkliste kontraproduktiv ist. Es geht aber nicht um den sehr spezifischen Einzelfall, sondern um Breitenwirkung.
|
|
|
|
|
Bei mir haben alle bisherigen checklisten immer einen Wandel durchlaufen....Sie veränderten sich von einer Do-liste mit der Zeit, am Anfang meiner Fliegerkarriere langsamer, heute sehr schnell, zu Check-listen im wahren Sinn des Wortes....ich ziehe das bis heute mit Papier durch, elektronisches Tool bisher nicht vorhanden...so habej aber Checklisten auch den Weg ins Berufsleben gefunden...vor allem in der Projektabwicklung....gut finde ich eine short-checklist in der nähe zu haben für krasse Notfälle....so wie das bei manchen Typen auf dem Steuerhorn zu finden ist...
Gruss
|
|
|
|
|
Das ist eben auch der Punkt: Es gibt Do-Listen und es gibt CHECK-Listen. So habe ich das jedenfalls während meines IFR-Trainings gelernt. Niemand, der sich mal mit der Theorie der Checklisten beschäftigt hat wird jede Checkliste als "Do List" ausführen. Geht in vielen Flugsituationen auch gar nicht.
Meine Lösung (ein bißchen Werbung ;-)) war die Entwicklung der App smartCHECK, die mir die Checklisten vorliest!
|
|
|
|
|
Ich gehe die items durch (Ausführung) und checke anschliessend auf Vollständigkeit per Liste sobald möglich..in entspannten Situationen eher sofort, je nach Bedarf und Situation auch später...ist ein (kompetenter) Gast an Board, lasse ich mir checklisten auch vorlesen...
Allerdings ein guter Zeitpunkt sich mit checklisten mal wesentlich intensiver zu beschäftigen...
Frage der Definition: habe ich einen pilot monitoring und dieser liest mir die items vor und ich prüfe entsprechend, ist es dann eine Do- oder eine Checkliste?
Gute Nacht
|
|
|
|
|
In meiner Fliegerwelt gibt es "Do"- und "Follow Up"-Checklisten. Do-Checklisten arbeite ich Punkt für Punkt ab, z.B. die Takeoff-Checklist. Mit einer FollowUp-Checkliste prüfe ich nachträglich, ob ich bestimmte Punkte korrekt aus dem Kopf abgearbeitet habe, z.B. die AfterTakeOff-Checklist.
Beide Arten von Checklisten kann Dir Dein Co vorlesen, es hängt von Deinem Vorgehen ab, ob es eine Do"- oder "Follow Up"-Checkliste ist.
Grüsse, Thomas
|
|
|
|
|
|
22 Beiträge Seite 1 von 1
|
|
|
|
|
|
|
|
|
|
