ניהול ובקרת ספקים

כללי - מבוא

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

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

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

סמכויות היחידה למערכות מידע

יחידת IT, באמצעות מנהל הפרויקט, אחראית למימוש הפרויקט, על מרכיבי הפיתוח, ההצטיידות וההטמעה של המערכת ובכלל זה:

 

 ·         עמידה ביעדי הפרויקט במסגרת התקציב והלו"ז שהוגדרו,

 ·         השתתפות באופן פעיל, בכפוף לנוהלי הארגון, בכל שלבי המשא ומתן וחתימת החוזה עם הספק,

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

 ·         ניהול תקציב הפרויקט,

 ·         ביצוע בקרה ומעקב לפרויקט.

 

אחריות וסמכות מנהל הפרויקט

ניתן לחלק את אחריות וסמכות מנהל הפרויקט לשלושה תחומים:

 

 ·         אחריות כוללת

 ·         תחום האיכות

 ·         תחום משאבים ולו"ז

 

אחריות כוללת

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

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

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

 ·         דווח ללקוח הראשי בשלושה חתכים: דיווח עיתי, דיווח סטאטוס ודיווח על חריגות.

 

תחום האיכות

·         ביצוע בקרת איכות לכל תהליכי הפיתוח של הפרויקט.

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

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

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

 ·         אישור ופיקוח על ביצוע תוכנית בדיקות המערכת ובדיקות הקבלה.

 ·         ניתוח תקלות ומימוש הפקת לקחים מהפיתוח והבדיקות השונות.

 ·         כתיבה ויישום נוהל שינויים בפרויקט.

 ·         הכנת  מסמכי התקנה, תחזוקה ותפעול לליווי קליטת הפרויקט והטמעתו בארגון.

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

 

תחום משאבים ולו"ז

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

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

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

 ·         המלצה על הקפאת גרסה.

 ·         הכנת תוכניות תקציביות שנתיות ורב שנתיות לפרויקט כולו, ניהול תקציב הפרויקט ובקרת תשומות.

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

 ·         פיקוח על התקשרויות חוזיות בארץ ובחו"ל באמצעות גורמי הרכש בארגון.

מחזור חיים של הפרויקט

להלן דגשים במחזור חיים של פרויקט המשלב ספקים וקבלני חוץ:

 

 ·         שלב הייזום

 ·         שלב התנעת הפרויקט

 ·         שלב הבקשה להצעות

 ·         שלב הפיתוח

 ·         שלב קליטה והטמעה

 ·         שלב תפעול ותחזוקה

 

שלב הייזום

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

סוגי קבלני משנה / ספקים חיצוניים שיכולים לבוא בחשבון הם:

 

 ·         ספק זוכה במכרז – מיקור  חוץ מלא (כולל אחריות על התחזוקה),

 ·         ספק זוכה במכרז – מכרז לפיתוח – האחריות על הפיתוח (ובהתאם להסכם גם על הדרכה והטמעה), כאשר האחריות על תחזוקת המערכת עוברת לארגון בסיום הפיתוח,

 

ישנם סוגי קבלני משנה / ספקים חיצוניים נוספים, שהם מחוץ לקטגוריה של ניהול ובקרת ספקים:

 

 ·         כוח אדם שכור בתוך פרויקט שמתבצע פנימי – In house,

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

 

שלב התנעת הפרויקט

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

 

 ·         ועדת היגוי,

 ·         גוף משתמשים,

 ·         מנהל פרויקט,

 ·         מומחה יישום

 ·         נציגים של תחום התשתיות.

 

ראה הרחבה בקיט וועדות הפרויקט בכרך ניהול/ניהול פרויקט.

בנוסף, נכתבים מסמכי האפיון המפורט ותכנית הבדיקות (STP)

 

הנחיות והמלצות

א.       כללי

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

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

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

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

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

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

 

ב.       בניית תוכנית עבודה

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

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

             ·         יש לחלק את תכולת אבני הדרך למנות סבירות, כאלה שהספק יכול לעמוד בהן (בתוכנה למשל, בהיקף של בין 1,000-2,000 ש"ע).

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

             ·         יש להגדיר בצורה ברורה ומדידה את התוצרים והדרישות לאישור אבני דרך.

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

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

             ·         מומלץ לתכנן פיתוח על פי יחידות מסירה הכולל אספקת תוצרים מדורגת המאפשר:

                         ·         הפחתת סיכונים,

                         ·         הטמעה משופרת,

                         ·         שילוב טוב יותר של משתמש הקצה,

                         ·         תיקוף וטיוב האפיון,

                         ·         הבטחה כי התוצר הסופי יתאים לצורך.

 

ג.        צוות הפרויקט מטעם הארגון

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

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

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

 

ד.       איוש צוות הספק

             ·         יש לדרוש מהספק למנות מנהל אחד שיהווה SPOC – Single Point of Contact, ויהיה בעל סמכות לקבל החלטות בפרויקט.

             ·         בנוסף לאיש הקשר האחד (SPOC), יש לדרוש מהספק למנות גם מנהל טכני.

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

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

             ·         השאלת תוכניתני הארגון לספק – על פי מדיניות והחלטה ברמת הנהלת IT או הארגון.

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

 

ה.      קבלן מחו"ל

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

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

 

שלב הבקשה להצעות

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

 

 ·         כתיבת מסמך בקשה להצעות (בל"ם, RFP),

 ·         קבלת מענה המציעים

 ·         בחירת ספק,

 ·         ניהול מו"מ מול הספק בתיאום/שיתוף גופי הרכש בארגון.

 

הנחיות והמלצות

א.       כללי

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

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

             ·         יש לזהות סיכונים הקשורים לאותה גישה.

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

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

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

             ·         נושא התיעוד / מסמכי המערכת – הפקה, הפצה, שמירה, אחזור וכו' – באחריות הספק.

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

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

 

ב.       תהליך ההתקשרות

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

             ·         יש לקבוע מראש קריטריונים להערכת וניקוד ההצעות

·         יש להקצות מספיק זמן למו"מ עם המציעים, לכל תהליך הרכש.

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

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

             ·         יש לעצור את תהליך ההתקשרות כל עוד הארכיטקטורה של המערכת החדשה (חומרה / תוכנה) לא סגורה ומאושרת. במקרים חריגים, יש לקבל אישור מהגורמים הבכירים ביותר ביחידת ה-IT

 

ג.        צוות בדיקת הצעות וסודיות מסחרית

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

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

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

 

ד.       דרישות מהספק

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

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

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

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

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

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

             ·         יש למנוע תלויות בין אספקות אחרות של הספק בהתקשרויות אחרות שלו מול הארגון.

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

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

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

             ·         חשוב לזכור – אין הכוונה שהספק יפסיד בפרויקט!

             ·         כלל ה- WIN-WIN אומר: "בואו לא נפעל בדרך שלי או בדרך שלך, אלא בדרך הטובה ביותר" (גרג אנדרסון).

 

ה.      טכנולוגיה חדשה

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

             ·         יש להיעזר בגורמי תשתית רלוונטיים שונים לקבלת הערכתם והמלצתם לאותה טכנולוגיה.

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

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

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

             ·        נדרש להקצות חוצצים גדולים יותר לפיתוח גם לצוותי התשתיות בפרויקט, בהנחה שגם להם התשתית חדשה.

             ·         נדרש להכשיר את גוף התשתיות לפני גוף הפיתוח.

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

             ·         יש להגדיר לו"ז המתחשב בחדשנות הטכנולוגית, לכל נושא הבדיקות, ההדרכה וההטמעה.

 

ו.         תשלום התמורה באבני הדרך

             ·         אין לאשר תשלום מראש, אלא רק לאחר אספקה ואישור התוצרים (סקר יכול להיות גם תוצר).

             ·         יש לוודא שבהסכם קיימת אופציה של "עיכוב תשלום", המעכבת חלק (10%, 15% וכו')  מעלות ההתקשרות הכוללת, עד אשר כל התוצרים שהתחייבו עליהם, יושלמו וימסרו.

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

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

             ·        בפרויקטים בהם נקבע שספק חייב לספק תקופת אחריות לאחר העברה לייצור, יש להקצות חלק מהתשלום הכולל עבור הפרויקט, בדרך כלל בין 5% - 15%, שישולם רק לאחר תום תקופת האחריות ויותנה בשביעות רצון מלאה של מנהלת הפרויקט / לקוח.

 

ז.        מכרזים וחברות לביצוע בתחומי התשתיות

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

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

 

ח.      ספק מחו"ל

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

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

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

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

             ·        שים לב, רק מה  שכתוב בבירור מחייב.

 

ט.      שיטות התקשרות

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

             ·         מחיר קבוע,

             ·         זמן וחומרים,

             ·         Cost +

 

י.         התקשרות במחיר קבוע

מהותה הגדרת עלות קבועה לתכולת פרויקט מוגדרת.

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

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

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

יש צורך בקיום מוקפד של סקר SRR (סקר דרישות מערכת), אפיון, עיצוב ועקיבות בשיתוף הספק בכדי להוריד מספר שינויים שידרשו.

 

יתרונות

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

 

חסרונות

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

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

             ·         רגישות לסיכונים.

 

יא.     התקשרות על בסיס זמן וחומרים

נהוגה בהתקשרויות מול חברות לצורך שכירת כוח אדם מקצועי (יועצים). מהותה: "קבל מוצר ושלם עליו בהתאם למשך השימוש".

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

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

 

יתרונת

העלויות בשיטה זו הן עלויות של הארגון והן כבר כוללות את רווח החברה.

 

יב.     התקשרות על בסיס "Cost +"

שיטה זו "מכסה" את עלות הפרויקט + רווח החברה מן הפרויקט.

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

בשיטה זו, החברה מגישה הצעת עלות הנדרשת לצורך פיתוח המוצר + עלות נוספת.

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

 

יתרונות

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

 

חסרונות

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

 

כתיבת הבקשה להצעות

הבקשה צריכה להיכתב באופן מפורט ולא להשאיר מקום לפרשנויות.

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

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

 

א.       תכולת המערכת

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

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

 

ב.       כוח אדם

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

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

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

 

ג.        ניסיון הספק

             ·        פירוט ניסיונו המוכח של הספק בביצוע פרויקטי מיקור חוץ.

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

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

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

 

ד.       טכנולוגיה

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

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

             ·         התממשקות לטכנולוגיות, השתלבות עם כלים שונים הקיימים בארגון.

             ·         המענה חייב לעמוד בדרישות אבטחת מידע של הארגון ולקחת בחשבון את המשמעויות (ביצועים וכו').

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

             ·         שדרוג חומרה בכל סביבות העבודה במהלך הפרויקט (פיתוח, בדיקות, ייצור) מדי X שנים, כנ"ל.

             ·         השדרוגים שצוינו בסעיפים שלעיל יכולים לכלול את עלות המוצרים (תוכנה/ חומרה) וביצוע העבודה או ביצוע העבודה בלבד כאשר עלות המוצרים היא ע"ח הארגון.

 

ה.      ביצועים ואמינות

הגדרת רמת ביצועים נדרשת של רכיבים שונים במערכת בסביבת הייצור שלה, למשל: משך עדכון טרנזקציה ב- On Line במערכת, משך עדכון טרנזקציה מול Main Frame, משך השבתה מקסימאלי (MTBF ו- MTTR), רמת אמינות נדרשת של ציוד היקפי וציוד קצה בתנאי סביבה שונים ועוד.

 

ו.         התקנה, הטמעה והדרכה

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

 

ז.        בדיקות

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

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

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

             ·         יש לחייב את הספק למסור את מפרטי בדיקות האספקה שלו לארגון.

             ·         יש לקבוע מראש את צוות בדיקות הלקוח.

             ·         יש להתייחס לסביבת בדיקת  הקבלה, היכן ממוקמת, מי אחראי עליה, מי מתקין אותה, מי מממן את הציוד.

             ·         נדרשת התייחסות מפורשת לסוגיית הסבת מידע ממערכת קיימת למערכת החדשה ומבחני קבלה למידע המוסב.

 

ח.      תפעול ותחזוקה

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

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

             ·         חשובה מאוד הגדרת SLA לתמיכה - יש להגדיר מראש, בשיתוף הגוף המתפעל, ולא לקראת שלב הטמעת המערכת.

             ·         פיתוח שו"שים (שינויים ושיפורים) - יש לקבוע מראש נוהל לתהליך הגדרת וביצוע שו"שים ואישורם. עלות שו"שים אלו תקבע לרוב לפי עלות שעות כוח אדם מקצועי.

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

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

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

 

ט.      ניהול ואבטחת איכות

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

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

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

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

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

 

י.         אבני דרך

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

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

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

 

 

 

מכרז

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

 

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

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

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

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

             ·         פרופיל החברה - דמיון בין תחומי עיסוק החברה למוצר המבוקש, פרויקטים דומים שבוצעו בחברה.

             ·         ניסיון שיש לחברה בעבודה עם הארגון.

 

מרבית המכרזים הינם משולבים: טכניים וניהוליים וגם כלכליים (קיימים מכרזים שהינם כלכליים נטו). במכרזים משולבים יש לתת תשומת לב לטבלת שקלול לתנאי סף טכניים וניהוליים ותנאי סף כלכליים. תנאי סף טכניים מתייחסים לפן הטכנולוגי ותנאי סף ניהוליים מתייחסים לאופן ניהול.

במכרז כלכלי יש להקפיד ליצור רשימת דרישות (סף) מפורטת ככל היותר כדי לוודא שהחברות שיתחרו בהיבט הכלכלי תהיינה רק המתאימות ביותר.

ד.       טיפים להוזלת עלויות הפרויקט

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

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

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

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

 

שלב הפיתוח

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

שלב זה מתבצע רובו ככולו על ידי הספק (למעט בדיקות קבלה).

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

 

הנחיות והמלצות

א.       כללי

             ·         יש לוודא שהוגדר תהליך למדידת ביצועי הספק.

             ·         יש לאפשר גישה לאנשי צוות רלוונטיים מטעם הארגון, להסכם עצמו ולהסכם רמת השירות (SLA) במטרה לסייע להם לבקר ולנטר את הפרויקט.

             ·         יש לתחזק רשימת הסכמים והסטאטוס שלהם, כדי לאפשר סקירה מהירה של כל פעילויות ההסכמים.

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

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

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

             ·         יש להקפיא את הדרישות  לאחר ה- SRR.

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

             ·         התחלת פיתוח התוכנה רק לאחר סיום אפיון הדרישות.

             ·         עמידה במשימה לאור המטרה – פַשְטוּת, הבאת מערכת מְסַפֶקֶת – תיבחן באמצעות מדידה.

             ·         קביעת תוכנית שיווק לפרויקט כחלק מתוכנית העבודה הפרויקטלית, התוכנית תכלול:

                         ·         הפצת מסמכים,

                         ·         הפצת אבות-טיפוס,

                         ·         חשיפה למנהלים בארגון,

                         ·         עידוד הצוותים העובדים,

                         ·         חשיפה לתקשורת.

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

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

 

ב.       אישור וטיפול בתשלומים

             ·         יש להכיר את דרישות הגורם המשלם – גוף הרכש בארגון.

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

             ·         יש לבדוק מסמכים משלימים בפרויקט, ולוודא שהספק מימש את הדרישות, לפני אישור התשלום.

             ·         יש לנטר את התשלומים למול התקציב והתנאים בהסכם.

             ·         יש לוודא שהוצאות הספקים מתועדות בצורה הולמת.

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

 

ג.        קשר עם הספק

             ·         שילוב איש קשר לארגון אצל הספק (בעל יכולות מתאימות) – בהתאם לגודל/מורכבות הפרויקט (חשש לעודף הזדהות).

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

             ·         קישור הספקים לדואר אלקטרוני של הארגון (במידת האפשר מבחינת מגבלות אבטחת מידע).

 

ד.       בקרה וניטור הפיתוח

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

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

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

             ·         יש לטפל באי-התאמות מייד עם גילויין.

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

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

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

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

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

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

             ·         דו"ח סטאטוס פרויקט – יש לקבל מהספק דו"ח סטאטוס פרויקט, אחד בכל חודש, על פי נוהלי הארגון. יש לוודא שילוב דרישה זו ב- SOW.

 

ה.      מנגנוני בקרה

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

להלן תיאור של מספר מנגנוני בקרה, את כולם נדרש להגדיר מראש במסמכי ההתקשרות השונים (החוזה, SOW וכו'):

 

             ·         הצגת אופן המענה על ידי הספק בפני מִנְהלת הפרויקט להתייחסות

             ·         ביצוע סקרים שוטפים על ידי הספק במהלך הפרויקט מול פורום הפרויקט,

             ·         הצגת אב טיפוס על ידי הספק,

             ·         ניהול הפרויקט על ידי הספק באמצעות גאנט המהווה כלי בקרה,

             ·         הגשת דוחות סטאטוס תקופתיים על ידי הספק,

             ·         ביצוע מבדקי איכות לספקים.

 

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

 

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

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

 

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

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

 

שלב קליטה והטמעה

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

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

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

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

בסיום ההרצה, מתבצעת העברת המערכת לייצור.

 

הנחיות והמלצות

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

למרות האמור לעיל, מומלץ להעביר את האחריות להדרכות בהיבט האפליקטיבי למִנהלת הפרויקט, תוך הקפדה על:

 

 ·         שימוש בכוח אדם מקצועי להדרכה

 ·         חיבור בין ההדרכה בהיבט האפליקטיבי להדרכה בהיבט העסקי

 ·         שילוב מערכי הדרכה ביחידות השונות.

 ·         במידה ונדרש, בניית כיתות ובניית סביבת הדרכה (העלויות גבוהות ונדרשת היערכות מראש).

 

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

 

שלב תפעול ותחזוקה

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

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

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

 

הנחיות והמלצות

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

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

 

עשייה "רוחבית" לאורך שלבי הפרויקט

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

ניהול סיכונים

הקצאת מנהל סיכונים

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

הקצאת אחראי לסיכון

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

 

ניהול ובקרת סיכונים במהלך הפרויקט

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

 

 ·         תאריך יעד – במקרה שלא יטופל, האם הסיכון ישפיע על יכולת צוות הפרויקט לעמוד בתאריך היעד לסיום הפרויקט?

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

 ·         איכות – האם עלייה ברמת הסיכון תשפיע על איכות העבודה? האם יידרש להקריב את האיכות במטרה לעמוד בתאריך היעד?

 ·         עלות – איזה עלויות נוספות תגרמנה, אם הסיכון יתבטא בעיכובים?

 ·         משאבים – האם יידרשו משאבים נוספים כדי למנוע את הסיכון? האם הצוות יידרש להשקיע יותר זמן (מה שישפיע על העלות)?

 

המלצות לביצוע

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

 

 

תוכנית ניהול סוגיות

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

סוגיות תנוהלנה במסגרת תוכנית ניהול סוגיות. המטרות העיקריות של תוכנית לניהול סוגיות הינן לוודא ש:

 

 ·         סוגיות מזוהות, מוערכות ומתועדות במטרה לפתור אותן,

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

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

 

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

 

תוכנית התקשורת בפרויקט

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

יישום תוכנית תקשורת שתוכננה היטב :

 

 ·         תסייע בתיאום וניהול ציפיות בקשר לפרויקט,

 ·         תוודא שהשיטה שתשמש לתקשורת, תהיה אפקטיבית ביותר,

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

 ·         תספק מידע רלוונטי, מדויק ועקבי, כל הזמן,

 ·         תייצר התלהבות בפרויקט ותתמוך בה לאורך זמן.

 

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

 

אישור ספקים לעמידה בדרישות האיכות

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

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

 

 ·         לימוד והכרת הרקע והדרישות מהספק

 ·         תכנון המבדק

 ·         ביצוע המבדק

 ·         ביצוע פעילות מתקנת ואישור הספק

 

גורמים מעורבים

אנשי איכות גורמים טכניים ואנשי רכש בארגון.

טפסים

 ·         רשימת תיוג למבדק איכות ספקים.

 ·         גלופה לסיכום מבדק.

התהליך

לימוד והכרת הרקע והדרישות מהספק

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

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

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

 ·         ציפיות מהספק.

 ·         דרישות מיוחדות בתהליך האישור.

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

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

 ·         הכנת תוכנית עבודה לבדיקת עמידת הספק בדרישות האיכות.

 ·         השלמה וקבלת חומר מהגורמים הבאים: אנשי האיכות, גורמים טכניים רלוונטיים, אנשי רכש, הספק

 ·         קבלת פרטי אנשי הקשר של הספק.

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

תכנון המבדק

·         בניית תכנית מבדקים ואישורה.

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

 ·         תיקוף רשימת התיוג על ידי מנהלי האיכות והרכש בארגון.

 ·         תיאום מועד המבדק ביחד עם הספק.

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

 

ביצוע המבדק

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

 ·         במועד המבדק - ביצוע שיחת פתיחה המתארת את הרקע לביצוע המבדק ואת שיטת ביצוע הסיקור.

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

 ·         סיכום המבדק - הצגת הממצאים, אי ההתאמות לדרישות וקביעת רמת ההתאמה.

 ·         קבלת הערות ופרסום דו"ח מבדק מסכם.

 ·         קבלת תוכנית פעולה מתקנת מהספק.

 ·         אישור תוכנית פעולה מתקנת של הספק.

 

ביצוע פעילות מתקנת ואישור הספק

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

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

 ·         משלוח מכתב אישור לספק.

בקרות ומדדים

בקרות איכות

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

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

 

בקרות לו"ז ותקציב

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

 ·         בפגישה הרבעונית תעודכן תוכנית העבודה ותתבצע בקרה תקציבית.

מדדים

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

תוצרים

סטאטוס פרויקט

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

סיכום מבדק איכות ספקים

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

רשימת תיוג למבדק איכות ספקים

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

תוכנית התקשורת בפרויקט

 

תוכנית זאת כולל את המרכיבים הבאים: קהלי יעד, תוכנית תקשורת, טבלת ריכוז הדיונים, לו"ז התקשורת, תבניות תקשורת, עקרונות תקשורת.

 

רשימת תיוג לתוכנית ניהול סוגיות

טבלת ניהול לסטטוס הטיפול בנושאים שונים בניהול הסוגיות.