תפריט נגישות

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

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

 1.רקע.

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

· תכולה.

· איכות הפתרון.

· השקעת זמן ומעורבות מצד הלקוח.

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

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

להלן פרוט קצר על כל אחד מגורמים אלו.

2. הסיבות העיקריות למשברים בפרויקט

2.1. אי הסכמה על תכולה (או: תאום ציפיות לקוי).

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

2.2. איכות הפתרון (או: מה חשוב יותר, הטכנולוגיה או המהות).

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

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

2.3.השקעת זמן ומעורבות מצד הלקוח (או: מחויבות אמיתית , מה היא?)

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

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

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

3.משברי משנה - חריגה מלוחות הזמנים ומתקציב

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

אבל, למרות שנראה שרוב המשברים פורצים על בסיס לוחות הזמנים או העלויות – התמונה שונה.

חשוב מאד להבין נקודה זאת. ברוב המקרים המשבר של העלות או לוחות הזמנים הינו תוצאה של אחד המשברים שתוארו למעלה ורק לעיתים נדירות המשבר פורץ בגלל זמן או כסף!

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

4.אין נמנעים ממשבר?

4.1.תכנון, תכנון, תכנון

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

התכנון נוגע לכל שלב בפרויקט:  

הגדרת המטרה - יש להתחיל מהגדרת הבעיה: מה העסק צריך, מה רוצים לפתור ולמה (ראה מאמר בנושא). מהלך זה נקרא IT BUSINESS ALIGNMENT – בדיקת הערך המוסף העיסקי  שהמהלך  יתרום מבחינה עסקית.

גילינו לדוגמא באחד המקרים כשהלקוח חשב שעליו לרכוש  מערכת ERP חדשה, שהפתרון הנכון להשגת מטרות הארגון הוא הטמעה של תוכנה לרצפת הייצור והתממשקות למערכת הקיימת, או לקוח אחר שחשב שהוא חייב פתרון רחב, מקיף וכולל (1,000,000$ עלות מוערכת ופרויקט של שנתיים), הבין כי פתרון נכון לצרכים היה פתרון ממוקד, קטן בהערכה של כ 200K$  במשך 6 חודשים. 

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

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

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

4.2.תיחום נכון

אחת הסיבות לחריגות בפרוייקט היא תיחום לא מוגדר בהתחלה ואי שמירה עליו בהמשך.

כל מילה נוספת בנושא זה מיותרת.

4.3.האפיון.

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

בעת ביצוע האפיון צריך לשמור על הכללים הבאים:

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

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

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

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

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

4.4.מעורבות הלקוח בפרויקט

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

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

4.5.ניהול הפרויקט.

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

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

4.6.היישום וההטמעה

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

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

5.הטיפול בעימותים במהלך הפרויקט

ברוב המקרים מתעוררים משברים במהלך הפרוייקט. עקרונות הטיפול במשבר בפרויקט תוכנה זהה לחוקים בכל מקרה אחר:

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

ב. אל תטייח. אם מתחילה מחלוקת – תציף אותה גם לדרגים הגבוהים של הארגונים, וטפל בה. 

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

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

6.היועץ.

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

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

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

7.סיכום.

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

1. IT Business Alignment - המצפן העיסקי של הפרויקט

2.תהליכי עבודה עיקריים - מפת הדרכים של הפרויקט

3. איפיון מפורט ו-CRP, ותוכנית עבודה מפורטת -  כלי העבודה של הפרויקט.

4. הנהלה וספק מחויבים.

5.מנגנונים מוגדרים של פתרון משברים.

6.יועץ מומחה / מנהל פרויקט  מלווה

 כותב המאמר: דודי אברמוביץ, מנכ"ל משותף בחברת אלטרנטיבה

 ליצירת קשר: dudi@alternative.biz