תחקור\הערכת מערכת (System Assessment) הוא שלב במחזור החיים בו מבוצעת בדיקה בדיעבד של מערכת ממוחשבת, על מנת לאתר תקלות ובעיות, כמו גם נקודות חיוביות, שאירעו במהלך פיתוח המערכת, התקנתה והעברתה לייצור שוטף ותחזוקה. זאת, על מנת להפיק מסקנות ולקחים, הן לפרויקט עצמו - להמשך דרכו - והן לפרויקטים אחרים בארגון בהווה ובעתיד.
תחקור/ הערכת מערכת (System Assessment) הוא שלב במחזור החיים בו מבוצעת בדיקה בדיעבד של מערכת, על מנת לאתר תקלות ובעיות, כמו גם נקודות חיוביות, בתהליך פיתוח המערכת, התקנתה והעברתה לייצור שוטף ותחזוקה. זאת, על מנת להפיק מסקנות ולקחים, הן לפרויקט עצמו - להמשך דרכו - והן לפרויקטים אחרים בארגון בהווה ובעתיד.
תחקור יבוצע באחד מהמקרים הבאים:
א. בסיום פרויקט – 6-3 חודשים מהכרזת המערכת כמבצעית (העברה לייצור). תחקור כזה מתאים בד"כ לפרויקטים גדולים (מסדר גודל ג3 בלבד).
ב. פרויקט שבוטל - פרויקט שהחל את שלב האפיון, אך בוטל בשלב כלשהו מאוחר יותר. תחקור כזה מתאים לכל סוג פרויקט בכל היקף שהוא.
ג. במהלך פרויקט - פרויקט שהתגלו בו בעיות חמורות, כגון: חריגה של 50% ומעלה בלו"ז או בעלויות, בעיות טכנולוגיות חריגות, או כל בעיה אחרת שמאיימת על יכולתו של הפרויקט להסתיים. תחקור כזה מתאים לכל סוג פרויקט בכל היקף שהוא.
קיים קשר בין תחקור לבין מספר נושאים אחרים קרובים כגון: בדיקות מערכת, שיקופים וניתוח סיכונים. ההבדל היסודי הוא בממד הזמן ובקשר למחזור חיי המערכת. בדיקות מערכת, שיקופים וניתוח סיכונים הם חלק אינטגרלי מתהליך פיתוח המערכת ומתבצעים ע"י צוות הפרויקט. תחקור לעומת זאת מיועד לבדוק את הפרויקט מתוך פרספקטיבה של זמן ומבוצע ע"י גורם חיצוני (לפרויקט). המקרה שנזכר בסעיף הראשון לעיל, תחקור בסיום פרויקט, הוא המקרה השכיח: התחקור נערך כ- 6 חודשים לאחר סיום הפרויקט ומטרתו לתת לדרג הניהולי מבט כולל על הפרויקט כולו, מתחילתו ועד להטמעתו אצל המשתמשים.
כל תיעוד וחומר אחר הקשור בבניית המערכת עשוי לשמש קלט. בפרט המקורות הבאים:
· תיקי מערכת: אפיון, עיצוב, בדיקות וכו'
· אב-טיפוס (Prototype)
· חוזים והתקשרויות עם גורמים חיצוניים (אם יש כאלה)
· סיכומי ועדות היגוי
· סיכומי שיקופים
· תוכניות אבטחת איכות
· מסמכי ניתוח סיכונים
· כל חומר אחר הנראה רלוונטי למתחקר
ראה סעיף פעילויות - תכנית עבודה להלן
תוצר ראשי: מסמך תחקור, ראה סעיף תוצרים מסמך תחקור להלן.
הערכת משך הזמן והמשאבים הדרושים לביצוע התחקור תלויה בפרמטרים רבים הנובעים מאופי וסוג המערכת, מידת המיומנות של הגורם המבצע את התחקור, מידת דחיפות סיום התחקור ועוד. ככלל אצבע ניתן להעריך שהמינימום הנדרש הוא 15 ימי עבודה לפרויקט קטן (ג1), 30 ימי עבודה לפרויקט בינוני (ג2) ו- 50 ימי עבודה לפרויקט גדול (ג3 ומעלה). למידע מפורט יותר ראה סעיף הערכת משך ביצוע התחקור להלן.
ביצוע שלב התחקור עצמו: מנהל יחידת המחשב, ועדת היגוי לפרויקט, או כל גורם מסמך אחר בארגון.
האפשרות המועדפת היא פונקצית אבטחת איכות (א"א) בארגון. מומלץ מאד להטיל משימה זו עליה. אפשרויות אחרות הן:
· גורם חיצוני לפרויקט ולארגון – הבחירה השנייה
· גורם חיצוני לפרויקט, פנימי בארגון, כגון צוות פרויקט אחר
· הפרויקט עצמו. מקרה זה לא מומלץ מסיבות ברורות, אך הוא אפשרי, בפרט בתחקור של פרויקט שהושהה או בוטל (מקרה ג' לעיל). צוות הפרויקט, מנהל הפרויקט בראשו, יעצור כל פעילות ויתחקר את עצמו (מעין שיקוף מורחב) ראה קיט שיקופים בפרק כלים תומכים.
מפקח על ביצוע התחקור ומאשר את סיומו. הצוות המנהלי של הפרויקט (ועדת ההיגוי).
לפי החלטה מקומית בכל ארגון.
האלטרנטיבות להמשך בפרויקט הן:
· הפסקת פעילות המערכת והחלפתה באחרת (בתחקור של מערכת עובדת)
· הפסקת פעילות המערכת עד להכנסת השיפורים הנדרשים, בהתאם ללקחים שהופקו (בתחקור של מערכת עובדת)
· ביצוע פעולות מתקנות והכנסת השיפורים הנדרשים, בהתאם ללקחים שהופקו, במהלך הפעלת המערכת (בתחקור של מערכת עובדת)
· הקפאת הפרויקט (בתחקור של פרויקט חי).
· שיפור אלמנטים בפרויקט הטעונים שיפור (בתחקור של פרויקט חי).
האלטרנטיבות ברמת הארגון הן:
· ביצוע פעולות מונעות והכנסת שיפורים, לאור הלקחים שנלמדו, בטווח המיידי במערכות אחרות בארגון.
· גיבוש אסטרטגיה לביצוע פעולות מונעות ושיפור תהליכים, לאור הלקחים שנלמדו, בטווח הארוך במערכות אחרות בארגון.
במקרה של פרויקט חי: הפרויקט מתנהל כשורה, כולל שיקופים בהתאם להתקדמות המערכת, ואין צורך בתחקור.
במקרה של פרויקט שהסתיים:
· פרויקטים מסדר גודל ג1 או ג2 אינם חייבים תחקור. הנהלת יחידת המחשב יכולה להחליט לבצע תחקור בכל זאת.
· פרויקטים מסדר גודל ג3 חייבים תחקור. הנהלת יחידת המחשב יכולה להחליט לוותר על התחקור.
להלן פירוט הפעילויות לתחקור מערכת. ההחלטה אם לארגן פעילויות אלה בתכנית עבודה מדוקדקת (תרשים גאנט / פרט) או לבצען כרשימת משימות ולנהלן בכלי למעקב משימות, היא של הגורם המבצע את התחקור. כך או כך, על מנת להגיע לתוצאות טובות יש לבצע את הפעילויות המפורטות להלן. פעילויות המסומנות ב- [n] הן פעילויות צומת, אבני דרך או שיקופים.
הפעילויות המקדימות שיש לבצע, לפני התחלת ביצוע התחקור הן:
· זיהוי הצורך לביצוע תחקור: ראה הסבר בפרק כללי לעיל באשר לכל הסיבות והאפשריות השונות לביצוע תחקור
· קבלת מחויבות סופית מהלקוח – הזמנת עבודה.
· קבלת מחויבות ממנהלת הפרויקט וועדת ההיגוי
· קבלת מחויבות מסיוע טכני וגורמי תשתית אחרים שמיומנותם ועצתם דרושים לתחקור
· הוספת יועצים חיצוניים?
· שאלון שביעות רצון משתמשים מופיע להלן כחלק מתהליך התחקור. במקרים מסוימים, ניתן לשקול לבצע אותו כפעולה מקדימה על מנת לבסס את עצם הצורך בתחקור המערכת.
מנהל המחשוב ימנה את הגורם שיבצע את התחקור. כהעדפה ראשונה יש לבחור נציג מצוות אבטחת איכות בארגון. לחילופין, כל גורם מקצועי שלא היה מעורב בפיתוח המערכת. רק במקרה קיצוני של "אין ברירה" תוטל המשימה על מנהל הפרויקט או על גורם אחר שהיה מעורב בפיתוח המערכת המתוחקרת.
חיוני ללוות את המינוי בהוצאת כתב מנוי מסודר בתפוצה רחבה ומחייבת.
בניית תכנית עבודה על בסיס רשימת הפעילויות להלן 4-11. לחילופין, ניתן לבנות "רשימת משימות" כמוסבר לעיל ובאישור ועדת ההיגוי.
מבצע התחקור יידע את הגורמים המעורבים בפרויקט על קיום תחקור לפרויקט. ההודעה תלווה בבקשה לאספקת מידע וחומר קיים וקביעת פגישות עבודה.
מבצע התחקור יקבל ממנהל הפרויקט חומרים שליוו את פיתוח הפרויקט:
· מסמכי תיעוד שלבי מחזור החיים: תיקי מערכת
· תכתובות והתקשרויות עם גורמי חוץ (אם יש)
· סיכומי ועדות היגוי
· סיכומי שיקופים
· מסמכי ניתוח סיכונים
· מסמכי תוכניות עבודה
· מסמכי תוכנית אבטחת איכות
· כל חומר רלוונטי אחר
לאחר לימוד יסודי של החומר שקיבל, ייפגש מבצע התחקור עם הגורמים הבאים (לפחות):
· מנהל הפרוייקט
· מומחה היישום – הלקוח
· הצוותים המקצועיים
· נציג ועדת ההיגוי
· גורמים מעורבים נוספים לפי ראות עיניו.
מטרת הפגישות היא הבנת תהליך הפיתוח ואיתור בעיות ולקחים (שליליים וחיוביים).
המתחקר ישלח טפסי שביעות רצון למדגם מייצג של משתמשי המערכת, כפי שהופיעו ברכיב 2.2 בתיק המערכת העדכני. (ראה "רשימות תיוג לתחקור מערכת" רשימה של שאלות להצגה בפני המרואיינים מחולקת עפ"י נושאים. ניתן להשתמש ברשימת התיוג לביצוע הראיון עצמו או כתזכורת לנושאי התחקור.
· שאלון שביעות רצון משתמשים בהמשך)
· יש לצרף לשאלון מכתב הסבר ובו פירוט מען ולו"ז למילוי והחזרת השאלון.
· עם קבלת השאלון יש לנתחו ולהשתמש בממצאים שנתגלו בו:
· במסמך עצמאי ובמצגות שונות
· במסמך התחקור.
בהתאם לנסיבות הפרויקט, יש לשקול כתיבה והפצה מוגבלת של טיוטה של התחקור. יש שיקולים כבדי משקל בעד ונגד פעולה זו וכל ארגון / פרויקט יחליט לגופו של עניין.
בכל מקרה, המסמך ייכתב על בסיס גלופת מסמך התחקור המופיעה בסעיף מסמך תחקור להלן, על מנת להתמקד בתוצר הסופי ולחסוך משאבים. אין ליצור מסמכי ביניים בפורמט אד-הוק וזמני!
מסמך התחקור הסופי והמלא ייכתב על סמך הגלופה המתוארת בסעיף מסמך תחקור להלן. מסמך זה יהיה הרחבה של הטיוטה שנכתבה לעיל.
יש לשקול גם כתיבה של מצגת לדרג הניהולי. ראה מצגת תחקור בלשונית תוצרים.
לקראת הדיון המסכם, יופץ המסמך לגורמים שישתתפו בדיון:
· מנהל מערכות מידע
· יו"ר ועדת ההיגוי
· מנהל הפרוייקט
· מומחה היישום
· מבצע התחקור
· גורמים נוספים לפי הצורך
מנהל המחשוב ייזום דיון מסכם לתחקיר. בדיון יציג המתחקר את העבודה שביצע ויידונו לעומק הבעיות העיקריות והלקחים לביצוע.
סיכום הדיון יכלול לו"ז וגורם מבצע לכל לקח שיוחלט שיש לבצע.
· יש לוודא קיום כתב מינוי לצוות התחקיר. רצוי שיהיה צוות ולא אדם אחד כדי לנטרל כל שמץ של דיבורים על הטיה בתחקיר.
· כתב המינוי צריך להינתן מבעל התפקיד הבכיר ביותר האפשרי, על מנת שיהיה קל לאנשי הצוות לקבל שיתוף פעולה מהמרואיינים.
· כתב המינוי אמור לפרט מה נדרש מצוות התחקיר, עד כמה הם יכולים להתפרס או נאלצים להצטמצם מבחינת נושאי התחקיר, והאם יש דגשים מיוחדים שחשובים למנהל הממנה או לארגון.
יש להכין רשימה כזו, סביר להניח כי היא תתעדכן במשך רוב זמן התחקיר. יש לשאול את המרואיינים האם הם חושבים כי יש צורך לדבר עם אנשים נוספים, ולהצליב שמות אלו עם הקיימים ברשימה.
מומלץ להכין טבלה עם שמות האנשים, תפקידם, דרכי ההתקשרות עימם, והתאריך בו מתוכנן / בוצע הראיון עימם.
יש לברר היכן נמצא החומר לגבי נשוא התחקיר (פרוייקט / מערכת..). סביר להניח כי רובו יימצא אצל מנהל הפרויקט או האחראי, אולם כדאי לברר האם ישנם "איים" של מידע המקומות אחרים.
יש לקרוא את החומר, כולל התכתבויות, ורצוי לעשות זאת לפני תחילת הראיונות, על מנת שניתן יהיה למתחקר לבור את מוץ מהתשובות שיקבל.
כאשר התבהרה מספיק התמונה עבור הצוות המתחקר, יש להכין שאלון או רשימת תיוג, באמצעותו אח"כ ירואיינו האנשים השונים. השאלון אמור להכיל רשימה של שאלות, פתוחות, אשר יאפשרו למרואיינים להביע את דעתם על אספקטים שונים של הפרויקט, החל מייזומו, למשל ועד להטמעתו.
לשם עזרה בחיבור השאלון, ניתן להיעזר בעץ המערכת, ובאמצעותו לתת דגשים על נקודות שנראות חשובות יותר מאחרות, למשל אם נראה לצוות כי נושא הטכנולוגיה בפרויקט קיבל תשומת לב פחותה מדי / רבה מדי / לא נכונה, אזי יש מקום לנסח שאלה מתאימה שתיגע בכך.
לא לשכוח להשאיר שאלה אחת לפחות שתאפשר למרואיין להוסיף דברים משלו, במידה שהוא רוצה להוסיף מעבר לשאלות הקיימות בשאלון (בסגנון: האם יש לך דברים נוספים לומר שלא נשאלו או לא דובר עליהם?).
זה השלב העיקרי, למעשה של התחקיר, כי רק כך ניתן לקבל את ההתרשמות של המעורבים בפרויקט, בצורה אמיתית ופנים אל פנים.
יש לדאוג כי תהליך הראיון עצמו לא יראה כאילו הוא חקירה בתחנת משטרה, ולכן מומלץ לשלוח לפני הראיון את השאלון למרואיין, כדי שיוכל להתכונן לפני הראיון ולא יהיה לחוץ בתשובותיו. יש לעודד את המרואיינים לדבר ולהשתדל לרשום את דבריהם, מאחר ויכול להיות כי הם יובילו אח"כ למרואיינים, שאלות או מסקנות נוספות.
יש לזכור כי בזמן קיום הראיונות לא ניתן לבצעם באופן רצוף כי הצוות קשור לזמני המרואיינים, ולכן כדאי להשאיר חלק מחומר הקריאה לתקופה זו. כמו כן יש לזכור כי לאחר ביצוע הראיון, יש עדיין להשאיר בערך אותו זמן לניתוח ועיבוד הידע שהתקבל, ידע שיכול להאיר נקודות שלא טופלו עד כה, ואפילו להוסיף שאלה חדשה לשאלון במידת הצורך.
המסמך עצמו אמור להיכתב על פי עץ המערכת, שלא לשכות פריטים, ובכל סעיף וסעיף אליהם מתייחס הצוות יש לחלק ל – "ממצאים" – שם מציג הצוות את מה שגילה, העובדות האובייקטיביות, והחלק השני – "לקחים" – כלומר מה ניתן ללמוד לדעת הצוות מממצאים אלו, בין אם לטובה ובין אם לרעה.
את עיקרי הלקחים מומלץ להציג בתחילת המסמך (תמצית מנהלים).
את הטיוטה יש להגיש קודם כל לגוף שמינה את הצוות, לקריאה ראשונית, ואח"כ (או במקביל, זה תלוי בכל מקרה לגופו), גם לבעלי העניין העיקריים,על מנת שיוכלו להעיר את הערותיהם.
לאחר קבלת ההערות, יש להחליט האם משנים חלקים מהמסמך, ואם לא – להתייחס להערה ולהסביר מדוע לא.
יכול להיות שרק לאחר כתיבת המסמך הסופי הוא יועבר להערות, שוב, הכול לפי העניין.
חשוב מאוד להכין גם מצגת, שתציג את עקרי התחקיר, ואשר תוצג בפורום הרחב ביותר האפשרי בארגון, בהתאם להחלטת הגוף המזמין. הצגה זו חשובה, על מנת לוודא כי הלקחים יישמעו על ידי קהל רחב ככל האפשר.
להלן מספר נושאים הראויים להתייחסות מיוחדת במהלך ביצוע התחקיר:
· תועלות - יש לתרגם התועלות לערכים ריאליים ולהציג אותם בתחקיר. במידת הצורך, לקראת התחקיר ניתן לכתוב שאילתות בנושא ולהפנות אותן לגורמים רלוונטיים שיוכלו לסייע בתחקור.
· הדרכות, הטמעות תמיכה וסיוע - חובה להציג נושאים אלה במצגת סיכום התחקיר ואת הלקחים שהופקו (חיוביים או שליליים).
· ביצועים וצריכת משאבים - בעת הצגת סטאטוס עלויות, מעבר לעלויות כ"א יש להציג התייחסות לנושא הביצועים וצריכת משאבים במערכות המחשב לכל אורך חיי המערכת.
· סיכונים - יש להציג אפקטיביות של הטיפול בסיכונים בחומרה גבוהה (עפ"י הגדרות הארגון) או שרמתם X ומעלה. כמו כן יש להציג סיכונים שלא אותרו (בעיות שהתממשו בפרויקט), או כאלה שבטעות הוגדרו שוליים.
· קבלת התייחסויות של גורמים שמחוץ לארגון: ניתן לראיין גורמים שונים הרלוונטיים לשלבי הפרויקט השונים: התנעת הפרויקט, בנייה (אפיון/פיתוח), להטמעה או לתפעול השוטף. יחד עם זאת יודגש כי אין להזמין גורמים אלו להצגת התחקור. הצגת התחקור היא פנימית בארגון.
· קבלת התייחסות של כלל השותפים לפרויקט: בנוסף, יש לאתר את כל בעלי התפקידים בארגון שהיו מעורבים בפיתוח (גם אם הם נמצאים כעת התפקיד אחר), לראיין אותם ולקבל התייחסותם לכלל הסוגיות המועלות במסגרת התחקור.
משך ביצוע התחקור מושפע ממספר פרמטרים מרכזיים:
· היקף הפרויקט
· מצב התיעוד של הפרויקט ושל המערכת
· זמינות הגורמים המעורבים
· מידת חדשנות המערכת
· מידת העומק הנדרשת בתחקור
· ניסיון קודם של הגורם המבצע
· סיבוכיות המערכת
על מנת להעריך את משך ההשקעה הנדרשת בתחקור מומלץ להשתמש במודל המוצג להלן.
ד. קבע תחילה אם הפרויקט נחשב לקטן, בינוני או גדול. הגדרת מפת"ח היא:
· פרויקט קטן עד 100,000$
· פרויקט בינוני עד 500,000$
· פרויקט גדול מ- 500,001$ ומעלה
להסבר מפורט יותר ראה מודל מפת"ח. אם יש הגדרה ארגונית או מקומית, התחשב בה.
ה. השתמש בכלל האצבע הבא:
· פרויקט קטן: 15 ימי עבודה לפחות
· פרויקט בינוני: 30 ימי עבודה לפחות
· פרויקט גדול: 50 ימי עבודה לפחות
ו. בדוק אם מספרים אלה מתאימים לניסיון שנרכש בארגון שלך. בדוק פרויקטי תחקור שכבר בוצעו בעבר בארגון שלך (אם יש כאלה).
ז. בחר את סדרת הפרמטרים המתקנים והמקדמים שבטבלה להלן המתאימים למקרה שלפניך.
ח. יש לקחת את ההערכה הבסיסית שהתקבלה מסעיפים 2 ו- 3 לעיל ולהכפיל אותה בשרשרת המקדמים שהתקבלו מהטבלה. לדוגמא: 58.78 = 1.25*0.9*1.1*0.95*50. ניתן כמובן להתעלם ממקדמים שערכם 1.
ט. ההערכה הסופית היא איפוא 58.8 ימי עבודה (לעומת 50 שהייתה ההערכה הראשונית לפי כללי האצבע בסעיפים 2 ו- 3 לעיל). המקדמים שבטבלה גרמו לתוספת של קרוב ל- 9 י"ע.
פרמטרים מתקנים (מקדמים) לחישוב משך ביצוע התחקור
פרמטר |
איכות הפרמטר |
מקדם (מכפיל) עבור המקרה |
---|---|---|
מצב התיעוד (מסמך אפיון!) |
גרוע |
1.25 |
|
בינוני |
1 |
|
טוב |
0.95 |
זמינות הגורמים המעורבים |
נמוכה |
1.2 |
|
בינונית |
1 |
|
טובה |
0.95 |
מס' מרואיינים |
מעל 10 |
1.15 |
|
5-9 |
1 |
|
1-4 |
0.95 |
מידת חדשנות המערכת |
גבוהה |
1.2 |
|
בינונית |
1.1 |
|
אין חדשנות |
1 |
מידת העומק הנדרשת בתחקור |
גבוהה |
1.3 |
|
רגילה |
1 |
|
כללית / נמוכה |
0.9 |
ניסיון קודם של צוות התחקור |
אין |
1.25 |
|
בינוני |
1 |
|
גבוה |
0.85 |
סיבוכיות המערכת |
גבוהה |
1.15 |
|
רגילה |
1 |
|
נמוכה |
0.9 |
יש להשתמש בגלופת מסמך תחקור\הערכת מערכת לא רק כמסמך מסכם, אלא גם כמסמך עבודה שוטף, הן בתחילת התהליך כמסמך מכוון ומנתב (אוריינטציה) והן במהלך התחקיר כטיוטות ובקרה על התהליך. חשוב לסכם עם הלקוח, בתחילת העבודה, שזה הפורמט והתכולה של התחקור שהוא עתיד לקבל בסוף התהליך. פרק המנהלה יכול לשמש כתוכנית העבודה כבר בתחילת התהליך (בעת שמועלה בכלל הרעיון לביצוע התחקור) ושאר סעיפי המסמך כמצגת איך ייראה המסמך הסופי. באופן זה יהיה ברור לכל המעורבים בתהליך מה התוצר המרכזי אליו חותרים ואיך תתבצע העבודה.
גלופת הלימוד למסמך תחקור מכילה לצד כותרות ומבנה כללי, גם הנחיות, דברי הסבר וטקסטים מומלצים. תפקידם לקצר ולייעל את כתיבת המסמך.
גלופת העבודה מכילה את מבנה הפרקים והסעיפים ומספר הערות חיוניות לכתיבת המסמך.
מסמך תחקור שייך לקבוצת מסמכי המערכת, דוגמת אפיון, עיצוב, בדיקות וכו', הבנויים בהתאם לעץ המערכת. להלן מספר הערות חשובות בהקשר זה:
· רשימת רכיבי עץ המערכת המוגדרת בגלופה היא בסיסית ובבחינת "מינימום נדרש". הכללת רכיבים נוספים של עץ המערכת תיעשה בהתאם לפרויקט בו מדובר. ראה גלופת עץ מערכת רמה שנייה או שלישית בקיט עץ מערכת בכרך יסודות.
· הערכת הרכיבים השונים היא דומה. בכל רכיב יש לבדוק: מה נקבע באפיון, מה השתנה במהלך פיתוח המערכת, מה מומש וכו'. ראה רכיבים 1.2, 1.6, 2.11 ועוד כדוגמא. גם רכיבים שלא פורטו יתוחקרו ויוערכו באופן דומה.
· רכיבים מסוימים יתוחקרו לא רק מול מה שהוגדר באפיון, אלא מול תקנים המקובלים בענף \ בארגון \ ביחידת המחשוב. למשל: דרישות מינימום לאבטחת מידע והגנת הפרטיות.
רשימה של שאלות להצגה בפני המרואיינים מחולקת עפ"י נושאים.
ניתן להשתמש ברשימת התיוג לביצוע הראיון עצמו או כתזכורת לנושאי התחקור.
שאלון שביעות רצון של המשתמשים הוא מרכיב חשוב בתחקור \ הערכת מערכת. עם זאת, הפעלתו אינה פשוטה וכרוכה לא רק במשאבים יקרים, אלא גם ב"רגישויות ארגוניות" שאין לזלזל בהן. ההחלטה אם לכלול את השאלון בתהליך התחקור, נתונה בידי ועדת ההיגוי של התהליך.
להלן מספר כללים בהפעלת השאלון:
· יש לשאוף להפצה מירבית של השאלון לכלל משתמשי המערכת. זכור, בכל מקרה מספר התשובות שתקבל יהיה נמוך.
· אין לסמוך רק על הנשאלים שיענו מרצונם. יש להקצות זמן ומשאבים ל"שיווק" השאלון, לפנייה ישירה לנשאלים ואף לסיוע במילוי השאלון.
· יש לאפשר כשבועיים להחזרת השאלונים.
· יש לבצע ניתוח של הטפסים המלאים ולעדכן את התוצאות כחלק מהתחקור.
· יש לבדוק שאין הטיה של הטפסים שמולאו בכיוון של מחלקה מסוימת, סוג משתמשים מסוים וכו'.
· שאלון שביעות הרצון המצורף הוא דוגמא בלבד ומכיל מספר שאלות מועט. ניתן להוסיף ולגרוע שאלות בהתאם לאופי המערכת, סוג המשתמשים וכו'.
המטרה הראשית של השאלון היא לקבל הערכה כללית ומהירה של פרויקט (מערכת) ענ"א, מכל סוג שהוא ובכל מצב בו הוא נמצא, בין אם הוא עובד כבר בשיטת מפת"ח, בין אם לאו. זהו כלי מרכזי בתחקור מערכות והערכתן (System Assessment). מטרת משנה היא לבנות באופן מהיר ונוח אינדקס תיעוד למערכת קיימת. לעתים קרובות מתברר שמטרת משנה זו היא חשובה יותר משום שהיא חיובית ובונה ומסייעת לפרויקט בקידום התיעוד שלו, בעוד שהראשונה היא בקורתית באופיה.
השאלון בנוי בשיטה של "הערכה עצמית" וניתן להשתמש בו במגוון רחב של "אופני מילוי". דרך מאד יעילה היא קיום סדנא בארגון, לאחר קורס מבוא והתנסות קצרה במפת"ח, בה משתתפים ראשי צוותים ומנהלי פרויקטים. לאחר המילוי ניתן לערוך סבב בשיטת "אחד בודק את השני". בכל מקרה,
מילוי השאלון איננו משימה קלה ויש לגשת לביצועה בצורה מסודרת ואחראית ולהקציב את המשאבים וסביבת העבודה המתאימים.
אבטחת איכות של שלב תחקור/הערכת מערכת תתמקד בתוצרים – תיק התחקור ושאלון שביעות הרצון, ובתהליך ביצוע התחקור.
רשימת תיוג לבדיקת תהליך התחקור
· מי המתחקר, מה הקשר שלו לפרויקט?
· האם בוצעו תחקורים דומים בעבר?
· מה בדיוק המנדט? האם הוגדר בברור מה יתוחקר ומה לא?
· האם מונתה ועדת היגוי? סמכות פרויקטלית, או גם כלל ארגונית?
· האם אכן נסקרו כל הרכיבים שהוגדרו לתחקור?
· האם אכן יושמו\מיושמים הלקחים?
מומלץ לבדוק את מסמך התחקור לפי רשימת התיוג הבאה:
· קצר מדי? ארוך מדי? גלישה לאפיון?
· האם מכיל מספיק מידע על מנת לקבל החלטה להמשך?
· האם ברור מהן מסקנות התחקור בטווח הקצר והארוך ומה משמעויותיהן?
· מי אישר את המסמך?
למידע מפורט יותר, ראה הקיט בדיקת תיעוד בכרך איכות.