דגשים להצלחתו של פרויקט תוכנה

 

איך מבטיחים הטמעה אופטימלית של מערכות מידע בארגון?

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

1. מערכות לניהול תנועות (TPS - Transaction Processing System) 

2. מערכות מידע ניהוליות (MIS - Management Information Systems) 
3. מערכות תומכות החלטה (DSS - Decision Support System) 
4. מערכות מידע למנהלים בכירים (ESS (EIS) - Executive Support Systems) 

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

אם בעבר לארגון היו מערכות מידע רבות שלכל אחת מהן בסיס נתונים משלה, דבר הגורם להוצאות תחזוקה רבות ולכפילות נתונים, כיום הארגון מעוניין במערכת מידע אחת (ERP - Enterprise Resource Planning), אשר לה בסיס נתונים אחד ומסביבה מערכות עזר (כגון: BI, CRM, PM) אשר עונות על צרכים נוספים ומשתמשות באותו בסיס נתונים. בצורה זו, הארגון חוסך הוצאות תחזוקה והמידע קיים במקום מרוכז אחד – באינטגרטיביות מלאה וללא כפילויות. 

 

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

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

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

1. פיתוח עצמי של תוכנה מותאמת ע"י יחידת מערכות המידע של הארגון
2. הרחבה או שינוי במערכת הקיימת
3. פיתוח חיצוני של תוכנה מותאמת לצרכיו של הארגון
4. רכישת מוצר מדף ללא ביצוע התאמות לצרכיו של הארגון
5. רכישת מוצר מדף והתאמתו לצרכי הארגון

 

יתרונות וחסרונות בפרויקטים השונים

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

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

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

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

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

1. ניהול הפרויקט על פי מתודולוגית מחזור החיים

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

א) שלב הייזום

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

ב) שלב הדרישות

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

 

ג) בקשה למידע (RFI-Request For Information)

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

ד) בקשה להצעה (RFP-Request For Proposal)

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

ה) שלב האפיון

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

ו) עיצוב ובנייה

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

ז) בדיקות מערכת ואינטגרציה

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

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

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

ט) ביצוע פיילוט

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

י) העברה לייצור

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

יא) תחזוקה

בשלב זה המערכת עובדת בצורה שוטפת, ומתבצעת בה תחזוקה שוטפת.

יב) ניטור וסקירה

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

 

2. תמיכה והובלה מצד ההנהלה

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

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

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

 

3. הקמת ועדות מקצועיות ומינוי מנהלי פרויקטים

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

ועדת היגוי

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

מנהלת הפרויקט

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

מנהל הפרויקטים

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

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

 

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

 

3. ניהול הזמן - השילוב בין זמני הביצוע של המשימות השונות במהלך הפרויקט. 

 

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

 

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

 

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

 

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

 

8. ניהול הסיכונים - ניהול הסיכונים הינו תהליך כולל לכל שלבי הפרויקט (יורחב בהמשך).

 

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

 

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

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

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

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

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

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

 

1. הכנת תבנית פעולה לגידור סיכונים

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

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

 

1. מימוש תוכנית הגידור

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

 

5. שימוש באבני דרך לכל אורך חיי הפרויקט 

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

 

6. שימוש בכלים ייעודים לניהול תכנון ובקרה

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

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

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

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

 

1. נתיב קריטי

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

סיכום

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

---

 

צרו קשר עם המומחים שלנו למערכות מידע

 

מקורות מידע: 

• PMBOK - Project Management Body Of Knowledge

• COBIT- IT Government Institute 4.1 

• נוהל מפת"ח לניהול פרויקטי תוכנה.

 

הירשם לניוזלטר

Please fill out the following form to access the download.