המודלים הקלאסיים של כשל בתפעול נוהגים לייחס
את הכשל לטריגר, האירוע הראשון בשרשרת האירועים שהובילו לאובדן. בגישה זו,
קיימת נטיה להסיט את הדיון מהמפתחים, שאיפשרו את ההסלמה, אל האדם שהיה
מעורב בתפעול המכונה.
יש למקד את הדיון בתכן שאיפשר את מצב הכשל.
מאפיינים של רשלנות
המפתח
מדריך זה משתמש במונח "כשל בתפעול" במקום המונח הנפוץ יותר "טעות אנוש", המייחס למפעילים את האחריות
לכשל.
אין להסתפק בכך שבעקרון,
המפעיל יכול לחפש ולמצוא את המידע הדרוש לפתרון הבעיה. בשעת מבחן, המפעיל
אינו מסוגל לחפש את המידע הדרוש לפתרון הבעיה ביסודיות בכל בסיס הנתונים,
לנתח אותו במדויק, להבין נכון את המצב ואת משמעויותיו, ולבחור בדרך הפעולה
האופטימאלית.
אין להטיל את
האחריות לכשל על המפעיל או המשתמשים. במקום זאת, יש להשקיע את המשאבים
במניעת הכשל הבא.
מתפקידיו של היצרן להביא את תמונת המצב אל מודעות המפעיל,
ולהציג את המידע הרלבנטי באופן שהמפעיל יוכל ליישם בתהליך קבלת ההחלטות.
דוגמאות ישום
-
יש להבחין בין פתרון בו המכונה מספקת
למפעיל מידע לגבי מצבה, לבין פתרון בו מובטח שהמפעיל אכן מודע למצב
המכונה. לדוגמא, מערכת
TMI
סיפקה למפעילים מידע לגבי מצבה, אבל המפעיל לא הצליח על בסיס מידע זה
לאבחן את מצב המערכת (אירוע כשל
מספר 17: התאונה בתחנת הכח הגרעינית TMI).
-
יש להבחין בין פתרון בו המכונה מאפשרת
למפעיל גישה לפונקציה הדרושה בשעת חירום, לבין פתרון בו מובטח שהמפעיל
ידע לחפש ולמצוא את דרך הגישה לפונקציה הנדרשת. לדוגמא, קריסת מערכת
החשמל ב-NYC
בשנת 1977 התאפשרה בין השאר מכיוון שהמפעיל לא הצליח למצוא את הפקד
שנדרש כדי לבצע את פעולת ניהול העומס.
|