סיכום
Summary
שמישות (Usability) · שיעור 6
- שמישות = יעילות/אפקטיביות/שביעות-רצון, מנוף לאיכות-נתונים.
- שמישות ≠ קבלה — טפל בשתיהן.
- סולם שלוש-שכבות; תמיד מהנמוך, ובסס בראיות.
- S/4HANA: Fiori-first + Clean Core + Personas כגשר.
מטרת השיעור
ידע אצורשמישות היא מנוף-נתונים מרכזי ב-PM: ככל שהדיווח קל ומדויק, כך נתוני-התחזוקה אמינים וה-KPI שעליהם נשענים ההחלטות נכונים. הפרק הגדיר שמישות (ISO 9241-11: אפקטיביות/יעילות/שביעות-רצון), הבחין בינה לבין קבלת-משתמשים, והציג סולם-כלים בן שלוש-שכבות: משתמש (SU3/תפקידים/וריאנטים), IT-ללא-קוד (SHD0/Customizing/Action Box/Business Client/Mobile/Fiori/GuiXT/Personas) ותכנות (Upstream/BAPI/Web/Customer Exits). הכלל: בחר תמיד את השכבה הנמוכה-ביותר שפותרת, ובסס שיפורים על מחקרי-שמישות מבוססי-ראיות.
למה זה חשוב
ידע אצורסיכום בקצרה: שמישות = כמה נוח לעבוד עם המערכת, והיא חשובה כי דיווח-נוח = נתונים-טובים. נוחות לבד לא מספיקה — צריך גם שהמשתמשים יקבלו וירצו (קבלה). לשיפור יש 'סולם': קודם הגדרות-אישיות, אז כלים-של-IT-בלי-קוד, ורק לבסוף תכנות. ולפני שמשנים — בודקים עם משתמשים-אמיתיים מה באמת עוזר.
ערך עסקי
ידע אצורלקבע מסגרת-החלטה לכל בעיית-שמישות ב-PM: לזהות את הקהל, לבחור את השכבה-הנכונה, ולאמת בראיות — כדי למקסם קבלה, איכות-נתונים והחזר-השקעה.
מושגי מפתח
ידע אצור- שמישות = יעילות/אפקטיביות/שביעות-רצון, מנוף לאיכות-נתונים.
- שמישות ≠ קבלה — טפל בשתיהן.
- סולם שלוש-שכבות; תמיד מהנמוך, ובסס בראיות.
- S/4HANA: Fiori-first + Clean Core + Personas כגשר.
דוגמה מ-CBC
ידע אצורבארגון אסטרטגיית-השמישות: Fiori למתכננים, Asset Manager לטכנאי-שטח, SHD0/Personas למסכי-GUI שנותרו, Clean Core בכל-הרחבה, ומחקרי-שמישות לפני-פריסה — הכול נמדד ב-Adoption, זמן-דיווח ושלמות-נתונים, ומחובר ל-KPI זמינות-הקו. בקשה לשיפור דיווח-תקלה: מאפיינים Persona (טכנאי-רוחב), מודדים Baseline, פותרים בשכבה-נמוכה (SHD0 + Action Box, ולא פיתוח), בודקים A/B ב-Personas, פורסים את הזוכה ומודדים Adoption — מחזור-שלם של שיפור-שמישות מבוסס-ראיות.
טבלאות
ידע אצור| טבלה | תיאור |
|---|---|
| USR05 | USR05 |
| TSTCV | TSTCV |
| AUFK | AUFK |
| QMEL | QMEL |
טרנזקציות
ידע אצוראפליקציות Fiori
ידע אצורקונפיגורציה (SPRO)
ידע אצור• מסגרת-החלטה: אפיין-קהל → בחר-שכבה-נמוכה → אמת-בראיות → מדוד-Adoption. • ב-S/4HANA: Fiori-first, Clean Core, Personas כגשר.
הערות
ידע אצורשאלות ראיון סכם את עקרון-הסולם לשיפור-שמישות. בחר תמיד את השכבה-הנמוכה-ביותר שפותרת: קודם אפשרויות-המשתמש (SU3/תפקידים/וריאנטים), אז IT-ללא-קוד (SHD0/Customizing/Fiori/Personas), ורק לבסוף תכנות — לפי עלות/סיכון/שדרוג. מהי המסקנה המרכזית של הפרק? שמישות היא מנוף לאיכות-נתונים וקבלה; משפרים אותה בכלי-המתאים-לשכבה, מבססים בראיות (מחקר-שמישות/Personas A/B), ושומרים Clean Core ב-S/4HANA. נושאים קשורים • PM · עיבוד הזמנת-תחזוקה • PM · דיווח-גמר • PM · אינטגרציות ו-IDocs
טעויות נפוצות
ידע אצור- פיתוח-יתר במקום שכבה-נמוכה.
- התמקדות בשמישות תוך-הזנחת קבלה.
- שינוי-מסכים ללא מחקר-שמישות מבוסס-ראיות.
פתרון תקלות
ידע אצור• השקעה-בשמישות ללא-תוצאה ➔ בדוק את שכבת-הקבלה (אמון/הדרכה/תועלת). • שיפור לא-מוכח ➔ חסר Baseline ומחקר-שמישות.
שיטות עבודה מומלצות
ידע אצור- תמיד מהשכבה-הנמוכה כלפי-מעלה.
- טפל בשמישות ובקבלה במקביל.
- בסס כל שיפור על מדידה ומחקר; מדוד Adoption.
טיפים
ידע אצור- המסגרת המעשית: (1) שמישות ≠ קבלה — טפל בשתיהן (TAM: Ease-of-Use + Usefulness + ליווי); (2) סולם-עלות/סיכון: User → Non-programmer IT → Programmer, תמיד מהנמוך; (3) ב-S/4HANA Fiori-first + Clean Core (Released APIs/Extension Points), Personas כגשר ל-GUI כבד; (4) החלטות מבוססות-מחקר-שמישות (Personas A/B, SUS, Time/Errors). היישום לארגון: טכנאי-שטח ב-Asset Manager, מתכננים ב-Fiori, מסכי-GUI שנותרו ב-Personas/SHD0 — מדידים ב-Adoption ושלמות-נתונים.
סיכום
ידע אצור• שמישות = יעילות/אפקטיביות/שביעות-רצון, מנוף לאיכות-נתונים. • שמישות ≠ קבלה — טפל בשתיהן. • סולם שלוש-שכבות; תמיד מהנמוך, ובסס בראיות. • S/4HANA: Fiori-first + Clean Core + Personas כגשר.