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