89... PFI- Private Finance Initiative

Transcription

1 הועדה לבדיקת פרויקטים גדולים של פיתוח תוכנה בממשלה מסמך מסכם ירושלים, מרץ 2010

2 תוכן עניינים מבוא...3 המלצות הועדה...5 סיכום המלצות המנמ"רים פרק 1 פ- רויקטים במערכות מידע- הצלחות וכישלונות...23 תקציר מנהלים סקירה- פרויקטים של IT בעולם...29 בעיות מרכזיות בניהול פרויקטים של...31 IT פרויקטים של IT בממשלה...37 מורכבות הפרויקט הממשלתי...39 גורמים המשפעים על מידת הצלחת פרויקטים בממשלה...41 גורמים ספציפיים לכישלון IT בממשלה...43 מתודולוגיות...47 פרק 2 רכש תקציר מנהלים מחזור החיים של שלב הרכש- פרויקטים של מערכות מידע...53 מניעת קשיים או התמודדות עימם בשלב הרכש...54 נתיבי הבריחה של הזמן...55 המלצות לשיפור העתיד סקירה משווה- שלב הרכש...62 פרק 3 ש- יטות התקשרות...70 תקציר מנהלים מיקור חוץ...72 חוזים...77 סוגי חוזים קביעת סוג החוזה...80 מודלים של תשלום PFI- Private Finance Initiative אבני דרך חוזים מודולרים פרק 4 מ- כרזים...98 תקציר מנהלים תהליכי רכש דיאלוג תחרותי Dialogue) (Competitive היבטים שונים במכרז מערכת היחסים עם הספקים רמת המאקרו- יחסי הממשלה ותעשיית הIT רמת המיקרו- יחסי המשרד והספק במהלך הפרויקט קשיים העולים מצד הספקים פרק 5 מ- קרי בוחן מקרי בוחן משווים מקרי בוחן- ישראל ביבליוגרפיה נספחים

3 מבוא הועדה לבחינת ההצלחה והכישלון במכרזים ובהתקשרויות לביצוע פרויקטים גדולים לפיתוח תוכנה בממשלה, מונתה על ידי מר טל הרמתי, סגן החשב הכללי. מסמך זה, נועד לסכם את פעילותה של הועדה ולהגיש את המלצותיה. חברי הועדה הם: יו"ר הועדה - אודי נסימיאן, מנמ"ר משרד המשפטים; חבר ועדה יהודה סרוסי, סמנכ"ל מערכות מידע, המוסד לביטוח לאומי; חבר ועדה שמעון זמיר, ראש אגף תקשוב במשרד החוץ; חבר ועדה דן בן סימון, מנהל אגף מערכות מידע בהוצאה לפועל; חבר ועדה - אביב מצא, נציג משרד החינוך; חבר ועדה ד"ר נחמן אורון, יועץ; חבר ועדה ד"ר רועי גלברד, יועץ; מרכזת הועדה מילכה נשיאל, משרד האוצר; עוזרת מחקר לועדה - מעין רוזנברג-שץ. מסמך זה מבקש להביא לידי ביטוי את עבודת הועדה ועוסק בנושאים של הערכת פרויקטים, הצלחה וכישלון, התקשרויות, חוזים ומכרזים במערכות מידע. המסמך מאגד את החומרים שעלו בפגישות הועדה ומסתמך על מקורות שונים- מסמכים ממדינות שונות בעולם המערבי, אתרי האינטרנט של מדינות אלה, מאמרים אקדמיים ומחקרים שונים. כמו כן, נערך סבב ראיונות עם מנמ"רים במשרדי ממשלה שונים, על מנת לקבל תמונה הוליסטית על המתרחש בשטח. המסמך בנוי מפרקים של סקירה תיאורטית ועולמית, אשר בתחילת כל אחד מהם מצוי תקציר מנהלים. לאחר מכן, מובאים מספר מקרי בוחן מהארץ ומהעולם. תקציר נושאי הפרקים: פרק 1, פרויקטים במערכות מידע- הצלחות וכישלונות: פרק זה מבקש לבחון את גורמי ההצלחה והכישלון של פרויקטים במערכות מידע. הפרק פותח בדיון בשאלה מה הם המדדים להצלחה וכישלון וממשיך בהצגה של נתונים סטטיסטיים על הצלחה וכישלון של פרויקטים במערכות מידע בעולם על פי אחת משיטות המדידה. לאחר מכן, הפרק מפרט את הבעיות המרכזיות בניהול פרויקטים של,IT כאשר על פי רוב הקשיים נובעים מן הגורם האנושי ולא מן הגורם הטכנולוגי. כמו כן, ניתנים דגשים על מקומות של קושי ואפשרויות לשיפור, ברמה המתודולוגית. החלק האחרון של הפרק, עוסק בהצלחה וכישלון של פרויקטים במערכות מידע, בממשלה. מוסברת המורכבות של הפרויקטים הממשלתיים ונמנים גורמים המשפיעים על מידת הצלחתם. פרק 2, רכש: פרק זה מבקש לבחון את שלב הרכש כמכלול. ראשית, הפרק מציג את מעגל החיים מלווה בהסבר לגבי נקודות הביקורת מודל זה, של שלב הרכש בפרויקטים של מערכות מידע. 3

4 הקריטיות- על פי משרד המסחר הבריטי. לאחר מכן, הפרק מבקש לזהות את הגורמים לעיכובים וקשיים בשלב הרכש ומוצעות המלצות כיצד להימנע או להתמודד עם גורמי הקושי, על מנת לאפשר את הצלחת הפרויקט. בסופו של הפרק מובאת סקירה עולמית על מדיניות ומצב הרכש בארה"ב, קנדה ואוסטרליה. פרק 3, שיטות התקשרות: הפרק עוסק במספר תתי-נושאים של שיטות התקשרות. ראשית, ישנה התייחסות לבחירה במיקור חוץ, לפיתוח של מערכות מידע ממשלתיות. לאחר מכן, מובאת סקירה של סוגי החוזים האפשריים לשימוש ברכש של IT ומובאים מספר שיקולים לבחירה בסוג החוזה. כמו כן, מפורטים היתרונות והחסרונות של החוזים הנפוצים ברכש של מערכות מידע. לבסוף, נסקרים שלושה מודלים של תשלום- הPFI אשר איננו מומלץ, אבני הדרך והחוזה המודולרי. פרק 4, מכרזים: פרק זה עוסק בהליכי המכרז. הפרק מונה ארבע שיטות של הליכי רכש ומבקש לעדכן בהליכי רכש חדשים הנהוגים בעולם. לאחר מכן, הפרק מפרט היבטים שונים במכרז כגון עלויות לספקים ומספר משתתפים. בהמשך, עוסק הפרק ביחסי הממשלה והספקים ובוחן אותם הן ברמת המאקרו יחסי הממשלה והתעשייה, והן ברמת המיקרו- היחסים בין הלקוח והספק בפרויקט. לבסוף, מובא סיכום של דברי הספקים כפי שהם נמסרו לוועדה. פרק 5, מקרי בוחן: פרק זה מציג שלושה מקרי-בוחן מן העולם ושלושה מקרי-בוחן מן השנים האחרונות בישראל. המקרים מתארים את השתלשלות הפרויקטים ומעלים מסקנות מאשר אירע. חברי הועדה והעומד בראשה מבקשים להודות לנציגי מנהלי מערכות המידע בממשלה, נציגי הספקים, נציגי המגזר העסקי וכל מי שהופיע בפני הועדה והביא את דבריו לעבודת הועדה. 4

5 המלצות הועדה פרק זה נועד לסכם את ההמלצות העולות מפעילות הועדה ומן הסקירה של הדו"ח. מפאת קוצר הזמן וריבוי הנושאים שעל שולחנה של הועדה, זיהתה הועדה את הנושאים העיקריים שלדעתה יש לשנות ואשר בהם יש לטפל. הועדה ממליצה כי נושאים אחרים יטופלו על ידי גוף הCIO הממשלתי, שהוא האכסניה לטיפול בנושאים אלה וממליצה לקבוע מסגרת הנחיות אופרטיביות בכל אחד ואחד מן הנושאים המובאים בהמלצות שלהלן. ההמלצות מתייחסות לכל פרויקט בכל סדר גודל. יחד עם זאת, אנו ממליצים כי בפרויקטים גדולים (מעל 4 מליון ) ההמלצות יהיו מחייבות. הפרק יתייחס להמלצות הבאות: מדדים לבחינת פרויקטים משרד CIO ממשלתי הקמת פונקציית IT Governance -OCIO חוק חובת המכרזים ותקנות התכ"ם שימור ושיתוף ידע הכשרה מקצועית מתודולוגיה אחריות ניהולית התקשרויות שיטות המכרז סוג החוזה מסגרות חוזיות אחידות להתקשרויות ממשלתיות שעניינן מחשוב סעיף שביעות רצון קודמת כוח אדם מקצועי עובדים מן החוץ עובדי תקן הפרדה בין פיתוח לתחזוקה שוטפת שיתוף פעולה עם התעשייה 5

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

7 משרד CIO ממשלתי במדינות העולם המערבי, קיימת לרוב יחידה המרכזת את נושא סטנדרטיזציית ותפיסת הIT הממשלתית ומשתייכת על פי רוב למשרד ראש הממשלה או למשרד מתווה מדיניות כלל ממשלתית אחר. יחידה זו אחראית, לרוב, על פיתוח של נושא הIT ברמת האסטרטגיה, המדיניות והפרקטיקות המומלצות, באמצעות איסוף מידע תיאורטי וידע הנלמד מהשטח ומהווה אתר לייעוץ עבור המנהלים. יחידה זו, גם עשויה לעסוק בבחינת מתודולוגיות אפיון שונות ובקביעת מתודולוגיית ניתוח אחידה. בקרב המנמ"רים עימם שוחחה הועדה, הועלה הצורך ביחידה כזו, אשר תוכל לרכז את נושא הIT כך שתוכל לסייע בקביעת מדיניות ותאפשר להציג קול אחד לגבי נושאים שונים הקשורים לIT בממשלה. יחידה כזו עשויה להוות פה לקשיי רכש ייחודיים הקיימים בתחום הIT. המלצה 2: מומלץ להקים יחידת CIO כלל ממשלתית, אשר תגדיר את מדיניות ואסטרטגיית המחשוב לממשלת ישראל לשנים הבאות. סמכויות היחידה ינועו על הקו שבין גוף מנחה לגוף מבצע. המוצבת במשרד סמכות לאומית בעלת יחידה הממשלתי הוועדה רואה במשרד ה- CIO אסטרטגי. מכוח זה גם ייגזר מעמד גופי הIT במשרדים עצמם. הרכב וסמכויות הגוף אשר יגיש את הוועדה ממליצה להקים צוות שיגבש את מבנה, המלצותיו לאישור הממשלה. בין היתר יבחנו הנושאים הבאים: קביעת מדיניות ואסטרטגיית המחשוב הממשלתית o מעורבות באישור תוכניות עבודה ותקציבי המשרדים o סטנדרטים ומתודולוגיות o סמכויות ועדת תקשוב מרכזית. o ביצוע/ תקצוב פרויקטים רוחביים o תקנון עובדי המחשוב o רכש וחוזים o הקמת פונקציית IT Governance -OCIO פונקציית ה- OCIO הינה יחדה שתפקידה לתמוך ביעדים ובמטרות הארגון על ידי יישור פעילות מערך המחשוב עם היעדים האסטרטגיים של הממשלה ולהבטיח כי המימוש בפיתוח ובתחזוקה נעשה בראייה מרבית של עלות/תועלת. בארה"ב מוגש כל שנה דו"ח מסכם לקונגרס, על הנעשה בתחום הIT באותה השנה. משרד ה- OCIO האמריקאי פועל מתוך שקיפות מלאה לציבור לגבי הפרויקטים במשרדים השונים. בבריטניה קיים גוף במשרד המסחר, האחראי על בידוק של הפרויקטים הגדולים. הביקורת נעשית בנקודות קריטיות לפרויקט, ואורכת 3-5 ימים. לאחר הביקורת ניתנות נקודות לשיפור 7

8 ומוענק לפרויקט צבע המעיד על מגמתו- ירוק (חיובי), צהוב (מאותגר), אדום (בעייתי). הבריטים, בתוך שנתיים הם חסכו יותר מ 500 מליון ליש"ט במונחים של תמורה לכסף. לטענת המלצה 3: במסגרת יחידת ה- CIO, תוקם פונקציה שתפקידה לנהל את מטה המנמ"ר הממשלתי ולהוציא מן הכוח אל הפועל את תפיסת המשילות הניהולית Governance.IT הפונקציה תפעל להנחלת תוכנית עבודה, מדידה ובקרה והטמעת נהלי עבודה אל מול משרד הממשלה. השירותים המסופקים על ידי מערך המחשוב ינוהלו באופן אחיד, שקוף, מדיד ובעל הלימה עסקית ברורה. מנגנוני היחידה יתמקדו בניהול האסטרטגי של מערך המחשוב, הכולל תכנון רב שנתי, ניהול נכון של דרישות, קביעת סדרי עדיפויות, ניהול אינטגרטיבי של משאבים וסיכונים. חוק חובת המכרזים ותקנות התכ"ם חוק חובת המכרזים בצורתו הנוכחית אינו מותאם לייחודיות הרכש של פיתוח תוכנה. החוק אינו מתחשב בצרכיו הייחודיים של הרכש- מדובר בשוק דינאמי אשר משתנה ומתהווה בקצב מסחרר. כיום, תהליך הרכש הוא ארוך ונוקשה מכדי לענות לצרכי רכש פיתוח תוכנה. סיבוכיות הפרויקטים הגדולים הינה גדולה גם במגזר העסקי וקשיי הרכש הממשלתיים רק מוסיפים על מורכבות הפרויקטים ובכך מפחיתים את סיכויי הצלחתם. הקשיים העיקריים הם בתחום הגדרת הדרישות- חוק חובת המכרזים אינו מציע את הגמישות המספקת לשינויים אשר בתחום פיתוח התוכנה הינם בלתי נמנעים ומהווים חלק בלתי-נפרד מן הפרויקט. כפי שהדברים מתנהלים כיום קיים מעט מאוד שיקול דעת למנמ"רים ולוועדות השונות, להענקת מרחב תמרון בתוך הפרויקט ובהתאם לצרכיו. כמו כן, אין היום כמעט פעולה שאינה עוברת דרך הועדות והסכומים שנקבעו לעלייה לועדות הינם זעירים במונחים של השקעות.IT חוסר הגמישות מתבטא גם בנוגע לאומדן שכמעט ואינו מאפשר טעויות/שינויים. המלצה 4: מומלץ למנות בהקדם צוות שיכלול מנמ"רים ומשפטנים אשר יבחן את חוק חובת המכרזים ותקנות התכ"ם. הוועדה ממליצה לאמץ את הערות המנמ"רים לתקנות חובת המכרזים (ר' נספח 10). o יש להנחות גוף זה להציע שינויים ייחודיים בחקיקה לתחום מערכות המידע במגמה להבטיח כי שלב הרכש לא יהווה גורם מעכב עבור הפרויקטים. o לשקול ביצוע מכרז סגור (עד 3 ספקים) לטכנולוגיות המידע, בסמכות ועדת ענ"א משרדית עד לסכום של שני מליון. 8

9 שימור ושיתוף ידע מצאנו כי מדינות בעולם שמות דגש רב, על למידה מתמדת ומשותפת מן הפרויקטים. גם ממקרי הבוחן השונים בארץ, עלה כי למידה מניסיון העבר סייעה לפרויקטים להימנע מטעויות. אצל הבריטים, קיים ריכוז של הידע שנצבר מן הפרויקטים השונים אצל משרד המסחר וכן המשרד יוצר מדריכים שונים לשיפור הפרויקטים, כאשר החומרים שנאספו מופצים למשרדים. ברוב המדינות, קיימים פורומים מקוונים לשיתוף ידע. בישראל כיום, אין גוף המרכז את הידע הרב המצטבר מן הפרויקטים שנעשו ושעודם בתהליך. המלצה 5: מומלץ להקים גוף שיתוף ידע בין המשרדים, בו יהיו חברים גם יועצים העובדים עם הממשלה. בכל משרד ימונה אחראי לתחום ניהול הידע הטכנולוגי. שימור ושיתוף הידע שנצבר מפרויקטים הינו בעל ערך קריטי. כיום, אין גוף המרכז את הידע הרב המצטבר מן הפרויקטים שנעשו ושעודם בתהליך. גוף הידע, יעבד ויפיץ אותו לכל המשרדים על מנת שניתן יהיה ללמוד מן המתרחש בשטח- ולהשתמש בידע זה באופן המיידי ביותר. הכשרה מקצועית כפי שצוין, עולם המחשוב הינו דינאמי ומתפתח במהירות. דורות הטכנולוגיה מתקצרים והעדכניות הטכנולוגית של העובדים הינה קריטית להצלחה. לפיכך מומלץ כי יוקצה תקציב הדרכה אשר יאפשר את רמת העדכניות הטכנולוגית הנדרשת. גם ברמת מנהלי הפרויקטים, נמצא כי למיומנות ולניסיון ערך רב ועל הממשלה לקדם הכשרות לקידום מיומנויות הניהול. בארצות שונות בעולם, קיימים גופים המבצעים ימי הכשרה ורענון למנהלי הIT הממשלתיים. נושא זה, ממוקם כיום גבוה בסדר העדיפויות של מדינות העולם המערבי אשר שוקדות על הנחת סטנדרטים לפרקטיקות ניהול של IT ועל פיתוח דרישות פורמאליות למיומנויות אנשי הפרויקט, וראוי כי יבחן היטב גם בישראל. טכנולוגית כך שתשמר את רמת להקצות תקציב יעודי לצרכי הדרכה והכשרה המלצה 6: מומלץ העדכניות הטכנולוגית הנדרשת. הועדה ממליצה כי תקציב ההדרכה יעמוד על סך של 3% מסך כל תקציבי המחשוב. לכל עובד/ת יקבע מסלול הכשרה רב שנתי המתאים לתחום בו הוא עוסק. 9

10 מתודולוגיה כיום אין מתודולוגיה אחידה הנהוגה בממשלה וכל משרד מבצע כמידת יכולתו ורצונו, רענון של המתודולוגיה. כמו כן, לא קיים גוף המבקר את הנושא המתודולוגי בממשלה. 1 פיתוח אינקרימנטלי- הפיתוח האג'ילי הינו פיתוח זריז של תוכנה. השיטות המשתייכות לזרם האג'ילי, מתבססות על פיתוח איטרטיבי, כאשר הדרישות והפתרונות מתפתחים לאורך הדרך, באמצעות שיתוף הפעולה של צוות הפיתוח, המורכב מבעלי תפקידים שונים והלקוחות. בחלק משיטות האג'ייל גם מתאפשרת לפתח בו זמנית מספר מרכיבים. המניפסט לפיתוח תוכנה אג'ילי (דצמבר, 2001) קובע את סדר העדיפויות הבא: "אנשים ויחסי גומלין על פני תהליכים וכלים, תוכנה עובדת על פני תיעוד נרחב, שיתוף הלקוח על פני מו"מ חוזי, תגובה לשינוי על פני היצמדות לתוכנית. כלומר, יש ערך ברשימה כולה, אך אנו מעריכים יותר את הפריטים המודגשים". השיטה, מבוססת על ההנחה כי לא ניתן להגדיר תוכנה במלואה וכי טעויות מתרחשות תמיד ולפיכך מתמקדת ביכולת הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי פיתוח. הדיאלוג בין הלקוח, המפתחים וההנהלה מודגש מאוד בשיטה זו. הלקוחות, מקבלים תוצרים תוך פרקי זמן קצרים יחסית ויכולים לבצע שינויים תוך כדי תנועה. יתרונות השיטה: הקטנת הסיכונים, גמישות בדרישות, חדשנות, קבלת תוצרים "נראים" בתוך פרקי זמן סבירים, מעקב ובקרה שוטפים ואפשרות להפסקת ההתקשרות ביתר קלות. אין זה המקום להרחיב על השיטה, אך מצאנו, כי השימוש בשיטות האג'יליות ברחבי העולם הולך וגובר כאשר מחצית מן החברות לפיתוח תוכנה שסקרה חברת גרטנר, הודיעו כי יגבירו 2 את השימוש בשיטות אלה. יתרה מזאת, במחקר שמסקנותיו מוגשות בימים אלה לצבא, הגיעו חוקרים ישראליים למסקנה כי על הצבא לעבור להשתמש יותר בשיטות האג'יליות. תוכניות פיילוט שנעשו במחקר, הוכחו כמוצלחות ונטען כי הוכחה בעבר הצלחה באימוץ שיטות האג'ייל גם בארגונים גדולים ומסורתיים. ועדה אמריקאית שחקרה את השימוש בשיטת ה- Waterfall בצבא האמריקאי מצאה כישלונות רבים בשיטה זו. המלצה 7: מומלץ להקים צוות שיבדוק את המתודולוגיה הנהוגה בממשלה ויפעל להאחדה, התאמה, רענון ומודרניזציה של המתודולוגיות. מומלץ לבחון מחדש את ההסתמכות הבלעדית על נוהל מפת"ח. מומלץ לשקול הקמת גוף רגולציה פנים ממשלתי שיפעל לתקנון עבודת יחידות המחשוב. הגוף ישמש כגוף הסמכה מקצועי למקצועות טכנולוגיות המידע. כל פרויקט פיתוח תוכנה הוא שונה ויש להתאים לו את שיטת הפיתוח. מומלץ לבחון אפשרויות לפתח בממשלה גם בשיטות האג'יליות העשויות לצמצם קשיים רבים בהם נתקל הפיתוח בממשלה ולהביא תוצרים מהר יותר לשולחן המשתמש. מתוך: אתר ויקיפדיה, 2 Heller, U. Hazzan, O. Frank, A.J. (2009). Agile Software Engineering And Its Realization In A Military Organization. Manuscript, received- December 15,

11 אנו ממליצים על ביצוע תוכנית פיילוט שתאמץ מתודולוגיות פיתוח זריזות ורזות יותר. אחריות ניהולית פרויקטים של IT נחשבים ברחבי העולם לפרויקטים מורכבים מאוד אשר השאלה כיצד להצליח בהם, עודנה מטרידה את המגזר העסקי והציבורי כאחד. המסמך מונה מספר גורמים פוליטיים, ארגוניים וטכנולוגיים היוצרים מורכבות מוגדלת של הפרויקט בממשלה. קיימת הסכמה בין המחקרים כי שני הגורמים המשפיעים ביותר על הצלחת הפרויקט הממשלתי ועל קידומו המהיר, הם הניהול והתכנון שלו. תכנון טוב, יאפשר הליך רכש מהיר יותר. ככל שהליך הרכש יתארך, כך תגדל הסבירות כי הדרישות ישתנו והפרויקט יסתבך. ברמת הניהול, עולה ממחקרים רבים וכן ממקרי הבוחן שנבחנו, כי ישנה חשיבות עליונה, לתמיכת ההנהלה הבכירה בפרויקט. חשוב כי מנהל בכיר ייקח על עצמו את האחריות לפרויקט וכן, כי השר של המשרד יהיה מיודע ומעורב בפרויקט. חשוב כי למנמ"רים יינתנו כלים תקציביים שיאפשרו גמישות לניהול הפרויקט. המלצה 8: מעורבות המנהלים הבכירים הינה קריטית. אין להתחיל פרויקט ללא הגדרת מנהל בכיר מטעם המשתמש הסופי שייקח על עצמו את האחריות המלאה להצלחת הפרויקט. תקבע שדרת קבלת החלטות ואחריות בפרויקט. יאושר מנגנון שיאפשר למנמ"ר גמישות תקציבית לניהול הפרויקטים ולאשר חריגות בהיקף של עד 10% מהתקציב של פרויקט נתון במסגרת התקציב המשרדי. מומלץ לצמצם את מספר התקנות בתקציבי המחשוב. התקשרויות שיטות המכרז באירופה, הגיעו למסקנה כי בפרויקטים מורכבים של IT ניתן להגיע לדיוק מרבי של הדרישות על ידי קיום דיון מפורט על הפיתרון שמציעים הספקים- עם מספר מצומצם של ספקים. תהליך זה, תורם לחשיבה חדשנית ומגדיל את התחרות. שיטה זאת, נמצאה על ידי האירופאים ככדאית יותר משיטת המו"מ הקיימת וכיום בבריטניה כל רכש הIT נעשה בדרך זו. עקב שוק הספקים הקטן יחסית בישראל ועלותה הגבוהה של שיטה זו, ייתכן ויש לשקול שיטה דומה שמבחינת מאפייניה תתאים יותר לישראל- ספקי בית. בשיטה זו, נבחרים 3-4 ספקים, לאחר בדיקות איכותיות מקדימות של כל הספקים המעוניינים, כאשר בין 3-4 ספקים אלה, יערכו מכרזים למשך תקופה ארוכה יחסית. יתרונותיה של שיטה זו, הם כי היא תאפשר ביצוע מכרזים מפורטים מאוד כך שהפתרונות יינתנו לפני סגירה על החוזה. מעבר לכך, השיטה תתרום להיווצרות יחסי אמון הדוקים עם הספקים, תשמר את התחרותיות ותאפשר טיפוח ההתמחויות שונות למשרדים שלא תמיד מקבלים מענה (כגון-משרד החינוך). 11

12 המלצה 9: מומלץ לבחון את שיטות המכרז. כיום בעולם מתקיימות שיטות נוספות אשר אין דומה להן במשרדי הממשלה בישראל ויתכן וניתן להפיק מהן תועלת. סוג החוזה כיום ברחבי העולם משתמשים בפיתוח מערכות של IT בעיקר בחוזים מסוג פיקס פרייס וקוסט+. המדיניות כיום הינה להתאים את החוזה לסוג הפרויקט הספציפי, בהתאם למאפייניו. קיימת טענה, כי בחוזה מודולרי קל יותר לעבוד עם פיקס פרייס. אולם, לאור הקושי הרב עם חוזה מסוג זה, כדאי לחשוב מהן האפשרויות החוזיות העומדות בפני הממשלה. ניתן לחשוב על חוזים המעוצבים באופן גמיש יותר, הנושאים גם תגמולים חיוביים ושליליים ומבטאות סיכונים משותפים לספק וללקוח. יש להיערך מבחינה תקציבית למתן תמריצים חיוביים ולא רק שליליים. חוזה הפיקס פרייס יוצר לרוב מצב של ניגוד אינטרסים בין הלקוח והספק לאחר חתימתו (לקוח- רוצה למקסם תכולות, הספק-לצמצם). מעבר לשקילת חוזים אחרים, ניתן גם להשתמש ב"הצהרת כוונות משותפת" בדומה למודל הבריטי- יצירת מסמך המטיל את האחריות על שני המנהלים הבכירים מצד הלקוח והספק, מאגד את הצדדים סביב מטרות משותפות ומגדיר קריטריונים להצלחה אשר על פיהם ימדדו שני הצדדים כשתבחן הצלחת הפרויקט. מסמך כזה נועד ליצור מטרות משותפות כך שתתומרץ העבודה המשותפת על הפרויקט. המלצה 10: מומלץ לשקול בכל פרויקט לגופו את סוג החוזה המתאים לו ולשקול חוזים, המבטאים יותר סיכונים משותפים לספק וללקוח. ניתן להציע לצדדים בפרויקט לחתום על מסמך "הצהרת כוונות משותפת" שנועד ליצור אינטרס משותף להצלחת הפרויקט. כל מנהל בצד הלקוח יהיה מחויב במסמך הסכמות לעמידה ביעדי הפרויקט. למדיניות מתקשרות מסגרות חוזיות אחידות להתקשרויות ממשלתיות שעניינן מחשוב טענות הספקים בנוגע להעדר סטנדרטיזציה של התנאים בין המשרדים, האמריקאית לפיה יש לצמצם את הסטנדרטים הייחודיים לממשלה. הממשל מעודד כיום שימוש בסטנדרטים המגיעים מן המגזר הפרטי שכן הדבר מצמצם עלויות לממשלה ומקל על הספקים. בהשוואה לחוזים בשוק סטנדרטים שונים המופיעים בחוזה, לבצע בדיקה לגבי המלצה 11: מומלץ העסקי. פורום משותף לממשלה ולספקים עשוי לבצע בדיקה כזאת. מומלץ לשאוף להנהגת שימוש בסטנדרטים עסקיים מקובלים. מומלץ להנהיג נוסח חוזה מוסכם שישמש בצורה אחידה את כל המשרדים. 12

13 בחינת ההצעות במכרזים מנמ"רים וספקים ציינו כי מוטיב המחיר עדיין משמעותי מדיי. כמו כן, לא נקבע מנגנון להתמודדות עם הצעת מחיר נמוכה מדיי. המלצה 12: מומלץ לתת משקל יתר לציון האיכות. כמו כן, יש לשקול כיצד להתמודד עם הצעת מחיר נמוכה מדיי כדי להימנע ככל הניתן מאפקט המטרייה ומספק זוכה שמפסיד כסף. סעיף שביעות רצון קודמת במכרזים של הממשלה אין ביטוי מספק לקשיי ההתקשרות עם ספקים שהפרו התחייבויות או התנהלו בהתקשרויות קודמות שלא-כשורה מול המשרדים הממשלתיים. הווה אומר, ספק שההתקשרות עימו במשרד כלשהו לא עלתה יפה, יכול לגשת למכרז במשרד אחר כמעט ללא הורדת ציון על התקשרות העבר הלקויה. חשוב לציין כי לדעת הועדה סעיף שביעות רמון קודמת, יביא לצינון הנורמה אצל חלק מן הספקים הממהרים לעתור כנגד הליכים מכרזיים ויעניק מוטיבציה לספקים לטפח התקשרות טובה. המלצה 13: מומלץ להכיל סעיף סף של שביעות רצון מן הספק, אשר לא יאפשר לספקים שבעבר לא קיימו את התחייבויותיהם לממשלה, לגשת למכרז או- יקנוס אותם בהורדת ציון (ר' דוגמא בנספח 11). כוח אדם מקצועי עובדים מן החוץ ביחידות המחשב בממשלה מועסקים עובדי תקן ועובדים מקצועיים המועסקים באמצעות בתי תוכנה. היקף מיקור החוץ במגזר הממשלתי בארץ גבוה כפליים (ויותר) מהמקובל בעולם המערבי. המצב הנוכחי, של מיקור חוץ גורף, יוצר לא רק בזבוז כלכלי אדיר, אלא גם חוסר לויאליות ושביעות רצון נמוכה של העובדים. המדיניות הנוכחית "המקדשת" את המחיר אינה מאפשרת גיוס כוח אדם תקציבי איכותי דבר היכול להגדיל את סיכויי ההצלחה של הפרויקט. כי אם כלומר קליטת עובדים לא כעובדי תקן, "קצובי זמן". המלצה 14: מומלץ לעבור לעבודה בחוזים במתכונת התקשרות חוזית (חוזה מומחים) בין הממשלה לעובד, המאפשרת הפסקת התקשרות בהתראה מתאימה. 13

14 עובדי תקן שיטת התגמול הנוכחית לעובדי תקן מקשה על גיוס כוח אדם איכותי לניהול ובקרה על פרויקטי מחשוב בממשלה. המלצה 15: מומלץ למצוא דרכים לשיפור התגמול לעובדי תקן איכותיים: לאפשר חוזים אישיים למנהלי פרויקטים מצטיינים. לאפשר גיוס מנהלי פרויקטים מצטיינים מהשוק הפרטי כעובדי מדינה בחוזה אישי. הפרדה בין פיתוח לתחזוקה שוטפת הניסיון לפתח פרויקטים במסגרת צוותי התחזוקה גורם לתחרות על משאבים. המציאות מלמדת כי בדרך כלל "הדחוף יגבר על החשוב" דבר שיגרום להתארכות הפרויקטים ואף לכישלונם. המלצה 16: מומלץ להפריד בין צוות הפיתוח לבין צוות התחזוקה. פרויקט צריך להיות מנוהל פרויקטאלית כאשר כל המשאבים המוקצים עבורו צריכים לעסוק אך ורק בקידום הפרויקט. מומלץ לאפשר מיקור חוץ רק בפיתוח של יישומים ולא במסגרת פעילויות של תחזוקת יישומים. שיתוף פעולה עם התעשייה ברחבי העולם קיימת מודעות לחשיבות הקשר של הממשלה עם התעשייה, בתחום מערכות המידע. מדינות העולם המערבי הקימו פורומים שנועדו לחזק את הקשר הזה. הפורומים, המאגדים את בכירי המנהלים הממשלתיים ושל התעשייה בתחום מערכות המידע, מאפשרים דיאלוג בין הצדדים ושיתוף של רעיונות, מגמות, אתגרים והצלחות. פורומים כאלה משפיעים על מדיניות הממשלה בIT, מאפשרים לממשלה לקבל פידבק ראשוני מן התעשייה לגבי פרויקטים שונים ומאפשרים להחליף פרקטיקות וידע חדש בתחום. חלק מן הפורומים, אף מגבשים מסמכים מסכמים והמלצות. בקרב המנמ"רים והספקים שראיינה הועדה, שררה הסכמה רחבה כי פורום כזה נחוץ ועשוי להועיל מאוד ליחסי הממשלה עם תעשיית הIT. פורום כזה, אף עשוי להוות מענה לטענת הספקים כי הממשלה אינה מכירה מספיק את המגבלות והסביבה העסקית בה פועלות חברות בת של חברות בינלאומיות. והמנמ"רים הממשלתיים. פורום משותף למנהלי תעשיית הIT המלצה 17: מומלץ להקים להתייעצות, החלפת מידע והעלאת סוגיות העומדות על סדר היום. הפורום ישמש 14

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

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

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

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

19 הרמה הבין-משרדית קידום הIT בממשלה- קיים צורך בבניית CIO ממשלתי שיקדם את ההבנה הממשלתית לגבי חשיבות הטכנולוגיה, ושיטפל ברמה האסטרטגית בניהול נושא הIT בממשלה. גוף כזה, יהיה גוף הקובע מדיניות אסטרטגית, סדר גודל של תקציב (תקציב יותר נוקשה לIT ), העלאת הנושא לסדר היום, גיוס תמיכה של המנכ"לים. הדבר יאפשר למנמ"רים להילחם במשותף על מטרותיהם. למידה - הוכח כי כאשר נעשתה למידה ממכרזים קודמים, במשרדים שונים, היא תרמה רבות ומנעה חזרה על טעויות העבר. כיום לא קיים גוף ידע משותף (בין-משרדי) של למידה. רענון ושיפור הניהול- מומלץ לקיים קורסי רענון לשיפור הניהול העסקי בממשלה. פורטל בתוך היחידה/ בין משרדי - מסייע לשיתוף מידע. המלצות- מתודולוגיות דר' רועי גלברד, יו"ר תוכנית מערכות מידע, אוניברסיטת בר-אילן לאור העיסוק המצומצם בהיבטי המתודולוגיה השונים, ולאור הרציונל שהוצג בסעיף הקודם, יש מקום לסייג את ההמלצות המובאות להלן, ולהציגן בגדר "אני מאמין" אישי, שלא בהכרח משקף את כלל בוודאי שאין הדברים מעוגנים בבדיקה ספציפית מקדימה. חברי הועדה. יחד עם זאת, רק בחינה בפועל של המלצות מסוג זה, יש בה כדי לתת אינדיקציה של ממש בנושא ולהעביר את הדיון מרמה תיאורטית לרמה פרקטית. קוראת להקמת צוות שיהווה את הגרעין לפעילות האינטגרציה של ההמלצה המוצגת להלן, מתודולוגיות המחשוב במשרדי הממשלה. תוך שהיא ממוקדת בהיבט האפיון בלבד, בהקשר של פיתוח אפליקציות ייחודיות. הצוות הנידון יורכב משני חברים, עם הפרופיל המקצועי הבא: ניסיון בניתוח מערכות, ניהול פרויקטים, כתיבת מכרזים ומענה למכרזים. - האחד ניסיון בפיתוח יישומים, הכרות עם סביבות פיתוח, פיתוח חבילות תשתית, וניהול צוות - השני פיתוח. הצוות הנ"ל יועסק במשך שנתיים, במשרה מלאה, ויהווה את גרעין אינטגרציית המתודולוגית הנידון במהלך השנה השנייה יתווספו אל הגרעין שני חברים נוספים, והם יפוצלו לשני צוותים בשלב להלן. מבחני השטח. לפיכך, עלות ההמלצה מוערכת בכ- 6 שנות אדם (שני חברי צוות למשך שנתיים, ושני עלות שנראית סבירה לאור תוצריה הישירים ולאור חברים נוספים במסגרת השנה השנייה). האפשרות לקבל באמצעותה הערכה ריאלית בנוגע להרחבת גישת הפתרון גם לתחום הפיתוח. שני הראשונים פעילותו של גרעין האינטגרציה המתודולוגי תורכב ותבחן בשלושת הנושאים הבאים. מתוכננים לביצוע במהלך שנת הפעילות הראשונה. והשלישי מיועד לשנה השנייה, תוך שהוא מבוצע באמצעות שני צוותים שיתפצלו מהצוות המקורי. 19

20 אינטגרציית מתודולוגיות אפיון במהלך שמונת החודשים הראשונים גרעין האינטגרציה יעסוק בסקירה ובהערכה של מתודולוגיות האפיון השונות המשמשות במשרדי הממשלה השונים, בפרויקטים השונים. בתום הסקירה, הצוות יציג את ממצאיו בפני ועדה מקצועית, שתכיל נציגים מהמשרדים השונים. יחד עם הועדה תיקבע מתודולוגית ניתוח אחידה, לפרויקטים השונים, בהתאם למאפייניהם ולרמות הסיכון. הצוות יגדיר ויתעד בצורה מפורטת את המתודולוגיה ואת הדרך והכלים להשתמש בה. אימות - בגישת Case Study במהלך ארבעת החודשים הבאים הצוות יבצע אפיון של מערכת שזה עתה הושלם אפיונה ושנמצאת בתהליכי פיתוח. תוצרי האפיון לא יעמדו לרשות הצוות, אלא רק אותם מקורות מידע שעמדו בפני מאפייני המערכת המקוריים. לקוח המערכת יבחן את שני התוצרים על פי פרמטרים שיוגדר מראש. האפיון יקבל ניקוד משמעותי במידה וימצא שהצליח לזהות ולחמוק מ"מוקשים" בהם פיתוח המערכת נתקל בפועל בקשיים למיניהם. עימות - בשני מבחני שטח במידה והתוצר, של צוות האינטגרציה, יוערך בצורה משמעותית גבוהה מזאת של תוצר האפיון המקורי, הצוות יורחב לארבעה אנשים שיתפצלו לשני צוותים, כאשר בכל צוות אחד מאנשי הגרעין המקוריים וחבר נוסף מהתחום המשלים (ניתוח /פיתוח). כל אחד משני הצוותים הנ"ל ישובץ לאפיון מערכת שונה במשרד שונה. תוצרי האפיון יועברו לצוותי פיתוח. יעילות המתודולוגיה תוערך בהתאם להצלחת הפיתוח, באופן יחסי להצלחתו בפרויקטים אחרים, במובנים הרגילים של עמידה בזמן, משאבים ותכולות שהוגדרו בתחילת הפרויקט. זאת מתוך ההנחה שאיכות האפיון והתאמתו הגבוהה לצרכיו האמיתיים והריאליים של הלקוח, תאפשר את עמידת הפיתוח במסגרות הזמן והמשאבים שהוקצו לו. שכן, כתוצאה מהאפיון הנ"ל אמורות להיות פחות "הפתעות" במהלך הפיתוח, כמו גם פחות דרישות מיותרות, שאין צורך אמיתי בפיתוחן..I.II.III במידה והנ"ל יוגדר בהצלחה, יהיה בכך משום הוכחה של ממש לכדאיות אימוצה של גישה ריכוזית (למרות חוסר הפופולאריות שלה בימינו). גישה שרק אז יהיה מקום לדון בכדאיות הרחבתה אל מעבר לתחומי האפיון, לשאר התחומים המתודולוגים (שהוצגו בתחילת הפרק), ואף מעבר לכך, אל תחום הפיתוח עצמו. מרחב פתרון כללי בתי התוכנה משמשים כיום את משרדי הממשלה בשלושה אופנים: כחברות כוח אדם, המספקות עובדים לפעילויות התפעול והתחזוקה השוטפות. - כגופים מקצועיים, המבצעים את הפרויקטים הגנריים לאור ניסיונם הייחודי בהטמעת מערכות - ה"מדף" הנ"ל. "חצי מקצועיים" כיוון כגופים "חצי מקצועיים", המבצעים את פיתוח האפליקציות הייחודיות. - שפרויקטים אלו, בסבירות גבוהה, מכילים דרישות פונקציונאליות וטכנולוגיות, שהספק מעולם 20

21 לא התנסה בהן. וכתוצאה מכך, כאמור, אחוזי ההצלחה של פרויקטים אלו נמוכה באופן משמעותי. מרחב הפתרון הכללי ממוקד בתחום של פיתוח אפליקציות ייחודיות שכן: בהקשר של פרויקטים גנריים, כפי שהוסבר, לבתי התוכנה ניסיון ומקצועיות שאינם ברי תחליף - ו/או תחרות. אציין את דעתי בהקשר של בתי התוכנה כספקי כוח אדם לפעילויות התפעול והתחזוקה, - לחוזים ולעבור באופן גורף זאת לפיה יש להפחית ככל האפשר בצורת העסקה האישית, באופן זה ניתן יהיה לחילופין, או להפחית באופן משמעותי את עלויות אישיים קצובים בזמן. כאשר בנוסף כוח האדם, או להגדיל את היקפי כוח האדם בלא להגדיל את מסגרת התקציב. הערה זאת רלוונטית, על הנ"ל המשרדים ייהנו משביעות רצון ולויאליות גבוהה של עובדיהם. כאמור, לעניינינו בהיבט אפשרויות גיוס כוח אדם לתמיכה בגישות הפתרון השונות. להלן שלוש מתוך שכך, כאמור, מרחב הפתרון מתייחס לתחום של פיתוח אפליקציות ייחודיות. קטבים, שכל אחד מהם ממקם את היבט גישות המציגות קטבים אפשריים במרחב הפתרונות. פיתוח והנחלת הידע המתודולוגי והטכנולוגי במוקדים שונים. תקינה באחריות הגורם הממשלתי- גרעין המתודולוגיה, שהוצג בסעיף ההמלצות, משקף את ייזומו של מצב בו הממשלה לוקחת על עצמה את האחריות לכל הנושא המתודולוגי, על כל מרכיביו: אפיון, פיתוח, ניהול, תיחור וכד'. השלב הבא, בתרחיש זה, הוא מיסודו של גוף תקינה מוסדר והתניית השתתפותם, של ספקי תוכנה למיניהם, בפרויקטי מחשוב ממשלתיים, בקבלת הסמכה מגוף התקינה הנ"ל. לגישה זאת ישנם תקדימים, הן עקרוניים בדמות מסלולי Certification של גופי תקינה פרטיים, והן בדמות מודל ה- CMMI שהוא תוצר של חיל האוויר האמריקאי, משרד ההגנה ואוניברסיטת.Carnegie Mellon עלות כוח האדם של גוף התקינה הנ"ל, ימומן כאמור, מהחיסכון הכספי, או לחילופין מאפשרות הגדלת היקף כוח האדם המועסק, כתוצאה הפיכת חוזי העסקה, של כוח אדם, מחוזי מיקור- חוץ, לחוזים אישיים קצובים בזמן, כפי שהוסבר קודם. הקמת בית תוכנה ממשלתי- גישה זאת מציגה את התמונה הקוטבית ביותר למצב הנוכחי. תמונה בה הממשלה מקימה, בנוסף על גוף התקינה שממשיך לפעול באופן עצמאי, גם בית תוכנה. בית התוכנה יתחרה כשווה בין שווים, ללא הקלות, בבתי התוכנה הפרטיים. בית התוכנה נהנה לכאורה מנכסי תשתיות התוכנה שמועברות לידיו, אך אם לא ישכיל להפוך נכסים אלו לתשתיות ולידע כלליים הרי שלא ישיג יתרון של ממש. כשכנגד, אם כן ישכיל לעשות זאת, הרי יוכל להשיג ולמצות את כל היתרונות הגלומים בתפיסה ריכוזית של יישומי מחשוב. לא מפתיע יהיה לשמוע דעות והערכות שונות בנושא זה, אך לטעמי בשלב זה, הדיון באפשרות זאת הוא תיאורטי לחלוטין ונטול כל עיגון במציאות, כל עוד לא תתקבל הוכחה כלשהי ליכולת לבצע עבודה אינטגרטיבית חוצת משרדים. הוכחה זאת יכולה להתקבל במסגרת פעילותו של גרעין המתודולוגיה שהוצג במסגרת ההמלצה

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

23 פרק 1 פרויקטים במערכות מידע- הצלחות וכישלונות הקדמה פרק זה מבקש לבחון את גורמי ההצלחה והכישלון של פרויקטים במערכות מידע. הפרק פותח בדיון בשאלה מה הם המדדים להצלחה וכישלון וממשיך בהצגה של נתונים סטטיסטיים על הצלחה וכישלון של פרויקטים במערכות מידע בעולם על פי אחת משיטות המדידה. לאחר מכן, הפרק מפרט את הבעיות המרכזיות בניהול פרויקטים של,IT כאשר על פי רוב הקשיים נובעים מן הגורם האנושי ולא מן הגורם הטכנולוגי. כמו כן, ניתנים דגשים על מקומות של קושי ואפשרוי תו לשיפור, ברמה המתודולוגית. החלק הבא, עוסק בהצלחה וכישלון של פרויקטים במערכות מידע, בממשלה. מוסברת המורכבות של הפרויקטים הממשלתיים ונמנים גורמים המשפיעים על מידת הצלחתם. תקציר מנהלים מדדים להצלחה/כישלון קיים דיון נרחב בשאלה כיצד מודדים הצלחה או כישלון של פרויקט פיתוח תוכנה. אנו נבקש לסקור מספר דרכי התמודדות עם שאלה זאת. ההמלצה היא, כי הקריטריונים להצלחה יוגדרו מראש, לאור מטרות הפרויקט (תוך הענקה של גמישות מסוימת המאפשרת שינויים במהלך הפרויקט). השיטה הנפוצה ביותר, היא בחינה של הפרויקט במדדים של זמן, עלות ותכולה. אולם, כיום קיימת ביקורת על בלעדיותם של מדדים אלה, הטוענת כי הם אינם משקפים את מלוא המורכבות אלא מציגים רק זווית ראיה מסוימת. לפיכך, מובאים מספר מחקרים אשר ממליצים על הוספת שני קריטריונים נוספים- עמדת המשתמש וההשפעה הארגונית שיש לפרויקט. כמו כן, ישנה הסכמה כי יש להעניק לקריטריון איכות התכולה משקל רב יותר על פני הזמן והעלות. סקירה- פרויקטים של IT בעולם הממשלה היא המגזר הרביעי באחוזי השקעתו בIT, מתוך עלויות התפעול. קודמים לה בהשקעתם המגזר הפיננסי, הביטוחים והשירותים המקצועיים, הרואים בIT גורם אסטרטגי. תחת ההגדרה של עמידה בתקציב, זמן ותכולה, כיום רק 32% מהפרויקטים במערכות מידע, נחשבים כמוצלחים ו- 24% מהם נכשלים. בארה"ב ובאיחוד האירופי מבוזבזים מדי שנה סכומים שבין מיליארד דולר על פרויקטים שנכשלו. ככל שהפרויקט גדול יותר, סיכויי הכישלון שלו גדלים. נמצא, כי פרויקטים גדולים נכשלים כמעט ב- 50% יותר מאלה הקטנים. ביטול הפרויקטים הגדולים, נעשה לרוב לאחר שהושלמה כבר מחצית הפרויקט. 23

24 בעיות מרכזיות בניהול פרויקטים של IT הקשיים בניהול הפרויקטים, מתמקדים במימד האנושי-ניהולי ופחות במימד הטכנולוגי. על נקודות התורפה נמנים: תכנון גרוע, טכנולוגיה בהקשר המשרדי, מטרות לא ברורות, הערכות לא ריאליות של זמן/משאבים, העדר תמיכה ומעורבות של ההנהלה הבכירה ושל המשתמשים, שינויים תוך כדי הפרויקט, קשיי תקשורת צוותית, חוסר במיומנויות, ואי שיתוף של מומחים. ברמה המתודולוגית, נמצא כי שיטות ה AGILE תופסות תאוצה וחברות משתמשות בהן יותר ויותר. אולם, למרות הגישות הרבות לפיתוח תוכנה, עדיין ישנו חוסר ודאות לגבי מה יוצר תהליך טוב ואיזה מבנה על הארגון לאמץ על מנת שהפרויקט יצליח. פיתוח התוכנה נעשה מורכב יותר ולפיכך יש להקפיד על התאמת המתודולוגיה לשטח,לעבוד לפי הנחיות ברורות ומפורטות ולעדכן את המתודולוגיות והתהליכים הנגזרים מהן, באופן מתמיד. פרויקטים של IT בממשלה באופן כללי, אמון הציבור ביכולת הממשלות לנהל פרויקטים מוצלחים של -IT נמוך. נראה, כי פרויקטים בממשלה נוטים להיכשל יותר מפרויקטים במגזר הפרטי (ב- 20% ). ממשלות בעולם משקיעות בהנחת סטנדרטים לפרקטיקות ניהול פרויקטים של IT וכן יותר ויותר מגדירות דרישות פורמאליות להגדרת מיומנויות אנשי-הפרויקט. למרות זאת, על פי התחזית, 30% מן הפרויקטים של IT שיזמו הממשלות, יתבטלו (עד 2010). מורכבות הפרויקט הממשלתי הקושי העיקרי בפרויקטים ממשלתיים הוא המורכבות הרבה שלהם מחד והרצון ליצור פרויקט גדול ושאפתני מאידך. את המורכבות של הפרויקטים הממשלתיים, ניתן לחלק למורכבות פוליטית, ארגונית וטכנית. המורכבות הפוליטית נוצרת עקב היותו של הארגון הממשלתי משוקע במערכת פוליטית אשר יוצרת שיקולים נוספים בפרויקטים כגון צורך בפרויקט שאפתני בעל תאריכי יעד נוקשים וקושי לשקול מחדש את הצורך בפרויקט לאחר שינויים פוליטיים משמעותיים. המורכבות הארגונית נוצרת עקב עבודתם של משרדי הממשלה עם מספר ארגונים אוטונומיים בעלי אינטרסים משלהם וכן, עקב הקשר ההדוק בין פרויקט של IT ושינוי ארגוני (קשר שעשוי לגרום להערמת קשיים). המורכבות הטכנית קשורה ברמת גמישות שונה לתהליכים הפוליטיים והארגוניים ותהליכי מערכות הIT. גם שיטות הפיתוח המתפתחות במהירות עשויות להערים קשיים. כמו כן, קיימת מורכבות הנוגעת לקושי לחבר בין מערכות קיימות וחדשות. את המורכבות הרבה שנוצרת בפרויקטים הממשלתיים, מומלץ לצמצם על ידי עבודה בצעדים קטנים וחלוקת הפרויקטים ליחידות נשלטות. כמו כן, יש לחזק את מעורבותם של שרי המשרדים אשר עשויים לסייע להצלחת הפרויקט. 24

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

26 מדדים להצלחה/כישלון קיים דיון נרחב בשאלה כיצד מודדים הצלחה או כישלון של פרויקט פיתוח תוכנה. שיטה רווחת מאוד היא בחינה של הפרויקט במדדים של זמן, עלות ותכולה. פרויקט מצליח, אם הוא 3 הושלם בזמן, במסגרת התקציב ועם הפונקציות והמאפיינים הנדרשים. המדד הידוע ביותר ובוחן המשתמש בשיטה זאת הוא ה-,Chaos Report הדו"ח השנתי המוצג ע"י ה- 4 Standish Group את ההצלחה/כישלון של פרויקטים במערכות מידע בעולם. דו"ח זה נחשב לסטנדרט מקובל ואת נתוניו מ נציג בהמשך. אולם, פרויקטים של פיתוח תוכנה הינם מורכבים. לנוכח מורכבות זו, קיימת ביקורת על מדדי הזמן- עלות-תכולה. האם אכן ניתן לומר, למשל, כי פרויקט שחרג בעלות אך מסר את התכולה המלאה ובזמן- ייחשב לפרויקט שנכשל? כמו כן, יתכן ויתקבל פרויקט שעמד בשלושת המדדים, אך לא נעשה בו שימוש או- שהמשתמשים אינם מרוצים ממנו. האם פרויקט כזה יוגדר כמוצלח? בפרויקטים ממשלתיים של פיתוח תוכנה, קיימת מורכבות נוספת והיא היותם נתונים לביקורת 5 ציבורית וביקורות פנימיות רבות. על רקע מדיניות משתנה ומתפתחת, מפותחות המערכות הללו אשר פעמים רבות אין שני להן מבחינת ההיקף. בהתאם לכך, קל למערכות הIT לאבד קשר עם הציפיות והמטרות שנקבעו בהתחלה- הן עשויות להיות מושפעות מאוד ובקלות, על ידי אירועים חיצוניים, שינוי במדיניות או שינויים בקונצנזוס. אירועים שונים כאלה, מתרחשים על בסיס קבוע בממשלה. לאור אירועים אלה, מתעצמת השאלה האם ניתן בראיה פשטנית, לקבוע שפרויקט נכשל אפילו אם השינויים בעלות, היקף או זמן נעשו בשל סיבות לגיטימיות ואושרו בתהליכים מסודרים ומבוקרים. על הגדרה צרה זאת של הצלחה/כישלון, חולקים חוקרים רבים כיום, אשר טוענים כי מדובר בקריטריונים המשקפים רק זווית ראייה מסוימת וכי יש לבחון פרויקטים ממספר פרספקטיבות. מעבר 6 לזאת, קיימת כיום מודעות לצד הסובייקטיבי של מדדי ההצלחה דבר המציב בסימן שאלה את היכולת להגיע למדידה מלאה וסופית של מידת ההצלחה. לעיתים אינטרסים שונים של בעלי 7 תפקידים מביאים להגדרות שונות לאותו הפרויקט. תחת מגבלות אלה וכחלק מן הניסיון להגדיר הצלחה עד כמה שניתן, נבקש לסקור כאן מספר מחקרים המציעים להרחיב את ההגדרה הרווחת למדד של פרויקטים. Turner, J.R (1993). The Handbook of Project-based Management. McGraw-Hill. 5 מתוך: מסמך של משרד המסחר הבריטי,(OGC) ינואר 2009: Joint Programmes and Project Delivery Statement of Intent 6 לדוגמא, במחקר של (1999) Linberg עלה, כי מפתחי התוכנה קשרו את הצלחתם למידת שביעות הרצון שלהם מהפרויקט, שהושפעה מחוויית היצירתיות והלמידה שהם חשו במהלך עבודתם. Linberg, K. R.(1999). Software developer perceptions about software project failure: a case study. Journal Syst Software, 49: למשל: Fincham, R. (2002). Narratives of Success and Failure in Systems Development. British Journal ' הערה 8. ר, Hamidovic, A. & Krajnovic, S. (2005) וכן. of Management, 13: 1 14

27 מדדים לבחינה של פרויקטים דגש על פונקציונליות- על פי (2006) Rathod, 8 Agarwal & שערכו את מחקרם בהודו, ניתן לחלק את קריטריוני ההצלחה לשניים: קריטריון פנימי - כגון הישגים במונחים של עלות, זמן ותכולה; קריטריון חיצוני - כגון שביעות רצון המשתמשים מן התוצאות. החוקרים, בחרו להתמקד בבחינת ההצלחה על ידי צוות הפרויקט, ובחנו את הפרספקטיבה של: המפתחים, מנהלי הפרויקט, והמנהלים מצד המשתמשים. נמצא, כי זמן, כסף, תכולה ואיכות הינם קריטריונים חשובים להצלחת הפרויקט, בעיני בעלי המקצוע שנשאלו. הכול הסכימו, כי תכולה היא הקריטריון החשוב ביותר לקביעת הצלחת הפרויקט, כאשר אם עליהם לבחור בין פונקציונליות (שימושיות) של התכולה לבין איכותה, הועדפה פונקציונליות. מאידך, נמצא כי קריטריון העלות נתפס בעיני אנשי הצוות כפחות חשוב להסקה על הצלחת הפרויקט. 9 דרישות המשתמשים- מחקרו של (1998) Wateridge התבסס על סקר שערך בקרב מנהלי פרויקטים, מנתחי מערכות, לקוחות ומשתמשים. המחקר הגיע למסקנה כי קריטריון ההצלחה החשוב ביותר בפרויקטים של,IT הוא כי הפרויקט עונה על דרישות המשתמש. אולם, ניתן לראות כי בבסיס קריטריון זה קיימות תפיסות שונות: בעיני המשתמשים, "משתמש/ת מרוצה" היה הקריטריון השני בחשיבותו, בעוד מנהלי הפרויקטים- דרגו קריטריון זה רק במקום השביעי. עבור מנהלי הפרויקטים, עמידה בתקציב ועמידה בזמנים היו הקריטריונים הבאים לאחר קריטריון דרישות המשתמש. הדבר מעיד, כי המשתמשים קושרים בין עמידה בדרישותיהם ובין היותם מרוצים. אולם למנהלי הפרויקטים, זווית ראיה אחרת- עבורם, לעמוד במדדים שנקבעו על ידי ההנהלה הבכירה חשוב יותר ממסירה של מערכת ממנה המשתמשים מרוצים. ממשיך בקו שביעות רצון והשפעה ארגונית- מחקר נוסף, של (2005) Krajnovic 10 Hamidovic & זה של,Wateridge ומחפש מעבר לשלושת המדדים, גם את הפן הארגוני הרחב יותר. & Hamidovic Krajnovic מציעים, כי יש להוסיף למדדי ההצלחה של הפרויקט, שני מדדים נוספים: שביעות הרצון של המשתמש/ת והשפעה הארגונית. שביעות רצון המשתמש/ת- עד כמה המשתמש/ת מרוצה ממילוי הדרישות ועד כמה הפרויקט ענה על הציפיות. לרוב, נשאלים המשתמשים במערכת לגבי ציפיותיהם מן המערכת בנושאים כגון: הפונקציונליות, האמינות, התחזוקה והביצועים. ניתן למדוד את שביעות הרצון באמצעות שאלונים, Agarwal, N. Rathod, U. (2006). Defining success for software projects. An exploratory revelation. 8 International Journal of Project Management,24: Wateridge, J. (1998). How can IS/IT projects be measured for success. International Journal of 9 Project Management, 16(1): Hamidovic, A. & Krajnovic, S. (2005). An Example of a Novel Approach to Measuring Projects 10 Success within ICT Industry. 8th International Conference on Telecommunications. IEEExplore. 27

28 או באמצעים הקשורים ישירות לפרויקט (כגון: מידת השימוש במערכת). השפעה ארגונית- הצלחת הפרויקט ניכרת כאשר הוא משפר את תהליכי העבודה הארגוניים ומגביר את הפרודוקטיביות הארגונית (מבלי לפגוע בתהליכי העבודה העיקריים של הארגון). 11 מחקר נוסף המתייחס גם הוא לחמש הקריטריונים הללו, ביקש לדרג אותם על פי חשיבותם בעיני מנהלי הפרויקט, המשתמשים, מממן הפרויקט וחברי צוות הפרויקט. בהתאם למחקרים שעלו כאן, בממוצע הציונים שנתנו כל הנשאלים, נתפס אלמנט התכולה (הכולל איכות ופונקציונאליות) כבעל החשיבות הגבוהה ביותר. אחריו- דורג קריטריון המענה על דרישות המשתמש כשני בחשיבותו. קריטריון ההשפעה הארגונית, דורג במקום השלישי. במקום האחרון דורג קריטריון העלות (המנהלים, דרגו אותו במקום ה 3 ).,Hamidovic & Krajnovic מדגישים כי מוטב לקבוע את הקריטריונים להצלחה כבר בשלב מוקדם של הפרויקט ולבחון את הפרויקט לאורם באופן מתמיד. בהתאם להתפתחות הפרויקט אף יתכנו שינויים בקריטריונים. מדדי ההצלחה, יהיו מוסכמים על בעלי-העניין של הפרויקט (מנהלים, משתמשים וכו') ויש לקבוע אותם במונחים מדידים וברורים. 12 הצהרת כוונות משותפת - הבריטים, מציעים לחתום על הסכם "הצהרת כוונות משותפת" 13 ) Intent.(JSI Joint Statement of הסכם זה, הנחתם בין המנהלים הבכירים מצד הלקוח ומצד הספק, נועד בעיקרו לתמוך בפרקטיקות הקיימות בין הספק והממשלה אך גם מבקש להציע מנגנון פחות עמום למדידת ההצלחה של פרויקט הIT. בJSI, יוגדרו קריטריונים להצלחה, מול ההגדרה של התוצאות הארגוניות הרצויות ושל הפרמטרים העיקריים של הזמן, העלות והאיכות. פרויקט יוכרז כמוצלח/ לא, לאור הקריטריונים הללו. הקריטריונים הינם של מסירה בזמן (גם אם הזמן שונה במהלך הפרויקט בתהליך ניהול שינויים), בתקציב (גם אם התקציב שונה במהלך הפרויקט בתהליך ניהול שינויים) ובהתאם לדרישות של משתמשי המ פתח. לסיכום, נראה כי את הקריטריונים להצלחה מומלץ להגדיר מראש (תוך הענקה של גמישות מסוימת, המוסדרת בפרוצדורה ברורה ומאפשרת שינויים במהלך הפרויקט) ולאור המטרות שהוגדרו לפרויקט גם ברמה ארגונית וברמת דרישות המשתמש. הבריטים, אף מציעים מסגרת הסכם מול הספק המגדיר את הקריטריונים הללו. המחקרים כיום אינם שוללים את שלושת הקריטריונים הקלאסיים למדידת הצלחה (זמן-עלות-תכולה) אולם מבקשים לדייק אותם ולהוסיף עליהם: נראה, כי קיימת הסכמה רחבה במחקרים שהובאו כאן, כי יש להעניק משקל רב יותר לקריטריון התכולה. הומלץ להתייחס לקריטריון שביעות רצון המשתמשים- האם נענו דרישותיהם והאם הם מרוצים (ניתן להתייחס לשני קריטריונים אלה, כשונים זה מזה, כפי שעולה ממחקרו של.(Wateridge קריטריון נוסף אליו הומלץ להתייחס הוא ההשפעה הארגונית- האם שופרו תהליכי העבודה הארגוניים ועלתה הפרודוקטיביות בהתאם למטרות שנקבעו למערכת. Nelson, R. R. (2005). Project Retrospectives: Evaluating Project Success, Failure, and Everything In Between. MIS Quarterly Executive, 4(3): מתוך: מסמך של משרד המסחר הבריטי,(OGC) ינואר 2009: Joint Programmes and Project Delivery -Statement of Intent 13 הרחבה על הסכם זה, ניתן למצוא בפרק

29 סקירה- פרויקטים של IT בעולם השקעה ב IT 14 על פי נתוני חברת הייעוץ והמחקר "גרטנר", במחצית השנייה של שנת 2008 המגזר הממשלתי היה המגזר הרביעי מבחינת אחוזי השקעתו בIT, מתוך עלויות התפעול. קדמו לו רק המגזר הפיננסי, הביטוחים והשירותים המקצועיים. המגזרים הללו, המשקיעים רבות בIT רואים בו גורם אסטרטגי. 15 קיימת הערכה, לפיה הוצאת ממשלות העולם על,IT מהווה 10% מכלל ההוצאה העולמית על.IT דו"ח של ארגון ISBSG לממשלת ויקטוריה, אוסטרליה Software Development Projects in GOVERNMENT סקר של גארטנר, סיכוםהנתונים של שנת מתוך: Smith, M. & Potter, K. (2009). IT Spending and Staffing Report. Gartner website: 15

30 הצלחה/כישלון- פרויקטים של IT 2009 על פי נתוני ה- Chaos Report משנת המודד, כאמור, הצלחה/כישלון במונחים של עמידה בזמן, עלות ותכולה, 16 עולה : 32% מהפרויקטים הוגדרו כמוצלחים. 44% מהפרויקטים הוגדרו כ"מאותגרים"- מאחרים/ חורגים מן התקציב/ בעלי פחות מאפיינים (features) מן הנדרש. 24% מהפרויקטים הוגדרו כי כשלו לפני סיומם. השנה, חלה ירידה באחוז הפרויקטים המוצלחים. כמו כן, על פי הדו"ח, נרשם בשנה האחרונה השיעור הגבוה ביותר של כישלונות בעשור 17 האחרון. על פי אותו הדו"ח משנת, 2001 החריגה בעלויות מגיעה בממוצע לכ- 200%. ככל שהפרויקט גדול יותר, סיכוייו להיכשל גדולים 18 יותר בארה"ב, קרוב ל 150 מיליארד דולר, מבוזבזים מדי שנה (במגזר הפרטי והציבורי יחד) על פרויקטים שנכשלו ובאיחוד האירופי, הסכום קרוב ל 140 מיליארד דולר. שיעור הכישלונות של פרויקטים גדולים, גדול בקרוב ל 50% משעור הכישלונות של פרויקטים קטנים. קרוב לשני-שליש מתוך הפרויקטים הגדולים שנכשלו, בוטלו לאחר ש 50% מן הפרויקט הושלם. זאת, בעוד ביטול פרויקטים בסדר גודל בינוני, התרחש בדרך כלל לפני השלמת 50% מן הפרויקט. פרויקטי IT גדולים, מוערכים ביותר ממיליון $. בוטלו לאחר ש 50% הושלמו פרויקטי IT בינוניים. מוערכים בין פרויקטי $350K ועד מיליון $. בוטלו כאשר 25% עד 50% הושלמו IT קטנים-בינוניים. מוערכים בפחות מ $350K. בוטלו לפני ש 25% הושלמו ר- 30 ' הערה.2 16 דו"ח Standish Group Goldfinch, S. (2007). Pessimism, Computer Failure, and Information Systems Development in the Public Sector, Public Administration Review Mieritz, L. (2008). Exploring the Relationship Between Project Size and Success, Gartner website:

31 בעיות מרכזיות בניהול פרויקטים של IT 19 מסגרת עבודה לתהליכי פיתוח תוכנה, במאה ה 21 שלושת המרכיבים העיקריים לבניית תהליך של פיתוח תוכנה מעגל החיים- סדרה של אבני דרך והישגים אשר בהם מנהלים סיכונים באופן אפקטיבי, מבטיחים תקשורת ומאפשרים לפרויקטים לעבוד יחד. צוות- סדרה של גישות שמביאות את הצוות לעבוד יחד באופן אפקטיבי, יחד עם הלקוח ומאפשרות מסירה של התוכנה. פרקטיקות- הטכניקות שמגדירות, בוחנות, בונות ומוסרות את התוכנה בדרך היעילה ביותר. 20 הקשיים מתמקדים בניהול של הפרויקט- באנשים ולא בטכנולוגיה. הבעיות המרכזיות שנמצאו : תכנון גרוע- לעיתים עקב לחץ זמן לא מתאפשר למנהלים לתכנן ולהגדיר את הפרויקט כראוי. אין לראות בתכנון "בזבוז זמן עשייה". לשים לב, שפרויקטי IT עמוסים ביחסי התחלה-סיום: לעיתים לא ניתן להתחיל לבצע את אבן-הדרך הבאה, עד שהסתיימה הקודמת. לפיכך, ביצוע של התכנון הוא קריטי. לא מומלץ לבצע תוכניות יותר מדיי מפורטות לפרויקטים של,IT שכן אין למנהלים הידע הנדרש ליצור תוכניות מפורטות מספיק, והצוות או שאינו מיומן בכך או שאינו רוצה לעשות זאת- הם יעדיפו מייד ליישם את הפיתרון שלהם. חשוב לבצע חישוב סיכונים מדויק מנהלי הפרויקט לעיתים לא מודעים לרמת הסיכון שהם לוקחים מכיוון שלא ביצעו 21 תהליך לחישוב מדויק שלה. חשוב לא ליצור סיבוך-יתר : לא ליצור מערכות מסובכות מדיי לביצוע פעולות פשוטות. 22 דגש על בניית הטכנולוגיה בתוך ולמען המשרד - לטכנולוגיה אין ערך משל עצמה. רק כאשר היא נמצאת בקונטקסט של האנשים והתהליכים הארגוניים/עסקיים- יש לה פוטנציאל להיות בעלת ערך. אולם, פן זה של פרויקטים טכנולוגיים כמעט תמיד מוזנח. לפיכך- יש לחשוב על הIT כעל תוכנית לשינוי- מהותי (עסקי). תוכנית שנועדה לשנות במובן הרחב- מעבר לטכנולוגיה. יש להיערך לשינויים אנושיים, ארגוניים West, D. (2009). Best Practices: Software Development Processes, Forrester website: אם לא צוין אחרת במקום המתאים, הרי שהדברים על פי Al Neimat, T. (2005). Why IT Projects Fail, PROJECT PERFECT website: Sterpe, P. (2007). Ten Mistakes That Send Development Projects Off Track, Forrester website: 22 Symons, C. (2009). Programs, Not Projects, Deliver Business Value, Forrester website : 21

32 ותהליכים שיקרו במקביל להטמעת המערכת. פרויקט גם בעל פן ארגוני, אנושי ותהליכי. IT הוא לא רק טכנולוגיה אלא מטרות לא ברורות- יש להגדיר את המטרות באופן שאינו נתון לפרשנות מרובה. לדוגמא, יש לפרט ולהסביר את הציפיות מהמושג "שירות לקוחות" באופן שאינו נתון לפרשנות אישית של מבצעי הפרויקט. ללא הגדרה ברורה של המטרות, יהיה קשה להעריך את היקף ולו"ז הפרויקט. לעיתים ישנו עניין של חוסר מיומנות בהגדרת 23 הדרישות. הגדרת הדרישות באופן ראוי, הינה קריטית להצלחת הפרויקט. בעלי העניין והמשתמשים פעמים רבות אינם בטוחים לגבי הצרכים שלהם או שאינם מסוגלים לבטא אותם בבירור. הערכות לא ריאליות של זמן/משאבים- דוגמאות לטעויות נפוצות: יש להבחין בין זמן משימה, לבין משך המשימה. זמן המשימה- אינו כולל חישוב של ההפרעות. משך המשימה, היא הזמן הכולל להשלמת הפרויקט (כולל ההפרעות). אחת השגיאות הנפוצות היא חישוב המשימה לפי זמן, ולא לפי משך. טעות נוספת- שימוש בהערכה ליניארית כאשר החישובים הם מסובכים מזה (לדוגמא, לא ניתן לומר שהכפלה של 24 מספר האנשים העובדים על הפרויקט תביא להשלמתו בחצי הזמן...). דגש נוסף הוא כי יש לעדכן את ההערכות מעת לעת. שימוש בהערכה הראשונית של זמן 25 ומשאבים תפגע בפרויקט. עדכון של ההערכות נגזר מי דע שהתווסף למנהלי הפרויקט והוא בלתי נמנע בפרויקטים גדולים. העדר תמיכה של ההנהלה הבכירה, חוסר מעורבות של המשתמשים-על מנהלים הבכירים להראות תמיכה בפרויקט. יש לוודא האם למנהלים יש הסתייגויות- הדבר חשוב לקבלת תמיכתם בהמשך ובייחוד אם יתעוררו בעיות. יש לדאוג למעורבות של המשתמשים בתכנון והיישום שכן הם יושפעו מאוד מן המערכת (למשל, עשוי להיות מצב של אובדן משרות או מעמד). על המנהלים לדאוג כי הפרויקט יקבל הכרה 26 ארגונית ויוקדש לו הזמן הראוי גם בקרב העובדים ו/או משתמשים. אמון במנהלים - חשוב כי ההנהלה הבכירה המפקחת על הפרויקט תיתן אמון במנהלים להם נתנו את המשימות ותעסוק יותר בניהול העבודה ולא בביצוע שלה. בישיבות, יש לעסוק בהתקדמות העבודה ולא בירידה לפרטי-הפרטים שלה. Pitts, M.G. & Browne, G.J (2007).Improving requirements elicitation: an Empirical investigation of prompts procedural, Info Systems. 17, (2007) Sterpe ר' הערה. 7 Cardin, L. (2008). Debunking IT Project Failure Myths. Forrester website: 26 (2007) Sterpe ר' הערה.6 25

33 שינויים תוך כדי הפרויקט- creep" :"scope כאשר ישנם שינויים לא צפויים ובלתי נשלטים בדרישות המשתמשים במהלך התקדמות הפרויקט והדבר משפיע על היקפי הפרויקט. creep" "feature : הוספה של מאפיינים למערכת. ההנחה השגויה היא שעוד מאפיין קטן לא ישפיע על העלויות או הלו"ז ולכן אין התאמה והתייחסות לכך מצד המנהלים. אך זוהי טעות ויש להתחשב בתוספות והשינויים- יש להבין ולשים לב 27 על חשבון מה הם באים (זמן/ כסף וכד'). כאשר נעשה שינוי חשוב בדרישות אשר התבצע כראוי, אין להתייחס לחריגה בזמן או בכסף ככישלון, שכן מדובר במהלך מוצלח של מתן ערך נוסף למערכת. 28 בחירת דפוס הנהגה לא מתאים לפרויקט - טעות נפוצה היא למנות שני מנהלים לפרויקט מבלי להכריע למי הסמכות העליונה. תחרות בין שני המנהלים עשויה להכשיל את הפרויקט. טעות נוספת היא ועדות גדולות עם נציגים רבים. הדבר גורם לקבלת החלטות איטית- אם בכלל. חשוב יותר ליצור צוות שמקבל החלטות, מאשר צוות המייצג את דעת כולם. ניתן לידע מספר מצומצם של אנשי-צוות בדעת בעלי- העניין וכך כולם ייוצגו. בעיות תקשורת ואי-תפקוד צוותי קשיי תקשורת באים לידי ביטוי במיוחד בפרויקטי IT גדולים. עקב מורכבות המערכת, לעיתים צוותי הפיתוח עובדים קשה וההנהלה הבכירה אינה רואה את ההתקדמות מכיוון שמנהלי הפרויקט אינם מוצאים מה לדווח. חשוב כי מנהלי הפרויקט ידווחו באופן סדיר למנהליהם, גם אם 29 ההתקדמות כמעט ואיננה-נראית. הימנעות מטיפול בטעויות - הינה בעיה העשויה להיגרם מתרבות ארגונית. ישנם ארגונים המעדיפים להותיר בעיות לא-פתורות מאשר להסב את תשומת הלב אליהן. חוסר דיאלוג בנושא זה, עלול להכשיל את הפרויקט. מחסור במיומנויות- רוב פרויקטי הIT דורשים מגוון של מיומנויות ולא תמיד הן מצויות בצוותים. לעיתים גם ישנו הקושי להשיג אנשים בעלי המיומנויות הנדרשות. יש צורך (מעבר למיומנויות הטכנולוגיות המובנות מאליהן) באנשים המיומנים בתכנון, 30 ארגון ותקשורת. גם כאשר ישנו שימוש במיקור חוץ - יש צורך באנשים מבפנים היכולים להיות מעורבים בניהול והערכת הסיכונים הטכניים (2008) Cardin ר' הערה (2007) Sterpe ר' הערה.6 29 שם. 30 שם.

34 אי- 31 שיתוף מומחים מחברות בינונית וקטנות -(SME) מנהלי פיתוח מסכימים כי חשוב לערב מומחים לנושא הפרויקט, מעסקים קטנים בינוניים המכירים את התהליכים העסקיים, במיוחד בפרויקטים מורכבים. כיום לרוב לא אין מספיק שיתוף פעולה עימם. אולם מומחים לנושא הינם חשובים וכדאי שילוו את הפרויקט משלביו המוקדמים לאחר שבוצע עימם תיאום ציפיות לגבי מידת השתתפותם. 31 שם. 34

35 ר, 32 הרמה המתודולוגית שיטת ניהול הפיתוח בעשור האחרון, הגיחו גישות פיתוח חדשות, היוצאות נגד המודלים המפורטים וכבדי-התהליכים (כגון:.(CMMI שיטות ה- AGILE תופסות תאוצה, כאשר 33% מן הארגונים שהשתתפו בסקר של פורסטר (81 ארגונים) משתמשים בהן בצורה זאת או אחרת. יותר מ- 50% מן החברות שהשתתפו בסקר של פורסטר מ 2008 (שכלל 2227 ארגוני תוכנה) מרחיבות את שימושן ב.AGILE בתוך כך, שיטת ה SCRUM- המשתמשת במתודת הAGILE, נמצאה בשימוש הרב ביותר. אולם, למרות הגישות הרבות לפיתוח תוכנה, עדיין ישנו חוסר-ודאות לגבי מה יוצר תהליך טוב ואיזה מבנה על הארגון לאמץ על מנת לאפשר את הצלחת הפרויקט. השיטות הנפוצות ביותר לניהול פרויקטים של פיתוח תוכנה כיום (הנשאלים התבקשו לסמן את כל השיטות איתן הם עובדים- אם באופן חלקי ואם באופן מלא): ' הערה.5 32 West. (2009) 35

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

37 פרויקטים של IT בממשלה על פי סקר של Standish Group האמריקאית, משנת 2001, רק 18% מן הפרויקטים הממשלתיים 34 מצליחים. 35 על פי סקר שנעשה באוסטרליה ב 2006, פרויקטים ממשלתיים של IT באוסטרליה, נכשלו ב 20% יותר מאשר אלה הפרטיים. 36 התחזית צופה כי עד שנת 2010 יותר מ 70% מן הממשלות בעולם המפותח כלכלית, יניחו סטנדרטים לפרקטיקות של ניהול פרויקטי IT וכן ינהיגו דרישות פורמאליות להגדרת מיומנות אנשי הפרויקט. משרדי הממשלות יבטלו 30% מן הפרויקטים של IT אותם הם יזמו, כאשר לפחות 10% מן הפרויקטים שיבוטלו תקציבם מעל $200,000. אוסטרליה- סקר פרויקטים של 37 IT בממשלה במחקר שנערך מטעם הממשל האוסטרלי בשנת 2008, השתתפו 40 מחלקות ממשלתיות אשר דיווחו על ביצועיהן בפרויקטים של.IT להלן עיקר הממצאים: סיכום ביצועיהם של 193 פרויקטי IT ממשלתיים (יש לשים לב כי אחוז ההיענות היה כ- 75%): תועלת זמן עלויות דיווחו על הפקת תועלת מן הפרויקט אך לא סיפקו הוכחות למדידת התועלת דיווחו על מדידת התועלת מן הפרויקט והשוו את הציפיות מן הפרויקט לתועלת בפועל דיווחו על תוצאות שלא ניתנות למדידה לא ענו 44% 5% 45% 6% 37 (2007). Goldfinch, ר' הערה.3 McClure, D. (2007). From the CIO Trenches: Why Some Projects Fail and Others Succeed, Gartner website: Strauss, H. (2006). Why IT Projects Fail in Government, Gartner website: 37 דו"חמטעםהממשלהאוסטרלי, אוגוסט 2008: Review of the Australian government s use of information and communication technology

38 סיכום ביצועיהם של פרויקטי IT ממשלתיים גדולים, הנאמדים ביותר מ 5 מיליון דולר: *מתוך 193 הפרויקטים שנבדקו, 34 היו פרויקטים גדולים. 50% מהמשיבים לגבי פרויקטים אלה בחרו שלא לדווח על ביצועי הפרויקט. יש לקחת בחשבון כי ייתכן ומי שלא ענו על שאלות אלה של הסקר, נמנעו מכך מסיבות הקשורות למידת הצלחת הפרויקט או ליכולת למדוד אותה. בדיווח התועלת, הייתה הענות משמעותית יותר. תועלת זמן עלויות דיווחו על הפקת תועלת מן הפרויקט אך לא סיפקו הוכחות למדידת התועלת דיווחו על מדידת התועלת מן הפרויקט והשוו את הציפיות מן הפרויקט לתועלת בפועל דיווחו על תוצאות שלא ניתנות למדידה לא ענו 36% 11% 38% 15% 38

39 מורכבות הפרויקט הממשלתי הקושי העיקרי בפרויקטים ממשלתיים הוא המורכבות הרבה שלהם מחד והרצון ליצור פרויקט גדול ניתן לחלק למורכבות פוליטית, את המורכבות של הפרויקטים הממשלתיים, ושאפתני מאידך. 38 ארגונית וטכנית. מורכבות פוליטית IT כהחלטה פוליטית: ישנה נטייה בקרב מקבלי ההחלטות הפוליטיות, להאמין כי IT הוא פיתרון לכל בעיית מדיניות. זאת, מבלי שהם מבינים לעומק מה ניתן ולא ניתן לבצע באמצעות הIT. שר או גורם פוליטי אחר אשר מקבל החלטה באשר לIT ללא ייעוץ מתאים, מסכן את יכולת התקיימותו הריאלית 39 של הפרויקט מן ההתחלה. הממשלה נוטה להיחפז ולפרסם כי היא מתחילה בפרויקט מערכות מידע, לעיתים מבלי ששקלה היטב את ההשלכות של הפרסום על ביצוע הפרויקט. ברמת התדמית, מקבלי ההחלטות הפוליטיות שואפים להראות החלטיות ומעשיות. הדרך להראות זאת היא הצגת פרויקט שאפתני הנתון לתאריכי יעד מוגדרים ונוקשים. תאריכי יעד: תאריך-היעד של פרויקט פעמים רבות נקבע עקב הצהרה או החלטה פוליטית זאת או אחרת ומבלי שנעשה הליך תכנוני מסודר וריאלי. תאריך יעד לא ראלי, עשוי לגרום לפרויקט להיקלע 40 לבעיות חמורות. חשוב להקפיד כי כל פרסום שנעשה לפני היציאה למכרז, לא ייתפס כהתחלה של הפרויקט (הדבר עשוי להשפיע על תפיסת העמידה בלו"ז). שקילה מחדש של הפרויקט ותנאיו: הסביבה הפוליטית היא דינאמית. כאשר ישנם שינויים פוליטיים המשפיעים באופן ניכר על הפרויקט, יש לשקול מחדש תנאים מסוימים בפרויקט כגון מטרות, זמן ומשאבים. גם כאשר ישנן בעיות חדשות או סיכונים חדשים, יש לשקול מחדש את תנאי הפרויקט. אולם, מהלך כזה של שיקול-מחדש אינו תמיד מתאים פוליטית וכך, לעיתים האחראים על הפרויקט מתפתים להמשיך כרגיל, גם כאשר אין זה מוצדק להמשיך את הפרויקט. מורכבות ארגונית מספר ארגונים, מטרות פרטיות: אחת הסיבות שהפרויקטים בממשלה מורכבים, היא העובדה שבדרך כלל מספר ארגונים, אוטונומיים, מעורבים. מכיוון שארגונים פועלים בראש ובראשונה לפי המטרות שלהם, התרומה שלהם לפרויקט תלויה במידה בה הפרויקט משרת את המטרות שלהם. שינוי ארגוני: ישנו קשר הדוק בין שינוי ארגוני והכנסת מערכת.IT לשינוי ארגוני נלווה זה עשויה להיות השפעה משמעותית על כל פרויקט הIT (למשל, עלולים להתערער סטאטוסים ותקנים אשר 38 מתוך: דו"ח של 39 -Netherlands Court of Audit גוף עצמאי לביקורת על הממשלה בהולנד, הממונה על-ידי הקבינט, מתוך: דו"ח שהוגש למשרד למדע וטכנולוגיה הבריטי, תקציר הדו"ח מתוך: הדו"ח לרכש-מהיר, בריטניה, 2002.

40 עלולים להשפיע על היקפו או אף התקיימותו של השינוי, מה שמשפיע על הפרויקט). משרדי ממשלה רבים אינם רואים בפרויקט הIT כקשור למטרות המשרד ולשינוי ארגוני, מעבר לעניין הטכנולוגי שבו. מורכבות טכנית קשיי שינויים בIT : ישנו חוסר התאמה טבוע ברמת הגמישות, בין מערכות הIT והתהליכים הפוליטיים והארגוניים. בעוד התהליכים הפוליטיים והארגוניים הם דינאמיים וגמישים מטבעם, הרי שמרגע שפרויקט הIT יוצא לדרך, קשה לשנות אותו. שינויים כאלה אפשריים, אך יש להם מחיר במונחים של חריגה בזמן ובתקציב. והשיטות השיטות מתיישנות במהירות, מתפתח בקצב מהיר מאוד. הIT התפתחות השיטות: החדשות שצצות במהלך חיי הפרויקט עשויות להאיר את האסטרטגיה שנבחרה באור אחר, פחות 41 חיובי. מעבר לכך, חשוב להיות מעודכנים טכנולוגית, גם כדי להיות ריאליים לגבי אילו מערכות סביר כי יספקו את הסחורה, להבין את המניעים המסחריים ולנהל באופן אקטיבי את הספקים. לעיתים המשרדים מתקשים בהשגת אנשים מיומנים שכאלה. קשיים בחיבור המערכות: לעיתים קרובות, מערכות IT צריכות להיות מחוברות למערכות אחרות שכבר פועלות. ישנו קושי לתאם בין המערכות, וקושי זה מתעצם כאשר מספר ארגונים מעורבים בכך. לרוב לא מעריכים מספיק את הבעייתיות שעלולה להיווצר כאשר הנתונים של הארגונים השונים אינם מתקשרים ביניהם. בשל המורכבות הרבה שיוצרים גורמים אלה, לעיתים קרובות הפרויקטים הממשלתיים שאפתניים מדיי ומורכבים מדיי. פרויקט שהוא שאפתני מדיי, לא יצליח לאזן בין המשאבים זמן,פיננסים וכוח אדם. לפיכך, מוטב: להתחיל בקטן ולהתקדם בצעדים קטנים, לצמצם את המורכבות. לשם כך מומלץ: להפחית/להגביל את מספר הארגונים המעורבים. העדפה של תוכנות סטנדרטיות. כלל ה 80/20 : 80% מהעבודה בIT נוגעת ל 20% מהאפליקציות. יש לשאול האם יש להכניס לתוכנה את כל היוצאים מן הכלל? האם לא ניתן לבצע כמה מהם באופן ידני? לחלק את הפרויקט למספר פרויקטים יותר קטנים ונשלטים. השרים כגורם משמעותי: מעבר לקולם הפוליטי של השרים, הם גם האחראים על הניהול וההוצאה לפועל של הפרויקט. לפיכך, יש לחזק את מעורבותם של השרים- פיקוח צמוד מצידם, על המתרחש במשרדם עשוי למנוע מהפרויקט להפוך לשאפתני מדיי ולא- ראלי. 41 דו"ח שהוגש למשרד למדע וטכנולוגיה הבריטי, ר' הערה

41 גורמים המשפעים על מידת הצלחת פרויקטים בממשלה 42 תכנון, ניהול ולמידה בממשלה- ניהול ותכנון נכון של הפרויקטים - משפיע ביותר: תשתית מנהלתית טובה לניהול פרויקטים של,IT ברשות מנהל/ת המיומנים בניהול פרויקטים והרואים עצמם אחראים על התהליך, יביאו להשגת פרויקט מוצלח. בבריטניה ובארה"ב מתפרסמות רשימות העוקבות אחר ניהול הפרויקטים שלהן, ואף מפרטות בעיות שכיחות המשפיעות על הצלחת הפרויקט., בחינה מתמדת של הסיבות להצלחת/כישלון פרויקטים מאפשרת לנהל את הפרויקטים הבאים ביתר הצלחה. IT פירוט הגורמים מנהלי מערכות מידע בממשלה ומנהלי 43 נכשלים ואחרים מצליחים. מפרטים את הסיבות לפיהן לדעתם פרויקטים מסוימים IT הסיבות לפי דעתם של 20 מנהלי מערכות מידע אמריקאיים, להצלחה/כישלון של פרויקטי ממשלתיים: שיטות/תכנון פרויקט מבוסס מסוגלות ניהול פרויקט מחויבות ואחריות לIT דרישות פרויקט ברורות גיבוי מן ההנהלה הבכירה משאבים/מימון מספיקים את הרשימה ניתן לכנס לשני הגורמים העיקריים החשובים ביותר להצלחת הפרויקט, המנהלים שנשאלו: תכנון טוב של הפרויקט ומסוגלות ניהול פרויקט. לדעת ר, 42 (2007) McClure, ' הערה 21. אלא אם צוין אחרת. 43 שאלות שמומלץ לשאול לפני התחלת פרויקט גדול אשר מתבססות על הגורמים הנ"ל, ניתן למצוא בנספח 1. 41

42 תכנון טוב של הפרויקט: על תוכניות הפרויקט להיות מוגדרות היטב: יש להגדיר היטב את הקריטריונים להצלחה, דרישות הפרויקט, לו"ז ריאלי, הערכה מדויקת של סיכונים, וידוא כי ישנם משאבים מספיקים וכן הגדרה אפקטיבית והוצאה לפועל של המתודולוגיות שנבחרו לשימוש. 44 דגשים: הערכה וניהול של העלויות - ההערכה והניהול של עלויות הפרויקט, הינם נקודת חולשה בממשלה. נראה, כי המשרדים אינם מבצעים ניתוח אנליטי מוקפד דיו, להערכה וניהול של העלויות במהלך חיי הפרויקט. הדבר נובע מכך שהאנליסטים המבצעים את ההערכות, לעיתים קרובות אינם בעלי הניסיון, הכלים או התמיכה הדרושים על מנת להצליח בתפקידם. כמו כן, לעיתים בתהליך בחינת העלות, חסרה מעורבות ועצת-מומחים מצד מתכנני הפרויקט וכן עצה של מומחה בטכנולוגיה. הערכה וניהול לא טובים של העלויות גורמים פעמים רבות לעלויות הגבוהות מן האומדן ובמיוחד בפרויקטים מורכבים של.IT ישנו קושי למצוא את השיטה האפקטיבית ביותר להערכת עלויות. על משרדי הממשלה לחשוב כיצד הם מכשירים ומפתחים צוות מנתחי עלויות של פרויקטים (או מנתחי פרויקטים באופן כללי). על מנהלי מערכות המידע להדגיש את נושא ניהול העלויות בפני צוותי הפרויקטים כנושא הקריטי להצלחת הפרויקט. ניתן לקנות תוכנות העוקבות אחר עלויות המשאבים ועלויות אחרות. כמו כן, ניתן להקים פורום בין-משרדי לנושא ניהול העלויות, אשר יביא הרצאות מומחים לנושא ויאפשר שיתוף ידע ורעיונות. 45 הגדרת מטרות : ביחס למערכות מידע, מתפתחות ציפיות לא-ריאליות ומנופחות. לפיכך, במידה ומתבצע פיתוח של מערכת, יש להציב מטרות צנועות ולעשות שימוש בטכנולוגיות שכבר הוכחו. על המנהל/ת במגזר הציבורי להיות אדם סקפטי וחשדן כלפי האימוץ של מערכות המידע. מסוגלות ניהול פרויקט: מנהלי פרויקטים מנוסים ומיומנים, חשובים מאוד להצלחת הפרויקט. מעורבות המנהלים של הפרויקט חשובה ביותר וכן חשוב שיהיה גיבוי מן ההנהלה הבכירה (בר סמכא לפתירת בעיות שעולות. הדבר מצהיר גם על חשיבות הפרויקט בארגון). בנוסף מומלץ לצוות לכל פרויקט איש - PMO שעיקר תפקידו לסייע בתכנון לוחות הזמנים, ומעקב שוטף אחריהם (יכול לעסוק גם במעקב אחר התקציב,תחקירי פרויקטים שנסתיימו ועוד משימות שונות בצד הפרויקט). 46 דגש : ניהול קשיים בפרויקט- פעמים רבות הקשיים והבעיות מתגלים עוד בשלביו המוקדמים של הפרויקט, אך ההנהלה והמפקחים על הפרויקט אינם מצליחים לפתור את הקשיים. זאת, עקב נטייה הקיימת במשרדי הממשלה שלא לפתור את העניינים המסוכנים. קבלת החלטות לגבי הפרויקט, נעשתה יותר מורכבת ולפיכך התעצם הצורך בניהול אפקטיבי. האחראים על הפרויקט (ראשי המשרד, המנהלים והמפקחים) לפתח מיומנות כך שיוכלו לגלות קשיים מוקדם ולקבל החלטות בזמן. אין לצפות ממנהלי הפרויקט לדעת את הדברים אינטואיטיבית ולפיכך יש להציע להם כלים טובים לשליטה וניהול הפרויקט ולקבלת החלטות (2006) Strauss, ר. ' הערה (2007) Goldfinch, ר' הערה.3 46 (2006) Strauss, ר. ' הערה.34

43 מומלץ כי הממשלה תגדיר באופן ברור ופרקטי תהליכים לשליטה בפרויקט. על תהליכים אלה, להתחשב בסגנון קבלת ההחלטות, התרבות והפרקטיקות הנהוגות בממשלה ולזהות דרכי פעולה, תפקידים, חלוקת אחריות ותוצאות מתבקשות. כמו כן, חשוב כי משרדי הממשלה יפתחו דרכים לתרגל ולהעריך את מיומנות המנהלים בכלים אלה (מעבר לפעילות השוטפת). במהלך תרגול שכזה ניתן להשתמש בסימולציות להתמודדות עם מצבים מסובכים בפרויקט. על מנת להצליח יש לדאוג לשיתוף פעולה בין הגורמים השונים במשרד. מומלץ להקים צוות אשר לרוב יורכב מ- בכיר/ה בהנהלה, מנהל/ת מערכות מידע, איש/ אשת פיננסים, מנתח\י מערכות, ראשי מחלקות, אחראי/ת משאבי אנוש. בעזרת צוות זה, על המנהל/ת IT של המשרד לקדם אימוץ של כלים ופרקטיקות לשיפור ביצועי הפרויקטים, פיתוח מקצועי של אנשי הפרויקטים, שיתופי פעולה בין- משרדיים שיאפשרו למידה משותפת, ויציעו מסגרות עבודה, כלים ושיטות. כמו כן, מומלץ למנהל/ת הIT לקדם את שיתוף הפעולה עם התעשייה- לדון ביחד בשיטות חדשות שצצו ובנושאים הקשורים למסירה של פרויקטי.IT גורמים ספציפיים לכישלון IT בממשלה מדוע פרויקטים ממשלתיים נכשלים- וגיבש 10 סיבות עיקריות: 47 מאמר של חברת גרטנר, אסף מידע ממקורות רבים ושונים מטרות פרויקט לא ברורות/לא ריאליות הנחות לא מבוססות, מטרות לא מוגדרות היטב, הערכת לוחות זמנים ועלויות לא סבירים. גודל ואורך פרויקטים פרויקטים על כל שלביהם מתנהלים לאורך שנים, בהן משתנות לרוב הדרישות, בעלי התפקידים וכיוצ"ב. חוסר מומחיות טכנולוגית/ניהולית של הספק החיצוני או חוסר היכרות מספק עם הארכיטקטורה הממשלתית טעות בבחירת הספק, בעיות תקשורת, העדר בניהול-מבוסס- ביצוע, פרקטיקות ניהול חוזה שאינן אפקטיביות. בעיתיות במשמעת-הפרויקט ובתהליכי השליטה, המונעים קבלת החלטות מודעות מנהל/ת פרויקט לא מיומן/ת, נהלים לא מוגדרים היטב לתהליכי המסירה,(Delivery) ניהול לא מספק של הפרויקט, העדר הערכה של ביצועים והתקדמות, מחסור בפיקוח, סמכות מעורערת. מעקב לא מספק כמנהלים בכירים שאינם מעורבים ואינם מיודעים, פרקטיקות-ביצוע שאינן בשלות, מחסור בכלים סטנדרטיים למעקב אחר ביצוע. ניהול לא אפקטיבי- תפקידם של בעלי העניין אינו מוגדר וכך גם לא מוגדרת האחריות המוטלת עליהם, תוכניות תקשורת בין בעלי-העניין שאינן אפקטיביות, חוסר מעורבות של היחידות העסקיות של הממשל, מנהלים בכירים שאינם מעורבים ואינם מיודעים. Strauss, H. (2006). Why IT Projects Fail in Government, Gartner website:

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

45 48 מערכות מידע בממשלה- הצעות לשיפור ניהול הפרויקט מקומו של מנהל/ת הפרויקט בהצלחת הפרויקט הוא מרכזי ביותר. כאן נציע חמישה דגשים מרכזיים, אשר עשויים לקדם ולשפר את ניהול הפרויקטים בממשלה. הכרה ברמות-המורכבות השונות של הפרויקטים בממשלה, המגוון והמורכבות של הפרויקטים גדלו מאוד וכיום לא ניתן להסתפק, כבעבר, בגישת ניהול אחת כללית. כיום, ניהול הפרויקט עשוי להשתנות בגישה ובמיומנויות הנדרשות בהתאם 49 למורכבות של תחום הפרויקט והעבודה עצמה : היקף הפרויקט עשוי לנוע מפרויקט של יחידה אחת ועד לפרויקט של מספר ארגונים. במקביל לזאת, מורכבות ניהול הפרויקט תלך ותגדל כאשר ההתמקדות תהיה במשימות ופעילויות בין-משרדיות. פעילויות ניהול פשוטות יתמקדו בעיקרן בפיתוח אפליקציות בודדות. בעוד בפרויקטים מורכבים יותר, יתמקדו הפעולות בניהול אפליקציות מרובות ובאינטגרציה שלהן ושל בסיסי נתונים. הבנה וקבלה של השינוי הארגוני בממשלה, ניהול פרויקט הוא בדרך כלל גם הדרך הנהוגה ליישם שינוי. תהליך שינוי הסביבה הארגונית (העסקית) של המשרד הנלווה לתהליך הטמעת מערכת המידע, עשוי להשפיע על מידת ההצלחה של הפרויקט. שינויים בתהליכים הם הראשונים לתת תשובה לדרישות הלקוחות, הפיקוח והמדיניות. כדי להביא לשינוי, ניהול פרויקט אפקטיבי יבטיח כי תהליכי הליבה הארגוניים- הממשלתיים ייבנו, יתועדו ויתוחזקו באופן קפדני. ניהול אפקטיבי של פרויקט,IT תלוי בהבנה לעומק של התהליכים-הארגוניים (עסקיים) הנלווים לפרויקט, לפיכך על המנהלי/ות הפרויקט, להיות מיומנים בהבנת שינויים בתהליכי-העבודה במשרדם וההשלכות שיש לשינויים אלה. הפקת תועלת מיחסי התלות שבין הפרויקטים בעבר, הגישה הניהולית הייתה שכל פרויקט עמד בפני עצמו, כל משרד התמקד בפרויקטים שלו. אולם, הדרך להבטיח כי שירות או ביצועים מתבקשים יושגו, היא עבודה משותפת לעבר מטרות משותפות, תוך שימוש בפרקטיקות עבודה עקביות. יוזמות גדולות, בדרך כלל מכילות מספר פרויקטים מתמשכים. כתוצאה מיחסי התלות שבין פרויקטים, מנהל/ת הפרויקט ניצב/ת בפני דרישות חדשות הנובעות ממערכת היחסים. למשל, שיתוף בידע שמופק מפרויקט (כגון שיפור בתהליכים) בשלב מוקדם- כך שיוכל להיות מאומץ ומיושם במהרה. לכן, צוותי פרויקט רב-תחומיים נעשים חיוניים. צוותים אלה, המורכבים ממנהלי IT ואחראי-מדיניות בעלי מיומנויות רב-תחומיות עשויים לסייע להפיק תועלת עבור התהליך. McClure, D. (2006). Adopt New Skills to Address Symptoms of IT Project Failures in Government, 48 Gartner website: 49 לתרשים מורכבות הניהולביחס למורכבות הפרויקט, ר' נספח 3. 45

46 ניהול האינטראקציה בין בעלי העניין התחום המסורתי של מנהל/ת הפרויקט, משתנה. מנהלים טובים, לא יתמקדו רק בזמן, עלויות, מעקב אחר המשאבים, ניהול סיכונים וכו'. קיימות נקודות אינטראקציה בין בעלי העניין השונים כגון- יחידות משרדיות שונות, אנשי הIT בתוך המשרד וספקים. חשוב כי יהיו קיימים מודעות וידע לנהל נקודות אינטראקציה אלה - העדר מיומנות כזאת והגדרות לא ברורות של התפקיד והאחריות עשויים לפגוע בהצלחת הפרויקט. על מנת לנהל אינטראקציות אלה, על המנהלים להיות בעלי יכולות גם בתחום העסקי. על ראשי המשרדים להעצים את מנהל/ת הפרויקט. לשם כך יש לקבוע את הגבולות והאחריות של התפקיד. מערך לקידום מיומנויות ניהול הפרויקטים קיים מחסור במנהלי פרויקטים מיומנים ומוסמכים ברחבי ממשלות העולם. ההכרה במורכבות הגוברת של הפרויקטים והסיכונים הכרוכים בחוסר ניסיון, הביאה לצורך לקבוע רמות-מיומנות מוגדרות הנדרשות ממנהלי הפרויקטים. ממשלות בעולם מתחילות לעדכן ולהגדיר מחדש תהליכי 50 הסמכה למיומנויות שונות ברמות שונות של ניהול פרויקטים : רמת ניהול הפרויקט 1- בתוך מחלקה או יחידה, רמת ניהול פרויקט 2- הדורשת אינטגרציה כלל משרדית ורמת ניהול פרויקט 3- הובלה של פרויקט בין משרדי או כלל ממשלתי, בעל סיכון גבוה. בהתאם לרמות אלה, יש לפתח את המיומנויות הניהוליות. 50 לתרשים רמות הניהול מול המיומנויות הנדרשות, ר' נספח 4. 46

47 מתודולוגיות מאת: דר' רועי גלברד, יו"ר תוכנית מערכות מידע, אוניברסיטת בר-אילן היבט המתודולוגיות שזור לכל אורך מחזור חייו של פרויקט מחשוב, החל משלב הייזום, בדמות בדיקות, פיתוח, דרך מתודולוגיות אפיון, מתודולוגיות לבחינת יישימותו וכלכליותו של פרויקט, ומעל לכל, הטמעה, ותחזוקה; כל שכן מתודולוגית לתיחור ובחירה בין ספקים במסגרת המכרז; כמעטפת כללית, מתודולוגיות ניהול ובקרה של כלל המרכיבים הנ"ל. יחד במסגרת הזמן, של פעילות הועדה, לא ניתן היה להעמיק ולבחון מי מבין המתודולוגיות הנ"ל. מהמפגשים שערכה הועדה: מפגש עם מנמ"רים של משרדי ממשלה, מפגש עם מנמ"רים עם זאת, שקוויה המתודולוגי, תמונה בהקשר עולה עם מנהלי בתי תוכנה, ומפגש של חברות מהמשק, העיקרים הם כדלהלן: העדר אחידות מתודולוגית- מסתבר שאין אחידות מתודולוגית בכל המימדים. לא במימד סוגי הפרויקטים, כלומר אין מתודולוגיה אחת ברורה לפרויקטים מסוג X ומתודולוגיה ברורה ומוגדרת אחרת לפרויקטים מסוג Y. לא במימד שלבי הפרויקט (אפיון, פיתוח, בדיקה, הטמעה). ולא במימד הניהול והבקרה. כאשר הנ"ל נכון הן ברמת כל משרד כיחידה נפרדת והן ברמה רוחבית של כלל המשרדים. כהערה, אציין שאחידות שכזאת אינה בנמצא גם לא בקרב צוותי עבודה ופרויקטים המבוצעים באותו בית תוכנה. נוהל מפת"ח אינו מספק את המעטפת הנדרשת- לטעמי, העדר האחידות נובע מהעובדה שנוהל מפתח עוסק ברמת ה"מה" ולא ברמת ה"איך". נוהל המסתפק ברמת ה"מה" אין בכוחו להבטיח שהתשובות הניתנות על ידי המשיבים, לסעיפים-שאלות המוגדרות בו, אכן מספקות ואכן איכותיות. אמחיש זאת באמצעות דוגמה פשוטה: נניח שפרוטוקול רפואי מבקש לדעת אם לחולה יש או אין חום ואינו מגדיר את הדרך ואת האמצעים לביצוע פעולת מדידת החום. במקרה שכזה כל אחד יכול לטעון ככל העולה על רוחו, כיוון שכל אחד אכן מדד חום, אלא כלומר, רמת ה"מה" שביקשה שביצע זאת על פי מתודולוגית "מדידת החום" שפיתח לעצמו. לעולם לא יכולה להיות מספקת אם לא נלווית אליה רמת ה"איך", שתיערך בדיקת חום, המגדירה את הפרוטוקול והמדדים בנוגע לאופן בו יש לבצע את מדידת החום. לטעמי, למרות שכל בית תוכנה היה רוצה להשאיר את ה"איך" ל"יצירתיות" שלו, אין לקבל את גישתם ולו בגלל העובדה שעלתה בפגישה איתם, לפיה בתי התוכנה אינם משקיעים, ואינם מעוניינים להשקיע היא ניסוח עדין של מתודולוגיים אלו. כך שה"יצירתיות" בהיבטים (משיקוליהם הם) בעתיד "סמוך." בהיבט האפיון - באופן כללי, ההערכה היא שעובדים עם ניסיון והיכרות עם פעילויות המשרד (בלא קשר לאופן העסקתם) מוכשרים יותר לביצוע עבודות הניתוח והאפיון. מעבר לכך, כפי שנאמר בסעיף 1, אין כל אחידות באופן ביצוע האפיון, לא במשרדים השונים ולא בפרויקטים השונים

48 בהיבט תיחור ספקים- ההערכה הכללית היא שאין כיום כל מתודולוגיה ו/או מנגנון ליצור תחרות בין הספקים. תחרות שתבוא לידי ביטוי בשיפור ביצועיהם בפרויקטי המחשוב, ובכלל זה שיפור עמידתם במסגרות זמן, משאבים ותכולות. במצב הנוכחי כל פרויקט-מכרז נידון בפני עצמו, כאילו לראשונה, וכאילו מעולם לא הייתה היכרות, לא עם המתמודדים ולא עם פרויקטים דומים, במשרדים השונים..4 נושא המכרזים ומסגרת נוהלי חשכ"ל לעריכתם, נידונים בפרק נפרד. לפיכך, כל שאציין זה שמין הראוי לקשור את שיטות הבדיקה והתיחור שיוגדרו, באשר הם, למתודולוגיות ולכלים שהממשלה הייתה רוצה שבאמצעותם יבוצעו וינוהלו פרויקטי מחשוב בעתיד. בבחינת הגדרת "איך" ספציפי לכל אחד מהנ"ל. בהיבט מתודולוגיות פיתוח- במסגרת הועדה עלתה סוגיית "מפל המים" אל מול גישות,Agile כמו גם התמונה בנוגע לשונות הגדולה בין המשרדים, בכל הקשור לתשתיות פיתוח. לדוגמה, במשרד לביטחון פנים מצטיירת תמונת תשתיות פיתוח דלה ביותר, ביחס לאלו הקיימות במשרדים אחרים כדוגמת מנהל מקרקעי ישראל או הלמ"ס. נושא השונות ברמת התשתית כמו גם השונות ברמת הידע והניסיון צריכים לעמוד במרכזו של כל פיתרון שיוגדר. מתודולוגית הפיתוח, כמו מתודולוגיות האפיון והניהול, צריכה להיגזר ממאפייני הפרויקט ובכלל זה: בהירות היעדים, סיבוכיות פונקציונאלית, חדשנות טכנולוגית, וכד'. בהמשך הפרק מוצגות שלוש גישות עקרוניות במרחב הפתרון, במסגרתן ישנה התייחסות גם לנושא הפיתוח. אך הדיון בהיבטי הפיתוח, לטעמי, אמור לבוא רק בשלב מאוחר יותר, ולאחר אימות בפועל של ההמלצות בתחום האפיון. זאת, עקב מורכבות הנושא והפתרונות בהתאם. בהיבט מתודולוגיות ניהול ובקרה - לכל ידוע שתרשים גאנט משקף רק את מה שדווח בו. כל הדברים שלא "נאמרו" ושלא נובעים באופן ישיר מדיווח אודות שעות עבודה ואחוזי ההתקדמות (מוטלים בספק), כל הנ"ל נתון לא רק לפרשנות, אלא לתוצאות שונות שיש בהן כדי להפוך את תמונת המצב על פיה, באופן מוחלט. לאור הנ"ל, גאנט כזה או אחר אינו במוקד הדיון המתודולוגי, גם לא שקיפות הגאנט הנ"ל לשותפים בפרויקט, כי אם שלוש השאלות הבסיסיות: (1) מהותן של אבני הדרך אותן יש לבקר (2) אופן בחינת העמידה באבני הדרך הנ"ל (3) מנגנונים להשבת הפרויקט למסלולו במקרים של חריגה באבני הדרך. מעבר לכך, בהקשר של נהלי המכרז ותיחור הספקים, יש כמובן לדון במנגנוני פיצוי ובמנגנוני התנתקות למקרים של אי עמידה באבני דרך קריטיות או בפרויקט ככלל..5.6 לאור הנ"ל סעיף ההמלצות ידון בעיקרו בהיבט האפיון. היבט הפיתוח סבוך ומורכב, ארגונית, טכנית ומתודולוגית הרבה יותר מהיבט האפיון. לפיכך, ראוי לאמת תחילה את היבט האפיון, וברוח התובנות שיתקבלו בו, לבחון את החלופות בתחום הפיתוח. לפיכך, כאמור, סעיף ההמלצות מציע פעולות אופרטיביות בהיבט האפיון, ואילו אל היבט הפיתוח אתייחס רק במסגרת שלוש גישות עקרוניות להגדרת מרחב פתרון כללי. היבט הניהול והבקרה, כפי שהובהר, אמור להיגזר מהיבטי האפיון, הפיתוח, נוהלי המכרז ושיטת תיחור הספקים. 48

49 ראוי לעשות הבחנה בין שלוש פעילויות מחשוב פרויקטים המתייחסים לפעילות מהסוג השלישי. פעילות (ר' המלצות בהמשך). שונות. כאשר, מרבית הכשלים הנידונים הם של בהתאם לכך, ההמלצות מתייחסות לסוג זה של פעילות תפעול ותחזוקה- מתייחסת למערכות מבצעיות באשר הן. מערכות שבהתאם לצורך עוברות שינויים ושיפורים באופן שוטף. פעולה שמבוצעת על ידי צוות המערכת הקבוע (בלא תלות לאופן העסקת אנשי הצוות הזה).צוות המכיר וחי הן את הפן הטכני והן את הפן התפעולי של המערכת. כפי שצוין, הפעילות הנ"ל עומדת ככלל במסגרות הזמן והמשאבים המוגדרים לה. פיתוח גנרי- מתייחס לפרויקטים של הטמעת מערכות "מדף"- מערכות שהספק התנסה מספר פעמים בפיתוחן-הטמעתן בארגונים דומים, כגון פרוייקטי,CRM,ERP המרה בין סביבות וכדומה. אם נתעלם לרגע משאלת הדמיון (האם הטמעת ERP בחברה כזו או אחרת משולה להטמעת ERP בממשלה... ), הרי שניסיונו החוזר ונשנה של הספק, בתחום זה, אמור להניב אחוזי הצלחה גבוהים ואין מקום לנסות ו"להתחרות" בספקים בתחום זה, לא בהיבט המתודולוגי ולא בהיבט הניהולי. פיתוח אפליקציות ייחודיות- מתייחס ליישומים ייחודיים המפותחים במשרדים השונים. יישומים שאין להם תוכנות "מדף" מוכחות, ושאין להם מקבילות קרובות במשק, או אף במשרדים אחרים, ומכאן שיש צורך בפיתוח מבראשית של אפליקציה ייעודית-ייחודית בנושא. פרויקטים בתחום זה סובלים מאחוזי הצלחה נמוכים וכמובן גם מכישלונות מוחלטים. המאפיין הייחודי לפרויקטים אלו, הוא כאמור, היותם חד פעמיים ומתוך שכך רמת הסיכון בהם גבוהה יותר. האם על הממשלה לקחת חלק בסיכון זה? התשובה לטעמי שלילית לחלוטין, אלא אם מגדירים את הפרויקט כ- Joint Venture לפיתוח מוצר, שאמור להימכר בהמשך ללקוחות נוספים והממשלה שותפה ברווחים שיופקו. מכיוון שברור שאין זה כך, אין מקום, לטעמי, שהממשלה תיקח חלק בסיכון. בסוג זה של פרויקטים, לטעמי, המענה לסיכון צריך להתקבל משני מקורות: (1) מסגרת המכרז שאמורה לאפשר גמישות מסוימת של הפרויקט ובכלל זה הרחבה מצד אחד והתנתקות מצד שני (2) הגדרה ברורה ומדויקת של אבני דרך, כפי שצוין קודם, בתת סעיף 6. 49

50 הקדמה פרק זה מבקש לבחון את שלב הרכש פרק 2 1 כמכלול. רכש ראשית, הפרק מציג את מעגל החיים של שלב הרכש בפרויקטים של מערכות מידע. מודל זה, מלווה בהסבר לגבי נקודות הביקורת הקריטיות- על פי משרד המסחר הבריטי. לאחר מכן, הפרק מבקש לזהות את הגורמים לעיכובים וקשיים בשלב הרכש ומוצעות המלצות כיצד להימנע או להתמודד עם גורמי הקושי, על מנת לאפשר את הצלחת הפרויקט. בסופו של הפרק מובאת סקירה עולמית על מדיניות ומצב הרכש בארה"ב, קנדה ואוסטרליה. תקציר מנהלים מחזור החיים של שלב הרכש מחזור החיים מורכב משלבים בהם מפורט מה יש לבצע בכל שלב. בנקודות ההחלטה הקריטיות, מופיעים שערים- אלו הם נקודות הביקורת המרכזיות של הפרויקט. בנקודות הביקורת מתבצעת בדיקה של השלבים שנעשו וניתן אישור המשך לשלב הבא. מניעת קשיים או התמודדות עימם בשלב הרכש יש לשים דגש על התנהגות הממשלה כלקוח חכם. שלב רכש מהיר- עשוי להועיל להגברת התחרות ובכך להביא גם לרכש איכותי יותר. מאידך, על הממשלה להקפיד על רכש מהיר ובטוח, הבנוי מלוח זמנים בר- השגה כאשר היא אינה מתפשרת על תמורה לכסף, איכות ועוד. נתיבי הבריחה של הזמן- המסמך מונה את גורמי העיכוב המשמעותיים ביותר לשלב הרכש בפרויקטים ממשלתיים. הגורם לעיכוב הרב ביותר הוא סיבוכיות יתר של הפרויקט. עוד גורמים שנמנו: חוסר מחויבות מצד ההנהלה הבכירה, תכנון לוקה בחסר, אי- הבנת השוק, צוות שאינו מיומן, ניהול לא אפקטיבי. על מהירות שלב הרכש, משפיעים גם גורמי השפעה חיצוניים כגון תפיסת הציבור את הפרויקט ומחויבות ממשלתית וכן גורמים שונים מצידו של הספק. המלצות לשיפור העתיד- המסמך מונה מספר המלצות, להאצת שלב הרכש. גורמי האצה כלליים- תכנון מדוקדק, מנהיגות אפקטיבית, שימוש במסגרות עבודה, שימוש במכרזים אלקטרוניים וכן- עוד מספר פעולות מצד הלקוח הנוגעות לניהול הפרויקט. מרבית פרק זה מבוסס על מסמך ה-, FASTER PROCUREMENT בריטניה, מאי מקורות נוספים, מצוינים במקומות המתאימים. 50 1

51 פעולות מצד הממשלה- על הממשלה לנהוג כלקוחה חכמה. לשם כך, על המשרדים לוודא שהתרבות הארגונית שואפת למסירה מוצלחת וכי צוות הפרויקט שלהם בעל היכולות הדרושות. לשם כך, מובאים מספר דגשים לביצוע. המודל הבריטי- הבריטים מציעים תוכנית לפיה משרד המסחר יסייע לשיפור הפרויקטים. המשרד מציע ויציע בעתיד: כלי סטנדרטי להערכת יכולות, מדריך לשיפור ביצועי הפרויקט ומדריכים נוספים, פיתוח של ההנהלה הבכירה וייעוץ וסיוע בניהול הפרויקט. הבריטים מדגישים כי שיתוף ידע הוא הכרחי ללמידה משותפת מן הניסיון ולפיכך משרד המסחר ירכז את דוחות המשרדים השונים לטובת הכלל. משרד המסחר ממונה על מעקב אחר ההתקדמות בשיפור הפרויקטים והוא אף מדווח על כך לשרי-הממשלה. סקירה עולמית- שלב הרכש פרק זה סוקר את הנעשה בארה"ב, קנדה ואוסטרליה בתחום הרכש בכלל וברכש הIT בפרט. סקירה זו נועדה להעניק מבט כללי על המדיניות ופרטים לגבי שיטות הרכש יפורטו בשלב מאוחר יותר של דוח זה. דגש רב בקרב המדינות, מושם על שימוש במסגרות עבודה ושימוש ברכש אלקטרוני. במסמכי הממשלות מובהר כי חשוב ביותר לזהות מה נדרש מכל תהליך רכש ספציפי- זיהוי ברור אינו פשוט עבור הממשלות, שכן בדרך כלל מטרותיהן הן רבות-פנים. מעבר לכך, משרדי הממשלה אינם תמיד מאורגנים לקידום מסירה מוצלחת. לפיכך, יש צורך לזהות עניין זה כחשוב ולקדם אותו. ארה"ב- הינה הלקוחה הגדולה בעולם מבחינת היקף רכישותיה. הGSA - הינו גוף הרכש הגדול ביותר שלה, אשר מרכז גם את הסיוע לתהליך הרכש. הממשל האמריקאי שם דגש על הנושאים הבאים: אחידות במערכת הרכש והגברת השימוש במערכת האלקטרונית, מיקוד בתרבות של "מסירה", שימוש מרבי בשיטת הPBC - "חוזה מבוסס ביצוע", סטנדרטים ברורים ועד כמה שרק ניתן זהים לאלה של המגזר הפרטי וצוות מיומן. כמו כן, מובאים מספר אמצעים בהם השתמשו האמריקאים בכדי לקצר את זמן הרכש. בעניין רכש של,IT מודגש: שקיפות, שיתוף ודיווח בממשל האלקטרוני, מערכת אחידה בין המשרדים והממשלה, זיהוי דרישות, ניהול סיכונים, חיסיון ושימוש בחוזה מודולרי. קנדה- הממשלה הקנדית היא הגוף המבצע הכי הרבה רכישות בעולם אחרי ממשלת ארה"ב. גוף הרכש המרכזי שלה,(PWGSC) מבצע כ- 85% מן הרכש, כולל ניהול החוזים של הפרויקטים הגדולים ביותר. הקנדים מבקשים לשים דגש על רכש אלקטרוני והקימו לשם כך מערכות שונות המתמודדות עם רכש בהיקפים שונים. הקנדים, פתחו מאגר ספקים ממנו יכולים משרדי הממשלה לבחור עם מי לעבוד לפי צרכיהם. ברכש IT מושם דגש על מוכוונות ללקוח, אחידות המערכת וביצוע סטנדרטיזציה של התהליכים. 51

52 אוסטרליה- משרד הכספים האוסטרלי, מפרסם מסמך המהווה את מדיניות מסגרת העבודה ברכש האוסטרלי. מדיניות זאת מתווה קווים כלליים תוך שהיא מאפשרת למשרדים/מחוזות לפעול בתוכה ולקבוע את פרקטיקות הרכש המתאימות להם. עיקרון הליבה עליו מושתת הרכש האוסטרלי הוא עקרון התמורה לכסף money).(value for האוסטרלים מבקשים להשיג עקרון זה באמצעות עידוד תחרות, קידום השימוש היעיל, האפקטיבי והאתי במשאבים ושקיפות ואחריות בקבלת ההחלטות. גם האוסטרלים מדגישים את חשיבות פיתוח הרכש-המקוון, הכשרת הצוותים ושיתוף ידע. לגבי רכש,IT מוצגת תמצית המסקנות, של דו"ח שהוגש בשנת 2008, מודגש קידום נושא הממשל האלקטרוני, מאגר מקוון של ספקים לממשלה ודגש על מסגרת עבודה כללית. 52

53 מחזור החיים של שלב הרכש- פרויקטים של מערכות מידע השערים- מופיעים בנקודות הקריטיות לקבלת ההחלטות, בכדי לסייע לאחראי/ת הבכיר/ה על הפרויקט. מפורטים בנספח 5. פיתוח תיק עסקי מבוסס, אשר יצדיק את מטרת הפרויקט ואשר יסביר מדוע ההשקעה אפשרית מבחינה פיננסית וכדאית מבחינת התמורה עבור הכסף. יש לבחון את כל האופציות אל מול-מטרות, ההתאמה האסטרטגית, רווחים פוטנציאלים, אפשרויות מסירה מול עלות. יש גם להבהיר כאן מה לא כדאי לעשות. ניתוח אסטרטגי לפני התחלת פרויקט חדש. תכנון הרכש הפוטנציאלי וכיצד ינוהל. זהו השלב לבחור את שיטת הרכש המתאימה, ניתן להשתמש בחוזים קיימים. בשלב זה יש לזהות דרישות, להתערב ולהתעניין בשוק על מנת ללמוד עליו יותר. יש לזכור כי המטרה היא להשיג את התמורה הטובה ביותר סיום שלב הרכש של הפרויקט באופן מסודר- אם מכיוון שיצא לפועל, אם מכיוון שנכשל. החשוב ביותר בשלב זה, הוא להשלים את הלמידה ממה שהתרחש בשלב הרכש. צורך בזהות שער 5 שער 1 שער 2 פיתוח אסטרטגיית הרכש ופירוט הדרישות. על הניתוח להציע מספר אפשרויות ועל הדרך הנבחרת להיות זו שמשיגה את התמורה הטובה ביותר לכסף. על הדרישות להיות מנוסחות במונחים של תוצאות עבור הלקוח (מה להשיג ולא כיצד) ומפורטות מספיק על מנת שיתאפשר לשוק להגיב אליהן. פיתוח אסטרטגיית רכש לכל שלב קיימים מדריכים מפורטים כיצד לבצעו סיום ניהול החוזה שלב הביצוע של הרכש. ניהול אפקטיבי לאחר הענקת החוזה. זהו השלב הארוך ביותר ובפרויקטים של IT עשוי לארוך בין 7 ל 10 שנים. חשוב כאן, כי בארגון יימ צאו מיומנויות הניהול הנדרשות בפן הטכני, העסקי והשירותי. שער 4 פיתוח תיק פרויקט מוטב להבין את השוק כבר מן השלבים הראשונים של הרכש. כאן כדאי לבחון את יכולת-ההתקיימות של רעיון הפרויקט בשוק- לבדוק את תגובות הספקים ולעודד את המתאימים שבהם לגשת למכרז. כמו כן, זהו השלב לעודד או ליצור שווקים היכן שהתחרות מוגבלת או היכן שנוצר צורך בכך. חקר השוק בחירת הספק יצירת עניין מצד הספקים ובחירה מי ישתתפו בדיאלוג- התחרות. מומלץ לערוך שאלון מקדים בקרב המועמדים שהביעו עניין לבחינה ראשונית של התאמתם. בשלב זה יש לבחון את מצבם הפיננסי של המועמדים ואת יכולותיהם הטכניות לספק את דרישות הפרויקט. מומלץ להיוותר עם לפחות 3 מועמדים. הענקת חוזה שער 3 דיאלוג תחרותי ביצוע של הפרוצדורה לדיאלוג תחרותי- מאפשרת להעריך את ההצעות של המתחרים שנבחרו. מומלצת במיוחד בפרויקטים מורכבים. מוטב לנהל דיאלוג מקיף ככל האפשר אשר יכיל, בדרך את הטיוטה של החוזה, המודל המוצע, ותנאים שונים. כלל, גם 53 בסופו של דבר, כאשר נראה כי נענו הדרישות היטב, ניתן להזמין את המתחרים לשלב ה.Best & Final בחירת המתחרה הטוב ביותר Final) (Best & והענקת החוזה. בשלב ה,Best & Final החוזה יוענק על בסיס הפיתרון שהציע כל מתחרה במהלך שלב הדיאלוג ואשר ממלא באופן מספק את הדרישות של הפרויקט. לאחר בדיקה של המסמכים, ואישור כי כל הבדיקות הרלוונטיות נעשו, ניתן לחתום על החוזה. מוטב לוודא כי הארגון מוכן ליישום.

54 מניעת קשיים או התמודדות עימם בשלב הרכש חשיבות אפקטיביות-הרכש הזמן הרב שלוקח מגיבוש הקונספט של הפרויקט ועד להתקשרות, פעמים רבות מעכב את יישומן של מטרות ממשלתיות מרכזיות. המגזר הפרטי מוטרד מהזמן והעלות שעליו להשקיע במכרזים הציבוריים ובכך, המגזר הציבורי נעשה פחות אטרקטיבי עבורו. הדבר משפיע, כמובן, על אלמנט התחרות. יש להתייחס לרכש כעניין אסטרטגי- על מנת שהממשלה תוכל להשיג את התמורה הטובה ביותר לכסף, על הממשלה להתנהג כלקוח חכם. מהירות-אך לא בכל מחיר במאמציה לקצר את לוחות הזמנים של שלב הרכש, על הממשלה לשים לב כי אינה מתפשרת על: התמורה לכסף, איכות סבירה (ניתן להתפשר על פונקציות מסוימות לטובת זמן/עלות של הרכש), יחסיה עם לקוחות/ שותפים/ ספקים, רמת- סיכונים סבירה, מילוי של הדרישות החוקיות הנוגעות לרכש ציבורי. יש להקפיד על רכש מהיר בטוח- מוטב ליצור לוח זמנים מהיר ואמין, מאשר לוח זמנים שאפתני- מדיי, שאינו בר השגה או לחלופין, שאיננו בטוח. מה מאפיין פרויקטים מוצלחים ומהירים בממשלה במימד הרכש: פישוט הוראות הרכש והפרוצדורה. כגון (trade-offs) קיומן של דרישות ברורות וניהול אפקטיבי של שקלול תמורות פונקציונאליות מול זמן/ עלות. התמקדות במסירה (Delivery) לאור מטרות ברורות. ניהול אפקטיבי של בעלי העניין. תחלופה נמוכה של אנשי הפרויקט והדרגים הגבוהים. מסייעת להימנע משינוי דרישות. מנהל/ת פרויקט מוכשר/ת, הנתמכ/ת גם בצוות אפקטיבי ומיומן. שימוש מושכל (ולא זהיר-מדיי!) בפרוצדורות הממשלתיות. הבנת השוק הימנעות מיחסי- יריבות, מסייעת להימנע מאי-הבנות ומו"מ ארוך. ניהול אפקטיבי של נושאים טכניים. הימנעות מסיבוכיות-יתר ומתאריכי-יעד שאינם ריאלים. 54

55 נתיבי הבריחה של הזמן גורמי העיכוב המשמעותיים ביותר- בפרויקטים ממשלתיים. כולם עיכבו את הפרויקטים בהיקף של חודשים, להוציא הגורם הראשון, שגרם לעיכובים בהיקף של שנים: סיבוכיות- יתר- ניסיון לכלול את כל הדרישות הידועות ועוד...בהגדרות התכולה. פרוצדורות תכנון המעוגנות בחוק. הגדרה שגויה של היקף, דרישות ושקלול תמורות (Trade-offs) הוסכמו על ידי דרג גבוה מספיק (אף ברמת השר, כאשר הדבר רלוונטי). או אי-וידוא כי הללו שינויים בדרגים הגבוהים (רמת ההנהלה/ הרמה הפוליטית) שהובילו לשינוי בדרישות. שינויים בהיקפים creep),(scope עקב בעלי עניין שאינם מנוהלים כראוי. 52 זמן רב הלוקח לאישור תיק הפרויקט. מהירות קבלת ההחלטות וקבלת האישורים מן משרדיות, ועדות ממשלתיות ופרוצדורות תכ"ם. השונים הגורמים השונים, זהירות-יתר בשימוש בפרוצדורות הממשלתיות, היוצרת עיכובים במכרז. עתירות משפטיות בנושא מכרזי הממשלה. התמשכות תהליכי מכרזים הנובעת מחוסר בהירות או אי-הבנה. חוסר שליטה ביועצים החיצוניים או אי- תמרוץ שלהם לפעול לצמצם את העיכובים. ועדות o o o o o o o o o o o גורמי השפעה חיצוניים לפרויקט- החלטות ממשלתיות של הדרגים הגבוהים, מחויבות ממשלתית ותפיסות של הציבור את הפרויקט עשויים להשפיע על לוח הזמנים של הרכש באופן משמעותי. לפיכך, מומלץ לדבוק בהצעות הבאות: מוטב לקבוע תאריכי-יעד ולסכם התחייבויות, רק לאחר שנעשתה תוכנית יישום אפקטיבית. חשוב להקפיד כי כל פרסום שנעשה לפני היציאה למכרז, לא ייתפס כהתחלה של הפרויקט (הדבר עשוי להשפיע על תפיסת העמידה בלו"ז). קביעת הדרישות לפני תחילת הרכש, ולפני שנעשית איזו שהיא מחויבות ציבורית לתאריכי יעד. מוטב לוודא כי בעלי-עניין בכירים לא ישנו ללא צורך את הדרישות, לאחר שתהליך הרכישה התחיל. אם הדבר בלתי-נמנע, יש לקחת בחשבון את כל ההשפעה של השינוי על פרויקט. ככל שתהליך הרכש יתארך, כך גדלה הסבירות שהדרישות ישתנו! גורמים המשפיעים מצד הספק - על מהירות תהליך הרכש: הבנתו את סוג העסק של הלקוח, דרישותיו ותהליכיו- חוסר הבנה את הלקוח עשוי לגרום לעיכובים ואכזבות. יש לבדוק עד כמה הספק אכן מסוגל לעמוד בדרישות השוק (עומד בחסמי-כניסה לשוק) ובעל היכרות עם הידע הנדרש. 52 תיק הפרויקט מגדיר בעיקרו את ההצדקה לקיום הפרויקט- הרווח מן הפרויקט והצרכים שהפרויקט ממלא- עשוי להתבטא בשיפור השירות לאזרח, חיסכון בכוח אדם, ייעול התהליכים הפנימיים והבין-משרדיים וכדומה. 55

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

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

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

59 צוות מנוסה ומיומן- על המשרדים לעשות מאמץ להבטיח כי צוות הפרויקט הינו בעל המיומנויות והניסיון המתאימים. כאשר ישנו שימוש ביועצים חיצוניים, יש להבטיח כי קיימות מיומנויות בתוך-המשרדים, לניהולם. חשוב כי היועצים יהיו מנוסים במסירה מוצלחת וכי יהיו תמריצים לעודדם לסייע בהצלחת הפרויקט ובהשלמתו המהירה. ניהול יעיל של תיק הפרויקט והפיננסים- תיק איכותי, פשוט, ברור ומאושר, תקציב אפקטיבי. ניהול אפקטיבי של סיכונים- יש להבהיר את הסיכונים ומיקומם (לקוח-ספק). ניהול נושאים טכניים- על המשרד להיות בעל יכולת לקבל החלטות טכניות מצדו (הלקוח). אם יש צורך, ניתן להביא מומחה טכני. גם את הסיכונים הטכניים יש להבהיר, למקם ולנהל. התערבות אפקטיבית בשוק- ציפיות ריאליות מהשוק (אם יש צורך-יש ללמוד את השוק), פיתוח מערכת יחסים פתוחה, חזקה והוגנת עם הספקים, וידוא כי הדרישות הובנו, שליחת טפסי המכרז רק לחברות שידוע כי מסוגלות לבצע את העבודה. מסגרות עבודה- מוטב להשתמש במסגרות עבודה שכן הדבר עשוי לחסוך זמן ומאמץ. אולם- עבור רכש גדול ומסובך, מסגרות עבודה עשויות להיות מגבילות מדיי. תמיכה אלקטרונית- מומלץ לעשות שימוש בתקשורת האלקטרונית לתמיכה ברכש. הערכת ושיפור יכולות- לפני התחלה של פרויקט, מומלץ לסקור את יכולות הביצוע והניהול של פרויקטים במשרד. על פי ההערכות הללו, על המשרדים לקבוע לעצמם סדר-יום לחיזוק מקומות של חולשה ולהסרת חסמים בדרך להצלחה. דיווח על ההערכות ותוכנית השיפורים- מומלץ כי המשרדים יגישו דיווח שיוגש לדרגים הגבוהים (אצל הבריטים- דיווח למשרד המסחר). מומלץ כי לדיווח יתווספו גם קשיים עם תוכנית השיפורים וגם הצלחות שהיו- על מנת שגם המשרדים האחרים ירוויחו משיתוף המידע. מציעים כי התוכנית להערכת היכולות שהציעו (כאן בהמשך), תבוא לידי ביטוי גם כאן. שיתוף ידע בין המחלקות- מומלץ ליצור שיתוף ידע בין המחלקות. אם דרך ריכוזו של משרד המסחר ואם דרך רשתות ידע. משרד המסחר אוסף את כל דוחות הסיכום של הפרויקטים השונים, ומסכם את מה שנלמד מהם לכדי מדריך לפרקטיקה טובה (כאן בהמשך) כך שכל המשרדים יוכלו ליהנות מן הידע המצטבר. המודל הבריטי- סיוע משרד המסחר למשרדי-הממשלה, בשיפור הפרויקטים דוחות ביקורת- מאז שנת 2001, צוות עצמאי ומיומן בדק נקודות מפתח בפרויקטים ממשלתיים. הדוחות אינם ציבוריים אלא מוגשים לאחראי הבכיר ביותר על הפרויקט, כך שיתאפשר שיח פתוח. לפרויקטים ניתנים 3 צבעים אפשריים: אדום- על מנת להצליח, הפרויקט לנקוט פעולות תיקון מיידיות; צהוב- על הפרויקט לבצע את המלצות הביקורת לפני נקודת המפתח הבאה; ירוק- הפרויקט בדרך נכונה, אם כי מוטב כי יתחשב בהמלצות הביקורת. צוות הבדיקה ימנה בין 3 ל 5 אנשים, ובכל נקודת מפתח, תארך הביקורת בין 3-5 ימים. בתוך שנתיים, הושלמו יותר מ 500 דוחות בנקודות מפתח, עבור פרויקטים בשווי של 59

60 יותר מ 60 מיליארד ליש"ט. הפרויקט מיועד לחסוך יותר מ- 500 מיליון ליש"ט במונחים של 53 תמורה עבור הכסף. כלי סטנדרטי להערכת יכולות (נספח 7) שמוצע ע"י משרד המסחר. באמצעות כלי זה, יוכלו המשרדים לבצע בידוק-עצמי לגבי ההצלחה שלהם בניהול הרכש, וכך לקבוע תוכנית כיצד לשפר את יכולתם- אל מול אינדיקאטורים שיסייעו להם בכך. התוכנית וההערכה שלה, ייבדקו כל שנה ע"י משרד המסחר. יצירת מדריך לשיפור ביצועי הפרויקט- משרד המסחר יוצא תוכנית עבודה אחת ממוקדת, לשיפור של ביצוע פרויקטים. המדריך ירכז את הפרקטיקות והסטנדרטים הטובים ביותר, כך שתתגבש גישה יותר אחידה. המדריך יהיה ממוקד בשיפור ביצועי הפרויקט, חשוב כי הוא יעודכן וישופר מעת לעת, ויעסוק בתכנון, הכנה ותפקיד ההנהלה הבכירה, בנושאים של הדרכה לגבי תיק עסקי, טפסים סטנדרטיים לכתיבת הדרישות כולל דוגמאות, הדרכה לשימוש חכם בפרוצדורות של האיחוד האירופי, הדרכה לקיצור-רשימות המכרז והערכה לפי קריטריונים סטנדרטיים, הדרכה לגבי מו"מ ונושאים שצצים לאחר המכרז. הנושאים יקיפו את מעגל החיים של הפרויקט. פרסום מדריכים (חלקם קיימים כבר היום) בנושאים: "חוקי זהב"- הדרכה לעמדות המפתח בפרויקטים, מה חובה עליהם לעשות בכדי למלא את תפקידם. מומלץ כי יוכן גם מדריך לאנשים החדשים בתפקידים אלה. ניהול סיכונים- מדריך בנושא זה, המלווה גם בהדרכה להכשרת צוות הפרויקט בנושא. מיומנויות למסירה מוצלחת- תוכנית עבודה שפיתח משרד המסחר להכשרת צוות הפרויקט, מומלץ כי רק מי שהוכשר בתוכנית/בתוכנית מקבילה יוכל להשתתף בפרויקט. פיתוח וחיזוק ההנהגה הבכירה- ההנהלה הבכירה תשתתף בתוכנית ייעודית לה, אשר תכיל גם את המרכיבים של תוכנית המיומנויות למסירה מוצלחת, ותעסוק בתרבות וההתנהגויות הנדרשות מן ההנהגה. על המנהלים הבכירים להבין כי תפקידם להאיץ ולהקל על תהליך הרכש ועל הפרויקט בכלל. דגש על סיוע בתחומים- מסגרת עבודה- משרד המסחר יציע הדרכה מתי להשתמש באיזה מסגרת-עבודה, וכיצד לעשות בה שימוש מתאים. המשרד יוסיף לחפש באופן מתמיד מסגרות- עבודה חדשות. הבנת השוק- משרד המסחר יעודד פרקטיקות להבנת השוק, כחלק מההכנה לתהליך הרכש. לדוגמא, ממליצים על השיטה הפ ר ה- מכרזית (נעשה כינוס מקדים של הספקים, המעריכים את העלות וההיקף) שנמצאה יעילה ותחרותית. הגברת התחרות וסיוע לספק- על משרד המסחר לקדם פרקטיקות שיסייעו להבטיח כי הספקים יוכלו להתחרות על הפרויקטים. פרקטיקות טובות יכללו (היכן שמתאים)- תוכנית עבודה צפויה, אינדיקציות מקדימות לגבי הרכש, כנס ספקים, שימוש ברשת האלקטרונית, קריטריונים להערכה, דרישות והנחות בהירות 53 מתוך: דו"ח שהוגש למשרד למדע וטכנולוגיה הבריטי,

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

62 סקירה משווה- שלב הרכש בחלק זה, תתבצע סקירה מתומצתת של מבנה הרכש והעקרונות המנחים אותו במספר מדינות. סקירה זאת נועדה להעניק מבט כללי על המדיניות, ופרטים לגבי שיטות הרכש יפורטו בשלב מאוחר יותר של דוח זה. בין המדינות הנסקרות, בחרנו שלא לסקר כאן את בריטניה שכן מדיניות הרכש שלה הובאה בהרחבה מוקדם יותר במהלך פרק זה. על לקחים שנלמדו מממשלות בעולם יש לתת עדיפות למניעים וצרכים ארגוניים להבטיח שהרכישות מונעות מהצרכים הללו. חיזוק והבהרה של תפקידי הניהול (כולל הניהול הבכיר). שילוב האינטרסים של הרכש, של המומחים והמשתמשים וכן האינטרסים הארגוניים, מנת להגביר את היעילות ולהבטיח כי הצרכים והאינטרסים השונים מקבלים מענה. שימוש, פיתוח וקידום הפרקטיקות הטובות ביותר, בסטנדרטים הטובים ביותר. למידה מטעויות ושיפור מתמיד. ראיית דברים גם מזווית הראיה של הספקים. שימוש במסגרות-עבודה. שימוש ברכש- אלקטרוני. חשוב ביותר לזהות מה נדרש מכל תהליך רכש ספציפי. זיהוי ברור אינו פשוט עבור הממשלות, שכן בדרך כלל מטרותיהן הן רבות-פנים. יש לזהות עניין זה כחשוב ולקדם אותו. ארצות הברית מבנה: 54 הממשל האמריקאי הינו הלקוח הגדול בעולם ורכישותיו מסתכמות בכ- 530 מיליארד דולר בשנה. 55 הGSA, The US General Services Administration -הינו גוף המסייע למשרדי הממשלה, בכך שמציע שירותים מן המגזר הפרטי ל,IT נדל"ן ורכש למינהו. GSA מציע גם פתרונות של מומחים ומדיניות ניהול. ה-,Office of Acquisition Policy המשרד הממונה על מדיניות הרכש בתוך ה,GSA מסייע ליצירת מערכת-רכש אשר תומכת ומקדמת את המטרות העסקיות והאסטרטגיות של הממשלה ומכוון להפחית את העלויות לממשלה ע"י קניה של שירותים ומוצרים יותר בזול וביתר מהירות. ה ( FAI) Federal Acquisition Institute הינו גוף מוביל בתחום פיתוח הון האנוש עבור אתר המשרד לניהול ותקציבים (OMB) האמריקאי

63 מערכת הרכש, ומוביל בתחום זה את תכנון האסטרטגי, הדרכת-המדיניות, סדרי- העדיפויות ויישום התוכניות לפיתוח של הון אנוש איכותי בתחום הרכש. עקרונות הרכש: עקרונות מנחים לרפורמה- הרכש האמריקאי עבר תהליך של רפורמה מתמשכת, בין היתר לאורם של הרעיונות הבאים : עידוד המשרדים להשתמש ב"מוצרי מדף" היכן שניתן. הגדלת טווח השימוש בפרוצדורות רכש פשוטות ושימוש בסחר אלקטרוני להודעה וקבלת תגובות על מכרזים. יצירת אחידות במערכת הרכש. חיזוק המיקוד במסירה. חיזוק נהלי ההתמודדות עם מחאה וטענות של משתתפים במכרז, המנוהלים דרך מערכת פורמאלית של תחקור משתתפים שלא-הצליחו. פתיחות להסתכל אצל אחרים למציאת רעיונות טובים. מערכת סחר אלקטרוני- מערכת ממשלתית אחידה, שתספק: הודעות על מכרזים ממשלתיים ופרטים לגביהם. אפשרות להירשם אלקטרונית למכרזים ולהגיש הצעות. מתן תשובות לשאלות לגבי המכרזים. תגדיל את איכות המידע לגבי תהליכי הרכש. שיטת הרכש בחר בשיטת הGSA - ה- Contracting (PBC) Performance-Based חוזה מבוסס- ביצוע, כשיטת הרכש המועדפת עליו ומחייב את כל המשרדים להשתמש בשיטה זו עד כמה שניתן. על פי שיטת ה,PBC יש לבנות את כל האספקטים של הרכש סביב מה שצריך להתבצע ולא סביב הדרך בה יש לבצע. כך, החוזה יתמקד בתוצאות והפתרונות הרצויים. קיים באתר ה GSA מדריך לשימוש בשיטה. עיקרון הסטנדרטיזציה- אחד העקרונות העומדים בבסיס תפיסת הרכש של האמריקאים, הוא עיקרון 56 הסטנדרטיזציה. האמריקאים מבקשים לעודד את השימוש בסטנדרטים התנדבותיים (לא מחויבים עפ"י חוק) אשר פותחו במוסדות ייעודיים לכך, שכן הם רואים בהם אמצעי להוצאה לפועל של המדיניות של המשרדים. על מנת לאכוף גישה זו, מכון התקנים האמריקאי, דורש מדי שנה דו"ח מפורט בו מדווח על היקף הטמעת התקנים-ההתנדבותיים בכל משרד. ה- Office of Management (OMB) and Budget - קבע, כי כל משרדי הממשלה חייבים להשתמש בסטנדרטים ההתנדבותיים- המוסכמים המגיעים מן המגזר הפרטי, במקום באלו הייחודיים לממשלה, להוציא מקרים בהם הדבר אינו עולה בקנה אחד עם החוק או שאיננו מעשי. מטרת הממשלה בצעדים אלה: 1. להפחית בהוצאותיה על יצירת תקנים משלה. Guijarro, L. (2009) ICT standardization and public procurement in the United States and in the European Union: Influence on e-government deployment, Telecommunications Policy. 33:

64 להקל מעול הציות לתקנות הממשלתיות- דבר שיתבטא בעלויות. 2. להמריץ ולאפשר תקנים אשר ישרתו את הצרכים הלאומיים. 3. לקדם יעילות ותחרות כלכלית דרך יצירת הרמוניה בתקנים. 4. לקדם את המדיניות לפיה יש להסתמך על המגזר הפרטי שיספק את שרותי הממשלה. 5. בעיקרון זה מתגלמת גם קריאת הממשל למשרדים, לעמוד באותם אמות-המידה הביצועיות של המגזר הפרטי. ישנה הכרה ברורה, כי איכות שלב הרכש, תלויה באופן קריטי במידת המקצועיות של צוות מיומן- FAI מוביל תוכניות לפיתוח צוות הרכש. לפיכך, יש לעודד הכשרות ופיתוח מקצועי מתמשך. ה- קריירת ניהול-רכש וכמו כן, מסייע למשרדים בזיהוי וגיוס מועמדים איכותיים למשרות בתחום הרכש. אמצעים לקיצור זמן תהליך הרכש שאומצו על ידי משרדי הממשל האמריקאי: הנהגה בכירה נוכחת ותומכת. מחויבות מוקדמת ואפקטיבית של בעלי-העניין. צוותים משולבים, מכל תחומי הרכש כולל: רכישה, הערכה, מו"מ, ניהול החוזים. וידוא שכל ספק מבין את הדרישות לאשורן. שימוש במידע על ביצועי-העבר של הספק. שימוש בתהליכים ומסמכים סטנדרטיים. ביצוע בו זמנית מו"מ והכנה ובדיקה של מסמכי החוזה. שימוש בלקחי-הניהול לשיפור ניהול הפרויקט. התחום הטכני ותחום כתוצאה משינויים אלה ואחרים, הצליחו משרדי הממשלה לחסוך 100 ימים בהשוואה לרכש רגיל. : IT רכש בנוגע לרכש של שקיפות, האלקטרוני 57,IT מדגישים האמריקאים את הנקודות הבאות : 58 שיתוף ודיווח -.(E-Government) מסכם העוסק במצב הIT ה OMB מכין דו"ח שנתי לקונגרס בנושא היישום של הממשל- הדו"ח, בממשלה, מרכז דיווחים מן המשרדים השונים לכדי מסמך סוקר את מצבם של פרויקטים ונועד לעקוב ולמדוד באופן שיטתי האם השימוש שנעשה במשאבים מסייע להשגת המטרות והתוצאות הרצויות. על פי הוראת הנשיא הנוכחי, יש לקדם באופן חסר-תקדים, את הפתיחות, נגישות המידע, שיתוף הפעולה והיעילות של הממשל, דרך השימוש במערכות מידע הסעיפים מתוך: תקנון הרכש האמריקאי, : 2005 REGULATION,(FAR) FEDERAL ACQUISITION של ה-.General Services Administration אלא אם צוין אחרת. 58 את דו"ח 2009 ניתן למצוא ב:

65 59 אחידות המערכת - משרד הOMB - קובע כי כל ההחלטות הנוגעות להשקעה ורכש של IT צריכות להיות בתיאום עם הארכיטקטורה של הפרויקטים של אותו המשרד ושל הממשלה ככלל. זיהוי הדרישות- כולל התחשבות ב- הבטחת המשאבים, הגנת פרטיות, ביטחון לאומי, מוכנות לשעת חירום, אפקטיביות באנרגיה ונגישות לבעלי מוגבלויות. דינמיות התחום- בפיתוח האסטרטגיה, יש לקחת בחשבון את הטבע הדינאמי של תחום הIT, דרך ביצוע מחקר-שוק. ניהול סיכונים- ניתוח הסיכונים, הרווח והעלויות. נטילת סיכון היא מעשה ראוי, כל עוד הסיכונים נשלטים וממותנים. ראשי המשרד וכן האחראים על הפרויקט, אחראים במשותף לנושא ניהול הסיכונים. חיסיון- על המשרדים לדאוג כי החוזים של הIT, יכילו הגנה על הפרטיות. על המשרדים להבטיח כי החוזים יבטיחו בין היתר: כי הספק ועובדיו ימלאו אחר חוקי ההתנהלות של המשרד; רשימה של איומים וסכנות צפויים בפניהם הספק צריך להגן; תאור של אמצעי אבטחה שיספק הספק ותוכנית של פיקוח על נושא החיסיון ואבטחתו. החוזה המודולרי- שימוש בחוזה אחד או יותר לרכישה של מערכות מידע, באופן אינקרימנטלי, עקבי ובין-מערכתי. הרעיון של שימוש בחוזה מודולרי, הוא להפחית את סיכון הפרויקט, לתמרץ את הספק ולאפשר ללוחות הזמנים להתאים לטכנולוגיה המשתנה במהירות. משרדי הממשלה מחויבים להשתמש בשיטה של חוזה מודולרי- עד כמה שרק ניתן- ברכישה של מערכות גדולות. ניתן להשתמש גם ברכישה של מערכות שאינן כה גדולות. בעיקרון זה נעסוק ביתר הרחבה, בפרק "שיטות רכש". קנדה מבנה: 60 אחרי הממשל בארה"ב, הממשלה הקנדית היא הגוף המבצע הכי הרבה רכישות בעולם ורכישותיה עולות על 16 מיליארד דולר אמריקאי בשנה. גוף הרכש המרכזי- ה Public Works and Government (PWGSC),Services Canada רוכש ביותר מ מיליארד דולר אמריקאי בשנה. גוף זה מרכז את הרכש מ 140 מחלקות ממשלתיות וכן מנהל את החוזים של הפרויקטים הגדולים ביותר (מעל 100 מיליון דולר). 59 מתוך: מזכר,OMB יולי מתוך: אתר משרד המסחרהאמריקאי

66 עקרונות הרכש: בקנדה, מושם דגש גדול על הרכש האלקטרוני: רכש בקנה מידה קטן- מערכת ה- (SRI) 61 Supplier Registration Information -מערכת לרישום אלקטרוני של ספקים המבקשים להשתתף במכרזי הממשלה. באמצעות מערכת זו מחפשים משרדי הממשלה השונים ספקים פוטנציאלים, כאשר מדובר ברכש שאינו כפוף להסכמי מסחר. 62 רכש בקנה מידה גדול- מפורסם ברשימת המכרזים הממשלתיים באתר של,MERX. MERX הינה מערכת המנוהלת על ידי Bank of Montreal תחת חוזה ממשלתי והשימוש בה, לעיתים מחויב על פי התקנות של הסכמי המסחר. רוב הרכישות במערכת מתחילות בסכום של $25,000 ומעלה. המערכת מאפשרת צפייה במכרזים הקיימים, הזמנה של מסמכים להשתתפות במכרז ויצירת פרופיל 63 של החברה. 64 מאגר ספקי -IT מערכת ה- - Professional Services (PS) Online מאפשרת לספקי IT ו/או ספקים מקצועיים להירשם למאגר הספקים הממשלתי, תוך שהם מפרטים את השירותים אותם הם מספקים. כך, באפשרותם לשווק את שירותיהם לממשלה. משרד ממשלתי המחפש ספק יכול לבצע חיפוש לדרישותיו ולקבל רשימת ספקים מתאימה. השימוש ברשת האלקטרונית, אפשר למשרדי הממשלה הקנדיים לקבל יותר הצעות למכרזים וביתר- מהירות. כך, הם דיווחו, מכירי המכרזים יורדים. ככל הנראה מה שמסייע להורדת המחירים הוא האפשרות לראות בMERX אילו חברות הגישו גם הן הצעה וכן את המחירים ששולמו עבור חוזים קודמים. רכש :IT נקודות נוספות המודגשות בנושא ה 65 IT הקנדי : על המשרדים לבנות את שירותי הIT שלהם באופן שהוא מוכוון לקוח. יצירת מערכת שירותים אחידה- כרגע, בקנדה ישנם 120 מרכזי נתונים, יותר מ 7000 שרתים ולכל משרד יש את רשת-התקשורת שלו ושירותים לשולחן-העבודה משלו. כמו כן, משתמשים ב 14 מערכות כוח אדם שונות. המטרה היא לייעל את משאבי הIT, כך שיהיו פחות כפילויות והיא תהיה יותר אפקטיבית. הדבר יאפשר למשרדים לעסוק בתוכניות הליבה שלהם, במקום להתמקד בניהול תשתית ה- IT שלהם. על ידי יצירת שרותי IT משותפים, עשויה הממשלה לחסוך בין אחוז, אולם המשימה עשויה לארוך מספר שנים. משרד ה,PWGSC מפתח תוכניות לביצוע סטנדרטיזציה של התהליכים בIT מתוך: על פי אתר ה,PWGSC

67 הממשלה הקנדית שמה דגש ותוסיף לשים דגש על היחסים עם תעשיית הIT ועל חשיבות ההתייעצות עימה כאשר מוציאים חוזה למכרז. הממשלה רואה חשיבות רבה בהתייעצות עם אנשי התעשייה להם ניסיון רב. אוסטרליה 66 מבנה : משרד ה- Finance and Deregulation האוסטרלי, מפרסם את ה- Commonwealth Procurement (CPG) Guidelines שהוא מסמך מדיניות מסגרת-העבודה של הממשלה האוסטרלית, לפיה על המשרדים לפעול כאשר בתוכה הם רשאים לקבוע את פרקטיקות הרכש המתאימות להם. מחלקת ה (AGIMO) Australian Government Information Management Office תחת משרד זה, עוסקת בנושאי אסטרטגיית הIT. 67 עקרונות הרכש : מודגשת חובת המנהלים לעבוד לפי מדיניות הממשלה באשר למסגרת העבודה, שכן זו תוביל להשגת תוצאות רכישה יעילות, אפקטיביות ואתיות. הדבר מעוגן בתקנות ויש לאשר את התוכנית מול הגורמים הבכירים. גם על ספקים במיקור-חוץ יהיה לפעול בהתאם לתקנות הרלוונטיות עבורם ועל פי המדיניות הממשלתית הכללית, והדברים יופיעו גם בחוזה. תמורה לכסף - עיקרון זה, דורש ניתוח השוואתי של כל עיקרון הליבה של הרכש האוסטרלי הוא העלויות הרלוונטיות והרווחים, לכל הצעה, לאורך כל מעגל-החיים של הרכש. עיקרון זה נאכף באמצעות: עידוד תחרות, ע"י שימוש בתהליכי רכש-תחרותי ודגש על הימנעות מאפליה. - קידום השימוש במשאבים באופן יעיל, אפקטיבי ואתי. יש להבטיח כי נעשה שימוש - במדיניות והפרוצדורות הנדרשות בתהליכי הרכש. שקיפות ואחריות בקבלת ההחלטות. יש להבטיח כי תהליכי הרכש הינם פתוחים, - שקופים וכי ההחלטות מוצדקות- על ידי שימוש בפרוצדורות המתאימות לכך. הערכה של התמורה לכסף- עלויות אינן המשתנה המכריע בהערכת התמורה לכסף. אלא יש להתייחס גם למשתנים הבאים: התאמה למטרות; יחס לביצועי-העבר של כל ספק; הסיכון היחסי של כל הצעה; מידת היכולת להתגמש במקרה של שינוי; שיקולים פיננסיים; הערכת אפשרויות החוזה (למשל- האפשרות להארכת החוזה). מקיפים ורלוונטיים כך ברורים, על הדרישות לפרט תנאי השתתפות הגיוניים, הדרישות- שיתאפשרו זיהוי, הערכה והשוואה של עלויות ורווחים באופן הוגן ועל בסיס משותף, לאורך כל שלב הרכש. 66 על פי אתר משרד הDeregulation Finance and 67 על פי- מדריך הרכש האוסטרלי, 2007; מסמך ה-,FASTER PROCUREMENT בריטניה, מאי

68 מעבר לעיקרון הליבה, הממשלה ביקשה להסב את תשומת הלב לדגשים הבאים: הגברת השימוש ברכש-מקוון. הכשרת צוות הרכש של הפרויקט, כך שיהיו "קונים בעלי ידע". ייסוד ועדות שמטרתן לבדוק ולבקר את החוזים. שיתוף בין המשרדים על ידי מערכת מקוונת פנימית, לפרסום מדיניות ותהליכי רכש. כמו כן, יופיע עלון חדשות במערכת זו. המערכת תהיה מחוברת למערכת-הרכש האלקטרונית. רכש :ICT בשנת, העריך הממשל האוסטרלי את הוצאות הממשלה על ICT AGIMO 68 לשנה. -מחלקת ה ב- 5.3 מיליארד דולר, Australian Government Information Management Office (AGIMO) מתאמת ואחראית על השימוש בIT בממשלה, וכן חוקרת ומפתחת את נושא כוח האדם המקצועי לנושאי,AGIMO. IT מדווחת לשר האחראי. ביקורת- בשנת הוגש לממשלת אוסטרליה דו"ח בנושא רפורמה בתחום ה-.ICT מן הדו"ח עולה הביקורת הבאה: חוסר שליטה מספקת, על גופי הממשל המקומיים (המחוזות האוסטרליים) והעובדה כי לכל משרד/ממשל ישנה אוטונומיה בנוגע להשקעות בICT, גרמו לכפילויות רבות, government לחוסר אחידות בסטנדרטים, מדיניות מקוטעת ולא ברורה וחוסר התחשבות בארכיטקטורה של הממשלה האוסטרלית מכיוון שאין מחויבות שכזו. המשרדים/ממשלים, אינם מתמקדים ואינם יודעים כיצד להתמקד, בנושא השגת יעילות ואפקטיביות בICT וכן בהבנת היכולות הארגוניות לנהל ולממש את הרווחים מן הפרויקטים. אין ביקורת ואמצעי-מדידה לבדיקת היעילות והאפקטיביות של הפרויקטים. בעוד הם מצהירים כי תחום ה ICT חשוב עבורם ביותר, המשרדים/ממשלים אינם משקיעים בפיתוח אסטרטגי של כוח אדם מיומן. אין תוכנית ממשלתית למרכזי-נתונים. עתה כל פרויקט מתייחס לנושא בנפרד. שוק ה ICT הממשלתי אינו יעיל (אין מספיק התייעצות עם השוק, חסמי כניסה וכו'). 70 -e- מערכת הממשל האלקטרוני האוסטרלי, שמה דגש על היעדים : מענה על צרכי המשתמש. מתוך: דו"ח מטעם הממשל האוסטרלי, אוגוסט :2008 of Review of the australian government s use and communication technology Review/index.html 69 שם 70 מתוך: אתר הרכש של משרדהאוצרהאוסטרלי government-strategy/index.html

69 מתן מענה אחיד ועקבי לפונים לממשלה. תמורה לכסף (נזכר כאן למעלה). פיתוח מיומנויות בניהול הפרויקט והרכש. בכוונת הממשלה, להשיג את היעדים באמצעות יישום האסטרטגיות הבאות: שימוש בטכנולוגיה חדשנית (כגון- ניצול הטלפונים הסלולריים, כרטיסים חכמים) הגברת שיתוף הפעולה עם התעשייה. חיזוק המבנה הקיים של הניהול והפיקוח על ה IT בממשלה (באמצעות.(AGIMO פיתוח מדדים לבקרה ובחינה של התהליכים וההישגים מפרויקטים קודמים. 71 אתר לספקים- משרד ה-,Finance and Deregulation מפעיל אתר מקוון לרישום של ספקי טכנולוגיות מידע ותקשורת. הספקים מוזמנים להירשם למאגר הספקים של הממשלה, כאשר זו, אינה מתחייבת מצידה לעשות שימוש דווקא בספקים הרשומים. 72 מסגרת עבודה - ה- Commonwealth Government Information Technology and Communications (GITC) הינה מסגרת העבודה, המציעה קווים מנחים לחוזי רכש הICT באוסטרליה. המסגרת, נבנתה בשיתוף עם נציגי התעשייה האוסטרלית והיא מבוססת על התנאים הסטנדרטיים של רכש בתחום ה-.ICT מדובר במסגרת כללית, ועל כל גוף רכישה ממשלתי-מקומי באוסטרליה להתאים אותה לדרישות הממשל המקומי. המסגרת אינה מתאימה לרכש אסטרטגי כגון מיקור חוץ מתוך: האתר של הGITC

70 פרק 3 שיטות התקשרות הקדמה הפרק עוסק במספר תתי-נושאים של שיטות התקשרות. ראשית, ישנה התייחסות לבחירה במיקור חוץ, לפיתוח של מערכות מידע ממשלתיות. לאחר מכן, מובאת סקירה של סוגי החוזים האפשריים לשימוש ברכש של IT ומובאים מספר שיקולים לבחירה בסוג החוזה. כמו כן, מפורטים היתרונות נסקרים שלושה מודלים של לבסוף, והחסרונות של החוזים הנפוצים ברכש של מערכות מידע. תשלום- הPFI אשר איננו מומלץ, אבני הדרך והחוזה המודולרי. תקציר מנהלים מיקור חוץ כיום, בממשלות העולם רוב עובדי ה IT הינם עובדים פנימיים ורק כרבע מהם הינם עובדים חיצוניים תחת חוזה. בארה"ב מדיניות הרכש היא להעדיף מיקור חוץ באספקה של שירותים ומוצרים. אותה מדיניות חלה גם על תחום הIT, במידה ואין המערכת נוגעת בפונקציות האינהרנטיות לממשלה. קיים דגש על בחירה של הפעולות שיבוצעו במיקור חוץ. הפרק מונה סיבות בגינן מבצעים מיקור חוץ בIT ומדגיש את הסיבות הנוגעות במיוחד למגזר הממשלתי- הפחתת עלויות, נגישות לצוות מיומן, שירות טוב יותר ועוד. מאידך נמנו שלושה גורמים מהם יש לחשוש עם היציאה למיקור חוץ: שליטה על הפרויקט, חוסר הכרות עם הארגון וקושי לשנות את המצב. לבסוף, נמנות ארבע עלויות סמויות של מיקור חוץ בIT - עלויות שבדרך כלל יש נטייה שלא לקחת אותן בחשבון- חיפוש הספק וחתימת החוזה; עלויות העברה לספק, עלויות ניהול מיקור החוץ ועלויות ההעברה בסוף החוזה. חוזים החוזים המשמשים את מערכת הרכש האמריקאית, מחולקים לשלוש קבוצות עיקריות: חוזי פיקס פרייס, חוזי שיפוי-עלות וחוזי זמן וחומר. לרכש של פיתוח תוכנה, משתמש הממשל האמריקאי בעיקר בחוזי קוסט+ ופיקס פרייס. אמנם כיום ממשל אובמה מעודד מאוד את השימוש בחוזי פיקס פרייס, אך בתקנות הרכש מודגש כי על החוזה להיקבע בהתאם לפרויקט הספציפי שכן לכל חוזה יתרונות וחסרונות. מומלץ כי הלקוח יקבע את סוג החוזה- אך יאפשר לספקים להציע חלופות נוספות שעשויות להשתלם יותר. את המו"מ על החוזה יש לבצע ביחד עם המו"מ על המחיר וכאשר שוקלים באיזה חוזה לעשות שימוש, יש לקחת בחשבון מספר גורמים וביניהם: תחרות מחירים, ניתוח מחיר ועלויות, סוג הדרישות ומורכבותן, זמן הביצוע וכו'. הפרק מפרט את היתרונות והחסרונות, הן לספק והן ללקוח, של שלושת החוזים הנפוצים (פיקס פרייס, קוסט+, (T&M כאשר חוזה הפיקס פרייס הנוקשה הינו החוזה 70

71 המועדף לשימוש אך איננו תמיד אפשרי, וחוזה ה- T&M הינו החוזה הפחות מועדף והשימוש בו יעשה רק כאשר לא נמצא חוזה מתאים אחר. מתוך סקירה של ספרות מחקרית, עולה כי ככל שחוסר הודאות לגבי הדרישות והעלויות בפועל גדול יותר, כך גדלה הנטייה להתרחק מחוזה הפיקס פרייס לעבר חוזה של קוסט+. מדד נוסף המשפיע על בחירת סוג החוזה הוא היכולת למדוד את איכות הפרויקט לאחר הביצוע: ככל שיכולת מדידת האיכות נמוכה יותר, ישנה התרחקות מפיקס פרייס לעבר קוסט+.. מודלים של תשלום,Private Finance Initiative -PFI הינו מודל לשותפות של המגזר הציבורי והפרטי. בזיכיונות אלה, השותף מהמגזר הפרטי לוקח אחריות על אספקת שירותים ציבוריים, כולל בניה ותחזוקה של התשתית הנדרשת (בדומה למודל.(B.O.T שיטה זו נעשתה נפוצה מאוד בבריטניה והיא מומלצת באופן כללי על ידי הממשלה- אך לא עבור פרויקטים של.IT עבור פרויקטים של IT ישנה הנחה נגד השימוש ב.PFI מחקר שנערך מטעם משרד האוצר הבריטי, מצא כי ברוב רכש הIT שהוגדר כמוצלח נעשה מו"מ מחודש על החוזים אשר הביא להתרחקות ממודל ה PFI ולאימוץ גישה שונה. ישנם מספר גורמים ייחודיים לIT אשר יוצרים קושי זה וביניהם: קושי להגדיר את הדרישות, קושי לחלק סיכונים, העדר מימון מצד שלישי ועוד. לפיכך, ממליץ משרד האוצר הבריטי לבחור במודלים של רכישה המשקפים טוב יותר את צרכיהם של פרויקטי.IT ההמלצה היא לחפש חוזים יותר מודולריים ושלביים. המדיניות הבריטית כיום, היא לפרק את הפרויקטים הגדולים לצעדים קטנים יותר, אותם קל יותר לנהל ואיתם קל יותר להתגמש בהתאם לדרישות המשתנות. אבני דרך- שימוש באבני דרך מומלץ על ידי הבריטים. בהשוואה לשיטת הPFI, שיטה זו יותר מאוזנת מבחינת התשלום כך שעלויות המימון לספק מופחתות והדבר יתבטא גם במחיר החוזה. בשיטה זו, לאחר הבנת הדרישות יש לפרק אותן לאבני דרך אשר מתארות מה על הצוות להשיג, על מנת להעביר את הפרויקט ממצב אחד למשנהו. אבני הדרך יוצרות יעדים, פורשות את התשלום ומשמשות לביקורת על התקדמות הפרויקט. האחראי על בניית אבני הדרך הוא הספק והממשלה בוחרת את מידת המעורבות שלה בתהליך. חשוב ביותר לקבוע קריטריונים ברורים ומוגדרים לבדיקת אבן הדרך וכן פרוצדורות בדיקה. המסמך מפרט את הסדרי התשלום בשיטת אבני הדרך, עליהם חשוב להקפיד. בין היתר יודגש, כי התשלום אינו קשור לעלויות אלא לאבן הדרך וכי הוא יינתן רק לאחר שהממשלה קיבלה דבר מה בעל ערך ארגוני (בעל תועלת גם אם החוזה יסתיים עתה). חוזים מודולרים- בהגדרות האמריקאיות לרכש מערכות מידע, נקבע כי יש להשתמש בחוזים מודולרים- שימוש בחוזה אחד או יותר לרכישה של מערכות מידע, באופן אינקרימנטלי, עקבי ובין- מערכתי. הרעיון של שימוש בחוזה מודולרי, הוא להפחית את סיכון הפרויקט, לתמרץ את הספק ולאפשר ללוחות הזמנים להתאים לטכנולוגיה המשתנה במהירות. החלוקה למספר רכישות קטנות מקלה על הניהול, מאפשרת מסירה שאינו תלויה בשלב הבא, מפחיתה את הסיכון לתוצאות שליליות של הפרויקט ועוד. אופי השלבים עשוי להשתנות בהתאם לסוג ואופי המערכת. 71

72 1 מיקור חוץ מיקור חוץ (Outsourcing) הוא יחס חוזי בין ספק שירות חיצוני לבין לקוח, בו הספק נוטל על עצמו אחריות כוללת לביצוע שירותי תכנון, פיתוח, יישום, תפעול ותחזוקה של רכיב אחד או יותר ממערכת או תהליך של הלקוח. לאחרונה, ארגונים רבים ובהם משרדי ממשלה, מפעילים יותר ויותר תהליכים, 2 שאינם תהליכי ליבה, בשיטת מיקור חוץ. אחוז העובדים תחת חוזה, לעומת אחוז העובדים השייכים לחברה- בתחום הIT 3 בממשלות ברחבי העולם- 73% מעובדי הIT הינם עובדים פנימיים. 27% מעובדי הIT, הם עובדים חיצוניים תחת חוזה. 1 דוח זה אינו מתיימר לדון בכל שאלת מיקור החוץ בממשלה, שהינה שאלה נכבדת שראויה למחקר נפרד בעניינה. הדיון כאן הינו ברמת הסקירה התיאורטית בהיבטי פרויקטים לפיתוח תוכנה בממשלה. 2 מתוך: אתר תפנית, בית ספר למנהלים ופיננסים לימודי המשך של האוניברסיטה הפתוחה: 3 סקר של גארטנר, סיכום הנתונים של שנת מתוך: Smith, M. & Potter, K. (2009). IT Spending and Staffing Report. Gartner website: 72

73 4 ההחלטה על מיקור חוץ בארה"ב, נקבעה מדיניות לפיה על משרדי הממשלה לבחון ראשית את אפשרות מיקור- החוץ כאשר ברצונה לרכוש שירות/מוצר או להרחיב שירות/מוצר קיימים מעל 30%. מדיניות זאת, קיימת משנת 1967 ולפיה יש להעדיף גורמים מסחריים באספקה של שירותים ומוצרים (כחלק מהתפיסה לפיה הממשלה אינה צריכה להתחרות באזרחיה). הרעיון העומד בבסיס ההחלטה לעבוד במיקור-חוץ, הוא שעל הארגון להתרכז בנושאי הליבה שלו ולכן אפשרות מיקור-החוץ תבחן ביתר שאת כאשר מדובר במערכות מידע: נושא הIT בממשלה, משרת את מטרותיה אך אינו הדבר בו היא עוסקת. יש לזכור, כי מיקור החוץ אינו מטרה בפני עצמה, אלא הוא כלי ניהולי. על משרדי הממשלה, בממשל האמריקאי, לבחון האם הפונקציות של מערכת הIT המתוכננת, הינן כאלה האינהרנטיות לממשלה, הווה אומר- פעולות הנוגעות במידע רגיש במיוחד ומצריכות שיפוטיות וסודיות כאשר מטפלים בהן. יש להפעיל שיקול דעת בהחלטה אילו מערכות שייכות לסוג זה. מערכות אלה, מוטב שיבוצעו בידי עובדי הממשלה. סיבות בגינן מבצעים מיקור חוץ, במערכות מידע סיבות המשותפות למגזר העסקי והממשלתי- מיקוד משאבי הארגון בפעולות הליבה מעבר למדידה שירותית SLA חיסכון בעלויות כוח אדם איכות משופרת של שירותי הIT גמישות גדולה יותר גישה טובה יותר לטכנולוגיות חדשות מתן אלטרנטיבה לעלויות של עובדי הארגון ייצוב עלויות מערכות המידע חיסכון בעלויות הטכנולוגיה הפחתת סיכון התיישנות הטכנולוגיה סיבות המאפיינות במיוחד את המגזר הממשלתי- מציאות תקציבית/ הפחתת עלויות- הערכות החיסכון נעות בין 40%-10% חיסכון בעלויות. למגבלות התקציב השפעה מרכזית על ההחלטה אילו פעולות להוציא למיקור חוץ. נגישות לצוות מיומן- בממשלה קיים מחסור בצוות מיומן היטב בין היתר מכיוון שאין באפשרותה לשלם משכורות גבוהות כמו בחברות העסקיות. כמו כן, לעובדים הקבועים קשה להדביק את הקצב המהיר של התקדמות הטכנולוגיה (אין הכשרות) מתוך: מסמך של משרד מערכות המידע האמריקאי, TECHNOLOGY, 1998 :OUTSOURCING INFORMATION

74 תגובתיות טובה יותר בנושא ה /IT שירות טוב יותר ללקוחות ולארגון- חברות הIT מתמחות בתחומן ולכן עשויות לספק שירות טוב יותר. בשל התמחותן, הן גם רוכשות ומפתחות ידע ומיומנויות בתחום ניהול הפרויקטים אשר לממשלה קשה יותר לפתח ולרכוש. סיוע עם המערכות הקיימות- פעמים רבות ישנו צורך לפתח פונקציות הקשורות למערכות קיימות. מערכות אלה, פעמים רבות, כתובות בשפות תכנות ישנות ואינן מתועדות היטב. למגזר הפרטי קל יותר להשיג אנשים בעלי המיומנות הנדרשת לטיפול במערכות אלה. הטמעה של ארכיטקטורה חדשה- מיקור חוץ הוא גם דרך להתמודד עם השינויים בטכנולוגיה. לארגוני הספקים יותר יכולת לרכוש ולתחזק משאבים טכנולוגיים חדשים ועלות זו נמוכה יותר מאשר לו הייתה עושה זאת הממשלה. גם את ההטמעה של הטכנולוגיה החדשה יודעים הספקים לעשות טוב יותר ומהר יותר עקב היותם בנויים לרענון מתמיד של הטכנולוגיות. הספקים גם יכולים לפזר את עלויות הטכנולוגיה החדשה בין מספר לקוחות, כך שלקוח אחד לא יישא בכל הנטל. חששות מן ההחלטה לבצע מיקור-החוץ שליטה- יש הטוענים כי ספק חיצוני לא יעמוד ברמת השירות הנדרשת מכיוון שאינו נתון לאותה השליטה הניהולית לה נתון עובד-ממשלה. ניתן להשיב לטענה זו, על ידי בניית יעדי ביצוע אותם יציבו המנהלים וכך ניתן יהיה למדוד ולשלוט בביצועי הספק. הכרות עם הארגון- יש החוששים כי ספק חיצוני יתפקד טוב פחות מעובדים פנימיים, שכן אין הוא מצוי באופן ההתנהלות של המשרד, מנהגיו ודרישות-הדיווח שלו. לפיכך, מומלץ לבחור ספקים אשר עבדו בעבר עם לקוחות הקשורים לסביבת המשרד. בנוסף, הקפדה על תקשורת טובה ושיתוף פעולה בין הספק והמשרד, יסייעו לספקים לדעת את הדרוש, בתחומים הקריטיים. אי יכולת לשנות את המצב- קיים חשש כי לאחר שהוצאו מערכות הIT לספק, יהיה זה יקר מדי לשנות את המצב ולהחזיר את הפיתוח לארגון או- לצאת בחוזה חדש מול ספק אחר. לחששות כגון אלה, ניתן להתייחס בחוזה למשל, לעגן את הדרישה "להעביר את הידע" חזרה לממשלה. במידה והפונקציות קריטיות במיוחד לתפקוד המשרד, ניתן לשקול את פיצול הפונקציות למספר חוזים קטנים לספקים שונים. 5 העלויות הסמויות של מיקור חוץ בIT ישנן עלויות שאינן נלקחות בחשבון במיקור חוץ של מערכות מידע, אם עקב חוסר מודעות לקיומן, ואם עקב חוסר מודעות לכך שהן משמעותיות. 1. עלויות חיפוש הספק וחתימת חוזה- תהליך זה עולה כסף. בסקר שנערך, נמצא כי עלות ההליך מגיעה ל 3% מהעלות הממוצעת של פרויקט.IT אולם, מומלץ מאוד להשקיע בתהליך זה שכן לרוב עלויות אלה משתלמות כשנמצא הספק המתאים: 5 Barthelemy, J. (2001). The hidden costs of IT outsourcing, MIT Sloan Management Review, 42(3),

75 בחירת ספק: אמינות הספק חשובה, וספק שתדמיתו חשובה לו- ינסה לגשר על פערים באופן הוגן וינהג בפחות אופורטוניסטיות. על מנת לבחור ספק טוב, ניתן לתת מספר חוזים קטנים ומעטי-סיכון, למספר ספקים במשך מספר מועט של שנים, ולבסוף לבחור (למשל: 4 ספקים) את הספקים המרכזיים, האמינים ביותר והנוחים ביותר לשיתוף פעולה, אשר איתם יבוצעו הפרויקטים הגדולים. כמו כן, ניתן לראיין את הלקוחות הקודמים של הספק לקבלת מידע נוסף. דרישות: מוטב לדעת כמה שיותר מה הן הדרישות ולהגדירן לספק כך יווצרו פחות פערים בחוזה. מאידך, לא ניתן לצפות תמיד את הדרישות כולן. יש לעגן נושאים אלה בחוזה, לדוגמא, ניתן להכניס סעיף הדורש מהספק להוציא סכום מסוים בכל שנה על שיפור הטכנולוגיה. על החוזה להיות ברור, מובן ומוגדר היטב ומוטב כי יהיו בו סעיפים כגון: סעיפי התפתחות: סעיפים החלים על הטכנולוגיה והמחיר של הפעילות. סעיפי חזרה: המאפשרים לארגון לקנות בחזרה את הרכוש שלו (כמו משרדים) או לגייס בחזרה את כוח האדם שהועבר לספק. 2. עלויות ההעברה לספק- עלויות אשר נוצרות כתוצאה מן הצורך של הספק לרכוש את הידע שעובדי-הIT בארגון כבר יודעים. לוקח זמן עד אשר הספק מגיע לרמת הידע הדרושה לו על מנת לממש את הפרויקט- זמן ההעברה הממוצע, הינו שנה. בעלויות ההעברה, ניתן להכליל- את זמן העבודה של עובדי הפנים אותו הם מקדישים לסיוע לספק; עלויות הנובעות משיבושים שונים וחוסר תגובה מהיר מספיק של הספק (לעומת עובדי הפנים המגיבים מהר יותר). ככל שהפעולה המיוצאת למיקור חוץ, ייחודית ומורכבת יותר, כך יהיו עלויות ההעברה גבוהות יותר. הפחתת העלויות- ראשית יש להיות מודעים לקיומן של עלויות ההעברה. יש להמריץ את העובדים (הן הפנימיים והן העובדים במיקור החוץ) לסייע בהעברה של הידע. מומלץ לקבוע זמן בו עובדי הספק מחויבים ללמוד ולא לעבור הלאה. כמו כן, דרישות ברורות מצד הלקוח יאפשרו העברה קלה יותר. כמובן, ספק המנוסה בתהליכים כאלה, יבצע את ההעברה ביתר בקלות. 3. עלויות ניהול מיקור החוץ- מוערכות בכ- 8% מהעלות השנתית של החוזה (ככל שהחוזה גדול יותר, אחוז העלות השנתית של הניהול- נמוך יותר). מורכבות מ: מעקב כי הספק ממלא אחר התחייבויותיו בחוזה מיקוח עם הספק- והחלת סנקציות במקרה הצורך מו"מ על שינויים בחוזה הפחתת העלות של ניהול הספקים- עלות הניהול הינה בדרך כלל סמויה. ראשית, יש לשים לב לקיומה. ניסיון בניהול של ספקים, מפחית את עלויות הניהול שלהם- שכן קל יותר לחברה להעריך את ביצועיהם (מנוסים בקביעת מדדים ומעקב אחריהם). גורם נוסף המשפיע על העלויות הוא- אמון במערכת היחסים של ספק-לקוח. אמון הדדי, יוצר מצב בו הספק משתדל לתת מענה הוגן, במקרה של פערים בחוזה. קידום של האמון, יכול להיעשות ע"י: וידוא כי מטרות שני הצדדים מובנות; עידוד תקשורת טובה- דיון בבעיות ברגע שהן עולות ושיתוף 75

76 פעולה בפיתרון שלהן; פגישות פנים-אל פנים לעיתים קרובות ויצירת קשר אישי. אם יתמידו ויתעקשו על כך- חברות יכולות ליצור אמון, גם כאשר מערכת היחסים היא בעייתית. 4. עלויות העברה בסוף חוזה- העלויות הכרוכות בהחלפת ספקים או באינטגרציה של פעילות הIT בחזרה לארגון. פעילויות אלה, של החלפת ספקים או החזרת פעילות הIT לארגון, אינן מתוכננות מראש בדרך כלל. כאשר מחליפים ספק- קיימות שוב עלויות מציאת ספק חדש, חתימה על חוזה והעברת המשאבים. כאשר מחזירים את הIT לארגון, קיימות העלויות של התחלת המחלקה מחדש. הפחתת עלויות ההעברה של סוף חוזה- חשוב מאוד להיות מודעים לעלויות של סיום מיקור-חוץ. מוטב להכניס סעיפים בחוזה המתמודדים עם אפשרות כזו. למשל, לאפשר את החזרת העובדים, הציוד והתוכנות שעברו לספק. אמצעי נוסף להפחתת עלויות הוא השארת צוות של מומחי IT בתוך חברת-הלקוח. כך, נותר צוות מומחה אשר יכול לנהל את הספק וכן להתמודד עם מקרים של החלפת ספק או שינוי בהיקף מיקור-החוץ. צוות כזה, יצמצם את עלויות סגירת הפרויקט. בחירה נכונה של פעולות שיבוצעו במיקור חוץ, מציאת ספק טוב, מנהלים וצוות מנוסים (או- יועצים שיסייעו), חוזה ברור, יחסי אמון עם הספק ושמירת מספר אנשי IT בארגון- יביאו להפחתת העלויות הסמויות של מיקור חוץ בIT. 76

77 חוזים 6 סוגי חוזים כאן נביא סיכום של מספר שיטות בהם משתמשים להתקשרות בחוזי.IT יתרונות וחסרונות של השיטות יידונו בהמשך. סולם האפשרויות נע בין שני הקצוות הללו: פיקס פרייס נוקשה <->(Firm-fixed-price) קוסט + תגמול קבוע.(Cost-plus-fixed-fee) כאשר, "פיקס פרייס נוקשה", מספק את התמריצים המקסימאליים לספק לשלוט בעלויות ולהתנהל אפקטיבית ומטיל את רוב הסיכון על הספק. "קוסט+ תגמול קבוע", מטיל על הספק אחריות מינימאלית לעלויות הביצוע ורוב האחריות היא על הממשלה. חוזים של פיקס פרייס Price) (Fixed חוזה המציב מחיר קבוע או כשמתאים- מחיר משתנה בתנאים מסוימים (בהמשך). חוזה מסוג זה, ייבנה על בסיס הדרישות, כאשר ניתן לקבוע מן ההתחלה מחיר סביר. חוזה זה מתאים רק כאשר הדרישות ברורות והסיכון בפרויקט הוא מינימאלי או ניתן לצפייה באופן ודאי למדיי. סוגי חוזה זה: פיקס פרייס נוקשה ( Firm-fixed-price )-המחיר אינו נתון לשינוי. לספק אחריות מלאה על עלויות הביצוע ולפיכך הסיכון כולו עליו וכן האחריות לרווח או ההפסד. חוזה מסוג זה, מספק את התמריצים המקסימאליים לספק לשלוט בעלויות ולבצע דברים באפקטיביות, כך שמטיל עול אדמיניסטרציה מינימאלי על הצדדים. ניתן להוסיף לחוזה זה, תמריצים נוספים. פיקס פרייס עם תמריץ incentive) -(Fixed price חוזה המאפשר לשנות את מחיר החוזה והרווח. הסכום המשתנה, נקבע בחוזה, ע"י נוסחא המתבססת על היחסים שבין עלות המטרה, רווח המטרה ועלות-התקרה (ומשתנים נוספים במקרה הצורך). לשימוש כאשר נראה כי לתמריצים תהיה השפעה על התנהלות העבודה של הספק. פיקס פרייס עם התאמת מחירים כלכלית adjustment) (Fixed-price with economic price משמש להגן על הממשלה והספק מפני תנודות כלכליות חזקות בעלויות העבודה או החומרים בזמן ביצוע הפרויקט. זאת, כל ידי כך מאפשר לשנות את הסכום שנקבע בחוזה כאשר מתרחשים מצבים ספציפיים. בחוזה מסוג זה יעשה שימוש כאשר ישנו ספק רציני לגבי יציבות השוק או תנאי העבודה שישררו בזמן של ביצוע החוזה וכאשר ניתן לזהות את הגורמים העשויים להשתנות. חוזה מסוג זה יהיה תלוי בהתפתחויות הכלליות בתעשייה. General Services 6 תקנון הרכש האמריקאי, 2005 :,(FAR) FEDERAL ACQUISITION REGULATION של ה-.Administration 77

78 פיקס פרייס עם קביעה עתידית/ רטרואקטיבית (Fixed-price with prospective/retroactive price -(redetermination קביעה עתידית- חוזה הקובע מחיר קבוע לתקופה הראשונה (שתהיה ארוכה עד כמה שניתן) ולאחר שזו תסתיים, יערך מו"מ מחדש. שימוש בחוזה זה, יעשה כאשר ניתן לקבוע מחיר סביר לתקופה מסוימת, אך לא לתקופה שאחריה. קביעה למפרע (רטרואקטיבית)- נקבע מחיר תקרה, ולאחר סיום החוזה, נקבע המחיר הסופי רטרואקטיבית ובמסגרת מחיר-התקרה. שימוש בחוזה מסוג זה יעשה בחוזי מחקר ופיתוח המוערכים ב-עד $100,000, כאשר לא ניתן לקבוע מחיר סביר מן ההתחלה. חוזים של שיפוי עלות Contracts) (Cost-Reimbursement חוזים הקובעים תשלום לספק על הוצאותיו בפועל בגין הפרויקט. התשלום הסופי יקבע בסוף החוזה, או בנקודות זמן עליהן הוחלט. על מנת להכין את התקציב (ממשלה) מעריכים את העלות וקובעים מחיר תקרה אותו לא ניתן לעבור ללא אישורים מיוחדים. חוזה מסוג זה, מתאים כאשר קשה לחזות באופן מדויק מספיק את עלות הפרויקט (מלכתחילה- יש להעדיף חוזה של פיקס פרייס). סוגי חוזה זה: חוזה עלות contract) -(Cost חוזה "שיפוי עלות", ללא תגמול נוסף (תגמול להלן- התשלום מעבר לשיפוי העלויות). מתאים לעבודות מחקר ועבודה של ארגונים ללא כוונת רווח. חוזה שיתוף-עלויות Sharing) (Cost חוזה "שיפוי עלות" בו הספק מסכים לקחת חלק בעלויות הפרויקט, כך שהממשלה תשלם רק חלק מעלות החוזה. כמו כן, לא יינתן תגמול נוסף לספק. חוזה זה, כדאי לספק רק במקרה שהוא מרוויח אחרת מן העבודה באופן המפצה אותו על הוצאותיו (למשל- מרוויח פיתוח מסוים). חוזה קוסט+ תגמול קבוע (Cost-Plus-Fixed-Fee) לרוב, כשמדובר על חוזה מסוג קוסט+ מדובר על חוזה מסוג זה. הספק מקבל תשלום על ההוצאות ובנוסף תגמול שנקבע מראש. התגמול מסוכם בשלב המו"מ על החוזה ולא ישתנה בהתאם לעלויות הפרויקט בפועל. אולם, התגמול עשוי להשתנות אם העבודה הנדרשת להשלמת הפרויקט תשתנה. חוזה מסוג זה, מתאים כאשר קיימת אי ודאות אשר מונעת שימוש בחוזה מסוג פיקס פרייס וכן, הסיכון עבור הספק עלול לעלות על ההטבות הלא- כלכליות של הספק מן הפרויקט. בחוזה מסוג זה, לספק אחריות מינימאלית על עלויות הביצוע. ישנם שני סוגים של חוזים מסוג זה: השלמה - רק לאחר השלמת מוצר/ מטרה שנקבעה, יתקבל התגמול. אם העלויות עולות על המצופה, הממשלה תוסיף לשלם לספק עבור העלויות, אך לא תגדיל את התגמול. תנאים- היקף העבודה לא נקבע באופן מדויק, אך החוזה קובע תקופת זמן ורמת-מאמץ המצופים מן הספק. כאשר תקופת הזמן תמה, אם הממשלה מאשרת את הביצוע, היא משלמת את התגמול. עבודה נוספת, תדרוש הסכם חדש. 78

79 בכל פרויקט בו ניתן להגדיר את היקף העבודה טוב מספיק, יש להעדיף את חוזה ה"השלמה". חוזה קוסט+ תגמול ממריץ -(Cost-Plus-Incentive-Fee) הספק מקבל תשלום ובנוסף תגמול נתון- לשינויים. החוזה הראשוני, קובע מטרות לעלויות ותגמול, כולל תגמול מינימאלי ומקסימאלי ונוסחא לשינוי התגמול. לאחר השלמת החוזה, ישולם לספק על בסיס הנוסחא שנקבעה. בפועל, התגמול יגדל אם החוזה הושלם בפחות מן העלות שנקבעה, או יקטן אם יושלם ביותר מן העלות. חוזה מסוג זה, מעודד את הספק לחסוך ולהרוויח באמצעות הפחתת עלויות ושיפור של ביצועים. חוזה קוסט+ מענק תגמול -(Cost-Plus-Award-Fee) הספק מקבל תשלום, תגמול קבוע (שעשוי להיות נמוך מאוד) ובנוסף אפשרות לקבלת תגמול נוסף. הממשלה תחליט על סכום המענק על פי הערכתה את ביצועי הספק בהתבסס על גורמים כגון ניהול העלויות, תבונה-טכנית, לו"ז ואיכות העבודה. המטרה של חוזה זה, היא לתמרץ את הספקים להוכיח מצוינות בגורמים אלה. חוזי זמן וחומר (T&M)) (Time-and-Material מתבססים על עלות החומרים וכן שעות העבודה, המתומחרות במחיר קבוע (הכולל גם את הרווח). בחוזים מסוג זה יעשה שימוש רק כאשר אין אפשרות לחזות את היקף או משך העבודה, או לחזות את העלויות באופן סביר. השימוש ב T&M יעשה רק כאשר נבדק ונקבע כי אין אף חוזה אחר מתאים ולאחר שנקבע מחיר תקרה אשר חריגה ממנו היא באחריות הספק. חוזים מסוג אלה אינם מספקים תמריצים לספק לשלוט בעלויות, ולכן חשוב ביותר לבצע מעקב אחר הספק להבטיח ביצוע אפקטיבי. חוזה שעות עבודה Hour) -(Labor חוזה מסוג T&M אשר בו הספק אינו מספק את החומרים. חוזה מפורש ) contract -(Letter מסמך חוזי מקדים, המאפשר לספק להתחיל את עבודתו באופן מיידי. שימוש בחוזה מסוג זה נעשה כאשר אין זמן לבצע מו"מ על חוזה סופי ולממשלה חשוב לתת לספק התחייבות כך שהעבודה תוכל להתחיל מיד. הממשל האמריקאי משתמש בעיקר בחוזים הבאים, חוזי שיפוי עלויות ) Reimbursement (Cost קוסט + תגמול קבוע Fee) (Cost Plus Fixed קוסט + מענק תגמול Fee) (Cost Plus Award קוסט + תגמול ממריץ (Cost-Plus-Incentive-Fee) חוזי פיקס פרייס ) Price (Fixed פיקס פרייס נוקשה Price) ( Firm Fixed פיקס פרייס עם תמריץ Incentive) (Fixed Price 7 לרכש של פיתוח תוכנה : מתוך אתר מנהל השירותים הכללים האמריקאי

80 8 קביעת סוג החוזה ארגונים רבים מסתמכים על החוזה המוכר להם ואינם פונים לבחון איזה חוזה הוא הכדאי ביותר. בדיקה כזו חשובה שכן לכל חוזה היתרונות והחסרונות שלו. נושא התמחור הינו בין הגורמים המובילים לבעיות במערכת היחסים בין הארגון ומערכת הIT וכן בין הלקוחות והספקים. חשוב כי ההמלצה לסוג החוזה תקבע עוד לפני ה,RFP שכן מודל התמחור הוא חלק אינטגראלי מחישוב העלויות. גם לאחר הRFP מומלץ לשוב ולוודא כי נעשתה הבחירה הנכונה לגבי סוג החוזה. הלקוח קובע- לטענת חברת הייעוץ והמחקר "גרטנר", על הארגון ולא על הספק- לבחור את מודל התמחור (למרות שישנם ארגונים המאפשרים חופש בחירה לספק) מהטעמים הבאים: במידה והספקים מציעים מודלים שונים בהצעותיהם, ייווצר קושי עבור הארגון להשוות בין ההצעות. בדרך כלל יציע הספק מודל תשלום המטיל עליו מינימום של אחריות פיננסית. לעיתים קרובות, במודלים המוצעים ע"י הספקים אין התייחסות לאספקטים הנדרשים ע"י היחידות הארגוניות, כגון- גמישות לשינויים או שקיפות בעלויות. מאידך, על מנת להיות פתוחים לחדשנות, יצירתיות וליצור מערכת יחסים יותר גמישה עם הספקים, ניתן לאפשר להם ב RFP להציע בנוסף מודלים חלופיים לתמחור. לרוב, ארגונים מבקשים מודלים חלופיים כאלה שכן לעיתים הם מציעים עלויות נמוכות יותר או לו"ז טוב יותר. הסיכון כגורם משמעותי בהקשר של מודלים לתמחור- הסיכונים ללקוח ולספק שונים זה מזה. עבור הלקוח, הסיכון קשור לתקציב ולשינויים הארגוניים משמעותיים. יכולתו של הלקוח לנהל את הסיכונים הינה קריטית להצלחת הפרויקט. עבור הספק, הסיכון קשור לביצועים הפיננסיים ולרווח הפוטנציאלי מהפרויקט. שיקולים אלה, משפיעים על רמת הסיכון שמוכן הספק לקחת- ככל שהסיכון הנתפס יהיה גבוה יותר, כך גם המחיר. סיכונים נוספים, גם ללקוח גם לספק, קשורים גם במבנה הפיננסי הספציפי של כל עסקה. פירוט לגבי הגורמים המשפיעים על רמת הסיכון של הלקוח ושל הספק, ניתן למצוא בנספח 8. 9 שיקולים בבחירת סוג החוזה על פי תקנות הרכש האמריקאי, יש לבצע מו"מ על סוג החוזה, ביחד עם מו"מ על המחיר. מטרת המו"מ היא להשיג רמת סיכון סבירה עבור הספק, ולתת לו את התמריץ המרבי לביצוע אפקטיבי וחסכני. בחוזה מסוג פיקס פרייס נוקשה,(Firm-Fixed-Price) אשר מנצל הכי טוב את מוטיבציית הרווח של ספקים, יש להשתמש כאשר הסיכון המעורב הוא מינימאלי או ניתן לצפייה ברמה סבירה של ודאות. כאשר לא ניתן לקבוע מחיר נוקשה, יש לשקול סוגי חוזים אחרים, אשר קושרים את הרווח לביצועי Maurer,W. Scardino, L. Doering, K. Ridder, F (2008). Pricing Model Definitions, Benefits and Risks for 8 General Services IT Services and Outsourcing Contracts. Gartner website: 9 תקנון הרכש האמריקאי, 2005 :,(FAR) FEDERAL ACQUISITION REGULATION של ה-.Administration 80

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

82 התאמה, יתרונות, חסרונות- שלושת המודלים הכללים לחוזי 10 IT חברת "גרטנר" מפרטת את היתרונות והחסרונות ללקוח ולספק בשלושת סוגי החוזים: חוזה פיקס פרייס שימוש: כאשר על הארגון לשלוט או לחסוך בהוצאות וחשוב לו לדעת מהו המחיר הצפוי לשירותים. חשוב כי היקף העבודה יהיה מוגדר היטב, צרכי השירות יהיו ברורים והדרישות יציבות. כמו כן, חשוב כי לארגון יהיו קריטריונים ברורים למדידת איכות השירות וההצלחה. על הארגון להבין כי קביעת מחיר, משמעותה ויתור על חלק מן הגמישות שיש בתמחור על פי השוק. הספקים, מתבססים בתמחור על מידת ביטחונם כי הם יכולים למדוד את היקף המאמץ הנדרש מהם. בסביבות לא יציבות יהיה קשה לספק לעבוד עם חוזים מסוג זה. ספק לקוח יתרונות חסרונות יתרונות ברור הכנסה תרשים קושי רב יותר להתאים לחריגה נמוך סיכון לאורך תקופת ההסכם דרישות או היקפים בעלויות במקרה הצורך יכולת לנהל את הרווחיות פחות מאפשר חדשנות הארגון את מכריח מדיוק שימוש דרך את היטב להגדיר במשאבים ההיקפים והדרישות החוזה, תנאי קיבוע לשלם פוטנציאל קיים ועלויות שירות רמת מאפשר הזדמנות לרווח השוק, ממחיר יותר צפויים; קל יותר לתקצב ארוכי- בחוזים בייחוד טווח סיכון התמחור: ללקוח- נמוך עד בינוני; לספק- בינוני עד גבוה חסרונות סכנה לחריגה בעלויות אם הנחות התמחור שגויות או שההסכם אינו מנוהל היטב מתח במערכת היחסים אם יש צורך בשינויים רבים חוזה קוסט+ שימוש: כאשר לארגון יש קושי להגדיר את היקף העבודה ורמת המאמץ הנדרשת וצופה כי הדרישות ישתנו. בחוזה כזה על הלקוח והספק להסכים על עלויות סבירות במהלך חיי הפרויקט, מה שדורש שימור של מערכת יחסים בריאה ביניהם. לקוח ספק יתרונות חסרונות יתרונות חסרונות הארגון יכול לדעת פוטנציאל לחוסר הסכמה סיכון נמוך לניתוק בין חשיפת הרווח בפני במדויק את קו-ההתחלה לגבי העלויות רווח ועלות הארגון של העלויות 82 (2008) al. Maurer et ר' הערה.5 10

83 פוטנציאל כי העלויות יעלו אם לא ינוהל הפרויקט קל להחליף למודל אחר אף עם אותו הספק נכון אין תמריץ לספק לשפר הבנה מפתח הארגון היעילות את של יותר טובה והאפקטיביות האלמנטים של עלויות ושל מערכת היחסים בין רמת השירות והמחיר סיכון התמחור: ללקוח- גבוה; לספק- נמוך. סיכון נמוך עבור שירותים חדשים יכולת לעבור לחוזה יותר רווחי בעיות במערכת היחסים אם קיים קושי להסכים על העלויות אדמיניסטרציה רבה, על מנת לעקוב אחר המשאבים והעלויות חוזה T&M שימוש: כאשר לא ניתן להעריך היטב את הדרישות וצפוי כי ההיקף או הדרישות ישתנו. הספקים יתחרו על החוזה, בהתבסס על זמינות המשאבים, רמת המאמץ הנדרשת ומשך הפרויקט. רמת המחויבות בין הספק והלקוח למערכת יחסים ארוכת-טווח היא מינימאלית ולכן התמחור יהיה בדרך כלל גבוה יותר. לקוח חסרונות יתרונות תמריצים מספק אינו הארגון משלם רק עבור לספק לשפר את היעילות בהם המשאבים או האפקטיביות השתמשו אדמיניסטרציה עלויות מאפשר לארגון לבחור בשל צורך גבוהות ולהתאים את המשאבים לעקוב אחרי החיובים בעלויות לשלוט קושי אין מחויבות לטווח ארוך ולהשוות את התמחור לספק סיכון התמחור: ללקוח- גבוה; לספק- נמוך. ספק יתרונות ניתוק קשר סיכון נמוך, בין רווח ועלות שימוש מאפשר חשבון על במשאבים הלקוח חסרונות אין מחויבות לרווח ארוך- טווח עלויות אדמיניסטרציה גבוהות בשל צורך לעקוב אחרי החיובים פיתוח מערכת היחסים הוא אתגר ; שיקולים נוספים: גמישות- יש לקחת בחשבון הערכה של רמת הגמישות שתידרש במהלך הפרויקט. למשל, אם חוזה של פיק פרייס יהיה ארוך טווח, יהיה קושי לבצע שינויים. ישנם מודלים יותר ופחות גמישים בהתאם. שקיפות- התמחור צריך להיות שקוף כך שהארגון יוכל להבין היטב את העלויות, את היחס בין האיכות והמחיר וכד'. כמובן, לא על חשבון המידע הפרטי של הספק. ישנם מודלים יותר ופחות שקופים. יכולת חיזוי- ישנם ארגונים הצריכים לדעת בדיוק כמה דברים יעלו בכל שנה. בארגונים כאלה יתכן ויכולת החיזוי חשובה יותר מגורמים אחרים. ישנם מודלים המאפשרים יותר ופחות יכולת חיזוי. 83

84 התאמה, יתרונות, חסרונות- פירוט לגבי חוזי הרכש האמריקאי האפשריים ל 11 IT סוג החוזה אופי החוזה והתאמתו סוג המוצרים משמעויות החוזה ומגבלות ניתן לקבוע מחיר סביר והוגן מראש פיקס פרייס נוקשה פיקס פרייס תמריץ קוסט תגמול קבוע קוסט תגמול הדרישות מפורטות ומוגדרות ברמה סבירה תנאים לשימוש: ישנו ניסיון ברכש של מוצר/שירות דומה יש נתונים אמינים לקביעת המחיר ויכולת להעריך ריאלית את העלויות ניתן לזהות ולתמחר את אזורי חוסר הודאות לגבי הביצועים הספק מוכן לקחת עליו את כל הסיכונים הפיננסיים מוצרים מסחריים, שירותים. סוג חוזה מועדף על פני כל חוזה אחר (אם מתאים) המחיר אינו ניתן להתאמה, ללא קשר לעלויות הספק כל הסיכון הפיננסי מוטל על הספק-סיכון מינימאלי לממשלה מטיל הכי מעט אדמיניסטרציה על הלקוח קיימת אי-ודאות לגבי המחיר, אך קיים פוטנציאל להורדת המחיר ו/או שיפור עם הביצוע, ע"י מתן לספק אחריות מסוימת על העלויות ותמריץ לרווח. על החוזה להכיל: עלות מטרה, רווח מטרה, מחיר תקרה, נוסחא לחישוב חלוקת הרווחים ניתן לתמרץ באמצעות האלמנטים הבאים- עלויות, ביצוע, מסירה ואיכות פיתוח וייצור רווח/הפסד מתבססים על העלות הסופית של הלקוח מול עלות המטרה שנקבעה חוזה כזה יתבסס על הקביעה כי זהו החוזה הכדאי מבחינת עלות ואין חוזה מתאים ממנו מבחינה אדמיניסטרטיבית הנטל על הלקוח והספק גדול יותר מאשר שאר חוזים מסוג פיקס פרייס לספק מערכת פיננסית מתאימה + קיימת אי ודאות לגבי ההיקפים הנדרשים ולא ניתן להעריך באופן סובייקטיבי את ביצועי הספק חוזה "השלמה"- לשימוש כאשר ישנה משימה מוגדרת, עם מטרות מוגדרות ותוצר סופי מוגדר חוזה "תנאים"- לשימוש כאשר היקף העבודה מוגדר רק באופן כללי יש להעדיף חוזה "תנאים" "השלמה" על חוזה התגמול הוא אחוז מוסכם מן העלות הצפויה, בזמן החתימה על החוזה התמריץ לשליטה בעלויות "השלמה"- חוזה הוא מינימאלי ופיתוח למחקר כאשר ניתן להגדיר יקר לניהול, יש לוודא שלספק היטב את המשימה, מערכת פיננסית מתאימה המטרות והתוצר סוג החוזה הפחות מועדף שכן אין כל סיכון פיננסי המוטל על הספק "תנאים"- חוזה ניתן למחקר. להשתמש בו לפיתוח כאשר חוזה קוסט+ תמריץ איננו אפשרי גובה התגמול המקסימאלי לR&D - 15% (מן העלות הצפויה) + תמריצי הביצוע מוגדרים היטב וניתנים למדידה אובייקטיבית. התגמול יחושב ע"י נוסחא שתסוכם בחוזה בהתאם למערכת היחסים שבין עלות קושי במו"מ בקביעת הטווח מערכות פיתוח שבין התגמולים המינימאליים והמקסימאליים גדולות לאחר שנקבע כי זהו סוג החוזה להימדד הביצועים על הרצוי וכי הוא אפשרי מתוך:,Naval air חיל הים האמריקאי-

85 ממריץ התקרה למחיר הרצוי. התגמול הכולל בR&D לא יעלה על 15% מהעלות הצפויה על החוזה להכיל: עלות מטרה, תגמול מטרה, תגמול מקסימאלי ומינימאלי, נוסחא לחישוב התגמול חישוב והתאמת התגמול, החוזה יעשו בסיום אדמיניסטרטיבית אובייקטיבית יקר לניהול, יש לוודא שלספק מערכת פיננסית מתאימה פיקוח יהיה כי חשוב במהלך ראוי ממשלתי הביצוע להבטיח כי נעשה שימוש בשיטות אפקטיביות וישנה שליטה יעילה בעלויות קוסט מענק תגמול + לתמריצים יש תועלת אך קשה למדוד עד את הביצוע עד הסוף הביצוע של הספק נתון להערכה סובייקטיבית ההערכה נעשית בתקופת הביצוע לקביעת מענק התגמול, ברורים בזמן עליו הוחלט, יקבעו מדדים המענק יינתן על הצטיינות בביצועים, איכות, זמנים ואפקטיביות בעלויות וניתן להעניק חלק ממנו או את כולו ניתן לפצל את המענק ל 2 : ל 3% לא לחרוג מעבר *מענק בסיס- מהעלות הצפויה * מענק כולל שירותים שהמאמץ לגביהם יכול להימדד רק סובייקטיבית המענק לא יחושב על ידי נוסחא משקללת סכום המענק שיוחלט ע"י הממשלה, אינו נתון לדיון עדיפות לשימוש בחוזים מסוג "קוסט+תגמול קבוע" או "קוסט+תגמול ממריץ" על פני חוזה זה לא ייעשה שימוש בחוזה זה, אם המענק אינו צפוי להניב תועלת נוספת (בביצוע/ בעלויות וכד') יש לוודא חוזה יקר לניהול. פיננסית מערכת שלספק מתאימה מענק הבסיס ביחד עם המענק הכולל, לא יעלו ב R&D על 15% מהעלות הצפויה. T&M (לא נמנה ברשימת החוזים האמריקאיים לIT ) לשימוש כאשר לא ניתן בשום אופן להעריך את משך והיקף העבודה או העלויות הצפויות פרויקטים של שרותי לשימוש רק כאשר אף חוזה תכנון והנדסה אחר איננו מתאים המשולבים גם ביצור. איננו מעודד שליטה תחזוקה בשעת אפקטיבית בעלויות חירום דורש מעקב מתמיד ע"י הממשלה, על מנת להבטיח ניהול אפקטיבי של הספק יש לקבוע מחיר תקרה בזמן מתן החוזה 85

86 המלצות לבחירת חוזה 12 מחקרם של Kalnins &Mayer שבדק 394 חוזים וכן סוקר מחקרים נוספים, מביא את ההמלצות הבאות לבחירת סוג החוזה, בהתאם לסוג ואופי הפרויקט *: חוסר ודאות לגבי העלויות בפועל ודרישות הפרויקט חוזה פיקס פרייס מעניק יותר תמריצים לספק לפעול באפקטיביות, כיוון שהוא הנושא בחריגה בעלויות או- מרוויח כאשר הוא חוסך. כאשר פרויקט הוא מורכב, קשה להעריך את העלות הכוללת מראש ואת הדרישות המדויקות ואז חוזה של פיקס פרייס, הופך בעייתי. במחקרים קודמים, נמצא כי הערך העיקרי של חוזי T&M לעומת חוזי פיקס פרייס, הוא העלות הנמוכה של מו"מ מחודש. בחוזי,T&M לספק מובטחים החזרים ללא מו"מ, כל עוד נצמדים להיקף הפרויקט. כך, בחוזי,T&M כאשר הדרישות משתנות קל יותר ללקוח לבקש מן ספק שינויים ללא מו"מ על החוזה. כאשר חוסר הודאות היא ברמה בינונית, ניתן לשקול חוזי קוסט+. מחד, כל עוד לא הייתה חריגה ממחיר התקרה שנקבע, ניתן לשנות דרישות ללא מו"מ מחודש. מאידך, קיימים תמריצים לספק לפעול באפקטיביות (כי אינו יכול לחרוג ממחיר התקרה). מכאן: רמת ודאות גבוהה פיקס פרייס רמת ודאות בינונית קוסט + רמת ודאות נמוכה T&M עלויות מדידת האיכות לאחר הביצוע יכולת הלקוח למדוד את האיכות לאחר ביצוע הפרויקט, הינה גורם חשוב נוסף, לבחירת סוג החוזה. כאשר ישנו פוטנציאל גבוה לבעיות איכות נסתרות, או פגמים חבויים (קושי לבצע בדיקת איכות מהימנה לאחר סיום הפרויקט)- הרי שחוזה מסוג פיקס פרייס הוא בעייתי, שכן לספק קיים תמריץ חזק להפחית את האיכות באופן שלא לא יתגלה בקלות ללקוח, על מנת לחסוך בעלויות. בחוזים מסוג T&M בעיה זו פחותה. למעשה, חוזים מסוג זה אף עשויים לתמרץ איכות-עודפת, במטרה להגדיל את העלויות. כאשר יכולת המדידה של האיכות לאחר הביצוע היא בינונית-סבירה, חוזה של קוסט+ עשוי להיות תחליף אפקטיבי לחוזים האחרים. קיומו של מחיר תקרה, עשוי להחליש את מוטיבציית הספק לספק איכות נמוכה יותר. מכאן: יכולת מדידת איכות טובה פיקס פרייס יכולת מדידת איכות בינונית קוסט+ יכולת מדידת איכות נמוכה T&M Kalnins, A. &Mayer, J.M (2004). Relationships and Hybrid Contracts: An analysis of contract choice 12 in information technology. Journal of Law Economics & Organization, 20 (1), * חשוב לציין כי בהגדרה של המאמר לT&M הוא מוגדר ללא מחיר-תקרה (בשונה מן הנאמר כאן למעלה). כאן, מחיר תקרה, מצוי בחוזה מסוג קוסט+. 86

87 מערכת היחסים עם הספק מערכת היחסים עם הספק, עשויה להשפיע על בחירת החוזה. במידה והתקיימה מערכת יחסים בעבר, שעלתה יפה, יהיה יותר אמון בין הספק והלקוח והעבודה המשותפת עשויה להיות אפקטיבית יותר. האמון, עשוי לשמש כתמריץ ליעילות, ובכך יפתור את נקודת התורפה של חוזים מסוג.T&M אותו אמון, עשוי גם להפחית את המחיר בחוזים מסוג פיקס פרייס, אלא שחוסר הודאות של הIT המצריך שינויים רבים, עדיין עושה אותם פחות אטרקטיביים מחוזי. T&M נראה, כי במערכת יחסים יותר אמינה, בפרויקטים של,IT ישנה נטייה להשתמש יותר בחוזים מסוג T&M או- קוסט+. הרחבה נוספת על נושא מערכת היחסים עם הספק תעשה בהמשך. 14 מחקר נוסף, בדק את כדאיות השימוש בחוזי פיקס פרייס נוקשה וקוסט+ (ספציפית נבדק: קוסט+ תגמול קבוע). המחקר, נעשה לגבי חוזים של R&D (מחקר ופיתוח) בממשלה. מחקר זה מצא, כי בפרויקטים של R&D ככל שהעמימות מבחינתו של הספק לגבי תנאי הפרויקט גדולה יותר, כך התמריצים משפיעים עליו פחות, כיוון שחוסר-הודאות מדאיג אותו. לפיכך, כאשר העמימות היא גדולה, חוזה של קוסט+ יתאים יותר (פחות מבוסס על תמריצים). דגשים לחוזים חוזים אפקטיביים מבנים את מערכת היחסים שבין הספק והלקוח, 15 באופן המשתלם לשניהם. יש לשים לב כי חוזה מסוג פיקס פרייס, קל יותר לניהול ולפיכך ישנה נטייה שלא לעקוב אחר העלויות בפועל של הפרויקט, מה שעשוי להסתכם בעלות כוללת גבוהה יותר מהצפוי. כמו כן, לא תמיד מצליחים לקחת בחשבון את כל העלויות הצפויות בחוזה. חוזה של קוסט+ אומנם קשה יותר לניהול אך הוא מכריח מעקב צמוד אחר העלויות תוך כדי ביצוע, מה שמאפשר השוואה 16 מתמדת של התקציב לעלויות בפועל. Mukerji, S. (2003). Ambiguity Aversino and cost-plus procurement contracts discussion paper series- Department of economics. Oxford. Aubert, B. Houde, J.F. Patry, M. Rivard, S. (2003). Characteristics of IT Outsourcing Contracts, Proceedings of the 36th Hawaii International Conference on System Sciences. Alfano, S (2004).The real value of cost-plus: fixed-price contracts give remodelers an excuse to ignore job costing. That's a mistake that could really cost you

88 המדיניות האמריקאית כיום 17 לאור המשבר הכלכלי, פנה הנשיא אובמה לבחון את מצב הרכש האמריקאי והוציא הנחיות בנושא. כמדיניות, ממשל אובמה הודיע כי יש לעודד שימוש בחוזים מסוג פיקס פרייס וקובע שיש לעשות בהם שימוש עד כמה שרק ניתן. הממשל הודיע כי בכוונתו להקפיד יותר מבעבר כי יעשה שימוש בחוזים אלה. חוזים מסוג קוסט+ ו- T&M, כך נקבע, הינם בעלי סיכון רב כיוון שאינם מספקים תמריצים לספק לשלוט בעלויות ולפיכך הם בזבזנים, לא יעילים ונתונים לשימוש לקוי. אומנם קיימים מקרים בהם יש צורך להשתמש בחוזים כאלה, אך נמצא כי בפועל משרדי הממשלה לעיתים קרובות משתמשים בחוזים הללו ללא סיבה מספקת וללא ניהול מספק. כך למשל, סכום החוזים מסוג שיפוי עלות (קוסט+ למינהו) הוכפל בין השנים 2000 ועד 2008: בשנת 2000 העלות הכוללת של חוזים מסוג זה הייתה 71 מיליארד דולר. בשנת 2008 העלות הכוללת הגיעה לכדי 135 מיליארד דולר. בקרוב יעשו שינויים בתקנות הרכש בארה"ב, לגבי המדיניות והפרקטיקות הקשורות בחוזי שיפוי עלויות, על מנת למנוע שימוש מרובה בהם. 18 מאידך, קיימת ביקורת בעיתונות, על השימוש בחוזי פיקס פרייס כשמדובר במערכות מידע. נשמעות טענות מצד מומחים כי יש להתאים לכל פרויקט את סוג החוזה המתאים לו. מדיווחים של מכון המחקר INPUT (מכון המדווח לממשלה), עולה כי משרדי הממשלה האמריקאים עדיין אינם מיישמים בפועל את מדיניות הפיקס פרייס של ממשל אובמה. רק 18% מן הפרויקטים השונים (לא רק (IT שיצאו במסגרת תוכנית התמריצים של הממשל להתמודדות עם המשבר הכלכלי, אכן מיושמים בפיקס פרייס ורוב הפרויקטים עדיין נעשים בחוזה של קוסט+. הטענה נגד חוזים של פיקס פרייס בקרב המגזר הממשלתי בארה"ב, היא שלחוזים אלה לוקח זמן רב יותר לצאת לפועל, הם קשים יותר לכתיבה, דורשים יותר אנשי-צוות, קשים יותר לניהול וישנה סבירות גבוהה יותר כי הם יעוררו התנגדויות. מאידך, עדיין רוב החוזים של הממשלה באופן כללי (נתונים מ 2008 ), נעשים בפיקס פרייס- 60% ורק 25% נעשים בקוסט+, כך לפי משרד הOMB האמריקאי. באופן כללי, קיימת טענה, כי ישנה מטוטלת הנעה בין שני סוגי החוזים והפופולאריות שלהם משתנה מעת לעת את הוראות הנשיא אובמה לראשי המשרדים, ניתן למצוא במזכר של הבית הלבן: /Departments-and-Agencies-Subject-Government מתוך מזכר של המשרד לניהול ותקציבים האמריקאי, יולי Brodsky, R. (2009). NEWS+ANALYSIS Cost of Risk. Government Executive. 18

89 מודלים של תשלום 19 PFI- Private Finance Initiative ה-,PFI הינה אחת השיטות מסדרת ה- -(PPP) Public Private Partnerships שותפות של המגזר הציבורי והפרטי. ה-,PFI הינם חוזים בהם המגזר הציבורי, מסכם על רכישת שירותים איכותיים, לטווח-ארוך, מחברה במגזר הפרטי. כך יכול המגזר הציבורי לנצל את יתרונות הניהול במגזר הפרטי כשהם מתומרצים בקיומו של סיכון פיננסי עבור המגזר הפרטי. בזיכיונות אלה, השותף מהמגזר הפרטי לוקח אחריות על אספקת שירותים ציבוריים, כולל בניה ותחזוקה של התשתית הנדרשת. על מנת שיצליח, על ה PFI להתנהל במערכת יחסית טובה בין הסקטור העסקי והפרטי מתוך הבנת האחריות המשותפת. PFI במערכות מידע מחקר שנערך מטעם משרד האוצר הבריטי, העלה כי פרויקטים מסוג PFI הינם בעלי השפעה חיובית 20 בדרך כלל. אולם, הדבר לא הוכח לגבי תחום הIT. המחקר קובע כי ברוב רכש הIT, שהוגדר כמוצלח, נעשה מו"מ מחודש על החוזים, אשר הביא להתרחקות ממודל ה PFI הרגיל ולאימוץ גישה אחרת. המחקר הצביע, כי בגלל ההבדלים המשמעותיים בין PFI בתחום הIT PFI- ל בתחומים אחרים, והקשיים הנלווים של הבטחת חלוקת-סיכונים ראויה באמצעות,PFI הרי שייתכן כי PFI בIT לא יוכל לספק באופן עקבי, תמורה לכסף money).(value for קשיי הPFI בתחום הIT התקשרות בתחום ה IT אינה מתאימה היטב למספר דרישות מרכזיות ב :PFI קושי להגדיר את הדרישות: קצב השינוי המהיר בתחום זה (בשילוב עם הקשר ההדוק הקיים בין תשתית הIT והצרכים התפעוליים של הארגון) מקשה על המגזר הציבורי להגדיר באופן אפקטיבי את התוצאות הנדרשות, בחוזה ארוך-טווח. ככלל, סביר מאוד שהדרישות בפרויקט,IT ישתנו לעיתים תדירות במהלך החוזה. קושי לחלק תחומי אחריות וסיכונים: הרמה הגבוהה של האינטגרציה בין תשתית הIT והמערכות האחרות של הממשלה, מקשות על התווייה ברורה של תחומי האחריות ללקוח ולספק, ולפיכך נוצר קושי לאבחן, למקם ולאכוף חלוקת סיכונים ראויה. קושי להחליף ספק: בניגוד לפרויקטים של PFI בתחומים אחרים, עקב המורכבות הרבה של נושא הIT וקשיי האינטגרציה במערכות הלקוח, קשה בPFI של IT להחליף ספק שנכשל, מתוך דו"ח משרד האוצר הבריטי, יולי 2003: challenge.pfi: Meeting the investment % נמסרו בזמן או אף מוקדם מכך. כל הפרויקטים שנדגמו, נמסרו במסגרת התקציב. 77% מהמנהלים במגזר הציבורי דיווחו כי הפרויקט ענה על ציפיותיהם.

90 באופן המשתלם- מבחינת זמנים. משמעות הדבר, שכאשר שירות לא סופק כראוי, הממשלה נמצאת בעמדת נחיתות בבואה לשאת-ולתת עם הספק הנוכחי. העדר שוק של מימון-מצד-שלישי: לעומת תחומים אחרים של,PFI בחוזי PFI של IT נדיר כי מעורב מימון מצד שלישי. זאת, למרות הציפייה כי שוק כזה, יתפתח עם התפתחות הPFI בIT. למצב בו לא קיים מימון מצד שלישי, ישנן מספר תוצאות: o יכולתו של המגזר הפרטי לממן עלויות פיתוח ישירות וארוכות טווח מוגבלת. לפיכך על מנת לממן את העלויות, על החברות ללוות כסף. הדבר נכון במיוחד בפרויקטים גדולים של, IT אז על החברות לממן שנים של פיתוח לפני שהן מקבלות רווח כל שהוא. o העדרו של גורם שיכול היה לבצע הערכת סיכונים מעמיקה ומקיפה ביותר אשר הוכח כי מפחיתה את הטיית האופטימיות אצל הלקוח ומחזקת את תנאי החוזה. הדבר מקשה על הבטחה של חלוקת סיכונים אפקטיבית ובכך מפחית את יכולתו של חוזה הPFI להבטיח תמורה לכסף במגזר הציבורי. o עבור חברות קטנות ובינוניות קיים קושי לגשת למכרזים לפרויקטים רבים, בייחוד בהתחשב בהיקפם הגדול של חלק מהפרויקטים והדרישה מן המגזר הפרטי, ברבים מחוזי הPFI, לממן ישירות את עלויות הפיתוח. העדרן של חברות קטנות- ובינוניות, מחליש את התחרות. קושי הנובע מטבעה של ההשקעה הכספית - אמנם פרויקטים של PFI בכל התחומים (כולל,(IT כוללים רכש של נכסים (כגון: בניינים, אפליקציות,IT מערכות), אולם ב,IT עלויות המסירה של הפרויקט נשלטות בעיקר על ידי עלויות שנתיות שוטפות ולא על ידי העלויות הישירות של השקעה בנכסי הפרויקט. בפרויקט טיפוסי של,IT נכסי הפרויקט הם פחות משליש מערך הפרויקט, בעוד בפרויקטים של PFI שאינם,IT נכסי הפרויקט בעלי ערך הגבוה מזה באופן משמעותי. עלויות רענון הנכסים, חוזה קצר- חייו של חוזה PFI בIT הינם לרוב קצרים יותר מזה של PFI בתחומים אחרים IT) טיפוסי- 10 שנים; תחומים אחרים שנה). אורך חייהם של נכסי פרויקט ה IT (כגון: מחשבים וכו') אף קצר יותר מזה של החוזה. כתוצאה מכך, על הספק לקחת על עצמו גם את העלויות המשמעותיות של רענון הנכסים במהלך הפרויקט (למשל, החלפת שרתים, נצרכת יותר מפעם אחת ב 10 שנים). זאת, בעוד בפרויקט טיפוסי של PFI שאיננו,IT רוב הנכסים יהיו שמישים לאורך כל חייו של החוזה. היות ההשקעה מתמשכת ומדורגת, מקשה על הגדרת ואכיפת צרכי השירות לטווח ארוך. 90

91 ביצועי חוזה מסוג PFI בIT ניתוח פרויקטים של IT שנעשו בשיטת,PFI בבריטניה, משקף מספר הבדלים. הפרויקטים המוצלחים ביותר היו אלה אשר נשאו ונתנו מחדש על החוזה לאחר החתימה, להשגת הגדרת דרישות יותר גמישה, כשהם מתרחקים ממודל הPFI. 16 נבחנו אך נועד לתת אינדיקציות. הסקר שנעשה על ידי משרד האוצר הינו מצומצם למדי, הפרויקטים נבחרו ממחלקות שונות ובגדלים שונים. במגזר הציבורי. IT פרויקטים מייצגים של ממצאים: 76% מן הפרויקטים הוגדרו כעונים על ציפיות המשתמש או אף עולים עליהן. רק 22% מן הפרויקטים, על פי המנהלים, מסרו % מן הרווחים שהוגדרו לפרויקט. ניסיון הלקוחות הממשלתיים עם פרויקטים של IT בשיטת PFI מידת שביעות הרצון של המשתמשים הערכת מנהלי הפרויקט לגבי אחוז המסירה (Delivery) של היעדים שהוגדרו לפרויקט עלה על הציפיות לא ענה על הציפיות ענה על הציפיות 91

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

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

94 אבני דרך לאחר שקבעו כי חוזים מסוג PFI אינם מוצלחים כאשר מדובר בIT, המליצו הבריטים על שיטת אבני 22 הדרך. בהשוואה לשיטת ה,PFI השיטה המוצעת יותר מאוזנת מבחינת התשלום, כך שיופחתו עלויות המימון לספק. הפחתת עלויות המימון, יתגלמו במחיר של הספק. תשלום עבור אבני הדרך, יכסה את עלויות הספק (פיתוח, ציוד וכו'). אולם, התשלום לא יתאים בדיוק לעלויות של הספק, אלא עליו לשקף גם את הערך שנמסר באותה אבן דרך (לאחר שעבר מבחן ביצוע). 23 בשיטה זו, לאחר הבנת הדרישות יש לפרק אותן לאבני דרך. אבני הדרך מתארות מה על הצוות להשיג, על מנת להעביר את הפרויקט ממצב אחד למשנהו. על מנת להשיג את אבני-הדרך, על הצוות לספק מוצרים מסוימים תוך שכל שלב מערב את האנשים הקשורים אליו. אבני-הדרך, משמשות לביקורת על התקדמות הפרויקט ומצבו- הצוות יכול להגדיר את מצבו אל מול אבן הדרך. כאשר מפתחים אותן, מומלץ להימנע מהגדרה מפורטת מדיי שלהן- הגדרה של כל צעד וצעד באבן הדרך עשויה לבלבל את הצוותים המנוסים. ניתן לתת דוגמאות שינחו, אך לא לתת הוראות מפורטות מדיי. כמו כן, מוטב לא להגדיר מתודולוגיה ספציפית לאבן הדרך אלא לאפשר לצוותים לבחור אותה בעצמם. 24 אבני דרך בחוזי ה ICT על פי מודל הסכמי הICT הבריטיים, תוכנית הפרויקט, תכיל חלוקה לאבני דרך. החלוקה, תיכלל בדיונים של שלב הרכש, ותגדיר מה הן אבני הדרך למסירה, תאריך יעד לכל אבן דרך ומתי היא מאושרת. אבני הדרך יכללו בחוזה, כך שיהיו מחייבות וכישלון בהשגתן ילווה בהשלכות כספיות על הספק. לפיכך, יש לנהל תהליך בחינה קפדני ומפורט של עמידה בדרישות. יש לדון בתהליך זה, בשלב הדיאלוג כך שהדברים יהיו ברורים ומוסכמים. הספק יהיה אחראי על בחינת אבני-הדרך, הממשלה תבחר את מידת המעורבות הרצויה לה בבחינת כל אבן דרך (בהתאם למידת חשיבות אבן הדרך או אם יש תשלום הנלווה לה). כאשר בונים תהליך לבחינת אבן הדרך יש לפרט את: o פרוצדורת הבדיקה של כל אחד מהצדדים את אבן הדרך o קטגוריות לבדיקה, כאשר לכל קטגוריה דירוג מידת החשיבות שלה על פי מודל הסכמי ICT שלמשרדהמסחרהבריטי,(OGC) חלק שני: GUIDANCE NOTE 2: DESIGNING A.PAYMENT MECHANISM USING THE ICT SERVICES MODEL AGREEMENT West, D. (2009). Best Practices: Software Development Processes, forrester website: על פי מודל הסכמי ICT של משרדהמסחרהבריטי,(OGC) גרסה אחרונה מאוקטובר 2009: ICT SERVICES AGREEMENT GUIDANCE el%20ict%20agreement%20guidance%20version%202%203.pdf

95 פרוצדורות לבדיקה מחדש במקרה של כישלון o קריטריון ההצלחה o השלב בו מוענק אישור לאבן הדרך o לרוב, רק חלק מאבני הדרך ילוו בתשלום. תאריכים אחרים שאינם תאריכי יעד של אבני הדרך, בהתאם לפרויקט, משמעותיים. יהיו פחות 25 הסדרי התשלום בשיטת אבני הדרך מודל התשלום, יונחה על ידי התפיסה כי יש להעביר מידה מספקת של סיכונים לספק, אך בתוך כך גם לצמצם את המצב בו עליו לכסות תקופות ממושכות של תזרים מזומנים שלילי. על מודל התשלום, לקבוע כיצד תשלם הממשלה לספק עבור שירותיו ובאילו תמריצים ייעשה שימוש על מנת להניע את הספק לבצע את המסירה באופן המיטבי. התשלום לא יהיו קשור ישירות לעלויות הספק- אלא לאבן הדרך. לא כל אבן דרך צריכה להיות מלווה בתשלום. תשלום עבור אבן דרך, יהיה רק כאשר הממשלה מקבלת דבר מה בעל ערך ארגוני מוכח ולאחר שהושלמו בהצלחה הבדיקות הרלוונטיות עליהן הוסכם. בהקשר זה, "ערך ארגוני" משמעותו דבר מה אשר הממשלה תוכל למצוא בו תועלת במידה והחוזה מסתיים ביום שלאחר הגשת אבן-הדרך. למשל, במקרה של פיתוח תוכנה, חשוב כי ניתן יהיה להוסיף ולפתח את התוכנה במקרה והחוזה עם הספק מסתיים לפתע. לכן, חשוב כי יהיה הסכם רישיון לשימוש ללא גביית תשלום נוספת מצד הספק- כך שניתן יהיה להמשיך לפתח את התוכנה עם צד שלישי. התשלום המרבי עבור אבן הדרך, יכלול רק את העלויות שנקבעו עבור אבן הדרך הספציפית, בהסכם (ללא תשואה). התשלום יינתן רק עם מילוי הדרישות של אבן הדרך. רק במקרה בו אופן תשלום זה, אינו מספק ומהווה נטל פיננסי כבד ביותר על הספק ניתן לבצע את התשלום לספק בתשלומים, תוך קביעת שלב אחד או יותר, לתשלום. תשלומים שכאלה יעשו רק בליווי מסמך המאפשר לממשלה למשוך חזרה את התשלום במידת הצורך. יש להימנע ככל האפשר מתשלומים כאלה ולעשות בהם שימוש רק כאשר הם משפרים את התמורה לכסף. בדרך כלל, אבן הדרך המשמעותית ביותר, המלווה בתשלום, היא זו אשר קשורה ל"אישור התקדמות". אישור התקדמות, הינו אישור הניתן על ידי המשרד המזמין ומעיד כי הבדיקות שנעשו לוידוא מוכנות למסירה הושלמו בהצלחה. כל התשלומים ששולמו עד "אישור התקדמות", יהיו תשלומי-שירות ללא תשואה עבור הספק. לכל "אישור התקדמות" תקבע "נקודת ביצוע חוזה", שהיא נקודת זמן שנבחרה, שאחריה כל השירותים הרלוונטיים (לאבן הדרך) פועלים במלואם, ובסביבה בה אמורים להיות מוטמעים (כולל אינטגרציה). יכולות להיקבע עוד אבני דרך, בין נקודת "אישור ההתקדמות" ל"נקודת על פי מודל הסכמי ICT שלמשרדהמסחרהבריטי,(OGC) חלק ראשון ושני: ICT SERVICES AGREEMENT. GUIDANCE NOTE 1,2 GUIDANCE,

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

97 חוזים מודולרים 26 בהגדרות האמריקאיות לרכש מערכות מידע, נקבע כי יש להשתמש בחוזים מודולרים. החוזה המודולרי- הינו שימוש בחוזה אחד או יותר לרכישה של מערכות מידע, באופן אינקרימנטלי, עקבי ובין-מערכתי. הרעיון של שימוש בחוזה מודולרי, הוא להפחית את סיכון הפרויקט, לתמרץ את הספק ולאפשר ללחות הזמנים להתאים לטכנולוגיה המשתנה במהירות. משרדי הממשלה חייבים להשתמש אם כן, בשיטה של חוזה מודולרי- עד כמה שרק ניתן- ברכישה של מערכות גדולות. ניתן להשתמש גם ברכישה של מערכות שאינן כה גדולות. כאשר משתמשים בחוזה מודולרי, מחלקים רכש של מערכת גדולה למספר רכישות קטנות יותר אשר: קלות יותר לניהול, מאשר לנהל את כל הרכישה המקיפה בבת אחת. מאפשרות לגשת באופן אינקרימנטלי למטרות המורכבות של ה IT ובכך להגביר את ההסתברות כי המטרות יוגשמו ותושג מערכת שמישה. מאפשרות מסירה, יישום ובדיקה של מערכת או פיתרון, באופן בלתי תלוי בתוספת הבאה (בשלב הבא). מאפשרות הזדמנות לתוספת הבאה למערכת, ליהנות מן ההתקדמות הטכנולוגית שחלה בינתיים ו/או לענות לצרכים חדשים שנוצרו במהלך השימוש והיישום של השלבים הקודמים. מפחיתות את הסיכון לתוצאות שליליות, של כלל הפרויקט, על ידי בידוד המרכיבים של המערכת. אופי השלבים עשוי להשתנות בהתאם לסוג ואופי המערכת. יש לקחת בחשבון את הגורמים הבאים: o על מנת לקדם את ההתאמה, ברכש IT הנעשה באמצעות חוזה מודולרי, על כל שלב לענות על הסטנדרטים המקובלים של IT כאשר ישנם כאלה, וכן על כל שלב להתאים לארכיטקטורה של מערכת המידע הראשית של המשרד. o הדרישות הביצועיות של כל שלב צריכות להיות עקביות לדרישות הביצוע מן המערכת הכוללת, ועליהן להתממשק עם השלב הבא. עבור כל שלב, יבחר סוג החוזה המתאים אשר יקל על הרכש של השלב הבא. סוג החוזה יבחר בהתאם לנסיבות. החוזה/החוזים יבנו כך, שיבטיחו כי הממשלה לא נדרשת לרכוש שלבים נוספים. על מנת למנוע התיישנות, חוזה מודולרי של,IT צריך עד כמה שאפשר, להינתן בתוך 180 ימים מבקשת ההצעה. אם לא ניתן להעניק את החוזה בתוך 180 ימים, על המשרדים לשקול לבטל את בקשת ההצעה. עד כמה שניתן, יש לקבוע בחוזה את ביצוע המסירה בתוך 18 חודשים. General Services 26 תקנון הרכש האמריקאי, 2005 :,(FAR) FEDERAL ACQUISITION REGULATION של ה-.Administration 97

98 פרק 4 מכרזים הקדמה פרק זה עוסק בהליכי המכרז. הפרק מונה ארבע שיטות של הליכי רכש ומבקש לעדכן בהליכי רכש חדשים הנהוגים בעולם. לאחר מכן, הפרק מפרט היבטים שונים במכרז כגון עלויות לספקים ומספר משתתפים. בהמשך, עוסק הפרק ביחסי הממשלה והספקים ובוחן אותם הן ברמת המאקרו יחסי הממשלה והתעשייה, והן ברמת המיקרו- היחסים בין הלקוח והספק בפרויקט. לבסוף, מובא סיכום של דברי הספקים כפי שהם נמסרו לועדה. תקציר מנהלים תהליכי רכש כיום ברכש של IT נעשה שימוש ב- 4 סוגים של תהליכי רכש: פרוצדורה פתוחה, פרוצדורה מוגבלת, דיאלוג תחרותי ומשא ומתן תחרותי. עד לעת האחרונה נעשה שימוש רב בפרוצדורת המו"מ ברכש של פרויקטים מורכבים של.IT בשנים האחרונות פיתח האיחוד האירופי את פרוצדורת הדיאלוג התחרותי והחל משנת 2006 הודיעו הבריטים כי פרוצדורה זו תחליף את פרוצדורת המו"מ. בפרוצדורת הדיאלוג התחרותי נעשה פרסום מכרז לרשימה מקוצרת עליה הוחלט על פי בדיקות מקדימות. מתוך הרשימה, נבחרים הספקים עימם ינוהל דיאלוג. בשלב הדיאלוג מפתח כל ספק מועמד פתרונות אפשריים, כאשר רשימת הדרישות הראשונית מתפתחת והולכת תוך כדי שיח. כאשר הממשלה מזהה פיתרון שעונה על צרכיה נסגר הדיאלוג לכל מו"מ נוסף, ונבחר הספק המועדף. פרוצדורה זו נועדה להרחיב את הדיאלוג עם הספקים לגבי פתרונות אפשריים כך שתתאפשר התאמה וגמישות בדרישות, לעודד חדשנות ויצירתיות ולעודד את התחרות. חסרונות השיטה הם- עלויות גבוהות, קושי משפטי אל מול חשיפת המידע באופן שאינו שווה מול החברות, מתח בנוגע לשמירת הסודיות, השקעה כספית גדולה לספקים, קושי בקביעת קריטריונים מהימנים להערכה של הספקים. היבטים שונים במכרז עלויות הפחתת עלויות המכרז לספקים הינה אינטרס של הממשלה- הן על מנת לעודד את הספקים לגשת והן כיוון שעלויות המכרז מגולמות בסופו של דבר גם בתמחור החוזה. לפיכך מומלץ לתת מידע למועמדים בשלב מוקדם ובאופן מסודר, להעמיד את התנאים בשלב מוקדם, לקבוע לו"ז צפוף אך ריאלי, וידוא כי האישורים הנדרשים ניתנים בשלב הנכון ובזמן והקפדה כי תהליך הרכש נעשה באופן אפקטיבי ויעיל. 98

99 השתתפות הספקים במכרז על המשרד לבצע הערכה של פוטנציאל שוק הספקים, האם סביר כי יספק תחרות אמיתית. לפיכך, מומלץ לבצע חקר שוק וכנס ספקים שיעורר עניין ויספק מידע. יש להקשיב ולענות לדאגות שמעלים הספקים. יש להעריך את מספר הספקים שנוח כי יתחרו במכרז- מספר קטן מדיי של ספקים עלול לפגוע בתחרות ובאפשרות לחדשנות. מאידך, מספר גדול מדיי של ספקים עלול לגרום לספקים לנשור מן התחרות, לפגוע בלוחות הזמנים ובעלויות. מומלץ להקפיד על מינימום של 3 ספקים המתאימים להתמודד על המכרז בשלב המו"מ. לעיתים נוצר כשל שוק- כאשר אין מתמודדים או שקיים רק מתמודד בודד ראוי. מומלץ לבדוק האם כשל השוק נובע מבעיה מערכתית בשוק. במידה וכן, שינוי הליך הרכש לא ישנה ועל המשרד לשקול כיצד הוא מגן על האינטרסים שלו בהמשך התהליך. במידה והכשל אינו מערכתי ומתרחש לפני קבלת ההצעות, יתכן והוא נובע מהחלטות של הספקים לסגת- יש לעצור את התהליך ולבדוק מדוע. במידה והכשל מתרחש לאחר קבלת ההצעות והתקבלה הצעה בודדת, יש לשקול את איכותה וכן לשקול עד כמה השפיעה לטובה התחרות עד שלב זה, על התמורה לכסף. מערכת היחסים עם הספקים עסקאות מושפעות מאוד ממערכות יחסים ולפיכך חלק ניכר מהצלחת הפרויקט תלויה בפיתוח יחסי עבודה חזקים בהם שני הצדדים חותרים למטרות משותפות. ברחבי העולם מודעים לחשיבות המעורבות ושיתוף הפעולה של הספקים ומצאו דרכים שונות להדק את היחסים עימם. ברמת יחסי הממשלה ותעשיית הIT, קיימים פורומים שונים ברחבי העולם אשר נועדו להפגיש בין נציגי הממשלה ונציגי תעשיית הIT. פורמים אלה נועדו לשיתוף וקידום רעיונות שונים והם נותנים קול לתעשיית הIT אל מול הגורמים הממשלתיים. בחלק מהמדינות, פורומים אלה מגבשים המלצות ודוחות לממשלה. ברמת היחסי המשרד הממשלתי והספק במהלך הפרויקט, ישנו דגש על יצירת מצב של Win-Win והוא נתפס כגורם המשפיע ביותר על יישום מוצלח של אסטרטגיית מיקור החוץ. מצב כזה, מצריך גמישות המושגת על ידי תקשורת טובה. על הלקוח והספק להסכים כי דיאלוג תמידי הוא נורמה. מומלץ להקים מנגנונים שיתמכו בתקשורת כגון פגישות על בסיס קבוע. הבריטים פתחו הסכם של "הצהרת כוונות משותפת" -(JSI) מתוך כוונה לתמוך בפרקטיקות הקיימות בין הספק והממשלה ולהציע מנגנון פחות עמום למדידת ההצלחה של הפרויקט. הסכם זה, נועד לגלם את הציפיות מהפרויקט ונחתם על ידי המנהלים הבכירים של שני הצדדים.ההסכם מבקש להצהיר על מחויבות מצד ההנהלה הבכירה של שני הצדדים, על יצירת דיאלוג פתוח ועל התמקדות בתוצאות שיוגדרו בו. 99

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

101 תהליכי רכש על פי משרד המסחר הבריטי, 1 ישנן ארבע פרוצדורות-רכש עיקריות : פרוצדורה פתוחה (מכרז פומבי): כל הספקים מוזמנים לגשת למכרז. הספקים שהגיבו להודעה, יקבלו את כל מסמכי החוזה. אין אפשרות לקצר את רשימת המועמדים ע"י תהליך של בדיקה מקדימה (Pre-Qualification) ואין לבצע מו"מ על החוזה. פרוצדורה מוגבלת (מכרז סגור): מאפשרת ללקוח להגביל את מספר הספקים המוזמנים אל המכרז על ידי תהליך של בדיקה מקדימה. אין לבצע מו"מ על החוזה. מתאימה כאשר הדרישות מפורטות מספיק בכדי שהספק יוכל לפתח ולהעריך את ההצעה ללא מו"מ משמעותי. פרוצדורת הדיאלוג התחרותי: הלקוח מבצע בדיקה מקדימה ומזמן מספר מצומצם של ספקים להשתתף בתהליך הדיאלוג במהלכו דנים בכל צדדי הפרויקט ומפותחים פתרונות. הלקוח יכול להמשיך בדיאלוג עד אשר הוא מזהה פיתרון אחד או יותר שעשוי להתאים לדרישותיו. אז, הוא סוגר את הדיאלוג ומזמן את המתמודדים הסופיים. לאחר סגירת שלב הדיאלוג מותרות רק הבהרות ודיון מוגבל ביותר, שאיננו בבחינת מו"מ. פרוצדורת המו"מ התחרותי :(RFI) הלקוח מבצע בדיקה מקדימה ומזמן מספר מצומצם של ספקים להשתתף בתהליך של מו"מ. אין חוקים מפורטים כיצד לבצע את המו"מ ובניגוד לפרוצדורת הדיאלוג התחרותי אין סיום פורמאלי לשלב המו"מ לפני החתימה על החוזה. בפועל, לעיתים קרובות היה מו"מ משמעותי לאחר בחירת הספק לאחר שהמתח של התחרות התפוגג. 2 נמצא, כי מידת המורכבות של הפרויקט, השפיעה על פרוצדורת הרכש שנבחרה. עד העת האחרונה 3 נעשה שימוש רב בפרוצדורת המו"מ ברכש של IT (ושל (PFI. זוהי פרוצדורה הלוקחת יותר זמן מן הפרוצדורה הפתוחה וזו המוגבלת, מכיוון שמדובר במו"מ על דרישות שהן יותר מורכבות וקשות להגדרה מראש. כיום, ישנו ניסיון באירופה להחליף שיטה זו בשיטת הדיאלוג התחרותי. הן שיטת הדיאלוג התחרותי האירופאית והן שיטת הפתרון המשותף הקנדית (עליהן נרחיב בהמשך פרק זה), הינן שיטות שנועדו להרחיב את הדיאלוג עם הספקים לגבי הפיתרונות האפשריים, כאמצעי התמודדות עם רכש שהוא מורכב במיוחד. השיטות, נועדו לשפר את פרוצדורות הרכש מחד, אך הן גם יקרות יותר לביצוע, מאידך. גם בקנדה וגם באירופה הן נבחרו כשיטות המועדפות לרכש מורכב מתוך מדריך של משרד המסחר הבריטי -(OGC).Competitive Dialogue in מתוך מסמך שחובר מטעם חברת הייעוץ וההכשרה,RICS הוצג בכנס באוניברסיטת דבלין Hoezen, M. and Hillig, J.B (2008). The Competitive Dialogue Procedure: Advantages, Disadvantages, and its Implementation into English and Dutch Law. 3 מתוך: -FASTER PROCUREMENT בריטניה, 2002

102 ר( 4 דיאלוג תחרותי Dialogue) (Competitive 5 בשנת 2004 פרסם האיחוד האירופי את שיטת הדיאלוג התחרותי, בציפייה ששיטה זו תחליף (להוציא מקרים מיוחדים) את פרוצדורת המו"מ התחרותי בה השתמשו עד אז לרכש מורכב. בבריטניה, אימצה המלצה זו והחל משנת 2006, על מנת להשתמש בשיטת המו"מ התחרותי, יש לבקש אישור מיוחד, תוך הבאת טיעונים לבקשה לאחר התייעצות עם המחלקה המשפטית, המסחרית וייעוץ חיצוני. הטענה הייתה, כי מו"מ משמעותי לאחר בחירת הספק, כפי שמתרחש בפועל בשיטת המו"מ התחרותי, מסלף את התחרות וכן יוצר קושי לממשלה לשאת ולתת בהצלחה כאשר אין מתח תחרותי. לפיכך הובאה שיטת הדיאלוג התחרותי. ייחודה של השיטה הוא בכך שהיא מחייבת התחלה וסיום פורמאליים של שלב הדיאלוג. שיטת הדיאלוג התחרותי, צפויה להיות יקרה יותר מאשר מו"מ רגיל, הן ללקוח והן לספק שכן יותר ספקים יהיו מעורבים בדיון על הפרטים ובהגשה של הצעות מפורטות. אולם, בהתאם למדיניות משרד האוצר הבריטי, לא תהיה השתתפות בהוצאות המכרז אלא במקרים מיוחדים. עבור ספקים שיזכו במכרז, ההוצאות משתוות להוצאות של מו"מ רגיל. הטענה היא כי הכנה מוקדמת ומפורטת, הכוללת מעורבות עם שוק הספקים היא הכרחית וכי השקעה בשלב זה, סביר שתניב תהליך רכש יותר אפקטיבי ובשקלול הכולל יותר תמורה עבור הכסף- וכן תפחית חלק מן הסיכונים הקשורים ברכש מורכב. יתרונו של הדיאלוג התחרותי הוא בכך שהוא משמר את המתח-התחרותי במהלך המו"מ ומאפשר למועמדים להבין ביתר בהירות מה מצופה מהם בתהליך. הרעיון הוא, כי המשרד הממשלתי יגדיר את ה"מה"- את הדרישות המפורטות 6 כאשר במהלך הדיאלוג המועמדים יספקו את ה"איך". שימוש בפרוצדורה השיטה, משמשת לחוזים מורכבים בהם על הממשלה לדון עם הספקים על כל צדדי החוזה המוצע. שימוש בשיטה זו, יעשה רק במקרים של חוזים מורכבים במיוחד, כאשר הלקוח אינו מסוגל להגדיר את האמצעים הטכניים להשגת המטרות, המורכבות המשפטית והפיננסית היא גדולה (קשור יותר לחוזים ארוכי טווח של בנייה) ולא ניתן להעניק את החוזה בפרוצדורה פתוחה/ מוגבלת מתוך המדריך הבריטי לדיאלוג תחרותי, 2008 ' הערה (1 :Competitive Dialogue Procedure, וכן מדריך שלמשרדהמסחרהבריטי (OGC) המסמך המלא מטעם האיחוד האירופי: 6 מתוךמסמך של "4P", לה מיזם משותף עם הממשלה הבריטית: Competitive Dialogue - A new chapter in procuring large and complex projects 20large%20and%20complex%20projects.pdf

103 בIT, פעמים רבות המשרד מחפש את הפתרון שיתאים ביותר לצרכיו. לכן, לעיתים קרובות המשרד לא יכול להגדיר את האמצעים הטכניים להשגת מטרותיו ולפיכך השימוש בדיאלוג תחרותי עשוי להתאים. האיחוד האירופי ממליץ על שיטה זו עבור פרויקטים מורכבים של -IT במקום שיטת המו"מ. מבנה התהליך פרויקטים מורכבים הינם בעלי מאפיינים מיוחדים לפיכך על המשרד להתאים את תהליך הרכש כך שיתאים למטרותיו. תרשים השלבים: הערכה תכנון תהליך הדיאלוג. בחירת פרוצדורה והצדקתה, לפני הדיאלוג: תכנון והכנות ראשוניות- מוקדמת של מספר המתחרים ושל מספר שלבי הסינון, הערכת כדאיות הפרויקט במונחים של תמורה לכסף. שלב זה חשוב במיוחד בתהליך של דיאלוג תחרותי. פרסום המכרז לרשימה המקוצרת- החלטה על הרשימה לפי בדיקות מקדימות. כאן יש דגש יש להעריך האם תתקיים בהכנה המוקדמת, וקריטריונים להערכה- על הכנה מוקדמת תחרות אפקטיבית ע"י בחינה של מספר המתחרים, חוזקם, מידת העניין שלהם בפרויקט ורצונם להשתתף בתהליך הרכש. בחירת המועמדים והכנה לשלב הדיאלוג- המועמדים שיבחרו ישתתפו בשלב הדיאלוג. יש המגדיר היטב את מדובר במסמך דרישות מפורט ביותר, להכין את מסמך הדרישות. ההיקפים. הדיאלוג: פתיחת שלב הדיאלוג עם שליחה של הזמנה להשתתף הזמנה להשתתף בדיאלוג- למועמדים מן הרשימה המקוצרת. ההזמנה תפרט שוב את דרישות המשרד ותפרט את שלבי הדיאלוג, את הנושאים הנתונים לדיון ואת הקריטריונים להמשך תהליך הרכש. ניהול דיאלוג לפיתוח פיתרונות- המשרד יכול לדון בכל הצדדים של החוזה עם המשתתפים יינתן יחס ומידע שווה לכל המועמדים ומשרד לא יעביר מידע לגבי במהלך שלב זה. ניתן להפחית ממועמד אחד למשנהו אלא בהסכמת אותו המועמד. הפתרונות שהוצעו, מרשימת המועמדים גם בשלב זה, על ידי השוואה לקריטריונים שהוכרזו מראש- יש לדאוג להכניס סעיף כזה במכרז. סגירת הדיאלוג- כאשר המשרד מזהה פיתרון או פתרונות אשר עונים על צרכיו, אם יש צורך- לאחר השוואה ביניהם. המועמדים יגישו הצעה שלמה ומתומחרת עם סגירת הדיאלוג. בניגוד לשלב ה- Best & Final בפרוצדורת המו"מ, כאן לא יתקבל מו"מ מחודש על ההצעה. אחרי הדיאלוג: מכרז סופי- הערכת ההצעות. דיון אחרי הדיאלוג- הבהרות אחרונות. ללא התאמה משמעותית של ההצעות, לא יעשו שינויים ודיונים בנושאים עקרוניים כך שהתחרות לא תסולף. על מנת להתמודד עם שינויים 103

104 בלתי-נמנעים לאחר חתימת החוזה, מומלץ להגדיר מספר קטגוריות רחבות לשינויים פוטנציאליים ולתאר כיצד תעשה ההתמודדות אם יקרו. בחירת הספק המועדף- הבהרת המחויבויות וסגירת החוזה. 7 יתרונות וחסרונות בשיטת הדיאלוג התחרותי יתרונות: הדיון לגבי הפרטים של המכרז יעשה בשלב הדיאלוג, אז יש לממשלה יותר כוח שכן יש יותר מתח תחרותי. כך, תתקבל יותר תמורה לכסף. סגירת הדיאלוג וחוסר האפשרות להמשיך ולנהל מו"מ לאחר בחירת ההצעה הזוכה, מונעים חריגה בהיקפים. ישנה גמישות בתהליך לדון בכל האלמנטים של הפיתרון כך שניתן להתאים את הדרישות ולהבהירן תוך כדי שלב הדיאלוג. הבנה טובה יותר של הספקים את הדרישות עשויה להביא לציוני-איכות גבוהים יותר. הכרת פתרונות הספקים כבר בשלב מוקדם מקנה יתר ביטחון ללקוח ומאפשרת בחינה של מידת הריאליות של האומדן. להיות החדשנות עשויה הגמישות של שלב הדיאלוג עשויה לתרום לחשיבה חדשנית. אטרקטיבית עבור הספקים שכן הם ירוויחו ממנה גם כן. הספקים מבססים את הפיתרונות שהם מציעים על תחום ההתמחות שלהם, מה שעשוי לסייע להצלחת הפרויקט. השיטה מאפשרת לסעיפי החוזה, מיקום הסיכונים והמבנה הפיננסי להיות מותאמים למצב הספציפי. כך, מתאפשר גם מיקום סיכונים מדיוק יותר. המשרד יאלץ להשקיע יותר בפיתוח אלמנטים אסטרטגיים של הפרויקט כגון קריטריונים לזכייה. חסרונות: עלויות גבוהות במיוחד: בשל הצורך להשקיע זמן ועבודה בתהליך, הן מצד הלקוח והן מצד הספקים. גורם נוסף העשוי להשפיע על העלויות ועל משך הפרויקט הוא הסבירות לתביעות משפטיות לאחר ההחלטה על הזוכה. ניתן לומר שהסיכוי לתביעות משפטיות הוא יחסית גדול שכן עלויות התביעה הן נמוכות יחסית להשקעה שהשקיע הספק בשלב הדיאלוג והרווח בניצחון במשפט עשוי להיות גדול. מתח בין חובת השקיפות לבין חובת השמירה על סודיות המידע של החברות המשתתפות (לא לחשוף את הפתרונות שנתנו). כמו כן, השמירה על הסודיות אינה מאפשרת פיתרונות משולבים ממספר חברות והדבר פוגע בחדשנות. מעבר לכך ישנו חשש מתמיד של החברות כי המידע שנמסר בסופו של דבר כן יתגלה ולא ניתן להבטיח כל זליגה של מידע באופן חוקי. 7 (2008) Hillig Hoezen and ר' הערה 2. וכן מתוךמסמך של חברת "4P", לה מיזם משותף עם הממשלה הבריטית, ר' הערה

105 ההשקעה הכספית מובילה להשתתפות של הספקים הגדולים בלבד, מה שפוגע בספקים הקטנים ובתחרותיות. קיימת הצעה לסייע כספים למתמודדים, אולם הדבר אינו עולה בקנה אחד עם המדיניות במקרה של הבריטים. קושי בהערכת המועמדים: קושי לקבוע מראש קריטריונים מהימנים להערכה. ניתן לקבוע קריטריונים מסוימים במכרז אך, עשויים להתגבש פתרונות במהלך הדיאלוג שיעמידו קריטריונים מהימנים יותר להערכה, כאלה אשר מתאימים יותר לצרכי הפרויקט. 8 פיתרון משותף פרוצדורת רכש חדשה יחסית נוספת, היא הפרוצדורה הקנדית של "פיתרון משותף" ) Solution Joint.(Procurement- JSP פרוצדורה זו, נועדה לפתור בעיות עסקיות מורכבות, כאשר אין "פיתרון מוכן". התהליך הוא רב-שלבי, דורש שיתוף פעולה ומבקש להשתמש במגזר הפרטי כדי לעצב מגוון רחב יותר של פתרונות. הפתרונות בדרך כלל הינם רחבי-היקף וארוכי טווח. נכון לשנת 2008, פרובינציית קולומביה הבריטית Columbia) (British שבקנדה, חתמה על חוזים בשיטת הפיתרון המשותף, בשווי כולל של יותר מ 1.6 מליון דולר. תרשים התהליך א'- הערכה האם סוג הבעיה מתאים לתהליך הפיתרון המשותף. ב'- הכנת RFP עם קריטריונים להערכה. שלב 1- בחירת ארבעה ספקים בהתבסס על יכולות ומחויבות. צמצום הרשימה ל 2 ספקים בלבד, בהתבסס גם על ההצגה של הקונספט. שלב 2- פיתוח מסגרת לפיתרון משותף, באופן איטרטיבי (עם כל ספק באופן עצמאי). בחירת הספק המוצלח למו"מ. שלב 3- ביצוע ניתוח סיכונים קפדני, לתיקוף של הנחות, תהליכים ארגוניים, כוח אדם, נתוני מחירים וכו'. שלב 4- מו"מ על מבנה העסקה, ניהול ותוכניות ההטמעה. סיום החוזה וחתימה. תהליך זה דורש דרגה גבוהה של גמישות ותקשורת. מדובר בתהליך שעלותו גבוהה יותר מאשר הפרוצדורות הרגילות. 8 מתוך: דו"ח של משרד החשב הכללי של קולומביה הבריטית, קנדה: An Audit of Joint Solution and the Revenue Management Project, 2008/2009 report 1. April 2008 Procurement 105

106 היבטים שונים במכרז משך התהליך- מההחלטה על מיקור חוץ ועד חתימת החוזה, פרויקטים של IT דוגמא שנלקחה מחברה שהוציאה למיקור חוץ 2 9 פרויקטים שונים החל מהרעיון להוציא למיקור חוץ ועד ההחלטה הרשמית החל מההחלטה הרשמית ועד תחילת חיפוש הספק מתחילת חיפוש הספק ועד בחירתו מבחירת הספק ועד תחילת העבודה על החוזה מתחילת העבודה על החוזה ועד חתימתו מחתימת החוזה ועד תחילת הביצוע סך הכל חוזה של 2.5 מליון $ 8 חודשים מייד 3 חודשים מייד 6 חודשים חודש 18 חודשים חוזה של 500 מליון $ 5 חודשים חודש 6 חודשים מייד 2 חודשים חודש 15 חודשים 10 עלויות המכרז (בתהליך מו"מ או דיאלוג תחרותי) הפחתת עלויות המכרז הינה אינטרס של הממשלה, הן משום הרצון לעודד את הספקים לגשת והן, כיוון שעלויות המכרז מגולמות בסופו של דבר גם בתמחור החוזה. לפיכך, יש לנהל היטב את עלויות המכרז כך שיהיו מינימאליות. לשם כך מומלץ לשים לב לנקודות הבאות: מתן מידע למועמדים בשלב מוקדם ובפורמט הראוי העמדת התנאים בשלב מוקדם קביעת לו"ז צפוף אך ריאלי והקפדה עליו וידוא כי תהליך הרכש נעשה באופן אפקטיבי ויעיל וידוא כי לצוות הרכש יש היכולות המספיקות; הכנה מראש של נייר עמדה של הלקוח לגבי כל תחומי המו"מ/הדיאלוג כך שלמועמדים יהיה זמן מספק לניתוח ופיתוח של תגובתם וידוא כי תהליכי האישור נעשים בשלב הנכון ובמסגרת לוח הזמנים באופן עקרוני, משרד האוצר הבריטי מתנגד להשתתפות בהוצאות הספקים על המכרז הדבר עשוי להיות מוצדק רק כאשר ישנה דאגה לגיטימית לגבי היכולת ליצור מתח-תחרותי, ובמקרים כאלה יש לבחון כל מקרה לגופו. Barthelemy, J. (2001). The hidden costs of IT outsourcing, MIT Sloan Management Review, 42(3), מתוך מדריך של משרד המסחר הבריטי -(OGC).Competitive Dialogue in 2008 ר' הערה

107 השתתפות הספקים במכרז על המשרד הממשלתי להעריך את פוטנציאל שוק הספקים האם סביר כי יספק תחרות אמיתית. לשם כך מומלץ לבצע חקר שוק וכנס ספקים- בו יוסבר הפרויקט לספקים פוטנציאלים על מנת לעורר עניין והשתתפות. כחלק משלב התכנון לקראת הדיאלוג/מו"מ, על המשרד להקשיב ולענות לדאגות שמעלים הספקים (למשל- במקרה של דיאלוג תחרותי ישנו קושי עם נושא הקניין הרוחני, שכן ישנו דיון מפורט בפתרונות לפני סגירת החוזה; קושי עם לוחות הזמנים וכד'). במידה וישנו ספק רציני לגבי מידת העניין של הספקים בפרויקט, מומלץ כי המשרד ישקול לדחות את התחלתו של תהליך הרכש. יתכן ויהיה צורך לשנות את הפרמטרים של הפרויקט בכדי לעשותו יותר אטרקטיבי, להפחית חסמי- כניסה או לנקוט בפעולות ממריצות אחרות. שיקולים לגבי מספר המשתתפים- יש לשים לב, כי בזימון של מספר קטן מדיי של ספקים להציע פתרונות, קיים סיכון של התעלמות מספקים שיכלו להציג פתרונות חדשניים ולהגביר את התחרותיות. מאידך, זימון של מספר רב מדיי של ספקים, עלול לגרום לספקים לנשור מן התחרות עקב תפיסת סיכוייהם לזכות כנמוכים. כמו כן, תהליך של דיאלוג תחרותי/מו"מ עם מספר רב של ספקים עשוי לפגוע בעלויות ובלוחות הזמנים ולפיכך יש לצמצם את מספרם- אך יש לעשות זאת בזהירות. במידה ולמשרד יש ניסיון מספיק עם שוק הפרויקט, אשר עליו ניתן לבסס את שיקול הדעת- מספר קטן יותר של משתתפים עשוי להספיק ליצירת תחרות. בשוק לא מוכר או מתפתח ייתכן ועדיף יותר משתתפים שיספקו תחרות. על מנת להבטיח את התחרותיות, בשיטת הדיאלוג/המו"מ יש להקפיד על מינימום של 3 ספקים המתאימים להתמודד על המכרז בשלב המו"מ. בפרוצדורה המוגבלת, ישנו מינימום של 5 ספקים 11 שיוזמנו למכרז. בשלב הגשת ההצעות הסופיות, בדיאלוג תחרותי, יהיו לפחות שני מועמדים ראויים סופיים- במידה ולא, על המשרד לשקול האם לקבל את ההצעות למכרז. התמודדות עם כשל שוק כשל שוק או העדר תחרות, מתרחש כאשר אין מתמודדים או שקיים רק מועמד אחד במכרז, או- כאשר ישנם שני מועמדים אך רק אחד מהם נחשב ראוי. במצב כזה, העדר התחרות פוגע בתמורה עבור הכסף, לפיכך על המשרד לערוך בדיקה כיצד כדאי לנהוג. אם נראה כי אין אפשרות להבטיח את התמורה לכסף יש לעצור את הליך הרכש. מומלץ לבדוק את הסיבה לכשל השוק: במידה והכשל נובע מבעיה מערכתית בשוק פרוצדורת רכש שונה לא תפתור את הבעיה ועל המשרד לחשוב כיצד הוא מגן על האינטרסים שלו בהמשך התהליך. במידה והכשל אינו מערכתי, ייתכן והעדר התחרות נובע מ: דאגה בשוק הספקים הפוטנציאלי לגבי מידת המחויבות של המשרד לפרויקט; או דאגה לגבי המיומנויות או הניסיון של צוות הפרויקט. 11 תקנות החוזים הציבוריים, בריטניה- The Public Contracts Regulations

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

109 מערכת היחסים עם הספקים חוקרים טוענים מזה זמן רב, כי עסקאות מושפעות מאוד ממערכות יחסים. מנהלים במגזר הציבורי 12 והפרטי מסכימים כי חלק ניכר מהצלחת הפרויקט תלוי באישיות של המעורבים ובפיתוח יחסי עבודה חזקים בהם שני הצדדים חותרים למטרות משותפות. מערכות יחסים מפחיתות את 13 ההסתמכות על החוזה עקב אמון שנוצר בין הצדדים. מאידך, חוזים אפקטיביים מבנים את מערכת 14 היחסים שבין הספק והלקוח, באופן המשתלם לשניהם. לפיכך, חשוב לוודא לאורך כל מהלך הפרויקט שהמטרות העסקיות הן של הלקוח והן של הספק- מושגות. המיקוד צריך להיות האם הלקוח והספקים משיגים את התוצאות להם ציפו כאשר חתמו על החוזה. אם התוצאות עומדות בקו 15 אחד עם הציפיות, למערכת היחסים יש סיכוי טוב בהרבה להישאר בריאה. מערכת יחסים לא טובה, מעבר להשפעתה השלילית על קידום הפרויקט, גם עשויה להתדרדר לצורך בהחלפת ספק- תהליך שעלותו גבוהה. ברחבי העולם, מודעים לחשיבות המעורבות ושיתוף הפעולה של הספקים ומצאו דרכים שונות להדק את היחסים עימם: רמת המאקרו- יחסי הממשלה ותעשיית הIT 16 ארה"ב- הוקמה מועצה (GITEC),The Government Information Technology Executive Council המורכבת ממנהלים בכירים של IT בממשלה ונועדה לתמוך במסירה של מערכות מידע איכותיות ואפקטיביות, ללקוחות. המועצה מונתה ביוני 1966 מטעם הבית הלבן, על מנת להוות פורום בו מנהלים בכירים מן הממשל ומן התעשייה יוכלו לשתף רעיונות, אתגרים והצלחות. המועצה יזמה מיזמים רבים אשר נועדו להשפיע על הכיוון והעתיד של תעשיית הIT וביניהם- סמינרים למנהלים, קבוצות עבודה, כנסים וועדות. אוסטרליה- במדינת קווינסלנד, הוקמה בינואר 2005 קבוצת עבודה משותפת לנציגי הממשלה ונציגי 17 תעשיית הIT (ICT Industry Workgroup). קבוצה זו, תחת איגוד תעשיית הIT האוסטרלית,(AIIA) נועדה להבטיח את שיתוף הפעולה בין ארגוני ה ICT השונים, כך שייווצר קול אחיד מול הממשלה, המאפשר תקשורת טובה יותר עימה. הקבוצה, יצרה פורום בו היא דנה בנושאים שונים הקשורים מתוך: מעגל החיים של רכש,IT בריטניה. שער 5- Kalnins, A. &Mayer, J.M. (2004). Relationships and Hybrid Contracts: An analysis of contract choice in information technology. Journal of Law Economics & Organization, 20 (1), Aubert, B. Houde, J.F. Patry, M. Rivard, S. (2003). Characteristics of IT Outsourcing Contracts, Proceedings of the 36th Hawaii International Conference on System Sciences. Maurer,W. Scardino, L. Doering, K. Ridder, F. (2008). Pricing Model Definitions, Benefits and Risks for IT Services and Outsourcing Contracts. Gartner website:

110 ליחסי תעשיית ה IT והממשלה ואף מגבשת מפעם לפעם 18 דו"חות והמלצות. קיים אתר בנוסף, אינטרנט המביא עדכונים שוטפים לגבי מעשיה של הקבוצה. 19 בריטניה- איגוד תעשיית הטכנולוגיה הבריטית,(Intellect) מציע מספר שירותים להקלה על האינטראקציה בין התעשייה והממשלה, וייעוץ צמוד. הרעיון של השירותים שמציע האיגוד, הוא לאפשר למשרדי הממשלה לקבל פידבק מן התעשייה עוד בשלב הרעיון הראשוני, כך שיתאפשר ניתוח מקדים של עלויות, סיכונים ואפשרויות יישום. האיגוד, יצר פורום של בכירי.IT פורום זה, מורכב ממנהלים בכירים במשרד המסחר הממשלתי (OGC) ומה Intellect 20 ועוסק במספר תחומים. ביניהם קוד רכישה ממשלתי- הקוד מעודד שיתוף פעולה פתוח, בין הממשלה, הספקים וספקי המשנה, מתוך תפיסה שכך הפרויקט יצליח יותר. הקוד מציע מספר צעדים בהם על הצדדים לנקוט כגון: הגינות, פתיחות ומקצועיות. גיבוש המלצות כיצד לקבל תמורה לכסף מעבר לרצון לקבל את "העלות הנמוכה ביותר" (למשל- לבדוק את עברו של הספק, שקילת גורמים לא-כלכליים כגון רמת שירות וכו'). בכך, 21 נעשה ניסיון להגביר את האפקטיביות של המסירה והרכש. קנדה- איגוד ארגוני הIT הקנדיים,(ITAC) הקים ועדה של מנהלים בכירים מן התעשייה אשר ארגוניהם מתרכזים במתן שירותים לממשלה. הועדה מתכנסת בין 6 ל 8 פעמים בשנה, על מנת לפקח, להעריך ולייעץ לגבי מדיניות ופרקטיקות של רכש. גורמים ממשלתיים משתתפים בפגישות באופן קבוע ומדווחים בכל פגישה על ההתקדמות שנעשתה ביוזמות רכש של.IT הועדה מחולקת לתתי-ועדות המתמקדות בנושאים שונים כגון טלקום, תנאי חוזים ושירותים מקצועיים. תתי הועדות 22 אחראיות על סקירת הנושאים והצגת ההמלצות לממשלה. רמת המיקרו- יחסי המשרד והספק במהלך הפרויקט 23 יצירת מצב של Win- Win (ארה"ב) יצירת מצב של Win- Win בין הממשלה והספק היא אולי הגורם המשפיע ביותר על הבאה ליישום מוצלח של אסטרטגיית מיקור-החוץ. גמישות, היא המפתח ליצירת מצב של.Win- Win המסמכים החוזיים, צריכים להבטיח כי גם הממשלה וגם הספק יוכלו לחיות איתם. דבר זה נכון במיוחד בעולם דוגמא למספר דוחות כאלה, ניתן למצוא באתר איגוד תעשיית הIT האוסטרלית (AIIA) מתוך: דו"ח שהוגש למשרד למדע וטכנולוגיה הבריטי, מתוך: דו"ח מטעם הממשל האוסטרלי, אוגוסט :2008 of Review of the australian government s use and communication technology Review/index.html 22 מתוך: אתר -ITAC 23 מתוך: מסמך של משרד מערכות המידע האמריקאי, TECHNOLOGY, 1998 :OUTSOURCING INFORMATION

111 הIT, שכן הסבירות לשינויים בפרויקט במהלך תקופת ההתקשרות, היא גבוהה מאוד ולא ניתן יהיה להתעקש שלא לשנות דבר מן החוזה. המפתח לגמישות הוא התקשורת. על הלקוח והספק להגיע להסכמה שדיאלוג תמידי הוא הנורמה ולא ייתכן מצב בו תופסים את החוזה כקפוא. תקשורת טובה בין הגורמים השונים בפרויקט, יכולה להסתייע בקבוצות עבודה (בהם חברים בעלי תפקידים משני הצדדים), אשר יפגשו על בסיס קבוע. קבוצות אלה, יזהו ויפתרו בעיות, יציעו רעיונות חדשים בתחום הניהול והטכנולוגיה וישפרו תהליכים. דרך נוספת, לשמירה על מצב של Win- Win היא לתגמל ספקים אשר הביאו לחיסכון בפרויקט (למשל- ע"י טכנולוגיה חדשה, שינוי לטובה בתהליכים שדרשו זמן רב, ניהול סיכונים נכון וכו'). התגמול יעוגן בחוזה וכמובן יש לדעת כיצד לנהל אותו. השיטה היותר חדשה לשמירה על מצב של Win- Win היא הסכם לחלוקת החיסכון. בהסכם כזה, הממשלה נותנת לספק חלק מן החיסכון שנוצר כתוצאה מהשקעה שהשקיע הספק (למשל- יצר חלק מסוים מן הפרויקט על חשבונו, שניתן למדוד בו כמה משאבים נחסכו) או שיפורים שיישם. במידה ומדובר במערכת הפועלת לאורך זמן, יקבל הספק חלקים מן הרווחים למשך תקופת זמן קצובה. 24 המלצות הבריטים למנגנוני סיוע ליחסים שבין הספקים והממשלה : יש לפתח מנגנונים אשר יסייעו לעידוד יחסי שיתוף הפעולה בין הספקים והממשלה. כגון: תהליכי שינוי מוגדרים ומתועדים עליהם הוסכם במשותף. בתוך כך, יצירת "מסלול מהיר" לזיהוי שינויים משמעותיים אליהם יש צורך בהתייחסות ובאישור של ההנהלה הבכירה. במהלך המכרז יש לבחון ולקחת בחשבון האם לספק רקורד של פתיחות. שיתוף הדדי בתוכניות. יש להבטיח כי המחויבות החוזית הנוגעת לצוות הספציפי מכובדת עם התחלת הפרויקט. על האחראי/ת הבכיר/ה של הפרויקט לוודא כי לא נעשים שינויים באנשי המפתח של הפרויקט ללא הסכמת הצד השני. החלטה על מטרות משותפות על ידי ההנהלות הבכירות והבנה שלהן. יצירת לוח המפרט את העקרונות עליהם הוסכם, שלא במסגרת חוזית ואשר עליו יחתמו המנהלים הבכירים של שני הצדדים- כגון, "הצהרת כוונות משותפת"-,JSI שתוצג להלן. 25 הצהרת כוונות משותפת על רקע היות פרויקטי הIT הממשלתיים, מאופיינים בסביבה של מדיניות משתנה וארועים חיצוניים בעלי השפעה רבה, הבריטים, מציעים לחתום על הסכם "הצהרת כוונות משותפת" ) Statement Joint מתוך מסמך שהוגש לקבינט הבריטי, Action: 2000 Successful IT Modernising Government in 25 מסמך של משרד המסחר הבריטי,(OGC) ינואר :2009 Statement Programmes and Project Delivery Joint of Intent

112 (JSI).(of Intent זאת, מתוך כוונה הן לתמוך בפרקטיקות הקיימות בין הספק והממשלה והן להציע מנגנון פחות עמום למדידת הצלחה של פרויקט, אשר מכיר באופי הייחודי של פרויקטים מסוג זה. ה- JSI הינו הסכם הספציפי לכל פרויקט ופרויקט, הנחתם על ידי המנהל/ת הבכיר/ה בצד של הממשלה ובצד הספק. ההסכם אינו מחליף את החוזה או מחייב משפטית, אלא נועד לגלם את הציפיות מן הפרויקט. הסכם ה-,JSI מניע דיאלוג והבנה הדדית בין המשרד הממשלתי והספק על ידי תהליך של חקר הפרויקט והבנה והסכמה לגביו. זהו המקום להגדיר את הקריטריונים להצלחה של הפרויקט. מומלץ כי ההסכם יוצג בקווים כללים כבר בכנס הספקים וכי טיוטה של ההסכם תוגש עוד לפני הענקת החוזה. ההסכם נוגע בדברים במונחים של מדיניות ותוצאות ארגוניות ולא דן באופן מפורט באספקטים של הIT. כך, מושם דגש רב יותר על הגעה לתוצאות הארגוניות הדרושות (במקום התמקדות צרה מדיי בפרויקט הIT בלבד). על התוצאות הארגונית הדרושות להיות מצוינות גם בחוזה. עקרונות הJSI מדיניות המשרד- פעמים רבות פרויקטים נועדו ליישם מדיניות חדשה של הממשלה. במידה ולא, יש לציין אילו פעולות אופרטיביות נועד הפרויקט ליעל ולהפוך ליותר אפקטיביות. כמו כן, מומלץ לציין את השינויים הארגוניים הצפויים- שרטוט כללי של הJSI עשוי להביא לזיהוי מוקדם של מתחים וקונפליקטים פוטנציאלים. כמו כן, מומלצת הצגת קווי המתאר (אם ישנו רצון שלא לחשוף הכל) של תיק הפרויקט. הדבר עשוי לקדם הבנה. כדאי גם לשים לב לקונטקסט של המערכות והפרויקטים הקיימים. הצהרת מחויבות מצד ההנהלה הבכירה של שני הצדדים. דיאלוג פתוח והתנהגות חיובית. שימוש ב"פרקטיקה הטובה ביותר"- מדריכים לניהול פרויקטים של IT שהוצאו ע"י הממשלה מתוך ניסיון שהצטבר מפרויקטים רבים. יש לעקוב כי הצוות משתמש בפרקטיקות אלה לאורך הפרויקט. התמקדות בתוצאות יש להגדיר היטב מה הן התוצאות הרצויות לארגון. חשוב שגם הספק יבין מה הן. כאן יוגדרו גם הפרמטרים העיקריים של הזמן, העלות והאיכות. מול סעיף זה, ניתן להגדיר את הקריטריונים להצלחה, ורק על פיהם יוגדר הפרויקט כמוצלח/לא. ניהול שינויים. כאשר יש צורך בשינויים המשפיעים על מדדי ההצלחה, הדבר יעשה באופן מובנה ובאישור ההנהלה הבכירה. ה JSI אינו מסמך המתעדכן עם השינויים, אלא הוא סטנדרט לפיו יש להעריך את השינויים. 112

113 קשיים העולים מצד הספקים 26 אוסטרליה עלות הגשת ההצעות וההשתתפות במכרז גבוהה עבור הספקים. קבלת ההחלטות איטית בנושאים של הגדרת צרכים ארגוניים/עסקיים, הערכת הפתרונות הטכנולוגיים וסגירת החוזה. התנאים והתקנות של החוזה לעיתים קרובות מכבידים או שאינם מסחריים. נושאים של אחריות, בטחונות וקניין רוחני מכבידים על הספקים ולעיתים מסתכמים בהחלטה לא לגשת למכרז. האחריות בלתי-מוגבלת או שישנן מגבלות כה גבוהות עד כי הן כמו אחריות בלתי- מוגבלת; סעיפי בטחונות בסכומים גבוהים מאוד- ההגבלות כה חמורות עד שלעיתים אינן זמינות בשוק הביטוחים האוסטרלי; בנושא הקניין הרוחני, הממשלה לעיתים קרובות, דורשת את הזכויות כברירת מחדל. כיוון שפעמים רבות היא אינה מנצלת אחר כך את הזכויות הללו, הערך שהן יכלו ליצר לתעשיית הIT האוסטרלית אובד. טענה כי הממשלה מתמקדת יותר מדיי בדרישות ובתהליכים במקום בתוצאות, בניגוד למגמה בשוק הפרטי. פעמים רבות המשרדים מכתיבים את הדרישות באופן מוגזם ומפורט מדיי. השוק הפרטי נוטה לאפשר יותר גמישות בעיצוב הפתרונות, מה שמעודד יותר חדשנות מצד הספקים. הממשלה לעיתים קרובות בוחרת את הספק המציע את ההצעה הזולה ביותר העונה על הדרישות המינימליות, מה שאינו מספק תמורה אמיתית לכסף, לדעת הספקים. סקר שערך איגוד התעשייה הטכנולוגית האוסטרלי, בקרב 66 חברות (מתוכן- 79% חברות קטנות-בינוניות, המרוויחות פחות מ- 15 מליון דולר אוסטרלי לשנה), מדווח כי 40% מהן החליטו שלא להשתתף בשוק הממשלתי. הסיבות העיקריות היו: עלות ומורכבות תהליך המכרז בעיתיות התנאים והענישה הגדרות לא טובות של תוצאות וסיכונים כמו כן, טענו החברות כי מושג ה"שותפות" מובן ומבוצע טוב יותר במגזר הפרטי- כאשר גישה של "אנחנו והם" קיימת פחות מאשר בחוזים עם הממשלה. 26 דו"ח מטעם הממשל האוסטרלי, אוגוסט :2008 of Review of the australian government s use and communication technology Review/index.html 113

114 27 טענות שעלו מצד הספקים בישראל- סיכום חלק מן הטענות שעלו בקרב הספקים האוסטרלים, עלו גם בישראל, יחד עם טיעונים נוספים. כאן, נבקש לסכם את הטענות שעלו מצד הספקים, בהתבסס על שיחות שערכה הועדה עימם ועל חומרים שהועברו על ידם. קשיים תנאי חוזה משתנים- גם כאשר יש שימוש בנוהל מפת"ח עדיין יש תחושה כי החלק של התנאים בחוזה פרוץ, ואין אחידות בין המשרדים לגבי התנאים. על הספקים להקדיש משאבים רבים על מנת להתמודד עם כל חוזה ותנאיו. הימנעות מהתקשרות עם הממשלה- מעבר לתנאים הקשים בחוזה, שני גורמים נוספים מונעים ספקים מלגשת למכרזים. ראשית, הטענה היא כי בממשלה התשלום הוא נמוך. שנית, בממשלה יש פחות מנגנונים המסייעים לצאת ממצבים שהסתבכו ולכן מגיעים יותר לבית המשפט. הדבר קשור גם לנושא הבירוקרטיה הסבוכה בה נתקלים הספקים ואשר יוצרת אצלם לעיתים החלטה שלא להשתתף במכרז. אלמנט המחיר במכרז- האופן בו כיום משוקלל המחיר בתחרות על המכרז, נותן לו משקל רב מדיי. חברות המציעות הצעות איכותיות יותר מאחרות אינן מקבלות את העדיפות הראויה שכן הדבר אינו מקבל מספיק משקל בחישוב המחיר- יש לשקול את נוסחת המחיר המשמשת כיום את הממשלה. מדיניות חברה בינלאומית- החברות הבינלאומיות, חייבות לפעול על פי מדיניות חברת האם שנקבעת על פי סטנדרטים עולמיים ונוגעת בנושאים כגון: דיווחים חשבונאיים, עמידה בתנאים פיננסיים, גידור סיכונים, הנחיות משפטיות ועוד. בהתאם לכך, חברת הבת מבוקרת ומאושרת באופן שוטף והדוק בכל שלבי ההתקשרות. בתוך כך, אצל חלק מן החברות (למשל- (HP קיים גם עיקרון ההכרה בהכנסה, הקובע כי אין להכיר בהכנסה אפילו שולמה במלואה אלא עד שכל הסיכונים הכרוכים ביצירת אותה הכנסה, הוסרו וכי הכנסה זו אינה כפופה לכל סוג של השבה. פעמים רבות, בממשלה מוצגות דרישות סף פיננסיות, משפטיות ומקצועיות, המקשות על חברות גלובאליות להשתתף במכרזים. חסמים הקשורים לחשיפות כספיות- o אחריות הספק- אם כי משרדים רבים כבר אינם נוהגים כך, עדיין ישנם משרדים המבקשים להטיל אחריות בלתי מוגבלת על ספק או אחריות לנזקים לא-ישירים. הטלת אחריות כזו אינה עומדת ביחס סביר לתמורה החוזית. הטענה היא, כי מקובל בתחום להטיל על הספק אחריות לנזקים ישירים בלבד. כמו כן, מקובל להגביל את תקרת הפיצוי המצטברת. יש לאזן טוב יותר את מיקום הסיכונים. מעבר לכך, הנושאים המטרידים את הספקים בבואם לחתום על הסכמים עם הממשלה בנספח 9 ניתן למצוא מסמך שנכתב על ידי מר נועם קפלן מנהל מגזר ציבורי בHP ובו הוא מפרט את

115 טוענים הספקים כי תמיד קיימים פערים בצפיות ולא ניתן לדרוש מהספק לקחת אחריות על כל טעות. יש יותר מקום לגמישות. o דרישות לשיפוי- קושי עם הדרישה לשיפוי הספק מייד עם דרישה ראשונה בגין נזקים שהספק עשוי לחוב בהם. טענה כי לא ניתנת לספק מספיק אפשרות למצות את התהליכים לפני שיחויב. o פיצויים ללא תקרה בגין עיכובי לו"ז/ביצועים- לעיתים החוזים מטילים סנקציות גם כאשר לא מדובר באחריות הספק. כמו כן, לעיתים לא מצוינת תקרה עליונה לסך הפיצויים ולעיתים לא ניתנת לספקים התרעה ואפשרות לתקן את ההפרה. סיכון כזה משפיע על התמחור ללקוח. o זכות המדינה להפסיק את הפרויקט- מבקשים לקבוע מנגנון פיצוי סביר לספק, כאשר רק לעיתים המדינה מסכימה לפצות את הספק בגין הוצאות בפועל. הפסקה זמנית של הפרויקט ללא זמן מוגדר, מקשה על הספק ואינו מאפשרת לו להיערך לחידוש מתן השירותים עקב אי-הודאות. נושאים המשליכים על תזרים הפרויקט- o הפרדה בין חלקי החוזה- מבחינה חשבונאית, עדיף עבור הספקים ליצור הפרדה ברורה בין תקופת ההקמה לבין תקופת התחזוק/תפעול שכן יש לדבר משמעות מבחינת חישוב הסיכונים (שבתקופת ההקמה הם גדולים יותר מאשר בתקופת התחזוק/תפעול). o אבני דרך לתשלום- חשוב לקבוע כי אבן הדרך הושלמה וכי התשלום סופי ולא ניתן להשבה. מבקשים כי בפרויקטים של פיקס פרייס הנמשכים מעל לשנה יתקיים אירוע קבלה סופי הכולל תשלום, שכן תשלום רק עם אירוע הקבלה הסופי פוגע ברווחיות ובאטרקטיביות העסקה. o ערבויות- לעיתים ישנה דרישה להמצאת "ערבות מקדמה". זו דרישה אשר פוגעת אף היא בהכרה בהכנסה, והספקים מבקשים לבטלה. כמו כן, מבקשים הספקים לתת לספק התראה סבירה לתיקון הפרות לפני חילוט ערבויות. בקשה נוספת, היא להפריד בין הערבות הקשורה בביצוע הפרויקט לבין הערבות הקשורה במתן שירותים שוטפים. - Step-in clause o סעיף המחייב את הספק לשלם את עלותו של צד שלישי המפתח במקומו, במקרה והספק לא עמד במחויבותו החוזיות. קושי עם סעיף זה, שכן הכללתו פוגעת ביכולת ההכרה בהכנסה של החברה. זכויות קניין רוחני- הדרישה הרווחת כי ללקוח כל זכויות הקניין הרוחני, מקשה. מערכות המידע הקיימות בשוק הן לרוב גנריות או לפחות מבוססות על פלטפורמות וטכנולוגיות גנריות ותהליכים אשר חוזרים על עצמם כל הזמן. הלקוח נהנה מהניסיון והידע של הספק ואנשיו וככל שהלקוח יעמוד על כך להשאיר אצלו זכויות קניין הרוחני, כך ייאלץ הספק למדר יותר ויותר את אנשי הפיתוח, לכתוב כל פעם שורות קוד מחדש, ולוודא שלא עשה שימוש חוזר בשורות קוד אשר "שייכות" ללקוח אחר. יתרה מכך, ככל שמפתחים שורות קוד חדשות כל פעם, יש סיכונים כרוכים בדבר; לעומת זאת, קוד שנעשה בו כבר שימוש, נבחן והוכיח 115

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

117 פתרונות שהוצעו על ידי הספקים פתרון כולל- חוזה סטנדרטי ופורום משותף: על חלק ניכר מן הקשיים שהועלו, ניתן לענות, לדעת הספקים, על ידי יצירת חוזה סטנדרטי לשירותי מחשוב. ניתן ליצור גרסא אחת או אף 2-3 גרסאות, שיהוו חוזה סטנדרטי, אשר לו יצורף נספח המתאים להתקשרות הספציפית. את הנוסח יגבשו יחד פורום של הממשלה ונציגי הספקים. כך, ניתן יהיה לענות הן לצרכים של חברות בת של חברות זרות והן לצרכים של חברות ישראליות וכמובן גם לצרכי הלקוחות הממשלתיים. הפורום ידון במבנה החוזים ותנאיהם ברמה האסטרטגית וילווה בהמלצות לשינויי חקיקה. כמו כן, הקמה של פורום כזה, תאפשר לדון בבעיות שורשיות (לא ספציפיות) ברמה התרבותית- יצירת אמון בסיסי בין הממשלה והספקים- קושי אשר חזר ועלה שוב ושוב בדיונים. התייחסויות לנושאים שונים בממשלה חלוקת הפרויקטים לחלקים קטנים- מומלצת על ידי הספקים, כאמצעי להקטנת הסיכונים ולעבודה עם חוזי פיקס פרייס. השתתפות הממשלה בעלויות המכרז, לא תסייע אלא מוטב להשקיע את הכסף בהכנה למכרז- אפיונים טובים יותר ופירוק למכרזים קטנים. העצמת סמכויות המנמ"ר- ישנו פער בין סמכויות המנמ"ר לבין המקבילים לו במגזר העסקי. למנמ"ר היכולת לפשט דברים כך שלא יגיעו לבית המשפט ולכן עליו להיות בעל היכולת לקבל החלטות כדי לסייע לפרויקט שמסתבך. לפיכך, ממליצים ללמוד ולחקות את המנמ"ר מהמגזר העסקי גם בממשלה וכן להגדיר נהלים שיאפשרו לו יותר חופש פעולה בניהול הפרויקט. פתרונות לבעיות ספציפיות בחוזים חברות בינלאומיות: תשומת לב והתחשבות במדיניות והתקנות של החברות הגלובאליות, בדרישות הסף של המכרז. זאת, מתוך הכרה כי הסטנדרטים הפנימיים הינם חמורים ומדוקדקים כמו גם הביקורת מצד חברת האם. על הממשלה להכיר ולהבין טוב יותר את הסביבה העסקית בה פועלות החברות. פתרונות לחסמים הקשורים לחשיפות כספיות: הגבלת האחריות על הספק, יצירת תקרת פיצוי והצמדת גובה הפיצוי למדד הרלוונטי (למשל, XX% מסך התמורה של אבן דרך ספציפית) כמו כן, מבקשים ליצור נוהל של התרעה בדבר הפרה ואפשרות לתקן לפני הטלת הפיצוי. באשר לדרישות לשיפוי להודיע לספק על כל דרישה ותביעה על מנת שיוכל לנהל את ההגנה בפני התביעה. בנושא הפסקת הפרויקט, מבקשים הספקים לקבוע מנגנון פיצוי סביר עבורם, במקרה של הפסקת ההתקשרות על ידי המדינה. פתרונות לנושאים המשליכים על תזרים הפרויקט: יצירת אבני דרך לתשלום במקום תשלום רק עם אירוע הקבלה הסופי. כך, רווחיות הספקים תפגע פחות והעסקה תעשה יותר אטרקטיבית. בנוגע לערבויות- בקשה לבטל את הדרישה להמצאת "ערבות מקדמה" וכן לתת התראה מספקת לתיקון הפרות לפני חילוט ערבויות. בקשה נוספת, היא להפריד בין הערבות הקשורה בביצוע הפרויקט לבין הערבות הקשורה במתן שירותים שוטפים. בעניין 117

118 ה- step-in clause מציעים כי תקבע תקרת פיצויים הוגנת. לגבי תנאי התשלום, מבקשים הספקים לקבוע תנאי תשלום אחידים של שוטף +30 או לחלופין 60 ימים מיום החשבונית. קניין רוחני: הספקים מציעים להותיר את זכויות הקניין הרוחני בידי הספק, כך שיתאפשר ללקוח ליהנות מידע וניסיון שנצטברו אצל הספק ומפתחיו. הדבר יוזיל עלויות, יקצר מועדים ויקטין סיכונים. הכוונה היא שללקוח תהיה בעלות במערכת וזכות שימוש בלתי מוגבל בה וברכיבים שלה, לרבות בפיתוחים שנעשו, אך יחד עם זאת לאפשר לספק למכור את הפיתוחים לגורמים נוספים (כמובן שכל מידע או פיתוח קודם שהיה בבעלות הלקוח, יישארו בבעלות הלקוח בלבד). מדדים: צמצום השימוש במדדים סובייקטיביים כגון "שביעות רצון הלקוח" והגדרת מדדים ברורים הניתנים למדידה. יש לטייב את הגדרת מדד האיכות של הספק ולהגדיל את ההתייחסות למרכיב האיכות (כיום מקובל בתעשייה 70%). פתרון מחלוקות: מבקשים לכלול מנגנון ליישוב מחלוקות בהסכם בין הממשלה והספקים. מנגנון כזה עשוי לקבוע דיאלוג, בוררות או מנגנונים של אסקלציה פנימית במקרה של מחלוקת. 118

119 פרק 5 מקרי בוחן מקרי בוחן משווים 28,Inland Revenue בריטניה "To tax and to please, no more than to love and to be wise, is not given to men" Edmund Burke Inland Revenue הינו 29 המשרד הממונה על איסוף כספי המיסים בבריטניה. החל מאפריל 2005, משרד זה אוחד עם משרד המכס, ומתקרא מעתה (HMRC).HM Revenue & Customs באחריות המשרד, איסוף המיסים הישירים והעקיפים, נקודות זכאות וקצבאות ילדים. עד שנת 1994, החזיקה IR ביחידה פנימית למערכות מידע, אשר תפקדה מ 13 מרכזים שונים, ומנתה 2600 עובדים בתקציב של 250 מיליון ליש"ט לשנה. חזון המחשוב הבריטי,( IR ה מחלקת Inland Revenue (מעתה להלן- התעתדה להיות ספינת הדגל של חזון מחשוב השירותים הממשלתיים בבריטניה. חזון זה, של יצירת "ממשל אלקטרוני" הוגדר כ- "ניצול הכוח של טכנולוגיית המידע והתקשורת לשינוי הנגישות, האיכות והיעילות של השירותים הציבוריים ובכך לסייע בשיפור היחסים שבין האזרחים לגופים הציבוריים העובדים עבורם". בריטניה, ביקשה לראות עצמה כמובילה את נושא המחשוב-הממשלתי בעולם. מצד ראשי הממשל, היו מספר ציפיות ממערכות המידע. ראשית, ציפו כי היא תתאים לצרכי המשתמש- גם אם פחות לצרכיהם הארגוניים של נותני- השירותים. כמו כן, ציפו כי המערכת תהיה קלה לגישה, תאפשר גישה אליה גם לאחר שעות העבודה וכן כי ניתן יהיה להצביע דרכה על עניינים שונים ובכך להגביר את המעורבות הדמוקרטית של הציבור. 28 מתוך: דו"ח משרד המדע והטכנולוגיה הבריטי, 2003: דו"ח ביקורת של הNAO - המשרד הלאומי לביקורת, בריטניה, מרץ 2000: eds_strategic.aspx?alreadysearchfor=yes דו"ח 37 של הועדה לענייני דין וחשבון ציבורי, בריטניה, אפריל 2006: וכן- Beynon -Davies, P. (2005). Constructing electronic government: the case of the UK inland revenue. International Journal of Information Management. 25, 3 20 מתוך האתר הרשמי של הHMRC,

120 שותפות Inland Revenue וחברת EDS בפרויקט מערכת המס יציאה למכרז תחרותי, המבוסס על נתונים של המחלקה, מהשנים לאחר שEDS נבחרה, התאמת החוזה להתפתחויות מאז (מה שמייקר את ההצעה ב 203 מליון ליש"ט) חתימת חוזה ל 10 שנים עם EDS לפיתוח מערכת.IT 1900 אנשי צוות מערכות מידע של המחלקה עברו ל EDS וכן כל המחשבים ומערכות המידע. עד השלמתו ב 2004, החוזה אמור היה להיות שווה למעלה מ- 2 מיליארד ליש"ט. מכיוון שלא ניתן היה לצפות את הגודל, הטכנולוגיה או המאפיינים לטווח ארוך של המערכת, הוחלט שהחוזה לא יהיה מסוג פיקס פרייס כך שיוכל להשתנות בהתאם לשינויי מדיניות ואדמיניסטרציה. לפיכך, הוחלט על יצירת מנגנוני 30 תשלום שיווסתו את עלויות החוזה (התמריץ העיקרי- EDS תפחית את מחירי העבודה ב 35% במהלך שנות החוזה). דו"ח של הNAO (המשרד הלאומי לביקורת) טוען לתמונה חיובית, עם קשיים: תחת לוח זמנים עזרה למחלקה להביא לשינויים משמעותיים, EDS השותפות עם תובעני. גורמים חשובים בניהול המוצלח של השותפות, כוללים: מעורבות אקטיבית של מנהלים בכירים, הכרה בכך ששני הצדדים צריכים להבטיח רווחים, ניהול סיכונים אקטיבי ומחויבות לפתור קשיים ברוח חיובית ובונה. ועדה ברשות הפרלמנט (PAC) הביעה את הצורך ביצירת אמות-מידה (benchmarks) לאורך כל הדרך, לבחינת עלויות, יעילות ואפקטיביות של EDS לעומת חברות אחרות. באופן כללי, ניתפס מודל היחסים שבין EDS ו Inland Revenue כמודל חיובי. אולם, כפי שקורה עם התקשרויות בקנה מידה גדול, עשויים להיות קשיים בפרויקטים מסוימים. הקשיים העיקריים: קשיים ביישום הטכני של המערכת, וקשיים בהטמעת המערכת אצל בעלי העניין ובמיוחד אצל משלמי-המיסים הבריטים. המערכת חוותה בין השנים שורה של תקלות וביניהן: באפריל 2000 שירות עצמי אינטרנטי, הוגש בזמן ע"י צוות הפיתוח. אולם, המשרד ספג פרסום שלילי כאשר לקוחות רבים הביעו קושי עם השימוש במערכת ובמיוחד עם המערכת להגשת טפסי החזרי מס. לפיכך, בנובמבר IR 2000 מינתה ייעוץ חיצוני לבדיקת שירות זה. מן הייעוץ עלו מספר כישלונות במערכת. כתוצאה מכך, ביצעה IR תיקון כללי של המערכת לשירות עצמי אינטרנטי. כך, עד דצמבר 2001, אחוזי ההצלחה במילוי הטפסים להחזרי מס, עלה ל 70%. במאי 2002, החליטה IR להשהות את השירות, לאחר שנתגלתה פירצה בטיחותית במערכת. בסוף יוני 2002, הוחזרה המערכת לשימוש. באפריל 2003 נוצרה בעיה במערכת, שגרמה לקבלת מאות אלפי תלונות לגבי איחור בתשלומים. האחראי על התשלומים הודה ביוני כי המערכת אינה עובדת כפי שציפו. פירוט לגבי מודל התשלום, ניתן למצוא בנספח 2 בדו"ח הביקורת של הNAO - ר' הערה

121 ועדה מטעם האוצר טענה כי תפקוד המערכת היה לא מקובל ויצר לחץ הן על המערכת והן על הצוות. התקלות במערכת המשיכו גם במהלך ובשנת 2004 לשליש מן המשפחות הזכאיות להחזרי-מס, ניתן תשלום-יתר של בין 10 ל 14 אחוז, 2.2 מיליארד ליש"ט. בעיות בדואר-האלקטרוני: IR שאפה לבצע את התקשורת עם הלקוחות דרך הדואר האלקטרוני. אולם, עקב בעיות בטיחות, היא השהתה את אספקת שירות זה. בעיות יישום המערכת, העלו את שאלת העלות-תועלת של הפרויקט. למשל, במונחים של ההשקעה הנוכחית במערכת- העלות עבור המחלקה, להגשה אלקטרונית של החזרי-מס, לכל יחיד ב 2002, הייתה. 212 עלות אותה הפעולה כאשר היא מבוצעת על ידי האזרח דרך הדואר, הינה. 60 IR החזיקה מEDS אחראית לתקלות הרבות שנוצרו ודרשה פיצויים. הפסדי המשרד היו מהטעות שיצרה תשלומי-יתר שלא ניתן יהיה להשיב מן האזרחים (39 מיליון ליש"ט) וכן 65 מיליון ליש"ט עלויות ניהול ותיקון המערכת. נובמבר 2005, EDS מתחייבת לשלם מיליון ליש"ט, לרשות המיסים הבריטית עקב 31 התקלה במערכת החזרי המס מידת זוהה גורם מרכזי נוסף לכישלון המערכת והוא- לקחים עד שלב זה מעבר לכישלונות הטכניים של המערכת, השימוש במערכת. IR לא ביצעה סקירה של גורמים העשויים להשפיע על מידת השימוש במערכת אצל הלקוחות- כגון: גורמים אישיותיים וסוציו-אקונומיים שונים, עירור מודעות ציבורית, יצירת תחושה אצל המשתמשים כי הם מרוויחים מהשימוש באמצעים אלקטרוניים וכד'. כך, למשל, בעוד על פי כ 315,000 אנשים, הרי התכנון היו אמורים להשתמש במערכת לתיוק החזרי המס, ב , שרק 39,000 אכן עשו זאת. המצב בו לא הייתה אינטגרציה בין המערכות השונות, השפיע גם הוא על מידת השימוש במערכת, שכן הדבר אותת לציבור שהזנת נתונים לIR אינה משמעותית עבור הקשר עם המשרד. המכרז החדש, רקע לאחר שההתקשרות עם EDS נגמרה (כאשר יש הטוענים להצלחה ויש לכישלון) הוצא מכרז חדש לפיתוח מערכת IT עבור משרד המיסים והמכס הבריטי-.(HMRC) מעבר זה מספק אחד למשנהו, היה הראשון בקנה מידה שכזה, במגזר הציבורי. 31 עוד על הסכם הפיצויים ניתן למצוא ב: 32 הדו"ח ה 28 של הועדה לענייני דין וחשבון ציבורי, הפרלמנט הבריטי, מאי

122 חוזה - ASPIRE החברה שזכתה במכרז הייתה Capgemini והחוזה עימה נחתם ביולי החוזה החדש החליף את החוזה עם EDS לשירותי,IT וכן חוזה נוסף שהיה לIR עם חברת Fujitsu להקמת מערכת מידע של ביטוח לאומי. באפריל 2006, צורף החוזה של חברת Accenture שהיה מסוג,PFI ונחתם מול משרד המכס, לחוזה של המשרד המאוחד (הHMRC ). שני החוזים יחד, המכילים שלושה פרויקטים, זכו לשם Acquiring Strategic Partners for the ) ASPIRE.(Inland Revenue ההערכה היא, כי חוזה ה ASPIRE יגיע עד ל 8.5 מיליארד ליש"ט, וזאת מעבר לחוזה הראשוני ל 10 שנים. תהליך המכרז HMRC החליטה להחליף את החוזה הקודם (עם EDS ו-,(Accenture בשותפות אסטרטגית עם ספק אחד לו תהיה אחריות כללית על כל שירותי הIT. עלויות המכרז למשרד- תמיכה בעלויות המכרז- על מנת להגביר את התחרות (לאחר שמשרד המסחר העריך שחברות עלולות להירתע מלגשת למכרז), המשרד הלך לקראת הספקים ועל מנת להפחית את העלויות שלהם מימן תמיכה בIT, כך שהספקים יוכלו להציג את יכולותיהם- זאת, באופן חריג מבחינת נהלי הבריטים במכרזים. 7.7 מיליון ליש"ט הוצאו למימון העלויות והלמידה של המשתתפים במכרז. בנוסף, המשרד נתן גם 0.9 מיליון ליש"ט בתמריצים. המשרד הצדיק את המימון בטענה שהצגת היכולת תניב גם היא תוצרים בהם ניתן יהיה להשתמש. אולם בסופו של דבר, המשרד לא השתמש בתוצרים אלה ולא בדק את רווחיותם. הועדה מצאה כי סיוע שכזה, מעודד את החברות לגשת למכרז וכן מפחית את מחיר ההצעה, שכן עלויות אלה היו משתקפות בה לולא ההשתתפות של המשרד. תמיכה בעלויות המעבר- בנוסף, המשרד החליט לממן בעצמו את עלויות המעבר בין הספקים, כך שבהצעה המוגשת על ידי הספקים לא תיכלל עלות שכזו. בכך, עודד המשרד ספקים נוספים להשתתף במכרז ושידר שאיננו תומך בספק הנוכחי (EDS) שכן עלויות ההעברה, עשויות היו לחסום כל תחרות אפשרית מצד ספקים אחרים. הבחירה- 2 חברות עלו לשלב האחרון של המכרז. ההצעה של Capgemini ו- Fujitsu הייתה גבוהה ב 32 מיליון ליש"ט מזו של EDS עם.Accenture שתי ההצעות היו נמוכות ב 21% ממודל העלויות הראשוני של המשרד, אך זאת לאחר שההצעות והמודל השתנו במהלך המו"מ, שבו השתנו גם הדרישות. המשרד מצא, כי ההצעה של Capgemini התאימה יותר לצרכי הIT שלו, והדרישות המשתנות וכי האיכות שלו הצדיקה לחלוטין את העלות הגבוהה יותר. סיכום תהליך המעבר לספק חדש המכרז התבסס על דרישות הIT של המשרד ב החוזה גדל מ 2.8 מיליארד ליש"ט ל- 8.5 מיליארד ליש"ט מכיוון שצרכי הIT והפרויקטים של המשרד גדלו, וכן מכיוון שהחוזה שולב בחוזים האחרים (לכדי חוזה הASPIRE ). המעבר עלה למשרד 47.5 מיליון ליש"ט בסך הכל מיליון ליש"ט שולמו ל Capgemini עבור ההעברה (כפי שהוסכם מלכתחילה במכרז) ועוד שולמו 5.7 מיליון ליש"ט ל- EDS על מנת לסייע בהעברה. 122

123 מסקנות מהמכרז החדש- ניתוח התמורה לכסף של ההצעות: המשרד יכול היה לנתח את התמורה לכסף של ההצעות הללו בצורה טובה יותר, אם היה משתמש בניתוח-רגישות כאשר בחן את ההשפעה של שינויים בהיקף העבודה, על העלות והרווח השוליים. אולם, גם לאחר הגידול בהוצאות, המשרד אינו סבור כי הדבר היה משפיע על בחירתו את Capgemini כספק. הניתוח האחרון מראה, כי עם העבודה הנוספת שנדרשה, Capgemini עתה אף זולה יותר מאשר EDS הייתה, באותו המצב. מו"מ על דמי המעבר: בתהליך המכרז המשרד הודיע כי ישלם את עלות ההעברה, אך לא הסכים על העלויות הייחודיות של ההעברה, עד אחרי חתימת החוזה. מהלך זה, עלה לו בזמן רב של מו"מ לגבי השאלה- האם עלות ספציפית היא ייחודית או לא. בראיה לאחור, היה לעשות את הדברים אחרת: אם המחלקה מסכימה לשלם דמי-מעבר, יש לבצע את המו"מ לגביהם לפני סיום העסקה, וכך לנצל את מתח התחרות להורדת עלויות. כמו כן, אין סיבה לשלם רווח-שולי לספק (כפי שנעשה בסופו של דבר כאן). שיתוף פעולה בין הספקים והעברת הצוות: ההעברה המרכזית, הושלמה בהצלחה ובזמן. הצוותים וספקי המשנה, הועברו מ EDS ל- Capgemini ללא קשיים מיוחדים. נמצא, כי ההעברה של הצוות הינה קריטית להצלחת ההעברה בכללותה. בחוזה מול EDS קיים היה סעיף יציאה לפיו על החברה למסור מידע ולתמוך בכל ספק נכנס. שיתוף הפעולה שהיה בין הספקים הקל על ההעברה, ואפשר לפעילות היום-יומית להמשיך כרגיל. הערכת איכות הייעוץ: המשרד לקח ייעוץ בהיקף של 11.9 מיליון ליש"ט, במהלך הרכישה וההעברות. אולם, לא נעשתה הערכה של איכות הייעוץ. המשרד העריך שקיבל תמורה סבירה, וכן טען כי הערכה רשמית של הנושא, תהיה בזבוז משאבים. בחוזה החדש הוחמרו תנאי הענישה של הספק, למרות שהדבר גורם להעלאת מחיר החוזה. סיכום המסקנות מפרויקט IR תשומת לב למשתמשי המערכת הינה גורם חשוב להצלחת הפרויקט. יש לבצע סקירה של גורמים אשר ישפיעו על השימוש במערכת- לוודא מה יגרום ללקוחות להשתמש במערכת ומה יוריד את אחוזי השימוש. יש לבצע בדיקה קפדנית של צרכי המשתמשים. מימון חלק מעלויות המכרז לספקים מעודד ספקים לגשת ומעודד תחרות (אין פה הצעה כללית ואין זו המדיניות הבריטית בדרך כלל- אלא שכאן מדובר במקרה שבו היה ספק בעל יתרון התחלתי רב). מימון עלויות המעבר, מעודד ספקים נוספים לגשת למכרז. יש לחתום על הסכם מימון עלויות המעבר לפני חתימת החוזה הסופי ולא לאחריו. יש להעדיף ספק שמתאים לצרכי הIT, הדרישות המשתנות ואיכות המכרז ולא את העלות הנמוכה. 123

124 מומלץ לנתח את התמורה לכסף של ההצעות במכרז תוך שימוש בניתוח-רגישות כשבוחנים את ההשפעה של שינויים בהיקף העבודה, על העלות והרווח השוליים. העברת הצוות וספקי המשנה הינה קריטית להצלחת ההעברה. יש לעודד את שיתוף הפעולה בין הספקים- זה הנכנס וזה היוצא, שכן שיתוף פעולה ביניהם הינו קריטי להצלחה. תנאי הענשה מחמירים לספק במקרה של אי-עמידה ביעדים, גם אם הדבר יעלה את מחירו של החוזה. מערכת ה- SUITES מחלקת 33, ארה"ב "פיתוח כוח העבודה" ),(DWD Department of Workforce Development במדינת וויסקונסין, מפעילה תוכנית של ביטוח לאבטלה. על פי תוכנית זו, על כל מעסיק משלם סכום מסוים לקרן האבטלה.,DWD ביקשה לפתח מערכת מידע, הנקראת State Unemployment ) SUITES (Insurance Tax Enterprise System אשר תאסוף מידע לגבי השכר ותשלומי המס מן המעסיקים. IT פרויקט נוסף של המחלקה, הינו ה- Enhanced Automated Benefits and Legal ) EnABLES (Enterprise System אשר נועד להעניק תשלומים למובטלים זמניים. התוכנית הייתה, להחליף את המערכות הקיימות שהתיישנו מתוך כוונה כי התוכנות החדשות יאפשרו התאמה קלה יותר ואפקטיבית מבחינת עלויות, לשינויים עתידיים בחוק ביטוח-אבטלה. כמו כן, התוכנות החדשות כך קיוו- יהיו ידידותיות יותר עבור העובדים וישפרו את השירות למעסיקים. תוצאות עלויות ולו"ז עד ספטמבר 2006, הוציאה DWD על הפרויקט 63.9 מליון דולר, כאשר רוב התקציב מגיע ממיסי המדינה ו 20 מליון דולר מהכנסות ממיסים ששלמו המעסיקים באופן מיוחד עבור שיפור המערכת. סכום זה, עלה באופן משמעותי על האומדן הראשוני והחריגה בזמנים הייתה גם היא משמעותית: SUITES חרג ב 18.7 מליון דולר ושינה את לוח הזמנים לסיום הפרויקט מפברואר 2004 למרץ 2008; EnABLES חרג ב 23.4 מליון דולר והיה אמור להסתיים ביוני כאשר עד פברואר 2007, הוא לא הסתיים. מהלך הפרויקט- SUITES אפיון המערכת: בין השנים חתמה DWD על חוזים עם שלוש חברות ייעוץ אשר ביצעו (כל אחת ביצעה חלק אחר) ניתוח של התהליכים, הציעו כיצד להחליף את המערכת הקיימת ויצרו אפיון מפורט עבור התוכנה. חברת Accenture נבחרה לסיים את עיצוב דרישות המערכת, לפתח ולהטמיע את התוכנה. החוזה דרש כי עובדי DWD יעבדו בצמוד עם חברת Accenture במהלך הפיתוח. 55.5% מעלות מתוך: דו"ח שהוגש לנציגי הסנאט של מדינת וויסקונסין, ארצות הברית. אפריל 2007:

125 הפיתוח עד ספטמבר 2006, היו עלויות פנימיות של,DWD כולל משכורות והטבות שניתנו לעובדי הפרויקט מטעם.DWD המרכיב הראשון של המערכת הוטמע בספטמבר DWD שינתה את אומדן העלויות 5 פעמים ואת לוח הזמנים הצפוי 3 פעמים. עקב חריגה משמעותית מאוד בהיקפים, אי עמידה בזמנים ולמרות ש Accenture הסכימה לספוג, 26,000 שעות עבודה ללא תשלום, החליטה DWD להפסיק את ההתקשרות עימה באוגוסט 2005 ולקחת אחריות בעצמה על הפרויקט. צוות פנימי של DWD לקח את האחריות להשלים את הפיתוח. קשיי הפרויקט פישוט והתאמת התהליכים: לפני הפיתוח, לא נעשה הליך להתאים ולפשט את התהליכים. הפשטה והתאמה, יכלו להפחית מהמורכבות וכך היה נדרש פיתוח יקר פחות. DWD אמנם שילמה לחברת ייעוץ עבור ניתוח של התהליכים הקיימים, מעל $100,000 אך זו לא בדקה האם ניתן לפשט אותם. הגדרת הדרישות: DWD שילמה 3.5 מליון דולר לחברת ייעוץ עבור הגדרת דרישות מדויקת ואפיון מפורט למערכת. אולם DWD לא הייתה מרוצה מהתקדמות חברת הייעוץ ולכן כאשר יצאה להליך RFP וחתמה עם Accenture האפיון המפורט עוד לא הושלם. ללא אפיון זה, לDWD ו Accenture לא היה בסיס סביר להעריך עלויות וזמנים. צוות DWD טען כי Accenture לא העריכה כראוי את המורכבות והתהליכים העסקיים שרצתה להשיג DWD מן המערכת ונעשה מו"מ חוזר ונשנה על היקפים ולוחות זמנים. הערכת עלויות ורווחים: DWD לא העריכה נכון את העלויות והרווחים הקשורים בפיתוח.SUITES למרות ששולם לחברת ייעוץ מעל $900,000, לנתח את האפשרויות ולהמליץ לגבי החלפת המערכת הקיימת, תועלת ההמלצות הייתה מוגבלת כיוון שDWD לא בדקה כראוי את התהליכים העסקיים ולא הגדירה מה דרישותיה מן המערכת החדשה. כתוצאה מכך, נגרמה פגיעה ביכולת של DWD לקבוע האם פיתוח תוכנה חדשה נדרש ואפקטיבי מבחינת עלות או שמא מוטב להחליט על גישה פחות יקרה או להתאים תוכנת מדף. סיכום: מן המקרה של DWD ומערכת SUITES ניתן ללמוד כי יש להשקיע בתכנון הפרויקט ולהנהיג אותו כבר מהשלבים הראשונים. אמנם, DWD לקחה חברות יעוץ חיצוניות על מנת שיעשו עבודת הכנה יסודית, אך היא לא מספיק הכווינה אותן לרצונותיה ולא קיבלה תוצאות טובות מספיק. קושי מרכזי בו נתקל הפרויקט הוא בהגדרת הדרישות ונראה כי הוא היה הגורם העיקרי לחריגה הגדולה בהיקפים- בזמן ובעלות הפרויקט. 125

126 34 SERV1 SERV1 הינו תאגיד ממשלתי העוסק בלוגיסטיקה ושירותים פיננסיים. SERV1 רצה ספק שיפתח אפליקציות, יטמיע ויתמוך במערכת תמורת 30 מליון דולר לשנה. הארגון בחר מתוך מאגר הספקים שלו, 2 ספקים ללא מכרז וה- CIO הציע הצעה ללא מיקוח: חוזה המשלם לספק לפי שעות העבודה, במחיר קבוע של 10% יותר מן העלויות שיעלה לארגון פיתוח בבית. הספקים שניהם הסכימו וה- CIO ראה בתהליך זה תהליך מוצלח. אולם, למרות תפיסת הCIO את הפרויקט כמוצלח, מנקודת המצב של הצוות, הספקים והיחידות העסקיות הדברים נראו אחרת. הם ציינו כי עיקר הבעיה הייתה בהגדרת האחריות. כוח העבודה של הספק הבין שהוא שם כדי לפתח את האפליקציות תחת הוראות הלקוח. צוות הארגון חשב כי אחריות הניהול והפיתוח מוטלת על הספק. ה CIO היה מודע לבעייתיות אך האשים את צוות הפיתוח בהתחמקות מאחריות. בנוסף, היחידות העסקית, הרגילות לעבוד עם 28 הספקים שבמאגר, אולצו לעבוד רק עם 2 הספקים שבחר הCIO - הם ראו בדבר ניסיון של מחלקת הIT לנהל אותן ולכן עקפו את ההסכמים עם 2 הספקים כאשר יכלו. עקב כל זאת, פוטר הCIO. קשיי הפרויקט התחשבות בבעלי העניין: שוש הבעיה נעוץ היה בשלב התכנון, בפיתוח האסטרטגיה- לא תוכנן נושא התקשורת בין התפקידים השונים. היחידות העסקיות ראו בIT כגורם התומך בארגון בעוד הCIO ראה בו חלק ממנו. היחידות העסקיות אולצו להשתמש בחוזים נגד רצונן ולהפסיק לעבוד עם הספקים אותם העדיפו. חוסר ניסיון: הלקוח לא היה מנוסה בפרויקטים של מיקור חוץ בIT וחוסר ניסיון זה השפיע- מנהל/ת מנוסה של פרויקטים במקרה זה חשוב/ה מאוד. חלוקת אחריות: לא הוגדרו היטב תחומי האחריות, התפקידים וחלוקתם בין הצדדים. סיכום: ממקרה זה, ניתן ללמוד כי תהליך מהיר והסכם זריז אינו תמיד כדאי. מיקוד רק בעלויות החוזה, עלול להסתכם בחוסר-התחשבות בבעלי עניין אחרים בחוזה. חוסר התחשבות זה, עלול ליצור אי-שיתוף פעולה מצד גורמים שונים בארגון, אשר עלול להכשיל את הפרויקט. חשוב לשים לב ולהגדיר היטב את תחומי האחריות והתפקידים. כמו כן, חשוב כי במידה והארגון אינו מנוסה במיקור חוץ, מנהל/ת הפרויקט יהיה/תהייה בעל/ת ניסיון. Cullen, S. (2009). Key Activities Of The Outsourcing Lifecycle. Sourcing & Vendor Relationships. 10 (1),

127 מקרי בוחן- ישראל מתוך דיוני הועדה ומפגישות שנערכו עם מנמ"רים ממשרדים שונים, נביא כאן מספר פרויקטים יוצגו התהליכים לגבי כל פרויקט, גדולים לפיתוח תוכנה שנעשו בשנים האחרונות בממשלה. העיקריים והמסקנות העיקריות העולות ממנו באופן ספציפי. בסופו של הפרק, ירוכזו כלל ההמלצות כפי שעלו ממקרי הבוחן ומדברי המנמ"רים. פרויקט מערכת סחר חוץ/ "דור חדש"- רשות המיסים על הפרויקט: מערכת המנהלת את תהליכי סחר חוץ של מדינת ישראל (חישובי מסים, חוקיות יבוא ואכיפה) לרבות סיוע למלחמה בטרור, בקרה, סטטיסטיקה ושמירה על חוקי הסחר הבינ"ל. התנהלות המכרז הודעה מן האוצר כי יש לצאת למכרז עקב חוק חובת המכרזים לאחר שמל"ם הפכה לחברה פרטית. ברשות המיסים חששו מן המכרז: היו מרוצים ממל"ם וכן, מדובר במערכת גדולה אשר כל הידע שלה מצוי אצל מל"ם. חששו שחברה אחרת שתקבל את המכרז תפגע במערכת. לפיכך, הובא יועץ חיצוני לבדיקת סוג והיקף המכרז (מעבר לצורך במכרז עפ"י חוק). חברת הייעוץ, ביצעה ניתוח של המערכת והסיקה כי באופן כללי: רמת השירות גבוהה התאמה פונקציונאלית בינונית גבוהה עלות מבנה ההתקשרות מגביל ההמלצה של ועדת המנמ"רים וחברת הייעוץ- להתחיל מערכת חדשה: עקב הבעיה בפונקציונליות של המערכת, הוחלט כי מערכת חדשה תתאים יותר- תהליכים חדשים, שירותים טובים יותר, מערכת שתענה על הדרישות החדשות. יקבלו מחיר טוב יותר במכרז. שבירת המונופול של מל"ם- כי אין להם יתרון בידע הדרישות (מה שכן היה להם בהעברת המתקן). הסיכונים בפיתוח מערכת חדשה נתפסו כיותר נמוכים מאשר בהעברת מתקנים החלטה על יציאה למכרז. שלב התארגנות ארך למעלה משנה וחצי. בהן הכנת מכרז לחברה שתכין ותלווה את המכרז על הפרויקט. חברת "מטאור" זכתה. 100 כתיבת אפיון המערכת ו- RFP ארכה כשנה וחצי. האפיון נעשה באמצעות ריכוז של 14 ועדות עובדים של המכס, שניתחו תהליכים. בנוסף, נעשה ניתוח סיכונים וניתוח של 127

128 מכרזים גדולים קודמים (מב"ת 2000, ת.ז, מערכת השכר) ללמידה מטעויות העבר ומציאת פתרונות טובים יותר. 128 בבניית המכרז נעשו מאמצים להקל על הספקים עד כמה שניתן, על מנת שיותר ייגשו. ידוע היה מלכתחילה, כי ישנן רק 3-4 חברות בשוק שיכולות להתמודד ורצו לדאוג כי כולן ייגשו. כנס ספקים מקדים- מה רוצים לעשות, דגשים, הערות במטרה כי שני הצדדים יקבלו יותר מידע. אגף התקציבים ביקש להטיל את מימון הפיתוח על הספק. היה חשש שלא ייגשו ספקים למכרז כי הסיכונים גדולים מדיי עבורם. לכן, הוחלט על הפחתת הסיכונים לספקים עבודה לפי אבני דרך ופריסה לתקופת התפעול. בפשרה מול האוצר, הוחלט על תשלום של 70% באבני הדרך ו 30% פריסה לתקופת התפעול. מנהל רשות המיסים דרש מועדת הכספים העלאה/עזרה במימון. הועדה העלתה את האגרה לטובת המערכת בטענה שהמערכת תוזיל לקהילת הסחר את העלויות. ספק אחד עתר לבית המשפט בנוגע למכרז. בינתיים המשיכו עם בניית המכרז תוך סעיפים מגבילים לנושא. עקרונות המכרז תהליך בחירת הספק -BEST&FINAL אופציונאלי: האגף מכריז כי הוא יוצא לB&F רק אם הוא רוצה. כך, מתמרצים את הספקים שלא יגישו הצעות מנופחות. בכדי שהמכרז לא יחשב לתפור, האגף מפרסם כי יוכנסו לכספת התנאים מראש. הצעה משופרת- מוסכם במכרז כי יהיה גיליון ציונים להצעה. גיליון זה, מועבר לספקים והם משפרים אותה. כך, מתקיים B&F גם על החלק הטכנולוגי. ציונים- 40% עלות, 60% איכות. מנגנון תוספות וגריעות: נוסחה להוספה או הורדה בתשלום. לא הוכתב פיתרון- לא הוכתבה טכנולוגיה אלא רק הדרישות. פרסום המכרז - נובמבר פורסם לחצי שנה. כנס ספקים שני. 10 חברות היו בקשר. ניתן מענה ל 450 שאלות. מל"ם, Ness ו- EDS רצו ללכת יחד. חששו ברשות המיסים שלא תהיה תחרות ולפיכך סרבו לקבל את ההתאגדות ואיימו כי יפנו לממונה על ההגבלים העסקיים. שלושת החברות ויתרו על השיתוף בפרויקט. החברות לא עמדו בחצי שנה ובקשו דחייה- היה צורך להאריך. הוחלט על כיתות לימוד- החברות ישבו כמה ימים ללמוד את המערכת. סייע להפחית את היתרון של מל"ם. בשלב זה של הפרויקט, גם נפתרה עתירת בית המשפט שעמדה מול המכרז. לקראת הגשת המכרז, פרשו רוב החברות ונותרו שתיים: Ness+EDS ו-מל"ם+ IBM. Ness+EDS העלו דרישות שהיו קשורות לשינוי המכרז ולא ניתן היה להיענות להן. בעקבות זאת, Ness+EDS פרשו. אוגוסט קבלת הצעה אחת ממל"ם.

129 ציונים: שלב א' - איכות ; 91.8 שלב ב' - איכות 88 (משופרת); שלב ג' - עלות הצעה מקורית 580 מיליון, עלות הצעה משופרת 443 מיליון. מו"מ להורדת מחיר- ההצעה הכספית גבוהה מהאומדן ולכן, מו"מ להורדת המחיר של החוזה בתיאום עם החשכ"ל. הוחלט על מיצוי המו"מ במרץ האומדן עודכן (למשל: מרכיב תשומות כוח אדם) ואושר: עלות הפרויקט כ מליון - פיתוח מערכת "דור חדש" - תחזוקה - 10 שנים לו"ז אפיון מפורט ופיתוח המערכת 3 שנים מסקנות מן הפרויקט העדר תחרות: היקף ומורכבות הפרויקט- חשש של הספקים מכישלון. שוק מציעים מצומצם בישראל, היכול לעמוד בסדרי הגודל של פרויקט מסוג זה. מל"ם הייתה עתידה להוסיף ולתחזק את המערכת הקיימת עד שתוכל החדשה להחליפה. הדבר הפריע לEDS שכן לא רצתה לפתח מערכת כשמל"ם נושפת בעורפה. מבחינת המשרד- עדיף היה שמל"ם תוסיף לתחזק על מנת שלא לשאת בנזקים שעלולים להיגרם עקב חוסר הניסיון עם המערכת, של.EDS אבל- יתכן וכדאי היה לבחון את האפשרות לתת לEDS את התחזוקה על מנת לחזק את התחרות. העדר יתרון יחסי- תחושה שמל"ם מכירה את המערכת טוב מכולם. תנאי תשלום- היה מקום להקל יותר בתנאי התשלום במכרז, אך קיים קושי מול החשכ"ל. יש מקום לתשלומים נוחים יותר לספק. יש לבדוק את הנושא של אחריות, ערבויות, ביטוחים, נזקים וכו' כיוון שדברים אלה מונעים מספקים לגשת. השקעה רבה מצד הספקים בהכנת ההצעה מול סיכון להפסד. יתרונות וחסרונות בבחירת מל"ם: יתרונות: סיכוי קלוש לעיכוב משפטי, חשיפה נמוכה לסיכון (עקב הכרות מל"ם עם המערכת), שמירת הידע בבית-נשאר אצל מל"ם, עמידה באומדן. חסרונות: העדר תחרות (מתבטא בעלות ובהעדר חלופה טכנולוגית), תהליך ארוך. מסקנות: ייתכן ומצד טובת הפרויקט היה כדאי יותר להישאר עם מל"ם מלכתחילה, או- במקרה של הליכה למכרז היה כדאי לעשות מאמצים גדולים ליצור יותר תחרות. הצעה משופרת: תהליך שיפור ההצעה בשלב הסופי, הועיל מאוד לפרויקט. הדבר היווה עוד תיאום ציפיות חשוב ויצר BEST&FINAL גם על הטכנולוגיה ולא רק על המחיר. 129

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

131 פרויקט רימון האגף לרישום והסדר מקרקעין האגף לרישום והסדר מקרקעין הינו אגף של משרד המשפטים, בפריסה ארצית, העוסק ברישום מקרקעין, הסדר מקרקעין, המפקח על רישום מקרקעין. ההחלטה לצאת למכרז צורך במערכת מידע שתענה על הצרכים הלא-ממוחשבים ותחליף (היכן שקיימת) את המערכת המיושנת. הליך המכרז התקשרות עם משרד ייעוץ : יצירת צוותי אפיון של הלקוח, יחד עם היועצים. יצירת,RFI אפיון על, תהליכי עבודה, נוהל מפת"ח וכו'. ספטמבר 2006, התפרסם המכרז הראשון. הוגשה הצעה אחת בלבד- (IBM) שלא עמדה ברכיב האיכות. תהליך הסקת מסקנות מן המכרז הראשון. כתיבת מכרז שני על בסיס הלקחים שהופקו + תוספת תכולה: תחזוקת המערכת הקיימת של הרישום כיוון שבינתיים התקרבה לסיומה ההתקשרות עם ספק התחזוקה של המערכת הקיימת (כך- המכרז נעשה לפיתוח ותחזוקה). כמו כן, הוספה דרישה לספק, למימוש בשלבים (על מנת לאפשר אספקת תוצרים לעובדים בשלב מוקדם ככל האפשר). ניתן יתרון לספק שיגיש פיתרון בשלבים (אך לא היה חיוב). כדי לא לאבד את התקציב עבור המכרז הראשון- על המכרז היה להסתיים עד ה- 31 בדצמבר, מה שיצר לחץ רב. מרץ פרסום המכרז הפומבי השני. סבב שאלות לפני כנס הספקים- כנס ספקים- סבבי שאלות נוספים- הגשת הצעות. במסגרת המפרט פורסם מפ"ל מפורט. לכל סעיף הוסבר בבירור כיצד יינתנו הציונים. נגשו: טלדור+נס; HP +מטריקס; +EDS סיסטמטיקס. תחרות מספקת מצד המשרד. טלדור + נס לא עברו סף איכות. ניקוד האיכות שם את EDS במקום הראשון ואת HP במקום השני. עם פתיחת מעטפות העלות התברר כי EDS נתנו את ההצעה הזולה ביותר. באישור וועדת ענ"א משרדית, נפתח הליך מו"מ עם שני המציעים. ההתקשרות עם EDS כוללת שני מרכיבים: 131 תחזוקת המערכת הקיימת במחיר חודשי קבוע + מנגנון ביצוע שינויים ושיפורים כל זאת בכפוף ל-.SLA הקמת המערכת החדשה: פרויקט הקמה בפיקס פרייס, התקדמות בשלבים על פי אבני דרך בתכנית העבודה, כאשר התמורה לכל אבן דרך קבועה בחוזה על פי הצעת המענה של EDS למכרז. הקמת המערכת החדשה מתבצעת בכפוף למנגנון קנס/פרס. קנס בגין איחור ותגמול חד פעמי כנגד עמידה בתכנית העבודה.

132 כיום הפרויקט מתקדם ויחסי העבודה עם הספק טובים מאוד. מסקנות מן הפרויקט תשלום על אבני דרך- אחד הקשיים במכרז הראשון היה, שהתשלומים על אבני הדרך נתנו כמקדמה ולא כתשלום. לדבר משמעות פיננסית עבור הספקים (לא יכלו לדווח על התשלומים כהכנסה). שימוש במפ"ל מפורט- יתרונות: שקיפות, תוצאה יותר מבושלת. חסרונות: מאפשר לספקים לוותר על חלקים אשר יתכן כי יתגלו כחשובים בהמשך. חיסרון נוסף, נובע מחוק חובת המכרזים כל מה שלא הוגדר מראש לא ניתן לביצוע כך שלא ניתן להוסיף תכולות שנשכחו/ לא חשבו עליהם וכד'. אפיון מפורט- כתיבת אפיון מפורט לפני יציאה למכרז פיתוח- בחוזים של פיקס פרייס. זאת על מנת לשלב את כל התובנות שעולות משלב האפיון המפורט בתנאי ההתקשרות עם ספק הפיתוח. קושי בקשר שבין חוק חובת המכרזים והתקציב, שכן הגבלת התקציב דורשת תכנון מוקדם ומשאירה מעט מאוד מקום לטעויות. חוק חובת המכרזים מחייב את הכפופים לו להגיע לכל התקשרות לאחר תהליך כזה או אחר של מכרז. התלות בתקציב המדינה מציבה לעיתים אילוצים נוספים על התהליך המורכב גם כך של פרסום מכרז, בכך שצריך לעמוד בלוחות זמנים מסוימים על מנת לא לאבד את התקציב ששוריין להתקשרות. אומדן-נוצר קושי כאשר מחיר האומדן רחוק ממחיר הספקים. האומדן מחייב את הלקוח נוצר במידה והייתה טעות תמימה בחישוב האומדן, היא עלולה לפסול תהליך שלם של מכרז. יחסי אמון עם הספקים- חשובים ביותר. באחריות שני הצדדים להתנהל בכוונה מלאה ל-.WIN-WIN חשוב לפתח יחסים הוגנים, תפיסה של מטרה משותפת וצוות אחד. חשוב כי מנהלי הפרויקטים יצרו אווירה של אמון. פרויקטים גדולים מצליחים כיוון שיודעים לנהל את הבעיות שכן אין פרויקט בסדר גודל שכזה, הנטול בעיות. 132

133 פרויקט שחור לבן- הרשות לאיסור הלבנת הון הכנה הרשות לאיסור הלבנת הון הוקמה בשנת המכרז על הפרויקט יצא עוד לפני שקמה הרשות- על בסיס ועדה. אפיון הדרישות- על בסיס החוק על ידי אנשי הועדה ויועצים חיצוניים. מכרז בסדר גודל בו רק חברות גדולות יכלו לגשת. המכרז: פיתוח, הקמה, תחזוקה ל 3 שנים. כולל רכש של החומרה ורישיונות (שעוברים). היקף של 32 מליון הליך המכרז ניתנו 4 חודשים לספקים בכדי לעבוד על המכרז, כולל שני כנסי ספקים לשאלות ותשובות והבהרות. אפריל הגשת הצעות על-ידי: Team +יעל; אלביט; נס+ IBM ; מטריקס+ טלדור תחילת החלטה על העוברים לשלב הבא: על פי מפ"ל ואומדן מחיר שנעשה לפני המכרז. נבחרו אלביט ו- Team +יעל, שעמדו בציון איכות 80%. הצעות המחיר נפתחו רק אחרי ציון האיכות. -Best & Final אלביט ירדו מ 68 מליון - ל 31.5 מליון. טענו שהורידו את שנות התחזוקה (הגישו הצעה על 4 שנים) וכי הפרויקט הוא אסטרטגי מבחינתם ורוצים אחר כך למכור את המערכת ולפיכך הסכימו להוריד דרסטית את המחיר ולבצע את הפיתוח. Team ירדו מ 35 מליון ל 33 מליון. ההצעה של אלביט, מעבר למחיר, הייתה טובה יותר- אלביט נבחרה. ההסכם נחתם ביוני חוזה מסוג פיקס פרייס. אפיון כללי של המערכת לאחר המכרז, ארך מספר חודשים. אפיון מפורט, ארך כשנה. לאחר הפיתוח בוצעו 4-5 סבבי בדיקות שבהם טענו כי הם אלביט מוכנים להגשה מבחינתם, אך בפועל הוגשה מערכת שאינה מכילה את כל התכולה, אינה יציבה ולכן משרד המשפטים פסל ודרש תיקון. ינואר עליה עם המערכת. תכולה מרודדת, מערכת חסרת יציבות. סקירת המצב הקיים העידה כי הפיגורים הינם בלתי סבירים; אין תמיכה בגרסה מותקנת; אין כוונה להשלים גרסה; אין סיכוי להשלים את המערכת. הספק צבר הפסד משמעותי והסיכוי להשלמת המערכת הוא נמוך ביותר עד לא קיים. ינואר לאחר הליך בוררות שכשל, נבחנו מספר חלופות ומשרד המשפטים ואלביט מחליטים על פרידה. פרידה בפועל ביוני

134 הפרויקט כיום לאחר הפרידה מאלביט, הוחלט להמשיך את הפיתוח בתוך הבית ונבנה צוות פיתוח. הצוות- 15 אנשים העובדים תחת חוזה של בית תוכנה, במשרד המשפטים. הסיבות בגינן הוחלט שלא לצאת במכרז נוסף: משך הזמן שהיה אורך לכתוב, להפיץ, לבדוק, לקבל החלטה, לחתום על חוזה. הניסיון שנצבר אצל מנהלי המחשוב מטעם המשרד, יחד עם הצטברות ההבנה אצל הלקוח (המשתמשים) לגבי תעדוף נושאים אפשר פיתוח עצמי. היה צורך דחוף לתמוך במערכת שעלתה כבר לאוויר ולקבל את המערכת מידי אלביט לצוות כלשהו ולכן היה חובה לגייס צוות במהירות. נעשתה חלוקה למודולים והוחלט על סדר הפיתוח. היתרון- הפיתוח נעשה תוך כדי תנועה, ניתן לבחון את הדברים האם נעשים כראוי ולהחליט על שינויים. מסקנות מן הפרויקט ספק מפסיד- לא ניתן להצליח בפרויקט כאשר הספק מפסיד. ספק מפסיד פירושו הפסד גם ללקוח. יש רק מצב אחד שניתן להצליח ובו שני הצדדים מרוויחים.(win-win) כאשר הספק חותך את הצעת המחיר בחצי ומציע מחיר נמוך מאוד, מדובר בתמרור אזהרה משמעותי ויש לשקול את פסילת הספק. פערים בין הדרישות לבין הצרכים בפועל- פערים בציפיות שלא ניתנו לגישור. המכרז נכתב עוד לפני שהרשות הוקמה, כאפיון על כולל, על בסיס החוק. חשוב לפתח ציפיות ראליות כלפי הספק ולא לדרוש עוד ועוד. סביבת פיתוח לא יציבה- הרשות הייתה גוף בהקמה. עקב כך סביבת הפיתוח הייתה מאוד לא יציבה: שינויים רבים בנפחי המידע, בחוקים ועוד. יש לקחת זאת בחשבון בחוזה: לבנות מכרז מודולרי, חלוקה למודולים ותעדוף, הבהרה לרשות כי הרחבת תכולה משמעה שו"ש ולעגן במכרז כמות שעות/תקציב אשר מיועד לשו"שים של שינויי חקיקה ואחרים. אושר לאלביט לפתח שלא לפי נוהל מפת"ח- מה שהתברר כלא- כדאי. דרישות- תפיסה כי ניתן לדרוש מהספק עוד ועוד לגבי התכולה. בדיקה על ידי המשתמשים- לא נעשתה בדיקה מובנית מספיק, על ידי המשתמשים. הסדרים ברורים לגבי ניהול הפרויקט- לחתום על הסדרים ברורים ומובנים עם הספק לגבי הניהול של הפרויקט מצד הלקוח. למשל- סיכומי דיון: על מנת לא לפתוח פתח לספק לכתוב את הדברים כפי שהוא רוצה, חשוב להתייחס בהסכמים לשאלה מי מאשר את סיכומי הדיון 134

135 ביבליוגרפיה מסמכים בריטניה מודל הסכמי ICT של משרד המסחר הבריטי,(OGC) עדכון מאוקטובר 2009: ICT SERVICES AGREEMENT GUIDANCE %20Model%20ICT%20Agreement%20Guidance%20Version%202%203.pdf משרד המסחר הבריטי,(OGC) דו"ח מינואר 2009: Programmes and Project Delivery Joint Statement of Intent מדריך של משרד המסחר הבריטי -(OGC).Competitive Dialogue in pdf הדו"ח ה 28 של הועדה לענייני דין וחשבון ציבורי, הפרלמנט הבריטי, מאי תקנות החוזים הציבוריים, בריטניה- The Public Contracts Regulations מדריך של משרד המסחר הבריטי (OGC) :Competitive Dialogue Procedure, דו"ח 37 של הועדה לענייני דין וחשבון ציבורי, בריטניה, אפריל 2006: המשרד למדע וטכנולוגיה הבריטי, דו"ח שהוגש למשרד, 2003: תקציר הדו"ח

136 .PFI: Meeting the investment challenge משרד האוצר הבריטי, יולי 2003: בריטניה,,FASTER PROCUREMENT דו"ח ממאי מסמך שהוגש לקבינט הבריטי, Action: 2000 Successful IT Modernising Government in דו"ח ביקורת של הNAO - המשרד הלאומי לביקורת, בריטניה, מרץ 2000: eds_strategic.aspx?alreadysear chfor=yes חברת "4P", בשיתוף עםהממשלההבריטית: Competitive Dialogue - A new chapter in procuring large and complex projects ocuring%20large%20and%20complex%20projects.pdf מעגל החיים של רכש,IT בריטניה. שער 5- מודל הסכמי ICT של משרד המסחר הבריטי,(OGC) חלק ראשון ושני: ICT SERVICES AGREEMENT. GUIDANCE NOTE 1,2 GUIDANCE, ארצות הברית מזכר של המשרד לניהול ותקציבים האמריקאי, Acquisition,Improving Government יולי 2009: מזכר של הבית הלבן,,Government Contracting מרץ 2009: /Departments-and-Agencies-Subject-Government משרד הOMB (ניהול ותקציבים) האמריקאי, דו"ח לממשל מנושא הממשל האלקטרוני, 2009: 136

137 דו"ח שהוגש לנציגי הסנאט של מדינת וויסקונסין, ארצות הברית. אפריל 2007: תקנון הרכש האמריקאי, 2005 : REGULATION,(FAR) FEDERAL ACQUISITION של ה- General Administration משרד ה OMB האמריקאי, מזכר הנוגע לרכש תוכנה, יולי 2004: משרד מערכות המידע האמריקאי,,OUTSOURCING INFORMATION TECHNOLOGY 1998: אוסטרליה הממשל האוסטרלי, דו"ח מאוגוסט 2008: Review of the Australian government s use of information and communication technology מדריך הרכש האוסטרלי, המשרד לניהול מידע,(AGIMO) ספטמבר 2007: ארגון,ISBSG דו"ח לממשלת ויקטוריה, אוסטרליה. :2004 in Software Development Projects GOVERNMENT האיחוד האירופי -Netherlands Court of Audit גוף עצמאי לביקורת על הממשלה בהולנד, הממונה על-ידי הקבינט, דו"ח מ 2007: האיחוד האירופי, תקנות הדיאלוג התחרותי, מרץ 2004: קנדה and משרד החשב הכללי של קולומביה הבריטית, קנדה: An Audit of Joint Solution Procurement the Revenue Management Project, 2008/2009 report 1. April

138 מאמרים Agarwal, N. Rathod, U. (2006). Defining success for software projects. An exploratory revelation. International Journal of Project Management, 24: Al Neimat, T. (2005). Why IT Projects Fail, PROJECT PERFECT website: Alfano, S (2004).The real value of cost-plus: fixed-price contracts give remodelers an excuse to ignore job costing. That's a mistake that could really cost you. Aubert, B. Houde, J.F. Patry, M. Rivard, S. (2003). Characteristics of IT Outsourcing Contracts, Proceedings of the 36th Hawaii International Conference on System Sciences. Barthelemy, J. (2001). The hidden costs of IT outsourcing, MIT Sloan Management Review. 42(3), Beynon -Davies, P. (2005). Constructing electronic government: the case of the UK inland revenue. International Journal of Information Management. 25, 3 20 Brodsky, R. (2009). NEWS+ANALYSIS Cost of Risk. Government Executive. Cardin, L. (2008). Debunking IT Project Failure Myths. Forrester website: Cullen, S. (2009). Key Activities Of The Outsourcing Lifecycle. Sourcing & Vendor Relationships. 10 (1), Fincham, R. (2002). Narratives of Success and Failure in Systems Development. British Journal of Management, 13:

139 Goldfinch, S. (2007). Pessimism, Computer Failure, and Information Systems Development in the Public Sector, Public Administration Review. 67 (5), Guijarro, L. (2009). ICT standardisation and public procurement in the United States and in the European Union: Influence on egovernment deployment, Telecommunications Policy. 33: Hamidovic, A. & Krajnovic, S. (2005). An Example of a Novel Approach to Measuring Projects Success within ICT Industry. IEEExplore. 8th International Conference on Telecommunications. Heller, U. Hazzan, O. Frank, A.J. (2009). Agile Software Engineering And Its Realization In A Military Organization. Manuscript, received- December 15, Hoezen, M. and Hillig, J.B (2008). The Competitive Dialogue Procedure: Advantages, Disadvantages, and its Implementation into English and Dutch Law. Kalnins, A. &Mayer, J.M (2004). Relationships and Hybrid Contracts: An analysis of contract choice in information technology. Journal of Law Economics & Organization, 20 (1), Linberg, K. R. (1999). Software developer perceptions about software project failure: a case study. Journal Syst Software, 49: Maurer,W. Scardino, L. Doering, K. Ridder, F (2008). Pricing Model Definitions, Benefits and Risks for IT Services and Outsourcing Contracts. Gartner website: McClure, D. (2006). Adopt New Skills to Address Symptoms of IT Project Failures in Government, Gartner website: McClure, D. (2007). From the CIO Trenches: Why Some Projects Fail and Others Succeed, Gartner website: Mieritz, L. (2008). Exploring the Relationship between Project Size and Success, Gartner website: 139

140 Mukerji, S. (2003). Ambiguity Aversino and cost-plus procurement contracts discussion paper series- Department of economics. Oxford. Nelson, R. R. (2005). Project Retrospectives: Evaluating Project Success, Failure, and Everything In Between. MIS Quarterly Executive, 4(3): Pitts, M.G. & Browne, G.J (2007).Improving requirements elicitation: an empirical investigation of Prompts Procedural, Info Systems. 17, Smith, M. & Potter, K. (2009). IT Spending and Staffing Report. Gartner website: Sterpe, P. (2007). Ten Mistakes That Send Development Projects off Track, Forrester website: Strauss, H. (2006). Why IT Projects Fail in Government, Gartner website: Symons, C. (2009). Programs, Not Projects, Deliver Business Value, Forrester website : Turner, J.R. (1993). The Handbook of Project-based Management. McGraw-Hill. Wateridge, J. (1998). How can IS/IT projects be measured for success. International Journal of Project Management, 16(1): West, D. (2009). Best Practices: Software Development Processes, Forrester website: 140

141 אתרי אינטרנט אתר המשרד לניהול ותקציבים (OMB) האמריקאי, אתר משרד הDeregulation Finance and האוסטרלי, אתר מנהל השירותים הכללים האמריקאי אתר ה GSA האמריקאי, אתר ה PWGSC הקנדי, אתר איגוד תעשיית הIT האוסטרלית (AIIA) - אתר ה GITC האוסטרלי, אתר -ITAC ' אתר הרכש של משרד האוצר האוסטרלי, government-strategy/index.html אתר ה-,Naval air חילהיםהאמריקאי- אתרתפנית, בית ספר למנהלים ופיננסים, לימודי המשך שלהאוניברסיטה הפתוחה: אתר הHMRC, בריטניה 141

142 נספחים 142

143 נספח 1 שאלות שמומלץ לשאול לפני התחלת פרויקט IT גדול: האם קיימת תוכנית עשויה-היטב, הכוללת עלויות, לו"ז, אבני דרך ונקודות ביקורת ריאליות? האם עוקבים אחר תהליכים מתודלוגיים מוכרים? האם הפרויקט פורק למרכיבים שניתנים לניהול? האם למנהל הממונה הניסיון המתאים לגודל ומורכבות הפרויקט? האם תוכנית הפרויקט משקפת הגדרה מדויקת של צרכי הIT הלקוח/הספק? התואמים את צרכי במידה וקיים איש,PMO האם תפקידיו ברורים,מוגדרים ומובנים ע"י כל השותפים בפרויקט? האם כל מובילי הפרויקט (תחת המנהל/ת הראשי/ת) מעורבים בתהליכי הניהול וקיבלו את תוכניות הפרויקט? האם יש מספיק בטחונות מימוניים בהתאם לתוכנית הפרוייקט? האם השתנה משהו משמעותי מאישור והפקת תוכנית הפרויקט ועד להתחלתו? נספח 2 תהליכים נוספים המניעים את הגדלת המורכבות של פרויקטים והמשפיעים על מבנה התהליכים: טווח קצר מול טווח ארוך- רוב המנהלים מקבלים החלטות לענות על צרכים בטווח הקצר. הדינאמיקה הארגונית דורשת שינויים לעיתים-קרובות, חדשנות ושיפור מתמיד. לעומת זאת, ה IT מתנהל במעגל איטי יותר, ודורש זמן תכנון, בניה ופריסה של התוכנה בכדי לתמוך בארגון. כך, נוצר מתח של הטווח הקצר מול זה הארוך המקשה על התהליך. צוות שאינו מיומן צוות שהבעיה בארגון, בתחום או בטכנולוגיה חדשה לו יזדקק ליותר עזרה מגורם מנוסה. יש לעצב תהליך הכשרה כך שיתאים לרמות השונות של הקבוצות. שימוש במספר מודלים של מיקור- כיום רוב הארגונים משתמשים במודלים שונים של מיקור המשלבים בדרגות שונות, מיקור- חוץ עם עובדי-פנים. שיטות אלה מגדילות את סיבוכיות תהליכי הפיתוח אשר פעמים רבות עליהם להתממשק עם תהליכים של ספק חיצוני או שעליהם להנחות מפתחים אשר מעורבים בפרויקט רק לזמן קצר. תהליכים רבים מחויבים לציית לדרישות מסוימות ונתונים לביקורת- בחלק מהמגזרים ישנן תקנות ממשלתיות שדורשות לתעד ולדווח על תהליכים מסוימים. בדרך כלל תהליכים אלה הם אוטומטיים, מה שאומר כי שינוי בתהליכים צריך להיות מתועד. צוותי הבדיקה לרוב אינם מהנדסי תוכנה, לכן, תהליך התיעוד צריך להיות מתואר בפשטות. מאידך, התיעוד גם צריך להיות מספיק גמיש כדי שצוותי הפרויקט יוכלו למסור את התיעוד באופן שיהיה יעיל גם עבור הלקוח. 143

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