המודלים הקלאסיים של כשל בתפעול נוהגים לייחס את הכשל לטריגר, האירוע הראשון בשרשרת האירועים שהובילו לאובדן. בגישה זו, קיימת נטיה להסיט את הדיון מהמפתחים, שאיפשרו את ההסלמה, אל האדם שהיה מעורב בתפעול המכונה.

מאפיינים של רשלנות המפתח

מדריך זה מעדיף את השימוש במונח "כשל בתפעול" על פני המונח הנפוץ יותר "טעות אנוש", המייחס את האחריות לכשל למפעילים.

התחשבות במגבלות המפעיל

הנחיה - אחריות המפתח למניעת טעויות מפעיל. אין להסתפק בכך שבעקרון, המפעיל יכול לחפש ולמצוא את המידע הדרוש לפתרון הבעיה. בשעת מבחן, המפעיל אינו מסוגל לחפש את המידע הדרוש לפתרון הבעיה ביסודיות בכל בסיס הנתונים, לנתח אותו במדויק, להבין נכון את המצב ואת משמעויותיו, ולבחור בדרך הפעולה האופטימאלית.

תפקידיו של היצרן כוללים אבטחת בטיחות בתפעול ואבטחת שימושיות. באחריותו להביא את תמונת המצב אל מודעות המפעיל, ולהציג את המידע הרלבנטי באופן שהמפעיל יוכל ליישם בתהליך קבלת ההחלטות.

הנחיה - מיקוד הדיון. יש למקד את הדיון בתכן שאיפשר את מצב הכשל.

אין להטיל את האחריות לכשל על המפעיל או המשתמשים.

 במקום זאת, יש להשקיע את המשאבים במניעת הכשל הבא.

דוגמאות ישום

• יש להבחין בין פתרון בו המכונה מספקת למפעיל מידע לגבי מצבה, לבין פתרון בו מובטח שהמפעיל אכן מודע למצב המכונה. לדוגמא, מערכת TMI סיפקה למפעילים מידע לגבי מצבה, אבל המפעיל לא הצליח על בסיס מידע זה לאבחן את מצב המערכת (אירוע כשל מספר 17: התאונה בתחנת הכח הגרעינית TMI).

• יש להבחין בין פתרון בו המכונה מאפשרת למפעיל גישה לפונקציה הדרושה בשעת חירום, לבין פתרון בו מובטח שהמפעיל ידע לחפש ולמצוא את דרך הגישה לפונקציה הנדרשת. לדוגמא, קריסת מערכת החשמל ב-NYC בשנת 1977 התאפשרה בין השאר מכיוון שהמפעיל לא הצליח למצוא את הפקד שנדרש כדי לבצע את פעולת ניהול העומס.