 |
לפני שמנהלים מידע צריך לנהל את התקציב
מנהלים תקציב בתבונה. מימין: זיו מנדל, ג'ימי שוורצקופף ואלדד בר-אדון | צלם: TheMarker
בשנה האחרונה פרויקטי מערכות מידע אדירי היקף בישראל הוקפאו, הופסקו ואף הגיעו לבית משפט בעקבות חריגות בתקציב או אי עמידה בתנאים. מומחים בתחום מנתחים כשלים מרכזיים בתכנון תקציבים ומציעים פתרונות
24.08.08 | 11:22Career
תוכנות הניהול הארגוניות של היום שונות מאד מן הטפסים והקלסרים אותם החליפו - הן יוצרות תהליכי עבודה חדשים ומשנות סדרי ניהול בכל שדרות הארגון.
מסיבה זו, החלפת או שינוי מערכת מידע או מערכת ניהול ארגונית היא החלטה מהותית הדורשת חשיבה מוקדמת רבה על אופיה של המערכת אותה שוקלים לאמץ. במידה וזו אינה תואמת את אופיו ונהליו של הארגון המיישם, יקרו אחד משלושת התסריטים הבאים: או שהמערכת תיזנח ותהפוך לרוח רפאים הרודפת את העובדים, שיעדיפו להתעלם ממנה, או שנהלי העבודה ישתנו או שהמערכת תשתנה. אחד מהסיפורים הידועים בתעשיית טכנולוגיות המידע מספר על חברה פיננסית שרכשה תוכנת לניהול ארגוני שלא התאימה לתהליכי העבודה בארגון. לאחר התאמות ושינויים אין ספור לתוכנה, שמשמעותן גם עלויות ניכרות שנוספו על מחירה הראשוני של המערכת, שלא היה זול מלכתחילה, כל מה שנותר מהמערכת המקורית היה השם.
היחס המורכב בין תהליכי עבודה למערכות מידע הוא גם הסיבה העיקרית לכך שפרויקטים רבים בתחום נוטים לחרוג מהמסגרת התקציבית, ממסגרת הזמן וממסגרת הציפיות. רק באחרונה עלו מספר פרויקטים רחבי היקף לכותרות לאחר שהופסקו, הוקפאו או הגיעו לבית משפט. בסוף 2007 הושבת פרויקט המחשוב של צה"ל לאחר שנתיים של עבודה. בתחילת 2008 מחקה חברת נס טכנולוגיות 21 מיליון דולר מהחשבון שהוגש לחברת הראל ביטוח בעקבות הסכם פשרה שהושג לאחר שהשתיים נאבקו בבתי המשפט. הראל טענה שנס לא עמדה בזמנים שצוינו בחוזה בין שתי החברות. פרוייקט מרכב"ה למחשוב המשרדים הממשלתיים הלך והסתבך לאורך השנים, וממדי תקציבו צמחו מ-335 מיליון שקלים לסכום כמעט כפול - אלה רק המקרים הבולטים ביותר, כשלהם קודמות התרחשוית דומות בחברות מרכזיות במשק.
אך המצב בישראל אינו שונה בהכרח מהמצב בעולם. פיני כהן, אנליסט בחברת המחקר STKI, אמר כי יותר ממחצית מפרויקטי המחשוב בעולם נכשלים. מבין אלו, כ-20%-30% כלל לא עולים לאוויר. משיחות עם מומחים ובכירים מעולם מערכות המידע עולה כי למרות הדמיון של השוק המקומי לעולמי בכל הנוגע לבעיות בניהול תקציבי פרויקטים, הרי שלשוק המקומי גם מאפיינים ייחודיים הנובעים מאופיים של המנהל והעובד הישראלי וחלקם באקוסיסטמה הכלכלית בישראל.
"כשמגיע שלב היישום כולם מתחילים לצעוק"
"הישראלים רוצים מערכת שפועלת בדיוק לפי הדרישות שלהם, דבר שדורש שינוי ניכר של המערכת, וכמובן עולה הרבה כסף", סיפר יאיר פרנק, מנהל תחום אסטרטגיה ומערכות מידע בפילת. פרנק סבור שהתאמה כזו היא הסיבה העיקרית לנסיקה של עלויות בפרויקטי מערכות מידע. "כשחברות מתחילות פרויקט הן חושבות שיוכלו להתיישר לפי המפרט של המערכת, אך כשמגיע שלב היישום כולם מתחילים לצעוק וההנהלה פתאום דורשת ממנהל הפרויקט לשנות את המפרט. בסופו של דבר הפרויקטים האלה עולים הרבה יותר ממה שהחברה רצתה כי היא לא הצליחה להיצמד למה שהמערכת בעצם יכולה לעשות".
מגזרים מסוימים דורשים יותר התאמות. למשל, בכל הקשור לרגולציות פיננסיות, החוקים המסדירים את תנועות הכספים בין גופים מורכבים, ובעיקר שונים מאוד ממדינה למדינה. גם מערכות מתוצרת חברות ענק עולמיות, כמו סאפ או אורקל, לא נותנות פתרונות לסבך הביורוקרטי הכרוך בהוצאת תלוש משכורת של עובד ישראלי.
על מנת להתמודד עם תנאים אלו ממליץ פרנק להקצות כ-20% מהתקציב לשינויים בלתי צפויים בפרויקטים שבהם התוכנה מפותחת מתחילתה ועד סופה, ו-10% בפרוייקטים הכרוכים בהתאמה של תוכנה קיימת לארגון. לפי נתוני חברות מחקר, שיעורים אלה כפולים מהשיעורים המקובלים בתכנון פרויקטי מערכות מידע בעולם.
"פעמים רבות מנהלי מערכות מידע (מנמ"רים) יודעים שאם היו מציינים לוחות זמנים ריאליים ותקציב ריאלי הם לא היו מקבלים תקציב. הרי תמיד אפשר להסביר מדוע דרושה תוספת", אמר זיו מנדל, מנכ"ל ג'ון ברייס, חטיבת ההדרכה וההטמעה של חברת מטריקס. "מצד שני, ספקים מגישים לוחות זמנים לא ריאליים כדי לזכות במכרזים. ספקים לפעמים אומרים 'בפרויקט הזה אני זוכה, לא משנה מה, כדי לתפוס מומנטום'. בסופו של דבר הלקוחות מפסידים מזה כי תמיד יש שינויים, וספקים שמפריחים הבטחות באוויר לא יכולים להתמודד עם השינויים האלה".
"באחד מפרוייקטי הטמעת סאפ הראשונים שבוצעו בישראל, המנמ"ר פוטר רק כי הכניס המון שינויים במערכת", המשיך מנדל. "כיום זה שונה - מנמ"רים יודעים לשים גבולות. כיום גם תוכנות שמוטמעות ללא שינויים אחראיות להמון פרויקטים מוצלחים, כמו הפרויקט להטמעת מערכת שירות לקוחות בשירותי בריאות כללית. בנוסף, ארגונים בישראל למדו שהם צריכים להתאים את עצמם לתהליכי עבודה שנוצרו בארגונים בולטים בשוק שצברו ניסיון בעבודה עם תוכנות ארגוניות מסוימות".
היבט נוסף הגורם לחריגה מתקציבים הן עלויות שלא נובעות מפיתוח או התאמה של תוכנה. מחקר של ג'ון ברייס מצא כי חברות בארה"ב משקיעות כ-17% מתקציבי מערכות מידע בהדרכת עובדים ובהנחלת תהליכי עבודה חדשים הקשורים לתוכנות ארגוניות. מנדל, שלו ניסיון רב בפרויקטים כאלו, אמר כי האחוז המקביל בישראל קרוב יותר ל-5%. לדברי פרנק, דווקא בישראל יש להקצות שיעור גדול מהתקציב להדרכת העובדים רב. "במקביל לבחירת המערכת צריך לעבור תהליך גדול מאוד של הטמעת השינוי בכל רמות הארגון. צריך להקדיש יותר כסף ותשומת לב לניהול השינוי מאשר בחו"ל - בערך 20%".
לטענת כהן, סיבה נוספת לצורך בשינויים מרחיקי לכת היא הזמן הרב שעובר בין יצירת הקשר בין עם ספקיות ויצירת המפרט ועד להתחלת הפיתוח. "במהלך הזמן שהחברה המטמיעה עובדת על המפרט הארגון משתנה והשוק משתנה, ואז נוצרות דרישות אחרות", אמר כהן. "פיתוח המפרט נמשך שנה, וגם אז הדרישות של הצוות משתנות".
לא צריך למנוע שינוי
"כמובן שלא צריך למנוע יכולת שינוי", פסק מנדל. "באחת מחברות הביטוח הגדולות דורש כעת המנמ"ר מכל מנהל שבא אליו עם דרישה לשינוי במערכות הארגוניות להציג נתוני החזר על השקעה - נתונים מדוייקים על צפי הרווח או החסכון של החברה לעומת ההוצאות הנדרשות לשינוי. מעבר לכך, גם במידה שהשינוי מוצדק, דואג המנמ"ר להסביר למנהל היטב את העלויות". השיטה המומלצת להוספת מאפיינים לפרויקטים קיימים, על פי מנדל, היא להחליף מאפיין אחד באחר - אם דרישה אחת התקבלה צריך להבין שדרישה אחרת תרד - הרי חייבים לעמוד בתקציב. כך, למשל, מנהל שירצה להוסיף אפשרות ליצור דו"חות שעות עבודה יתבקש לבחור אפיון אחר עליו יוותר, כמו למשל דו"חות על ספקים".
לטענת כהן, התכנון התקציבי הלקוי נובע, לפחות בחלקו, מהעלות הנמוכה באופן יחסי של כוח האדם בישראל. "נגיד שאני רוצה לקשר בין חלקים שונים של המערכת - למשל בין מצבת העובדים למערכת הדיוור הפנימית - אני יכול להכניס מראש כלים שיוכלו לעשות זאת כשהבקשה תעלה, בעלות ראשונית גדולה. מצד שני, אני יכול לקחת שניים שלושה אנשים שיפתחו מערכת כשיהיה בה צורך, מכיוון שלפעמים הם עולים פחות מרכישת מערכת".
מערכת המחשוב של בנק המזרחי היא דוגמה בולטת לשימוש ביכולות פיתוח עצמיות. בנק המזרחי משתמש ב-OS2, מערכת הפעלה מיושנת מאד של יבמ. למרות ש-OS2 אינה נתמכת על ידי יבמ כבר שמונה שנים, סומכים מנהלי המערכות בבנק על המפתחים הפנימיים, וכך חוסכים בעלויות של שדרוג המערכת. גורמים בתעשייה טוענים שהמערכת לא רק חוסכת עלויות, אלא גם פועלת מצוין וכמעט ללא תקלות.
אומרים ליועץ לאילו מסקנות להגיע
אחת הבעיות אותן מציינים המומחים כרלוונטית ביותר לשוק הישראלי היא התנהלות של חברות מול יועצים בתחום מערכות המידע. יועצים, על פי רוב, הם נציגים של החברות המתמחות בהטמעה, כמו מטריקס, נס, או טלדור, או נציגים של חברות המתמחות בייעוץ בלבד. "חטא הגאווה שלנו, התחושה שאנחנו יותר חכמים מכולם, פוגעת בנו רבות", אמר פרנק. "ראינו את זה בהרבה מאוד מקומות: במערכת השלטונית, בצבא ובמגזר הציבורי. אנחנו פחות פתוחים לייעוץ. עם זאת, אולי גם שוק הייעוץ צריך להתמקצע - יש בישראל יועצים שלא לוקחים את העסק ברצינות הראויה ובאחריות הראויה".
מנדל סבור כי הבעיה העיקרית היא דווקא ביחס ליועצים: "יש הרבה יועצים בישראל - אז כנראה שכן שוכרים אותם. הבעיה היא ביחס אליהם. גם כשכבר לוקחים, עושים את זה ככיסוי תחת. פעם הזמינו אותי לייעץ לארגון בטחוני. המנמ"ר ביקש ממני תוכנית למערכת אבטחת מידע והגשתי לו את הצעה שהתייחסה למערכת בסדר גודל של 30 אלף דולר. הוא דחה אותה בלי לחשוב פעמיים. בהצעה הבאה הגשתי לו תוכנית בעלות של חצי מיליון דולר. את התוכנית הזאת הוא קיבל, למרות שחצי מיליון דולר היה חצי מתקציב מערכות המידע שלהם. לפני חצי שנה פגשתי את אותו מנמ"ר ושאלתי אותו מה עלה בגורלה של אותה תוכנית. הוא אמר לי שאם הוא היה מגיש את התוכנית הראשונה שהצעתי לו למנכ"ל, היא ודאי היתה מאושרת ואז הוא היה אחראי לביצועה. עם הצעה של חצי מיליון דולר לא היה שום חשש כזה. בישראל מנסים לקחת את היועץ הכי זול כי הוא בדרך כלל יגיד את מה שמצפים ממנו לומר".
שיטות תמחור חלופיות
לדעת מומחים רבים, דעתנות, ביטחון עצמי ויצירתיות הן התכונות המאפיינות את מנהל מערכות המידע הישראלי. תכונות אלו משליכות כמובן גם על אפשרויות הרווח, אך הן גם מעלות את ההיתכנות להתנפחות תקציבים. בכל הנוגע לשיטות שימנעו התנפחות תקציבים, ממליצים המומחים על שתי שיטות, האחת שיטת פיתוח תוכנה המכונה Agile והשנייה היא שיטת תקצוב בשם קוסט-פלוס. כהן סבור ששימוש בשיטת פיתוח התוכנה Agile Software Development, שבה צוות פיתוח קטן פועל באופן הדוק מול הארגון שהזמין את הפרויקט, תוכל לסייע לפתרון בעיות התנפחות התקציב. בשיטה זו הצוות המפתח נדרש להציג תוצאות שעומדות לבחינה כל שבועיים. כך מתנהלים הפיתוח וההטמעה באופן הדוק הרבה יותר. בין הארגונים שמיישמים את Agile נמנים צה"ל וזרועות הביטחון. "Agile מוריד את עלויות הפיתוח ב-50% - נתון מדהים כשלעצמו. בארה"ב השיטה כבר מאד רווחת", אמר כהן. עם זאת, לדבריו, השיטה אינה מקובלת בארגונים מוסדיים "מכיוון שאלו לא רוצים לעבוד בשיטה שאין בה מפרט עבודה מוגדר".
אלדד בר-אדון, מנכ"ל חברת אימפרוב ולשעבר מנכ"ל One1, מעדיף גם הוא שיטות מודולריות כמו Agile. "לא הייתי בכלל נכנס לפרויקט שאמור להימשך שנה", אמר בר-אדון. "שלושה חודשים מתכננים את הפרויקט, תשעה חודשים עובדים עליו, ועד שמראים תוצאות הסביבה העסקית כבר השתנתה לחלוטין". צחי טוחן, שותפו של בר-אדון הוסיף: "לא רק שהסביבה העסקית השתנתה - גם האדם שקיבל את ההחלטות התחלף".
להבדיל מ-Agile, שרלוונטית רק לפרויקטים של פיתוח תוכנה, שיטת קוסט-פלוס רלוונטית לכל סוגי הפרויקטים. בשיטה זו מתחייב הלקוח לשלם את מלוא עלויות הפיתוח וסכום נוסף, קבוע או לפי אחוזים מן העלות, שמועבר למיישם. להבדיל משיטות התקצוב המסורתיות, בקוסט-פלוס לא נקבע תקציב מראש. "קוסט-פלוס היא שיטת תקצוב שבה כולם מרוויחים", אמר ג'ימי שוורצקופף, ראש חברת המחקר STKI. "לא ניתן לדייק בחיזוי העלות המדוייקת של פרויקט מחשוב גדול. קוסט-פלוס עונה על הבעיה הזאת. עם זאת, השיטה מתאימה כמובן רק ללקוחות ולספקים שיצרו ביניהם מערכת של אמון מלא". שלא במפתיע, שיטת ההתקשרות הזו עוד לא זכתה לתפוצה רחבה בשוק הישראלי.
להתמקד באנשים, לא בטכנולוגיה
ב-2001 התאספה קבוצה של מומחים באתר הסקי סנואובירד שביוטה ויצרה מנשר חדש בתחום פיתוח התוכנה. המנשר, שקרא לפיתוח תוכנה ממוקד באנשים ולא בטכנולוגיה, איגד כעשור של התפתחויות בשיטות פיתוח התוכנה, שזכו לשם Agile Software Development, או פשוט Agile.
צוות מפתחים שעובד בשיטה זו יתמקד בשביעות הרצון של הלקוח, באמצעות צעדים קטנים ובעלי שימושיות בפני עצמם והתנהלות פנים אל מול פנים. השיטה מבוססת על עבודה בצעדי פיתוח קטנים אך מלאים: צוות פיתוח קטן מתמקד ביצירת מוצר מוגמר בפרק זמן של שבועיים עד חודש, כשבלוח זמנים זה מבצע הצוות את כל השלבים הנדרשים בפיתוח המוצר - מתכנון ועד ביצוע. מחזור של פעולות כאלו יוצר, בסופו של דבר, פיתוח מלא. אופן עבודה זה מהדק את הקשר בין דרישות הלקוח למוצר הסופי. Agile מפחיתה באופן ניכר את הצורך בתיעוד התקדמות, שכן היא נמדדת במוצרים מוגמרים עצמם. לרוב נלווית אל Agile מתודולוגיית העסקת כוח אדם המכונה - Scrum עבודה בצוותים של 5-9 מפתחים ללא היררכיה ברורה, על פי רוב בסביבת עבודה פתוחה, כשלפחות אדם אחד בצוות הוא מהחברה שהזמינה את הפרויקט.
ההבדל העיקרי בין עבודה ב-Agile לשיטות אחרות הוא הפער שבין תוכנית מתווה לתכנון אדפטיווי - בעוד שמפרטי הפיתוח המקובלים קובעים מראש את צורתו של המוצר המוגמר, המוצר המתקבל ב-Agile נוצר לאורך זמן ובהתאמה לתוצאות בכל שלב.
בין חסרונותיה של Agile, הברור ביותר הוא חוסר היכולת לצפות את אופיו של המוצר המוגמר, את זמן הפיתוח ואת היקף התקציב. בעיה אחרת היא שהעבודה יכולה להיעשות רק על ידי מפתחים מנוסים. מעבר לכך, להבדיל משיטות מקובלות יותר לתקצוב ושיטות היררכיות שמשרטטות את פיתוח המוצר מן המסד ועד הטפחות, Agile מצריכה אופי ניהולי שלא מתאים לכל ארגון גדול. ארגונים ממסדיים גדולים, המחויבים בדיווח מתמיד לדירקטוריון ולבעלי מניות, יצטרכו להכין את עצמם מראש לבעיות הדיווח הנובעות מן השיטה.
עוד בנושא - פרוייקט מיוחד: תעשיית ההיי-טק והדולר | מנהל מערכות מידע בארגון חייב להיות איש חזק, קר רוח, והכי חשוב - תקשורתי | טסים לעבודה |