הכנת מכרז

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

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

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

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

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

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

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

מתודולוגית היישום

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

העברת המערכת לאחריות הלקוח

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

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

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

אחריות

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

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

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

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

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

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

הדרכה והטמעה

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

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

1. הדרכה מלאה ע"י הספק לכל המשתמשים בארגון
2. Train the Trainers - הדרכת מדריכים שידריכו את המשתמשים. מודל זה נהוג בארגונים גדולים שיש להם מחלקות הדרכה פנימיות. למודל זה יש מספר יתרונות ביניהם: הוא זול הרבה יותר בגלל שמדריכים מספר מצומצם של מדריכים שיעבירו הדרכות לכלל המשתמשים והוא מבטיח על שמירת ידע בארגון ויכולת הדרכת משתמשים כאשר ישנה תחלופה של עובדים.

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