הנדסת אנוש וחוויית הפעלת משתמש מערכת בפיתוח מערכות אמל"ח צבאיות

מפעיל מערכת אמל"ח מבצעית בזרוע היבשה. המטרה של FTUX היא לאפשר בזמן אמת (שגרה, מב"מ וחירום) את הצלחת המשימה על־ידי המפעיל המבצעי באמצעות "הקלה טכנולוגית"

זרועות הצבא השונות, משרד הביטחון (מפא"ת ומנה"ר) והתעשיות הביטחוניות מפתחות מערכות אמל"ח טכנולוגיות עבור מערכי הפעלת הכוח השונים במערכת הביטחונית, וכמו כן מערכות תומכות, ניהוליות, ממדלות ומחקריות עבור מערכי בניין הכוח. תהליך פיתוח אמל"ח מוסדר בנוהלי פיתוח, ייזום והצטיידות שונים אך דומים דיים בזרועות השונות. בתהליך אפיון ופיתוח מערכות אמל"ח מושקעים משאבים רבים המיועדים לתכולות העבודה השונות, ובהם: אפיון טכני, הנדסת מערכת, ניהול פרויקטלי, כתיבת דוחות, סקרי דרישות וסקרי תכן, פיתוח, בדיקות, רכש, קבלני משנה, מחקרים מלווים, אינטגרציה, ניסויים, הטמעה, התקנת מערכות בשטח ובקרה ניהולית. רכיב הנדסת האנוש בכלל, ובתוכו רכיב האפיון לטובת FTUX ׁׁׁ- First Time User Experience בפרט, מהווה לרוב רכיב שולי עד מזערי מהעוגה התקציבית של הפרויקט. במאמר זה אנסה להוכיח כי יש לעבות את רכיב ה־FTUX כחלק מרכיב הנדסת האנוש בתהליך הפרויקטלי ובמשאבי הפרויקט, לטובת טיוב הפעלת האמל"ח והמפעילים המבצעיים עצמם.

עקרון FTUX מגלם את היכולת של מפעיל מערכת מבצעי או טכנו־מבצעי להפעיל מערכת אמל"ח/אמסל"ח (אמצעי סיוע ללחימה) בפעם הראשונה, או "כמו ראשונה" (לדוגמה, לאחר היעדרות ממושכת או הפסקת פעילות מכל סיבה שהיא), באופן מספק, שיאפשר למסגרת לעמוד במשימתה תוך הימנעות מכישלון בהפעלת המערכת. יכולת זאת נגזרת מאפיון, מפיתוח וממימוש מערכת האמל"ח/אמסל"ח באופן שינגיש תחושת מוּכרות למפעיל המבצעי בכל פעם שהוא ניגש להפעלת המערכת בכלל, ובפעם הראשונה שהוא מפעיל אותה בפרט. המטרה של FTUX היא לאפשר בזמן אמת (שגרה, מב"מ וחירום) את הצלחת המשימה על־ידי המפעיל המבצעי באמצעות "הקלה טכנולוגית". כיום בצה"ל ובמערכת הביטחונית הדגש הוא על התאמת המפעילים למערכות האמל"ח - המפעילים המבצעיים מאותרים, ממוינים ומוכשרים לפי יכולותיהם האישיות ומסוגלותם בהפעלת מערכות. לשיטת מאמר זה, נכון יהיה לפתח מערכות אמל"ח טכנולוגיות שיתאימו ליכולות המפעיל המבצעי ולהפעלת המערכות במקום המצב הקיים, שבו המסגרות בוחרות את המפעילים המבצעיים בהתאם למאפיינים הנדרשים להפעלת מערכות האמל"ח המורכבות.

שימור מוסכמות ושימוש בידע מצטבר

האמל"ח הקיים או המפותח בימינו נשען על מתודולוגיה, ידע, תו"ל ופו"ש שהצטבר במהלך עשרות שנים. כמו כן הוא נשען על ידע מצטבר של אלפי משתמשים מבצעיים שהפעילו את המערכת, במסגרת היחידה או החיל, שנים רבות. כלל הידע עובר כבמעין משפך וירטואלי לתוך נייר הדמ"צ והאפיון של הדור הבא של המערכות המבצעיות עבור אותה יחידה או מסגרת. ידע זה מכיל מוסכמות שצרובות במוחו של המפעיל המבצעי באימונים ובזמן אמת, ויש ערך לשימורן. דוגמה לכך, המצויה כמעט בכל מערכת טכנולוגית אזרחית הקיימת כיום, היא צורת כפתור השמירה (Save) המיוצג באייקון של תקליטון (Floppy Disk). מנגד, רבים ממשתמשי המערכות הטכנולוגיות האזרחיות כיום צעירים מכדי לזכור שבעבר, לפני שנים לא רבות, אמצעי השמירה הנפוץ היה תקליטון. רובם אינו מודע למשמעות שנושא אותו אייקון, נוסף על היותו סַמן של שמירת תוצר.

התחשבות בנורמות טכנולוגיות מובנות ומוטמעות אצל המפעיל המבצעי

ידע נצבר וממומש כיום במסגרות השונות במערכות אמל"ח קיימות - "מערכות לגאסי" - שנשענות על ניסיון עתיר ורחב שלרוב גם מוכח מבצעית. חיכוך קיים ומוכר נמצא תמיד בשלבי אפיון מערכות אמל"ח בין הקיים והמתפקד ובין החדש. ניתן לראות זאת בהטמעת טכנולוגיות חדשות הנשענות על אלגוריתמיקה פורצת דרך, אשר לרוב מגיעה לשוק האזרחי ולאחר מכן לעולם הביטחוני. לדוגמה, מערכת Waze הקיימת כ־14 שנים ומבצעת אופטימיזציית נסיעה בכבישי ישראל; קונספט המערכת מאפשר הבשלה טכנולוגית של מערכת צבאית לחישוב מסלול של פלטפורמות, עבירות בצירים ואופטימיזציית משאבי משימה. הבשלה זאת מיושמת כיום במערכות ניווט דיגיטליות בזרוע היבשה ובמנהלת לוחמ"מ באמ"ן, בצורת אמצעי מיפוי וניווט טכנולוגי לרמת המ"פ, המ"מ ואף נווט החוד בכוח היבשתי המתמרן. כלומר, Waze ללוחם במשימה היבשתית. דוגמה נוספת היא הבשלת מערכת Gett (לשעבר - Get Taxi) בשנים האחרונות. מערכת הביטחון מיישמת קונספט דומה במכרזי אש במערכות שו"ב וניהול משימה. אף שיש שוני בין הזמנת מונית לנסיעה בעיר ובין הפעלת אש על מטרה, העיקרון הוא אחד - מיצוי משאבים אל מול תנאי סביבה ומשתני משימה. בחיכוך הבריא בין קיים לחדש, כלומר בין "מערכות מורשת" ובין טכנולוגיה חדשה פורצת דרך, יש אלמנט נוסף - הנורמות הטכנולוגיות שמוטמעות אצל מפעיל האמל"ח. סביר להניח שמפעיל אמל"ח ישמש בתפקידו שנים מעטות (פרק הסדיר ואולי גם פרק קבע), אך יהיה "מפעיל מערכות אזרחיות", כמו מערכות הפעלה, אפליקציות, מכשירי מובייל, טאבלטים, כלי רכב ועוד, במשך תקופה ארוכה.

מקרה אחר: חייל חי"ר בשירות סדיר הנמצא בפעילות צבאית, הכוללת ניווט אל היעד באמצעות טאבלט ובו מפות GIS1 צבאיות ומערכת הפעלה לצורכי ניווט. אותו לוחם חי"ר צעיר שמפעיל כשנה וחצי עד שנתיים אמל"ח בחטיבת חי"ר, מפעיל כעשר שנים "מערכת אזרחית" - סלולרי בעל מערכת הפעלה אנדרואיד או אפל. כלומר, אותו מפעיל מבצעי מחטיבת החי"ר, מפעיל טלפון חכם במשך פי חמישה או שישה יותר מהזמן שבו הוא מפעיל אמל"ח. לפי עקרונות ה־FTUX נכון היה לקפ"ט שמאפיין את מערכת הניווט על־גבי טאבלט, לאפשר יכולת של מערכת הפעלה וממשק משתמש מותאמת אישית למפעיל האמל"ח בזמן ההתקנה On boarding.2 כלומר, לפי דוגמה זאת, בשטחי הכינוס בשלב ההיערכות, טרום היציאה לפעילות, מערכת הניווט הצבאית על־גבי הטאבלט הייתה "שואלת" את המפעיל המבצעי איזה סלולרי הוא מכיר ומחזיק באופן אישי, ומבצעת התאמה של מערכת התפעול לפי עקרונות המערכת שלו.3 מערכת שאינה בעלת אלמנטי FTUX מצריכה גורם מקצועי שידריך ויכשיר את מפעיל המערכת הייעודי לשימוש באמל"ח. אם אותו מפעיל אינו יכול להפעיל את המערכת בזמן אמת (למשל, פציעה בפעילות מבצעית), שאר החיילים במסגרת לא יוכלו להפעיל את המערכת ללא אלמנט ה־FTUX, מכיוון שאינם מוסמכים או מוכשרים לתפעולה הכללי והמבצעי.

זיהוי מוסכמות ולאחר מכן - התעלמות מהן

במערכות אזרחיות נעשה שימוש במוסכמות טכנולוגיות ותפעוליות עכשוויות. לדוגמה, שימוש באפליקציית היכרויות אזרחית הפועלת על־פיSwipe left - Swipe right  (דפדוף במסכי מגע). מוסכמה זאת מאפשרת למשתמשי מערכת בעלי קשב נמוך לבצע מעבר ממסך אחד למסך אחר באופן מיידי, ובה בעת ללמד את המערכת בקו כללי את העדפותיהם האישיות. מוסכמה טכנו־עיצובית זאת באה בשנה האחרונה לידי ביטוי גם במערכות ובאפליקציות אזרחיות אחרות הפועלות בתחומים ושווקים אחרים, כמו אפליקציית הזמנת חדרי מלון או אפליקציית הזמנת טיסות זולות. הסיבה לחיקוי המוסכמה והטמעתה בשוק האזרחי באמצעות פתרונות שונים היא מכיוון שבעולם האזרחי השוק פתוח ואין כמעט פרקי הכשרות, למעט תוכנות עבודה מקצועיות, שלרוב ממשק ההפעלה וממשק המשתמש שלהן אינו אינטואיטיבי דיו. נוסף על כך, משך חיי האפליקציה והמערכת בשוק האזרחי הוא שנים מעטות. כלומר, גוף המפתח אפליקציה אזרחית יודע במהלך האפיון והפיתוח שלמערכת יכולים להיות חיי מדף ושוק קצרים. לעומת זאת, מערכות אמל"ח "יכולות לחיות" עשרות שנים, במיוחד כשמדובר בפלטפורמות כמו רק"ם, כלי שיט, כלי טיס, רכב לוגיסטי וכדומה. מערכות צבאיות אינן תלויות באופן שבו השוק האזרחי מקבל ומטמיע אותן. הדבר היחיד שמתעדכן בהן הוא גרסאות הפעלה, גרסאות שו"שים ותיקוני באגים. מסיבה זאת, לפי עקרונות ה־FTUX, הקפ"ט שמאפיין את המערכת הטכנולוגית הצבאית אינו צריך להתחשב במוסכמות אזרחיות בשלב האפיון והפיתוח, כיוון שהן מחזיקות מעמד שנים בודדות, לעומת מערכות האמל"ח שמחזיקות מעמד (ברוב המקרים) עשרות שנים.

דוגמה טובה למגמה שמתפתחת בשנים האחרונות בשוק האזרחי היא השימוש ביכולת זיהוי דפוסי דיבור (לא זיהוי קול או מבטא) לצורך מתן פקודות קוליות למערכת, או ביצוע שאילתות כמו מהו מזג האוויר מחר או מהו השער של מט"ח כלשהו. תאגידים גלובליים מובילים כמו אפל, סמסונג, אמזון ואיביי מטמיעים פתרונות טכנולוגיים אלה בקווי המוצר של החברה. לא הייתי ממליץ לאפשר יכולת כזאת במפי"ק4 של סוללת חת"ם. כך כל חייל או אדם הנכנס למפי"ק יוכל "להוריד" פקודת אש לקני הארטילריה באמצעות מערכת זיהוי פקודות מסוג זה. מנגד, נכון יהיה להשתמש בטרנד טכנולוגי זה לצורך הזנה אוטומטית, מיון וסיווג של מידע המועבר ברשת הקשר למערכות שו"ב. הדבר יהיה יעיל במיוחד בהתחשב בפס הנמוך הנדרש לתקשורת קולית, לעומת הפס הרחב הנדרש לתקשורת נתונים.

רימון רסס ונצרת ביטחון. על הכפתור הרצוי להיות בולט ומזמין לשימוש

הקפדה על איזון בריא בין המודל המנטלי ובין מודל המערכת

כיום, במהלך ייזום פרויקט, אפיון מערכת ופיתוח, הקפ"ט בונה הכוח שם לרוב את הדגש על מודל המערכת: כיצד היא עובדת, מהו תפעולה הנכון, הביצועים, ההגבלים והיכולות, כיצד היא מתמודדת עם תנאי סביבה ומערכות אחרות ואפילו מתחשבת בתאלמ"ג (תאימות אלקטרו־מגנטית) בסביבתה. עם זאת, הדגש על המודל המנטלי של מפעיל האמל"ח קטן באופן ניכר. משאבים מעטים מוסטים לחקר המודל המנטלי של מפעיל האמל"ח, כיצד הוא תופס את משימתו באמצעות המערכת וכיצד עליו להפעיל אותה באופן נכון. הסיבה לכך, לרוב (בהתבסס על תחקור קפ"טים במפא"ת ובזרועות השונות), היא העובדה שפרויקט יוצא לדרך עם משאבים מוגבלים, וחלק מעבודת הקפ"ט היא לבחון ולהחליט היכן לשים את הדגש המשאבי. כיוון שמודעות מערכת בניין הכוח לחשיבות ממשק המשתמש קטנה, המשאבים המופנים לנושא במהלך אפיון המערכת קטנים גם כן. כמו כן, הקפ"ט בגוף פיתוח לא תמיד שם לב או מודע ליתרון המשאבי המערכתי הטמון בהנדסת אנוש טובה, בדגש על FTUX. הנדסת אנוש טובה יותר יכולה לחסוך משאבים רבים מאלה המושקעים בפיתוחה. לדוגמה, צמצום משך הכשרה - משאב כספי גבוה שמקורותיו מגיעים בדרך כלל מהזרוע, בדומה למקורות תקציב פיתוח האמל"ח. דוגמה נוספת היא ייעול האימונים, מה שיביא לחיסכון תקציבי ולהתייעלות משקית, יחד עם ייעול השימוש באמל"ח (שיעור גבוה יותר של פגיעות במטרה, צמצום שימוש בשעות מנוע עקב הגעה מהירה יותר ליעד וכדומה). למעשה, מבחינת ROI5 עדיף יהיה לזרוע להשקיע יותר בממשקי המשתמש ובחוויית המפעיל של המערכת, ובכך לחסוך באופן ניכר ואולי אף לקצר פרקי הכשרה המוקצים ללימוד של תפעול מערכת.6

הקפדה על עיצוב מוכוון משתמש7

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

עיצוב מוכוון משתמש - מפעיל האמל"ח הוא לבנת המרכז שסביבה מאופיינת המערכת, על כל רבדיה התפעוליים, והוא שותף לכלל תהליכי האפיון והתכן.

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

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

שילוב תהליכים תוספתיים במערכות

בתהליך אפיון מערכת חדשה או גרסת המשך של מערכת קיימת ומבצעית, נכון לשלב תהליכים תוספתיים, כמו למשל הוספת פיצ'ר תומך קבלת החלטות למפעיל המבצעי. השאלה היא: כיצד ניתן ונכון להוסיף פיצ'ר כזה לפלטפורמה שטסה באוויר או שטה בים כבר 30 שנה, ומוּכרת למספר רב של משתמשים ואנשי אחזקה - בלי לשנות אותה או את ממשקי המשתמש שלה באופן שיחייב הסמכה מחדש על תתי־מערכות, או על המערכת כולה, או הוצאה משירות של מפעילים ותיקים? על־מנת לעשות זאת נכון, על הקפ"ט קודם כול לחקור ולהבין כיצד המפעיל המבצעי עובד עם המערכת. נכון לעשות זאת באמצעות שני תהליכים ניהוליים:

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

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

דוגמה ראשונה לשילוב תהליך תוספתי היא שילוב נוהלי מדיניות הפעלה במערכת הגנה אווירית, כך שהיא מוזנת במדיניות מבצעית ברורה, ובכך הדבר מפשט תהליכים למפעיל המבצעי. למשל, האם לשגר כמה מיירטים לעבר איום במתאר ספציפי או רק אחד, והאם לבצע יירוט על־ידי המערכת בשטחים פתוחים, או רק מעל מרכזי אוכלוסייה? דוגמה אחרת היא הוספת ישויות ואלמנטים במערכת שו"ב לפי תו"ל אג"מי וספרות חילית (כך שהתמונה הדיגיטלית תיראה כמו השקף בתלקון הקרב), ובהם סט"מים (סימנים טקטיים מוסכמים), קווי פו"ש אג"מיים (קווי בטיחות וקווי הפעלה שונים) ושכבות וקטוריות וסימני מיפוי על ציר אג"מי.

מַזְמִינוּת ושימוש ב"נצרות ביטחון"

הנתונים והידע לשם ביצוע המשימה, כמו גם תפעול הפעולות הללו, מרוכזים במערכות טכנולוגיות מתקדמות הפרוסות בשטח, בקרונות ההפעלה ובחמ"לי הפיקוד. חוסר בהירות עקב ממשקי משתמש לא מתאימים עלול לגרור טעויות ותקלות מבצעיות של ממש. לדוגמה, מפעיל מערכת המבצע טעות תפעולית יכול לגרום נזק בעל משקל מבצעי רב, כמו לחיצה שגויה על פקד המזין מטרות תרגיליות לסביבה מבצעית, או מנגד למחוק מטרות מבצעיות במערכת דואלית בזמן תרגיל חילי או תרגיל הכשרה. אירוע כזה יכול להתבצע כאשר ממשק המשתמש של המערכת אינו מאפשר למפעיל להבדיל באופן ודאי בין כפתור רצוי וכפתור מצוי במסכי המערכת. לשם כך יש להתחשב בעקרון ה"מַזְמִינוּת". לפי עיקרון זה, על הכפתור הרצוי להיות בולט ומזמין לשימוש באופן ניכר יותר מהכפתור המצוי.

במקרה של מפעיל מבצעי שאינו מיומן דיו בהפעלת המערכת, או שמפעיל את המערכת בפעם הראשונה בזמן חירום, נכון יהיה לשלב במערכת "נצרות ביטחון" כשכבה נוספת של הגנה לפני ביצוע משימה או מימוש פקודה במערכת. לפיצ'רים אלה אחריות גדולה, שכן הם החסם האחרון לפני ביצוע פעולה מבצעית בעלת משקל ואחריות. עם זאת, יש להשתמש ב"נצרות" האלה במשורה, שכן העמסת השימוש בהן יכולה לפגוע הן בקשב והן באמון של המפעיל המבצעי במערכת. אחת הדוגמאות לשימוש אפשרי ב"נצרות ביטחון" היא לפני מחיקת קבצים כמו תיקי מבצע ותיקי תרגיל במערכת שו"ב. "נצרת ביטחון" נוספת יכולה להופיע לפני מתן פקודת אש למערכת יורה על־ידי מחשב הירי במסגרת (בודדת, צוותית, פלוגתית, גדודית וחטיבתית); "נצרת ביטחון" לפני הורדת שינוי משימה לכוח בשטח; לפני מתן פקודה שחורגת ממדיניות (כמו מדיניות הפעלת אש או מדיניות טיסה); ביצוע עדכון גרסה למערכת טכנו־מבצעית.

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

בידול נסיינים ומשתמשים

דרך אפקטיבית למקסם מודל FTUX  בשלב אפיון המערכת היא לבדל בין מפעילי מערכת שונים, ולתשאל אותם. סיעור מוחות בקרב קבוצות מפעילים שונים יקל על תהליך ה־FTUX למשתמשים כמותם (לדוגמה, חיילים בפרק הכשרה, חיילים ותיקים, מפעילי מערכת בקבע, מערך המילואים). לנסיינים ולמפעילים מהקטגוריות השונות תהיה דעה אחרת לרוב, ומיקוד בתכולות ובפיצ'רים של המערכת שיהיו חשובים להם יותר. לדוגמה, ככל שהנסיינים יהיו מבוגרים יותר (למשל, מפעילי מערכת במילואים בדרגות גבוהות), חשיבות הגופן וגודלו תעלה. לעומת זאת, למפעילים צעירים ובמיוחד בשירות סדיר, פיצ'ר זה פחות חשוב.

סיכום

עקרון ה־FTUX הוא נדבך חשוב בתורת הנדסת האנוש, ומקבל דגש רב ומובהק בעולם פיתוח האמל"ח והמערכות הביטחוניות, מכיוון שבשונה מהשוק האזרחי, במערכת הביטחונית ובצה"ל למפעיל המבצעי אין דעה חופשית בנושא. הוא מחויב מתוקף תפקידו להשתמש במערכת המבצעית לביצוע המשימה הצבאית, ואינו יכול לבחור על דעת עצמו מערכת אחרת הקיימת בשוק החופשי. מכיוון שמפעיל האמל"ח יכול להיות בעל תפקיד שפוגש את המערכת בפעם הראשונה או לאחר זמן ממושך ללא מופע כשירות תקף, כדי להקל עליו לבצע את משימתו כהלכה חשוב לשים דגש על כך שהמערכת תאופיין ותפותח לפי עקרונות FTUX. בצה"ל מתקיימים תדיר מפגשים בין משתמשים ארעיים (כמו חיילי מילואים) למערכות אמל"ח טכנולוגיות מתקדמות, ולא תמיד זמן ההכשרה מאפשר שליטה מספקת במערכת. נוסף על כך, במהלך השנים עולה מורכבות המערכות עקב השתנות מפת האיומים, הזירה, המשימות והפו"ש ביחידות הצבא בבניין והפעלת הכוח.

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

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

לקבלת חומרים נוספים מבית "מערכות" - ניתן להירשם לניוזלטר שלנו בכתובת: maarachot@idf.il

מפעיל מערכת אמל"ח מבצעית בזרוע היבשה. חוסר בהירות עקב ממשקי משתמש לא מתאימים עלול לגרור טעויות ותקלות מבצעיות